AWSでの権限設定がわかりません！→IAMについてわかりやすくまとめてみました。


# IAMとは
IAM = Identify and Access Managementの略です。これもAWSで提供されているサービスの一つになります。AWSで提供されている各種リソースへの認証および認可について管理するサービスです。

まずリソースへアクセスする際に該当ユーザーについて認証をして、アクセスできるか確認します。さらにアクセスできる度合いも制御します。例えばフルアクセス、読み込みのみ等です。

"誰"が"何に"対して"どのように"アクセスできるかを決め、実現するサービスです。

# IAMの概要
![IAM Overview.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/54430/eef871fd-77bd-0f3a-20e5-51024a2f6c7b.jpeg)

1. ユーザーはAWS CLI, AWS SDK, AWSマネージメントコンソールを利用してAWSにログインする。
2. AWSにログインする際には、IAMユーザーあるいはIAMグループを用いて、パスワードなどを利用して認証する
3. 認証されたIAMユーザーおよびIAMグループはIAMポリシーに従って各AWSリソースに対するアクセス権限が許可される（フルアクセス、読み込み・書き込み、読み込みのみ等）

# IAMはなぜ重要か

**AWS権限設定はIAMに統合**
AWSは利用できるサービスが多岐にわたります。それに対して権限設定はIAMに統合されています。

例えば開発・ＱＡ・本番環境の構築を考えます。

* 開発メンバーは開発環境のすべてのサービス、リソースにアクセスできる。
* プロビジョニングアカウントはそれぞれQAと本番環境にアクセスできるがLambdaの変更はできない。
* データベース運用メンバーは本番環境のS3へのすべての権限を持っている

これらの権限設定はすべてのIAMのユーザー、グループ、ポリシー、ロールにより設定します。

**IAMで設定すべき必要なリソースがわかりにくい**

またIAMを正しく理解すべきもう一つの理由は、対象となるサービスおよびリソースの関連性が複雑ためです。

例えばLambdaを考えてみます。Lambda関数を利用するには該当の関数に対する許可があればよいのは明らかです。Lambdaを作成した際に自動的にIAM実行ロールが作成されます。

しかし例えばLambdaでDyanamoDBを利用していると、DynamoDBの該当のテーブルに対しても許可が必要となります。コードを書いているだけでは許可が必要かどうかわかりません。実際に動かしてみてから、実は必要だったことが明らかになり、適宜ポリシーで許可を与えることになります。このような場合Lambda作成者とIAMの管理者が同じであればトライアルアンドエラーで済ませることができますが、Lambda作成者が日本、IAM管理者が海外にいる場合時間ばかりかかります。

# IAMに関係する用語
## サービス
AWSで提供されるサービス。例えばEC2, S3, Lambdaなどです。

## AWSリソース
AWSで提供されているサービスの中で、ユーザーが実際に操作できる対象です。

* 例えばAmazon EC2サービスならEC2インスタンス、Amazon S3ならばS3バゲットがあります。

## ルートユーザー
ルートユーザーはAWSアカウントを作成した際に作るユーザーになります。

- アカウントに紐づいているすべてのAWSサービスとリソースについてアクセス権を持ちます。
- IAMアクセスポリシーによるアクセス許可はできない→常にすべてのサービス・リソースにアクセスできます。
- 基本ルートユーザーは使いません。
- 管理者用に別のIAMユーザーを作成して、管理者権限を割り振りましょう。
- アカウント乗っ取りを防ぐためにMFAを設定するのがよいでしょう。

## IAMユーザー
IAMユーザーはAWSを操作する人に個別に割り当てるユーザーになります。

-  ユーザーはログインする際に認証ができます。
-  ユーザーに紐づけられたIAMポリシーにより各種リソースに対する認可を設定できます。
-  ただし基本はIAMグループに所属させて、グループごとにポリシーを設定するのが望ましいでしょう。
-  一つのIAMユーザーは複数のグループに所属することができます。

## IAMグループ
ユーザーをアサインするグループです。

- グループに紐づけられたIAMポリシーにより各種リソースに対する認可を設定できます。
- グループに設定された認可はグループに所属しているIAMユーザーに引き継がれます。

## IAMポリシー
AWSリソースに対して許可されるあるいは許可されない操作、つまり権限を設定します。

- IAMポリシーはJSONで記述します。一見取り付きにくいですが、フォーマットは決まっています。慣れればそれほど難しくはありません。
- ポリシー作成時にはAWS Policy GeneratorもしくはIAM Policy Simulatorが利用できます。 

## IAMロール
IAMを構成する要素の中でもっとも理解が難しいのがIAMロールになります。
IAMロールを用いるメリットは２つあります。

* IAMポリシーを個別にオブジェクトに割り振る必要がなくなります。
* IAMポリシーの割り当てについて柔軟な条件を付けることができる

IAMロールはAWSサービスもしくは、個別のアプリケーションに割り当てられます。

- IAMロールはIAMユーザーもしくはグループには付与されません。
- IAMロールにはIAMポリシーを紐づけます。

詳細および使用例については後程説明します。ここでは権限をユーザーだけではなく、サービスおよびAWSリソースにも割り振ることができる、ということだけ理解してください。

# IAMユーザーの認証方法
ユーザーがログインする際に認証する方法は複数あります。アカウントの重要度あるいは環境に合わせて認証方法は変えるべきです。主な認証を方法を記載しておきます。

パスワード認証

- 主にマネージメントコンソールへログインする際に利用されます。
- ユーザー名とパスワードの組み合わせ。

アクセスキー認証

- API経由でAWSリソースへアクセスする際に利用される認証方法です
- 長期的な認証を提供するために用いられます。
- アクセスキーIDとシークレットアクセスキーの組み合わせになります。認証の際には両方が必要です。
- IAMユーザーもしくはルートユーザーに紐づけることができます。最大2つまで作成できます。
- ただしルートユーザーに紐づくアクセスキーは避けるべきでしょう。

MFA

- 認証を強化したい場合に用います。
- 第一要素はパスワード認証もしくはアクセスキー認証になります。
- 第二要素は認証されたデバイスもしくはSMSに送信される認証コードにより認証します。

# IAMロールの使い方
IAMロールは説明だけ読んでいてもなかなか理解できません。しかしユースケースでIAMロールを利用しないときーつまりパスワード認証もしくはアクセスキー認証の時ーと、IAMロールを利用するときを比べてみるとすぐ理解できます。

ここではもっともよくつかわれるパターンであるEC2からのS3バゲット利用シーンを使って比べてみます。

まず下記はEC2インスタンスのアプリケーションからS3バゲットを利用する際に、アクセスキーを利用して認証をする方法です。
![IAM Role-1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/54430/f398b22d-56b6-8c7a-31a0-83fdcea2bb3a.png)

この例ではアクセスキーがEC2インスタンス内のアプリに埋め込まれています。

- ACCESSキーはアプリケーションとポリシーの組み合わせによりユニークになります。
- アクセスキーを変更するためにはアプリを修正する必要があります。
- EC2インスタンスに不正アクセスがあった場合には、アクセスキーが漏洩する可能性があります。

ではそれに対してIAMロールを利用してみます。
![IAM Role-2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/54430/473f843b-d6fb-8743-42a5-7653b0c1f3a7.png)

- アクセスキーはアプリケーション内部には埋め込まれていません。
- 権限のつけ外しは、アプリケーションをいじることなく可能です。

# IAMの使い方
![2020-03-10_16h26_03.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/54430/f7f45618-49cf-5ae8-3229-8ad2d9be0ecc.png)


# IAMポリシー全体のデザイン
テスト開発ならともかくとして本番環境ならば、かならずIAMの全体像をデザインする。はじめてであればなかなかうまくいかない。しかし最初にデザインをしておき、問題が起きたらデザインの手直し→実装とすればセキュリティについて漏れがなくなりやすい。デザインは以下のポイントで整理する。

* 管理するオブジェクトもしくはサービスの一覧を作成する
* 上記で明らかになった対象について必要なポリシーを明らかにする
* ポリシーにアタッチするグループを作成する
* 各グループに所属するユーザーの一覧を作成する

## IAMオブジェクトの作成
デザインが仕上がったら順番にIAMオブジェクトを作成していきます。

* IAMユーザーを作成します。
* IAMグループを作成します。
* IAMポリシーを作成します。
* IAMポリシーをIAMグループに割り当てます。
* IAMユーザーをIAMグループに割り当てます。

# IAMポリシーの内容
IAMポリシーでは、どのAWSサービスの、どのリソースに対して、どのようなアクションを許可するかをJSON形式で記述する。ただし、AWSコンソールではGUIが提供されているために、一般的なポリシーを作成するならばJSONを気にする必要はない。

** GUI形式でポリシーを作成 **
![2020-03-10_16h42_15.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/54430/e247c668-4f4e-4112-95f4-a5671e9f6d76.png)

** 同じポリシーをJSON形式で作成 **
![2020-03-10_16h42_21.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/54430/06341b5a-df9a-ce44-b065-6668cdf2cff7.png)


# 参考
[Introduction to AWS Identity and Access Management](https://www.aws.training/Details/Video?id=16448)
英語ですが10分ちょっとでIAMの概念とIAMロールのユースケースを理解できます。IAM初めての人はまずここから！

[【図解/AWS】IAM入門～ロールとグループとポリシーの違い,設計・設定手順について～](https://milestone-of-se.nesuke.com/sv-advanced/aws/iam-policy-role-group/)
概要を理解したら、次にIAMユーザー、グループ、ポリシー、ロールについて勉強する必要があります。このページはそれぞれの概念がわかりやすく説明されています。

[AWS IAM入門](https://www.slideshare.net/qt_takada/aws-iam-69758187)
IAMロールについての基本およびユースケースがわかりやすく記載されています。上記の資料と合わせて読めば、ほぼIAMロールについて理解できます。

[【[AWS Black Belt Online Seminar] AWS Identity and Access Management (AWS IAM) Part1 資料公開](https://aws.amazon.com/jp/blogs/news/webinar-bb-aws-iam-part1-2019/)

IAMロールについてさらに理解を深めたければAWSブラックベルトです。スライド68枚、動画50分近くとかなり内容が濃くなっていますが、これを理解すれば間違いなくIAMブラックベルトでしょう。その反面IAM初心者にはおお勧めできませんので、まずは上記３つをこなし、自分でもいくつかIAMサービスをいじってからチャレンジしましょう。