よくある質問

Cloud Identity and Access Management の使用中に直面する可能性のある一般的な問題について学びます。

Google Cloud Identity and Access Management について

Google Cloud Identity and Access Management(Cloud IAM)とは

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

なぜ Cloud IAM が必要なのですか?

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

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

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

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

Cloud IAM を使用する前に、IAM クイックスタートをご覧ください。

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

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

役割とポリシー

役割とポリシーとの関係は何ですか?

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

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

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

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

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

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

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

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

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

  • メンバーがプロジェクトの権限を変更できるようにする必要があり、他のユーザーにプロジェクトに対するアクセス権を付与できる権限を持つのはオーナーだけであるため、そのメンバーにオーナーの役割を付与したい場合。

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

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

現在、IAM のカスタムの役割ベータ版リリースとして提供されています。

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

リソースに付与されている役割は、GCP ConsolegetIamPolicy() メソッド、gcloud コマンドライン ツールを使用して確認できます。手順については、プロジェクト メンバーへのアクセス権の付与、変更、取り消しをご覧ください。

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

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

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

上記のポリシーの例では、オーナーの役割を alice@example.comadmins@example.comgoogle.commy-other-app@appspot.gserviceaccount.com に割り当て、ネットワーク閲覧者の役割を bob@example.com に割り当てます。

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

IAM ポリシーは、Google Cloud Platform Consolegcloud ツール、IAM メソッドを使用して作成し、管理できます。これを行う方法については、プロジェクト メンバーへのアクセス権の付与、変更、取り消しをご覧ください。

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

プロジェクトの IAM ポリシーは、GCP Console、project.getIamPolicy() メソッド、gcloud ツールを使用して確認できます。手順については、プロジェクト メンバーへのアクセス権の付与、変更、取り消しをご覧ください。

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

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

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

ポリシーは、デベロッパー コンソール、API、gcloud ツールを使用して更新できます。手順については、プロジェクト メンバーへのアクセス権の付与、変更、取り消しをご覧ください。

ポリシーのサイズ制限はどれくらいですか?

各ポリシーには、そのすべてのバインディングで合計 1,500 までの members を含めることができます。

IAM ポリシーをいくつまで利用できますか?

自身のレベル(組織レベル、プロジェクト レベル、リソースレベルなど)で IAM ポリシーをサポートするすべてのリソースは、単一のポリシーを持つことができます。各ポリシーには、そのすべてのバインディングで合計 1,500 までのメンバーを含めることができます。

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

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

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

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

ID

どの ID に Cloud IAM の役割を付与できますか?

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

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

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

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

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

Cloud IAM を使用してユーザーを作成、管理できますか?

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

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

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

注: 変更が反映されるまでには最大で 80 秒かかることがあります。

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

役割の更新では、リクエストの送信後に反映されるまでに最大で 80 秒かかることがあります。

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

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

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

インスタンスにアクセスできるユーザーを制限するにはどうすればよいですか?

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

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

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

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

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

サービス アカウント

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

1 つのプロジェクトに 100 のサービス アカウントを作成できます。100 個を超えるサービス アカウントをプロジェクトで作成する必要がある場合は、アカウント マネージャーに連絡してください。

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

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

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

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

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

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

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

組織レベルかプロジェクト レベルで Compute ネットワーク管理者の役割をネットワーク管理者に付与し、Compute インスタンス管理者の役割をデベロッパーに付与すると、デベロッパーはインスタンスに対してあらゆる操作を行うことができますが、そのプロジェクトに関連付けられたネットワーク リソースに変更を加えることはできなくなります。

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

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

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

できません。実行中の Compute Engine インスタンスのサービス アカウントは変更できません。サービス アカウントをインスタンスに関連付ける操作は、作成時にのみ可能です。ただし、実行中のインスタンスに関連付けられているサービス アカウントに付与された権限を変更することはできます。変更すると、その権限がすぐに有効になります。

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

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

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

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

監査

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

Cloud 監査ログを使用して、IAM ポリシーに対する変更を定期的に監査できます。監査ログは 30 日間のみ保持されます。ログをさらに長く保管するには、ユーザーが明示的にログをエクスポートする必要があります。

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

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

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

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

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

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

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

Stackdriver Logging の役割を使用して、ログへのアクセスを制限できます。

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

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

このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...

Cloud Identity and Access Management のドキュメント