概要

SlideShareのIdentity and Access Management (IAM)のまとめ。

内容は5本立て。

IAMの概要
IAMポリシー
IAMロール
AWS Security Token Service
まとめ

IAMの概要

AWS利用者の認証と、アクセスポリシーを管理する。
AWS操のためのグループ・ユーザの作成が可能。
ユーザごとに認証情報の設定ができる。
(e.g.) 管理者 or 開発チーム or 運用チーム、それぞれにとって最低限必要な操作権限の付与。EC2とS3を使う場合だと、管理者はEC2とS3に関する操作権限、開発チームはS3の操作権限、運用はS3の参照権限のみ、って感じ。APIやマネジメントコンソールからのアクセスに対して、権限をチェックしてくれる。

IAMユーザ

1つのAWSアカウントに対して5000ユーザまで作成できる。
ユーザごとに設定できる情報は以下。

ユーザ名
- IAMユーザの識別と、マネジメントコンソールへのログインに使用
- パス(optional)
  - 組織階層に合わせてパスを作ったりできる
  - ユーザの検索時とかで便利
- 所属グループ
  - 10個のグループまで設定可能(1ユーザが所属できる上限と思われる)
- パーミッション
  - 各AWSサービスへのアクセスの権限
  - "ポリシー"の記述をJSONで行う

「アクセスキーID/シークレットアクセスキー」は、RESTやクエリ形式のAPIを使うときの認証に使用する。1ユーザにつき2つまで。Active/Inactiveのスイッチができる。
「X.509 Certificate」はSOAP形式のAPIリクエストに使用する。OpenSSLなどで証明書を作りアップロードする。
※X.509がまずよくわからないので、今後調査が必要。どうして方法に違いが出るのかも見えてくるはず。

IAMはマネジメントコンソールのログインに使用できる。AWSアカウントごとに専用のログインURLが用意されているので、そこから入る。デフォルトだとURLにAWSアカウント名が含まれる形になる。
※URLが割れたらAWSアカウントの情報が漏れてしまうので、多分変更することが推奨なんじゃないかと思っています。

IAMグループ

1つのAWSアカウントで100個のグループを作成できる。
グループに対しては、

グループ名
パス // ユーザのそれと同じ。optional
パーミッション

この3つ。グループに設定したパーミッションは、IAMユーザに付与したパーミッションと 同時に評価される らしい。

IAMポリシー

AWSアカウントに対する権限設定。JSONでアクセス条件を記述
例の1ブロックを引用します。

{
	"Effect": "Allow",
	"Action": [
		"s3:ListBuckets ",
		"s3:Get * ",
	],
	"Resource": [
		"arn:aws:s3:::myBucket"
	],
	"Condition": {
		"StringEquals": {
			"aws:SourceIP":
				["176.32.92.49/32"]
		}
	}
}

Effectで当該ブロックの「許可/不許可」の設定。
Actionで「どの操作について？」の指定。
Resourceで「どのAWSリソース(サービス)？」の指定
Conditionで「この"制御"をどういう条件で有効にする？」の指定。
上記の例だと
　「アクセス元IPが〜〜のとき、S3の"ListBuckets"と"Get系操作"を許可」
となる。ワイルドカードが使えたり、指定の操作以外をNotActionで指定できたり、器用。
Resourceに出てくる arn はAmazon Resource Nameの略。Resourceの名前の記述は arn:aws で始まる文字列になる。Actionと同じくNotResourceなる指定が使える。

ActionとResourceで記述できるサービスの範囲はそれぞれ異なる。SlideShareより引用します。

Conditionに書いた並列するブロックの評価はAND, 1つの演算子の中で書いた並列の値はORで評価される。詳しくはドキュメント参照。サンプル見ながら覚えるのが早そう。

IAMポリシーのジェネレータ

IAMポリシーは公式でジェネレータが存在するらしい。Lispで書いたら捗るんじゃね？とか思ってたら一瞬で出鼻をくじかれた。

適用状態のテスト

CLI実行時に --auth-dry-run

ec2-delete-snapshot snap-xxxxxx --auth-dry-run # Example

を付けることで、実際にサービスを動かさずに操作実行の可否を確かめられる。

ユーザベースとリソースベース

IAMポリシーはリソースに対しても関連付けできる。S3やSQSのキューなど。

IAMのクロスアカウントアクセス

S3, SQS, SNSなどで利用可能。AWSアカウントをまたいでアクセス許可ができる。

IAMロール

ユーザ(orグループ)やリソース以外に、AWSサービスやアプリケーションに対してAWS操作権限を設定することができる。アプリケーション間の連携とかでこの機能が必要になってくる。で、それを実現させるのがIAMロール。
ユーザやリソースといった、直接の管理対象でないモノに対して割り当てる権限だから"ロール"なんだろうと解釈しました。

IAM Role for EC2 instance

アプリケーションから他のAWSサービス(orアプリケーション)にアクセスするのにIAMユーザを使うこともできる。ただ、その場合はアプリケーションのコードに認証情報を埋め込む必要が出てくる。その情報はインスタンスのどこかで持っていなければならないのであんまり好ましくない。IAMロールを利用すると、 インスタンスと鍵管理を分離 することができる。
図解はスライドを引用。

IAMロールのクロスアカウントアクセス

図解がぱっと見ちょっとわからない。後でまた見直すことにする。

AWS Security Token Service (STS)

一時的に利用するトークンを発行するサービス。動的にIAMユーザを作成し、ポリシーを適用できる。
運用や開発で、急場の処置とかで作る必要が出たIAMアカウントとかはこれを使うのだろうか。
※IAM Role for EC2はこれを利用しているとのこと。 Assume Role(?)とか言うらしい

IAMの権限階層

SlideShareより引用。

Identity Federation

企業・組織の認証機能と、AWSの認証を紐づける。
認証したユーザごとに、一時的なアクセスキー(Temporary Security Credentials)を発行。

Temporary Security Credentials

AWSに対して一時的な認証情報を作成する仕組み。
以下の3つのキーをチケットとして発行する。

アクセスキー
シークレットアクセスキー
セッショントークン

一時的な認証情報なので有効期限は短い。デフォルトで12[h], 最小-最大で1-36[h]。

ユースケース

引用します。51ページ以降は動作の図解があるのでそれを見るのが早いと思います。

まとめ

IAMでもっとセキュアで安全にAWSを使いましょう！オペレーションのミスも減らせるよ
STSをうまく使うとアプリケーションやモバイルからAWSサービスを直接扱える
IAM自体には課金なし。どんどん使ってセキュリティを高めましょう