Google PCA: 組織設計、IAM、クラウドガバナンス — 学習ガイド

By Laurynas Brazys · 5 September 2026 · #google #PCA #certification #exam-prep #study-guide

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

概要

組織設計、IAM、ガバナンスは、すべての Google Cloud アーキテクチャが実行される基盤を確立します。優れた設計は、明確な管理境界を作成し、影響範囲を最小限に抑え、最小権限を有効にし、コストを管理し、多くのチームや環境にわたって運用をスケーリングします。ガバナンスは、ゲートよりもガードレールを重視すべきです。つまり、安全で、測定可能で、元に戻せるデフォルト設定を自動化し、日々の管理はワークロードに最も近いチームに委任します。

リソース階層と ID の基礎

Google Cloud のリソースは、組織 → フォルダ → プロジェクト → リソース（例: Compute Engine インスタンス、バケット）という厳密なツリー構造を形成します。IAM ポリシーと組織のポリシーの制約は、ツリー構造の上から下へと継承されます。

主要な設計原則:

• 単一の組織を使用してガバナンスを集中管理します。主要な管理境界（例: 事業部門、リージョン、規制対象と非規制対象）のために、トップレベルのフォルダを作成します。
• 各境界内に、環境フォルダ（本番、非本番）を作成し、異なるポリシーを適用します。プロジェクトは可能な限りワークロード単位で一時的なものとし、影響範囲を縮小し、チャージバックを容易にします。
• 継承: 許可の付与は累積されます（祖先とノード自体の許可バインディングの和集合）。IAM Deny ポリシーが使用されている場合、それが優先され、許可が存在する場合でもアクセスをブロックできます。ツリーの上位に広範なロールを配置することは避けてください。影響範囲が大きく、元に戻すのが困難になります。

ID ソース:

• Cloud Identity は、ワーカー ID のプレーンです。企業の IdP（SAML/OIDC）と統合して、認証とライフサイクル（入社、異動、退社）を集中管理します。必要に応じて、Google Cloud Directory Sync を使用して属性とグループの同期を行います。
• グループは、IAM の主要なサブジェクトです。グループベースのアクセスにより、スケーラブルな変更と監査可能な所有権が可能になります。グループのグループというパターン（例: net-admins, sec-admins, app-team-A）を使用し、グループのメンバーシップを管理できるユーザーを制限します。
• サービス アカウントは、ワークロードを表します。保存されたキーよりも、短期的な認証情報を使用するサービス アカウントの権限借用を優先します。ユーザー管理のサービス アカウント キーは避け、厳格な承認とローテーションを伴う例外として扱います。
• ワークロード ID のパターン:
  • GKE Workload Identity は、Kubernetes のサービス アカウントを Google のサービス アカウントにバインドし、ノード全体の認証情報を不要にします。
  • Workload Identity Federation は、外部 ID（オンプレミス、他のクラウド、GitHub Actions）がキーなしで短期的な Google アクセス権を取得できるようにします。プール/プロバイダのスコープと属性条件を使用して、アクセスを制約します。

一般的な失敗モードと緩和策:

• フォルダまたは組織レベルで基本ロール（オーナー/編集者/閲覧者）を付与すると、広範囲にわたる過剰な権限につながります。厳密にスコープが限定された非常時用のプロジェクトでのみ使用してください。
• 所有者が不明確なままグループが乱立すると、最小権限が損なわれます。グループには命名規則、目的のタグ、所有者のメタデータを強制します。
• 孤立したサービス アカウントや古いバインディングはリスクを蓄積します。定期的なアクセス レビューを計画し、IAM Recommender を使用して未使用の権限を削減します。

IAM モデル、ロール、アクセス操作

ロールとバインディング:

• 事前定義ロールは、特定のサービス向けにキュレートされており、デフォルトの選択肢とすべきです。
• カスタムロールは、事前定義ロールが大まかすぎる場合のギャップを埋めます。必要と観察された最小限の権限セットから構築し、バージョン管理とテストを行います。
• 基本ロール（閲覧者/編集者/オーナー）はレガシーであり、過度に広範です。組織およびフォルダのスコープでは避けてください。日常業務にオーナーを使用せず、強力な補完的統制を備えたプラットフォームの非常時用に予約しておきます。
• 条件付きロール バインディング（IAM Conditions）は、resource.name、resource.matchTag、request.time、request.auth.audiences などの属性を使用して、バインディングが適用される時期と場所を制約します。期間限定のアクセス、本番環境へのタグベースのアクセス、またはロケーションを制限したアクションに条件を使用します。

最小権限と権限昇格:

• 「読み取り」、「操作」、「管理」の職務を分離します。たとえば、ネットワーク、セキュリティ、アプリの各チームは、それぞれ異なるスコープで異なるロールを取得します。
• Access Approval ワークフローやチケット駆動の自動化を使用してジャストインタイムの権限昇格を行い、条件を介して期間限定のロールをバインドします。

Deny ポリシーと危険性:

• IAM Deny は、危険な権限（例: resourcemanager.projects.delete）を中央でブロックできます。Deny は許可を上書きし、サブツリー全体に適用されます。徹底的に検証してください。設定を誤ると、自動化がロックアウトされたり、デプロイが失敗したりする可能性があります。

可監査性とレビュー:

• 組織レベルで管理者アクティビティ ログを有効にします。これらはデフォルトで 400 日間保持されます。機密性の高いサービスについては、データアクセス ログを有効にし、長期保存と監査のために BigQuery にルーティングします。
• 定期的なアクセス レビューを実施します。Cloud Asset Inventory でバインディングを列挙し、所有権レジストリと比較し、IAM Recommender が提案する未使用のロールを削除し、例外の有効期限を確認します。

役立つ例（期間限定、タグスコープのバインディング）:

• gcloud projects add-iam-policy-binding PROJECT_ID –member=“group:prod-ops@example.com” –role=“roles/compute.instanceAdmin.v1” –condition=‘title=ProdOnlyTemp,expression=resource.matchTag(“organizations/1234567890/env”,“prod”) && request.time < timestamp(“2026-01-01T00:00:00Z”)’

財務ガバナンスと組織のポリシーのガードレール

請求アーキテクチャ：

• 1つ以上の請求アカウントを財務部門の管理下に一元化します。複数の請求アカウントは、法的にまたは運用上必要な場合（例：別法人やリセラーモデル）にのみ使用します。
• プロジェクトと請求アカウントのリンクは自動化を介して行い、承認されたワークフロー外での手動リンクを許可しません。

チャージバックとコストの可視性：

• ラベルとコスト配分タグを一貫して使用します。ラベルはフィルタリングとレポート作成のための自由形式のメタデータです。タグは階層的で、IAM Conditionsやポリシーで使用できます。選択したタグのコスト配分を有効にすると、請求データのエクスポートに表示されるようになります。
• 請求データをBigQueryにエクスポートして分析します。オーナー、コストセンター、環境ごとにダッシュボードを構築します。各プロジェクトに責任のあるオーナーと予算を割り当てることを要求します。

予算と異常検出：

• フォルダおよびプロジェクトレベルでアラート付きの予算を作成します。プログラムによる対応（例：オンコールへの通知、チケットの起票、新規の割り当て増加の無効化）を追加して、想定外の支出を抑制します。
• 予想される使用量に合わせて割り当て（Quotas）と確約利用割引（CUDs）を使用し、その使用率を監視します。

組織のポリシーの制約（セキュア・バイ・デフォルト）：

• 組織またはフォルダレベルでガードレールを適用し、正当な理由がある場合にのみ緩和します。一般的な制約：

undefined

= true

undefined

= true

• VMイメージを制限する

undefined

undefined

= true

undefined

= true

undefined

= true

• 機密性の高い境界（ペリメター）を越える、サポート対象サービスにおけるデータ引き出しリスクを低減するために、VPC Service Controlsを使用します。

ポリシーの例外処理：

• 例外は、リクエスト可能、承認済み、期限付き、かつ監査可能でなければなりません。タグや時間によって例外のスコープを限定するために、IAM Conditionsの使用を推奨します。定期的に例外を調整し、policy-as-codeパイプラインを介して自動的に失効させます。

サービスアカウントキーを無効にする組織のポリシーの例（YAML）：

undefined

spec: rules: - enforce: true 次に適用します：

undefined

ランディングゾーン、共有サービス、自動化、および運用モデル

ランディングゾーン:

• 事前に強化されたベースラインを提供します: 組織のポリシー、ログシンク、CMEK戦略、共有VPC、プライベートDNS、Cloud NAT、Private Service Connect、監査およびセキュリティプロジェクト、制限されたイメージカタログ。
• 共有VPCのために、環境ごとにホストプロジェクトを分離します。ネットワーク管理者がホストプロジェクトを管理し、アプリケーションチームは正しいホストに接続されたサービスプロジェクトにデプロイします。

プロジェクトファクトリ:

• infrastructure-as-codeでプロジェクト作成を自動化します。以下の設定でプロジェクトを定型的に作成します:
  • 正しいフォルダ配置と請求先アカウントへのリンク
  • 事前バインドされたグループとロール
  • デフォルトサービスアカウントの無効化または制限
  • 中央プロジェクトと保持バケットへのログシンク
  • 事前定義された予算、ラベル、タグ
• TerraformモジュールやCloud Config Controllerを使用してファクトリをコード化します。変更を適用する前にCIでポリシー検証を強制します。

共有サービスと分離:

• ID、ネットワーキング、CI/CD、アーティファクトレジストリ、セキュリティツールを専用プロジェクトに集約します。フォルダとVPCで環境を分離し、ファイアウォールポリシー、個別のサービス境界、環境ごとの異なるCloud KMSキーリングでラテラルムーブメントをブロックします。
• Private Service Connectとプロデューサープロジェクトを使用して、パブリックエンドポイントを公開せずに共有サービスをコンシューマーに公開します。

監査ログとガバナンスの自動化:

• 管理者アクティビティログとデータアクセスログを監査プロジェクトにルーティングします。コンプライアンスに準拠したCMEKと保持ポリシーでログバケットを設定します。
• Cloud Asset InventoryのフィードをPub/Subに送り、Cloud Functions/Cloud Runを使用してドリフト（例：公開バケット）を検出し、自動修復またはチケット起票を行います。
• Policy-as-codeスタック:
  • リポジトリに保存されたコードとしての組織のポリシーとIAM
  • KRMリソースのためのConfig Validator/Policy Controller
  • CI/CDでのデプロイ前ポリシーチェック
  • 望ましい状態を再適用するための定期的なリコンサイラージョブ

リソースの命名規則とタグ:

• 環境、アプリ、リージョン、シーケンスをエンコードした、短く読みやすい命名パターン（例：appA-prd-usw2-web-01）を強制します。タグはガバナンス（env=prod, pii=true, owner=team-x）のために予約します。プロジェクト作成時に必須ラベル/タグの存在を検証します。

複数チームでの運用と権限委譲:

• プラットフォーム、セキュリティ、ネットワークの各チームを設立し、明確に定義されたスコープとロールを設定します。プロジェクトレベルの管理は、フォルダの境界内でアプリケーションチームに委譲します。カタログやテンプレートを介して、ガードレール内でのセルフサービスを提供します。
• 影響範囲（blast radius）が小さい決定はチームに委ね、多くのプロジェクトや共有インフラに影響を与える決定は中央集権化することで、自律性とリスクのバランスを取ります。

実践的な問題シナリオ

Contoso Retail社は、3ヶ月以内に8つの製品チームをGoogle Cloudにオンボーディングする計画です。各チームには本番環境と非本番環境、分離されたネットワーク、中央集権化されたセキュリティログ、コストの責任の所在が必要です。プラットフォームチームは、サービスアカウントキーの乱立を防ぎ、VMイメージを制限し、インシデント対応のために時限的な昇格アクセスを有効にする必要があります。

アプローチ:

1. 階層とフォルダを確立する

• 部門ごとのトップレベルフォルダと、本番・非本番用のネストされたフォルダを作成します。理由：明確な管理境界により、組織全体の権限を付与することなく、製品チームへの権限委譲を可能にしながら、対象を絞ったガードレールと予算設定が可能になります。

2. Shared VPCを備えたランディングゾーンをデプロイする

• ネットワークチームが管理する本番・非本番ネットワーク用のホストプロジェクトを作成します。Shared VPCを介してチームのサービスプロジェクトをアタッチします。理由：ルーティング、NAT、ファイアウォールポリシーを一元管理しつつ、プロジェクトごとにワークロードを分離します。これにより、アドホックなネットワーキングによる乱立や一貫性のないセキュリティを防ぎます。

3. 組織のポリシーによるガードレールを実装する

• 制約を強制します：サービスアカウントキー作成の無効化、OS Loginの要求、Cloud SQLのパブリックIPの制限、VMイメージの信頼できるプロジェクトへの制限、均一なバケットレベルアクセスの有効化。理由：デフォルトでセキュアな設定により、頻発する設定ミスを削減します。例外は必要に応じて時限的に許可できます。

4. IDとグループを準備する

• Cloud Identityを企業のIdPと統合します。各チームの開発、運用、管理ペルソナごとのグループと、network-adminsやsec-adminsといったプラットフォームレベルのグループを作成します。理由：グループベースのIAMはスケーラブルであり、職務分離に沿っています。ライフサイクルは人事イベントと連動します。

5. 最小権限と条件付き権限昇格でIAMを定義する

• 事前定義されたロールをフォルダまたはプロジェクトスコープでグループにバインドします。本番タグが付いたリソースに限定され、24時間後に失効する条件付きバインディングを介して、インシデント対応のための権限昇格を有効にします。理由：日常業務は最小権限とし、必要な場合には安全で監査可能なエスカレーションを可能にします。

6. プロジェクトファクトリのパイプラインを構築する

• Terraformモジュールを使用して、必須のラベル/タグ（env, owner, cost-center）を持つプロジェクトを作成し、請求先アカウントをリンクし、正しいShared VPCにアタッチし、中央の監査プロジェクトへのログシンクを作成し、予算を設定します。理由：一貫性がありコンプライアンスに準拠したプロビジョニングを大規模に行うことで、手動によるドリフトをなくし、オンボーディングを迅速化します。

7. 監査ログとアクセスレビューを一元化する

• 管理者アクティビティログとデータアクセスログをCMEK付きでBigQueryにルーティングします。IAMのバインディングを列挙し、IAM Recommenderからのグループ所有権や最終アクセスデータと比較するためのクエリを毎月スケジュール実行します。理由：永続的な監査証跡と継続的なアクセスの適正化により、リスクとコストを削減します。

8. コストガバナンスとアラート

• コスト配分タグとラベルを有効にし、請求データをBigQueryにエクスポートし、財務部門とチームリーダーへの通知付きでフォルダごとおよびプロジェクトごとの予算を設定します。理由：透明性の高いチャージバックは説明責任を促進します。早期のアラートは想定外のコスト増大を抑制します。

9. Workload Identityとキーレスな自動化

• GKEにはWorkload Identityを有効にします。外部CI（GitHub）には、特定のリポジトリにスコープを限定した条件付きのWorkload Identity連携を設定します。理由：長期的なキーを排除し、使用を意図したワークロードに限定します。

10. 例外プロセスと自動化

• CIを介して自動的に失効する条件付きIAMバインディングや一時的なポリシー緩和を作成するリクエストワークフローを実装します。理由：コントロールを犠牲にすることなくチームに権限を与えます。すべての例外は時限的で監査可能です。

技術的な成果:

• チームは15分以内に、コンプライアンスに準拠したデフォルト設定で新しいプロジェクトをセルフサービスで作成できます。
• ユーザー管理のサービスアカウントキーは許可されません。インシデント対応のための権限昇格は時限的で、タグでスコープが限定されます。
• コストはチームと環境ごとに集計され、自動化された予算と異常アラートが設定されます。
• 監査ログとアクセスレビューにより、権限とポリシーが意図通りであることが継続的に検証されます。

すべてのドメイン · コンピュート、アプリケーションプラットフォーム、ワークロードアーキテクチャ →

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

Googleを閲覧 →