はじめに
こんにちは！
株式会社BFT名古屋支店・新卒のげんぬです。
名古屋支店に配属になりはや1カ月になります。時間の流れがとても早く感じますね。
前回のブログでは、同期のゆいちゃと一緒にAWSでweb３層を構築していました！
ゆいちゃは今GCPについてたくさんの知識をはてブロに挙げてくれてますね！
一方の私は、、、
未だにAWSを勉強中です！
特に次の案件で使用する技術要素であるIAMについて詳しく勉強しています。
今回のはてブロではIAMの基本知識や機能を中心にIAMについて勉強したことをアウトプットさせて頂きます。
AWSに初めて触れる方で特にIAMで躓いている方などにぜひ読んで頂きたいと思います！
IAMって何？
IAM=Identity and Access Managementです。
AWSリソースへのアクセスを安全に管理するための機能のことです。
IAMの中には、IAMポリシー、IAMロール、IAMユーザ等の機能があり、承認するリソースやユーザを制御しています。
今回はよく使用されるIAMの機能についてまとめてみました！
IAMポリシー
IAMポリシーとは
AWSリソースへの操作権限を設定する機能のことです。
そのため、ユーザやロールがリクエストした内容を許可していいかどうかが記載されています。
ポリシーは、プリンシパル（IAMユーザ、IAMロール）やリソースにアタッチして使用します。
Json形式のドキュメントで記述されていますが、GUIでの操作も可能です。
IAMポリシーの種類
IAMポリシーにはいくつか種類がありますが、今回はよく使用される２つのポリシーについてまとめました。
- Identity-based Policy
- Resource-based Policies
Identity-based Policyはプリンシパル（IAMユーザ、IAMロール）の実行許可内容について書いてある管理ポリシーです。
こちらは、AWSが既存で作成してくれているポリシー（AWS管理ポリシー）と私たちがカスタマイズできるポリシー（カスタマー管理ポリシー）の２つがあり、用途によって使い分けます。
Resource-based Policies はリソース側から許可するポリシーで直接リソースにアタッチして使用します。
IAMユーザ
IAMユーザとは
権限を制限されたユーザのことです。
１人１ユーザが基本の形で、権限はIAMポリシー、AMグループ、ユーザ管理のポリシーで管理しています。
では、ユーザの権限管理方法の１つであるIAMグループについてもここで触れていきます。
IAMグループ
完結にまとめると、IAMユーザの権限をひとまとめに管理する機能のことです。
ユーザーと権限を紐づける管理を簡単に行うことができるため、
権限の付与し忘れなどのミスを防ぐ効果も期待できます。
1人2人なら問題ありませんが、これが100人200人同じ権限のユーザが必要となった場合、まとめてしまった方が楽ですよね。
IAMロール
IAMロールとは
特定のアクセス権限を持ち、アカウントで作成できるアイデンティティの一つです。
役割を定義して、その役割に応じた権限を一時的にユーザやリソースに付与します。
IAMロールには、Turst（信頼関係）とPermissions(制限)という機能があります。
Turst（信頼関係）で使用できるユーザの制限を行い、Permissions(制限)で使用するリソースへのアクセス権限をポリシーを使用し行うことにより、安全にリソースを使用できるようにしています。
Assumeロール
役割に紐づく権限を引き受けることです。
プリンシパルがロールを受け取ることで一時的に権限として付与されたリソースの機能を使用することができます。
（ロールで権限を付与しているイメージを想像する際、ロールはヘルメットでよく例えられています。）
下の図はユーザがAssumeロールしたイメージです。
このように、Assumeロールすれば一時的にロール内の権限に従いインスタンスを使用できるようになります。
まとめ
IAＭについて、IAMポリシー、IAMユーザ、IAMロールの４項目についてまとめてきました。
AWSを使っていくうえで、IAMは切っても切り離せない機能なので今後も勉強を進めていきます！
また、IAMロールの機能としてスイッチロール、クロスアカウントアクセスを実践してみようと思っているのでそちらも完了次第、はてブロにアウトプットしていきます！
