よくある質問

コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

Identity and Access Management(IAM)の使用中に発生することのある一般的な問題について説明します。

IAM について

IAM とは

IAM を使用すると、Google Cloud リソースに関する権限を作成し、管理できます。これは、Google Cloud サービスに関するアクセス制御を 1 つのシステムに統合し、一貫性のあるオペレーションを提供します。コンセプトの概要については、IAM の概要をご覧ください。

なぜ IAM が必要なのでしょうか?

IAM を使用すると、セキュリティに関する最小権限の原則を導入できるため、リソースに対する必要なアクセス権のみを付与し、他のリソースへの望ましくないアクセスを防ぐことができます。IAM を使用すると、義務の分離に関するコンプライアンス条項を満たすことができます。

IAM をサポートする Google Cloud サービスはどれですか?

すべての Google Cloud サービスは、IAM を使用することで、承認された ID のみがサービスにアクセスできるようにします。さらに、サービスによっては、サービスに固有の IAM のロールを提供するものや、リソースレベルでアクセス権を付与するものがあります。IAM サポートの詳細については、概要をご覧ください。

IAM の使用を開始するにはどうすればよいですか?

IAM の使用を開始するには、IAM クイックスタートをお読みください。

IAM ポリシーを使用して、アプリケーションの認証と認可の両方を管理できますか?

IAM を使用して、Google Cloud リソースへの認可を管理できます。ユーザー認証を管理するには、LDAP や Google グループなど、管理に現在使用している方法を使用します。IAM を使用すると、Google アカウント、サービス アカウント、Google グループ、Cloud Identity ドメイン、Google Workspace ドメインへのアクセス権を付与できます。

ロールとポリシー

ロールと許可ポリシーの間にはどのような関係がありますか?

権限によって、リソースに対して許可されているオペレーションが決まります。Cloud IAM では、権限は「<サービス>.<リソース>.<動作>」の形式で表されます(例: compute.instances.get)。役割は権限のコレクションです。権限をユーザーに直接割り当てることはできないため、代わりに役割をユーザーに付与します。ロールをユーザーに付与する際には、そのロールに含まれているすべての権限がユーザーに付与されます。

IAM では、許可ポリシーを設定することで、誰(ユーザー)に、どのリソースに対する何(ロール)の権限を付与するかを制御できます。リソースに対する許可ポリシーとは、リソース上のプリンシパルに付与されるロールの全リストです。

権限、ロール、ポリシーの詳細については、IAM の概要をご覧ください。

基本ロールと事前定義ロールの違いは何ですか?

基本ロールとは、以前のオーナー、編集者、閲覧者のロールです。IAM には事前定義ロールが用意されており、基本ロールよりもきめ細かいアクセス権を設定できます。

基本ロールはどのような場面で使用するのですか?

基本ロールは開発環境とテスト環境で使用できます。一部のプリンシパルには、幅広い権限を割り当てたほうが良い場合があります。本番環境では基本ロールは使用しないでください。

独自のロール(カスタムロール)を定義できますか?

はい。カスタムの役割の記事をご覧ください。

リソースにどのロールが付与されているかを知るにはどうすればよいですか?

リソースに付与されているロールは、Google Cloud コンソールgetIamPolicy() メソッド、または Google Cloud CLI で確認できます。詳細

許可ポリシーの内容はどのようなものですか?

許可ポリシーは、バインディングのリストで構成されるポリシー オブジェクトとして表されます。バインディングはプリンシパルのリストをロールにバインドします。これは、次のコード例に示すように、コードで表すことができます。

{
  "bindings": [
   {
     "role": "roles/owner",
     "members": [
       "user:jiwoo@example.com",
       "group:admins@example.com",
       "domain:google.com",
       "serviceAccount:my-other-app@appspot.gserviceaccount.com"]
      },
      {
        "role": "roles/compute.networkViewer",
        "members": ["user:luis@example.com"]
      }
    ]
}

上記の許可ポリシーの例では、オーナーのロールを jiwoo@example.comadmins@example.comgoogle.commy-other-app@appspot.gserviceaccount.com に付与し、ネットワーク閲覧者のロールを luis@example.com に付与しています。

許可ポリシーを作成して管理するにはどうすればよいですか?

許可ポリシーは、Google Cloud コンソール、gcloud CLI、IAM メソッドを使用して作成し、管理できます。詳細

プロジェクトの許可ポリシーを参照するにはどうすればよいですか?

プロジェクトの許可ポリシーのロール バインディングを表示するには、Google Cloud コンソール、project.getIamPolicy() メソッド、または gcloud CLI を使用します。詳細

組織の許可ポリシーを参照するにはどうすればよいですか?

組織のポリシーのロール バインディングを表示するには、Google Cloud コンソール、organization.getIamPolicy() メソッド、または gcloud CLI を使用します。手順については、組織のアクセス制御をご覧ください。

許可ポリシーを更新するにはどうすればよいですか?

許可ポリシーは、Google Cloud コンソール、REST API、または gcloud CLI を使用して更新できます。詳細

許可ポリシーに含めることができるプリンシパル数に上限はありますか?

はい。許可ポリシーのプリンシパル数には上限があります。詳細については、IAM の割り当てと上限をご覧ください。

許可ポリシーのトラブルシューティングを行うにはどうすればよいですか?

Policy Troubleshooter を使用して、プリンシパルがリソースに対する特定の権限を持っているかどうかを確認できます。

または、Policy Analyzer を使用して、どのプリンシパルがどの Google Cloud リソースにアクセスできるかを詳しく把握できます。Policy Analyzer は、「どのユーザーがこの権限を持っているのか」や、「このユーザーはこのリソースに対してどのような権限を持っているのか」などの疑問を解消するときに役立ちます。

許可ポリシーを更新しようとすると「ポリシーの同時変更」に関するエラーが表示されるのはなぜですか?

許可ポリシーの同時変更で互いに上書きされないように、各許可ポリシーには etag フィールドが含まれています。このフィールドは、許可ポリシーを更新するたびに変更されます。更新された許可ポリシーを作成しようとしたときに、リクエストの etag が既存のポリシーと一致しない場合、次のエラー メッセージが表示されます。

同時ポリシーが変更されました。読み取り、変更、書き込みを指数バックオフで再試行してください。

この問題の詳細については、許可ポリシーでの ETag の使用をご覧ください。指数バックオフを含む再試行を実装する方法については、失敗したリクエストの再試行をご覧ください。

ID

どの ID に IAM のロールを付与できますか?

IAM を使用すると、次の種類の ID にアクセス権を付与できます。

  • Google アカウント
  • サービス アカウント
  • Google グループ
  • Google Workspace ドメイン
  • Cloud Identity ドメイン

IAM で Google グループを使用できますか?

通常は使用できます。唯一の例外はオーナーの役割です。グループにプロジェクトのオーナーの役割を割り当てられるのは、グループとプロジェクトが同じ組織に属している場合のみです。 組織のないプロジェクトでは、グループをオーナーにすることはできません。また、異なる組織のプロジェクトのオーナーとしてグループを割り当てることもできません。

可能であれば、個々のユーザーではなく、Google グループに対してロールを付与してください。ユーザーを追加または削除する場合、複数の許可ポリシーを変更するよりも Google グループにおいてそのユーザーを追加または削除するほうが簡単です。特定のタスクを実行できるようにするために複数のロールを付与する必要があるときは、Google グループを作成してそのグループにロールを付与し、そのグループにユーザーを追加してください。

1 つの許可ポリシーには、最大 250 個の Google グループを含めることができます。

IAM を使用してユーザーを作成および管理できますか?

いいえ。ユーザーの作成と管理には Cloud Identity または Google Workspace を使用します。また、LDAP や Google グループなどの現在の方法でユーザーを管理することもできます。LDAP を使用してユーザーを管理する場合は、Google Cloud Directory Sync を使用して Google ドメイン内のデータを同期する必要があります。ただし、ユーザーを管理するには、ユーザーがリソースにアクセスできるようにするために、許可ポリシーのロールにユーザーをバインドする必要があります(Google グループを使ってこれを行うことをおすすめします)。

IAM リソースにユーザーがアクセスできないようにするにはどうすればよいですか?

Google グループを介してユーザーに IAM ロールを付与した場合、そのユーザーをグループから削除できます。削除されたユーザーはグループに付与されたアクセス権を失います。グループを使用していない場合には、許可ポリシーを見直して個々のユーザーにアクセス権を付与した箇所を特定し、その箇所を許可ポリシーから削除する必要があります。個別のユーザーのアクセス権を取り消すためにすべての許可ポリシーを更新する必要がないため、Google グループを使用してアクセス権を付与するほうが簡単です。詳細

権限が付与された直後にユーザーがリソースにアクセスできなかったり、権限が削除された後も引き続きリソースにアクセスできたりするのはなぜですか?

通常、ポリシーの変更は 60 秒以内に有効になります。ただし、システム全体に変更が反映されるまでに 7 分以上かかることがあります。

自分の組織のメンバーではないユーザーに、プロジェクトのリソースへのアクセス権を付与するにはどうすればよいですか?

Google グループを使用して、組織外のユーザーをグループに追加し、そのグループをロールにバインドできます。Google グループにはログイン認証情報がないため、Google グループを使用して、リソースへのアクセス権のリクエストを行うための ID を確立することはできません。

ユーザーが組織に含まれていなくても、許可ポリシーに直接追加することもできます。ただし、会社の要件を満たしているかどうかは、管理者に確認してください。

インスタンスへのアクセス権を持つユーザーを管理するにはどうすればよいですか?

インスタンスへのアクセス権を持つユーザーを管理するには、Google グループを使用してプリンシパルにロールを付与します。ロールを付与すると、許可ポリシー内にロール バインディングが作成されます。インスタンスが起動するプロジェクトまたは個々のインスタンスにロールを付与できます。ユーザー(たとえば my-user@example.com などの Google アカウントで識別されるユーザー)が、ロールにバインドされているグループのメンバーでない場合、許可ポリシーが適用されるリソースにはアクセスできません。

IAM で多要素認証(MFA)を使用するにはどうすればよいですか?

個々のユーザーが MFA を使用する場合、それらのユーザーの認証方式が適用されます。つまり、ID システムで MFA をサポートする必要があります。Google Workspace アカウントの場合、ユーザー自身がこれを有効にする必要があります。Google Workspace が管理する認証情報では、Google Workspace ツールを使用して MFA を有効にできます。

サービス アカウントは IAM を使用するユーザーとどのように異なりますか?

サービス アカウントは、アプリケーションがプログラムにより Google サービスにアクセスするために使用できる特別な Google アカウントです。このアカウントは、個々のエンドユーザーではなくアプリケーションや仮想マシン(VM)に属しています。アプリケーションはサービス アカウントを使用して、ユーザーの関与を必要とせずに Google のサービス API を呼び出すことができます。

サービス アカウント

プロジェクトに含めることができるサービス アカウントの最大数はいくつですか?

デフォルトでは、プロジェクト内に最大 100 個のサービス アカウントを作成できます。追加のサービス アカウントをプロジェクトで作成する必要がある場合は、割り当ての増加をリクエストできます。

IAM を使用しているときにサービス アカウント キーをローテーションするにはどうすればよいですか?

Google Cloud が管理するキーは、毎日ローテーションされます。ユーザーが管理するキーをローテーションするには、IAM サービス アカウント API を使用し、サービス アカウント キーを自動的にローテーションします。キーをローテーションするには、新しいキーを作成し、新しいキーを使用するようにアプリケーションを切り替えます。その後、古いキーを無効にして、不要になった古いキーを削除します。

自分のプロジェクトでサービス アカウントを作成できるユーザーを制御するにはどうすればよいですか?

オーナーと編集者の役割には、プロジェクトにサービス アカウントを作成する権限が含まれています。ユーザーにサービス アカウントを作成する権限を付与する場合は、オーナーまたは編集者の役割を付与します。

組織の下にサービス アカウントを作成できますか?

現在、サービス アカウントは、プロジェクトの下にだけ作成できます。組織の下に直接サービス アカウントを作成することはできません。ただし、組織レベルで IAM 権限を付与すると、権限はその組織の下のプロジェクトに継承され、プロジェクトの下のサービス アカウントにも継承されます。

ネットワークとファイアウォールのルールを管理する専用のチームがあります。開発チームにインスタンスの管理を任せ、ネットワークやファイアウォールの変更はできないように、任務の分離を維持するにはどうすればよいですか?

まず、組織レベルまたはプロジェクト レベルで Compute ネットワーク管理者のロールをネットワーク管理者に付与します。次に、Compute インスタンス管理者の役割をデベロッパーに付与します。この責務の分離により、デベロッパーはインスタンスにアクションを実行できる一方で、プロジェクトに関連付けられたネットワーク リソースに変更を加えることができなくなります。

組織内のチームが互いのインスタンスにアクセスできないようにする必要があります。どのようにすればいいですか?

チームごとに 1 つずつ、2 つのプロジェクトを作成します。次に、プロジェクトごとに個別の許可ポリシーを作成し、どのチームがどのプロジェクトやプロジェクトに含まれるインスタンスにアクセスできるかを制御します。または、ロールの異なる複数のサービス アカウントを使用する方法もあります。

インスタンスの起動に使用するサービス アカウントを変更できますか?

はい。ただし、Compute Engine インスタンスを実行するためのサービス アカウントは変更できません。変更するにはインスタンスを一時的に停止する必要があります。インスタンスを停止してから新しいサービス アカウントを割り当て、インスタンスを再始動します。詳細については、Compute Engine のドキュメントをご覧ください。

サービス アカウント アクターの役割はどのようなシナリオで使用しますか?

サービス アカウント アクターの役割は廃止されました。サービス アカウントとしてオペレーションを実行する必要がある場合は、サービス アカウント ユーザーの役割を使用してください。

サービス アカウント ユーザーの役割はどのようなシナリオで使用しますか?

サービス アカウント ユーザーのロールは、サービス アカウントとして操作を実行する権限を与えます。compute.instanceAdmin 役割と一緒に iam.serviceAccountUser 役割を付与すると、ユーザーはサービス アカウントを使用する Compute Engine インスタンスの作成と管理を行うことができます。サービス アカウントの serviceAccountUsers であるユーザーは、サービス アカウントがアクセスできるすべてのリソースにアクセスできます。

監査

許可ポリシーを監査するにはどうすればよいですか?

Cloud Audit Logs を使用して、許可ポリシーの変更を定期的に監査できます。監査ログの保持期間の詳細については、ログの保持期間をご覧ください。

監査ログには何が記録されますか?

Admin Activity 監査ログは、あらゆる API 呼び出しと管理アクションを対象に、サービスやプロジェクトの構成とメタデータに影響するイベントをログエントリとして記録します。Data Access 監査ログは、以下のイベントに関係するログエントリを記録します。

  • API 呼び出しまたは管理アクションで、サービスまたはプロジェクトの構成やメタデータを読み込むもの。

  • API 呼び出しまたは管理アクションで、サービスが管理するユーザー提供データ(データベース サービスに格納されているデータなど)の作成、変更、読み取りを行うもの。

  • プロジェクト レベルの setIamPolicy() メソッドが記録されます。

  • サービス アカウントとサービス アカウント キーが記録されます。

監査ログへのアクセス権を持つユーザーを制御するにはどうすればよいですか?

Cloud Logging のロールを使用して、ログへのアクセスを制御できます。

監査ログを永続的に保存するにはどうすればよいですか?

個々の監査ログエントリは、一定期間保持され、その後削除されます。[ログの保持期間](/logging/quotas#logs_retention_periods)は、ログエントリの保持期間を制御します。割り当てポリシーの制限を超えてログエントリを保持するには、Cloud Logging から Cloud Storage バケットまたは BigQuery にログを転送します