Cloud IAM

解決する課題

組織全体に同じアクセス制御モデルを行き渡らせつつ、事故と漏洩を防ぎます。

• 全員がオーナー、では事故が起きる → 必要な人に必要なロールだけを、必要な階層で渡したい
• アプリにキーを埋め込みたくない → サービスアカウントやWorkload Identity 連携で鍵レスに
• 数百プロジェクトの権限を個別管理したくない → 組織・フォルダ単位で付与して継承させたい
• 監査で「誰が何をできるか／何をしたか」を説明したい

主要概念と用語

• プリンシパル（メンバー）: アクセスする主体。Google アカウント（user:）、Google グループ（group:）、サービスアカウント（serviceAccount:）、Google Workspace / Cloud Identity ドメイン（domain:）、allUsers / allAuthenticatedUsers など
• ロール: 権限（service.resource.verb 形式のパーミッション。例 compute.instances.start）の集合。プリンシパルに「権限」を直接ではなくロール経由で付与する
  • 基本ロール（basic / primitive）: roles/owner・roles/editor・roles/viewer。広すぎるため本番では非推奨
  • 事前定義ロール（predefined）: サービスごとに用途別に用意された推奨ロール（例 roles/storage.objectViewer）
  • カスタムロール: 必要なパーミッションだけを束ねた独自ロール
• IAM 許可ポリシー（allow policy）: リソースに紐づくバインディング（role ↔ members の対応）の集合
• リソース階層: 組織（Organization）→ フォルダ（Folder）→ プロジェクト（Project）→ リソース。上位で付与したロールは下位に継承される
• サービスアカウント: 人ではなくワークロード（VM・Cloud Run・GKE 等）に紐づく ID。AWS の IAM ロールに近い
• 条件（IAM Conditions / CEL）: リソース名・時刻・属性などで付与を絞り込む条件付きアクセス

仕様・制限・クォータ

• グローバルサービス（リージョンに依存しない。プリンシパルとポリシーは全リージョン共通）
• 権限はプリンシパルに直接付与できない。必ずロールにまとめてバインドする（AWS のように JSON で個別の Action を列挙するモデルとは異なる）
• ポリシーにはサイズ上限（1 リソースあたりのバインディング数・許可ポリシーの最大サイズ）があり、メンバーをグループ化することで上限と管理コストを抑えるのが定石
• IAM Deny ポリシーは許可ポリシーとは別建てで、組織 / フォルダ / プロジェクトにアタッチする
• 短期トークンは Security Token Service（STS）/ IAM Credentials API が発行（signJwt / generateAccessToken 等）。AWS の STS に相当

内部の仕組み

リクエストが来ると、IAM はそのリソースから上位階層へさかのぼって有効なポリシーを合成し、評価します。

1. デフォルトは拒否（どのロールにも含まれなければアクセス不可）
2. 対象リソース＋継承された上位（プロジェクト/フォルダ/組織）のバインディングを集め、要求パーミッションを含むロールが付与されていれば許可
3. ただし該当する IAM Deny ルールがあれば、許可より優先して拒否

設計パターン / ベストプラクティス

• 最小権限の原則: 基本ロール（Owner/Editor/Viewer）を避け、事前定義ロール、足りなければカスタムロールで必要なパーミッションだけに絞る
• 付与は階層の適切な高さで: 全社共通は組織/フォルダ、個別はプロジェクト/リソースに。個人ではなくグループへ付与して入退社に強くする
• サービスアカウントキーを作らない: VM/Cloud Run/GKE にはアタッチしたサービスアカウントを使い、外部ワークロードには Workload Identity 連携（Workload Identity Federation）、GKE Pod には Workload Identity を使って鍵レスにする
• IAM Conditions で時間・リソース名・タグ（条件）により付与を限定する
• 組織ポリシー（Organization Policy） と併用し、IAM だけでは縛れないガードレール（外部公開の禁止等）を設定する

運用・監視

• IAM Recommender（ロール推奨） が直近の利用実績から過剰なロールの引き下げを提案
• Policy Analyzer で「このプリンシパルはどのリソースに何ができるか」を棚卸し、Policy Troubleshooter でアクセス可否の理由を逆引き
• Cloud Audit Logs（管理アクティビティ／データアクセス）で「誰がいつ何をしたか」を監査
• 権限エラー時は、有効ポリシー（継承込み）→ 条件 → Deny ポリシーの順で確認する

コスト

IAM 自体は無料で、ロール付与・ポリシー評価・STS によるトークン発行に料金はかかりません。ただし周辺の機能には課金されるものがあります。

セキュリティ

• 基本ロールを本番で使わない（特に roles/owner の乱発を避ける）
• サービスアカウントキー（JSON）を発行・配布しない。鍵レス（連携 / アタッチ）を優先する
• 特権操作には MFA（2 段階認証）を Cloud Identity / Workspace 側で必須化し、allUsers / allAuthenticatedUsers の付与を監査する
• IAM Conditions と Deny ポリシーで、想定外の経路・時間・リソースを塞ぐ

関連サービス・比較（AWS との対応）

ハンズオン / CLI例

# プロジェクトに対し、ユーザーにストレージ閲覧の事前定義ロールを付与
gcloud projects add-iam-policy-binding my-project \
  --member="user:alice@example.com" \
  --role="roles/storage.objectViewer"

# ワークロード用のサービスアカウントを作成し、必要なロールだけ付与
gcloud iam service-accounts create app-sa \
  --display-name="App Service Account"

gcloud projects add-iam-policy-binding my-project \
  --member="serviceAccount:app-sa@my-project.iam.gserviceaccount.com" \
  --role="roles/pubsub.subscriber"

# 現在のプロジェクトの IAM 許可ポリシーを確認（誰に何のロールが付いているか）
gcloud projects get-iam-policy my-project --format=json

# 認証中の自分の権限主体を確認（トラブル時に便利）
gcloud auth list