動機
IAMのことを今までちゃんと考えたことはありませんでした（よくない）。
サービスを利用するときに、そのサービスの既存のポリシーをReadOnlyで割り当てようか、FullAccessで割り当てようかを考えたくらいでした…
でもそれではよくない！ということで、この本を読んだのを機に、IAMについてしっかりとりかいしたいと思いました。
IAMとは
AWS Identity and Management (以下、IAM)は、AWS 利用に関する認証と認可を司るサービスです。
認証と認可
認証と認可はOAuthに関わるときにもよく出てきますね。
認証は本人性のの確認（Authentication)で、
認可はリソースに対する利用権限の付与(Authorization)です。
わかりづらいですね…ログインは認証で、その対象者はなにができるのか、なにができないのかが認可です。
OAuthの場合だと、認証はそのサービスへのログインであり、認可はサードパーティのアプリケーションになにをどこまで許可するのかということです。
例えばfacebookの認可だと、フィードへの投稿を許可するなどがあります。
AWSアカウントとIAMユーザー
AWSアカウントはルートアカウントとも呼ばれるアカウントで、絶対的な権限を持ちます。
通常利用してはいけません。IAMユーザーを作成し、IAMユーザーでログイン、管理など行いましょう。
IAMの機能
IAMには以下の5つの機能があります。
- IAMユーザー
- IAMグループ
- IAMポリシー
- IAMロール
- パーミッションバウンダリー
ひとつずつみていきます。
IAMユーザー
共有アカウントは作成せずに、必ず個々でユーザーを作成しましょう（MFA利用推奨）。
プログラム、ツールから利用の際もそれぞれに作成します。
IAMユーザーに直接権限を付与することも可能ですが、管理コストが高くなるのでやめましょう。
次に紹介するIAMグループで管理し、ユーザーの役割に応じてグループに所属させる方法が良いです。
IAMグループ
IAMグループは同一の役割を持つIAMユーザーをグループ化する機能です。IAMユーザーは複数のグループに所属することもできます。
IAMグループに権限を付与することにより、権限を容易に、かつ正確に管理することができます。
権限の付与方法は管理ポリシーとインラインポリシーの2つです。
IAMポリシー
IAMポリシーはAWSリソースへのアクセス権限をまとめたものです。
以下の3つの大きなルールに基づいて権限を設定します。
- Action(どのサー ビスの)
- Resource(どういう機能や範囲を)
- Effect(許可 or 拒否)
IAMポリシーの種類
IAMポリシーには2種類あります。
- AWSが最初から設定しているAWS管理ポリシー
- ユーザーが作成したカスタマー管理ポリシー
ポリシーはIAMユーザー、IAMグループ、IAMロールに付与できます。
IAMポリシーの使い分け
筆者のオススメは足し算と引き算。
AWS管理ポリシーで基本的な権限を付与、カスタマー管理ポリシーで権限を制限するのがよいと言っています。
IAMロール
IAMロールはAWSサービスやアプリケーションに対してAWSの操作権限を与える仕組みです。
LambdaやECSなど、実行している個々のタスクに対してIAMユーザーを割振れないようなサービスでIAMロールを利用します。
IAMロールは使わなくてもなんとかなりますが、IAMロールを正しく使うことによって、AWSの安全性も利便性も格段に高まります。積極的に使っていくのが良さそうです。
パーミションバウンダリー
IAMの移譲権限を制限する機能です。
IAMユーザー、IAMロールに対してアクセス制限を行います。
付与した権限とパーミションバウンダリーで許可した権限の重なり合うところのみ有効な権限として動作します。
あまり利用しなさそうな機能なのですが、一旦どういうものかは理解しておきたいです。
まとめ
パーミッションバウンダリーを除いた4つのIAMについてしっかりと理解することで、9割方マスターできます。
IAMユーザーはユーザーごとに作成します、また、共有アカウントは禁止です。
IAMグループはグループ化する機能で、グループにたいしてポリシーを付与します。
IAMポリシーは権限をまとめたものです。
IAMロールはAWSの操作権限を与えます。
IAMロールをうまく使うとアクセスキーがほぼ不要になります。
次回からはIAMポリシーについて詳しく掘り下げます。またIAMポリシーのデザインパターンについても理解していこうと思います。