Google ACE: リソース階層、IAM、請求管理 — 学習ガイド

By Laurynas Brazys · 31 August 2026 · #google #ACE #certification #exam-prep #study-guide

こちらの一部です： Google Associate Cloud Engineer — 学習ガイド. 検証済みの解答で練習： Google試験ハブ, または時間制限付き模擬試験に挑戦： ExamRoll.io.

概要

リソース階層、Identity and Access Management (IAM)、および請求管理は、Google Cloud運用のコントロールプレーンを形成します。回復力のある設計は、明確な階層（組織、フォルダ、プロジェクト）でポリシーと説明責任の範囲を定め、グループ中心の管理とワークロード用の短期的な認証情報を用いて最小権限のIAMを適用し、コストの帰属のために予算、エクスポート、ラベルを使用し、組織のポリシーと包括的な監査ロギングでガバナンスを強制することから始まります。運用の卓越性は、継承の標準化、請求とログの一元化、そして長期的なキーの代わりにサービスアカウントの権限借用を使用することによってもたらされます。このセクションでは、中心となる構成要素、その意図された使用方法、そして避けるべき一般的な障害モードについて詳述します。

リソース階層とアイデンティティモデル

リソース階層
- 組織: ルートノード。Cloud IdentityまたはGoogle Workspaceで作成されます。グローバルなポリシー（IAM、組織のポリシー、タグ）を所有します。
- フォルダ: 部門、環境（例: dev、prod）、またはアプリケーションのためのオプションのグルーピング。管理の委任やポリシーのスコープ設定に役立ちます。
- プロジェクト: リソース、API、割り当て、IAM、および請求先アカウントの関連付けの管理境界。ほとんどのGoogle Cloudリソースはプロジェクトの子です。
- 継承: IAMポリシーと組織のポリシーはトップダウンで継承されます。上位レベルでの拒否や制約が優先されます。例外や緊急時対応（break-glass）の必要性を最小限に抑えるために、配置（組織 → フォルダ → プロジェクト）を計画します。
プリンシパル
- Googleアカウント（ユーザー）、Googleグループ、サービスアカウント、およびWorkload Identity Federationを介した外部ID。
- ライフサイクルの変更やレビューを簡素化するため、人間のアクセスにはGoogleグループを主要なバインディングターゲットにすべきです。
- サービスアカウントはアプリケーションやサービスを表します。キーよりもワークロードIDを優先します。
ワークロードID
- Google Cloud内: GCE/GAE/Cloud Run/GKEは、メタデータサーバーを使用して、アタッチされたサービスアカウント用の短期的なトークンを生成します。
- Google Cloud外: Workload Identity Federationは、静的なキーなしで外部ID（OIDC/SAML/AWS）をサービスアカウントにマッピングします。
設計上のトレードオフと障害モード
- フォルダ構造のないプロジェクトの乱立は、ポリシーの重複とドリフトを引き起こします。
- ユーザーに直接ロールを付与すると手作業が増加します。グループベースのバインディングを優先します。
- 広範な権限を持つCompute Engineのデフォルトサービスアカウントを使用するとリスクが高まります。ワークロードごとに最小権限のサービスアカウントを作成します。
- プロジェクトを間違ったフォルダの下に配置すると、不適切なポリシーが継承されます。タグを使用するか、変更管理を行いながら慎重にプロジェクトを移動します。

IAMロールとポリシー設計

ロールの種類
- 基本ロール（閲覧者、編集者、オーナー）: 広範でレガシー。厳密に管理された緊急時対応（break-glass）を除き、使用を避けます。
- 事前定義ロール: サービスごとにキュレートされています。ほとんどのユースケースで優先して使用します。
- カスタムロール: 特定のニーズに合わせて、組織またはプロジェクトスコープで権限を集約したもの。
- 条件付きロール: IAM Conditions (CEL)は、リソース名、フォルダ、タグ、時刻などのコンテキストを追加します。強力なロールを制約するために使用します。
ポリシーの原則
- 最小権限: 最も狭いスコープ（リソース/プロジェクト/フォルダ）で、最小限のロールのみを付与します。
- 職務の分離: 職務（例: ネットワーク管理者 vs. セキュリティ管理者 vs. 請求管理者）を分割します。デプロイと承認のアクションを単一のプリンシパルに結合させません。
- 継承の認識: 組織/フォルダレベルでのバインディングはすべての子孫に影響します。適用する前に、意図した影響範囲（blast radius）を文書化します。
拒否ポリシー
- IAM Denyは、他の場所で許可されていても権限を明示的にブロックします。ガードレールとして使用します（例: deny iam.serviceAccountKeys.create）。
- 拒否が優先されます。時間制限のある例外プロセスを備えた、文書化された緊急時対応（break-glass）を確保します。
例
- カスタムロールをdevからprodにコピーする:

undefined

OS Loginを使用してグループベースのSSH管理権限を付与する:

undefined

障害モード
- 組織またはフォルダレベルで付与された編集者ロールが、意図せずすべてのプロジェクトにカスケードします。
- 過度に厳格な条件を持つ条件付きロールは、自動化をサイレントに破壊する可能性があります。展開前にPolicy Troubleshooterでテストします。
- カスタムロールは新しい権限の追加に遅れがちです。定期的にレビューします。

請求とコスト管理

請求先アカウントと関連付け
- 課金対象サービスを利用するには、プロジェクトを1つの請求先アカウントに正確にリンクする必要があります。
- ロール: 請求先アカウント管理者（Billing Account Administrator）はアカウントと支払い方法を管理し、請求先アカウントユーザー（Billing Account User）はプロジェクトをリンクし、プロジェクト請求管理者（Project Billing Manager）はプロジェクトの請求リンクを管理します。
- 企業の請求先アカウントに一元化します。プロジェクトの請求先アカウントの関連付けを更新してプロジェクトを移行します。
予算、アラート、帰属
- 予算はアラートを生成しますが、支出の上限ではありません。強制が必要な場合は、Pub/SubとCloud Functions/Cloud Runを使用してプログラムによる修復を行います。
- 日次/月次のコスト分析と予測のために、請求データをBigQueryにエクスポートします。帰属のためにリソースのラベルやタグと組み合わせます。
- ラベルとタグ: キー（例: cost_center, env, app）を標準化します。ラベルが欠落していると、帰属の精度が低下します。
コスト分析
- BigQueryエクスポートを使用して、SQLでSKU/サービスごとのローリング予測を計算します。詳細なレポート作成のために、リソースメタデータ（例: GCEのラベル）と結合します。
- 複数プロジェクトの分析には、すべてのプロジェクトのエクスポートを集約するか、単一の中央データセットにエクスポートします。
よくある落とし穴
- 新しいプロジェクトに予算が設定されていない。プロジェクト作成時に予算を自動作成するポリシーを確立します。
- BigQueryエクスポートがないと、履歴の洞察が制限されます。履歴を構築するために早期に有効化します。
- プロジェクトに個人のクレジットカードを使用すると、説明責任が断片化します。適切なIAMと支払いプロファイルを使用して、企業の請求先アカウントに統合します。
- 共有サービスプロジェクトでのコストの異常には、タグ付けと部門間請求（cross-charging）ポリシーが必要です。

安全なワークロードの認証とアクセスパターン

サービスアカウントの権限借用
- キーよりも権限借用を優先します。呼び出し元のアイデンティティに roles/iam.serviceAccountTokenCreator を付与します。これにより、呼び出し元はサービスアカウントとして機能するための短期的なトークンを取得できます。
- 例:

undefined

キーとローテーション
- ユーザー管理のキーは避けてください。必要な場合は、Secret Manager に保存し、少なくとも90日ごとにローテーションし、使用状況を監視し、VPC Service Controls と CMEK で制限します。
- 制約を適用してキーの作成をブロックします。

undefined

OS Login と SSH
- グループベースの IAM ロール（compute.osLogin、compute.osAdminLogin）で OS Login を使用します。各ユーザーは、自身の Google アカウントに公開 SSH キーをアップロードして、帰属可能なアクセスを実現します。監査は、管理アクティビティログとデータアクセスログを介して行います。
- イメージに共有 SSH キーを組み込むことは避けてください。
Workload Identity 連携
- オンプレミスや他のクラウド環境では、ID 連携を構成して、キーを作成せずに Google Cloud へのアクセスを許可し、データ漏洩のリスクを低減します。
障害モードと緩和策
- リポジトリや CI/CD 変数にキーを保存すると侵害につながります。権限借用または連携に切り替えてください。
- 広範なロールを持つデフォルトのサービスアカウントは危険です。constraints/iam.allowedPolicyMemberDomains で制限し、基本ロールを削除してください。
- 従来の GCE インスタンスでスコープが欠落していると API アクセスがブロックされる可能性があります。API ごとの IAM とデフォルトのアプリケーション認証情報を使用することを推奨します。

ガバナンス、組織のポリシー、監査、トラブルシューティング

組織のポリシーと制約
- 制約を使用してガードレールを適用: VM の外部 IP の不許可、リージョンの制限、キー作成の防止、許可されるサービスの制限、均一なバケットレベルアクセスの要求、ドメイン共有の制限。
- リソース階層でターゲットを指定し、環境固有の例外についてはタグで調整する。
Cloud Identity とライフサイクル
- Cloud Identity は、ユーザーディレクトリ、SSO、および管理ロールを提供します。権限を限定的に委任し（例: グループ管理者、ユーザー管理管理者）、入社・異動・退職のワークフローを自動化して、グループメンバーシップとアクセス権を更新します。
- 機密性の高い環境では、Access Approvals と Access Transparency を使用します。
監査ロギング
- 管理アクティビティログとシステムイベントログは常に有効です。データアクセスログは明示的に有効にする必要があり、コストが発生する可能性があります。
- フォルダ/組織からの集約シンクをセキュリティプロジェクトにルーティングして一元管理します。CMEK とアクセス制限で保護します。
- Policy Denied ログを監視して、組織のポリシーの競合を検出します。
複数プロジェクトにまたがるトラブルシューティングツールキット
- Policy Troubleshooter: 有効な IAM と拒否ポリシーを考慮して、アクセスが許可または拒否される理由を診断します。
- Cloud Asset Inventory: 組織/フォルダ/プロジェクト全体の IAM バインディングとポリシー履歴をクエリします。例:

undefined

ログエクスプローラ: プリンシパル、メソッド、リソースでフィルタリングして、プロジェクトをまたいだアクションを追跡します。
オペレーターのコンテキスト切り替えのための gcloud 構成:

undefined

一般的な障害モード: 競合する組織ポリシーによるデプロイのブロック、データアクセスログの欠落による調査の妨げ、不適切なスコープで付与された IAM。ランブックと変更前のプレビューを確立して、インシデントの MTTR を削減します。

実践的な問題シナリオ

Aurelia Retail 社は、買収後に複数のチームとプロジェクトを統合します。同社は、請求の一元管理、数百台の Compute Engine VM にわたる一貫した IAM と SSH 管理の徹底、そして最小限の混乱でガバナンスを確立する必要があります。

会社の請求先アカウントを作成し、プロジェクトをリンクする

理由: 単一の請求先アカウントで、支払い方法、クレジット、予算を一元管理します。プロジェクト移行グループに「請求先アカウントのユーザー」ロールを、チームリーダーに「プロジェクトの請求管理者」ロールを付与することで、過剰な権限を与えることなくプロジェクトを再リンクできます。
アクション: コンソールで請求先アカウントを作成します。各プロジェクトについて、その請求先の関連付けを更新します。中央の分析プロジェクトで、BigQuery への請求データのエクスポートを直ちに有効にします。

フォルダとタグでリソース階層を標準化する

理由: プロジェクトを環境フォルダ (prod, nonprod) の下に配置することで、ガードレールの継承とターゲットを絞った例外設定が可能になります。タグを使用すると、フォルダツリーを複製することなく、きめ細かい組織ポリシーのターゲティングが可能になります。
アクション: prod と nonprod 用のフォルダを作成し、それに応じてプロジェクトを移動します。env=prod|nonprod のタグとアプリケーション識別子を定義します。

最小権限と職掌分散を備えたグループベースの IAM を実装する

理由: グループを使用すると、ライフサイクル管理と監査が簡素化されます。デプロイ担当者、セキュリティ管理者、ネットワーク管理者の間でロールを分割することで、影響範囲 (blast radius) を縮小します。
アクション: app-operators、net-admins、sec-admins、billing-managers 用の Google グループを作成します。必要に応じて、フォルダ/プロジェクトスコープで事前定義ロールをバインドし、基本ロールの使用は避けます。

OS Login ベースの SSH 管理を適用する

理由: ユーザーアカウントに紐付けられた個別の SSH キーは、帰属が明確で取り消し可能なアクセスを提供します。OS Login のロールは IAM を介して Linux アカウントを管理するため、共有キーが不要になります。
アクション: 各プロジェクトで OS Login のメタデータを有効にします。ops-admins グループに compute.osAdminLogin を付与します。例:

undefined

サービスアカウントキーを権限借用 (impersonation) に置き換える

理由: 短命な認証情報は、キーの漏洩リスクを軽減し、ローテーションを簡素化します。監査ログには誰が誰の権限を借用したかが記録され、トレーサビリティが向上します。
アクション: ワークロードのサービスアカウントに対して、CI/CD ランナーのアイデンティティに roles/iam.serviceAccountTokenCreator を付与します。ユーザー管理のキーを削除し、新しいキーの作成をブロックする組織ポリシーを適用します。

ガードレールとして組織のポリシーを適用する

理由: 制約により、すべてのプロジェクトでリスクの高い構成を防ぎつつ、正当な理由がある場合はタグ付けされた例外を許可できます。
アクション: 本番環境での外部 IP の不許可、承認されたロケーションへのリージョン制限、サービスアカウントキー作成の無効化といった制約を適用します。文書化された承認がある特定のプロジェクトに対しては、タグを使用して例外を許可します。

コストガバナンスを確立する

理由: 予算は予算超過の前にオーナーに警告を発し、BigQuery エクスポートは費用按分と予測を可能にします。ラベルとタグは、リソースの支出をコストセンターにマッピングします。
アクション: フォルダごと、および主要なアプリケーションごとに、Pub/Sub 通知付きの予算を作成します。デプロイテンプレートと CI でのポリシー検証を通じて、ラベルポリシーを適用します。

監査の一元化とトラブルシューティングの迅速化

理由: 組織全体でのログ集約とアセットインベントリにより、調査とコンプライアンス報告が迅速化します。
アクション: CMEK で保護されたバケットを持つセキュリティプロジェクトへの集約シンクを作成します。重要なサービス (Cloud Storage, BigQuery) のデータアクセスログを有効にします。Cloud Asset Inventory を使用して IAM バインディングを定期的にスキャンします。アクセス失敗時には Policy Troubleshooter を、管理アクティビティ/データアクセスの追跡にはログエクスプローラを使用するようオペレーターをトレーニングします。

プレビューと段階的なロールアウトで変更を運用化する

理由: 適用前に IAM とポリシーの影響を検証することで、サービス停止を削減します。
アクション: まず非本番環境 (nonprod) で IAM と組織のポリシーをテストします。利用可能な場合は、ドライランとポリシーシミュレーションを使用します。デプロイの自動化には、カナリアリリースと切り戻し計画を実装します。

このアプローチにより、請求とコストインサイトの一元管理、OS Login による帰属が明確な SSH 管理、権限借用による最小権限の IAM、組織のポリシーによる強力な予防的統制、そして新しい複数プロジェクト環境全体にわたる堅牢な監査とトラブルシューティングが実現します。

すべてのドメイン · Compute Engine と仮想マシンオペレーション →

これらの問題を練習する → · ExamRoll.ioで時間制限付き練習 →