これで分かった!Google CloudのIAMの仕組みやAWSとの違い

記事タイトルとURLをコピーする

G-genの杉村です。Google Cloud(旧称 GCP)の Identity and Access Management(略称 Cloud IAM)は、きちんと使いこなすことで強力なセキュリティ統制を効かせることができます。本投稿では、その内部構造まで解き明かしていきます。

Cloud IAM とは

Identity and Access Management(略称 IAM、もしくは Cloud IAM)とは Google Cloud リソースに対するアクセス制御を司る仕組みです。

IAM は、誰が、どのリソースに対して、どういう条件で、何をできるか、について管理します。

ここでいうリソースとは、例えば Compute Engine の VM や BigQuery のテーブルなど、Google Cloud に存在するオブジェクトの1つ1つを指しています。これらに対する操作権限を定義する仕組みが IAM です。

ID(アカウント)

Google Cloud におけるアカウント管理

IAM を理解するには Google Cloud における ID 管理(アカウント管理)を理解する必要があります。

Google Cloud の管理コンソールにログインしたり CLI ツールを実行するためのユーザーアカウントは、Google Cloud では Google アカウント と呼ばれます。

アカウントとしては、無償の Gmail アカウントを使うことも、Google Workspace(旧 GSuite)や Cloud Identity といった仕組みで集中管理することもできます。

AWS の IAM User との違い

Amazon Web Services(以下、AWS)をご存知の方のために、Google でのアカウント管理と、AWS の「IAM User」との違いをご紹介します。

AWS における ID は IAM User と呼ばれ、 AWS アカウント(テナント)の中で管理されています。つまり AWS では IAM User 自体もクラウドリソースです。一方の Google Cloud では、アカウントはクラウドリソースではなく、Google Cloud から分離され Google Workspace や Cloud Identity といった、別サービスで管理されます。

ですから、既に Google Workspace をお使いであれば、アカウントをそのまま Google Cloud の管理用アカウントとして活用できます。

Google Workspace をお使いでない場合は、Cloud Identity という仕組み(Free エディションでは 50 アカウントまで無償で利用可能)で組織を作り、ID を管理することができます。

ID 管理の違い

Google アカウントとグループ

Google アカウントは1個人に対して1個、発行されることが想定されています。共用アカウントの作成は「パスワードの漏洩」「有事の際に監査ログから実行者が追えない」「それによる内部犯に対する抑止力低下」などのリスクがあります。

Google Workspace でも Cloud Identity でも、アカウント名は john@example.com のようにメールアドレス形式です。

なお個人の Google アカウント(Gmail アカウント)も Google Cloud 用アカウントとして権限を持たせることが可能です。

また admin-grp@example.com のように グループ を作成して、アカウントをグループに所属させることができます。グループは、Google Workspace(Cloud Identity)の管理コンソールで作成するのが原則です。なおグループは Google Workspace においてはメーリングリストとして利用されます。

ただし企業で Google Cloud を利用する場合は個人アカウントではなく Google Workspace か Cloud Identity の利用が強く推奨 されます。個人向け Google アカウントだと、グループでの権限管理や、組織のポリシーなどの強力な管理機能が利用できないためです。

Google アカウントについての詳細は、以下の記事も参照してください。

blog.g-gen.co.jp

サービスアカウント

Google Cloud にはサービスアカウントという概念があります。

サービスアカウントは、Google アカウントとは異なり、人間ではなくプログラムが利用するアカウントです。プログラムから Google Cloud の各種サービスを操作する際は、サービスアカウントに権限を持たせて、サービスアカウントの認証情報で認証・認可させます。

また、サービスアカウントはGoogle アカウントとは異なり一つのクラウドリソースです。そのためサービスアカウントはいずれかの Google Cloud プロジェクト内に作成されます。

サービスアカウントの詳細については後述します。

IAM の仕組み

IAM とリソースの関係

Google Cloud の IAM で最も重要なのは IAM 権限はアカウント(主体)とリソースの間に紐づくものであるという点です。

リソースとIAMの関係

Google Cloud では、「誰が(Googleアカウント、グループ等。総称してメンバーと呼ばれる)」「何をできるか(IAM ロール)」という権限設定情報を、個々のリソースが持ちます。つまり、主語がリソースです。

なお、リソースとは Compute Engine VM や、BigQuery データセットなどを指します。Google Cloud プロジェクト自体もリソースですし、組織もリソースである点に注意が必要です。

後に詳しく記述しますが、AWS では、個々の主体が、「何に対して」「何をできるか」という権限設定情報を持ちます。つまり、主語は IAM ユーザーなどの主体です。ここが Google Cloud と AWS の大きな相違点です。

継承

上位のリソースに権限を紐づけると、下位のリソースに継承(inherit)されます。

例えば組織のトップノード(組織ツリーの最上位のこと。ルートとも言う)に対して、「メンバー : XXX@example.com」「IAM ロール : オーナー」という権限を紐づけたとします。このとき XXX@example.com さんはその組織の配下にある全てのリソース(フォルダ、プロジェクト、VM インスタンスや BigQuery データセット)にオーナー権限をふるうことができます。

一方であるプロジェクトに対して「メンバー : XXX@example.com」「IAM ロール : オーナー」という権限を紐づけると XXX@example.com さんはそのプロジェクト配下にある全てのリソース(VM インスタンスや BigQuery データセット)にオーナー権限を行使することができますが、他のプロジェクトに対しては権限が及びません。

継承

また、例えばある VM インスタンスにオーナー権限を付与しても、XXX@example.com さんは その VM にだけオーナー権限を行使できるのであって、他のリソースを操作したり閲覧することはできません。

これを理解できれば、何にどんな権限付与すると、どこまで効果が及ぶのかを理解できるでしょう。

許可と拒否

Google Cloud の IAM では、すべてのリソースは、デフォルトですべてのアカウントからの操作を拒否します(暗黙の Deny)。IAM Policy に対して binding を追加することで、メンバーに対して、アクション実行の許可を明示的に与えることができます(明示的な Allow)。

一方で拒否ポリシー(Deny policies)を IAM ポリシーとは別に作成することで、明示的な Deny を設定することが可能です。

ポリシーの評価順は「明示的な Deny > 明示的な Allow > 暗黙の Deny 」であり、明示的な Deny が最も強いです。

そのためポリシー設計時は、基本的には「明示的な Allow」を付与する/しないで管理することを基本とし、どうしても強い権限で拒否したいときだけ、明示的な Deny を使う、といった手法が良いでしょう。 拒否ポリシーは強力なため、安易に使うと後から修正が難しくなる場合があるためです。

拒否ポリシーの詳細については以下の記事で解説しています。

blog.g-gen.co.jp

IAM の内部構造(IAM Policy)

Cloud IAM の許可ポリシーの構造もご紹介します。

内部構造

全てのリソース(組織、フォルダ、プロジェクト、VM インスタンスや BigQuery データセット)は IAM Policy というポリシーを1つだけ持っています(AWS でいう IAM Policy とは全く別物のため、注意が必要です)。

IAM Policy は1つのリソースにつき、1つだけです。

IAM Policy は複数の binding を持つことができます。

binding の中には「誰が (Googleアカウント/グループ等。総称してメンバーと呼ばれる) 」「何を (IAM ロール)」「どういう条件で (condition)」実施できるのか、という情報が入っています。

あるリソースの IAM Policy を JSON フォーマットで確認すると、以下のようになります。

{
  "bindings": [
    {
      "members": [
        "user:jie@example.com"
      ],
      "role": "roles/resourcemanager.organizationAdmin"
    },
    {
      "members": [
        "user:divya@example.com",
        "user:jie@example.com"
      ],
      "role": "roles/resourcemanager.projectCreator",
      "condition": {
          "title": "Expires_July_1_2022",
          "description": "Expires on July 1, 2022",
          "expression":
            "request.time < timestamp('2022-07-01T00:00:00.000Z')"
      }
    }
  ],
  "etag": "********",
  "version": 1
}

このように、一つの IAM Policy の中に配列で複数の bindings が入っており、一つの binding の中にはどういう条件(condition)で誰が(メンバー)何をできる(IAM ロール)のかが記述されている、ということが分かります。

gcloud コマンドによる IAM Policy 操作

ここまで分かれば、コマンドラインツール gcloud で IAM 権限を付与するときは、以下のようにする理由が分かるでしょう。

プロジェクト全体に IAM 権限を付与するとき

gcloud projects add-iam-policy-binding my-project-id --member='user:test-user@gmail.com' --role=roles/resourcemanager.projectCreator`

VM インスタンスに IAM 権限を付与するとき

gcloud compute instances add-iam-policy-binding my-instance --zone=asia-northeast1-b --member='user:test-user@gmail.com' --role='roles/compute.securityAdmin'

各リソースの IAM Policy に対して add-iam-policy-binding をすることで、 binding を追加しているのです。

AWS IAM との比較と連携

概要

この章では、Google Cloud の IAM の仕組みをより正しく理解するため、AWS の IAM との違いに着目して解説します。また、AWS との IAM の連携方法についても紹介します。

AWS を特に利用したことがなく、これから利用する予定も無い方は読み飛ばして頂ければと思います。

ID(IAM User)

マネジメントコンソールにログインしたり、 CLI ツールを実行するための ID は、 AWS では IAM User と呼ばれ、 AWS アカウント(テナント)の中で管理されます。

Google Cloud の ID は Google Cloud とは分離され Google Workspace や Cloud Identity で管理されることとは対照的です。

概念の違い

AWS IAM では IAM Policy で権限セット(できること)を定義し、それを 権限主体 (IAM User や Group 。総称して Principal に紐づけます。

別の言葉で言うと、「どのリソースに対して」「何ができるか」という権限定義を人に紐づけるのです。

これは Google Cloud の IAM が、「誰が」「何をできるか」をリソースに紐づけるのとは考えが異なります。

AWS IAM と Google Cloud IAM の比較

用語の違い

IAM Policy、IAM Role といった用語は両クラウドで共通していますが、意味は大きく異なっています。混同しないように気を付けましょう。

意味 AWSでの用語 Google Cloud の用語
権限セット IAM Policy IAM Role
権限を実行する IAM 主体(人間) IAM User Google アカウント
権限を実行する IAM 主体(サービス) IAM Role サービスアカウント
IAM 主体をまとめるグループ IAM Group Google グループ
個々のリソースが持つ IAM 設定 対応概念なし IAM Policy

AWS IAM と Google Cloud IAM の連携

Google Cloud の IAM には Workforce Identity および Workload Identity という仕組みがあります。これらの仕組みを使うと、外部の ID プロバイダ(IdP)と OpenID Connect(OIDC)や SAML 2.0 を使って連携させることができます。

Google Cloud の側から AWS の IAM Role を信頼し、AWS の IAM Role に Google Cloud サービスアカウントの権限借用を許すことで、Google Cloud への API 実行を認可することができます。

人間のユーザー向けの連携機能が Workforce Identity、プログラムなどワークロード向けの連携機能が Workload Identity です。

詳細は以下を参照してください。

また、以下の当社記事で実際に AWS から Workload Identity によって Google Cloud へ認証・認可させた実例を紹介しています。

blog.g-gen.co.jp

blog.g-gen.co.jp

サービスアカウント

サービスアカウントとは

サービスアカウントとは、人間ではなくプログラムが利用するアカウントです。プログラムから Google Cloud API を利用する際は、サービスアカウントを使って認証・認可を行います。サービスアカウントはGoogle アカウントとは異なり Google Cloud プロジェクトの中に作成するクラウドリソースです。

サービスアカウントはメールアドレスの形式の名称を持ちます。以下は、サービスアカウント名の例です。

my-service-account@my-project-id.iam.gserviceaccount.com

サービスアカウントの利用

プログラムから Google Cloud の各種サービスを操作する際は、以下のいずれかの方法でプログラムをサービスアカウントとして認証させます。

  1. サービスアカウントキー(JSON 形式等)を読み込ませる
  2. プログラムが動作する実行環境(VM 等)にサービスアカウントをアタッチする

前者の方法は、サービスアカウントの秘密鍵を JSON 形式でダウンロードし、実行環境に配置して、それをプログラムから読み込ませる方法です。

後者の方法は、プログラムの実行環境が Google Cloud 環境である場合にのみ使えます。Compute Engine VM や Cloud Run サービス、Cloud Functions 関数などにはサービスアカウントをアタッチすることができます。Cloud SDK(クライアントライブラリ)や gcloud コマンドは、認証情報を明示的に指定しなければ、自動的に実行環境にアタッチされたサービスアカウントの認証情報を利用します。

サービスアカウントキーの注意点

サービスアカウントキーを利用するプログラムの実行環境が Google Cloud 環境であれば、前掲の2つの方法のうち、後者の方が強く推奨 されます。

サービスアカウントキーは JSON 形式のテキストファイルであり、漏洩の危険性があります。キーファイルが漏洩すれば、サービスアカウントが持つ権限を自由に行使して、Google Cloud 環境への侵害が可能になってしまいます。

後者のサービスアカウントをアタッチする方法であれば、キーの漏洩はありません。

また、組織のポリシー機能により、サービスアカウントキーの発行自体を禁止させることも可能です。以下の記事も参照してください。

blog.g-gen.co.jp

サービスアカウントの権限借用

サービスアカウントの応用技として権限借用があります。

他のプリンシパル(Google アカウントや他のサービスアカウント)からサービスアカウントの権限を借用して Google Cloud API を実行することが可能です。詳細は以下の記事も参考にしてください。

以下の記事では Terraform のセキュアな利用のためにサービスアカウントからの権限借用を活用する例を紹介しています。

blog.g-gen.co.jp

サービスエージェント

Google Cloud サービスが使う特殊なサービスアカウントとしてサービスエージェントがあります。

以下の記事で詳細に解説しています。

blog.g-gen.co.jp

PAM による特権管理

Privileged Access Manager(PAM)は、承認フローを通して時限付きの権限管理をするための仕組みです。Cloud IAM の1機能として無料で提供されています。

所定の承認者が承認したときに作業者に IAM 権限が付与され、設定時間が経過すると、権限が自動的に剥奪されます。「ジャスト・イン・タイム」な権限管理が可能になる仕組みです。

詳細は以下の記事を参照してください。

blog.g-gen.co.jp

杉村 勇馬 (記事一覧)

執行役員 CTO / クラウドソリューション部 部長

元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。