AWSの重要なサービスであるIAMですが、簡単なようで奥が深いサービスです。
基本的な仕様はシンプルで理解しやすく個人で利用している場合はそれほど悩むケースはないと思いますが、複数の組織や複数のアカウントで運用を行う場合、つまづく事も多いのでしっかりと基礎を理解しておくことが重要だと思います。
IAMの機能はとても幅広いのですが、今回はIAMポリシーに的を絞って解説します。
IAMポリシーの種類
IAMポリシーは以下の５種類が存在します。
１． アイデンティティベースのポリシー
２． リソースベースのポリシー
３． アクセス許可の境界
４． Organizations SCP
５． アクセスコントロールリスト (ACL)
「１」、「２」が基本的なポリシーでどのシステムでも利用されるものになります。
１つ１つ見ていきます。
アイデンティティベースのポリシー
ユーザー、ユーザーのグループ、ロールに付与できるポリシーです。
「人」に権限を与えるイメージで「誰がどのリソースに対して何を実行できるか」を指定します。一般的な権限管理なので理解しやすいと思います。
「誰が」の部分はIAMではPrincipalで指定するのですが、アイデンティティベースのポリシーの場合は「付与先＝Principal」になるのでポリシードキュメントで記述は不要です。
リソースベースのポリシー
S3やRDSなどのAWSリソースに対して付与するポリシーです。
リソース側から見て「このリソースに対して誰が何を実行できるか」を指定します。
「誰が」はポリシーのPrincipal要素で以下を指定することが可能です。
・AWSアカウント
・ルートユーザー
・IAMロール
・IAMユーザー
・ロールセッション
・フェデレーティッドユーザーセッション
・AWSのサービス
リソースベースポリシーの代表的な例は「S3のバケットポリシー」とIAMロールの信頼ポリシー」です。
ポイント：クロスアカウントアクセス
自アカウント内のリソースに権限を与えたい場合は「アイデンティティベースのポリシー」だけで大丈夫ですが、別のアカウントに対して権限を付与したい場合、「アイデンティティベースのポリシー」に加えて「リソースベースのポリシー」でも権限を与える必要があります。
アクセス許可の境界(Permissions boundary)
アイデンティティベースのポリシーが IAMエンティティに付与できるアクセス許可の上限を設定します。
言葉がややこしいですが、付与できる権限の範囲を制限することが出来るということです。
アイデンティティーポリシーで権限が付与されたとしても、「アクセスの境界範囲」で許可された範囲内でしか権限は付与されないので権限の統制をしたい場合や、誤って不要な権限が付与されるのを防ぎたいような場面で利用します。
Organizations SCP
AWS Organizationsで提供される機能です。
「アクセス許可の境界」と似たような機能ですが、SCPではOrganizationsの機能を利用して、組織単位でポリシーを制御することが出来ます。
ActiveDirectoryのドメインポリシーが近いイメージだと思います。
アクセスコントロールリスト (ACL)
リソースにアクセスできる別アカウントのプリンシパルを制御するポリシーです。
（同じアカウント内のプリンシパルのアクセス権を制御することはできない）
代表的なものはS3バケットのACL、VPCサブネットのACLです。
セッションポリシー
ロールまたはフェデレーティッドユーザーの一時セッションに付与するポリシーです。
例えばユーザー毎にアクセス可能なS3オブジェクトを用意し、ユーザーに関連付けされたS3オブジェクトにのみアクセス許可を与えるようなケースで利用します。
参考資料
ポリシーがどのように評価されるのか？のドキュメントです。
ポリシーの評価論理
クロスアカウントポリシーの評価論理
IAMポリシーのシミュレーターです。
IAM ポリシーシミュレーターを使用した IAM ポリシーのテスト
以上
