VPC Service Controls を有効にするためのベストプラクティス

このドキュメントでは、Google Cloud 組織で VPC Service Controls の保護を構成して適用する際の推奨プロセスについて説明します。

VPC Service Controls を不用意に有効にすると、既存のアプリケーションで問題が生じ、停止する可能性があります。有効化は慎重に計画し、時間をかけてデータの収集、テストの実施、違反ログの分析を行うことをおすすめします。VPC Service Controls オペレーションチームとアプリケーションチームの関係者がこのタスクを実行できる状態であることを確認してください。

VPC Service Controls にオンボーディングするワークロードまたはアプリケーションごとに、有効化プロセスを繰り返す必要があります。

コミュニケーションの調整

多くの場合、ネットワークセキュリティチームまたはクラウド支援チームが VPC Service Controls の有効化作業を主導します。部門の枠を超えたミーティングを実施し、アクションアイテムを文書化する専任の担当者を設けることをおすすめします。チームでは、以下の作業を共同で行います。

Google Cloud APIs のアクセスパターン
サービス境界違反の特定
境界へのアクセスの許可

従来のネットワークファイアウォールと同様に、正当なビジネスワークロードを効率的に機能させるために必要なフローを識別して、許可することを目的としています。

ドキュメントのアクセスパターンとユースケース

有効化プロセスを開始するには、すべての有効なアクセスパターンを特定し、文書化します。アクセスパターンは、境界内外にある要素の間で繰り返し可能なインタラクションのタイプです。一般的なアクセスパターンとしては、次のものがあります。

データのアクセスパターン: 境界外のサービスは境界内にあるデータを保存または取得します。
リソースのアクセスパターン:
- ユーザーは Google Cloud コンソールを使用して境界のプロジェクトにアクセスします。
- サードパーティのツールやサービスが境界内のリソースを管理し、アクセスできます。
- 境界内のサービスまたはリソースは Google API にアクセスします。
エンドポイントのアクセスパターン:
- ユーザーは、組織が管理するデバイスから境界内のリソースにアクセスします。
- オンプレミスリソースが境界内のリソースと通信を行います。

ワークロードのアクセスパターンを特定した後、ユースケースを特定し、前述のリストのいずれかのアクセスパターンに分類します。一般的なユースケースは次のとおりです。

クラウド管理者は、境界の一部であるプロジェクトを管理します。
境界外にある Terraform、Jenkins、Microsoft Azure DevOps などの自動化サービスは、境界内でのリソースのデプロイを管理します。
境界外にある Ansible、Chef、Puppet などの構成管理サービスは、境界内にあるリソースへのソフトウェアのデプロイと構成を管理します。
境界外にある Forseti や SIEM などのセキュリティモニタリングと適用サービスは、境界内のリソースのデータを使用し、セキュリティポリシーを適用します。

すべてのユースケースについて、次のことを文書化します。

アクセスパターン
ユースケースをトリガーできる行為者
ユースケースをトリガーする条件
ユースケースが有効なアクセスパターンで、許可するべきかどうか
ユースケースに関連するすべての前提条件

アクセスパターンのサンプルとユースケーストラッカーについては、VPC Service Controls オンボーディングテンプレート - ユースケース（PDF）をご覧ください。

インタビューを行う

ワークロードチームとのインタビューを実施し、前述のコミュニケーションテンプレートから収集したアクセスパターンとユースケースを話し合います。これらのインタビューで尋ねる例としては、次のような質問が考えられます。

ユースケースで、VPC Service Controls の有効化を最優先事項として検討しているか。最初の有効化では最優先のワークロードのみを検討し、ビジネスクリティカルなリソースを保護した後に、他の重要度の低いワークロードのオンボーディングを行うことをおすすめします。
すべてのユースケースを包括的に実行できるか。この処理により、すべての境界シナリオがトリガーされるため、境界の適用後にアプリケーションが正しく機能することを十分に分析、確認できます。
ユースケースの実行にはどれくらいの時間がかかるか。
このワークロードで VPC Service Controls の有効化と競合する可能性がある大幅な変更を計画しているか。VPC Service Controls を有効にする前に、ワークロードの機能が安定した状態である必要があります。

ドライランを準備する

ドライランモードは、アプリケーションを中断することなく違反を特定することで、VPC Service Controls 適用のテストの複雑さを軽減します。ドライランは、すべての違反をログに記録し、ブロックを行わない別の境界として構成できます。ドライラン境界にあるワークロードを実行し、違反ログを生成して分析できます。

ドライラン環境を準備するには、次の操作を行います。

境界の対象となるすべてのプロジェクトを特定し、これらのプロジェクトのユースケースとインタビュープロセスを完了します。
ドライランの境界を作成し、すべてのプロジェクトを追加します。
VPC Service Controls のサービス境界の [制限付きサービス] > [保護するサービス] で、サポートされているすべてのサービスを追加します。
すべてのログを BigQuery に送信する集約ロギングシンクを作成するか、一般的な BigQuery データセットにドライランのログを送信するプロジェクトごとのログシンクを作成します。これらのログメッセージのクエリを実行し、VPC Service Controls の違反の特定を行うには、SQL クエリを使用できます。

関連するすべての VPC Service Controls ログメッセージを含むログシンクを作成するには、次のフィルタを使用します。
```
logName="projects/$PROJECT/logs/cloudaudit.googleapis.com%2Fpolicy"
```
最大限のセキュリティを確保するため、サポートされていないサービスへのアクセスは拒否します。制限付きサービスのみが境界内で機能するように境界を構成します。これを行うには、アクセス可能なサービスリストを RESTRICTED-SERVICES に構成します。
許可されたパブリック IP、ID、信頼できるデバイス、プロジェクト、VPC ネットワークのリストがすでにある場合は、ドライラン境界の該当する上り（内向き）ルールまたはアクセスレベルに追加します。既知の正当なフローを許可すると、違反ログの数が減り、審査担当者は対処可能なイベントに集中できます。
プロジェクト内のどの VPC にも、インターネットまたはプライベート VIP への下り（外向き）パスがないことを確認します。
すべての VPC に restricted.googleapis.com を指す *.googleapis.com DNS があることを確認します。

ユースケースを実行する

合意した時点で、アプリケーションチームにドライラン境界でプロジェクトのワークロードを実行してもらいます。Google API を呼び出す可能性があるすべてのコードの対象範囲を網羅していることを確認してください。ドライランが完了すると、指定のレビューチームが違反ログの分析を行うことができます。

違反を分析する

ドライラン違反ログには、アプリケーションの違反でアクションが必須かどうか（境界の許可リストへの ID または IP アドレスの追加など）を判断するために必要なほとんどの情報が含まれています。違反データは BigQuery テーブル cloudaudit_googleapis_com_policy に保存されます。違反を分析する主な要素は次のとおりです。

保護されるサービスと呼び出される API メソッド。
リクエストをブロックしていた境界内のプロジェクト。
保護された API を呼び出す ID のメール。
発信者の IP アドレス。
違反のタイプ。

次の例は、すべての違反の詳細を返す BigQuery クエリです。

SELECT
receiveTimestamp, #time of violation
Resource.labels.service, #protected Google Cloud service being blocked
protopayload_auditlog.methodName, #method name being called
resource.labels.project_id as PROJECT, #protected project blocking the call
protopayload_auditlog.authenticationInfo.principalEmail, #caller identity
protopayload_auditlog.requestMetadata.callerIp, #caller IP
JSON_EXTRACT(protopayload_auditlog.metadataJson, '$.dryRun') as DRYRUN, #dry-run indicator
JSON_EXTRACT(protopayload_auditlog.metadataJson, '$.violationReason') as REASON, #reason for violation
protopayload_auditlog.metadataJson, #raw violation entry
FROM `BQ_DATASOURCE_NAME.cloudaudit_googleapis_com_policy_*`
where JSON_EXTRACT(protopayload_auditlog.metadataJson, '$.dryRun') = "true" #ensure these are dry-run logs

違反ログを確認する

違反ログを確認すると、次の条件に当てはまるかどうかを判断できます。

ID（メール）によって、保護された API が呼び出されるかを確認
境界外からの API 呼び出しを呼び出し元に許可するべきかを確認

前述の基準に基づいて、ID、デバイス、IP アドレス、CIDR 範囲、プロジェクト、またはネットワークに外部から境界へのアクセスを許可する必要があるかどうかを判断します。

一部のエントリに IP アドレス private が含まれる場合があります。これは、呼び出しが Google ネットワーク（Google 独自のサービスまたは境界外のプロジェクト内の VPC のどちらか）から行われたことを示しています。ログシンクライターなどの Google サービスの場合は、Google サービスアカウントを許可リストに追加する必要があります。

メールアドレスのないエントリは、IAM 権限がないために拒否された読み取り専用オペレーションの Cloud Audit Logs の削除が原因です。この場合、IP アドレスとリソース名を使用してアクセス試行の発生源を特定できます。このような種類のアクセス試行は、組織外のユーザーによる誤ったアクセスである可能性があります。たとえば、ユーザーが類似した名前のバケットを間違って入力した場合などです。

違反タイプが SERVICE_NOT_ALLOWED_FROM_VPC の場合、VPC Service Controls でサポートされているが、保護された API のリストに追加されていないサービスがワークロードで使用されている可能性があります。たとえば、IAM が原因でこのような違反が発生した場合、管理者は次の Google Cloud CLI コマンドを実行して、アクセス可能なサービスのリストに IAM を追加する必要があります。

gcloud access-context-manager perimeters update perimeter_test \
 --add-vpc-allowed-services=RESTRICTED-SERVICES,IAM.googleapis.com \
 --policy=1234567890

Looker Studio ダッシュボードを作成して、違反を確認できます。詳細については、Looker Studio を使用して Google Cloud 組織の VPC Service Controls 違反をモニタリングするをご覧ください。以前のデータポータルが Looker Studio という名称になりました。

次のステップ

サービス境界の詳細を確認する。
サービス境界の作成方法を学習する。

VPC Service Controls を有効にするためのベスト プラクティス