IAM とリソース階層 — 権限設計の基礎

Google Cloud のセキュリティ設計は「誰が（who）・どのリソースに対して（which）・何をできるか（what）」を決める IAM と、その判定の土台になるリソース階層から始まります。PCA 試験ではセクション 3.1 の中核であるだけでなく、ネットワークやデータの問題にも「最小権限で」という条件が繰り返し登場します。この章で権限設計の語彙を固めておくと、以降の全章が読みやすくなります。

リソース階層 — ポリシーは上から下へ流れる

Google Cloud のリソースは 4 階層のツリーを構成します。最上位の組織（organization）、任意の中間層であるフォルダ（folder）、リソースを入れる基本単位のプロジェクト（project）、そして VM やバケットなどのサービスリソースです。ルート以外の各リソースは必ずちょうど 1 つの親を持ちます。

• 組織: 会社に相当するルートノード。Google Workspace または Cloud Identity のアカウントと 1 対 1 で紐づき、ドメインのユーザーがプロジェクトを作ると自動的にプロビジョニングされます
• フォルダ: 部門・チーム・環境（dev / prod）を表すグルーピング。最大 10 段までネストでき、1 つの親フォルダ直下には 300 フォルダまで置けます（2026-08 時点）
• プロジェクト: API の有効化・課金・IAM のもっとも基本的な境界。すべてのサービスリソースはどれかのプロジェクトに属します

第 1 章で作った学習用プロジェクト（第 1 章参照）のような個人アカウントのプロジェクトには組織がなく、プロジェクト自体が階層の頂点になります。後からドメインに組織を作成すれば、その配下へ移行できます。

この階層が重要なのは、IAM の許可ポリシーが上から下へ継承されるからです。あるリソースで実際に効く「有効なポリシー」は、そのリソース自身に付与されたポリシーと、全祖先（プロジェクト・フォルダ・組織）から継承したポリシーの和集合です。つまり組織でロールを付与すれば全プロジェクトに効き、逆に「親で与えた権限を子で打ち消す」ことは許可ポリシーではできません（拒否には後述の拒否ポリシーという別の仕組みを使います）。

「部門ごとにアクセスを分離したい」「環境（dev / prod）ごとに権限を変えたい」という要件は、フォルダで階層を切り、付与するレベルを設計するのが定石です。「全プロジェクト共通の監査閲覧権限」なら組織レベルに 1 回付与、「このアプリの開発者だけ」ならプロジェクトレベルというように、ロールをどの階層に付与するかを設計します。

IAM の構成要素 — プリンシパル・ロール・許可ポリシー

IAM のアクセス制御は 3 つの要素で表現します。アクセスする主体のプリンシパル（principal）、権限（permission）の集合であるロール（role）、対象のリソースです。権限は service.resource.verb 形式（例: compute.instances.list）で、おおむね REST API のメソッドと 1 対 1 に対応します。重要なのは、権限を直接プリンシパルに付与することはできないという点です。必ずロールにまとめて、ロールをプリンシパルに付与します。

「誰にどのロールを与えたか」を記録するのが許可ポリシー（allow policy。IAM ポリシーとも呼ばれます）です。許可ポリシーはリソースにアタッチされる JSON / YAML のオブジェクトで、ロールとプリンシパル群を結びつけるロールバインディングの集合を持ちます。

プリンシパルはバインディングの中でプレフィックス付きで指定します。人間のユーザー（Google アカウント・Google グループ・workforce identity）と、ワークロード（サービスアカウント・workload identity）の 2 系統があります。

gcloud では、ポリシー全体の読み取りに get-iam-policy、1 バインディングの追加 / 削除に add-iam-policy-binding / remove-iam-policy-binding を使います。複数の変更をまとめて行うときは「読み取り → ローカルで編集 → set-iam-policy で書き戻し」の read-modify-write が推奨手順です。許可ポリシーの変更は通常 2 分、最長で 7 分以上かかって反映されます（2026-08 時点）。

許可ポリシーを補完する仕組みも押さえておきましょう。拒否ポリシー（deny policy）はロールが付与されていても特定の権限の使用を拒否し、IAM Conditions はバインディングに属性ベースの条件（リソースタグや時間帯など）を付けます。Privileged Access Manager を使うと、承認フロー付きの一時的な権限付与（Just-in-Time アクセス）を実現できます。

基本ロール・事前定義ロール・カスタムロール

ロールには 3 種類あります。試験でも実務でも「どれを選ぶか」の判断基準が問われます。

基本ロール（basic role）のうち Owner / Editor / Viewer はレガシー基本ロール（IAM 以前からある旧称 primitive role）で、条件付きバインディングも使えません。2026-08 時点では新しい基本ロール Admin（roles/admin）/ Writer（roles/writer）/ Reader（roles/reader）が Preview として追加されていますが、コンソールからは付与できず gcloud / API 経由のみです。いずれにせよ公式ドキュメントは「本番環境では代替がない場合を除き基本ロールを付与しない」と明言しています。数千の権限を一括で渡すことは最小権限の原則に真っ向から反するからです。

カスタムロールは権限を 1 つずつ列挙して作る自前のロールです。作成できるのは組織レベルとプロジェクトレベルだけで、フォルダレベルでは作成できません。また Google は事前定義ロールと違ってカスタムロールの権限を自動更新しないため、新機能で必要になった権限は自分で追加し続ける必要があります。削除したカスタムロールの ID が再利用可能になるまで最長 44 日かかる点にも注意してください（2026-08 時点）。

サービスアカウント — 鍵を作らないのが原則

サービスアカウント（service account, SA）は、人ではなくアプリケーションや VM などのワークロードが使う特別なアカウントです。メールアドレス形式の ID（SA_NAME@PROJECT_ID.iam.gserviceaccount.com）を持ち、アイデンティティとリソースの二面性があります。つまり「SA にロールを付与してリソースへアクセスさせる」ことも、「SA というリソース自体に『誰がこの SA を使えるか』のポリシーを付ける」こともできます。

SA の認証でもっとも避けたいのがサービスアカウントキー（ダウンロード型の秘密鍵）です。キーは漏えいすればそのまま成りすましに使える強力な資格情報で、公式ドキュメントも「他の選択肢があるならキーを使わない」と明記しています。認証手段は次の優先順位で選びます。

1. 開発中: 自分のユーザー資格情報で Application Default Credentials（ADC）を使う
2. Google Cloud 上のワークロード: リソースに SA をアタッチする（Compute Engine への直接アタッチ、GKE の Workload Identity）
3. 外部（オンプレ・他クラウド・CI/CD）のワークロード: Workload Identity Federation で鍵なし連携
4. 最終手段: どうしても代替がない場合のみ SA キーを作成し、厳重に管理する

impersonation — 人が SA の権限を一時的に借りる

認証済みのプリンシパルが SA として振る舞うことを impersonation（借用）と呼びます。SA に対して roles/iam.serviceAccountTokenCreator（権限 iam.serviceAccounts.getAccessToken を含む）を持つプリンシパルは、その SA の短命トークン（数時間以内で失効、自動更新なし）を取得して API を呼べます。キーと違って、ほとんどの監査ログには借用した本人と SA の両方の ID が残るため、「誰がやったか」を追跡できます。gcloud では --impersonate-service-account フラグ一発で使えます（コンソールは常にユーザー資格情報で動作し、impersonation はできません）。

混同しやすい roles/iam.serviceAccountUser は「SA をリソースにアタッチする（iam.serviceAccounts.actAs）」ためのロールです。VM に SA を載せてデプロイする人には serviceAccountUser、SA の権限を CLI で借りたい人には serviceAccountTokenCreator、と使い分けます。どちらも「SA が持つ全権限への入口」になるため、付与は慎重に行います。

Workload Identity Federation — 外部ワークロードの鍵なし認証

オンプレや AWS・Azure、GitHub Actions などの外部ワークロードが Google Cloud にアクセスするとき、従来は SA キーを配布していました。Workload Identity Federation（WIF）はこれを置き換える仕組みで、外部 IdP（AWS、Azure、GitHub、GitLab、Kubernetes、OIDC / SAML 2.0 対応 IdP、X.509 証明書など）のトークンを Google の Security Token Service（STS）が OAuth 2.0 token exchange 仕様で検証し、短命の連携トークンに交換します。Workload Identity プール（環境ごとに作るのが推奨）とプロバイダ（属性マッピングと検証条件の定義）を設定し、連携 ID は principal://（個体）や principalSet://（グループ・属性単位）でバインディングに指定します。

組織ポリシーと職掌分散（SoD）

IAM が「誰が操作できるか」を決めるのに対し、組織ポリシー（Organization Policy Service）は「どんな構成が許されるか」をリソース階層全体に強制するガードレールです。組織ポリシーは制約（constraint）の集合として設定し、たとえ Owner 相当の権限を持つ人でも、制約に反する構成は作れません。代表的な制約には次のようなものがあります。

• iam.disableServiceAccountKeyCreation — SA キーの作成を禁止（キー事故の元栓を締める）
• iam.automaticIamGrantsForDefaultServiceAccounts — デフォルト SA への自動的なロール付与を停止
• compute.vmExternalIpAccess — VM の外部 IP 付与を制限
• gcp.resourceLocations — リソースを作成できるリージョンを制限（データレジデンシー）

制約にはブール型（強制する / しない）とリスト型（許可 / 拒否する値の列挙）があり、上位で設定したポリシーは下位に継承されます。下位では継承をそのまま受けるか、自分のポリシーで置き換えるかを選べます。設定には roles/orgpolicy.policyAdmin が必要で、本適用の前に影響だけを監査ログで観測するドライランも使えます。組織ポリシーは組織リソースが前提の機能なので、組織なしの学習プロジェクトでは「読んで理解する」に留めましょう（第 13 章で代表的な制約を深掘りします）。

職掌分散（Separation of Duties, SoD）は「1 人の人間・1 つのアイデンティティに、悪用可能な権限の組み合わせを集中させない」という設計原則です。IAM ではこれを次のように実装します。

• アプリケーションのコンポーネントごとに信頼境界を分けて専用の SA を作る（1 つの SA を複数ワークロードで共用しない）
• 環境をプロジェクト（さらにフォルダ）で分離し、開発者に本番プロジェクトの変更権限を与えない
• ロールを付与する権限（例: roles/resourcemanager.projectIamAdmin）と、監査する権限（例: roles/iam.securityReviewer）を別のグループに分ける
• SA の impersonation 権限（serviceAccountTokenCreator / serviceAccountUser）は「自分より強い SA を借りられる」privilege escalation の入口になるため、付与先を絞る

gcloud config get-value project
gcloud projects get-iam-policy PROJECT_ID

bindings:
- members:
  - user:you@example.com
  role: roles/owner
etag: BwYnXk...
version: 1

gcloud iam service-accounts create pca-audit \
  --display-name="PCA handson audit"

gcloud projects add-iam-policy-binding PROJECT_ID \
  --member="serviceAccount:pca-audit@PROJECT_ID.iam.gserviceaccount.com" \
  --role="roles/browser"

gcloud projects get-iam-policy PROJECT_ID \
  --flatten="bindings[].members" \
  --filter="bindings.members:pca-audit" \
  --format="table(bindings.role)"

gcloud projects remove-iam-policy-binding PROJECT_ID \
  --member="serviceAccount:pca-audit@PROJECT_ID.iam.gserviceaccount.com" \
  --role="roles/browser"
gcloud iam service-accounts delete \
  pca-audit@PROJECT_ID.iam.gserviceaccount.com --quiet

gcloud iam service-accounts add-iam-policy-binding \
  pca-audit@PROJECT_ID.iam.gserviceaccount.com \
  --member="user:YOUR_EMAIL" \
  --role="roles/iam.serviceAccountTokenCreator"

gcloud projects describe PROJECT_ID \
  --impersonate-service-account=pca-audit@PROJECT_ID.iam.gserviceaccount.com

WARNING: This command is using service account impersonation. All API calls will be
executed as [pca-audit@PROJECT_ID.iam.gserviceaccount.com]
lifecycleState: ACTIVE
projectId: PROJECT_ID

gcloud iam service-accounts list \
  --impersonate-service-account=pca-audit@PROJECT_ID.iam.gserviceaccount.com

gcloud iam service-accounts remove-iam-policy-binding \
  pca-audit@PROJECT_ID.iam.gserviceaccount.com \
  --member="user:YOUR_EMAIL" \
  --role="roles/iam.serviceAccountTokenCreator"

gcloud iam roles create pcaAuditor --project=PROJECT_ID \
  --title="PCA Auditor" \
  --description="プロジェクト情報と IAM ポリシーの閲覧のみ" \
  --permissions="resourcemanager.projects.get,resourcemanager.projects.getIamPolicy" \
  --stage=GA

gcloud iam roles describe pcaAuditor --project=PROJECT_ID

gcloud policy-intelligence troubleshoot-policy iam \
  //cloudresourcemanager.googleapis.com/projects/PROJECT_ID \
  --principal-email=pca-audit@PROJECT_ID.iam.gserviceaccount.com \
  --permission=resourcemanager.projects.get

gcloud projects remove-iam-policy-binding PROJECT_ID \
  --member="serviceAccount:pca-audit@PROJECT_ID.iam.gserviceaccount.com" \
  --role="roles/browser"
gcloud iam service-accounts delete \
  pca-audit@PROJECT_ID.iam.gserviceaccount.com --quiet
gcloud iam roles delete pcaAuditor --project=PROJECT_ID

# 確認: 何も表示されなければ削除完了
gcloud projects get-iam-policy PROJECT_ID | grep pca-audit

つまずきポイント

理解度チェック

まとめと次章へ

• リソース階層は組織 → フォルダ → プロジェクト → リソース。許可ポリシーは上から下へ継承され、有効なポリシーは和集合で評価される
• IAM は「プリンシパルに、リソースに対するロールを付与する」。権限の直接付与はできず、付与単位はグループが基本
• ロールは事前定義が第一候補。基本ロールは本番で使わず、カスタムロールは組織かプロジェクトで作成しメンテを覚悟する
• SA は「鍵を作らない」が大原則。アタッチ → WIF → impersonation を使い分け、最終手段以外でキーを発行しない
• IAM（誰が）と組織ポリシー（何を許すか）は多層防御として重ねて使い、SoD で権限の集中を避ける

権限の土台ができたので、第 3 章では VPC ネットワーキングに進みます。ファイアウォールルールのターゲットにサービスアカウントを使うなど、この章の知識はすぐに再登場します。IaC で IAM を宣言的に管理する方法は第 16 章で扱います。

参考リンク（一次情報）:

• IAM overview / Roles overview
• Resource hierarchy
• Service accounts overview / Best practices for using service accounts
• Workload Identity Federation
• Organization Policy Service
• Troubleshoot access with Policy Troubleshooter