よくある質問

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、G Suite ドメインへのアクセス権を付与できます。

役割とポリシー

ロールとポリシーとの関係とは

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

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

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

基本の役割と定義済みの役割の違いは何ですか?

基本の役割とは、以前のオーナー、編集者、閲覧者の役割です。IAM には事前定義済みの役割が用意されており、基本の役割よりもきめ細かいアクセス権を設定できます。可能な限り、事前定義された役割を ID に付与することで、リソースにアクセスするのに必要な最小限のアクセス権のみを付与してください。

基本の役割はどのような場面で使用するのですか?

次のようなシナリオでは、基本ロールを使用します。

  • Google Cloud サービスで事前定義済みの役割を利用できない場合。使用可能なすべての事前定義済み役割のリストについては、事前定義済みの役割の表をご覧ください。

  • プロジェクトに関する幅広い権限を付与する必要がある場合。この状況は、開発環境またはテスト環境で権限を付与する場合によく生じます。

  • プロジェクトの権限の変更をメンバーに許可する必要がある場合は、メンバーにオーナーの役割を付与します。オーナーのみが、他のユーザーにプロジェクトのアクセス権を付与する権限を持っているからです。

  • メンバーがきめ細かい権限を必要としない小規模なチームで働いている場合。

独自の(カスタム)役割を定義できますか?

はい。カスタムロールの記事をご覧ください。

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

リソースに付与されている役割は、Cloud ConsolegetIamPolicy() メソッドまたは gcloud コマンドライン ツールで確認できます。詳細をご覧ください。

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

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

{
  "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 に割り当てます。

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

IAM ポリシーは、Google Cloud Consolegcloud ツール、IAM メソッドを使用して作成し、管理できます。詳細をご覧ください。

プロジェクトの IAM ポリシーを確認するにはどうすればよいですか?

Cloud Console、project.getIamPolicy() メソッド、または gcloud ツールを使用すると、プロジェクトの IAM ポリシーを確認できます。詳細をご覧ください。

組織レベルのポリシーを確認するにはどうすればよいですか?

組織レベルのポリシーは、Cloud Console、organization.getIamPolicy() メソッド、または gcloud ツールを使用して確認できます。組織レベルのポリシーを確認する方法については、組織のアクセス制御をご覧ください。

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

ポリシーは、Cloud Console、REST API、または gcloud ツールを使用して更新できます。詳細をご覧ください。

ポリシーに含めることができるメンバー数に上限はありますか?

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

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

testIamPermissions() メソッドを使用して、特定のリソースに対する呼び出し元の権限を確認できます。このメソッドは、リソース名と権限のセットをパラメータとして取り、呼び出し元が持つ権限のサブセットを返します。

IAM 役割の効果を検証できます。たとえば、アクセス権のない Cloud Console ページにはアクセスできません。たとえば、ログ閲覧者の役割だけが付与されているユーザーが App Engine ページにアクセスしようとすると、次のエラー メッセージが表示されます。

選択したリソースのオペレーションを実行する権限がありません。

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

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

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

この問題の詳細については、ポリシーでの ETag の使用をご覧ください。

ID

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

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

  • Google アカウント
  • サービス アカウント
  • Google グループ
  • G Suite または Cloud Identity ドメイン

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

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

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

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

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

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

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

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

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

通常、メンバーのアクセス権が付与または取り消されるまで 60 秒かかりません。ただし、状況によっては、これらの変更がシステム全体に完全に反映されるまで最大 7 分かかることがあります。

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

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

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

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

インスタンスへのアクセス権を持つユーザーを管理するには、Google グループを使用して ID をロールにバインドします。このバインディングは、インスタンスが開始されるプロジェクト レベルで適用されるポリシーの一部として表示されます。ユーザー(たとえば my-user@example.com などの Google アカウントで識別されるユーザー)が、ロールにバインドされているグループのメンバーでない場合、ポリシーが適用されるリソースにはアクセスできません。

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

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

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

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

サービス アカウント

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

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

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

Google Cloud が管理するキーは、毎日ローテーションされます。ユーザーが管理するキーをローテーションするには、IAM サービス アカウント API を使用し、サービス アカウント キーを自動的にローテーションします。キーをローテーションするには、新しいキーを作成し、新しいキーを使用するようにアプリケーションを切り替えてから、古いキーを削除します。serviceAccount.keys().create() メソッドと serviceAccount.keys().delete() メソッドを一緒に使用して、ローテーションを自動化します。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

監査

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

Cloud Audit Logs を使用して、IAM ポリシーに対する変更を定期的に監査できます。監査ログの種類に応じて保管期間が異なります。Data Access ログは 30 日間、Admin Activity ログSystem Event ログは 400 日間保持されます。

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

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

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

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

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

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

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

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

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

個々の監査ログエントリは、一定期間保持され、その後削除されます。Cloud Logging の割り当てポリシーでは、ログエントリが保持される期間について説明します。割り当てポリシーの制限を超えてログエントリを保持するには、Cloud Logging から Cloud Storage バケットまたは BigQuery にログをエクスポートします