Contents
この記事に書いていること
- リソースベースポリシーつけたとき結局権限どうなるっけ..?
- リソースベースポリシーの暗黙的な挙動
公式ドキュメントに書いてありますが、理解含めて紹介します。
https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/reference_policies_evaluation-logic.html
アイデンティティーポリシーとリソースベースポリシーどっちが使われる?
IAMユーザが例えばS3を操作することを想定します。
その場合IAMユーザにもS3関連の権限付与できますし、S3側にもIAMユーザをプリンシパルとして権限付与できます。
その場合どちらの権限が使用されるのでしょうか?
上記の絵がすべて物語っているんですが、リソースベースのポリシーとアイデンティティーベースのポリシーどちらでも許可されている操作が最終的に実行可能な操作となります。
クロスアカウントを考えるとイメージしやすいかもしれません。
例えば以下の要件があったとします。
- S3がアカウントAにあったとして、アカウントBの人にもフルアクセスを許可したい
- アカウントBの誰にどう使わせるかはアカウントBの管理者に任せたい
- アカウントBの管理者はアカウントBのTくんに読み込み権限を付与したい
この要件を満たすには以下の対応をすればよいです。
- アカウントAのS3にリソースベースポリシーをつけ、アカウントBをプリンシパルに設定し、フルアクセスを許可
- アカウントB側で、アカウントBのIAMユーザTくんにアイデンティティーベースポリシーをつけ、アカウントAのS3に対してRead権限を付与
結果、このTくんはアカウントAのS3をReadだけすることができますが、書き込みはできません。
つまり2つのポリシーの共通部分が適用されることになります。
実際には
実際にはポリシーベースポリシーとアイデンティティーポリシーだけでなくSCPなどいろんなポリシーを総合して最終的な判断がなされます。ですがこの記事ではリソースベースポリシーとアイデンティティーベースポリシーだけに絞って書いています。
リソースベースポリシーの暗黙的動作
AWSではポリシーは基本的に暗黙的Denyですが、リソースベースポリシーとしては許可(Pass)となるのはどういったときでしょうか?
公式ドキュメントに書いてありました。
リソースベースのポリシー – リクエストされたリソースに、リクエストされたアクションを実行することをプリンシパルに許可するリソースベースのポリシーが含まれている場合は、コードは許可の最終決定を返します。リソースベースのポリシーがない場合、またはポリシーに
Allow
ステートメントが含まれていない場合は、コードが続行されます。注記:
IAM ロールまたはユーザーの ARN をリソースベースのポリシーのプリンシパルとして指定した場合、このロジックは異なる動作をする可能性があります。ロールを引き受けるか、ユーザーをフェデレートすると、セッションが生成されます。その場合、リソースベースのポリシーによって付与された有効なアクセス許可は、そのプリンシパルのアクセス許可境界またはセッションポリシーによって制限されます。引き受けられたロールセッションまたはフェデレーティッドユーザーセッションについての効果的なアクセス許可の詳細については、「セッションポリシー」および「境界を使用した有効なアクセス許可の評価」を参照してください。
https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/reference_policies_evaluation-logic.html
今回の場合まとめるとこういうことです
許可(または続行)になるとき
- リソースベースポリシーがなかった場合
- Allowステートメントにマッチした場合
- Denyステートメントにマッチしなかった場合
拒否されるとき
- Denyステートメントにマッチした場合
つまり暗黙的動作は”続行”です。他のポリシーに依存する形になります。
まとめ
- リソースベースポリシーとアイデンティティーベースポリシーの重複部分が実際に実行できる権限
- リソースベースポリシーの暗黙的動作は”続行”