AWS IAMについて

今後の開発のために、AWS関連で学習してきたことを備忘録的に記載していきます。
第一弾はIAM。AWSにおける権限管理のサービスで、AWSを触る上で避けては通れないものかと思います。また、一番重要であるとも言えます。

※ 以下AWS公式より抜粋

AWS Identity and Access Management (IAM) は、AWS リソースへのアクセスを安全にコンソールするためのウェブサービスです。IAM を使用して、リソースを使用するために認証 (サインイン) され、許可された (アクセス許可を持つ) ユーザーを制御します。

IAMの主な構成要素はPolicy,Role,User,Groupからなる。

Policyは各サービスに対するアクセス許可、不許可の設定を行うもので、AWSが最初から提供しているPolocyもあれば、自分でカスタマイズして作成することも可能。Policyの記述はどのサービスに、どういった条件で、どのような許可/不許可を与えるかなどをGUIで設定も可能だし、JSONでそれらの記述をすることも可能。
Roleは複数のPolicyを一つにまとめたもの。日本語にすると「役割」だが、まさにそういった用途で利用できる。例えば、「Admin」というRoleを作成し、そのRoleに対して、Adminに該当するようなPolicyをアタッチしていく。また、各サービスに対して直接アタッチする場合もある。特にEC2などは、作成時にそのEC2用のRoleを作成してアタッチしておいた方が良い。（後からアタッチ出来ないので。。。これがないと、詳細なVMのログをCloudWatchに送れない）
Userはその名の通り、UserのObject。AWSではアカウント作成時にRootアカウントが出来るが、このRootアカウントは権限が強すぎるため、出来るだけ使わない方が良い。AWSも公式にそう宣言している。たとえ自分が管理しているAWSであっても、このUserを作成し、Adminに該当するような権限をつけた方が良い。このUserには「AWS CLIなどでプログラムからアクセスする」ものと、「マネジメントコンソールからアクセスする」ものの二種類ある。もちろん両方の権限をつけたUserを作成することも可能。また、人につけるだけでなく、プログラム実行用のUserとしても利用可能。
Groupは、複数のUserを一つにまとめたもの。このGroupに対してRoleやPolicyをアタッチすると、そのGroupに属するUserにそれらの権限がアタッチされる。

私もそうだが、一般的な使い方としては下記になると思います。
　1. 必要な権限をもつPolicyを作成する
　2. それらのPolicyを役割ごとにまとめてRoleを作成する
　3. Userを所属させる「Admin」や「Developer」、プログラムに付与する「AdminProgram」、「XXXProgram」などのRoleを作成
　4. 人やプログラムに該当する各Userを作成
　5. Userをそれぞれの役割に応じたRoleに含める
　6. Roleでは定義できない例外的な権限を各UserにPolicyでアタッチする（例えば、開発者ではあるが、経理系も兼ねているので、Billingも見せたい等）

Cognitoを使う場合や、異なるAWSアカウント間の連携をする場合などは別の設定も必要になりますが、基本的には上記で問題ないかと思います。
私もAWSでプロジェクトを始める時は、まずは上記を行います。
上記以外で私が最初にやるのは
　1. パスワードポリシーの設定（何文字以上、英数混合必須、何日ごとに更新など）
　2. 人につけるUserにはMFA（二要素認証）の必須化
です。

参考になれば幸いです。