ド底辺お嬢様でもわかるAWS IAMについて

IAMって庶民の管理くらい面倒ですわ～～！？！？！？

IAMって面倒ですよね。
EC2にはAMIっていう似た名前もあるし、AWS初学者だと500000%詰まる。
特にAWSを触って間もない頃だとユーザー？ロール？ポリシー？グループ？なんじゃそりゃ？ってなる。
特に設計とかになってくると絶対にあたまぐーるぐるする項目です。
今回はユーザー、ロール、ポリシー、グループについて要点を勢いでまとめてみる試みです。

じいや！！！ユーザーを準備なさって！！！

IAMユーザーについてAWS公式ドキュメントでは以下のように説明される。

AWS Identity and Access Management (IAM) のユーザーとは、AWS で作成したエンティティのことです。IAM ユーザーは、AWS とやり取りするために IAM ユーザーを使用する人間のユーザーまたはワークロードを表します。AWS のユーザーは名前と認証情報で構成されます。
管理者アクセス許可を持つ IAM ユーザーが AWS アカウントのルートユーザー ということではありません。ルートユーザー の詳細については、「AWS アカウントのルートユーザー」を参照してください。

🤮🤮🤮🤮
つまり雑に要約するとこういうこと。

1. あ～～！！パソコンを使いてぇですわ～～！！
2. ログインするにはユーザーが必要ですわ～～！！
3. じいや！ユーザーを作ってくださいまし！！！
4. ユーザーできたしこれでログインできますわ～～！！
   

つまりこのユーザーのこと。

WindowsとかLinuxとかMacOSでもユーザーを作らないとパソコンにはログインが出来ないはず。
このユーザと同じ働きをするのはIAMユーザってこと。
AWSにログインしてあれこれするときに使うのが「IAMユーザ」って考えたらいい。

ちなみに「AWS アカウントのルートユーザー」って言うのは超最強管理者みたいなもの。
Linuxで言うRoot、WindowsでいうAdministratorみたいなもので、要するにサイキョーのユーザー。
でもサイキョーのユーザーをみんなで使うようにしちゃうと絶対誰かが悪いことをするでしょ？
子供がパソコン使っててもしサイキョーの権限があったら親の目を盗んでえっちなソフトを入れてこと悪いことするでしょ？（偏見）
ってことなので、基本的には権限をある程度絞ったユーザーをAWS利用者ごとに1:1で払い出すのがベター。

ばあや！！！IAMロールって私の髪の毛より巻いてますの！？！

IAMロールについてAWS公式ドキュメントでは以下のように説明される。

IAM ロールは、特定の許可があり、アカウントで作成できるもう 1 つの IAM アイデンティティです。IAM ロールは、アイデンティティが AWS で実行できることとできないことを決定するアクセス許可ポリシーを持つ AWS アイデンティティであるという点で IAM ユーザーと似ています。ただし、ユーザーは 1 人の特定の人に一意に関連付けられますが、ロールはそれを必要とする任意の人が引き受けるようになっています。また、ロールには標準の長期認証情報 (パスワードやアクセスキーなど) も関連付けられません。代わりに、ロールを引き受けると、ロールセッション用の一時的なセキュリティ認証情報が提供されます。

ロールを使用して、通常は AWS リソースへのアクセス権のないユーザー、アプリケーション、サービスにそのアクセス権を委任できます。例えば、AWS アカウントのユーザーに、通常はないリソースに対するアクセス許可を付与したり、ある AWS アカウント のユーザーに、別のアカウントのリソースに対するアクセス許可を付与したりできます。

🤮🤮🤮🤮

つまり雑に要約するとこういうこと。

1. あ～～！！庶民に私のパソコンで仕事させてぇですわ～～！！
2. でも庶民ごときにパソコンが自由に使えるユーザーを渡すのも癪ですわね……
3. じいや！ログインだけできるユーザーを作ってくださいまし！！！
4. ばあや！この庶民によわよわ庶民の権限を貸し出してくださいまし！！！
5. よわよわ庶民の権限が付きましたわ～～！！これで最低限仕事させられますわよ～～！！
   

つまりこの貸した権限のこと。

注目したい点は本来はログインしか出来ないユーザーなのに、権限を貸し出したことでExcelが使えるようになったこと。
これは権限を貸し出したことで本来できない範囲ができる様になったと考えられる。
つまりIAMロールは、IAMユーザーに貸し出すことで一時的にそのユーザーでは出来ない作業ができるようになる機能を持つ。
より正確に書くのであれば、IAMユーザーを利用して他のAWSの機能やサービスを利用する際に、そのユーザーが本来利用できない機能やサービスについて利用が可能なロールを貸し出すことで、そのユーザーが機能やサービスを利用することができると理解する事ができる。

また、IAMロールはもう一つ重要な機能を持つ。
公式ドキュメントから引用した文章の、この一文。

ロールを使用して、通常は AWS リソースへのアクセス権のないユーザー、アプリケーション、サービスにそのアクセス権を委任できます。

ユーザーってのはわかったけどアプリケーション？サービス？どゆこと……
🤮🤮🤮🤮

つまり雑に要約するとこういうこと。

1. あ～～！！PCにマイニングさせてぇですわ～～！！
2. ちょっと！！なんかマイニングソフトが動きませんわ！？！？！
3. ばあや！勝手に放置しててもマイニングできるように権限をつけてくださいまし！！！
4. 権限が付きましたわ～～！！これで放置で金稼ぎできますわ～～！！
   

ここで重要なのは、本来は動作しなかったマイニングソフトがパソコンにIAMロールをつけたことで動作するようになったこと。
これはIAMロールをつけたパソコンはロールの権利を使って勝手にソフトを動かせるようになったと理解できる。
つまりIAMロールは、AWSリソース（例えばEC2の仮想コンピュータやLambdaの関数など）にIAMロールをつけることで、そのIAMロールの権限の範囲内でコンピュータや関数が自動で動けるようになる機能を持つ。

より正確に書くのであれば、AWSの特定のサービスが他のAWSの機能やサービスを自動的に利用する際は、それが利用する機能やサービスについてロールで許可を出さないと利用できないと捉える事ができる。
このあたりについてはものすごくありえないくらい覚えやすいクラメソ様の記事があるのでそっちを見てください。（他力本願寺）

おかあさま！！！ポリシーってなんですの！！！

IAMポリシーについてAWS公式ドキュメントでは以下のように説明される。

AWS でのアクセスを管理するには、ポリシーを作成し、IAM アイデンティティ (ユーザー、ユーザーのグループ、ロール) または AWS リソースにアタッチします。ポリシーは AWS のオブジェクトであり、アイデンティティやリソースに関連付けて、これらのアクセス許可を定義します。AWS は、IAM プリンシパル (ユーザーまたはロール) によってリクエストが行われると、それらのポリシーを評価します。ポリシーでの許可により、リクエストが許可されるか拒否されるかが決まります。通常、ポリシーは JSON ドキュメントとして AWS に保存されます。

🤮🤮🤮🤮
つまり雑に要約するとこういうこと。

1. あ～～！！バチクソ男漁りがしてぇですわ～～！！
2. はぁ～～～！？このユーザーじゃあタップルで王族重課金ができませんわ～～！？！？！
3. おかあさま！このユーザーにおとうさまのクレカを自由に使えるよう許可してくださいまし！！！
4. 許可が出ましたわ～～！！これで札束パワープレイ男漁りできますわよ～～！！
   

つまりこの許可のこと。
IAMポリシーは様々な制限に対して許可を定義するもの。
ポリシーで許可の範囲を自由に決めて、それをつけたり外したりすることでIAMユーザーのできるコトを決めることができる。
具体的に例えるなら、「EC2を自由に使える許可」というものをIAMユーザーに付与したら、そのユーザーはEC2を自由に使う許可が得られる。
なお、許可ができるならもちろん否認もできる。
例えば「EC2を使っちゃダメ」って否認するポリシーをつけたら、そのユーザーはEC2に関する機能が全部使えなくなる。

また、この許可はその他のエンティティにもつけることができる。
エンティティというのにはIAMロールが含まれる。
IAMグループも含まれるが一旦割愛。

つまり雑に要約するとこういうこと。

1. あ～～！！めんどくせぇから庶民に私のパソコンで代わりに男漁りさせてぇですわ～～！！
2. じいや！庶民にログインだけできるユーザーを作ってくださいまし！！！
3. ばあや！この庶民にタップルに登録できる権限を貸し出してくださいまし！！！
4. おかあさま！この権限ならおとうさまのクレカが自由に使えるよう許可してくださいまし！！！
5. タップルだけ最強なバケモノ庶民が生まれましたわ～～！！これで男漁りさせられますわよ～～！！
   

そう、IAMロールにつけられるなら、IAMロールを貸し出したIAMユーザーのできることの範囲を指定することができる。
具体的に例えるなら、「EC2を自由に使える許可」をIAMロールにつけたとする。
そのIAMロールを貸し出してもらえるユーザーは、そのロールを使っている間はEC2を自由に使う許可が得られるってこと。
上の内容と同じく、許可ができるならもちろん否認もできる。
例えば「EC2を使っちゃダメ」って否認するポリシーIAMロールにつけたら、そのIAMロールを使うユーザーはEC2に関する機能が全部使えなくなる。

おにいさま！！！IAMグループってつまりファミリーってことでして！？！

IAMグループについてAWS公式ドキュメントでは以下のように説明される。

IAM ユーザーグループとは、IAM ユーザーの集合です。ユーザーグループを使用すると、複数のユーザーに対してアクセス許可を指定でき、それらのユーザーのアクセス許可を容易に管理することができます。

IAMユーザーの集合…？IAMユーザーってユーザーだから集合ってどゆこと……

🤮🤮🤮🤮

つまり雑に要約するとこういうこと。

1. あ～～！！我が家の臣下にもタップルを使えるようにしてやりてぇですわ～～！！！
2. はぁ～～～！？みんなのユーザーじゃあタップルができませんの～～！？！？！
3. おにいさま！超高級貴族グループを作って我が家の臣下全員のユーザーをグループにぶっこんでくださいまし！！！
4. おかあさま！タップルに登録できてクレカが使える許可をグループにつけといてくださいまし！！
5. 卍タップル最強超級貴族卍に生まれ変わりましたわ～～！！これで男漁りパワープレイですわ～～！！
   

つまりこのグループのこと。
IAMグループに所属しているユーザーは、デフォルトでグループに定められた許可範囲で自由な利用が可能になる。
つまり、IAMグループに適切に許可を設定することで、IAMユーザーに対して個別で設定したりする必要がなくなる。
また、許可についてはIAMポリシーのアタッチで管理を行う。
そのためIAMポリシーを適切に作成/付与し、グループ内のアカウントを適切に管理することで、ポリシーの個別付与や特定のサービス利用を目的としたIAMロールの作成などを行う必要がなくなる。
特にIAMユーザーが多数あるような環境におけるアクセス管理で非常に役に立つ。

これで最後ですわ～～～！！！

語弊を恐れずに書いたので非常にあやふやな点も多いとは思っています。
例えばIAMRoleについてはAssumeRoleやSwitchRoleに関しての説明もないですし、IAMPolicyについてはインラインやカスタマーなどの種類についての言及もしていません。
またサービス面で言うのであればIAM Identity Centerに関する説明なども省いてます。

ですが、本記事の目的は初学者の方にIAMと言うのはこういうものなんだよという基本骨子の部分がざっくりと伝わればいいかなと思って書きました。
なのでもしこの記事の内容を読んでみて、「ここがわからない」とか「ここってどういう構造なんだろう」と興味を持って頂いて、あわよくば自分で深く調べる…みたいな感じになっていただけますと筆者冥利に尽きます。

IAMは最初はとっつきにくく、その上理解するも複雑で難しそうとハードルが高いように見えますが、その実理解してしまえばこれほどシンプルで便利な機能は無いと思っています！
ぜひIAMについて理解を深めて頂いて、アクセス管理や設計などに生かしていただけると大変嬉しいです！

P.S 画像関係で怒られたら色々修正します