Google Cloud Assosiate Cloud Engineer 第2章　IAM とリソース管理

Google Cloud Assosiate Cloud Engineer
第2章　IAM とリソース管理

2.1 リソース階層

2.1.1 リソース階層とは何か

Google Cloud のリソースは、階層構造（リソース階層 / Resource hierarchy）で管理される。
この階層には主に次の 2 つの目的があると公式ドキュメントで説明されている。

  • リソースの「所有権」とライフサイクルを階層的に管理すること
  • IAM ポリシーや組織ポリシー（Organization Policy）の「接続ポイント」として機能し、継承を可能にすること

リソース階層は、ディレクトリやファイルを階層構造で管理する OS のファイルシステムに似ており、一般的に各リソースには 1 つの親しか存在しない。

ACE 試験では、この「どのレベルにどんな設定をぶら下げるか」を理解しているかどうかが、IAM やセキュリティ関連問題の前提になる。

2.1.2 リソース階層の全体像

Google Cloud の代表的なリソース階層は、次のような構造になる。

Organization（組織）        ← ルート（任意だが推奨）
└─ Folder（フォルダ）       ← 部門／チーム／環境ごとのグルーピング
   └─ Project（プロジェクト）← 課金・API・クォータ単位
      └─ リソース           ← GCE インスタンス、GCS バケットなど
  • Organization
    会社や組織全体に対応するルートノード
  • Folder
    部門・チーム・環境（prod / dev など）を表現する中間レイヤ
  • Project
    実際のワークロードやサービスを動かす単位（API 有効化・課金・クォータ付与の境界）
  • Project 配下リソース
    Compute Engine インスタンス、Cloud Storage バケット、Cloud SQL、GKE クラスタ など

個人アカウントで試すだけであれば Organization を持たない構成も可能だが、企業利用や IAM / Policy を本格的に設計する場合、Organization をルートにした構成が標準的な前提になる。

2.1.3 組織リソース（Organization）

Organization リソースは、Google Cloud リソース階層のルートノードであり、プロジェクトやフォルダの祖先にあたる。

  • 組織全体（会社・法人など）を表す
  • 1 つの Google Workspace / Cloud Identity テナントに対して 1 つの Organization が対応する
  • Organization に設定した IAM ポリシーや組織ポリシーは、配下のフォルダ・プロジェクト・リソースに継承される

ポイント:

  • 多くの Resource Manager 機能（組織ポリシー、フォルダ構成など）は Organization を前提にしている
  • Privileged Access Manager など一部サービスは Organization がないと利用できない

ACE 試験では、「Organization をルートに持つ構成」が前提として出題されるシナリオが多いと考えてよい。

2.1.4 フォルダ（Folder）

Folder は、Organization 配下に作成できる中間レイヤのコンテナリソースであり、プロジェクトやさらに下位のフォルダをまとめるために使われる。

フォルダの主な用途:

  • 組織構造の反映
    • 例：/Org/example.com/Departments/Finance のように部門単位でフォルダを分ける
  • 環境ごとの分離
    • 例：/Org/example.com/Environments/Prod と /Org/example.com/Environments/Dev
  • 権限とポリシーの境界
    • フォルダ単位で IAM ロールや組織ポリシーを設定し、配下のプロジェクトへ継承させる

公式ドキュメントやベストプラクティスでは、フォルダを用いて「部門・チーム・環境ごとのトラスト境界（信頼境界）を作る」設計が推奨されている。

ACE 試験的には、次の点を押さえておくとよい。

  • フォルダにも IAM ポリシーを付与でき、それは配下のフォルダ・プロジェクトに継承される
  • フォルダはネスト可能で、複数階層にすることで柔軟な権限設計ができる

2.1.5 プロジェクト（Project）とその配下リソース

Project は、Google Cloud の基本的な「作業単位」であり、多くのサービスの課金単位・クォータ単位・API 有効化単位になる。

プロジェクトの特徴:

  • 各プロジェクトには一意な Project ID と Project Number が付与される
  • API を有効化し、サービスアカウントやリソースを作成する単位
  • 課金アカウントと関連付けられ、利用料金が計算される単位

その配下には、実際のワークロードを構成するリソースがぶら下がる。

Project: app1-prod
├─ Compute Engine インスタンス
├─ Cloud Storage バケット
├─ Cloud SQL インスタンス
└─ GKE クラスタ

IAM の観点では、プロジェクトレベルでのロール付与が最もよく使われる。プロジェクトに付与されたロールは、そのプロジェクト内の全リソースに継承される。

2.1.6 IAM ポリシーの継承モデル

リソース階層の理解で特に重要なのが、IAM ポリシー（Allow ポリシー）の継承である。

公式の IAM ドキュメントでは、次のように説明されている。

  • IAM ポリシーは、Organization → Folder → Project → リソース の順に上位から下位へ継承される
  • あるリソースの「有効ポリシー（effective policy）」は
    • そのリソース自身のポリシー
    • すべての先祖リソース（親フォルダ、親組織など）のポリシー
      の和集合（union） で決まる

これを模式的に表すと次のようになる。

Organization: roles/logging.admin （ユーザー A）
   ↓ 継承
Folder: （追加なし）
   ↓ 継承
Project: roles/storage.admin （ユーザー A）
   ↓ 継承
GCS バケット（Project 配下のリソース）

⇒ ユーザー A の有効な権限 = logging.admin + storage.admin

重要なポイントは次の通り。

  1. 上位で付与したロールは下位で「消せない」
    • 上位の IAM バインディングを、下位のポリシーで打ち消すことはできない。
    • これは公式ブログや Q&A でも繰り返し説明されている。
  2. 下位リソースでは、上位ポリシーにロールを追加することだけができる
    • 例：Organization で「閲覧権限のみ」、特定プロジェクトで「編集権限」を追加、など。

ACE 試験では、次のようなシナリオとしてよく問われるイメージを持つとよい。

  • 「Organization レベルで広く Viewer 権限を付与している状態で、特定プロジェクトだけオーナー権限を与えたい」
  • 「特定のフォルダ配下のプロジェクトだけに、ネットワーク管理ロールを付けたい」

このとき、「どのレベルで誰にどのロールを付ければ、最小権限を守れるか」を判断する問題が出る。

2.1.7 組織ポリシーと階層（軽く触れておく）

IAM とは別系統だが、組織ポリシー（Organization Policy） もリソース階層に沿って適用される。

  • 組織ポリシーは、「外へ公開禁止」「特定リージョンのみ許可」など、構成のガードレールを定める仕組み。
  • 通常は Organization や Folder 単位で設定し、配下プロジェクトに継承させる。

ポリシーの評価ロジックは IAM より複雑だが、ACE レベルでは「上位で設定した組織ポリシーが、デフォルトでは下位に適用される」ことを押さえておけば十分である。

2.1.8 設計パターンと ACE 試験での押さえどころ

最後に、リソース階層の設計パターンと、試験で意識すべきポイントをまとめる。

よくある設計パターン（例）

Organization: example.com
├─ Folder: Prod
│   ├─ Project: app1-prod
│   └─ Project: app2-prod
└─ Folder: Dev
    ├─ Project: app1-dev
    └─ Project: shared-dev-tools
  • Organization レベル
    • 全社共通の Viewer 権限、セキュリティチームの監査ロールなどを付与
  • Prod フォルダ
    • 本番環境のみに強い組織ポリシー（例：公開制限）を適用
    • 本番運用チームに対して編集・管理ロールを付与
  • Dev フォルダ
    • 開発チーム向けにより自由度の高い権限を付与

ACE 試験でのチェックポイント

  • リソース階層の順序：Organization → Folder → Project → リソース を即答できること
  • 「どのレベルで IAM / 組織ポリシーを設定すると、どこまで影響するか」を説明できること
  • 「上位で付けたロールを下位で打ち消すことはできない」「有効ポリシーは親子すべての和集合」という原則を理解していること

この節の内容は、後続の「IAM ロール」「Service Account」「組織ポリシー」などの理解の土台になる。
ACE の IAM 系問題はすべて、このリソース階層の上で考えることになるため、ここでイメージをしっかり固めておくことが重要である。

2.2 IAM ロール

2.2.1 ロールとは何か

IAM（Identity and Access Management）では、ユーザーやサービスアカウントなどの「プリンシパル」に対して、権限そのものではなくロール（役割） を付与する。ロールは複数の権限（permissions）をまとめた束であり、「誰に（principal）・どのロールを・どのリソース階層で」付与するかを IAM ポリシーとして定義する。

個々の権限は compute.instances.start や storage.objects.get のような最小単位のアクションであり、実際の運用ではこれらを直接ユーザーに付与することはなく、ロールを通してまとめて扱う。

Google Cloud IAM のロールは大きく次の 3 種類に分類される。

  • Basic roles（基本ロール / 旧 Primitive roles）
  • Predefined roles（事前定義ロール）
  • Custom roles（カスタムロール）

ACE 試験では、この 3 種類の違いと、最小権限の観点からどれを使うべきかを判断できることが重要になる。

2.2.2 ロールの種類と名前の形式

IAM ロールは種類によって名前の形式が異なる。

  • Basic roles（基本ロール）
    • 例: roles/owner, roles/editor, roles/viewer
  • Predefined roles（事前定義ロール）
    • 例: roles/storage.objectViewer, roles/compute.instanceAdmin.v1, roles/bigquery.dataEditor
    • 形式: roles/SERVICE.IDENTIFIER
  • Custom roles（カスタムロール）
    • プロジェクトレベル: projects/PROJECT_ID/roles/ROLE_ID
    • 組織レベル: organizations/ORG_ID/roles/ROLE_ID

ロールの種類によって権限の広さ・管理主体・利用目的が異なるため、試験問題のシナリオで「どのレベルのロールをどこに付けるべきか」を問われたとき、この分類を意識して読むことが大切である。

2.2.3 Basic roles（基本ロール）

Basic roles は、初期の Google Cloud に存在した「プロジェクト全体」に対する大まかな権限で、次の 3 つから構成される。

  • Viewer (roles/viewer)
    • すべてのリソースに対する読み取り権限
  • Editor (roles/editor)
    • 読み取りに加え、多くのリソースの作成・変更・削除を行える
  • Owner (roles/owner)
    • Editor の権限に加え、IAM ポリシーの変更や課金設定の変更など管理系操作を行える

これらのロールは「プロジェクト内のほぼすべてのサービス・リソースに対する権限」を含んでいるため、適用範囲が極端に広い。公式のセキュリティガイドでは、次のように明確に注意喚起されている。

Basic roles は、すべての Google Cloud サービスにまたがる数千の権限を含む。
本番環境では、やむを得ない場合を除き Basic roles を付与しないこと。

つまり、Basic roles は以下のような位置づけになる。

  • 利点:
    • テスト環境などで「とりあえず全部触っていい」状態を簡単に作れる
  • 欠点:
    • 本番環境に付与すると、不要な権限まで与えることになり、最小権限の原則に反する
    • 権限の調査や監査が難しくなる

ACE 試験では、「本番環境で Basic roles を使う選択肢は原則として不適切」と考えてよい。
選択肢の中に roles/editor や roles/owner が紛れ込んでいる場合、それを選ぶべき状況はかなり限定的である。

2.2.4 Predefined roles（事前定義ロール）

Predefined roles は、Google Cloud が各サービスごとに提供しているサービス固有の細かいロールである。

特徴は次の通り。

  • 各ロールは特定のサービスやユースケースに特化した権限の集合
  • Google が管理しており、新機能の追加などに応じて権限が更新される
  • Cloud Storage、Compute Engine、BigQuery など、ほぼすべての主要サービスに多数の Predefined roles が用意されている

例として、公式ドキュメントや技術ブログなどに挙げられる代表的なロールは次の通り。

  • roles/storage.objectViewer
    • Cloud Storage オブジェクトの閲覧のみ（読み取り専用）
  • roles/storage.objectAdmin
    • オブジェクトの作成・削除などを含むより広いオブジェクト管理権限
  • roles/compute.instanceAdmin.v1
    • Compute Engine インスタンスの作成・変更・削除など、インスタンス管理に必要な権限一式
  • roles/bigquery.dataEditor
    • BigQuery のデータセットやテーブルに対する変更権限

Predefined roles の利点は、「最小権限の原則を守りつつ、現実的な運用に必要な権限をまとめて付与できる」ことである。

公式のセキュリティガイドでも、「本番環境では Basic roles ではなく、可能な限り Predefined roles か Custom roles を使うべき」と明記されている。

ACE 試験における典型的なパターンは次のようなものだ。

  • 「Cloud Storage バケット内のオブジェクトを読み取るだけの権限が必要」 → roles/storage.objectViewer
  • 「特定のプロジェクトで Compute Engine インスタンスの起動・停止・作成・削除を行いたい」 → roles/compute.instanceAdmin.v1
  • 「BigQuery のデータを更新したいが、プロジェクト全体の管理権限は不要」 → roles/bigquery.dataEditor

選択肢に Basic roles と Predefined roles が混在している場合、最小権限を満たす範囲で最も狭い Predefined role を選ぶのが基本戦略となる。

2.2.5 Custom roles（カスタムロール）

Custom roles は、組織やプロジェクト固有の要件に合わせて、必要な権限だけを集めて作成できるロールである。

特徴:

  • 組織レベルまたはプロジェクトレベルで作成可能
  • 既存の権限リストから必要なものだけを選んでロールを定義する
  • 事前定義ロールではカバーしきれない細かい要件（社内ツール・特定業務フローなど）に対応できる

Custom role の名前の例:

  • 組織レベル:
    • organizations/123456789012/roles/SecurityReadOnly
  • プロジェクトレベル:
    • projects/my-project/roles/BatchJobRunner

作成方法はコンソール・gcloud・API などで提供されており、公式ドキュメントには gcloud iam roles create を用いたサンプルが掲載されている。

一方で、Custom roles は設計と運用の難易度が高いという側面もある。

  • どの権限を含めるべきかの判断が難しく、最小権限を満たす構成を自力で考える必要がある
  • 乱立すると管理が煩雑になり、「何のためのロールか分からないロール」が増えてしまう

そのため、多くのベストプラクティスでは、次のような方針が推奨されている。

  1. まずは可能な限り Predefined roles で対応する
  2. どうしても要件に合うロールが見つからない場合にのみ Custom roles を検討する
  3. Custom roles は命名規約や管理フローを決めたうえで慎重に運用する

ACE 試験では、「Custom roles を作るべきか／Predefined roles で対応すべきか」という判断が問われることがあるが、原則として Predefined roles を優先し、Custom roles は例外的な手段と理解しておけば十分である。

2.2.6 最小権限（Least privilege）とロール選択

IAM のコア原則は、公式ドキュメントやブログでも繰り返し述べられている通り、最小権限（least privilege） である。

  • ユーザーやサービスアカウントには、「その業務に本当に必要な権限だけ」を付与する
  • 過剰な権限（例: Editor, Owner, 広すぎる Custom roles）は、誤操作や侵害時の被害を拡大させる

Google はこれを支援する仕組みとして、IAM Recommender を提供している。これは、過去の 90 日間などの使用状況を分析し、「使われていない権限を含むロール」を特定して削減を提案する機能である。

ACE 試験での実務寄りシナリオでは、例えば次のような問い方をされる。

  • 「現在 Editor ロールが付与されているが、実際には一部の操作しか行っていないユーザーがいる。セキュリティを強化するにはどうすべきか」
    • → IAM Recommender を使って不要な権限を特定し、より狭い Predefined role または Custom role に置き換える、といった選択肢が正解になりやすい。

2.2.7 ACE 試験で押さえておくべきポイント

IAM ロールに関する ACE 向けの要点を整理すると、次の通りである。

  1. ロールの 3 種類を区別できること
    • Basic / Predefined / Custom の違い・用途・注意点を説明できること。
  2. Basic roles の危険性を理解していること
    • Viewer / Editor / Owner は「プロジェクト全体」に非常に広い権限を与えるため、本番環境での利用は推奨されない。
  3. Predefined roles を最優先で使うという指針
    • サービスごとの細かいロールが用意されており、最小権限を満たしやすい。
    • Cloud Storage や Compute、BigQuery など代表的なロールのイメージを持っておく。
  4. Custom roles の位置づけ
    • 例外的なニーズに対して、既存権限からピンポイントでロールを組み立てるための仕組み。
  5. 最小権限と IAM Recommender
    • 使われていない権限を検出し、ロールの削減（置き換え）を提案する仕組みが存在する。
    • 「セキュリティ強化」「不要な Editor の削減」といったシナリオで回答のヒントになる。

この節で説明した内容は、後の「Service Account」「アクセスとセキュリティの構成」ドメインにも直結する。
IAM ロールの選択を誤ると、どれだけリソース階層やネットワークを正しく設計してもセキュリティは崩壊するため、ACE 学習の早い段階でしっかり整理しておくべき最重要トピックである。

2.3 Service Account

2.3.1 サービスアカウントとは何か

サービスアカウント（Service Account, SA） は、人間のユーザーではなく、
「アプリケーション」や「ワークロード」が Google Cloud リソースにアクセスするための ID である。

公式ドキュメントでは、サービスアカウントを次のように位置づけている。

  • サーバー間（server-to-server）のやり取りで
  • アプリケーション自身が自分のリソースにアクセスする、あるいは
  • 管理者がドメイン全体の権限を委譲する場合に利用する「特別なアカウント」

ACE 試験の文脈では、「人間のユーザーに直接権限を付けるのではなく、アプリケーションに対応するサービスアカウントに権限を付与する」という設計思想が重要になる。

2.3.2 サービスアカウントの種類

Google Cloud のサービスアカウントは、大きく次の 2 種類に分けられる。

  1. ユーザー管理のサービスアカウント（user-managed service accounts）
    • 開発者や管理者が自分で作成・管理する SA
    • 例: アプリケーション用、バッチ処理用、CI/CD パイプライン用など
  2. Google 管理のサービスアカウント（service agents / Google-managed service accounts）
    • Cloud Storage、Cloud Functions、Cloud Composer など、
      各サービスが内部処理のために自動的に作成する SA
    • プロジェクトに自動で追加され、該当サービスの動作に必要な権限が付与される

ACE のレベルでは、主に ユーザー管理のサービスアカウント を意識しておけばよいが、
問題文に「自動で作成されるサービスアカウント」「サービスエージェント」が出てきた場合、
「Google Cloud 自身がバックエンド処理用に使う ID である」と理解しておくと選択肢を読みやすくなる。

2.3.3 サービスアカウントと IAM ロール／権限委譲

サービスアカウントも、ユーザーと同じく IAM のプリンシパルの一種である。
つまり、「誰に（＝どのサービスアカウントに）」「どのロールを」「どのリソース階層で」付与するか を決めることで、アプリケーションの権限を制御できる。

典型的なパターンは次の通り。

  • バッチ処理用 SA に roles/bigquery.dataEditor を付与し、
    BigQuery テーブルの読み書きを許可する
  • Web アプリ用 SA に roles/storage.objectViewer を付与し、
    Cloud Storage から静的コンテンツを読み出す権限を与える

また、Compute Engine や GKE、Cloud Run などの実行環境にサービスアカウントを「紐付ける」ことで、
そのワークロードが API を呼び出す際に、紐付けられた SA の ID で認証・認可が行われる。

ポイントは次の 2 つである。

  1. 権限は「人」ではなく「ワークロード」に付与する
    • 人間ユーザーにはあくまで「運用・管理用の権限」を付け、
      本番処理そのものはサービスアカウントに任せる。
  2. 付与するロールは最小権限で
    • roles/editor などの Basic role ではなく、
      roles/storage.objectAdmin など適切な Predefined role を選ぶ。

ACE 試験では、「どのサービスアカウントに、どのロールを付けるべきか」を問うシナリオが頻出する。

2.3.4 認証パターンと鍵（キー）管理の基本

サービスアカウントで認証する方法にはいくつかのパターンがあるが、
現在のベストプラクティスは一言でいうと “できるだけ鍵（JSON キー）を使わない” である。

(1) キーレス認証（推奨）

多くの Google Cloud ランタイム環境（Compute Engine、GKE、Cloud Run など）では、
サービスアカウントキーをローカルに置かなくても、
メタデータサーバや内蔵の認証機構を通じてトークンを取得できる。

例:

  • Compute Engine インスタンスに SA をアタッチ → インスタンス内から Application Default Credentials（ADC）を利用
  • Cloud Run サービスに SA を指定 → 実行時にその SA の短命トークンで認証される

この場合、JSON キーのファイルはそもそも存在せず、
漏洩リスクが大幅に下がる。

(2) ユーザー管理のサービスアカウントキー（できれば避ける）

gcloud iam service-accounts keys create などで作成する
「ダウンロード可能な JSON キー」は、長期間有効な静的な認証情報であり、
漏洩した場合のインパクトが非常に大きい。

公式のベストプラクティスでは、次のように明言されている。

  • 可能な限り、ユーザー管理のサービスアカウントキーを使用しない
  • 代わりに、
    • ランタイムのキーレス認証（ADC）
    • Workload Identity / Workload Identity Federation
    • サービスアカウントの権限借用（impersonation）
      などを使う

どうしてもキーを使わざるを得ない場合は、

  • 期限付きキーの利用（有効期限を設定）
  • Secret Manager 等への安全な保管
  • 定期的なローテーション
  • 利用者・利用場所の最小化

といった運用が必須となる。

(3) Workload Identity 連携 / Federation

オンプレミスや他クラウド（AWS・Azure 等）から Google Cloud にアクセスする場合、
サービスアカウントキーの代わりに Workload Identity 連携（Federation） を使うことが推奨される。

  • 外部 IdP（OIDC、SAML など）のトークンを
    Google Cloud の Security Token Service に渡し、
    短命のアクセス トークンに交換する仕組み
  • JSON キーを配布・管理する必要がなく、漏洩リスクを大きく減らせる

ACE 試験では深い設定手順までは問われにくいが、
「オンプレや他クラウドから安全に認証したい → Workload Identity Federation が候補」
というレベル感は押さえておきたい。

2.3.5 サービスアカウントの権限借用（Impersonation）

サービスアカウントの権限借用（impersonation） は、
ユーザーや別のサービスアカウントが、
特定のサービスアカウントになりすまして一時的に権限を行使する仕組みである。

仕組みとしては、常に 2 つの ID が登場する。

  1. 認証済みプリンシパル（借用元）
    • 例：開発者のユーザーアカウント、CI/CD 用のサービスアカウントなど
  2. 権限を借用されるサービスアカウント（借用先）

借用元は、IAM の roles/iam.serviceAccountTokenCreator など必要なロールを借用先 SA に対して持っているとき、
その SA のアクセストークンを発行し、
「サービスアカウントとして」API を呼び出すことができる。

代表的な利用例:

  • 開発者が gcloud コマンドで
    --impersonate-service-account=SA_EMAIL を指定して操作する
  • Terraform などの IaC ツールから、
    権限の強い SA を直接キーで持たせるのではなく、
    Impersonation で一時的に借用させる

セキュリティ面では、次の利点がある。

  • 強い権限を持つ SA のキーを配らずに済む
  • 借用元プリンシパルに対しても、
    「トークン発行」という限定的な権限だけを与えられる
  • Cloud Audit Logs で「誰がどの SA を借用したか」が追跡しやすい

ACE 試験では、
「サービスアカウントキーを配布せず、開発者に一時的に強い権限を使わせたい」といった設問で
Impersonation + 最小権限ロール の組み合わせが模範解答となることがある。

2.3.6 実務で頻発する落とし穴

サービスアカウントは便利な一方、設計や運用を誤ると
セキュリティインシデントの起点になりやすい。
公式ベストプラクティスや各種事例で繰り返し挙げられる「典型的な失敗」を整理しておく。

落とし穴 1: JSON キーの漏洩

  • キーを GitHub（たとえプライベートリポジトリでも）にコミット
  • チャットツールやメールでそのまま共有
  • アプリケーションバイナリや Docker イメージに埋め込む

などの行為は、
「パスワードをインターネットに貼っているのと同じ」と考えるべきである。

対策のポイント

  • そもそも鍵を使わず、ADC や Workload Identity を優先する
  • やむを得ず JSON キーを使う場合は、Secret Manager や外部の秘密情報管理ツールに保管
  • ソースコードリポジトリに絶対含めない
  • 誤ってコミットした場合は、キーを即時無効化し、履歴も含めて対応

落とし穴 2: デフォルトサービスアカウントへの広すぎる権限付与

Compute Engine などが自動で用意するデフォルトのサービスアカウントに
roles/editor などの広い権限を付与したまま運用するのは、
公式にも「避けるべき」と明記されている。

対策のポイント

  • デフォルト SA ではなく、用途ごとに専用 SA を作成する
  • 各 SA には最小限の Predefined role を付与する
  • 「自動ロール付与を使わない（Don’t use automatic role grants for default service accounts）」というガイドラインに従う

落とし穴 3: Domain-wide Delegation の乱用

Google Workspace 環境では、サービスアカウントに
ドメイン全体の委任（domain-wide delegation） を設定することができる。
これは「組織内のすべてのユーザーのデータにアクセスできる」強力な機能であり、
公式ベストプラクティスでは「必要な場合を除き避けるべき」とされる。

ACE 試験では詳細設定までは問われにくいが、
「非常に強い権限であり、原則避ける」 という認識は持っておきたい。

落とし穴 4: サービスアカウントの乱立と管理不備

  • どの SA が何の用途なのか分からない
  • 使われていない SA が大量に残っている
  • 誰も権限を見直していない

といった状態は、インシデント発生時の調査や監査を困難にする。

対策のポイント

  • 命名規約（用途・環境・システム名を含めるなど）を決める
  • IAM Recommender や監査ログで、未使用 SA や不要な権限を定期的にチェックする

2.3.7 ACE 試験で押さえるべきポイント

サービスアカウントに関して、ACE レベルで確実に押さえておきたいのは次の点である。

  1. サービスアカウントの役割
    • 「アプリケーションやワークロード用の ID」であり、人間ユーザーとは別であること。
  2. 権限付与の基本
    • SA 自体も IAM のプリンシパルであり、
      Predefined role などを用いてリソース階層に対してロール付与すること。
  3. キーの扱いと代替手段
    • 可能な限り JSON キーを使わず、ランタイムの ADC や Workload Identity 連携、Impersonation を使うのがベストプラクティスであること。
  4. 権限借用（Impersonation）の利用場面
    • roles/iam.serviceAccountTokenCreator によって、
      一時的に SA のトークンを発行して権限を借用できること。
  5. 典型的なアンチパターン
    • デフォルト SA に Editor を付けたまま放置する
    • JSON キーをコードリポジトリやチャットに流す
    • Domain-wide Delegation を安易に有効にする

この節の内容は、「アクセスとセキュリティの構成」ドメインだけでなく、
Compute、GKE、Cloud Run、CI/CD といった多くのトピックと密接に関わる。
ACE を目指すうえでは、「誰（どの SA）が、どのロールを持って、どのリソースにアクセスしているのか」 を
常に意識して設計・回答できるようになっておくことが重要である。

2.4 IAM シナリオ問題演習

この節では、IAM の考え方を「シナリオ問題」の形で確認する。
本番試験も、ほとんどがこうしたシナリオ形式の設問になるため、
どのレベルのリソースに・どのロールを・どのプリンシパルへ付与するかを意識しながら読み進めてほしい。

2.4.1 シナリオ1：Basic ロールか、Predefined ロールか

背景

あるプロジェクト marketing-analytics で、マーケティング部門のユーザーに
Cloud Storage バケット内のデータを「閲覧だけ」させたいという要件がある。

  • 対象バケット: gs://mk-data-raw
  • ユーザー: group:marketing@example.com
  • 要件:
    • オブジェクトのダウンロードは必要
    • アップロードや削除、バケット設定変更は不要
    • 他のプロジェクトのリソースにはアクセスさせたくない

設問

次のうち、最小権限の原則を満たす構成として最も適切なものはどれか。

A. プロジェクト marketing-analytics に対して、グループに roles/viewer を付与する
B. プロジェクト marketing-analytics に対して、グループに roles/storage.objectViewer を付与する
C. バケット mk-data-raw に対して、グループに roles/storage.objectViewer を付与する
D. バケット mk-data-raw に対して、グループに roles/storage.admin を付与する

ヒント: Basic ロール（Viewer / Editor / Owner）は、プロジェクト内の多くのサービスに広範な権限を与えるため、本番環境での利用は推奨されていない。
Cloud Storage には、オブジェクト閲覧専用の Predefined ロール roles/storage.objectViewer が用意されている。

解答

C. バケット mk-data-raw に対して、グループに roles/storage.objectViewer を付与する

解説

  • A: roles/viewer は Basic ロールであり、プロジェクト内のほぼすべてのリソースに対して読み取り権限を与える。
    Cloud Storage だけでなく、Compute Engine など他サービスのメタデータにもアクセス可能となるため、最小権限の原則に反する。
  • B: roles/storage.objectViewer 自体は適切だが、プロジェクトレベルで付与すると、そのプロジェクト内のすべてのバケットのオブジェクトを閲覧できる。
    「特定バケットだけ」とする要件を満たしていない。
  • C: バケットレベルで roles/storage.objectViewer を付与すれば、そのバケット内のオブジェクトだけを読み取れる。
    要件を満たしたうえで最小権限に近い構成であり、模範的な設計である。
  • D: roles/storage.admin はオブジェクトの作成・削除、バケット設定変更など広い権限を含むため、明らかに過剰である。

このシナリオは、Basic ロールではなく、サービス固有の Predefined ロールを選ぶという基本方針を確認する典型例である。

2.4.2 シナリオ2：リソース階層と継承の理解

背景

組織 example.com では、次のようなリソース階層を採用している。

  • Organization: example.com
    • Folder: Prod
      • Project: billing-prod
      • Project: app-prod
    • Folder: Dev
      • Project: app-dev

現在、グループ group:auditors@example.com に対して、
Organization レベルで roles/logging.viewer を付与している。

一方、app-dev プロジェクトだけは、監査対象外としたい要件が出てきた。

設問

このとき、「app-dev プロジェクトでは group:auditors@example.com にログ閲覧権限を与えない」状態にしたい。
どのように設定すればよいか。

A. app-dev プロジェクトの IAM から、group:auditors@example.com を削除する
B. app-dev プロジェクトに、roles/logging.viewer を明示的に付与しない
C. app-dev プロジェクトの IAM に、deny ポリシーを設定して roles/logging.viewer を拒否する
D. Organization レベルで付与している roles/logging.viewer を削除し、代わりに Prod フォルダ配下のプロジェクトにだけ付与する

ヒント: IAM ポリシーは、Organization → Folder → Project → リソースの順に上位から下位へ継承される。
子リソースに設定したポリシーは、親が付与した権限を制限（打ち消し）することはできない。

解答

D. Organization レベルでの付与をやめ、Prod フォルダ配下にだけロールを付与し直す

解説

  • A / B: app-dev の IAM ポリシーからエントリを削除しても、上位の Organization で付与したロールは継承され続ける。
    「子のポリシーで親の権限を消せる」というモデルではない。
  • C: Deny ポリシー（IAM Deny）は別の仕組みとして存在するが、
    ACE レベルではまず「Allow ポリシーの継承モデル」で考える問題が中心であり、
    多くのシナリオでは「親で与えたロールを見直す」形が模範解答となる。
  • D: ロール付与の位置を Organization から Prod フォルダに移せば、
    Prod 配下のプロジェクトだけに監査権限が継承され、Dev 配下の app-dev には継承されない。
    これが継承モデルに沿った正しい設計となる。

このシナリオは、「子で親の権限を制限できない」「どのレベルでロールを付与するかが非常に重要」という点を確認する。

2.4.3 シナリオ3：サービスアカウントと人間ユーザー、どちらに権限を付けるか

背景

ある分析アプリケーションが Compute Engine 上で動作しており、
BigQuery のデータセット sales_dataset に対して読み書きする必要がある。

要件:

  • アプリケーションは毎晩バッチ処理を実行し、レポートテーブルを更新する
  • 開発チームのメンバーは、人間のユーザーとしては BigQuery に書き込み権限を持つ必要はない
  • 最小権限の原則を守りたい

設問

次のうち、最も適切な設計はどれか。

A. 開発チームのユーザーに、プロジェクトレベルで roles/bigquery.dataEditor を付与する
B. 開発チームのユーザーに、データセット sales_dataset レベルで roles/bigquery.dataEditor を付与する
C. バッチ処理用サービスアカウントに、データセット sales_dataset レベルで roles/bigquery.dataEditor を付与し、その SA を Compute Engine インスタンスに紐付ける
D. バッチ処理用サービスアカウントに、プロジェクトレベルで roles/editor を付与し、その SA を Compute Engine インスタンスに紐付ける

ヒント: サービスアカウントは「アプリケーションやワークロード用の ID」であり、
人間ユーザーとは別に扱う。権限は人ではなく SA に付与し、最小権限の Predefined ロールを使うのが基本。

解答

C. SA にデータセットレベルで roles/bigquery.dataEditor を付与し、インスタンスに紐付ける

解説

  • A / B: 権限を人間ユーザーに付けてしまうと、誤操作や悪用のリスクが増える。
    また、バッチ処理に必要なのはアプリケーションの権限であり、
    開発者が常に書き込みできる必要はない。
  • C: バッチ処理を実行するのは Compute Engine 上のアプリケーションであり、
    それに紐付いたサービスアカウントに権限を与えるのが最小権限の設計となる。
    BigQuery にはデータセットレベルの Predefined ロール（例: roles/bigquery.dataEditor）が用意されているため、
    それを sales_dataset のみに付与すればよい。
  • D: roles/editor は Basic ロールであり、プロジェクト内の多くのサービスに対して書き込み権限を持つ。
    最小権限の観点から不適切である。

このシナリオでは、
「権限を人に付けるのではなく、サービスアカウントに付ける」 という基本設計を押さえる。

2.4.4 シナリオ4：クロスプロジェクトアクセスとロール付与位置

背景

組織 example.com では、ログを一元管理するために
「ログ集約プロジェクト」と「アプリケーションプロジェクト」を分けている。

  • Project A: app-prod
    • 本番アプリケーションが動作
  • Project B: logs-central
    • Cloud Storage バケット gs://central-logs にログを集約

要件:

  • app-prod から Fluentd（または Cloud Logging sink）を使って
    logs-central のバケットへログファイルを書き込みたい
  • app-prod のアプリケーションからは、logs-central の他リソースへアクセスさせたくない

設問

どのように IAM を設定すべきか。

A. logs-central プロジェクトに対して、app-prod のデフォルトサービスアカウントに roles/editor を付与する
B. central-logs バケットに対して、app-prod のサービスアカウントに roles/storage.objectCreator を付与する
C. app-prod プロジェクトに対して、logs-central のサービスアカウントに roles/storage.objectAdmin を付与する
D. 両プロジェクトに対して、組織レベルで roles/storage.admin を付与する

ヒント: Cloud Storage には、オブジェクト作成のみを許可するロール roles/storage.objectCreator などが用意されている。
IAM は「誰（member）」「どのロール」「どのリソース」に付与するかを組み合わせて考える。

解答

B. central-logs バケットに roles/storage.objectCreator を付与する

解説

  • A: roles/editor は Basic ロールであり、logs-central プロジェクト全体に対して広範な権限を与えてしまう。
    ログ集約用のプロジェクトにこれを付与するのはリスクが高い。
  • B: ログ集約の要件は「バケットに対してオブジェクトを書き込む」ことであり、
    roles/storage.objectCreator はその目的に特化した Predefined ロールである。
    バケット単位で付与すれば、他のリソースへのアクセス権は最低限に抑えられる。
  • C: ロール付与の向きが逆であり、logs-central の SA に app-prod への権限を与えても要件を満たさない。
  • D: 組織レベルで roles/storage.admin を付与するのは最悪に近い設計であり、
    全プロジェクトの Cloud Storage が管理不能なほど広く開放されてしまう。

このシナリオでは、
「どのプロジェクトのどのリソースに対してロールを付与するか」
「クロスプロジェクトの最小権限」
が判断ポイントになる。

2.4.5 シナリオ5：サービスアカウントキーか、Workload Identity か

背景

組織では、オンプレミス環境の CI/CD サーバから Google Cloud のリソースにアクセスし、
デプロイや構成変更を行っている。

現状:

  • オンプレのサーバに、Google Cloud のサービスアカウント JSON キーを置き、
    それを使って認証している
  • セキュリティチームから「長期間有効なキーがサーバに置かれているのはリスクが高い」と指摘された

設問

Google のベストプラクティスに沿って、
キー漏洩リスクを下げるために推奨される解決策はどれか。

A. JSON キーを暗号化して、同じサーバに保存する
B. JSON キーの有効期限を 1 年に設定する
C. Workload Identity Federation を用いて、オンプレの ID プロバイダから短命トークンで認証する
D. サービスアカウントに roles/owner を付与して、権限設定の手間を減らす

ヒント: Google は、「可能な限りユーザー管理のサービスアカウントキーを使わず、
Workload Identity Federation やランタイムの認証機構を使うべき」と明確に推奨している。

解答

C. Workload Identity Federation を用いる

解説

  • A / B: キーを暗号化したり、有効期限を短くしたりしても、
    「サーバに長期の認証情報を置く」という構造自体は変わらない。
    キーの漏洩リスクを根本から解決できていない。
  • C: Workload Identity Federation（WIF）は、外部 IdP と連携し、
    短命トークンベースで Google Cloud にアクセスさせる仕組みである。
    サービスアカウントキーを配布・管理せずに済み、セキュリティと運用性の両方が向上する。
  • D: roles/owner は基本ロールの中で最も強力であり、
    セキュリティリスクを増大させるだけなので論外である。

このシナリオは、
「サービスアカウントキーの扱い」と「より安全な代替手段」としての WIF を理解しているかを確認する。

2.4.6 試験での「IAM シナリオ問題」の見かた

ここまでのシナリオからわかるように、
IAM の問題では、次の 3 点を意識して読むと判断がしやすくなる。

  1. Who（誰に）
    • ユーザーか、グループか、サービスアカウントか
    • 本当に「人」に権限が必要か、それともワークロードに付与すべきか
  2. What（何を）
    • Basic / Predefined / Custom のどの種類のロールか
    • そのロールは過剰ではないか、最小権限になっているか
  3. Where（どこで）
    • Organization / Folder / Project / リソース のどのレベルでロールを付与するのが適切か
    • 継承の結果、どこまで権限が広がるか

IAM のシナリオ問題は、
「この 3 つを一貫した形で満たしている選択肢はどれか」
を探す問題と考えると解きやすくなる。

次の章以降では、Compute・Network など他のドメインでも同じ考え方を応用しながら、
構成判断のトレーニングを進めていく。