このドキュメントでは、推奨される VPC Service Controls のデプロイ アーキテクチャについて説明します。このドキュメントは、Google Cloud で本番環境規模でのデプロイを実行、運用し、機密データ損失のリスクを軽減したいネットワーク管理者、セキュリティ アーキテクト、クラウド運用担当者を対象としています。
VPC Service Controls による保護はクラウド サービスの機能に影響するため、VPC Service Controls の有効化は事前に計画し、アーキテクチャの設計中に VPC Service Controls を検討することをおすすめします。VPC Service Controls の設計はできる限りシンプルにしておくことが重要です。複数のブリッジ、境界ネットワーク プロジェクト（DMZ 境界）や複雑なアクセスレベルを使用する境界設計は使用しないことをおすすめします。
共通の統一された境界を使用する
共通の統一された境界ともいわれる単一の大きな境界は、複数の分割された境界を使用する場合と比べて、データの引き出しの防止に最も有効な保護を提供します。
共通の統一された境界には、境界の作成と保守を担当するチームの管理オーバーヘッドを削減できるメリットもあります。境界内のサービスとネットワーク リソースは、必要な IAM およびネットワーク制御の権限を使用して自由に通信できるため、境界管理を行うチームは主にインターネットから境界内のリソースへの接続である North-South アクセスに関与します。
組織が複数の小規模な境界を使用する場合、境界管理を行うチームは組織外部からの North-South トラフィックに加えて、組織の境界間の East-West トラフィックの管理にリソースを割り当てる必要があります。組織の規模と境界の数によっては、このオーバーヘッドがかなり大きくなることがあります。VPC ネットワーク内のリソースで直接的なインターネット下り（外向き）トラフィックが発生しないようにするなど、追加のセキュリティ制御とベスト プラクティスによって境界を階層化することをおすすめします。
サービス境界は、IAM コントロールの置き換えや必要性の低減を意図したものではありません。アクセス制御を定義する場合は、最小権限の原則に従い、IAM のベスト プラクティスを適用することをおすすめします。
詳細については、サービス境界の作成をご覧ください。
1 つの組織に複数の境界を使用する
ユースケースによっては、1 つの組織に複数の境界が必要になる場合があります。たとえば、医療データを処理する組織では、信頼性の高い難読化されていないデータ用の境界と、下位の匿名化されたデータ用の別の境界を設定し、外部エンティティとのデータ共有を容易にしつつ、信頼性の高いデータを保護することをおすすめします。
組織で PCI DSS などの標準を遵守する必要がある場合は、規制対象データに別の境界を設置することをおすすめします。
データ共有が組織の主なユースケースである場合は、複数の境界を使用することを検討してください。匿名化された患者の健康データなど、下位の階層のデータを生成して共有する場合は、別の境界を使用すると外部エンティティとの共有が容易になります。詳細については、安全なデータ交換のリファレンス パターンをご覧ください。
また、Google Cloud 組織を使用してパートナーやお客様などの独立したサードパーティのテナントをホストする場合は、テナントごとに境界を定義することを検討してください。これらのテナント間でのデータ移行を検討する場合は、別の境界を実装することをおすすめします。
境界の設計
境界を作成するときに、保護されているサービスをすべて有効にすることをおすすめします。これにより、運用の複雑さが軽減され、データの漏洩を最小限に抑えることができます。API を保護しないと、データ漏洩のリスクが増える可能性があります。組織で 1 つの API を保護し、別の API を保護しないようにする場合は、確認と正当な理由が必要です。
すべての新しいプロジェクトは、以降のセクションで説明する確認と評価のプロセスを実行する必要があります。評価の条件に見合うすべてのプロジェクトを境界に含めます。
境界内のどの VPC からもプライベート VIP へのパスがないことを確認します。private.googleapis.com へのネットワーク ルートを許可すると、VPC Service Controls を内部のデータの引き出しから防ぐことができます。サポートされていないサービスへのアクセスを許可しなければならない場合は、サポートされていないサービスの使用を別のプロジェクトに分離するか、ワークロード全体を境界外に移動します。
プロジェクトの確認と評価
一般的な企業には多くのプロジェクトがあり、そこには、コントロール プレーン、データレイク、ビジネス ユニット、ライフサイクル ステージなどのワークロードと高レベルな構造があります。これらのプロジェクトとコンポーネントは、フォルダに整理するだけでなく、VPC Service Controls の境界の内側と外側のどちらが適格かを評価することもおすすめします。評価を行うには、以下の点を考慮してください。
VPC Service Controls でサポートされていないサービスとハード依存関係があるコンポーネントはあるか。
VPC Service Controls の適用があいまいなため、このタイプの依存関係は境界では機能しない可能性があります。サポートされていないサービスの要件を別のプロジェクトに分離するようにワークロードを変更するか、ワークロードを境界の外にすべて移行することをおすすめします。
機密データがなく、他のプロジェクトの機密データを使用しないコンポーネントがあるか。
前述の質問のいずれかに対する答えが「はい」である場合は、プロジェクトを境界に配置しないことをおすすめします。許可リストの設計で説明されているように、この問題は回避できます。ただし、境界の複雑さを最小限に抑えることをおすすめします。
次のステップ
- サービス境界の作成方法を学習する。
- ドライラン モードで境界の影響をテストする方法を学習する。
- サービス境界間の通信を有効にする上り（内向き）ルールと下り（外向き）ルールについて学習する。