クラウド環境のセキュリティにおいて、アクセス権限管理（IAM）は「最後の砦」とも言える最重要コンポーネントです。本記事では、AWS、GCP、Azureの3大クラウドにおけるIAMの設計思想、機能の決定的な違い、そしてプロジェクトの規模や目的に応じた最適な選び方を、エンジニアの視点で詳細に解説します。
1. クラウド3社のIAM：設計思想の根本的な違いを理解する
AWS、Google Cloud（GCP）、Microsoft Azureの3社が提供するIAM（Identity and Access Management）は、いずれも「リソースへのアクセスを制御する」という目的は共通していますが、その設計思想や管理の哲学は驚くほど異なります。この違いを理解せずに設計を進めると、将来的な運用コストの増大やセキュリティホールの発生を招くことになります。
AWS IAM：圧倒的な「細分化」と「柔軟性」
AWSのIAMは、プログラマブルで極めて詳細な設定が可能です。すべての操作権限はJSON形式の「ポリシー」として定義され、リソースごとに「誰が、どのような条件で、何ができるか」を1つずつ積み上げていくスタイルです。
- 特徴: 非常に高い自由度。
- 哲学: 「明示的に許可されていないものはすべて拒否する」というホワイトリスト方式を、極めて細かい粒度で実装することを重視しています。
Google Cloud (GCP) IAM：直感的な「階層構造」と「継承」
GCPのIAMは、Google独自の「リソース階層」という概念に基づいています。組織、フォルダ、プロジェクト、そして個別のリソースという親子関係が明確であり、上位で設定した権限が下位に自動的に引き継がれる仕組みです。
- 特徴: 管理のシンプルさと見通しの良さ。
- 哲学: 「管理の手間を減らし、階層によって自然にガバナンスを効かせる」ことを重視しています。
Azure RBAC：組織構造に寄り添う「エンタープライズ・ガバナンス」
Azureは、Microsoft Entra ID（旧Azure AD）との密接な統合が最大の特徴です。Windows Server時代からのActive Directoryの系譜を継いでおり、企業の組織図（部署、チーム、役職）に基づいた権限管理を得意としています。
- 特徴: 既存の社内ID管理との親和性。
- 哲学: 「企業組織のガバナンスをそのままクラウドへ拡張する」ことを重視しています。
2. AWS IAMの詳細：ポリシーベースの緻密な制御
AWSのIAMを使いこなす鍵は、JSON形式の「IAMポリシー」の理解にあります。
JSONポリシーによる高度な条件定義
AWSでは、Effect (許可/拒否)、Action (操作)、Resource (対象)、そして Condition (条件) を組み合わせて権限を定義します。
例えば、「特定のVPCエンドポイント経由のアクセスのみ許可する」や「MFA（多要素認証）を通していない場合はS3の削除を禁止する」といった、環境変数やコンテキストに依存した動的な制御が可能です。
IAMロールと信頼ポリシー
AWS特有の強力な機能が「IAMロール」です。これはユーザーだけでなく、EC2インスタンスやLambda関数といった「リソース」に対しても権限を付与できる仕組みです。 「信頼ポリシー（Trust Policy）」を設定することで、一時的な認証情報を安全に受け渡すことができ、アクセスキーの漏洩リスクを最小限に抑えることができます。
管理の複雑さとその対策
自由度が高い反面、ポリシーが複雑化しやすく、「結局どの権限が有効なのか」が分かりにくくなる傾向があります。これを補完するために、AWSは「IAM Access Analyzer」や「Policy Simulator」を提供しており、設定ミスによる事故を未然に防ぐ仕組みを整えています。
3. Google Cloud (GCP) IAMの詳細：リソース階層と自動化
GCPのIAMは、Google Workspace（旧G Suite）を利用しているユーザーにとって非常に親しみやすい構造になっています。
リソース階層による権限の継承
GCPの権限管理は以下の階層で行われます。
- 組織 (Organization): 企業全体の設定。
- フォルダ (Folder): 部署や環境（開発・本番）ごとのグルーピング。
- プロジェクト (Project): 課金とリソースの最小単位。
- リソース (Resource): Compute EngineやCloud Storageなど。
上位の「フォルダ」レベルで「閲覧者」権限を付与すれば、その下の100個のプロジェクトに対しても自動的に権限が適用されます。これは、大規模な開発組織において管理コストを劇的に下げる要因となります。
IAM Recommenderによる最小権限の自動化
GCPの特筆すべき機能が「IAM Recommender」です。機械学習を用いて、過去90日間の実際の利用ログを分析し、「このユーザーはこの権限を持っていますが、実際には一度も使っていません。削除を推奨します」といった具体的な提案を行ってくれます。これにより、形骸化しがちな「最小権限の原則」を半自動で維持することが可能です。
サービスアカウントの利便性
GCPでは、プログラム用のアイデンティティである「サービスアカウント」の管理が非常にスムーズです。「Workload Identity」を利用することで、Kubernetes（GKE）上のポッドに対して、個別の秘密鍵を発行することなく安全に権限を付与できるなど、モダンな開発環境に最適化されています。
4. Azure RBACの詳細：Entra IDによる統合管理
AzureのIAM（Role-Based Access Control: RBAC）は、企業のITインフラの一部として機能するように設計されています。
Microsoft Entra IDとの強力な連携
Azureを利用する場合、ID管理の基盤は必ずMicrosoft Entra IDになります。これにより、社内のPCへのログイン、Microsoft 365（Outlook, Teams）の利用、そしてAzureリソースへのアクセスを、たった一つのIDで統合管理できます。社員の入社・退社・異動に伴う権限変更が、ディレクトリ側の操作だけで完結するのは大きなメリットです。
スコープ概念による柔軟な割り当て
Azureでは、権限を割り当てる範囲（スコープ）を明確に選択します。
- 管理グループ: 複数のサブスクリプションをまたぐ管理。
- サブスクリプション: 課金単位での管理。
- リソースグループ: 関連するリソースをまとめた単位。
- リソース: 個別のインスタンスなど。 これにより、「特定のプロジェクトチームには、そのプロジェクトのリソースグループ内でのみフル権限を与える」といった設定が容易に行えます。
特権アクセス管理 (PIM)
エンタープライズにおいて非常に強力なのが「Azure AD Privileged Identity Management (PIM)」です。これは、「常に管理者権限を持っている状態」を廃止し、「必要な時だけ、申請して、承認された時間だけ権限を有効化する」というJIT（Just-In-Time）アクセスを実現します。これにより、管理者アカウントが乗っ取られた際の被害を最小限に抑えることができます。
5. 主要機能の徹底比較表
各社のIAMにおける主要な用語や機能を比較表にまとめました。
| 比較項目 | AWS IAM | Google Cloud (GCP) IAM | Azure RBAC |
|---|---|---|---|
| 基本単位 | ユーザー、グループ、ロール | Googleアカウント、グループ、サービスアカウント | ユーザー、グループ、サービスプリンシパル |
| 権限の定義方法 | JSON形式のポリシー | ロールとメンバーのバインディング | ロール定義とスコープの割り当て |
| 階層構造 | フラット（タグやOUで補完） | 明確な親子階層（組織・フォルダ・プロジェクト） | 階層型（管理グループ・サブスクリプション・リソースグループ） |
| 権限の粒度 | 極めて細かい。APIアクション単位で制御可能。 | 中程度。事前定義ロールの活用が中心。 | 組織的。組み込みロールが豊富で使いやすい。 |
| 一時的権限付与 | STS（Security Token Service）による一時クレデンシャル。 | サービスアカウントの借用（Impersonation）。 | PIMによる時限付きアクティブ化。 |
| 分析・最適化 | Access Analyzer | IAM Recommender | Access Reviews |
| 外部ID連携 | OIDC, SAML 2.0 | Google Workspace, Cloud Identity | Microsoft Entra ID (ネイティブ統合) |
6. 実用的なユースケース別・推奨サービス
どのクラウドのIAMが「最適」かは、プロジェクトの性質や既存のIT資産によって決まります。
ケースA：高い技術力を持ち、セキュリティを極限までカスタマイズしたい
- 推奨: AWS
- 理由: AWSのIAMポリシーは、職人芸のような細かい制御が可能です。例えば、「特定のタグが付いたEC2のみ、特定の時間帯に、特定のIPからだけ再起動を許可する」といった要件にはAWSが最も適しています。TerraformなどのIaC（Infrastructure as Code）を使いこなし、コードで厳密なセキュリティを定義したいチームに向いています。
ケースB：スピード重視のスタートアップや、データ分析基盤を構築したい
- 推奨: GCP
- 理由: GCPのIAMは、学習コストが低く、直感的に操作できます。プロジェクトが増えても階層構造で整理しやすいため、スピード感のある開発現場でも権限管理が破綻しにくいのが特徴です。また、BigQueryなどのデータ関連サービスとの連携もスムーズで、分析担当者に「閲覧だけ」を付与する作業も一瞬で終わります。
ケースC：既にWindows/Microsoft 365環境があり、統制を重視する大企業
- 推奨: Azure
- 理由: 既存のActive Directory資産をそのまま活かせる点は、他社にはない圧倒的なアドバンテージです。人事システムと連動した自動的な権限付与や、PIMによる厳格な特権管理は、監査対応が必要なエンタープライズ企業にとって、運用の安心感を大きく高めてくれます。
7. 失敗しないためのIAM運用・3つの鉄則
どのクラウドを選択したとしても、IAM運用において避けては通れない共通のベストプラクティスがあります。
1. 最小権限の原則 (Principle of Least Privilege)
「とりあえず管理者権限（Administrator/Owner）」を付与するのは、クラウドにおける最大の禁忌です。
- まずは「すべて拒否」の状態からスタートする。
- 業務に必要な最小限の権限だけを、都度追加していく。
- AWSのManaged PolicyやGCPの事前定義ロールをそのまま使うのではなく、必要に応じてカスタムロールを作成し、権限を絞り込む努力が必要です。
2. IDの集約とMFAの徹底
個別のリソースごとにユーザーを作成するのではなく、可能な限りIDプロバイダー（IdP）を統合してください。
- MFA（多要素認証）は必須: 特権を持つアカウントはもちろん、一般ユーザーもMFAを強制する設定を入れましょう。
- アクセスキーの原則廃止: プログラムからのアクセスには、静的なアクセスキーではなく、IAMロールやWorkload Identityなどの一時的な認証情報を利用してください。
3. 定期的な棚卸しと自動分析の活用
「一度付与した権限は二度と消されない」のが運用の常です。
- 各クラウドが提供する分析ツール（IAM RecommenderやAccess Analyzer）を定期的にチェックする。
- 3ヶ月以上使われていないアカウントや権限を自動的に検知し、削除するフローを構築する。
- 「誰が何をしたか」を記録する監査ログ（CloudTrail, Cloud Logging, Azure Monitor）を有効化し、異常な権限使用を検知できるようにしておく。
よくある質問（FAQ）
Q1. IAMの設定を間違えて、自分自身もアクセスできなくなることはありますか？ はい、十分にあり得ます。特にAWSで「Explicit Deny（明示的な拒否）」を広範囲に設定したり、Azureでルートレベルの権限を誤って削除したりすると、管理者であっても締め出される「ロックアウト」が発生します。対策として、必ず「ブレイクグラス・アカウント（緊急用アカウント）」を1つ用意し、通常運用とは別のMFAデバイスで厳重に保管しておくことが推奨されます。
Q2. マルチクラウド環境で、3社のIAMをバラバラに管理するのが大変です。解決策は？ 主に2つのアプローチがあります。1つは、TerraformなどのIaC（Infrastructure as Code）ツールを使用して、3社の設定をコードで一元管理することです。もう1つは、外部のIDプロバイダー（OktaやAzure ADなど）を「信頼できる唯一の情報源（Source of Truth）」とし、各クラウドへフェデレーション（連携）させる構成をとることです。
Q3. IAMの機能自体に利用料金はかかりますか？ 基本的なIAM機能（ユーザー作成、ポリシー割り当てなど）は、3社とも原則無料です。ただし、一部の高度なガバナンス機能（AzureのPIM、AWSの高度なセキュリティ分析ツールなど）は、特定のライセンスプラン（Azure AD Premium P2など）や追加料金が必要になる場合があります。導入前に各社のドキュメントで最新の料金体系を確認しましょう。
関連記事
- 【実践】AWS IAMポリシーの書き方：初心者がハマる「評価論理」の落とし穴
- GCPのベストプラクティス：フォルダ構造とIAM設計で失敗しないためのガイドライン
- ゼロトラストを実現！Azure Entra IDによる「条件付きアクセス」の具体的な設定手順