このドキュメントでは、Google Cloud ランディング ゾーンを設計する際に考慮すべき重要なセキュリティ決定と推奨オプションについて説明します。これはランディング ゾーンに関するシリーズの一部であり、Google Cloud のランディング ゾーンを設計する際に必要な決定を理解したいセキュリティ スペシャリスト、CISO、アーキテクトを対象としています。
このドキュメントでは、セキュリティ チームやプラットフォーム チームなどの中央チームがこれらのランディング ゾーンのセキュリティ管理を実施していることを前提としています。このドキュメントで取り上げるのは、エンタープライズ規模の環境の設計であるため、ここで説明する戦略は小規模チームには適さない場合があります。
Google Cloud のランディング ゾーンを保護する際の決定事項
組織に最適なセキュリティ設計を選択するには、次の決定を行う必要があります。
アーキテクチャの図
このドキュメントで説明するアーキテクチャの例では、一般的なセキュリティ設計パターンを使用しています。具体的な制御は、組織の業界、ターゲット ワークロード、その他のコンプライアンス要件などの要因によって異なります。次の図は、このドキュメントの推奨事項に従ってランディング ゾーンに適用するセキュリティ管理のアーキテクチャを示しています。
上の図は、次のことを示しています。
- サービス アカウント キーの管理は、有効期間が長いサービス アカウント認証情報によるリスクを軽減します。
- VPC Service Controls は、境界の外部からのアクセスを制限する際に役立つ機密性の高いリソースの境界を定義します。
- Security Command Center は、安全でない構成や脅威の有無について環境をモニタリングします。
- 一元化されたログシンクが、すべてのプロジェクトから監査ログを収集します。
- Google のデフォルトの保存データの暗号化では、ディスクに保持されているすべてのデータが暗号化されます。
- Google のデフォルトの転送データの暗号化は、レイヤ 3 とレイヤ 4 のネットワーク パスに適用されます。
- アクセスの透明性により、Google が環境にアクセスする方法の可視化と制御が可能になります。
サービス アカウントの永続認証情報を制限する方法を決定する
サービス アカウントは、ワークロードに IAM ロールを付与し、ワークロードが Google Cloud APIs にアクセスできるようにするマシン ID です。サービス アカウント キーは永続的な認証情報であり、永続的な認証情報には高いリスクが伴います。デベロッパーが自由にサービス アカウント キーを作成できるようにすることはおすすめしません。
たとえば、デベロッパーがサービス アカウント キーを公開 Git リポジトリに誤って commit した場合、外部の攻撃者はそれらの認証情報を使用して認証を行うことができます。もう 1 つの例として、サービス アカウント キーが内部リポジトリに保存されている場合、キーを読み取ることができる悪意のある内部関係者が、認証情報を使用して独自の Google Cloud 権限をエスカレーションするおそれがあります。
これらの永続認証情報を管理する戦略を定義するには、有効な代替手段を提供し、永続認証情報の拡散を制限して、使用方法を管理する必要があります。サービス アカウント キーに代わる選択肢については、ユースケースに最適な認証方法を選択するをご覧ください。
以降のセクションでは、永続的な認証情報を制限するオプションについて説明します。ほとんどのユースケースに対して、オプション 1 をおすすめします。以降のセクションで説明する他のオプションは、オプション 1 が特定の組織に該当しない場合に考慮できる代替手段です。
オプション 1: 永続的なサービス アカウント キーの使用を制限する
公開されたキーは一般的な攻撃ベクトルであるため、サービス アカウント キーのダウンロードをユーザーに許可しないことをおすすめします。永続的なサービス アカウント キーの使用を制限することで、サービス アカウント キーを手動で管理するリスクとオーバーヘッドを減らすことができます。
このオプションを実装する場合は、次の点を考慮してください。
- デベロッパーが永続的な認証情報を作成およびダウンロードできないようにするには、組織のポリシーの制約
constraints/iam.disableServiceAccountKeyCreationを構成します。 - サービス アカウント キーよりも安全な代替手段についてチームに説明します。たとえば、Google Cloud 環境外のユーザーとアプリケーションがサービス アカウントを使用する必要がある場合は、サービス アカウント キーの代わりに、サービス アカウントの権限借用または Workload Identity 連携で認証できます。
- サービス アカウント キーをダウンロードする際に唯一の選択肢として、このポリシーの例外をリクエストするプロセスを設計できます。たとえば、サードパーティの SaaS プロダクトでは、Google Cloud 環境からログを読み取るためにサービス アカウント キーが必要になる場合があります。
有効期間が短いサービス アカウント用の API 認証情報を生成するツールがすでに存在する場合は、このオプションの使用を回避してください。
詳しくは以下をご覧ください。
- Google Cloud エンタープライズ基盤ブループリントの組織のポリシーの制約
- サービス アカウントを操作するためのベスト プラクティス
オプション 2: 追加のアクセス管理ツールを使用して有効期間が短い認証情報を生成する
永続的なサービス アカウント キーの使用を制限する代わりに、サービス アカウントの有効期間が短い認証情報を生成できます。有効期間が短い認証情報は、サービス アカウント キーなどの永続的な認証情報よりもリスクが低くなります。独自のツールを開発するか、Hashicorp Vault などのサードパーティ ソリューションを使用して、有効期間が短いアクセス認証情報を生成できます。
サードパーティ製ツールに投資してすでにアクセス制御のために有効期間が短い認証情報を生成している場合、または独自のソリューションを開発するのに十分な予算と容量がある場合は、このオプションを使用します。
有効期間が短い認証情報を付与する既存のツールを保有されていない場合や、独自のソリューションを構築するための容量が存在しない場合は、このオプションの使用を回避してください。
詳細については、有効期間が短いサービス アカウント認証情報の作成をご覧ください。
Google API を使用してデータの引き出しを抑制する方法を決定する
Google API には、すべてのお客様が使用できるパブリック エンドポイントがあります。Google Cloud 環境のすべての API リソースは、IAM アクセス制御の対象です。ただ、盗まれた認証情報を使用してデータにアクセスしたり、悪意のある内部関係者や侵害されたコードによって盗まれたり、誤って構成された IAM ポリシーによって公開されたりするリスクがあります。
VPC Service Controls は、このリスクに対処するためのソリューションです。ただし、VPC Service Controls を使用すると、アクセスモデルが複雑になるため、お客様固有の環境とユースケースに合わせて VPC Service Controls を設計する必要があります。
以降のセクションでは、Google API を使用してデータ漏洩を低減するオプションについて説明します。ほとんどのユースケースに対して、オプション 1 をおすすめします。以降のセクションで説明する他のオプションは、オプション 1 が特定のユースケースに該当しない場合に考慮できる代替手段です。
オプション 1: 環境全体で VPC Service Controls を広く構成する
サポートされているすべての API を制限する 1 つ以上の VPC Service Controls の境界内で環境を設計することをおすすめします。アクセスレベルや上り（内向き）ポリシーを使用して境界の例外を構成し、デベロッパーが必要に応じてコンソールにアクセスできるようにして、必要なサービスにアクセスできるようにします。
次の条件に該当する場合は、このオプションを使用します。
- 使用するサービスは VPC Service Controls をサポートし、ワークロードは無制限のインターネット アクセスを必要としない。
- Google Cloud にセンシティブ データを保存しており、漏洩すると多大な損失が発生する可能性がある。
- 境界の例外として構成できるデベロッパー アクセスの属性が一貫しているため、ユーザーは必要なデータにアクセスできる。
ワークロードが無制限のインターネット アクセスや、VPC Service Controls でサポートされていないサービスを必要とする場合は、このオプションの使用を回避してください。
詳しくは以下をご覧ください。
オプション 2: 環境のサブセットに対して VPC Service Controls を構成する
環境全体で VPC Service Controls を幅広く構成する代わりに、センシティブ データと内部専用ワークロードが含まれるプロジェクトのサブセットにのみ VPC Service Controls を構成できます。このオプションを使用すると、ほとんどのプロジェクトでより簡単な設計とオペレーションが可能になり、一方でセンシティブ データを含むプロジェクトではデータ保護が優先されます。
たとえば、センシティブ データを含む BigQuery データセットが限られた数のプロジェクトに含まれている場合に、この代替手段を検討できます。これらのプロジェクトのみにサービス境界を定義し、上り（内向き）ルールと下り（外向き）ルールを定義して、これらのデータセットを使用する必要があるアナリストを対象に範囲を絞った例外を設定できます。
別の例として、3 層アーキテクチャのアプリケーションで、一部のコンポーネントが境界外に存在する場合があります。ユーザー トラフィックからの上り（内向き）を可能にするプレゼンテーション階層は、境界外のプロジェクトである可能性があり、センシティブ データを含むアプリケーション階層とデータ階層はサービス境界内の別のプロジェクトである可能性があります。境界に対する上り（内向き）ルールと下り（外向き）ルールを定義して、階層が詳細なアクセス権を持つことで、境界を越えて階層が通信できるようにします。
次の条件に該当する場合は、このオプションを使用します。
- センシティブ データが含まれるのは、明確に定義された限られたプロジェクトのみである。他のプロジェクトにはリスクの低いデータが含まれている。
- 一部のワークロードは内部専用であるものの、パブリック インターネット アクセスが必要なワークロードや、VPC Service Controls でサポートされていないサービスに依存するワークロードも存在する。
- すべてのプロジェクトで VPC Service Controls を構成すると、過剰なオーバーヘッド発生するか、過度に多くの回避策が必要になる
多くのプロジェクトにセンシティブ データが含まれる可能性がある場合は、このオプションの使用を回避してください。
詳細については、VPC Service Controls を有効にするためのベスト プラクティスをご覧ください。
オプション 3: VPC Service Controls を構成しない
環境全体で VPC Service Controls を広範に構成する別の方法として、特に運用オーバーヘッドが VPC Service Controls の価値を上回る場合に、VPC Service Controls の使用を回避する選択を行うことができます。
たとえば、上り（内向き）ポリシーのベースとなる一貫したデベロッパー アクセス パターンが組織に存在しない場合があります。IT 運用が複数のサードパーティにアウトソーシングされている可能性があるため、デベロッパーはマネージド デバイスや一貫した IP アドレスからアクセスできません。このシナリオでは、デベロッパーが毎日のオペレーションを完了する必要がある境界への例外を許可する上り（内向き）ルールを定義できない可能性があります。
このオプションは以下の場合に使用します。
- VPC Service Controls をサポートしていないサービスを使用している。
- ワークロードはインターネットに接続しており、センシティブ データは含まれていない。
- マネージド デバイスや既知の IP 範囲など、デベロッパー アクセスに一貫した属性が存在しない。
Google Cloud 環境にセンシティブ データがある場合は、このオプションの使用を回避してください。
安全でない構成や脅威について継続的にモニタリングする方法を決定する
クラウド サービスを採用すると、オンプレミスのサービスを使用する場合にはない新たな課題や脅威が生じます。有効期間が長いサーバーをモニタリングする既存のツールは、自動スケーリングやエフェメラル サービスには適しておらず、サーバーレス リソースをまったくモニタリングしない場合もあります。したがって、採用できる可能性のあるすべてのクラウド サービスと連携するセキュリティ ツールを評価する必要があります。また、Google Cloud の CIS ベンチマークなどの安全なクラウド標準を継続的にモニタリングする必要があります。
以下のセクションで、継続的なモニタリングのオプションについて説明します。ほとんどのユースケースに対して、オプション 1 をおすすめします。以降のセクションで説明する他のオプションは、オプション 1 が特定のユースケースに該当しない場合に考慮できる代替手段です。
オプション 1: Security Command Center Premium を使用する
組織レベルで Security Command Center のプレミアム ティアを有効にすることをおすすめします。これにより、以下の事項を行ってセキュリティ体制を強化できます。
- セキュリティの状況とデータの攻撃範囲の評価
- アセット インベントリと検出の実施
- 構成ミス、脆弱性、脅威の特定
- リスクの軽減と修正の支援
ランディング ゾーンの構築の開始時に Security Command Center を有効にすると、組織のセキュリティ チームは、安全でない構成、脅威、修復オプションを準リアルタイムで可視化できるようになります。この可視性により、セキュリティ チームは、ランディング ゾーンが要件を満たしているか、デベロッパーがアプリケーションのデプロイを開始する準備ができているかを評価できます。
次の条件に該当する場合は、このオプションを使用します。
- インテグレーション作業を増やすことなく、すべての Google Cloud サービスと統合されるセキュリティ体制管理と脅威検出ツールが必要である。
- Google が自社のサービスを保護するために使用しているのと同じ脅威に関する分析情報、機械学習、その他の高度な方法を使用することを必要としている。
- 既存のセキュリティ オペレーション センター（SOC）は、大量のクラウドログから脅威に関する分析情報を生成するスキルや能力を保有していない。
既存のセキュリティ ツールがエフェメラルまたはサーバーレスのクラウド リソースに完全に対処し、安全でない構成をモニタリングして、クラウド環境で大規模に脅威を特定できる場合は、このオプションを使用することは回避してください。
オプション 2: 既存のセキュリティ ツールをクラウド セキュリティ体制の管理と脅威の検出に使用する
Security Command Center Premium ティアを使用する代わりに、他のクラウド セキュリティ体制管理ツールを検討するかもしれません。Security Command Center と同様の機能を持つさまざまなサードパーティ ツールがあるため、マルチクラウド環境に特化したクラウド ネイティブ ツールにすでに投資している可能性があります。
Security Command Center とサードパーティ製ツールを併用することもできます。たとえば、Security Command Center から別のツールへ検出通知を取り込む、または Security Command Center のダッシュボードにサードパーティのセキュリティ サービスを追加することができます。別の例として、SOC チームが脅威を分析できるように、既存の SIEM システムにログを保存することが必要な場合があります。大量のログを取り込み、SOC チームが未加工のログを分析して分析情報を取得することを期待するのではなく、Security Command Center が生成する検出結果通知のみを取り込むように既存の SIEM を構成する必要があります。
既存のセキュリティ ツールがエフェメラルまたはサーバーレスのクラウド リソースに完全に対処し、安全でない構成をモニタリングして、クラウド環境で大規模に脅威を特定できる場合にこのオプションを使用してください。
次の条件に該当する場合は、このオプションの使用を回避してください。
- 既存の SOC は、膨大なクラウドログから脅威に関する分析情報を生成するスキルや能力を保有していない。
- 複数のサードパーティ製ツールを複数の Google Cloud サービスと統合すると、価値よりも複雑性が増大する。
詳しくは以下をご覧ください。
必要なログを 1 か所に集約する方法を決定する
ほとんどの監査ログは、監査ログを生成した Google Cloud プロジェクトに格納されます。環境が拡大するにつれて、監査者が個々のプロジェクトのログをチェックできなくなることがあります。したがって、内部監査やセキュリティ運用のために、ログの一元化方法と集計方法を決定する必要があります。
以降のセクションでは、ログの集計のオプションについて説明します。ほとんどのユースケースに対して、オプション 1 をおすすめします。以降のセクションで説明する他のオプションは、オプション 1 が特定のユースケースに該当しない場合に考慮できる代替手段です。
オプション 1: 集約されたログシンクを使用して Google Cloud でログを保持する
セキュリティ チームが必要とする監査ログやその他のログに対して、組織全体で一元管理されるログシンクを構成することをおすすめします。ログ範囲の設定ツールを使用して、セキュリティ チームが必要とするログと、これらのログタイプを明示的に有効化する必要があるかどうかを確認できます。
たとえば、セキュリティ チームは、ユーザー作成のリソースすべての一元的な記録を必要とします。これにより、セキュリティ チームは不審な変更を監視して調査できます。セキュリティ チームは、機密性が高い特定のワークロードについて、データアクセスを変更不可の状態で記録することも必要としています。そのため、セキュリティ チームは、1 つのログシンクを構成して、管理アクティビティ監査ログを、すべてのプロジェクトから緊急の調査のために閲覧できる一元管理されたプロジェクトのログ分析バケットに集約します。次に、機密性の高いワークロードを含むプロジェクトから Cloud Storage バケットにデータアクセス監査ログの 2 つ目のログシンクを構成し、長期的な保持を行います。
次の条件に該当する場合は、このオプションを使用します。
- セキュリティ チームは、すべての監査ログやその他の特定のログタイプの一元化された記録を想定している。
- セキュリティ チームは、ログを生成したワークロードやチームの制御の対象範囲の外部で、アクセスが制限された環境にログを保存する必要がある。
次の条件に該当する場合は、このオプションの使用は避けてください。 - 組織に、ワークロード間の一貫した監査ログについての一元的な要件がない。 - 個々のプロジェクト オーナーが、独自の監査ログを管理する全責任を負っている。
詳しくは以下をご覧ください。
- エンタープライズ基盤ブループリントの検出制御
- Cloud Audit Logs のベスト プラクティス
- 集約シンクを構成する
- ログ範囲の設定ツール
- 保持ポリシーと保持ポリシーのロック
オプション 2: Google Cloud の外部にあるストレージに必要な監査ログをエクスポートする
ログを Google Cloud のみに保存する代わりに、監査ログを Google Cloud の外部にエクスポートすることを検討します。必要なログタイプを Google Cloud の集約ログシンクに一元化したら、そのシンクの内容を Google Cloud 以外のプラットフォームに取り込み、ログの保存と分析に使用します。
たとえば、サードパーティの SIEM を使用して、複数のクラウド プロバイダにまたがって監査ログを集約および分析できます。このツールには、サーバーレス クラウド リソースを操作するのに十分な機能があり、SOC チームは、この大量のログから分析情報を生成するスキルと能力を有しています。
このオプションは、Google Cloud でのネットワーク下り（外向き）コストと、他の環境でのストレージ コストと容量に応じて、非常に高コストになる可能性があります。使用可能なすべてのログをエクスポートする代わりに、外部環境で必要なログを選択することをおすすめします。
すべての環境とクラウド プロバイダのログを 1 つの一元管理された場所に保存する必要がある場合は、このオプションを使用します。
次の条件に該当する場合は、このオプションの使用を回避してください。
- 既存のシステムに、大量のクラウドログを追加して取り込む容量や予算がない。
- 既存のシステムでは、ログタイプと形式ごとのインテグレーション作業が必要である。
- ログをどのように使用するかという明確な目標なしにログを収集している。
詳しくは以下をご覧ください。
- エンタープライズ基盤ブループリントの検出制御
- Logging からのエクスポート シナリオ: コンプライアンス要件
保存データの暗号化に関するコンプライアンス要件を満たす方法を決定する
Google Cloud では、1 つ以上の暗号化メカニズムを使用して、保存されているすべてのコンテンツが自動的に暗号化されます。コンプライアンス要件によっては、暗号鍵を自分で管理しなければならない場合もあります。
以降のセクションでは、保存データの暗号化オプションについて説明します。ほとんどのユースケースに対して、オプション 1 をおすすめします。以降のセクションで説明する他のオプションは、オプション 1 が特定のユースケースに該当しない場合に考慮できる代替手段です。
オプション 1: デフォルトの保存データの暗号化を使用することを受け入れる
暗号鍵の管理に関する特定のコンプライアンス要件がない多くのユースケースでは、デフォルトの保存データの暗号化で十分です。
たとえば、オンライン ゲーム会社のセキュリティ チームは、すべての顧客データを保存時に暗号化する必要があります。鍵管理に関する規制要件はなく、保存時に Google のデフォルトの保存データ暗号化を確認することで、それがニーズに対して十分な制御になっていると満足しています。
次の条件に該当する場合は、このオプションを使用します。
- データの暗号化方法や暗号鍵の管理方法に関する特定の要件は存在しない。
- 独自の暗号鍵を管理するための費用と運用上のオーバーヘッドよりも、マネージド サービスを優先する。
独自の暗号鍵を管理するコンプライアンス要件がある場合は、このオプションを使用することは避けてください。
詳細については、Google Cloud での保存時の暗号化をご覧ください。
オプション 2: Cloud KMS を使用して暗号鍵を管理する
保存時の暗号化の他に、Google Cloud プロジェクト内の保存データの暗号化に使用する鍵をより詳細に制御する必要がある場合があります。Cloud Key Management Service（Cloud KMS）は、顧客管理の暗号鍵（CMEK）を使用してデータを保護する機能を提供します。たとえば、金融サービス業界では、センシティブ データの独自の暗号鍵の管理方法を外部監査者に報告する必要が生じることがあります。
管理の追加レイヤのために、CMEK を使用してハードウェア セキュリティ モジュール（HSM）または外部キー管理（EKM）を構成できます。顧客指定の暗号鍵（CSEK）はおすすめしません。Cloud External Key Manager（Cloud EKM）がより多くのサービスと高可用性をサポートしているため、これまで CSEK によって対処されていたシナリオは Cloud EKM によってより適切に対処されるようになりました。
このオプションを使用すると、セキュリティ チームが定める鍵管理をアプリケーション デベロッパーが行うことになります。セキュリティ チームは、CMEK 組織のポリシーで非準拠のリソースの作成をブロックすることで要件を適用できます。
このオプションは、次のうち 1 つ以上に該当する場合に使用します。
- 独自の鍵のライフサイクルを管理する必要がある。
- FIPS 140-2 レベル 3 認定 HSM で暗号鍵のマテリアルを生成する必要がある。
- Cloud EKM を使用して、Google Cloud の外部に暗号鍵マテリアルを保存する必要がある。
次の条件に該当する場合は、このオプションの使用を回避してください。
- データの暗号化方法や暗号鍵の管理方法に関する特別な要件は存在しない。
- 独自の暗号鍵を管理するための費用と運用上のオーバーヘッドよりも、マネージド サービスを優先する。
詳しくは以下をご覧ください。
- エンタープライズ基盤ブループリントの Cloud Key Management Service で暗号鍵を管理する
オプション 3: ストレージに保持する前にデータをアプリケーション レイヤでトークン化する
Google が提供するデフォルトの暗号化に加えて、独自のソリューションを作成して、データをトークン化してから Google Cloud に保存することもできます。
たとえば、データ サイエンティストは PII 情報を含むデータセットを分析する必要がありますが、データ サイエンティストは一部の機密フィールドの元データを読み取れないようにする必要があります。元データへのアクセスを制御するには、センシティブ データの保護で取り込みパイプラインを作成してセンシティブ データを取り込んでトークン化し、トークン化されたデータを BigQuery に保持します。
データのトークン化は、ランディング ゾーンで一元的に実行できるコントロールではありません。このオプションを使用すると、アプリケーション デベロッパーに独自の暗号化を構成する責任を負わせたり、アプリケーション ディベロッパーが使用する共有サービスとして暗号化パイプラインを開発するプラットフォーム チームに責任を負わせることができます。
このオプションは、特定のワークロードに未加工の状態での使用を回避する必要があるセンシティブ データが存在する場合に使用してください。
Cloud KMS を使用して暗号鍵を管理するで説明されているように、Cloud KMS が十分に要件を満たすことができる場合は、このオプションを使用することは回避してください。追加の暗号化パイプラインと復号パイプラインを介してデータを移動すると、アプリケーションの費用、レイテンシ、複雑性が増大します。
詳しくは以下をご覧ください。
転送データの暗号化に関するコンプライアンス要件を満たす方法を決定する
Google Cloud には、転送中のデータの信頼性、整合性、プライバシーを確保するためのセキュリティ対策がいくつかあります。セキュリティとコンプライアンスの要件によっては、アプリケーション レイヤの暗号化も構成できます。
以下のセクションでは、転送データの暗号化のオプションについて説明します。ほとんどのユースケースに対して、オプション 1 をおすすめします。次のセクションで説明するもう 1 つのオプションは、オプション 1 では特定のユースケースには不十分な場合に検討できる追加機能です。
オプション 1: デフォルトの転送データの暗号化で十分であるかどうかを評価する
多くのトラフィック パターンは、追加の構成を行うことなく Google のデフォルトの転送データの暗号化によるメリットが得られます。VPC ネットワークと接続された VPC ネットワーク内のすべての VM 間トラフィックは、レイヤ 3 またはレイヤ 4 で暗号化されます。インターネットから Google サービスへのトラフィックは、Google Front End（GFE）で終端します。GFE では次の処理も行われます。
- 着信 HTTP(S)、TCP のトラフィックと TLS プロキシ トラフィックを終端する
- DDoS 攻撃対策を実施する
- Google Cloud サービスへのトラフィックの転送とロード バランシングを行う
たとえば、Google API を使用して内部サーバーレス アプリケーションを設計している場合、サービスのネットワーク パスで、デフォルトの転送データの暗号化が自動的に使用されます。暗号化するトラフィックに対して、追加の転送データの暗号化制御を構成する必要はありません。
このオプションは、内部ワークロードが Google のデフォルトの転送データの暗号化で十分な場合に使用します。
次の条件に該当する場合は、このオプションの使用を回避してください。
- Cloud Interconnect を経由するすべてのトラフィックに暗号化が必要である。
- VPC ネットワークへのインターネット上り（内向き）トラフィックを許可する。
- すべての内部コンピューティング リソース間でレイヤ 7 の転送データの暗号化が必要である。
このような場合は、オプション 2: レイヤ 7 の転送データの暗号化を構成するようアプリケーションに要求するで説明されているように、追加の制御を構成する必要があります。詳しくは、Google Cloud での転送データの暗号化をご覧ください。
オプション 2: レイヤ 7 の転送データの暗号化を構成するようアプリケーションに要求する
デフォルトの転送データの暗号化に加えて、アプリケーション トラフィック用にレイヤ 7 の転送データの暗号化を構成できます。Google Cloud は、マネージド証明書、Anthos Service Mesh、Traffic Director など、アプリケーション レイヤの転送データの暗号化が必要なアプリケーションをサポートするマネージド サービスを提供しています。
たとえば、デベロッパーがインターネットからの上り（内向き）トラフィックを受け入れる新しいアプリケーションを構築しているとします。外部アプリケーション ロードバランサと Google マネージド SSL 証明書を使用して、単一の IP アドレスの背後でサービスを実行し、スケーリングします。
アプリケーション レイヤでの暗号化は、ランディング ゾーンで一元的に強制適用できるコントロールではありません。このオプションを使用すると、転送データの暗号化を構成する責任の一部がアプリケーション デベロッパーにシフトされます。
アプリケーションがコンポーネント間の HTTPS または SSL トラフィックを必要とする場合は、このオプションを使用します。
アプリケーションがオンプレミスのときは内部トラフィックの転送データの暗号化が必要なかったコンピューティング ワークロードをクラウドに移行する場合、このオプションの例外を制限付きで許可することを検討してください。大規模な移行では、移行前にレガシー アプリケーションのモダナイゼーションを行うと、プログラムに許容不可能な遅延が生じる可能性があります。
詳しくは以下をご覧ください。
クラウド サービス プロバイダによるアクセス管理に必要な追加の管理機能を決定する
クラウド導入では、クラウド サービス プロバイダ（CSP）によるアクセスの監査が必要になることがあります。Google Cloud では、クラウド プロバイダによるアクセスを検証できる複数の制御レイヤを提供しています。
次のセクションでは、CSP アクセスを管理するためのオプションについて説明します。ほとんどのユースケースに対して、オプション 1 をおすすめします。次のセクションで説明するもう 1 つのオプションは、オプション 1 では特定のユースケースには不十分な場合に検討できる追加機能です。
オプション 1: アクセスの透明性ログを有効にする
アクセスの透明性のログには、環境内で Google Cloud の担当者が行った操作（サポートケースのトラブルシューティングなど）が記録されます。
たとえば、デベロッパーが Cloud カスタマーケアにトラブルシューティングの問題を持ち、サポート エージェントに環境のトラブルシューティングを依頼します。アクセスの透明性ログが生成されます。ログには、サポート スタッフが行った操作（サポートケース番号など）が表示されます。
次の条件に該当する場合は、このオプションを使用します。
- サービス停止の復旧やサポート リクエストへの対応など、ビジネス上の正当な理由のためだけに、Google Cloud の担当者がコンテンツにアクセスしていることを確認する必要がある。
- センシティブ データへのアクセスを追跡するためのコンプライアンス要件があります。
オプション 2: アクセスの透明性ログとプロバイダのアクセス管理を有効にする
CSP が環境にアクセスする前に明示的な承認を付与するコンプライアンス要件がある場合は、オプション 1 に加えて、アクセスの透明性を他の制御で使用して、データへのアクセスを明示的に承認または拒否できます。
アクセス承認は、カスタマーケアと Google エンジニアリングがコンテンツにアクセスする必要がある場合に明示的な承認（メールまたは Webhook 経由）を必須とする手動ソリューションです。
Key Access Justifications は、Cloud EKM で構成された暗号鍵のリクエストに正当性フィールドを追加する、プログラムによるソリューションです。
次の条件に該当する場合は、このオプションを使用します。
- 一元管理を担うチームが Google 担当者によるコンテンツへのアクセスを直接管理できるようにする必要がある。
- アクセス承認では、各アクセス リクエストを承認または拒否する一元管理された機能が運用上のトレードオフよりも重要であるというリスクを受け入れることができる。これにより、サポートケースの解決が遅くなる可能性がある。
- Key Access Justifications について、所属する企業では暗号化戦略の一環としてすでに Cloud External Key Manager を使用しており、暗号化されたデータへのすべてのタイプのアクセス（Google 担当者によるデータへのアクセスに限らず）をプログラムで制御する必要がある。
次の条件に該当する場合は、このオプションの使用を回避してください。
- アクセス承認権限を持つ一元管理を担うチームが対応する必要がある場合に予想される運用の遅延は、高可用性とカスタマーケアからの迅速な対応を必要とするワークロードにとっては許容できないリスクである。
詳しくは以下をご覧ください。
Google Cloud ランディング ゾーンのセキュリティに関するベスト プラクティス
このドキュメントで紹介した意思決定に加えて、次のセキュリティに関するベスト プラクティスを検討してください。
- 環境内の ID をプロビジョニングします。詳細については、Google Cloud に ID をオンボーディングする方法を決定するをご覧ください。
- 組織のユースケースに合うネットワークを設計します。詳細については、Google Cloud ランディング ゾーンのネットワーク設計を決定するをご覧ください。
- エンタープライズ基盤ブループリントで定義されている組織のポリシーの制約を実装します。これらの制約により、不要な外部 IP アドレスの作成や、すべてのサービス アカウントへの編集者ロールの付与など、一般的なセキュリティ問題を回避できます。
- 組織のポリシーの制約の完全なリストを確認して、他の制御が要件に関連するかどうかを評価します。
次のステップ
- エンタープライズ基盤ブループリントを確認する。
- Google Cloud アーキテクチャ フレームワークでセキュリティに関するその他のベスト プラクティスを確認する。
- Google Cloud セキュリティ ベスト プラクティス センターで入手可能なブループリントと技術記事を読む。