【PART8 IAMポリシー おまけ1】ぜんぜんわからなかったIAMについてまとめてみました
こんにちはこぐまです。
ぜんぜんわからなかったIAMシリーズ8回目です。
ポリシーは、ただの手紙です。
その手紙の呼び方がたくさんありますが、大きく分けて3種類あります。
①手紙の使用用途での呼び方
②手紙の作り方での呼び方
③手紙を渡す（アタッチする）ときの呼び方
そして、ここまでそのすべてを紹介してきました。
今回は今まで紹介してきた部分と少しかぶるかもしれませんが、
備忘録としても補足しておきたい内容を記載しておきます。
よろしくお願いします。
マニュアルや画面での呼ばれ方について
「①手紙の使用用途での呼び方」
マニュアルではこれが「ポリシータイプ」と呼ばれています。
「ポリシーの一覧画面」では明に確認できる部分はありません。
IAM でのポリシーとアクセス許可
∟ポリシータイプ
「②手紙の作り方の呼び方」
マニュアルでは明に確認できる呼び方はありませんが、「アイデンティティベースのポリシーがAWS管理ポリシー、カスタマー管理ポリシー、インラインポリシーに分類できる」・・という記載があります。
しかし、「リソースベースポリシーはインラインのみ」という記載もあるように、ややふわっとした書き方をしています。
IAM でのポリシーとアクセス許可
∟アイデンティティベースポリシー
∟リソースベースのポリシー
「ポリシーの一覧画面」では管理ポリシーのみ「タイプ」の列に表示されます。「ポリシーの一覧画面」ではインラインポリシーは表示されません。
「①手紙の使用用途での呼び方」を複数利用した場合のアクセスについて
「①手紙の使用用途での呼び方」は6種類ありますが、それらを複数利用した場合に最終的なアクセス許可がどのように評価されるのかを記載します。
以下はすべて、手紙を受け取る相手（プリンシパル）が同一アカウント内であることを前提としています。
１．「アクセス許可の境界」と「アイデンティティベースのポリシー」を両方利用した場合
これは前にも例を挙げて説明しました。2つの共通部分でアクセス許可が決定されます。「アクセス許可の境界」は、権限を実際に与えるのではなく、権限の範囲を決めるので、これは何となくイメージつくかと思います。
逆に言えば共通部分がなければ、アクセス許可はないということになります。
２．「Organizations SCP」と「アイデンティティベースのポリシー」を両方利用した場合
SCPは、所属する組織の親アカウントから行動を許可される範囲を決めるものです。こちらも１と同様に、2つの共通範囲がアクセス許可となります。
これもまあイメージつくかと思います。
３．「リソースベースのポリシー」と「アイデンティティベースのポリシー」を両方利用した場合
この場合は、最低でもどちらか一つにAllowがある場合はOKです。
例えば、あるIAMユーザー「koguma」に「①アイデンティティベースのポリシー」として「②AWS管理ポリシー」である「AmazonEC2FullAccess（EC2全操作可能）」を「③許可ポリシー」としてアタッチします。
一方、「リソースベースのポリシー」として、S3バケットの書き込みを許可する「バケットポリシー」を作成し、プリンシパルとしてIAMユーザ「koguma」を指定します。
IAMユーザー「koguma」は「アイデンティティベースのポリシー」でS3を操作する明示的な許可はついていないけれど、S3のバケットを操作することが許されます。
これがちょっと面白いですよね。
「アイデンティティベースのポリシー」と「リソースベースポリシー」の優先順位というのは特になくて、どちらも対等に評価されます。どちらかでOKされてたらOKです。もちろん言うまでもなく明示的な拒否をされていたら一発アウトです。
４．「リソースベースのポリシー」と「アイデンティティベースのポリシー」と「アクセス許可の境界」と「セッションポリシー」を同時に使用した場合
めっちゃ複雑ですね。
先ほど話したように、「リソースベースポリシー」と「アイデンティティベースのポリシー」だけであれば、どちらかでAllow（許可）があればOKです。
そこに、「アクセス許可の境界」「セッションポリシー」を利用してきた場合はどうなるのか・・という話です。
ポイントは、「手紙を受け取る相手の指定の仕方」です。
つまり、「リソースベースのポリシー作成時のプリンシパルの書き方」によって決まります。
プリンシパルに、「アクセスするためのシステム的な仕組み（道具）」を指定した場合は、許可されます。例えば、「IAMフェデレーテッドユーザ（いわゆる代理人）」がアクセスする場合を考えます。
「手紙を受け取る相手」の指定を
・「IAMフェデレーテッドユーザが接続を試みようとする仕組み（IAMフェデレーテッドユーザセッションといいます）」とするか
・「代理人そのもの（いちIAMユーザー）」とするか
の違いです。前者は許可され、後者は拒否されます。
「アクセス許可の境界」「セッションポリシー」も利用する場合は、何かにアクセスしたいという場合、アクセスしたいと思う「本人」ではなく、アクセスするための「システム的な仕組み（道具）」に対して許可を与える必要があるということですね。
ここはかなり難しい部分ですので、マニュアルの以下の部分も参考にしていただけるといいかもしれません。
ポリシーの評価論理
∟アカウント内でのリクエストの許可または拒否の決定
∟３．リソースベースのポリシー
最終的に何が言いたいかというと、
「アクセス許可の境界」「セッションポリシー」も利用する場合は、「アイデンティティベースのポリシー」と「リソースベースのポリシー」のいずれかでアクセスが許可されていても、「手紙を受け取る相手」として「システム的に実際にアクセスする仕組みを作る道具」を指定しないと、「アクセス許可の境界」「セッションポリシー」の暗黙的な拒否で最終的に拒否されてしまうということです。・・長い(笑)
つまり逆にいうと、「システム的に実際にアクセスする仕組みを作る道具」を指定している場合は、「アクセス許可の境界」や「セッションポリシー」の暗黙的な拒否は無視されるということです。（※）
（※）マニュアルの以下の場所にも記載があります。
https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/access_policies_boundaries.html
境界を設定した場合の有効なアクセス許可の評価
∟リソースベースのポリシー
おまけ１は以上です。
おまけ２はここまでの練習問題チックなものを考えてみます！
読んで下さってありがとうございました！
この記事が気に入ったらサポートをしてみませんか？