このドキュメントでは、Google Cloud プロジェクトへのユーザーのアクセス権を取り消すためのベスト プラクティス、シナリオ、手順について説明します。このドキュメントを使用して、一貫した方法によって適切なタイミングでアクセス権を取り消すためのポリシーと手順を作成してください。
Google Cloud Platform リソースにとって重要なタイミングは、ユーザーのアクセス権を削除する必要がある場合です。従業員が会社を辞めたり、請負業者との契約が終了したり、共同作業者が他のプロジェクトに移ったりする場合、いくつかの作業を行ってリソースへの不要なアクセス権を完全に取り消す必要があります。
これらのプロセスの一部はオプションです。セキュリティ上のニーズ、使用中のプロダクト、アクセス権が取り消されるユーザーの信用に応じて、これらのステップのいずれを実行するかを決定する必要があります。
プロジェクトの設定に関するベスト プラクティス
設定時に慎重に選択することで、プロジェクトでユーザーのアクセス権を取り消す際の効率が向上します。
ユーザー アカウントを既存の ID プロバイダと連携する
ユーザー アカウントを既存の ID プロバイダと連携させると、ユーザー アカウントのステータスを同期できます。ID プロバイダからユーザー アカウントを削除すると、Cloud Identity のユーザー ID も削除されます。また、許可ポリシーにより、ユーザーは Google Cloud リソースにアクセスできなくなります。
詳細については、Google Cloud と外部 ID プロバイダの連携に関するベスト プラクティスをご覧ください。
ID 関連のその他のベスト プラクティスについては、アカウントと組織の計画に関するベスト プラクティスをご覧ください。
Google グループを使用してプロジェクト リソースへのアクセスを管理する
Google グループを使用すると、チームのメンバーシップやその他の条件に基づいてユーザーを整理できます。Google グループを作成したら、グループに基づいて Google Cloud プロジェクトとリソースへのアクセス権を割り当てることができます。ユーザーが別のチームに移動したときに、そのユーザー アカウントを別のグループに移動するだけで、前のグループの許可ポリシーによって付与されたアクセス権が自動的に削除されます。
詳細については、Google Cloud コンソールでのグループの管理と組織でグループを作成するをご覧ください。
OS Login を使用する
メタデータ ベースの SSH 認証鍵の代わりに、OS Login を使用してユーザーの Linux アカウントを Google ID にリンクできるようにします。ユーザー アカウントを削除すると、鍵は自動的に取り消されます。
手順については、OS Login を設定するをご覧ください。
外部ユーザー アカウントからのアクセスを制限する
外部ユーザーのアカウントのライフサイクルは制御できないため、これらのユーザーにプロジェクトへのアクセス権を付与しないでください。外部ユーザーを制限するには、iam.allowedPolicyMemberDomains リスト型制約を使用します。
手順については、ドメイン別の ID の制限をご覧ください。
Cloud SQL への接続時に Cloud SQL Auth Proxy を使用する
Cloud SQL Auth Proxy を使用すると、承認済みネットワークなどの IP ベースのアクセス制御ではなく、IAM 権限に基づいてワークロードを Cloud SQL に接続できます。Cloud SQL Auth Proxy は、ユーザーまたはサービス アカウントの認証情報を使用し、Cloud SQL インスタンスに対して承認された SSL / TLS レイヤに接続をラップすることで、接続を検証します。これは、セルフマネージド SSL / TLS 証明書または承認済みネットワークを使用するよりも安全な接続方法です。また、ユーザー アカウントの権限を取り消すときに Cloud SQL へのアクセス権を削除することも、ユーザー アカウントを完全に削除することもできます。
VM へのアクセスを制限する
Compute Engine や Google Kubernetes Engine で使用されるような仮想マシンは、攻撃にさらされる可能性が高くなります。いずれかのユーザーが VM へのアクセス権、特にルートアクセス権または管理者アクセス権を持っている場合、VM に変更を加えないように保証することは非常に難しく、以後アクセスできるようなバックドアが残ってしまいます。VM にアクセスできるユーザーを、明確かつ具体的な必要性のあるユーザーに限定してください。
デフォルトでは、プロジェクトの編集者と所有者は、プロジェクト内のすべての VM に対して管理者権限を持っています。このデフォルトのアクセス権を削除し、VM アクセスに最小権限の原則を使用します。
VM のログイン アクセス権を付与する前に、どのタスクにアクセス権が必要かを考え、可能であればそのニーズを満たす別の方法があるかどうか判断してください。たとえば、コードをデプロイするためにすべてのデベロッパーに VM ログイン アクセス権を付与する代わりに、デプロイを管理するために、Chef、Puppet、Salt などのツールの使用を検討します。
認証情報のローテーションの準備をする
プロジェクト レベルの認証情報を簡単かつ中断なくローテーションできるように、プロジェクトとリソースを設計します。これらの認証情報は、サービス アカウントキー、OAuth クライアント シークレット、データベース ルート パスワードなどのアプリケーション固有のシークレットなど、プロジェクト自体に関連するシークレットです。詳細については、不正使用された Google Cloud 認証情報の処理をご覧ください。
API キーを制限する
API キーを作成して管理する際に、それらを使用できるウェブサイト、IP アドレス、アプリのセットを制限します。閲覧者や API キー管理者などのロールを持つユーザー アカウントは、プロジェクトの API キーを閲覧できます。そのため、請求アクセス権を取り消すには、制限なしのキーをすべてローテーションまたは削除する必要があります。詳細については、API キーを保護するをご覧ください。
その他のベスト プラクティス
このドキュメントで説明しているベスト プラクティスに加えて、次のベスト プラクティスを確認してください。
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 プロバイダと連携している場合は、アクセス権の取り消しを自動的に行うことができます。
アカウントを別のグループに移動する
ユーザーのロールを変更する場合は、現在の Google グループからユーザー アカウントを削除します。グループ メンバーシップを管理するために、Cloud Identity または Google Workspace を ID プロバイダと連携している場合、アクセスの取り消しを自動的に行うことができます。
プロジェクト メンバーシップからユーザー アカウントを削除する
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 データベースへのアクセス権を取り消す
プロジェクトで Cloud SQL リソースを使用していない場合は、この手順をスキップできます。
Google Cloud コンソールで、[SQL インスタンス] ページに移動します。
アクセスを取り消すデータベースのインスタンス ID をクリックします。
左側のメニューで [接続] をクリックします。
[承認済みネットワーク] の IP アドレスのリストと [App Engine の承認] のアプリのリストが、想定どおりであることを確認します。アクセス権を取り消しているユーザーがここにリストされているネットワークまたはアプリケーションにアクセスできる場合は、それらのユーザーはこのデータベースにアクセスできます。
左側のメニューで [ユーザー] をクリックします。
ユーザーがアクセス権を持つすべてのユーザー アカウントのパスワードを削除または変更します。これらのユーザー アカウントに依存するアプリケーションは、必ず更新してください。
App Engine を再デプロイする
デフォルトでは、App Engine アプリは、関連するプロジェクトの編集者であるサービス アカウントにアクセスできます。App Engine のリクエスト ハンドラは、新しい VM の作成、Cloud Storage のデータの読み取りや変更などの操作を行うことができます。App Engine にコードをデプロイできるユーザーは、このサービス アカウントを使用してプロジェクトにバックドアを開くことができます。デプロイ済みのアプリのコードの整合性が気になる場合は、バージョン管理システムから既知の良好なイメージを使用して、モジュールを含むアプリを再デプロイできます。
権限が削除されたことを確認する
Google Cloud CLI で、search-all-iam-policies メソッドを実行し、特定のユーザー アカウントがアクセスできる可能性のあるリソースを探します。たとえば、ユーザーがリソースにアクセスできるかどうかを判断するには、次のコマンドを実行します。
gcloud asset search-all-iam-policies --scope='organizations/ORGANIZATION_ID --query='policy:IDENTITY'
ここで
ORGANIZATION_IDは組織番号です。IDENTITYはメールアドレスなどのユーザーの ID です。