絶対王政におけるIAMの運用について
AWS運用をやってくなかでちょこちょこ出てくるんだけど、IAMよくわかんね。
って思ったので以下の資料を参考にさせていただいてまとめてみました。
ただまとめるのもつまんないので絶対王政風味。
参考：
http://www.slideshare.net/AmazonWebServicesJapan/20150617-aws-blackbeltiam?qid=a93c7f89-bf69-44da-b07b-08ef7c9ca706&v=&b=&from_search=1
※ 下記ベストプラクティスはこちらからお借りしました。
そもそもIAMってなんじゃらほい？
→ AWS Identity and Access Management
Identity : 身元/同一性(この場合ユーザアカウントが対象) → 身分
Access Manegement : アクセス管理 → 権限管理/委任
AWSの中で、ユーザとそのアクセス権を管理するためのツールだね。
絶対王政的なIAMの権限階層(えらい順)
(1)AWSアカウント(王様)
→ 万能かつ最強かつ唯一絶対の王者。キング。えらい。
→ 王権（アカウント）を簒奪されると、全資産を(クレカ情報とか)国ごと持って行かれるため、
基本的に権限だけ与えて王座の間に引きこもって働かせないほうがいい。
(2)IAMユーザーアカウント(領主、騎士、平民)
→ 王様から割り当てられた権限(Policy)を実行可能なナイト。
→ 王様から許された範囲でしか活動できないが、割当て次第では王様並になんでもできる。
王様から「権限を委任してやるぞよ(administratoraccess)」と言われたやつは、
他ユーザー（あと自分にも）権限割り振りが可能。当然こいつも盗まれると危険。
(3)一時ユーザー：Temporary Securyty Credentials(傭兵)
→ 戦争や小競り合いのために一時的な許可(SessionToken)を貰って暴れる傭兵。
→ 雇う側と雇用期間契約(Expiration)を結ぶ。
契約は絶対にして不滅のため、期間の延長や途中解雇はできない。
絶対王政的なIAM政権(ベストプラクティス)
1. AWS アカウント（ルート）のアクセスキーをロックする
→ 王様が即位したらとっとと玉座の間に引きこもる。
2. 個々の IAM ユーザーを作成する
→ 騎士叙勲および領地の授与。
3. IAM ユーザーへのアクセス権限を割り当てるためにグループを使う
→ 公爵、伯爵、子爵、貧乏貴族、平民など、身分制度(roll)を厳格に。
→ 貧乏貴族に資産管理(View Billing)させたり、平民に国庫管理（S3FullAccess)させたりしちゃだめ。
4. 最小限の特権を認める
→ たまに全ユーザーに権限委任(administratoraccess)しちゃう雑な王様もいる。
その場合、ならずものが城を崩壊（EC2インスタンスを落とす)させたり、
おっちょこちょいが書物に火を（RDSのインスタンスを削除）放ったり、
城壁のゆるいところ(Security Group)を突破して隣国が攻めてきたりするので、
権限委任はかなり慎重に。
5. ユーザーのために強度の高いパスワードを設定する
→ 門番の頭が悪いからといって、間違っても王様の誕生日を数字4文字で合言葉に指定とかしない。
6. 特権ユーザーに対して、MFA を有効化する
→ パスワードがバレても最後の鍵(MFA)を設定することでなんとかなる。
→ ただし、物理MFA紛失したり仮想MFAのアプリを間違って消したりすると
王様本人が玉座の間に入れなくなるから注意。
7. EC2で作動するアプリケーションに対し、ロールを使用する
→ お城(EC2)に配備する騎士や兵士にはちゃんと個々の役割をあたえてあげる。
よそのお城に対する権限与えたりすると喧嘩が起きるので注意。
8. 認証情報を共有するのではなく、ロールを使って委託する
→ 身分制度(roll)にちゃんと権限をつけるように。
袖の下をもらったからといって通行手形（アクセスキー）を共有したりしちゃいけません。
9. 認証情報を定期的にローテーションする
→ 通行手形は顔パスにならないように定期的に変えましょう。
10. 不要な認証情報の削除
→ 通わなくなった行商人、降格された貴族なんかの通行手形は無効にすること。
11. 追加セキュリティに対するポリシー条件を使用する
→ 出入り口の無い城壁はただの負債(課金されます)なので適切な抜け道をつくること。
12. AWSアカウントのアクティビティの履歴の保持
→ どんな通行人が通ったか、手形番号は控えておきましょう。
以上。