Google Cloud での ID とアクセスのガバナンスのパターンと手法

Last reviewed 2024-07-11 UTC

Google Cloud で動作しているアプリケーションとワークロードの ID ガバナンスとアクセス管理の手法の開発にお客様の組織が活用できるような、さまざまな Google Cloud のプロダクトとサービスがあります。このドキュメントは、お客様のチームで作業し、これらのツールやコントロール、およびその使用方法について学びたいと考えている、セキュリティ管理者、オペレーション マネージャー、エンタープライズ アーキテクトを対象としています。

このドキュメントは、以下のものがあることを前提としています。

  • Google Cloud プロジェクト
  • Cloud Identity のグループとユーザーを管理するための管理者権限を持つユーザー アカウント。このドキュメントの例の手順を実行するには、このアクセス権が必要です。

  • Cloud Identity のグループとユーザーを管理するための管理者権限を持たないユーザー アカウント。このドキュメントの手順の例で設定するコントロールのテストを行うには、このアカウントが必要です。

    Google Cloud プロジェクトにアクセスできておらず、Cloud Identity の管理者権限がない場合は、Google Cloud プロジェクトの作成と Cloud Identity の設定をご覧ください。

未使用のアカウントと権限を検出する

未使用の（孤立した）ユーザー アカウントとサービス アカウントはセキュリティ リスクをもたらす可能性があるため、不要になったユーザー アカウントがあれば、削除することをおすすめします。次の方法で Google Cloud Policy Intelligence を使用すると、リスクを把握し、軽減できます。

  • 従業員の退職や異動などによって使用されなくなったアカウントや権限を企業の管理者が見つける際に役立ちます。
  • タスク完了後に放置されているサービス アカウントを特定する際に役立ちます。

IAM 推奨事項を表示して適用する

Identity and Access Management（IAM）Recommender は、ツールとサービスから構成される Policy Intelligence の一部です。ML を使用して、Google Cloud リソースへのアクセスが不要になったアカウントの特定に役立つ、スマート アクセス制御の推奨事項を作成します。その後、最適化案を確認して、適用するかどうかを決定できます。IAM Recommender は、組織のすべてのメンバー間の最小権限の原則を維持するのにも役立ちます。Recommender サービスは、推奨事項を提示するだけでなく、ML を使用して詳細な分析情報も提示します。この分析情報により、リソースで特徴的な使用パターンを確認できます。たとえば、プロジェクト内の権限の使用に関する追加情報を収集し、未使用の権限や不要になった権限を特定できます。また、未使用のサービス アカウントの特定もできます。

Google Cloud コンソールでは、エンタープライズ レベルの規模で IAM 推奨事項の表示と適用が可能です。次の例の手順では、BigQuery を使用して組織内のアクセス権限を確認してサイズを適正化します。BigQuery 統合を設定するには、IAM Recommender から生成された推奨事項の BigQuery データセットへのエクスポートを構成します。このデータに対するクエリは、Looker Studio や Looker などの可視化ツールを使用して確認できます。

実装

  1. Google Cloud コンソールの [プロジェクト セレクタ] ページで、Google Cloud プロジェクトを選択または作成します。

  2. 新しいプロジェクトでは、BigQuery が自動的に有効になります。既存のプロジェクトで BigQuery を有効にするには、BigQuery API を有効にします。

    API を有効にする

  3. IAM Recommender からデータを pull するように BigQuery Data Transfer Service を構成します。詳細については、BigQuery への最適化案のエクスポートをご覧ください。

  4. BigQuery ページに移動します。

    BigQuery に移動

  5. 次のクエリをコピーして、[エディタ] フィールドに貼り付けます。

    SELECT
   recommendation_details
FROM PROJECT_ID.DATASET.TABLE_NAME
WHERE recommender = "google.iam.policy.Recommender"
AND recommender_subtype = "REMOVE_ROLE"

    以下を置き換えます。

    • PROJECT_ID: この例の実行に使用する Google Cloud プロジェクト ID。
    • DATASET: BigQuery Data Transfer Service ジョブを設定したときに選択したデータセットの名前。
    • TABLE_NAME: BigQuery Data Transfer Service ジョブによって作成されたテーブルの名前。

    このクエリを実行して、IAM Recommender REMOVE_ROLE 最適化案の recommender_subtype サブタイプを特定します。

  6. [実行] をクリックします。クエリ結果を使用して、未使用のロールを特定し、適切な IAM ロール バインディングを行います。

    クエリの結果をスプレッドシートに保存できます。詳細については、クエリ結果をスプレッドシートに保存するをご覧ください。

ユーザーがリソースへのアクセスをリクエストできるようにする

企業の管理者は、ユーザーがリソースへのアクセス権をリクエストできるようにする必要があります。通常、これらのリクエストは承認プロセスに送られます。このプロセスでは、アクセス権が付与される前に、指定の承認者または承認者グループによってリクエストが承認される必要があります。Google グループを使用すると、複数のユーザーに対してアクセス ポリシーを適用できます。これにより、ポリシー管理のベスト プラクティスに従って、グループ メンバーに基づいてリソースへのアクセス権を付与できます。この方法により、グループ メンバーを変更することで参加、移動、脱退のイベントが発生するため、ポリシーが適切に維持されます。

個々のユーザーまたはサービス アカウントごとにアクセス制御を付与または変更する代わりに、Google グループを使用し、グループ全体に対してアクセス制御を付与または変更できます。IAM のポリシーを更新してユーザーを追加または削除するのではなく、Google グループに対して簡単にメンバーを追加または削除することもできます。

Google グループを使用してリソース アクセス権を設定する

Google グループは、Cloud Identity を使用して作成、管理します。Cloud Identity は、ユーザーとグループを管理する Identity as a Service（IDaaS）ソリューションです。Cloud Identity を構成すると、Google と他の ID プロバイダ（Active Directory、Azure Active Directory など）の間で ID を連携させることができます。さらに Google グループでは、ユーザーがグループへのメンバー登録をリクエストすることもできます。このリクエストは、グループ管理者に転送され、管理者がリクエストを承認または拒否します。詳細については、グループを作成し、グループ設定を選択するをご覧ください。

Google Cloud リソースへのアクセス権を付与するために Google グループを作成し管理する際は、必ず、選択した設定の影響を考慮してください。グループを管理できるユーザーの数は最小限に抑えることをおすすめしますが、複数のグループ管理者を設定して、常にグループにアクセスできるようにすることをおすすめします。また、グループ メンバーは、組織内のユーザーに制限することもおすすめします。

実装

この例の手順では、Google グループを作成して、閲覧者グループにサンプルの Google Cloud プロジェクトへのアクセス権を付与します。このグループに追加した（またはリクエストに応じてアクセス権を付与した）メンバーは、サンプルの Google Cloud プロジェクトを表示できます。

サンプルの Google グループを作成する

次の手順では、Cloud Identity が構成されていることを前提としています。詳細については、Cloud Identity の設定をご覧ください。グループの管理に必要な権限があることを確認してください。

  1. Google Cloud コンソールの [アプリケーション] ページに移動します。

    グループに移動

  2. [作成] をクリックします。

  3. グループの詳細を入力します。

    グループにメンバーを追加するには、[メンバーを追加] をクリックして、メンバーのメールアドレスを入力し、Google グループのロールを選択します。

    完了したら、[送信] をクリックするとグループが作成されます。

    グループ設定は Google グループ内でのみ管理できます。グループ設定を構成するには、[Google グループでこのグループを管理する] をクリックします。グループに参加できるユーザーを選択するには、[グループに参加できるユーザー] メニューで [組織のユーザーのみ] を選択します。

  4. [グループを作成] をクリックします。

グループに Google Cloud プロジェクトへのアクセス権を付与する

  1. Google Cloud コンソールの [プロジェクト セレクタ] ページで、Google Cloud プロジェクトを選択または作成します。

  2. Cloud Shell を開きます。

    Cloud Shell に移動

  3. 次のコマンドを実行して、グループ閲覧者にプロジェクトへのアクセス権を付与します。

    gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=group:GROUP_EMAIL --role=roles/viewer

    以下を置き換えます。

    • GROUP_EMAIL: 作成したグループのメールアドレス
    • PROJECT_ID: Google Cloud プロジェクトの ID

組織内のユーザーに対するユーザー アクセスのリクエスト処理をテストする

次の手順では、テスト用のユーザー アカウントを使用して、組織内のユーザーが Google グループへのアクセス権をリクエストする方法を示します。

  1. 管理者以外のユーザーとして、Google グループにログインします。サンプルの Google グループを作成するで作成したグループが [すべてのグループ] に表示されます。グループが表示されない場合は、検索を使用してグループを見つけてください。

  2. グループへのアクセス権をリクエストするには、[グループへの参加をリクエスト] をクリックします。

    アクセス権が付与されると、リクエストに使用した非管理者のユーザー アカウントには、そのグループが閲覧権限を持つ Google Cloud PROJECT_ID プロジェクトが表示されます。

Google Cloud リソースへの期限付きアクセス権を付与する

社内のユーザーに、Google Cloud リソースへの一時的なアクセス権が必要となることがあります。短期的なアクセス権は、デベロッパーが特定のタスクを実行するために Google Cloud リソースへの一時的なアクセスを必要とする場合に便利です。短期的なアクセス権には次のメリットもあります。

  • 管理オーバーヘッドの低減。
  • 最小権限かつタイムリーなアクセス権の原則に従う。

管理者がこの種のアクセス権を付与できることは、ユーザーが迅速かつ直接リソースにアクセスして対応する必要がある緊急時に役に立ちます。ところが、短期的なアクセス権を手動で追跡し、適切なタイミングで確実に削除することは困難です。IAM の条件付きアクセス ポリシーを使用すると、条件付きロール バインディングを使用して Google Cloud リソースへの一時的な（期限がある）アクセス権を設定できます。これにより、管理者の負担を減らせます。

条件付きロール バインディングとグループ メンバーシップの有効期限を使用する

Google Cloud リソースへのアクセスは、新規または既存の IAM ポリシーに条件付きロール バインディングを追加することによってさらに制御できます。条件付きロール バインディングを使用してユーザーやグループに一時的なアクセス権を付与する状況の例としては、次のようなことが挙げられます。

  • 指定期間後に期限切れとなるプロジェクトへのアクセス。
  • 毎月または四半期ごとに繰り返されるプロジェクトへのアクセス。
  • インスタンスの停止など、タスクを管理するための Compute Engine インスタンスへのアクセス。

Google グループを使用してユーザーに Google Cloud リソースへのアクセス権限を付与する場合、グループ メンバーシップの有効期限機能を使用することで、Cloud Identity Groups API でグループ メンバーシップの有効期限を設定できます。指定した時間が経過すると、ユーザーはグループから自動的に削除されます。

実装

条件付きロール バインディングを使用すると、特定の Compute Engine インスタンスを管理するための一時的なアクセス権をデベロッパーに付与できます。この例では、ロール バインディングの有効期限が 2021 年 12 月 31 日に設定されています。

  1. Cloud Shell で、環境変数を設定します。

    export INSTANCE=create example-instance-1
export ZONE=us-west1-b
export USER=USER_ID_TO_GIVE_TEMPORARY_ACCESS_TO

    USER_ID_TO_GIVE_TEMPORARY_ACCESS_TO は、一時的なアクセス権を付与する組織内のユーザーのユーザー名に置き換えます。

  2. Compute Engine インスタンスのサンプルを作成します。

    gcloud compute instances create $INSTANCE \
    --zone $ZONE \
    --machine-type g1-small

    次のステップで、組織内のユーザーにこのインスタンスに対する一時的なアクセス権を付与します。

  3. 選択したユーザーに一時的なアクセス権を付与します。

    gcloud compute instances add-iam-policy-binding $INSTANCE \
    --zone=$ZONE \
    --member="user:$USER" \
    --role='roles/compute.instanceAdmin.v1' \
    --condition='expression=request.time < timestamp("2022-01-01T00:00:00Z"),title=expires_end_of_2021,description=Expires at midnight on 2021-12-31'

  4. 作成した Compute Engine インスタンスを保持します。このインスタンスは、後述の特権アクセスの管理で使用します。

    または、次のコマンドを実行して example-instance-1 インスタンスを削除することもできます。

    gcloud compute instances delete $INSTANCE

ポリシーの変更、サービス アカウントの作成、監査用のサービス アカウントの割り当てなど、IAM ライフサイクル イベントを確認する必要がある場合は、Cloud Audit Logs が役立ちます。管理者は Cloud Audit Logs を使用して、フォレンジックや分析のために過去のデータを確認できます。監査ログを分析すると、アクセス パターンとアクセスの異常を把握できます。監査ログ分析は、次のシナリオでも重要になります。

  • データ漏えい時の権限とリソースへのアクセスの分析
  • IAM ポリシーの変更による本番環境の問題の分析（特に、どのユーザーまたはどのプロセスで変更したかを確認したい場合）

Cloud Audit Logs には、ユーザーが行った操作、アクティビティが発生した場所、日時に関する情報が保存されます。監査ログは次のように分類されます。

ID とアクセスに関連する管理ロギングには、次の監査ログを使用することをおすすめします。

  • 管理アクティビティ監査ログ
  • ポリシー拒否監査ログ

管理アクティビティ監査ログには、プロジェクト、Compute Engine インスタンス、サービス アカウントなどの Google Cloud リソースに加えた変更が保存されます。管理アクティビティ監査ログによって保存されるイベントの例は、次のとおりです。

  • サービス アカウントの作成。
  • IAM ポリシーの変更。
  • サービス アカウント キーのダウンロード。

ポリシー拒否監査ログは、ユーザーまたはサービス アカウントがセキュリティ ポリシー違反のために Google Cloud サービスへのアクセスを拒否されたときに記録されます。

ID ライフサイクル イベント用に Cloud Audit Logs を設定する

Cloud Logging API またはコマンドライン インターフェースを使用して、Google Cloud コンソールで監査ログを表示するか、そのログをクエリできます。

すべての監査ログには、保持期間があります。企業がデフォルトの保持期間を超えて監査ログを保存する必要がある場合は、ログシンクを作成して、ログを BigQuery や他の宛先のシンクにエクスポートする必要があります。BigQuery にログをエクスポートすると、データ列のサブセットと、時間や他の観点で選択したデータを表示し、集計分析を行えます。

実装

次の手順の例では、Google Cloud プロジェクト ログに対してクエリを実行し、次のいずれかのイベントが発生したかどうかをチェックする方法を示します。

  • IAM ポリシーが変更された。
  • 新しいサービス アカウントが作成された。
  • 新しいサービス アカウント キーが作成された。

IAM ポリシーの変更を表示する

  1. Google Cloud コンソールで、[ロギング] > [ログ エクスプローラ] ページに移動します。
  2. [ログ エクスプローラ] ページで、既存の Google Cloud プロジェクトを選択します。

  3. 次のクエリをクエリビルダーに貼り付けます。

    logName="projects/<PROJECT>/logs/cloudaudit.googleapis.com%2Factivity" AND
(resource.type="project" OR resource.type="service_account") AND
resource.labels.project_id="<PROJECT>" AND
(protoPayload.methodName="SetIamPolicy" OR
protoPayload.methodName="google.iam.admin.v1.CreateServiceAccount"
OR
protoPayload.methodName="google.iam.admin.v1.CreateServiceAccountKey")

    PROJECT は、実際の Google Cloud プロジェクト ID に置き換えます。

  4. [クエリを実行] をクリックします。

グループ メンバーの変更を表示する

Google グループ メンバーの変更は、アクティビティ ログで追跡されます。これらのログにアクセスする方法については、グループ メンバーシップ変更ログの表示をご覧ください。

アクセス証明

Policy Analyzer を使用すると、ユーザーが Google Cloud リソースへの適切なアクセス権を一定期間または定期的に持っているかを確認できます。この確認は、コンプライアンスと監査の目的で重要です。また、どのユーザーがどのリソース、あるいはどのくらいの容量にアクセスできるかを、セキュリティ担当者と監査担当者が確認するのにも役立ちます。Policy Analyzer は、組織内のリソース階層全体でどの Google Cloud リソースにアクセスできる ID またはプリンシパルか（ユーザー、サービス アカウント、グループ、ドメイン）を識別するのに役立ちます。また、アクセスの種類を識別するのにも役立ちます。Policy Analyzer では、次のような疑問に対する答えを得ることができます。

  • サービス アカウントにアクセスできるユーザーは誰か。
  • 個人を特定できる情報（PII）を含む BigQuery データセットのデータを読み取ることができるユーザーは誰か。

Policy Analyzer は、次の手段で使用できます。

Policy Analyzer を使用してユーザー アクセスをチェックする

次のクエリ例は、Policy Analyzer でユーザー アクセスに取得できるタイプの分析情報を示しています。

  • プリンシパル（ユーザー、サービス アカウント、グループ、ドメイン）のロールまたは権限、たとえば、元従業員による本番環境プロジェクトへのアクセス状況の確認。
  • ユーザーがアクセスできるリソース、たとえば、元従業員がアクセスできる本番環境プロジェクトのリソース。
  • リソースに特定のレベルのアクセス権があるプリンシパル、たとえば、プロジェクト内で特定のユーザーが削除できるバケット。

実装

次の手順の例では、Policy Analyzer を使用してユーザーの持っている権限を確認します。

  1. Cloud Shell で、プロジェクトの Cloud Asset API を有効にします。

    API を有効にする

  2. 次のコマンドを入力して、ユーザーがアクセスできるリソースを確認します。

    gcloud asset analyze-iam-policy --organization="YOUR_ORG_ID" \
    --identity="user:USERNAME_TO_CERTIFY"

    次の項目を置き換えます。

    • YOUR_ORG_ID: Google Cloud 組織 ID。
    • USERNAME_TO_CERTIFY: Google Cloud へのアクセス権を確認したいユーザーのユーザー名。

  3. BigQuery に IAM ポリシーデータを抽出します。詳細については、BigQuery へのポリシー分析の書き込みをご覧ください。

特権アクセスを管理する

組織の一部のユーザーでは、管理タスクを行うために、特定の Google Cloud リソースへの特権アクセス権が必要な場合があります。たとえば、特定の Google Cloud プロジェクトの管理、プロジェクトの請求と予算の設定、Compute Engine インスタンスの管理を行う必要がある場合があります。

ユーザーに特権的なリソースへの永続的なアクセス権を付与するのではなく、ユーザーにジャストインタイム特権アクセスをリクエストできます。ジャストインタイム特権アクセス管理を使用すると、次のことが可能になります。

  • 誤ってリソースを変更または削除してしまうリスクを軽減できます。たとえば、ユーザーが必要な場合にのみ特権アクセスを持つと、変更すべきでないリソースに意図せず影響を与えるようなスクリプトをユーザーが実行しないようにできます。
  • 権限が有効化された理由を示す監査証跡を作成します。
  • 監査とレビューを行って過去のアクティビティを分析できます。

他の方法としては、サービス アカウントに特権アクセスを付与し、ユーザーにサービス アカウントの権限借用を許可することもできます。

ユーザーに特権アクセスを付与する

Google Cloud における企業ユーザーの特権アクセスの管理の概要は次のとおりです。

  • 企業内のユーザーが、特権アクセスをリクエストできるようにします。
  • Cloud Audit Logs を確認して、特権アクセス リクエストとアクセス パターンを分析します。管理者はこれらのログを使用して、特権アクセス パターンを確認し、異常を検出できます。企業は、監査目的で必要に応じて適切に残すために、これらのログのエクスポートを検討することをおすすめします。
  • 特権アクセスが自動的に期限切れになるか、定期的に審査されるようにする。

リソースへの特権アクセス権を持つすべてのユーザーに対して、2 段階認証プロセス（多要素認証）を有効にします。Access Context Manager を使用して属性に基づくきめ細かいアクセス制御を作成することもできます。これにより、特権アクセスが使用される際のセキュリティが強化されます。たとえば、ユーザーがリソースに対する特権アクセスを使用する場合、ユーザーは企業ネットワーク上に存在する必要があるというアクセスレベルを設定できます。

実装

この例の手順では、管理者として Compute Engine インスタンスへの特権アクセスするための Google グループを作成します。Google Cloud に、Compute Engine インスタンスを管理するためのアクセス権を付与されたサービス アカウントを作成します。先のグループをこのサービス アカウントに関連付けると、グループのメンバーは特権グループのメンバーとなっている期間、サービス アカウントの権限を借用できます。

特権アクセス用の Google グループを作成する

  1. Google Cloud 管理者として、Google Cloud プロジェクトを選択するか、作成します。

    リソースの管理に移動

  2. プロジェクトに対する課金を有効にします。 課金を有効にする

  3. ユーザーがリソースへのアクセスをリクエストできるようにするの手順に沿って、新しい Google グループを作成します。

    グループに elevated-compute-access という名前を付けます。

Google Cloud サービス アカウントを作成する

  1. Cloud Shell で、特権アクセス用の Google グループを作成するで作成したプロジェクトの IAM Service Account Credentials API を有効にします。

    API を有効にする

  2. 以下の変数を設定します。

    export PROJECT_ID=$DEVSHELL_PROJECT_ID
export PRIV_SERVICE_ACCOUNT_NAME=elevated-compute-access
export DELEGATE_GROUP=GROUP_EMAIL_ADDRESS

    GROUP_EMAIL_ADDRESS を作成した Google グループのフルネームに置き換えます。

  3. サービス アカウントを作成します。

    gcloud IAMservice-accounts create $PRIV_SERVICE_ACCOUNT_NAME \
    --description="Elevated compute access" \
    --display-name="Elevated compute access"

  4. サービス アカウントにコンピューティング管理者ロールを付与します。

    gcloud projects add-iam-policy-binding $PROJECT_ID \
    --member="serviceAccount:$PRIV_SERVICE_ACCOUNT_NAME@$PROJECT_ID.iam.gserviceaccount.com" \
    --role="roles/compute.admin"

  5. 作成した Google グループに、プロジェクトへの Service Usage コンシューマ アクセスを付与します。

    gcloud projects add-iam-policy-binding $PROJECT_ID \
    --member="group:$DELEGATE_GROUP" \
    --role="roles/serviceusage.serviceUsageConsumer"

    この権限により、作成したサービス アカウントに Google グループのメンバーが成り代わることができます。

  6. 作成したサービス アカウントの権限を借用する権限を Google グループに付与します。

    gcloud IAMservice-accounts add-iam-policy-binding
$PRIV_SERVICE_ACCOUNT_NAME@$PROJECT_ID.iam.gserviceaccount.com --member="group
:$DELEGATE_GROUP" --role="roles/iam.serviceAccountTokenCreator"

  7. Google Cloud リソースに時間制限付きでアクセス権を付与するの手順でサンプルの Compute Engine インスタンスを作成して保持している場合は、この手順をスキップします。このインスタンスのサンプルを使用して、この例の手順を実施できます。

    または、次のコマンドを使用して、Compute Engine インスタンスのサンプルを作成します。

    gcloud compute instances create example-instance-1 \
    --zone us-west1-b \
    --machine-type g1-small

    この例のインスタンスを使用して、特権グループにメンバーシップが付与されているユーザーが、このインスタンスにアクセスできることを確認します。

監査ログを有効にする

企業の管理者は Cloud Audit Logs を有効にして、特権アクセスがログに記録され、確認と分析用に利用できるようにします。このセクションの手順では、監査ログを有効にする方法について説明します。

  1. プロジェクトの現在の IAM ポリシーを取得します。

    gcloud projects get-iam-policy $PROJECT_ID > /tmp/policy.yaml

  2. ポリシー ファイルを変更して、Compute Engine API に対するデータアクセス ログを有効にします。

    cat <<EOF >> /tmp/policy.yaml
auditConfigs:
- auditLogConfigs:
 - logType: ADMIN_READ
 - logType: DATA_READ
 - logType: DATA_WRITE
 service: compute.googleapis.com
EOF

  3. 新しいポリシーを設定します。

    gcloud projects set-iam-policy $PROJECT_ID /tmp/policy.yaml

管理者以外のユーザー アカウントでの成り代わりをテストする

管理者以外のユーザー アカウントを使用してグループへのメンバーシップを要求し、メンバーシップが付与されたら、サービスアカウントに成り代わることでセットアップをテストできます。

このセクションの手順では、企業ユーザーが Google Cloud リソースへの特権アクセスをリクエストする方法について説明します。この例の手順の Google Cloud リソースは、Google Cloud プロジェクトの Compute Engine インスタンスです。組織内のユーザーが、グループへのメンバーシップを付与された後、サービス アカウントの権限をどのように借用するかを実証するには、関連する Google グループにメンバーシップをリクエストします。

  1. 管理者以外のユーザー アカウントで Google グループにログインし、elevated-compute-access グループにメンバーシップをリクエストします。

  2. 同じアカウントで Google Cloud にログインします。管理者がリクエストを承認すると、グループにアクセスできるようになります。この例の手順では、グループのメンバーシップ リクエストが承認されることを前提としています。

  3. Cloud Shell で次のコマンドを実行して、デフォルト プロジェクトを設定します。

    gcloud config set project PROJECT_ID

    以前、特権アクセス用の Google グループを作成するセクションで作成したプロジェクト ID に PROJECT_ID を置き換えます。

  4. このプロジェクト内の Compute Engine インスタンスの一覧を取得します。

    gcloud compute instances list

    Google Cloud ユーザーには Compute Engine リソースにアクセスする権限がないことを示すエラー メッセージが表示されます。

  5. 次のコマンドを実行します。

    gcloud compute instances list
--impersonate-service-account=elevated-compute-access@$PROJECT_ID.iam.gserviceaccount.com

    このコマンドは、elevated-compute-access Google グループのメンバーシップが付与されたときのサービス アカウントに成り代わり、プロジェクト内の Compute Engine インスタンスを一覧表示します。

    管理者アカウントで作成した example-instance-1 Compute Engine インスタンスが表示されます。

監査ログをチェックする

Google Cloud 管理者は、生成された監査ログにアクセスして確認できます。

  1. 監査ログにアクセスする管理者権限を持つユーザー アカウントで Google Cloud コンソールにログインします。

  2. Cloud Logging で次のクエリを入力して、データアクセス ログを確認します。

    logName="projects/<PROJECT_ID>/logs/cloudaudit.googleapis.com%2Fdata_access"
AND
protoPayload.authenticationInfo.principalEmail="elevated-compute-access@PROJECT_ID.iam.gserviceaccount.com"

    PROJECT_ID をプロジェクト ID に置き換えてから、クエリを実行します。

    このクエリは、Compute Engine インスタンスにアクセスするためにサービス アカウントに成り代わった Google グループのユーザーを示します。また、サービス アカウントに対する成り代わりや、リクエスト ヘッダーの詳細など、他の関連情報も表示されます。

  3. 監査ログのペイロード（具体的には、ペイロード内の protoPayload.authenticationInfo オブジェクト）を確認します。サービス アカウントの権限を借用したユーザーのユーザー名は、firstPartyPrincipal オブジェクトの principalEmail キーの値として記録されます。

  4. 管理者は、Security Command Center のダッシュボードで、イベント脅威に関する検出結果を確認することもできます。Security Command Center の詳細については、Event Threat Detection の使用をご覧ください。

次のステップ