このドキュメントでは、アクセスレベルの実装と、許可リストに基づいてサービス境界の適用を開始するための推奨事項について説明します。
ワークロードのドライラン実行を完了したら、許可リストに追加する必要のある IP アドレスと ID のリストを特定します。また、一部のワークロードにはデバイスベースの許可リストも必要です。保護された Google Cloud リソースに対する制御されたアクセス権限を付与するには、VPC Service Controls のアクセスレベルを使用できます。アクセスレベルを実装する一部の実用的な手法は、IP アドレス、ID、デバイスに基づいています。
詳細については、上り（内向き）ルールを使用したコンテキストアウェア アクセスをご覧ください。
送信元 IP に応じてアクセス権を付与する
IP ベースの許可リストのアクセスレベルに使用できるのは、パブリック IP CIDR 範囲のみです。この方法では、この IP 範囲から保護されたすべての API が許可されるため、これらの IP の背後にある環境は信頼できる環境で、制御されている必要があります。この許可リストの一般的な利用シナリオは、オンプレミス ネットワークから境界アクセスを許可することです。次の図は、IP ベースの許可リストが境界アクセスのブロックと許可を行う方法を示しています。
上の図では、有効な ID が境界へのアクセスを試みます。IP アドレスから試行されたアクセスは拒否されます。ただし、企業のパブリック IP アドレスから派生したアクセスは許可されます。
このシナリオのバリエーションとして、別のプロジェクトまたは組織にデプロイされたプライベート リソースからの境界アクセスを許可する場合もあります。このユースケースでは、ソース プロジェクトに Cloud NAT ゲートウェイが必要です。Cloud NAT は 限定公開の Google アクセスと統合されており、リソースのサブネットで限定公開の Google アクセスが自動的に有効になり、Google API とサービスへのトラフィックが内部に保持されます。Cloud NAT ゲートウェイの外部 IP アドレスを使用してインターネットに転送されることはありません。トラフィックは Google 内部ネットワーク内でルーティングされるため、AuditLog オブジェクトの RequestMetadata.caller_ip フィールドは gce-internal-ip に編集されます。この場合、境界へのアクセスを許可するには、外部送信元 IP アドレスに基づいてアクセスレベルを構成するのではなく、プロジェクトやサービス アカウントなどの他の属性に基づいてアクセスを許可するように上り（内向き）ルールを構成する必要があります。
呼び出し元の ID に応じてアクセス権を付与する
ID ベースの許可リストを実装するには、サービス アカウントと組織の特権管理者を許可リストに追加します。境界は任意の IP アドレスの ID に対して開いているため、これらの ID が適切に保護されていることを確認する必要があります。また、許可リストに登録したサービス アカウントのキーの作成は避ける必要があります。ユーザー ID を境界の許可リストに追加することは一般的ではありません（グループは許可リストに追加できません）。
境界内のリソースには、境界内の VM、信頼できるオンプレミス ネットワーク、または信頼できるデバイスからアクセスできます。VPC Service Controls は Cloud Shell をサポートしていないため、Cloud Workstations を使用して境界内のリソースにアクセスすることをおすすめします。
呼び出し元のデバイス属性に応じてアクセス権の付与を判定する
デバイスの信頼性（信頼できるエンドポイントとも呼ばれます）は、有効な組織ユーザーが Chrome ブラウザまたは Chromebook にログインしていることに依存します。信頼性は OS ログイン セッションに適用されます。たとえば、Chrome セッションにログインして実行している Windows ユーザー（ブラウザを開いていなくてもかまいません）は、保護された境界の API で gcloud CLI コマンドを正常に呼び出すことができます。しかし、同じマシン上の別の Windows ユーザー セッションで、保護された境界の API のコマンドを呼び出すことはできません。
次のデバイス条件は、デバイスの信頼を確立する際に有効です。
承認済みの ChromeOS は、安全性の高い、暗号的に確認された状態であり、有効な組織ユーザーが安全に起動した Chromebook にログインしていることを示します。これは推奨されるティア 1 の信頼状態です。
デバイス アクセスに管理者の承認を必須にすると、Cloud Identity 管理者は、アクセス権を付与する前に各デバイスを承認できます。デフォルトでは、有効な組織ユーザーがログインしていると、デバイスは自動承認されます。ただし、自動承認オプションをオフにすることをおすすめします。
企業所有のデバイスを必須にする場合、Chrome エージェントが OS からシリアル番号を取得する必要があります。通常、これは BIOS から取得されます。この番号は、Cloud Identity に入力した既存のシリアル番号と一致する必要があります。
Chrome OS 以外のデバイスではシリアル番号が信頼されないため、昇格された管理者権限を持つユーザーにより、シリアル番号の悪用が可能になる場合があります。この条件はティア 2 の確認としてのみ使用することをおすすめします。
前述のリストで説明した条件に基づいて制御されたアクセス権限を付与するサンプル トラッカーについては、VPC Service Controls オンボーディング テンプレート - 許可リスト（PDF）をご覧ください。
適用を開始する
許可リストを設計してアクセスレベルを更新したら、ワークロードを再度実行して、違反がないことを確認することをおすすめします。ワークロードが違反なく実行されている場合は、アプリケーションに影響を与えずに VPC Service Controls の適用を開始できます。
適用を計画する際は、次のことを行ってください。
- 適用日を決めて、その日付をすべての関連チームに伝える。
- セキュリティ運用チームとインシデント対応チームがこのデプロイを認識していることを確認する。さらに、適切な権限を持つユーザーがログを調べて、必要に応じて追加の許可リストを承認するようにします。
- 質問や問題が発生した場合に対応チームが Google Cloud サポートケースを作成できるようにする。
- Terraform などの自動化ツールを使用して、境界とアクセスレベルを作成または変更する。これらのタスクを手動で実行することはおすすめしません。
適用を開始するには、まず、単一のワークロードに関連付けられたプロジェクトをドライラン境界からライブ境界に移動することから始めます。違反ログを監視しながら、アプリケーションが正しく実行されるまで待機します。残りのワークロードについて、このプロセスを 1 つずつ繰り返します。
ブロックされた違反を表示するには、境界内のすべてのプロジェクトの監査ログを 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') is null #exclude logs from a dry-run perimeter
次のステップ
- 境界の外部から保護されたリソースへのアクセスを許可する方法を学習する。
- サービス境界の一覧表示、更新、削除の方法を学習する。