AWS vs GCP vs Azure: 組織階層、IAM、キー管理を徹底比較

1つのクラウドのガバナンスモデルを知っていれば、他の2つの80%を知っていることになります。概念は同じで、語彙が変わるだけだからです。どのクラウドでも、何かを実際にデプロイする前に、同じ3つの問いに答えなければなりません。それは、アカウントをどのように整理するか、誰に何をする権限を与えるか、そして暗号化キーをどのように作成し制御するか、です。この記事では、AWS、Google Cloud、Azureを1層ずつ相互にマッピングし、このアナロジーが静かに破綻する4つの箇所を指摘します。

これらの4つのレイヤー-階層、ガードレール、ID、およびキー管理-は、すべてのクラウドアーキテクチャおよびセキュリティ試験の基盤でもあります。したがって、クロスクラウドの混乱から1週間を節約できるのと同じ読書が、認定資格のシラバスの大部分を占めています。各レイヤーを掘り下げる認定資格は最後にリンクされています。

すべてのクラウドが解決する3つの問題

マーケティングを取り除けば、すべてのガバナンスに関する議論は、互いに積み重ねられた3つのレイヤーで構成されています。

• 構造 - 環境を隔離し、ガードレールを適用し、請求を分割できるようにするための、ネストされたコンテナセット（組織 → グループ化 → ワークロード境界）。
• IDと権限 - どのプリンシパルがどのリソースに対してどの操作を実行できるか、およびどの付与も決して与えることができない上限を定める天井。
• キー管理 - 暗号化キーがどこに存在し、誰がそれらを使用でき、誰がそれらを管理できるか - 人々が常に混同する2つの異なる質問。

ほとんどのエンジニアは、最もよく知っているクラウドの要素をリストアップできます。難しいのは全体像、つまり忘れがちなレイヤー、そして各要素が他の2つのクラウドにどのように変換されるかです。

レイヤー1 - リソース階層

各クラウドには、トップレベルの組織ノード、部署や環境のためにネストできるオプションの中間グループ化レイヤー、および課金とブラスト半径の単位としても機能するワークロード境界があります。上位で設定されたポリシーは、3つすべてで下位に流れます。

• 組織のルート - AWS: 管理アカウントを持つ Organization。 GCP: organization node。 Azure: Microsoft Entra テナントによって裏付けられたテナントルート management group。
• グループ化コンテナ（ネスト可能） - AWS: Organizational Unit (OU)。 GCP: folder。 Azure: management group。
• ワークロードと課金の境界 - AWS: account。 GCP: project。 Azure: subscription。
• 境界内のリソースグループ化 - AWS: なし（タグ、またはアカウントごと）。 GCP: なし - project がコンテナです。 Azure: リソースグループ。これは必須であり、すべてのリソースはちょうど1つのリソースグループに存在します。

最初の真の相違点はここに隠されています。AWSでは、アカウントは厳格な境界 - ブラスト半径のデフォルトの単位 - であり、成熟したAWS環境が数十または数百のアカウントを運用する理由です。GCPでは、projectが2つのジョブを同時に行います。グループ化単位と課金/分離単位の両方であるため、個別の「リソースグループ」の概念はありません。Azureは、他のクラウドにはない第4レベル - リソースグループ - を追加し、subscriptionの下に配置して、単位としてデプロイおよび破棄するライフサイクルコンテナとして機能します。

レイヤー2 - 予防的ガードレール（権限の上限）

誰かに何も付与する前に、各クラウドでは、ノードの下に存在する可能性のある権限の上限、つまり個々の付与では突破できない天井を設定できます。これはアクセスを付与することと同じではありません。これは「組織全体で決して許可しない」レイヤーです。

• プリンシパルができることの上限 - AWS: Service Control Policy (SCP)。 GCP: Organization Policy の制約と IAM 拒否ポリシー。 Azure: Azure Policy。
• リソースに触れることができるユーザーの上限 - AWS: Resource Control Policy (RCP)。 GCP: リソースに対する IAM 許可/拒否ポリシー。 Azure: Azure Policy と拒否割り当て。
• サービス構成の強制 - AWS: 宣言型ポリシー。 GCP: Organization Policy の制約。 Azure: Azure Policy (deny / audit / deployIfNotExists)。

AWSはこのジョブを2つに分割しました。SCPはプリンシパル中心（「私たちのメンバーはXを行うことはできない」）であり、新しいRCPはリソース中心（「組織内にいない限り、外部アカウントであっても、このS3バケット、KMSキー、またはロールに触れることはできない」）です。これらを一緒に使用することで、どちらか一方だけではカバーできないギャップを埋めます。注意点: AWSとGCPでは、SCPまたはOrg Policyは何も許可しません - 単に権限を減らすだけです。Azureは異なる仕組みになっており、**RBAC（権限）とAzure Policy（コンプライアンスと構成）**を明確に分離しているため、ガードレールのジョブは主にAzure Policyに属し、「誰が何をできるか」は完全にRBACに属します。

レイヤー3 - IDと権限

すべてのクラウドは、プリンシパル、ロール（権限の束）、およびスコープという同じ3つの要素で付与を表現しますが、その要素の組み立て方は異なります。

• IDディレクトリ - AWS: IAM と IAM Identity Center (SSO)。 GCP: Cloud Identity / Google Workspace と IAM。 Azure: Microsoft Entra ID。
• 権限バンドル（「ロール」） - AWS: IAM ポリシー（マネージドまたはインライン）。 GCP: IAM ロール（基本、事前定義、またはカスタム）。 Azure: RBAC ロール定義（組み込みまたはカスタム）。
• 付与自体 - AWS: ユーザー、グループ、またはロールにアタッチされたポリシー。 GCP: リソースに対する IAM バインディング（メンバー + ロール、オプションで条件）。 Azure: ロール割り当て（プリンシパル + ロール + スコープ）。
• 条件と明示的な拒否 - AWS: IAM 条件キーと明示的な Deny。 GCP: IAM Conditions と拒否ポリシー。 Azure: RBAC 条件と拒否割り当て。

最も深い違いは、付与がどこに存在するのかです。AWSでは、ポリシーを主にID（ロールまたはユーザー）にアタッチし、権限はそれらとともに移動します。GCPでは、許可ポリシーはリソースにアタッチされます。つまり、プリンシパルPにリソースXでのロールRを付与し、それが階層を継承して下位に伝播します。Azureのロール割り当てはGCPのバインディングに似ていますが、管理グループ → サブスクリプション → リソースグループ → リソースチェーン内のスコープに紐付けられます。「AWS = IDにアタッチ、GCPとAzure = リソース/スコープにアタッチ」を理解すれば、多くのクロスクラウドの混乱が解消されます。

レイヤー3b - ワークロードID（忘れられがちな部分）

人間だけがプリンシパルではありません。コードにもIDが必要です。これを正しく設定することは、最小特権を実現するための最大のテコ入れとなります。どこでも共通の黄金律は、長期間有効な静的キーをデプロイしないことです - 代わりに、マネージドIDをワークロードにアタッチします。

• 実行中のワークロードのID - AWS: IAM ロール（インスタンスプロファイル、タスクロール、または OIDC 経由で引き受けられる）。 GCP: リソースにアタッチされたサービスアカウント。 Azure: マネージドID（システム割り当てまたはユーザー割り当て）。
• アプリケーション / 非人間プリンシパル - AWS: IAM ロール。 GCP: サービスアカウント。 Azure: サービスプリンシパル。
• クラウド外部からのキーレス信頼 - AWS: OIDC/SAML フェデレーションによる IAM ロール。 GCP: Workload Identity Federation。 Azure: ワークロードIDフェデレーション。

皆を戸惑わせる命名の重複に注意してください。AWSの「IAM ロール」は、引き受けるワークロードIDであるのに対し、GCPとAzureの「ロール」は単なる権限バンドルであり、IDはサービスアカウントまたはマネージドIDです。同じ言葉でも、2つの異なる役割があります。GCPのサービスアカウントキーとAzureのサービスプリンシパルシークレットはまだ存在しますが、どちらのクラウドも、ペリメーター外で実行されるものにはキーレスフェデレーションを強く推奨しています。

レイヤー4 - キー管理

最後に、暗号化です。各クラウドにはマネージドキーサービスがあり、キーを小さな階層で整理し、そして-決定的に重要なことですが-キーの使用（暗号化/復号化）をキーの管理（ローテーション、無効化、ポリシー設定）と分離しています。

• サービス - AWS: KMS、専用ハードウェア向けに CloudHSM。 GCP: Cloud KMS、Cloud HSM / 外部。 Azure: Key Vault、専用ハードウェア向けに Managed HSM。
• キーの構成 - AWS: KMS キー (CMK)、エイリアス、マルチリージョンキー。 GCP: キーリング → キー → キーバージョン。 Azure: ボールト → キー / シークレット / 証明書。
• アクセス制御 - AWS: キーポリシー + 付与 + IAM (これら3つすべてが組み合わされる)。 GCP: プロジェクト、キーリング、またはキーレベルでの Cloud KMS IAM バインディング。 Azure: デフォルトでは RBAC、またはレガシーなボールトごとのアクセスポリシー。Managed HSM は独自のローカル RBAC を使用します。
• 使用 vs 管理の分離 - AWS: 暗号化/復号化アクション vs キー管理アクション。 GCP: cryptoKeyEncrypterDecrypter vs admin ロール。 Azure: 「Crypto User」vs「Crypto Officer」スタイルのロール。

知っておくべき現在の問題点: 最新のAPIバージョンを持つ新しい Key Vault では、Azure RBAC がデフォルトのアクセスモデルとなり、古いボールトごとのアクセスポリシーはレガシーパスとなっています。これにより、Key Vault はようやくAzureの他の部分が権限を扱う方法と連携します。AWSは依然として異端です。KMSキーのキーポリシーは権限を持ち、IAMとは独立してアクセスを付与できるため、典型的なAWSの落とし穴は、キーポリシーを忘れてIAMを編集することで、キーから締め出されてしまうことです。GCPでは、KMSアクセスは他のすべてと同様にプレーンなIAMです。

メンタルモデルが破綻する場所

きれいにマッピングされたものが、文字通り信頼しすぎると危険です。アナロジーが漏れる4つの場所を挙げます。

• 「IAM ロール」は2つの異なる意味を持つ。 AWSでは、それは引き受け可能なIDであり、GCPとAzureでは、「ロール」は単なる権限セットであり、IDは分離されています。文字通りに翻訳してはいけません。
• AWSはIDに権限をアタッチし、GCPとAzureはリソースとスコープに権限をアタッチする。 クラウドを切り替えるとき、「どこを見てアクセスを監査するのか？」という直感を切り替える必要があります。
• アカウント、プロジェクト、サブスクリプションは同じブラスト半径ではない。 AWSアカウントは厳格な境界であり、GCPプロジェクトは境界、請求、グループ化を兼ね備えており、Azureサブスクリプションは主に請求とスケールの境界であり、リソースグループが日々のライフサイクルを処理します。
• ガードレールは減算、付与は加算 - ただしAzureは仕事を分割する。 SCPとOrg Policyは常に権限に上限を設けるだけであり、Azureはポリシーを介して上限を設け、RBACを介して付与するという2つの別々のシステムでこれを行います。

3つのクラウドすべてに共通する原則は同じです。構造によって強制される最小特権です。ガードレールを上位（組織、OU、フォルダー、管理グループ）に配置し、狭い範囲で付与し、静的キーよりもロールを優先し、「キーを使用できる」ことと「キーを管理できる」ことを分離します。クラウド間で名前は変わりますが、規律は変わりません。

実践的なヒント

• 最初のワークロードの前に階層を設計する。 後からアカウント、プロジェクト、またはサブスクリプションを改造することは、どのクラウドでも困難です。
• 上限は高く設定し、付与は低くする。 最上位にSCP/RCP、Org Policy、またはAzure Policyを設定し、機能する最も狭いスコープで特定のロールを付与します。
• マネージドIDをデフォルトとする。 AWSのIAMロール、GCPのサービスアカウント、AzureのマネージドID - そしてクラウド境界を越えるものにはキーレスフェデレーションを使用します。
• キー管理を特権として扱う。 暗号化/復号化と、ローテーション/無効化/ポリシー設定を分離し、AWSではIAMだけでなく常にキーポリシーも確認してください。
• Terraform または OpenTofu を使用する場合、これらのプリミティブはまさにコード化する対象となります - aws_organizations_*、google_folder、azurerm_management_group、およびそれらの下にあるIAM/RBACおよびKMSリソースです。

各レイヤーをクラウドごとに掘り下げる

すべてのクラウドのアーキテクチャおよびセキュリティ認定資格は、リソース階層、IAM/RBAC、およびキー管理に基づいて構築されています。実際の試験問題でこれらを練習したい場合は、CertLabProがそれぞれにコースを提供しています。

• AWS - 階層とIAMについてはSolutions Architect Associate (SAA-C03)、SCP、RCP、KMSについてはSecurity Specialty (SCS-C03)。AWS初心者ですか？Cloud Practitioner (CLF-C02)から始めましょう。
• Google Cloud - 組織、フォルダー、プロジェクト、およびIAMについてはProfessional Cloud Architect、IAM 拒否ポリシー、Org Policy、および Cloud KMS についてはProfessional Cloud Security Engineer。
• Azure - 管理グループとガバナンスについてはSolutions Architect Expert (AZ-305)、RBAC、Azure Policy、および Key Vault についてはSecurity Engineer (AZ-500)。Azure初心者ですか？Azure Fundamentals (AZ-900)から始めましょう。

まとめ

AWS、Google Cloud、Azureは、そのドキュメントが感じさせるほど異なっていません。それぞれが、アカウントを整理するための階層、プリンシパル-ロール-スコープに基づいて構築されたIDモデル、存在する可能性のある権限に上限を設けるガードレールレイヤー、およびキーの使用と管理を分離するキーサービスを提供します。4つのレイヤーを一度学べば、クロスクラウド翻訳はほとんど語彙の問題になります - そして、アナロジーが漏れる4つの場所を学べば、語彙が隠す間違いを回避できます。これらの基礎は、CertLabProの問題集が3つのクラウドすべてで掘り下げるように構築されているものです。