セキュリティ、プライバシー、コンプライアンス

アーキテクチャ フレームワークのこのセクションでは、セキュリティ コントロールの計画方法、プライバシーへのアプローチ、Google Cloud コンプライアンス レベルへの対応方法について説明します。

このフレームワークは、次の一連のドキュメントで構成されています。

戦略

次の戦略に基づいてセキュリティ、プライバシー、コンプライアンスを実現します。

ID と承認を制御し、必要最小限の権限を実装する。一元化された ID 管理を使用して、最小権限の原則に従い、適切な承認レベルとアクセス ポリシーを設定します。

階層化されたセキュリティ アプローチを構築する。アプリケーションとインフラストラクチャの各レベルでセキュリティを実装し、多層防御を実現します。各プロダクトの機能を使用してアクセスを制限します。暗号化を使用します。

重要なタスクのデプロイを自動化する。デプロイやその他の管理タスクを自動化し、人手による作業をなくします。

セキュリティ モニタリングを実装する。自動化ツールを使用して、アプリケーションとインフラストラクチャをモニタリングします。継続的インテグレーションと継続的デプロイ(CI/CD)のパイプラインで自動スキャンを使用し、インフラストラクチャの脆弱性を検出します。

ベスト プラクティス

セキュリティ、プライバシー、コンプライアンスを実現するには、次の方法をおすすめします。

  • リスクをコントロールする。
  • 認証と承認を管理する。
  • コンピューティングのセキュリティ コントロールを実装する。
  • ネットワークを保護する。
  • データ セキュリティ コントロールを実装する。
  • サプライチェーンのコントロールを使用してアプリケーションを構築する。
  • 監査ログを使用してインフラストラクチャを監査する。

リスクをコントロールする

Google Cloud でリソースを作成してデプロイする前に、セキュリティ機能を調査し、内部セキュリティ要件と外部規制要件を満たしているかどうかを評価します。

次の 3 つの管理領域でリスク回避を行います。

  • 技術的なコントロール。環境の保護に使用する機能とテクノロジーのことです。これには、ファイアウォールやロギングの有効化など、ネイティブのクラウド セキュリティ コントロールが含まれます。また、セキュリティ戦略を強化またはサポートするサードパーティ ツールやベンダーも該当します。
  • 契約による保護。Google Cloud サービスに関してクラウド ベンダーと締結した契約のことです。
  • 第三者による検証または証明。クラウド プロバイダがコンプライアンス要件を満たしていることを第三者機関が監査することです。たとえば、Google は ISO 27017 のコンプライアンスについて第三者機関の監査を受けています。

新しいパブリック クラウド サービスを導入する際のリスクを軽減するには、この 3 つの管理領域をすべて評価する必要があります。

技術的なコントロール

Google Cloud では、お客様がご自身のデータを所有し、その使用方法を制御することが基本的な前提となっています。お客様が Google Cloud システムに保存して管理するデータは、そのお客様に Google Cloud サービスを提供し、そのサービスを改善する目的でのみ使用されます。これ以外の目的では使用されません。Google では、お客様のデータへの内部からのアクセスを防ぐため、堅牢な内部統制と監査を行っています。たとえば、Google Cloud では、Google 管理者アクセスのログがほぼリアルタイムに提供されます。

契約による管理

Google Cloud は、コンプライアンス ポートフォリオの維持と拡大に取り組んでいます。データ処理およびセキュリティ規約(DPST)では、ISO 27001、27017、27018 の認証の維持と 12 か月ごとの SOC 2 および SOC 3 レポートの更新が定義されています。

DPST には、厳格なロギングと承認プロセスなど、Google サポート エンジニアによるお客様の環境へのアクセスを制限するアクセス制御の概要も記述されています。また、アクセス制御と契約上のコミットメントに関する詳細情報も記述されています。

第三者機関の証明書

コンプライアンス リソース センターで、Google Cloud の現在の認定と証明書を確認できます。

リソース

信頼とセキュリティ

認証と承認を管理する

Google Cloud 内では、Identity and Access Management(IAM)を使用してリソースのアクセス権を指定します。管理者は、リソースレベルでアクセスを制限できます。IAM ポリシーでは、「誰がどのリソースに対して何を行えるか」が規定されています。IAM ポリシーを正しく構成することで、リソースへの不正アクセスを防ぐことができます。

セキュリティ管理者は、ジョブの実行に必要なリソースとサービスにのみアクセスを許可したいと考えています(最小権限の原則)。

ジョブの実行に必要な管理権限よりも多い権限をユーザーに付与するべきではありません。また、付与する権限が少なすぎるのも問題です。権限を過剰に付与すると、内部の脅威やリソースの構成ミスが増加し、監査が難しくなる可能性があります。付与する権限が十分でないと、ユーザーがタスクの完了に必要なリソースにアクセスできなくなります。

アクセス管理ポリシーを作成する際に、さまざまな技術的な制御を利用できます。アクセス制御に使用できる主な機能とサービスは次のとおりです。

適切なロールを付与する

ロールは、ユーザーに適用される権限のコレクションです。権限により、リソースに許可されるアクションが決まります。通常は、REST メソッドに対応しています。たとえば、ユーザーまたはユーザー グループに Compute 管理者のロールを付与し、Compute Engine インスタンスの表示と編集を許可できます。

サービス アカウントを使用するタイミングについて

サービス アカウントは、個々のエンドユーザーではなく、アプリケーションや仮想マシン(VM)に属している特別な Google アカウントです。アプリケーションはサービス アカウントを使用して、サービスの Google API を呼び出します。ユーザーが直接関与することはありません。

組織ポリシー サービスを使用する

IAM で重要なのは「誰であるか」です。管理者は、特定のリソースに対して誰がアクションを実施できるかを権限に基づいて承認します。組織ポリシー サービスで重要なのは「」で、管理者は特定のリソースに対して制限を設定し、どのような構成が可能であるかを決定できます。

Cloud Asset Inventory を使用する

このサービスは、1 回の API 呼び出しで、さまざまな Google Cloud リソースとポリシーについてインベントリの組織全体のスナップショットを提供します。自動化ツールは、そのスナップショットをモニタリングやポリシー適用に使用します。また、コンプライアンス監査のためにアーカイブします。アセットの変更を分析する場合は、アセット インベントリでメタデータの履歴をエクスポートできます。

Policy Intelligence を使用する

推奨ツール、トラブルシューティング ツール、検証ツールは、IAM ロールの割り当てに関する推奨事項を提供します。過度に許容される IAM ポリシーをモニタリングして防止し、アクセス制御に関する問題のトラブルシューティングを支援します。

設計に関する質問

  • ID をどのように管理しているのか。
  • Google Cloud と ID の連携は可能か。
  • ユーザータイプに必要なアクセス権限は何か。プログラムによるアクセスとして、どのようなものが必要か。
  • デプロイ環境(テスト、開発、本番など)に応じて、ユーザーにアクセス制御のロールと権限を付与して監査するプロセスはあるか。

推奨事項

最小限の権限

  • (ロール/オーナー、ロール/編集者、ロール/閲覧者)などの基本的なロールは避けます。可能であれば、事前定義されたロールまたはカスタムロールを付与します。
  • 次のような場合には基本ロールを付与します。

    • Google Cloud サービスで事前定義ロールを利用できない場合。
    • プロジェクトに関する幅広い権限を付与する必要がある場合。この状況は、開発またはテスト環境で権限を付与する場合によく生じます。
    • メンバーがきめ細かい権限を必要としない小規模なチームで働いている場合。
  • アプリケーションの個々のコンポーネントは個別の信頼境界として扱ってください。異なる権限を必要とする複数のサービスがある場合は、サービスごとに個別のサービス アカウントを作成した後で、各サービス アカウントに必要な権限のみを付与します。

  • サービス アカウントとして活動できるユーザーの数を制限します。サービス アカウントに対するサービス アカウント アクターのロールを付与されたユーザーは、そのサービス アカウントがアクセス権を持つすべてのリソースにアクセスできます。サービス アカウント アクターのロールをユーザーに付与する際は十分な注意が必要です。

  • 各リソースに付与されているポリシーを確認し、継承階層を把握してください。子リソースに設定したポリシーで親リソースに付与されたアクセス権が制限されることはありません。

  • 必要最小限の範囲のロールを付与します。たとえば、ユーザーが Pub/Sub トピックを公開するだけの場合は、そのトピックのパブリッシャー ロールをユーザーに付与します。

  • メンバーにオーナーのロールを付与すると、このメンバーは、IAM ポリシーの変更を含め、ほぼすべてのリソースにアクセスして変更できるようになります。この権限の範囲の広さには、潜在的な危険も潜んでいます。オーナーのロールは、ユニバーサルなアクセス権が必要な場合にのみ付与してくだい。

  • デフォルトでは、組織を作成すると、ドメインのすべてのユーザーに請求先アカウント作成者とプロジェクト作成者のロールが組織レベルで付与されます。これらの職務を行えるユーザーを特定し、他のユーザーからこれらのロールを取り消します。

  • 個々のユーザーではなく Google グループにロールを付与します。IAM ポリシーを更新してユーザーを追加または削除する代わりに、Google グループでメンバーの追加または削除を行うほうが簡単です。

  • 特定のタスクの実行を許可するために複数のロールを付与する必要がある場合は、Google グループを作成してそのグループにロールを付与し、そのグループにユーザーを追加します。

  • Cloud Asset Inventory を使用している組織内のすべてのリソースを追跡します。

  • Policy Intelligence を使用して、ポリシー管理を自動化し、検証またはトラブルシューティングを行います。

  • IAM Conditions を使用して、リソースへのアクセスを条件付きの属性ベースで制御します。

  • VPC Service Controls を使用して多層防御を実装し、リソースへのアクセスをさらに制限します。

監査

  • Cloud Audit Logs を使用して、IAM ポリシーに対する変更を定期的に監査します。
  • Cloud Storage に監査ログをエクスポートして、ログを長期間保存します。
  • プロジェクトの IAM ポリシーを変更できるユーザーの管理状況を監査します。
  • ロギングのロールを使用して、ログへのアクセスを制限します。
  • ログ閲覧者に適用されるアクセス ポリシーを、ログのエクスポートに使用する Google Cloud リソースに適用します。
  • Cloud Audit Logs を使用して、サービス アカウント キーへのアクセスを定期的に監査します。

主なサービス

IAM は、特定の Google Cloud リソースにアクセスしてアクションを実行できるユーザーを承認し、Google Cloud リソースを一元管理します。

コンテキストアウェア アクセスは、ユーザーの ID とリクエストのコンテキストに基づいて、Google Cloud ワークロードとウェブ アプリケーションに対してきめ細かいアクセス制御を行います。Google では、組織でゼロトラスト セキュリティ モデルを使用することをおすすめしています。

Cloud Asset Inventory は、時系列データベースに基づいてインベントリ サービスを提供します。このデータベースには、Google Cloud のアセット メタデータの 5 週間分の履歴が保管されています。このサービスでは、特定のタイムスタンプを持つすべてのアセット メタデータをエクスポートできます。また、期間内のイベントの変更履歴をエクスポートすることもできます。

Cloud Audit Logs では、Google Cloud リソースに対して「誰が、いつ、どこで何をしたか」を確認できます。

リソース

コンピューティングのセキュリティ コントロールを実装する

リソースをネットワークに公開する方法を常に保護することをおすすめします。Google Kubernetes Engine(GKE)Compute Engine で利用可能な制御機能は次のとおりです。

プライベート IP

組織のポリシーを使用して、本番環境の VM への外部 IP からのアクセスを拒否します。GKE 内に限定公開 IP を持つ限定公開クラスタをデプロイすると、ネットワーク攻撃の可能性を抑えることができます。ネットワーク ポリシーを定義して、クラスタ内の Pod 間の通信を管理することもできます。

Compute インスタンスの使用状況

侵害が発生した場合は莫大なコストが発生する可能性があるため、インスタンスを起動し、IAM を使用してアクセスを制御できるユーザーを把握しておく必要があります。Google Cloud では、プロジェクトにカスタム割り当てを定義し、このようなアクティビティを制限できます。VPC Service Controls も役立ちます。詳細については、ネットワーク セキュリティに関するセクションをご覧ください。

Compute OS イメージ

Google では、定期的に管理とパッチ適用が行われている OS イメージを提供しています。独自のカスタム イメージを Compute Engine で実行することもできますが、パッチの適用、更新、保守は自身で行う必要があります。Google Cloud では、セキュリティに関する公開情報を通じて新たに見つかった脆弱性を定期的に公開し、既存のデプロイの脆弱性を修正しています。

GKE と Docker

App Engine フレキシブル環境では、Docker コンテナ内でアプリケーション インスタンスを実行できます。インスタンスはランタイムにいつでも実行できます。基盤となるインスタンスへの SSH アクセスを有効にすることもできますが、有効なビジネス ユースケースがない限り、これはおすすめしません。

Cloud Audit Logs は GKE で有効になっているため、クラスタでのすべてのアクティビティを自動的に収集し、不審なアクティビティをモニタリングできます。

クラスタにインフラストラクチャ セキュリティを提供するため、GKE では IAM とロールベースのアクセス制御(RBAC)を使用して、クラスタと名前空間へのアクセスを管理できます。

クラスタノードに常に最新のパッチが適用されているように、ノードの自動アップグレードを有効にできます。Google は GKE マスターを管理し、定期的に自動更新してパッチを適用します。また、Google が選んだコンテナ最適化イメージをデプロイに使用します。これは Google によって定期的にパッチが適用され、更新されます。

GKE Sandbox は、ホストカーネルから分離された追加のセキュリティ レイヤを必要とするマルチテナント アプリケーションのデプロイに適しています。

ランタイム セキュリティ

GKE は、さまざまなパートナー ソリューションと連携し、ランタイム セキュリティを実現しています。また、堅牢なソリューションを使用してデプロイのモニタリングと管理を行うこともできます。これらのソリューションはすべて、Security Command Center と統合されているので、単一ペインから確認できます。

ホスト保護のパートナー ソリューション

ホストの保護には、Google から提供される厳選の OS イメージだけでなく、さまざまな Google Cloud パートナー ソリューションを使用できます。Google Cloud で提供されるほとんどのパートナー ソリューションは Security Command Center と統合されており、パートナー ポータルで高度な脅威分析や追加のランタイム セキュリティに利用できます。Forseti も Security Command Center に統合されたセキュリティ ソリューションで、構成違反をモニタリングしてアラートを表示します。

設計に関する質問

  • コンピューティング ノードのセキュリティをどのように管理しているのか。
  • ホストベースの保護が必要か。
  • 厳選された強化イメージを使用しているか。
  • 本番環境でコンピューティング ノードを作成または削除できるユーザーをどのように制御するのか。
  • コンピューティングの作成と削除をどのくらいの頻度で監査しているのか。
  • サンドボックス環境でデプロイのセキュリティ テストを実施しているか。デプロイを実行してモニタリングし、デプロイノードの現在のバージョンとの互換性をどのくらいの頻度で更新しているのか。

推奨事項

  • 可能であれば、サービス アカウントを使用して VM との通信を分離します。
  • 明示的に必要な場合を除き、組織レベルで外部 IP アドレスを無効にします。
  • Google 厳選のイメージを使用する。
  • 新しい脆弱性に関するセキュリティ情報を追跡し、インスタンスを修正します。
  • GKE を使用する場合はプライベート マスター デプロイを使用します。
  • Workload Identity を使用して、GKE クラスタから Cloud API へのアクセスを制御します。
  • GKE ノードの自動アップグレードを有効にします。

主なサービス

Shielded VM は、ルートキットやブートキットからの保護に役立つ一連のセキュリティ制御によって強化された Google Cloud 上の仮想マシン(VM)です。Shielded VM を使用することで、リモート攻撃、権限昇格、悪意のある内部関係者といった脅威から企業のワークロードを保護できます。Shielded VM では、高度なプラットフォーム セキュリティ機能として、セキュアブート、メジャード ブート、仮想トラステッド プラットフォーム モジュール(vTPM)、UEFI ファームウェア、整合性モニタリングなどを使用します。

Workload Identity は、GKE 環境全体で最小権限の原則を適用しながら、侵害や不正アクセスの潜在的な影響範囲を減らします。

GKE Sandbox は、GKE 上でコンテナ化されたワークロード間の 2 番目の防御レイヤを提供するコンテナ分離ソリューションです。GKE Sandbox は、低 I/O でありながら高度にスケールされたアプリケーションを考慮して構築されました。これらのコンテナ化されたワークロードは、速度とパフォーマンスを維持する必要がありますが、セキュリティ強化のため、信頼性の低いコードが含まれている場合もあります。コンテナ ランタイム サンドボックスである gVisor は、アプリケーションとホストカーネル間に強化されたセキュリティ分離を提供します。gVisor を使用すると、整合性チェックの追加や、サービスのアクセス範囲の制限を行うことができます。これは、外部の脅威から保護するためのコンテナ強化サービスではありません。

リソース

ネットワークを保護する

新しいプロジェクトを作成すると、デフォルトの Google Cloud Virtual Private Cloud(VPC)が RFC 1918 IP アドレスで自動的にプロビジョニングされます。本番環境のデプロイでは、このデフォルトの VPC を使用しないことをおすすめします。代わりに、この VPC を削除して、必要なサブネットを持つ新しい VPC をプロビジョニングします。VPC ではプライベート IP アドレスを使用できるため、接続されたデプロイとプロジェクト全体でネットワークと IP アドレスの割り当てを慎重に設計することをおすすめします。IAM の適用を効果的に行うには、これらのネットワークをプロジェクトごとに 1 つにする必要があります。

Virtual Private Cloud を使用すると、デプロイ、管理、制御を一元化できます。単一のネットワークを提供し、ワークロードを複数のチームによって管理される個々のプロジェクトに分離する堅牢な本番環境デプロイを構築できます。Virtual Private Cloud はホスト プロジェクトとサービス プロジェクトで構成されます。ホスト プロジェクトは、よく考えられた VPC とサブネットを持つメイン プロジェクトです。サービス プロジェクトは、ホスト プロジェクトのサブネットに接続されるので、IAM を使用してプロジェクト レベルでユーザーを分離できます。

Cloud LoggingCloud Monitoring を使用すると、さまざまなサービスから大規模なログを取り込み、すぐに可視化できます。この機能を外部のセキュリティ情報 / イベント管理(SIEM)ツールと統合し、高度な脅威を分析できます。

ファイアウォール

Google Cloud のファイアウォールはスケーリングに優れています。プロジェクト レベルで定義でき、接続されているインスタンス レベルで評価されます。ファイアウォール ルールでは、上り(内向き)と下り(外向き)のネットワーク トラフィックを対象とする複数のルールを定義できます。このようなファイアウォール ルールを適用するスケーラブルなアプローチでは、ネットワーク タグまたはサービス アカウントを対象にします。

ファイアウォール ルールをより安全な方法でデプロイするには、サービス アカウントでファイアウォール ルールを使用します。ただし、Virtual Private Cloud のデプロイを使用する場合は、ホスト プロジェクトでファイアウォールを一元管理するように定義します。

ネットワーク侵入検知

多くのお客様は、オンプレミスで高度なセキュリティとトラフィック検査ツールを使用しています。特定のアプリケーションでは、同じツールをクラウドでも利用できます。VPC パケット ミラーリングを使用すると、既存の Virtual Private Cloud(VPC)のトラブルシューティングを行うことができます。Google Cloud パケット ミラーリングでは、サードパーティ ツールを使用してネットワーク トラフィックの収集と検査、侵入検知、アプリケーション パフォーマンス モニタリング、セキュリティ制御の強化を行い、Compute Engine と Google Kubernetes Engine(GKE)で実行されるワークロードのセキュリティとコンプライアンスを維持できます。

トラフィック管理

本番環境デプロイの場合は、各 VPC で構成されたルートを確認します。厳密なルールと限定的なルールを使用することをおすすめします。GKE デプロイの場合は、Traffic Directorを使用して Envoy 管理をスケーリングするか、Istio でトラフィック フローを管理します。

ネットワーク接続

Google Cloud 内で Virtual Private Cloud を選択するか、VPC ピアリングを使用します。ピアリングされたプロジェクトでは、ネットワーク タグとサービス アカウントは変換されませんが、Virtual Private Cloud を使用すると、これらをホスト プロジェクトで一元管理できます。Virtual Private Cloud ではサービス アカウントとネットワーク タグを一元管理できますが、割り当てと制限の管理方法は慎重に計画することをおすすめします。VPC ピアリングでは、これらの制御を管理する作業が重複する可能性がありますが、割り当てと制限は柔軟に設定できます。

外部アクセスの場合は、帯域幅のニーズを評価し、Cloud VPNCloud InterconnectPartner Interconnect のいずれかを選択します。単一の VPC またはプロジェクトを介してジャンプ ポイントを一元化することで、ネットワーク管理を最小限に抑えることができます。

VPC Service Controls は、IAM とは異なる追加のセキュリティ防御レイヤを Google Cloud サービスに提供します。IAM では詳細な ID ベースのアクセス制御が可能ですが、VPC Service Controls では、境界全体での下り(外向き)データの制御など、コンテキスト ベースの境界セキュリティが可能になります。VPC Service Controls と IAM を使用して、多層防御を実装します。

組み込みツール

Security Command Center には、Event Threat Detection(イベント脅威検出)、Google Cloud Armor ログ、Security Health Analytics(SHA)など、インフラストラクチャのセキュリティ分析に役立つ複数の検出機能があります。ワークロードに必要なサービスを有効にし、必要なデータのみをモニタリングして分析します。

Network Intelligence Center では、ネットワーク トポロジとアーキテクチャのパフォーマンスを視覚的に確認できます。ネットワーク パフォーマンスに関する詳細な分析情報を取得し、デプロイを最適化してサービスのボトルネックを解消できます。Network Reachability は、ネットワーク パスに適用されるファイアウォール ルールとポリシーに関する分析情報を提供します。

設計に関する質問

  • 現在、ネットワーク セキュリティをどのように管理しているか。
  • 境界ベースのファイアウォール フィルタリングを使用しているか。
  • アプリケーション レベルのファイアウォール フィルタリングに移行可能か。
  • ネットワーク アクセス制御をどのように管理しているのか。
  • 静的 IP アドレスの依存度が高いか。
  • サービスベースのアクセス制御に移行可能か。
  • ネットワーク セキュリティをどのようにモニタリングしているのか。
  • ネットワーク トラフィックのモニタリングに IDS/IPS を使用しているか。
  • 管理者が本番環境にアクセスするために、ネットワークをどのように管理しているのか。
  • 管理者のネットワーク アクセス アクティビティをモニタリングするために、監査を頻繁に行っているか。

推奨事項

  • VPC Service Controls を使用して機密データにサービス境界を定義します。
  • 可能であれば、Google Cloud ネイティブのファイアウォール ルールでトラフィックを管理します。
  • 可能であれば、少数の広範なファイアウォール ルールセットを使用します。
  • セキュリティを強化するため、サービス アカウントをファイアウォール ルールと併用します。
  • タグを使用する場合は、セキュリティ ポリシーのモニタリングを自動化します。
  • Security Command Center に加えて、サードパーティ製ツールを使用してネットワークを保護します。
  • 外部アクセスを制限します。
  • VPC のデフォルト ルートを変更する必要がある場合は、Google API の明示的なルートを追加します。
  • Google API を使用するインスタンスを同じサブネットにデプロイします。

主なサービス

VPC Service Controls を使用すると、Cloud Storage や BigQuery などの Google マネージド サービスからのデータ引き出しのリスクを軽減できます。VPC Service Controls を使用すると、Google マネージド サービスのリソースにセキュリティ境界を構成し、境界をまたがるデータの移動を制御できます。

Traffic Director は、Google Cloud のサービス メッシュ用フルマネージド トラフィック制御プレーンです。Traffic Director を使用すると、複数のリージョンのさまざまなクラスタや VM インスタンスでのグローバルな負荷分散のデプロイ、サービス プロキシからのヘルスチェックのオフロード、高度なトラフィック制御ポリシーの構成を行うことができます。Traffic Director は、オープン標準 API(xDS v2)を使用してデータプレーンのサービス プロキシと通信し、専用ソリューションに限定されないサービス メッシュ制御プレーンを使用できます。

Security Command Center では、Google Cloud のリソースとそのセキュリティの状態を確認できます。Security Command Center を使用すると、脅威の防止、検出、対処をより簡単に行うことができます。一元化されたダッシュボードから仮想マシン、ネットワーク、アプリケーション、ストレージ バケットの誤構成を特定し、ビジネス上の損害や損失が発生する前に必要か対策を講じることができます。また、Cloud Logging のセキュリティ ログ内の不審なアクティビティをすばやく表面化する機能や、仮想マシンの不正な使用を指摘する機能も組み込まれています。推奨事項に従って脅威に対処することも、ログを SIEM にエクスポートしてさらに詳しく調査することもできます。

Event Threat Detection は、Google Cloud 環境のさまざまなログを自動的にスキャンします。業界トップクラスの脅威インテリジェンスを使用して、マルウェア、クリプトマイニング、Google Cloud リソースへの不正アクセス、DDoS 攻撃、ブルートフォース SSH など、危険度が高く多大な被害をもたらす脅威を迅速に検出できます。セキュリティ チームは大量のログデータから情報を抽出し、リスクの高いインシデントをすばやく識別して修復に専念できます。

Istio は、統一された方法でマイクロサービスの接続、管理、保護を実現するオープン サービス メッシュです。マイクロサービス コードを変更することなく、サービス間のトラフィックフ ローの管理、アクセス ポリシーの適用、テレメトリー データの集計を行うことができます。Google Kubernetes Engine 上の Istio は GKE のアドオンです。Istio サービス メッシュとして作成して実行するすべてのコンポーネントを含むクラスタをすばやく作成できます。

パケット ミラーリングを使用すると、ネットワーク トラフィックをミラーリングし、侵入検知ソリューション(IDS)などのサードパーティのセキュリティ ソリューションに送信できます。侵入検出ソリューションが必要になる規制やコンプライアンスの要件(PCI 11.4 など)に対応しています。

リソース

データ セキュリティ コントロールを実装する

データ セキュリティ コントロールは、暗号化、ストレージ、データベースの 3 つの領域に実装できます。

暗号化

Google Cloud では、ニーズに合わせてさまざまな暗号鍵管理オプションを提供しています。ストレージ、コンピューティング、ビッグデータ ワークロードのいずれを選択する場合でも、鍵の生成、保管、ローテーションの要件にどのソリューションが最適かを判断する必要があります。広範なデータ セキュリティ戦略の一部として暗号化を使用します。

デフォルトの暗号化: 顧客データの保存時に Google Cloud がデータを暗号化します。ユーザーが特別な操作を行う必要ありません。エンベロープ暗号化の仕組みについては、Google Cloud での保存時の暗号化をご覧ください。

カスタム暗号化: Google Cloud では、Cloud Key Management Service(Cloud KMS)に鍵暗号鍵を保存する際に、エンベロープ暗号化を使用してデータを暗号化できます。また、必要に応じて Cloud Hardware Security Modules(HSM)も使用できます。Cloud KMS / HSM で個々の鍵に対してユーザーレベルの IAM 権限を使用すると、アクセスと暗号化プロセスを管理できます。管理アクティビティと鍵の使用ログを確認するには、Cloud Audit Logs を使用します。データを保護するには、Monitoring でログをモニタリングし、鍵が適切に使用されているかどうか確認します。

ストレージ

Cloud Storage ではオブジェクトのバージョニングを利用できます。状態を維持する必要があるオブジェクトに対しては、この機能を有効にすることをおすすめします。バージョニングにより追加のストレージ コストが発生するため、プライベート オブジェクトに対して使用する際は慎重に検討する必要があります。

オブジェクトのライフサイクル管理は、古いオブジェクトをアーカイブし、ストレージ クラスをダウングレードしてコストを削減する際に役立ちます。こうした操作を行うと、ストレージ クラスの変更とデータアクセスに関連するコストが発生する可能性があるため、慎重に計画する必要があります。

バケットロックを使用した保持ポリシーでは、コンプライアンスや訴訟で保存が義務付けられているオブジェクトのバケット内での保存期間を制御できます。バケットを特定の保持ポリシーでロックした場合、有効期限の前にバケットを削除することはできません。

アクセス制御

IAM 権限を使用すると、バケットに対するアクセス権とバケット内のオブジェクトへのアクセス権を付与できます。IAM 権限では、プロジェクトとバケットに対する幅広い制御が可能ですが、個々のオブジェクトを細かく制御することはできません。

アクセス制御リスト(ACL)は、個々のバケットやオブジェクトへの読み取りまたは書き込みアクセスを許可します。ほとんどの場合、ACL ではなく IAM 権限を使用することをおすすめします。ACL は、個々のオブジェクトを細かく制御する必要がある場合にのみ使用します。

署名付き URL(クエリ文字列認証)は、生成した URL を通じて、オブジェクトへの制限時間付きの読み取りまたは書き込みアクセスを許可します。URL を共有しているユーザーには、Google アカウントの有無にかかわらず、一定期間、オブジェクトに対するアクセスが許可されます。

署名付き URL は、限定公開オブジェクトへのアクセスを一定期間委任する場合にも便利です。

署名付きポリシー ドキュメントは、バケットにアップロードできる内容を指定します。ポリシー ドキュメントでは、サイズ、コンテンツの種類などのアップロード特性を、署名付き URL よりも細かく制御できます。ウェブサイトのオーナーはポリシー ドキュメントを使用して、訪問者に Cloud Storage へのファイルのアップロードを許可できます。

Cloud Storage の暗号化では、暗号化メカニズムを制御できます。Cloud Storage は、データをディスクに書き込む前にサーバー側でデータを暗号化します。次のいずれかを使用して、サーバー側の暗号化を制御できます。

  • 顧客管理の暗号鍵(CMEK)。Cloud KMS を使用して暗号鍵を生成し、管理できます。この暗号鍵は、標準の Cloud Storage 暗号化を強化する追加暗号化として機能します。

  • 顧客指定の暗号鍵(CSEK)。独自の暗号鍵を作成して管理できます。これは、標準の Cloud Storage 暗号化に追加される暗号化レイヤです。

Cloud KMS の鍵は Google によって複製され使用されますが、CSEK のセキュリティと可用性はお客様の責任となります。慎重に判断することをおすすめします。クライアント側で暗号化を行い、暗号化されたデータを Cloud Storage に保存することもできます。この場合、サーバー側でも暗号化が行われます。

永続ディスクは自動的に暗号化されますが、独自の鍵を設定し、管理することもできます。これらの鍵は Cloud KMS または Cloud HSM に保存することも、オンプレミス デバイスから提供することもできます。顧客指定の暗号鍵は、インスタンス テンプレートにも Google インフラストラクチャにも保存されません。したがって、鍵を紛失した場合、復元はできません。

デフォルトでは、永続ディスクのスナップショットが永続ディスクのロケーションに最も近いマルチリージョンに保存されますが、リージョンのロケーションを選択することもできます。スナップショットを共有すると、新しいリージョンにプロジェクト内の新しいマシンを簡単に復元できます。他のプロジェクトと共有する場合は、カスタム イメージを作成する必要があります。

コスト管理。キャッシュ制御メタデータを使用して、アクセス頻度の高いオブジェクトを分析し、Cloud CDN を使用して静的な公開コンテンツをキャッシュします。

設計に関する質問

暗号化

  • 暗号鍵の設定を使用するプロセスがあるか。
  • 鍵のライフサイクルをどのように管理しているか。
  • 暗号鍵へのアクセスをどのように制御しているか。
  • 鍵へのアクセスをどのくらいの頻度で監査しているか。

ストレージ

  • ストレージの使用をどのように計画しているか。レイテンシ、IOP、可用性の中でどれが重要か。
  • 機密データをどのように保存し、アクセスを制御するのか。
  • データをどのくらいの頻度で監査し、データへのアクセスをどのように制御するのか。
  • データの引き出しを監視するシステムはあるか。アラートをどのように処理するのか。

推奨事項

暗号化

  • Google が管理する鍵を使用して、鍵管理のライフサイクルを簡素化します。
  • IAM を使用して、Cloud KMS にアクセスできるユーザーを制御します。
  • 暗号鍵へのアクセス制御を頻繁に監査し、不要なアクセスを取り消します。

アクセス制御とストレージ

  • オブジェクト レベルのアクセス制御を使用して、バケット全体のアクセス権を制限します。
  • 機密データのオブジェクト バージョニングを有効にし、データを既知の状態にすばやく復元します。
  • Cloud Storage 内のオブジェクトやバケットを削除できるユーザーを制限します。
  • IAM 権限を付与する場合は、最小権限の原則に従います。
  • 自分が知らないユーザーに setIamPolicy 権限を付与しないでください。
  • 匿名ユーザーへの権限の付与は慎重に行います。
  • Cloud Storage のさまざまなロールを理解し、カスタムロールと権限を使用してロールを管理します。
  • オブジェクトやバケットにアクセスできなくなるような権限の設定を避けます。
  • バケットの管理権限を委任します。
  • Cloud Storage バケットで Bucket Policy Only が有効になっていることを確認します。

主なサービス

Cloud Key Management Service を使用すると、何百万もの暗号鍵を保持できます。また、データを暗号化する粒度を決定できます。鍵を定期的に自動ローテーションされるように設定し、データの暗号化に新しいプライマリ バージョンを使用できます。また、1 つの鍵バージョンでアクセスできるデータの範囲を制限することもできます。アクティブな鍵バージョンはいくつでも保持できます。

リソース

データベース アクセス制御を使用する

Cloud SQL をデプロイする前に、セキュリティのベスト プラクティスに従って、安全なアクセス制御を行う必要があります。アクセス制御はインスタンス レイヤとデータベース レイヤで行われます。

インスタンスレベル アクセスにより、App Engine または外部で実行中のアプリケーションまたはクライアントから、あるいは Compute Engine など別の Google Cloud サービスから、Cloud SQL インスタンスへのアクセスが承認されます。

データベース アクセスは、MySQL アクセス権限システムを使用して、どの MySQL ユーザーがインスタンス内のデータへのアクセス権を持つかを制御します。

可能な限り、Cloud SQL Proxy を使用してアプリケーションとデータベース間の通信を管理します。Cloud SQL Proxy は Compute Engine と GKE のデプロイで使用できます。

Cloud Bigtable は、プロジェクト レベルとインスタンス レベルで IAM を使用して同様の制御を行います。

Cloud Spanner を使用すると、プロジェクト、インスタンス、データベースのレベルでユーザーとグループのアクセスを制御できます。いずれの場合も、必要最小限の権限で IAM を使用することをおすすめします。

設計に関する質問

  • データベースへのアクセスを許可するプロセスはあるか。また、監査はどのくらいの頻度で行っているか。
  • データベースをスキャンして機密データを特定しているか。
  • データベースのスナップショットやバックアップをどのくらいの頻度で行っているのか。
  • これらの暗号鍵をどのように管理し、保護しているのか。

推奨事項

  • データベースへのアクセスを制限します。
  • IAM 権限を付与する場合は、最小権限の原則に従います。
  • 自分が知らないユーザーに setIamPolicy 権限を付与しないでください。
  • 匿名ユーザーへの権限の付与は慎重に行います。
  • BigQuery データセットが匿名でないこと、また一般公開されていないことを確認します。

リソース

データ セキュリティを実装する

Cloud Data Loss Prevention(DLP)は、機密要素を分類、マスキング、トークン化、変換するツールを備えており、ビジネスや分析のために収集、保存、利用するデータをより適切に管理できます。たとえば、フォーマット保持暗号化やトークン化のような機能を使用すると、データの有用性を失わずに結合や分析を行う一方で、元の機密データを難読化できます。

Cloud DLP アーキテクチャには、オペレーションの規模を問わず簡単に利用できる機能がいくつか用意されています。検査と匿名化のテンプレートは、一度定義した構成をリクエスト全般で利用できるようにする機能です。Cloud DLP ジョブトリガーとアクションは、検査ジョブを定期的に開始してジョブが完了したときに Pub/Sub 通知を出す機能です。

準識別情報とは、部分的であっても特定の個人や非常に小規模なグループを特定する手がかりとなる可能性のあるデータ要素またはその組み合わせのことです。Cloud DLP では k-匿名性、l-多様性といった統計指標を測定することで、データ プライバシーの現状を把握し、それを保護する能力を高めることができます。

主なサービス

Cloud DLP を使用すると、機密データについて理解を深めながら適切に管理できます。機密データの要素(クレジット カード番号、氏名、社会保障番号、米国および一部諸国の身分証明書番号、電話番号、Google Cloud 認証情報など)を、高速かつスケーラブルに分類して秘匿化できます。Cloud DLP は 120 種以上の定義済み検出項目を使って、パターン、フォーマット、チェックサムを識別し、そのコンテキストも考慮しながらデータを分類します。マスキング、セキュア ハッシュ、トークン化、バケット化、フォーマット保持暗号化などの手法でデータを秘匿化することもできます。

サプライチェーンのセキュリティ コントロールを使用してアプリを構築する

自動化ツールがないと、デプロイ、更新、パッチ適用が複雑になり、一貫したセキュリティ要件を満たすことが難しくなります。CI/CD パイプラインを構築すると、これらの問題の多くが解決します。詳しくは、オペレーショナル エクセレンスをご覧ください。

自動化されたパイプラインを使用すると、手動によるエラーをなくすことができます。標準化された開発フィードバック ループが提供されるので、プロダクトの迅速な反復が可能になります。したがって、これらのパイプラインを保護することが重要になります。パイプラインが侵害された場合、スタック全体が影響を受ける可能性があります。デプロイでコードをプッシュする前に、必要最小限の権限と承認チェーンを使用して、これらのパイプラインへのアクセスを保護することをおすすめします。

Cloud Source Repositories サービスと Container Registry サービスにより、バージョン管理を行うことで、ワークロード全体でデプロイの識別、保護、パッチ適用を行い、一貫性を維持できます。

コンテナ セキュリティ

Container Analysis により、コンテナのデプロイ前に脆弱性をスキャンし、問題を修正できます。Container Analysis はスキャンされたイメージのメタデータを保存します。これにより、最新の脆弱性を特定し、パッチの適用や更新を行うことができます。

Binary Authorization により、1 つまたは複数の一意の証明書を使用して、コンテナに署名を行うことができます。このような証明書とポリシー定義を使用することで、ランタイムにコンテナの識別と制御を行い、承認済みのコンテナのみをデプロイできます。厳密なポリシーモデルを使用し、少なくとも 1 人の署名者がコンテナ デプロイの承認とサインオフを行うように設定することをおすすめします。

Web Security Scanner は、デプロイされたアプリケーションをランタイムにスキャンし、脆弱性を検出します。署名されたユーザーとしてアプリケーションを操作し、さまざまなページをスキャンして脆弱性をスキャンするように Web Security Scanner を構成できます。意図しない動作を避けるため、本番環境を反映したテスト環境でスキャンすることをおすすめします。

複数のチームや部門にまたがる複雑なデプロイの場合は、段階的に監査と検証を行う自動処理で変更をデプロイします。

設計に関する質問

  • 本番環境に新しい変更をデプロイしてモニタリングするための明確なプロセス(カナリアテスト、脆弱性スキャン、承認チェーンなど)があるか。
  • 新たな脆弱性の発生を防ぐため、アプリケーション コードで脆弱性スキャンを実行しているか。
  • このようなスキャンをテストして監視するためのサンドボックス環境があるか。
  • デプロイのシークレットをどのように管理するのか。
  • シークレットの監査とローテーションをどのように行っているのか。

推奨事項

  • 承認済みのベースイメージと必要最小限のコンポーネントを使用します。
  • CI/CD プロセスの一部としてイメージ スキャンと分析を行います。
  • 通知と問題を追跡し、パッチの適用を自動化します。
  • シークレット管理を使用します。
  • アプリケーションのデプロイ方法を定期的に監査します。

主なサービス

Container Registry では、Docker イメージの一元的な管理と、脆弱性分析を行えます。また、きめ細かなアクセス制御によって、どのユーザーが何にアクセスできるのかを決定できます。CI/CD 統合があらかじめ用意されており、完全に自動化された Docker パイプラインを設定して迅速なフィードバックを得ることができます。Container Registry は、Google Cloud 上で実行される非公開のコンテナ イメージ レジストリです。Docker イメージ マニフェスト V2 と OCI イメージをサポートしています。

Container Analysis は、Container Registry に格納されているコンテナ イメージの脆弱性情報などのメタデータを提供します。メタデータはメモとして保存されます。イメージに関連付けられたメモが検出されるたびにオカレンスが作成されます。

Binary Authorization は、クラウド内で実行されるアプリケーションにソフトウェア サプライ チェーン セキュリティを提供するサービスです。Binary Authorization は、Container Registry または他のコンテナ イメージ レジストリから GKE にデプロイするイメージに対して機能します。Binary Authorization を使用すると、アプリケーションを本番環境にデプロイする前に、ソフトウェアの品質と整合性を保護するための内部プロセスを正常かつ確実に完了できます。

Security Command Center は、App Engine、Compute Engine、Google Kubernetes Engine ウェブ アプリケーションの脆弱性を特定します。アプリケーションをクロールして、開始 URL の範囲内にあるすべてのリンクをたどり、できる限り多くのユーザー入力とイベント ハンドラを処理しようとします。このスキャナでは、クロスサイト スクリプティング(XSS)、フラッシュ インジェクション、混在コンテンツ(HTTPS 内の HTTP)、更新されていない / 安全ではないライブラリなど、4 つのよくある脆弱性を自動的に検出します。偽陽性率は低く、早い段階で脅威を特定できます。セキュリティ スキャンのセットアップ、実行、スケジュール設定、管理は簡単で、Google Cloud をお使いのお客様は追加料金なしでご利用いただけます。

リソース

インフラストラクチャを監査する

Cloud Logging は、Google Cloud サービスの監査ログを提供します。Cloud Audit Logs は、セキュリティ チームが Google Cloud で監査証跡を維持するのに役立ちます。Cloud Logging はすべての Google Cloud サービスに統合されているため、長期的なアーカイブとコンプライアンス要件の詳細を記録できます。データアクセス ログのロギングはコストがかかる可能性があるため、この機能を有効にする前に慎重に計画してください。

コンプライアンス要件を満たすため、リアルタイム ストリーミングで監査ログをエクスポートして保存できます。Cloud Storage、BigQuery、Pub/Sub にエクスポートできます。ログを BigQuery または Cloud Storage に移動すると、コストを削減し、長期的な保管を行うことができます。

アクセスの透明性ログには、お客様から電話で依頼されたサポート内容に対する対応、サポート リクエストに応じて実施された詳細なエンジニアリング調査、サービス停止からの復旧など、ビジネス上必要な目的で実施された調査に関するデータが記録されます。

設計に関する質問

  • 監査ログをどのくらい保管しておく必要があるのか。
  • どのような監査ログを保管しておく必要があるのか。
  • 監査ログをエクスポートする必要があるのか。
  • エクスポートされた監査ログをどのように使用するのか。

推奨事項

  • レポートに必要な監査ログを BigQuery にエクスポートします。
  • 保管しておくだけで、使用または処理する必要のない監査ログを Cloud Storage にエクスポートします。
  • 組織レベルのシンクを使用して、組織のすべてのログを収集します。
  • ロギング シンクフィルタを使用して、エクスポートする必要のないログを除外します。

主なサービス

リソース