IAMについて
「Identity Access Manager」の略。
AWSには、2種類のアカウントが存在する。
- ルートユーザー
全てのサービスを操作できるため、リスク高
通常利用は避ける - IAMユーザー
どのサービスをどの程度操作できるか、アクセス範囲を決めることができる
IAMを使うことで
「誰が」=認証「どのサービスにアクセスできるか(アクセス権限)」=認可 を決め、
ユーザがアクセスできるAWSリソースのアクセス許可を管理することができる。
3つの機能
-
IAMユーザ
外部の人、リソースに付与する
「ユーザ名」と「パスワード」が割り当てられる
1つのAWSアカウントの中に複数作成OK
デフォルト状態ではアクセス許可が割り当てられていない -
IAMポリシー
「アクセス権限」を記述したもの
IAMユーザやIAMロールに割り当てることで、誰がどの権限を持つかを決める -
IAMロール
AWSのリソースに付与するもの
必要なアクセス権限を一時的に付与するときに使う
IAM用語
よく使われるIAM用語たち
- IAMリソース
IAMに保存されているユーザー・グループ・ロール・ポリシー・IDプロバイダーを指す。 - IAMアイデンティティ
識別・グループ化するために使うリソースオブジェクト。 - IAMエンティティ
認証に利用されるIAMリソースオブジェクト。 - プリンシパル
ルートユーザー・IAMユーザー・IAMロールを利用してサインインしてAWSにリクエストを行う人・アプリケーションを指す。 - ワークロード
アプリケーション・バックエンドプロセスなどのビジネス価値を提供するリソース・コードの集合体のことを指す。
ポリシーとユーザー
IAMユーザーは、アクセス許可を付与されるまで、どのリソースにもアクセスできない。
アクセス許可を付与するには、アイデンティティベースのポリシーを作成し、ユーザ・グループにアタッチする。
例
dynamodb:* リージョン内の Books アカウント
123456789012 テーブルに対しすべての Amazon DynamoDB アクション (us-east-2) を実行することをユーザーに許可する。
{
"Version": "2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "dynamodb:*",
"Resource": "arn:aws:dynamodb:us-east-2:xxxxxxxx:table/Books"
}
}
IAMロール
特定のアクセス権限をもつIAMエンティティ
IAMユーザとの違い
- ロールを必要とする人に割り当て可能
→IAMユーザーの場合、1人の特定の人に一意に関連付け - ロールセッション用の「一時的なセキュリティ認証情報」が提供される
→IAMユーザーの場合、標準の長期認証情報が付与される（パスワード・アクセスキー）
信頼ポリシー
JSONポリシードキュメントで、ロールを引き受けるための「信頼できるプリンシパル」を定義する。
シナリオ
ロールの一般的なシナリオ: ユーザー、アプリケーション、およびサービス
- アクセス権を第三者に付与する時
信頼ポリシーを用い、ロールを引き受けることができるユーザを指定する。 - インスタンス停止時のアクセス権限
最小権限の原則に則ったアクション
気密性の高い環境を誤って変更・削除されることを防ぐ
IAMの一時的な認証情報
AWS STS(Security Token Service)を用い、リソースへのアクセスを制御する「一時的なセキュリティ認証情報」をもつ信頼されたユーザを作成できる。
長期的なセキュリティ認証情報との違い
- 有効期限は数分から数時間に設定できる
- ユーザのリクエストに応じて自動的に生成される
- 失効した場合、新しい認証情報をリクエスト可能（その時点で権限がある場合）
メリット
- 長期のセキュリティ認証情報を配布しないので、セキュリティリスク低
- ユーザーに対して、AWS IDを定義せずリソースへのアクセス制御が可能
- 有効期限が限られているので、明示的に認証を取り消す必要がない
（STSについては後日、別記事で調べてまとめてみる）