【PART3 IAMグループ】ぜんぜんわからなかったIAMについてまとめてみました
こんにちはこぐまです。
ぜんぜんわからなかったIAMシリーズ3回目です。
前回は「IAMユーザー」と「ルートユーザー」の違いについてお話ししました。「IAMユーザー」は「ルートユーザー」と異なり、たくさん作ることができるという話をしました。
今回は「IAMグループ」についてお話していきます。
「IAMグループ」とは
IAMグループとは簡単に言うと「IAMユーザーをまとめたもの」となります。
例えば、
IAMユーザー「koguma」
IAMユーザー「ookami」
IAMユーザー「koyagi」
みたいに3人分のIAMユーザーを作ったとして、それぞれに同じ権限を与える（例えばEC2に関連する情報を参照できるという権限）という状況を考えた場合、以下2つの方法があります。
【方法１】一人一人ににその権限を直接付与する
【方法２】「IAMグループ」にその権限を付与し、3人をそのグループに所属させ、間接的に権限を付与する。
3人くらいなら別にどっちの方法でもいいですが、これが10人20人・・となる場合、【方法１】のように一つ一つのIAMユーザーに設定していくのは大変ですね。また、付け忘れなどのミスも発生しそうです。
そこで【方法２】のように「IAMグループ」を利用してまとめて権限を付けちゃおうという作戦です。「IAMグループ」の存在意義はここにあります。
「IAMグループ」はマニュアルでは「IAMユーザグループ」と表記されています。またAWSのIAMの画面では、以下のように「User groups」と英語表記されています。（昔ここグループって書いてあった気がするんだけど・・）
「IAMグループ」についての制約
以下、IAMグループについての代表的なきまりを記載します。
① 最初は一つも存在していません。グループは作成する必要があります。
② グループの入れ子（親グループ→子グループ）はできません。（下図参照）
③ 「IAMユーザー」は複数のグループに参加できます。（下図参照）
④ リソースベースのポリシーは、「Principal」にグループを指定できません。
⑤ グループにアタッチできるポリシーは「アクセス許可ポリシー」です。これには、「管理ポリシー」と「インラインポリシー」が利用できます。
④⑤については、現時点で何のことかわからなくても大丈夫です。
②③については大事なことなので図示します。
いずれにせよ、IAMユーザーの権限をまとめて管理するためにIAMグループという考えかたがあるということを理解いただければ大丈夫です。
相反する権限ーポリシーの評価論理
さて、ここで一つ、面白いことをしてみましょう。
前の決まりの③の通り、「IAMユーザー」は「複数のIAMグループ」に所属できます。例えば、あるIAMユーザ「koguma」が、2つのIAMグループ（GroupA, GroupB）に所属しているとします。
GroupAには、「EC2の一覧表示を許可するポリシー」がアタッチされているとします。
GroupBには、「EC2の一覧表示を禁止するポリシー」がアタッチされているとします。この時、IAMユーザ「koguma」はEC2の一覧を表示できるのでしょうか？
答えは「No」です。
AWSには権限の優先順位があります。（これを「ポリシーの評価論理」と言います。）優先順位は以下の通りです。
①明示的な拒否 ＞ ②明示的な許可 ＞ ③暗黙的な拒否（デフォルト）
何はともあれ、「明示的な拒否（ダメ、絶対！）」が一番強いです。
そして、何も記載がない場合は「暗黙的な拒否（基本ダメ）」です。
つまり、「何かを見たい、変更したい」という権限を持つためには、必ず「②明示的な許可」を記載する必要があるということです。
「②明示的な許可」があり、「①明示的な拒否」がない場合は、その行動は許されます。
「②明示的な許可」があり、「①明示的な拒否」がある場合は、②が①で上書きされるので、その行動は許されません。
今回はGroupAで「②明示的な許可」をしていて、GroupBで「①明示的な拒否」をしているので、その両方のグループに属するIAMユーザー「koguma」は上記の「ポリシーの評価論理」によって、最終的に「EC2の一覧は表示できない」と評価されます。（※）
（※）
なお、ここではアクセス許可の境界、およびSCPは考慮していません。
これらが絡んでくる場合、①明示的な拒否がなくてもアクセスが制限される場合があります。後々、お話ししようと思います。
今回はここまでにします。
読んでくださってありがとうございました！