アクセスレベルを設計する

このドキュメントでは、アクセスレベルの実装と、許可リストに基づいてサービス境界の適用を開始するための推奨事項について説明します。

ワークロードのドライラン実行を完了したら、許可リストに追加する必要のある IP アドレスと ID のリストを特定します。また、一部のワークロードにはデバイスベースの許可リストも必要です。保護された Google Cloud リソースに対する制御されたアクセス権限を付与するには、VPC Service Controls のアクセスレベルを使用できます。アクセスレベルを実装する一部の実用的な手法は、IP アドレス、ID、デバイスに基づいています。

詳細については、上り（内向き）ルールを使用したコンテキストアウェア アクセスをご覧ください。

送信元 IP に応じてアクセス権を付与する

IP ベースの許可リストのアクセスレベルに使用できるのは、パブリック IP CIDR 範囲のみです。この方法では、この IP 範囲から保護されたすべての API が許可されるため、これらの IP の背後にある環境は信頼できる環境で、制御されている必要があります。この許可リストの一般的な利用シナリオは、オンプレミス ネットワークから境界アクセスを許可することです。次の図は、IP ベースの許可リストが境界アクセスのブロックと許可を行う方法を示しています。

VPC Service Controls のネットワークとサービス境界により、信頼できないネットワークの有効な ID からのアクセスを阻止します。

上の図では、有効な 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 の信頼状態です。

    承認済みの ChromeOS オプションが有効化されたオペレーティング システム ポリシー。

  • デバイス アクセスに管理者の承認を必須にすると、Cloud Identity 管理者は、アクセス権を付与する前に各デバイスを承認できます。デフォルトでは、有効な組織ユーザーがログインしていると、デバイスは自動承認されます。ただし、自動承認オプションをオフにすることをおすすめします。

  • 企業所有のデバイスを必須にする場合、Chrome エージェントが OS からシリアル番号を取得する必要があります。通常、これは BIOS から取得されます。この番号は、Cloud Identity に入力した既存のシリアル番号と一致する必要があります。

    ChromeOS 以外のデバイスではシリアル番号が信頼されないため、管理者権限の昇格が行われると、シリアル番号の悪用が可能になります。この条件はティア 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

次のステップ