このドキュメントでは、 Google Cloud プロジェクトへのユーザーのアクセス権を取り消すためのベスト プラクティス、シナリオ、手順について説明します。ビジネスごとにポリシーとワークロードが異なるため、このドキュメントを使用して、一貫した方法によって適切なタイミングでアクセス権を取り消すための独自のポリシーと手順を作成することをおすすめします。
従業員が会社を辞める、請負業者との契約が終了する、コラボレーターが他のプロジェクトに移るなどの際、いくつかの作業を行ってクラウド リソースへの不要なアクセス権を取り消す必要があります。
これらのプロセスの一部はオプションです。セキュリティ上のニーズ、使用中のプロダクト、アクセス権が取り消されるユーザーの信用に応じて、これらのステップのいずれを実行するかを決定する必要があります。
プロジェクトの設定に関するベスト プラクティス
設定時に慎重に選択することで、プロジェクトでユーザーのアクセス権を取り消す際の効率が向上します。
ユーザー アカウントを既存の ID プロバイダと連携する
ユーザー アカウントを既存の ID プロバイダと連携させる場合は、ユーザーの停止イベントと削除イベントを反映するようにしてください。反映により、ID プロバイダからユーザー アカウントを一時停止または削除すると、ユーザーは Google Cloud リソースにアクセスできなくなります。
詳細については、 Google Cloud と外部 ID プロバイダの連携に関するベスト プラクティスをご覧ください。
ID 関連のその他のベスト プラクティスについては、アカウントと組織の計画に関するベスト プラクティスをご覧ください。
Workforce Identity 連携については、Workforce Identity 連携をご覧ください。
Google グループを使用してプロジェクト リソースへのアクセスを管理することを検討する
Google グループを使用すると、チームのメンバーシップ、アクセス要件、その他の条件に基づいてユーザーを整理できます。Google グループを作成したら、グループ メンバーシップに基づいて Google Cloud プロジェクトとリソースへのアクセス権を割り当てることができます。ユーザーが別のチームや職務に移動したときに、そのユーザー アカウントを別のグループに移動するだけで、前のグループの許可ポリシーによって付与されたアクセス権が自動的に削除されます。
Google グループの使用は、すべての状況に適しているわけではありません。たとえば、ビジネスの組織構造のみに基づくグループを使用してアクセスを管理しないでください。グループの使用に関するベスト プラクティスについては、Google グループの使用に関するベスト プラクティスをご覧ください。
詳細については、 Google Cloud コンソールでのグループの管理と組織でグループを作成するをご覧ください。
OS Login を使用する
メタデータ ベースの SSH 認証鍵の代わりに OS Login を使用して、ユーザーの承認済み鍵を Google ID にリンクします。ユーザー アカウントを削除すると、承認済みの鍵と VM へのアクセス権は自動的に取り消されます。詳細については、OS Login を使用して、IAM ポリシーに対する継続的なアクセス評価を行うをご覧ください。
手順については、OS Login を設定するをご覧ください。
外部ユーザー アカウントからのアクセスを制限する
外部ユーザーのアカウントのライフサイクルは制御できないため、これらのユーザーにプロジェクトへのアクセス権を付与しないでください。外部ユーザーを制限するには、iam.allowedPolicyMemberDomains リスト制約を使用します。
手順については、ドメイン別の ID の制限をご覧ください。
データベースで認証プロキシを使用する
認証プロキシを使用すると、データベース認証情報のライフサイクルを Google ID のライフサイクルに接続できます。Cloud Identity または Google Workspace でユーザー アカウントを一時停止または削除すると、データベースへのアクセス権が自動的に取り消されます。
詳細については、Cloud SQL Auth プロキシ と AlloyDB for PostgreSQL Auth プロキシ をご覧ください。
認証情報のローテーションの準備をする
プロジェクト レベルの認証情報を中断することなくローテーションできるように、プロジェクトとリソースを設計します。これらの認証情報は、サービス アカウントキー、OAuth クライアント シークレット、データベース ルート パスワードなどのアプリケーション固有のシークレットなど、プロジェクト自体に関連するシークレットです。詳細については、不正使用されたGoogle Cloud 認証情報の処理をご覧ください。
API キーを制限する
API キーを作成して管理する際に、それらを使用できるウェブサイト、IP アドレス、アプリのセットを制限します。閲覧者や API キー管理者などのロールを持つユーザー アカウントは、プロジェクトの API キーを閲覧できます。そのため、請求アクセス権を取り消すには、制限なしのキーをすべてローテーションまたは削除する必要があります。詳細については、API キーを保護するをご覧ください。
アクセス権限をモニタリングする
アクセスを慎重に追跡することで、アクセスの不正使用を軽減できます。IAM ロール Recommender を使用してロールの使用状況を追跡し、最小権限の原則を適用できます。また、Security Command Center のクラウド インフラストラクチャ資格管理（CIEM）機能を使用すると、デプロイ内のどのリソースにどの ID がアクセスできるかを管理し、構成ミスによる潜在的な脆弱性を軽減できます。
Cloud Storage で均一なバケットレベルのアクセスを使用する
均一なバケットレベルのアクセスを使用すると、IAM のみを使用して Cloud Storage バケットの権限を管理できます。他のアクセス制御オプションとともに均一なバケットレベルのアクセスを使用して、バケット内のコンテンツにアクセスできるユーザーを絞り込みます。
その他のベスト プラクティス
このドキュメントで説明しているベスト プラクティスに加えて、次のベスト プラクティスを確認してください。
Google Cloud プロジェクトへのアクセス権を取り消すシナリオ
次の表に、プロジェクト設定のベスト プラクティスにあるベスト プラクティスを実装した場合のアクセス権の取り消し方法を示します。
| シナリオ | アクセス権を取り消すオプション |
|---|---|
| 従業員が退職した。 | ユーザーの自動プロビジョニングによって Cloud Identity または Google Workspace 間の連携を設定すると、アクセス権の取り消しを自動的に行うことができます。 ベスト プラクティスに従わず、外部ユーザー ID にリソースへのアクセス権を付与した場合は、プロジェクトとリソースから手動で ID を削除する必要があります。 |
| 従業員の職務が変更された。 | チームグループから従業員を削除します。 |
| 契約期間が終了した。 | ユーザーの自動プロビジョニングによって Cloud Identity または Google Workspace 間の連携を設定すると、アクセス権の取り消しを自動的に行うことができます。 ベスト プラクティスに従わず、外部ユーザー ID にリソースへのアクセス権を付与した場合は、プロジェクトとリソースから手動で ID を削除する必要があります。 |
| アカウントが不正使用された。 | 手順については、不正使用されたGoogle Cloud 認証情報を処理するをご覧ください。 |
アクセス権を取り消す
プロジェクトの設定段階でうまく選択することで、それ以降のプロセスにおいて、ユーザーのアクセス権を効率的な方法で取り消すことができます。
ユーザーがアクセスできるリソースを確認するには、Policy Analyzer を使用します。手順については、IAM ポリシーを分析するをご覧ください。
ID プロバイダからユーザー アカウントを削除する
ユーザーが組織を離れ、ユーザーの自動プロビジョニングによって Cloud Identity または Google Workspace を ID プロバイダと連携している場合は、アクセス権の取り消しを自動的に行うことができます。
Workforce Identity 連携ユーザーの削除については、Workforce Identity 連携ユーザーとそのデータを削除するをご覧ください。
アカウントを別のグループに移動する
ユーザーのロールを変更する場合は、現在の Google グループからユーザー アカウントを削除します。グループ メンバーシップを管理するために、Cloud Identity または Google Workspace を ID プロバイダと連携している場合、アクセスの取り消しを自動的に行うことができます。
詳しくは、グループの詳細を表示して編集するをご覧ください。
IAM 許可ポリシーからユーザー アカウントを削除する
プロジェクト レベルの許可ポリシーからユーザー アカウントを削除するには、次の操作を行います。
Google Cloud コンソールで、[IAM 権限] ページに移動します。
ユーザー アカウントを削除するプロジェクトを選択します。
メンバーリストから、削除するユーザー アカウントを含む行の横にあるチェックボックスをオンにして、[削除] をクリックします。
フォルダ、組織、個々のリソースなど、許可ポリシーを設定できる他の場所を確認するには、権限が削除されたことを確認するをご覧ください。
プロジェクト認証情報をローテーションする
サービス アカウント キーをローテーションする
サービス アカウント キーを使用してサービス アカウントの認証を行う場合は、キーのローテーションが必要です。さらに、そのユーザーに対して、ソースコード リポジトリやアプリケーション構成などの Google Cloudツール以外のサービス アカウント キーへのアクセスが許可されているかどうかも確認します。
Google Cloud コンソールで、[API 認証情報] ページに移動します。
変更するサービス アカウントの名前をクリックします。
[キー] タブで [鍵を追加] をクリックします。
[新しい鍵を作成] をクリックします。
作成する [キータイプ] を選択します。ほとんどの状況では、JSON が推奨されますが、キータイプに依存するコードとの下位互換性のために P12 も使用できます。
[作成] をクリックします。新しいキーを含むファイルがブラウザから自動的にダウンロードされます。このキーを必要とするアプリケーションにキーをデプロイします。
新しいキーが正常に動作することを確認したら、認証情報ページに戻り、そのサービス アカウントに関連付けられている古いキーを削除します。
OAuth クライアント ID のシークレットをローテーションする
OAuth クライアント ID のシークレットからは、プロジェクトに直接アクセスできません。ただし、攻撃者が OAuth クライアント ID のシークレットを知っていると、アプリケーションを偽装し、悪意のあるアプリケーションからユーザーの Google アカウントへのアクセスをリクエストできます。
アクセスが取り消された担当者がシークレットにアクセスしたことがある場合（ソースコード リポジトリ、アプリケーション構成、または IAM ロールなど）、OAuth クライアント ID のシークレットのローテーションが必要になることがあります。
Google Cloud コンソールで、[API 認証情報] ページに移動します。
変更する OAuth 2.0 クライアント ID の名前をクリックします。
[クライアント ID] ページで [シークレットをリセット] をクリックします。
確認ダイアログで [リセット] をクリックすると、古いシークレットをすぐに取り消して新しいシークレットを設定できます。アクティブ ユーザーは、次回のリクエスト時に再認証する必要があります。
新しいシークレットを必要とするすべてのアプリケーションに新しいシークレットをデプロイします。
API キーをローテーションする
API キーは、プロジェクトやユーザーのデータに対するアクセスを提供しませんが、Google による API リクエストの課金対象を管理します。閲覧者や API キー管理者などのロールを持つユーザー アカウントは、プロジェクトの API キーを表示できます。制限なしのキーがある場合は、いずれかのユーザーのプロジェクトへのアクセス権を取り消す際、キーを削除または再生成する必要があります。
Google Cloud コンソールで、[API 認証情報] ページに移動します。
制限する API キーの名前をクリックします。
[キーを再生成] をクリックします。
新しく作成されたキーがダイアログに表示されます。置き換えるキーを使用して、このキーを任意のアプリケーションにデプロイします。
アプリケーションが新しいキーで正常に動作することを確認したら、認証情報ページに戻り、古い制限なしのキーを削除します。
VM へのアクセス権を取り消す
アクセス権を取り消すユーザーにプロジェクト VM へのログイン アクセス権がない場合は、この手順をスキップできます。
そのユーザーがアクセス権を持つすべてのプロジェクト レベルの SSH 認証鍵を削除します。
そのユーザーが SSH アクセス権を持つ VM ごとに、すべてのインスタンスレベルのキーを削除します。
ログイン アクセス権を持つすべての VM からそのユーザー アカウントを削除します。
ユーザーが VM にバックドアからアクセスできるようにインストールした可能性のある疑わしいアプリケーションがないかどうか調べます。VM 上で実行されているコードのセキュリティが不明な場合は、再作成し、必要なアプリケーションをソースから再デプロイします。
VM ファイアウォールの設定が、計画された構成または予期された構成から変更されていないことを確認します。
カスタムベース イメージから新しい VM を作成する場合、新しい VM のセキュリティを損なうような変更がベースイメージに対して行われていないことを確認します。
データベースへのアクセス権を取り消す
プロジェクトで Cloud SQL または AlloyDB for PostgreSQL リソースを使用していない場合は、この手順をスキップできます。
Cloud SQL データベースへのアクセス権を取り消すには、次の操作を行います。
Google Cloud コンソールで、SQL のインスタンス ページに移動します。
アクセスを取り消すデータベースのインスタンス ID をクリックします。
左側のメニューで [接続] をクリックします。
[承認済みネットワーク] の IP アドレスのリストと [App Engine の承認] のアプリのリストが、想定どおりであることを確認します。アクセス権を取り消しているユーザーがここにリストされているネットワークまたはアプリケーションにアクセスできる場合は、それらのユーザーはこのデータベースにアクセスできます。
左側のメニューで [ユーザー] をクリックします。
ユーザーがアクセス権を持つすべてのユーザー アカウントのパスワードを削除または変更します。これらのユーザー アカウントに依存するアプリケーションは、必ず更新してください。
AlloyDB for PostgreSQL データベースへのアクセス権を取り消すには、クラスタから IAM ユーザーまたはサービス アカウントを削除するをご覧ください。
App Engine を再デプロイする
デフォルトでは、App Engine アプリは、関連するプロジェクトの編集者であるサービス アカウントにアクセスできます。App Engine のリクエスト ハンドラは、新しい VM の作成、Cloud Storage のデータの読み取りや変更などの操作を行うことができます。App Engine にコードをデプロイできるユーザーは、このサービス アカウントを使用してプロジェクトにバックドアを開くことができます。デプロイ済みのアプリのコードの整合性が気になる場合は、バージョン管理システムから既知の良好なイメージを使用して、モジュールを含むアプリを再デプロイできます。
権限が削除されたことを確認する
権限は、組織レベル、プロジェクト レベル、または Policy Analyzer を使用して確認できます。
特定のユーザーが組織レベルでアクセスできる可能性のあるリソースを見つけるには、Google Cloud CLI で search-all-iam-policies メソッドを使用します。たとえば、ユーザーがリソースにアクセスできるかどうかを判断するには、次のコマンドを実行します。
gcloud asset search-all-iam-policies --scope='organizations/ORGANIZATION_ID --query='policy:IDENTITY'
ここで
ORGANIZATION_IDは組織番号です。IDENTITYはメールアドレスなどのユーザーの ID です。
プロジェクトの権限を確認するには、プロジェクトに対するプリンシパルの権限をご覧ください。
Policy Analyzer を使用して権限を確認するには、プリンシパルがアクセスできるリソースを特定するをご覧ください。
次のステップ
Google Cloud CLI の不正使用された OAuth トークンを緩和するためのベスト プラクティスについて学習する。
拒否ポリシーを作成して、ユーザーがアクセスできなくなる権限を指定する。