30日間で理解する GCP for AWSエンジニア - 実践ブログシリーズ - 2日目： GCPのIAMはAWSとどう違う？「プリンシパル」と「ロール」の理解

Last updated at 2025-08-16Posted at 2025-08-16

はじめに：なぜAWSエンジニアはGCPのIAMでつまずくのか？

皆さん、こんにちは！「30日間でGCPをマスターするAWSエンジニアの挑戦」シリーズ、2日目へようこそ。

AWSでは、IAMユーザー、IAMグループ、IAMポリシー、IAMロールといった概念を組み合わせて権限管理を行います。長年AWSを使ってきた方なら、{ "Effect": "Allow", "Action": "s3:GetObject" }のようなポリシーのJSONを自由に書くことに慣れていることでしょう。

しかし、GCPのIAMは、同じ「IAM」という名前を持ちながら、その設計思想が大きく異なります。

AWSの知識がGCPの学習で邪魔をしてしまう最初のポイントが、このIAMです。今日の記事を読めば、GCPのIAMがAWSとどう違うのか、そしてなぜそのように設計されているのかが、明確に理解できます。

この記事では、AWSのIAMの知識を前提に、GCPのIAMにおける最も重要な概念である 「プリンシパル」 と 「ロール」、そして 「リソース階層」 を徹底的に解説し、安全な権限管理のためのベストプラクティスを学びます。

IAMの基本構造の違い（AWS vs GCP）

まず、AWSとGCPのIAMの根本的な違いを図で見てみましょう。

AWSのIAM：ポリシーが主役

AWSのIAMでは、「ポリシー」 が権限を定義し、そのポリシーを 「ユーザー」「グループ」「ロール」 にアタッチすることで権限を付与します。

【AWSのIAMの権限付与の流れ】
ユーザー/グループ/ロール ───▶ ポリシー（権限の定義）

このモデルの強みは、JSON形式で非常に柔軟に、最小限の権限を詳細に記述できる点です。

GCPのIAM：ロールが主役

一方、GCPのIAMでは、「ロール」　が複数のパーミッション（権限）　をまとめたものとして定義されており、そのロールを「プリンシパル」 に付与します。

【GCPのIAMの権限付与の流れ】
プリンシパル ───▶ ロール（権限の定義）

これがGCPの「プリンシパルはロールを通じてリソースにアクセスできる」という基本的な考え方です。GCPは、細かいパーミッションを直接操作するのではなく、一貫性のある「ロール」を使用することを推奨しています。

👉 ポイント：用語が似ているが意味が異なる

AWSの「IAMロール」 は、一時的な認証情報を引き受けるためのIDです。
GCPの「ロール」 は、関連するパーミッション（permissions）の論理的な集まりです。

GCP IAMのリソース階層と権限継承

GCPではIAMを「どの階層に設定するか」が非常に重要です。この考え方は、AWS OrganizationsでIAMポリシーをアタッチするのと似ていますが、よりシンプルで直感的に機能します。

GCPの4つのリソース階層

組織（Organization）：会社の最上位階層。
フォルダ（Folder）：部門やチーム、環境（開発・本番）などの中間管理単位。
プロジェクト（Project）：AWSアカウントに相当する、リソースの最小管理単位。
リソース（Resource）：個々のサービス（VM、BigQuery Dataset、Cloud Storage Bucketなど）。

上位階層で付与したロールは、下位の階層に自動的に継承されます。

図解：権限継承のイメージ

組織 ─▶ フォルダ ─▶ プロジェクト ─▶ リソース

【具体的な継承例】

フォルダレベルで「閲覧者（roles/viewer）」ロールを付与すると、そのフォルダ内の全プロジェクトと、その中の全リソースを閲覧可能になります。
プロジェクトレベルで「Cloud Storage オブジェクト管理者（roles/storage.objectAdmin）」ロールを付与すると、そのプロジェクト内の全Cloud Storageバケットで、オブジェクトの管理が可能になります。

ハンズオン：AWSとGCPでのIAM設定比較

実際に手を動かして、AWSとGCPのIAM設定の違いを体感してみましょう。

シナリオ：開発者にインスタンス起動/停止とバケット読み取り権限を付与する

新しく入社した開発メンバーに、my-first-gcp-project プロジェクト内のCompute Engineインスタンスを起動・停止できる権限と、Cloud Storageバケットの中身を閲覧できる権限を付与します。

AWSの場合：IAMポリシーの作成

AWSでは、IAMポリシーをJSONで記述し、IAMユーザーにアタッチします。

【EC2インスタンス開始/停止を許可するIAMポリシー例】

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:StartInstances",
        "ec2:StopInstances"
      ],
      "Resource": "arn:aws:ec2:ap-northeast-1:123456789012:instance/*"
    },
    {
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::my-bucket/*"
    }
  ]
}

このポリシーをIAMユーザーにアタッチして利用します。権限が少し複雑になるだけで、JSONがどんどん長くなっていきます。

GCPの場合：ロールの付与

GCPでは、事前定義ロールをユーザーに付与します。

【gcloudコマンドでの設定例】

# Compute Engine インスタンス管理ロールを付与
gcloud projects add-iam-policy-binding my-first-gcp-project \
  --member="user:example-user@gmail.com" \
  --role="roles/compute.instanceAdmin.v1"

# Cloud Storage オブジェクト閲覧者ロールを付与
gcloud projects add-iam-policy-binding my-first-gcp-project \
  --member="user:example-user@gmail.com" \
  --role="roles/storage.objectViewer"

このように、GCPでは、必要な権限をロールという形で選び、ユーザーに付与するだけで済みます。AWSのように細かなJSONポリシーを自分で書く必要がなく、運用がシンプルになります。

GCPのベストプラクティスと注意点

GCPのIAMはシンプルですが、安全に運用するためにはいくつかのベストプラクティスがあります。

基本ロール（Owner/Editor/Viewer）は使わない
- これらのロールは非常に強力なため、意図しないアクセスを許可してしまうリスクがあります。学習用途以外では強く非推奨です。
まずは事前定義ロールを活用する
- GCPサービスごとに、最小権限の原則に基づいて多くの事前定義ロールが用意されています。これらを活用することで、安全かつ効率的に権限を管理できます。
必要に応じてカスタムロールを検討
- 事前定義ロールで要件を満たせない場合のみ、必要なパーミッションだけをまとめたカスタムロールを作成します。
- カスタムロールの例：特定のサービスアカウントで特定のAPIだけを呼び出す権限を付与する場合など。ただし、管理が複雑になるため、最小限に留めましょう。
サービスアカウントキーは発行しない
- AWSのアクセスキーと同様に、サービスアカウントキー（JSONファイル）は漏洩すると深刻なセキュリティリスクになります。
- 代わりにWorkload Identity Federationを利用し、キー管理なしで安全に認証する手法を強く推奨します。これは、AWSのIAM Roles for Service Accountsと非常に類似した仕組みで、キーを発行することなく外部からGCPリソースにアクセスできます。

【実用Tips】現在のIAM設定を確認するコマンド

# プロジェクトのIAMポリシー全体を確認
gcloud projects get-iam-policy my-first-gcp-project

# 特定のユーザーに付与されている権限を確認
gcloud projects get-iam-policy my-first-gcp-project \
  --flatten="bindings[].members" \
  --filter="bindings.members:example-user@gmail.com"

まとめ：AWSとGCP、それぞれのIAM設計思想

今回は、AWS経験者がつまづきやすいGCPのIAMについて、以下のポイントを解説しました。

AWSは「ポリシーを記述する」スタイル：JSONで柔軟に権限を制御する。
GCPは「ロールをバインディングする」スタイル：事前に定義されたロールを付与することでシンプルに管理する。
GCPのIAMはリソース階層で継承される：上位階層で付与した権限が下位に自動で引き継がれるため、付与場所に注意が必要です。
ベストプラクティスを守る：特に基本ロールは避けて、事前定義ロールやWorkload Identity Federationを活用することで、最小権限で安全に運用できます。

GCPのIAMは、AWSに慣れた方からすると最初は違和感があるかもしれませんが、この設計思想を理解すれば、より安全で運用しやすいシステムを構築できるはずです。

次回は、いよいよGCPのネットワークに足を踏み入れます。AWSのVPCと根本的に異なる 「VPCネットワーク」 の設計思想を徹底的に解説します。お楽しみに！

この記事が役に立ったという方は、ぜひ「いいね」や「ストック」をお願いします！

シリーズ記事一覧

[【1日目】はじめの一歩！AWSエンジニアがGCPで最初にやるべきこと]
[【2日目】GCPのIAMはAWSとどう違う？「プリンシパル」と「ロール」の理解]（この記事）
[【3日目】VPCの壁を越えろ！AWS VPCとGCP VPCネットワークの設計思想と実践ハンズオン]

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up