AWS IAM のきめ細かいアクセス制御 - ポリシーベース設計が実現する最小権限の原則
AWS IAM のポリシーベースアクセス制御の設計思想を解説し、Azure RBAC や GCP IAM との粒度の違いを具体的に比較します。
ポリシーベース設計という根本思想
AWS IAM の最大の特徴は、アクセス制御をポリシードキュメントとして JSON で記述する設計にあります。ポリシーは Effect (Allow/Deny)、Action (操作)、Resource (対象リソース)、Condition (条件) の 4 要素で構成され、この組み合わせにより極めて細かい粒度の制御が可能です。たとえば「特定の S3 バケット内の特定プレフィックスのオブジェクトに対して、特定の IP アドレスからのみ GetObject を許可する」といった制御を 1 つのポリシーステートメントで表現できます。この設計思想は AWS の創業初期から一貫しており、サービスが 200 を超えた現在でも同じポリシー言語で統一的に制御できます。ポリシーがコードとして管理できるため、Git でのバージョン管理、コードレビュー、CI/CD パイプラインでの自動検証が自然に組み込めます。
条件キーによる文脈依存の制御
AWS IAM の粒度を決定的に高めているのが Condition 要素です。グローバル条件キーとサービス固有の条件キーを組み合わせることで、単純なリソースレベルの制御を超えた文脈依存のアクセス制御が実現します。たとえば aws:SourceIp で送信元 IP を制限し、aws:RequestedRegion で操作可能なリージョンを限定し、aws:PrincipalTag でタグベースのアクセス制御 (ABAC) を適用できます。ABAC は特に大規模組織で威力を発揮します。プロジェクトタグが一致するリソースにのみアクセスを許可するポリシーを 1 つ作成すれば、新しいプロジェクトが追加されてもポリシーの変更は不要です。タグの付与だけでアクセス範囲が自動的に制御されるため、数百のプロジェクトを抱える組織でもポリシーの爆発的増加を防げます。さらに aws:MultiFactorAuthPresent で MFA 認証済みセッションのみに特権操作を許可するといった多層防御も条件キーで実装できます。
Azure RBAC との粒度の違い
Azure のアクセス制御は RBAC (Role-Based Access Control) を基盤としています。Azure RBAC ではロール定義をスコープ (管理グループ、サブスクリプション、リソースグループ、リソース) に割り当てる方式で、ロールには Actions と NotActions でアクション一覧を定義します。AWS IAM との最大の違いは、条件ベースの制御の柔軟性です。Azure も条件付きロール割り当て (ABAC) を 2022 年に GA しましたが、対応するリソースタイプが Storage Blob や Key Vault など一部に限定されています。AWS の条件キーがほぼ全サービスで利用可能なのに対し、Azure の条件式は対応範囲が狭く、サービスごとに使える条件属性が異なります。また、Azure ではカスタムロールの作成に上限があり (サブスクリプションあたり 5,000)、大規模環境ではロール管理の複雑さが課題になります。一方で Azure の強みは、Entra ID (旧 Azure AD) との統合による条件付きアクセスポリシーで、デバイスの状態やリスクレベルに基づくアクセス制御が得意です。
GCP IAM との設計アプローチの差異
GCP IAM はロールベースのアクセス制御を採用しており、事前定義ロール、カスタムロール、基本ロールの 3 種類があります。GCP の事前定義ロールは各サービスに対して細かく用意されていますが、AWS のようにポリシードキュメントで任意の条件を組み合わせる柔軟性には及びません。GCP IAM の条件式は CEL (Common Expression Language) で記述しますが、対応する属性が限定的で、リソースタグベースの ABAC は 2023 年にプレビューとして導入されたばかりです。GCP の特徴的な仕組みとして IAM Deny ポリシーがあり、組織階層の上位で特定の操作を明示的に拒否できます。AWS でも SCP (Service Control Policies) で同様の制御が可能ですが、SCP は Organizations の機能であり IAM ポリシーとは別レイヤーです。GCP はリソース階層 (組織、フォルダ、プロジェクト) に沿った IAM の継承モデルが明快で、この点は管理のシンプルさにつながっています。ただし、AWS の Condition キーが提供する文脈依存の制御粒度は、GCP では再現が難しい領域です。
最小権限を実現する実践的なアプローチ
最小権限の原則を理論で終わらせず実装に落とし込むには、AWS が提供するツール群の活用が鍵です。IAM Access Analyzer は CloudTrail のログを分析し、実際に使用されたアクションのみを含むポリシーを自動生成します。過剰な権限を付与した状態で運用を開始し、一定期間後に Access Analyzer で実使用に基づくポリシーに絞り込む手法は、最小権限への現実的なパスです。IAM Policy Simulator はポリシーの評価結果を事前にテストでき、本番適用前に意図しないアクセス拒否がないか検証できます。Organizations の SCP でアカウント単位の権限境界を設定し、IAM のパーミッションバウンダリーでロール単位の上限を定め、リソースベースポリシーでリソース側からもアクセスを制御する多層構造が、AWS IAM の真価です。IAM の設計パターンを体系的に学ぶなら、関連書籍 (Amazon) も参考になります。
まとめ
AWS IAM のポリシーベース設計は、Action、Resource、Condition の組み合わせにより、他のクラウドプラットフォームでは実現が難しい粒度のアクセス制御を可能にしています。Azure RBAC はロール割り当てモデルの明快さに強みがありますが、条件ベースの制御範囲が限定的です。GCP IAM はリソース階層の継承モデルがシンプルですが、ABAC の成熟度で AWS に後れを取っています。最小権限の原則を実務で実現するには、Access Analyzer によるポリシー自動生成、SCP による組織レベルの境界設定、パーミッションバウンダリーによるロール単位の制限を組み合わせた多層防御が有効です。アクセス制御の粒度は、セキュリティインシデント発生時の影響範囲を直接左右するため、クラウド選定における重要な評価軸です。