この記事を見たとき、自分もIAM ポリシーについて理解がないなと思ったので、2023/06現在の情報として自分が理解できるようにメモしておく

プリンシパルがAWSにアクションなどを実行してよいかをAWSにリクエストを行い、そのアクションの許可・拒否をステップごとに評価していく。

単一アカウントかクロスアカウントなのかで評価倫理が異なる

目次#

• 単一アカウントの場合
• クロスアカウントの場合

単一アカウントの場合#

公式ドキュメントを参照。

条件

• デフォルトでは、フルアクセスを持つ AWS アカウントのルートユーザー 以外は、すべてのリクエストが暗示的に拒否されます。
• アイデンティティベースのポリシーまたはリソースベースのポリシーに明示的な許可が含まれている場合、このデフォルト設定は上書きされます。
• アクセス許可の境界、Organizations SCP、またはセッションポリシーがある場合、この許可は明示的な拒否で上書きされる場合があります。
• ポリシー内の明示的な拒否は、すべての許可に優先します。

フロー

出典は公式より

上の条件3つが言っていることを翻訳すると

1. ルートユーザー以外はポリシーを書かないと基本全て拒否されるよ
2. IAMポリシーとかResource based policyとかでallowがあれば許可されるよ
3. だけどもSCPとかpermission boundary, session policyで拒否があったらそっちを優先するよ

ということ。

上記の条件の中で、resource based policyはリソースにアクセスするプリンシパルのタイプによって評価が異なってくるので注意する

例えば、アクセス許可のリクエストを実行するプリンシパルがIAM Userだった場合、

• Resource based policy … 許可
• Identity based policy … 暗黙拒否
• Permission boudary … 暗黙拒否
• Session Policy … 適用されない
• → Resource based policy でallowなので許可される

とか

session 系のrole(IAM role sessionとかfederated user)とかについては、そのユーザー自身にroleがついていると暗黙拒否で最終評価拒否になるけど、session自体にresource based policyの許可があればAllowされる

クロスアカウントの場合#

公式ドキュメントはこちら

下記の評価を行う。

出典は公式より

見て分かる通り、アカウントAのUserAがアカウントBのBucketBに対してPutObjectするためには、

1. 信頼するアカウントB内のリソースへのリクエストを許可する
2. アカウントBのリソースベースのポリシーで、アカウントAからのアクセスを許可する

が必要になる。

ので、上記を満たすためにやることは

• UserAのIAM ポリシーにBucketBへのPutObject Allowが評価されること
• BucketBのリソースベースポリシーにプリンシパルがUserAからのPutObject Allowが評価されること