はじめに

どーも、のぶこふです。
この記事はGFAMアドベントカレンダー2021の2日目の記事です。

AWSを触っていくにあたり、なにはともあれ、アカウントの作成ですよね。
今回は、アカウント周りについて、まとめていこうと思います。

参考資料は、みんな大好きBlack Beltより拝借しております。¹ ²

今回のサービス一覧

Service名とか	概要
ルートユーザ	アドミン
アクセスキー	IDとパスワード
IAMユーザ	ユーザ
IAMポリシー	アクセス許可の定義
IAMグループ	IAMユーザの集合
IAMロール	一時的なアクセス権限
STS	IAMロールが生成する

※IAM（AWS Identity and Access Management）
※STS（AWS Security Token Service）

関係性

名前とか文章だけだと分かりづらいので、図にしてまとまっているのがコチラです。³

各サービスについて、もう少し掘り下げます。

ルートユーザ

アカウントの全てのAWSサービス・リソースに完全なアクセス権を持つユーザー
- つまり、めちゃんこ強いです。何でも出来ます。出来てしまいます。→乗っ取られるとヤバい！
- ので、極力、使うことは避けましょう。
- 使用例は後述の通り
マネジメントコンソールへは、AWSアカウントを作成した時のメールアドレス・パスワードでログイン
- ルートユーザ＝AWSアカウントとほぼ同義

ルートユーザの認証が必要なタスクの例

※あくまでも一例です

ルートユーザのメールアドレスやパスワード変更
支払いオプションやサポートプランの変更
AWSアカウントの解約

アクセスキー

ルートユーザ、IAMユーザの長期的な認証情報
- 外部からAWSへのサービスへプログラムを通じてアクセスが可能になる
- ルートユーザのアクセスキー作成は推奨されていません
- そもそも、ルートユーザの使用が推奨されていません
アクセスキーID・シークレットアクセスキーで構成される
- つまり、IDとパスワードで構成されている
アクセスキーを使うよりも、（IAMユーザに必要最低限のIAMポリシーを付与した）IAMロールを使用するのが推奨されています。

アクセスキーは共有しないこと

複数人がAWSリソースへのアクセス権を共有したい時でも、共有はNG。
- AWSへのアクセスが必要なアプリケーションの場合は、STSを取得する（後述）
取り扱いには注意
- Githubリポジトリ
- AMIへの埋め込み
- 設計書などのドキュメントに記載
- ハードコーディング

IAM

AWSで作成するエンティティ
名前と認証情報で構成される
- フレンドリ名：ユーザの作成時に指定
  - 例）nobkovskii
- ARN（Amazon Resource Name）：リソースポリシーのPrincipalで指定
  - 例）arn:aws:iam::0123456789012:user/nobkovskii
- 一意の識別子：フレンドリ名を再利用したいとき等に権限のエスカレーションを避けることができる
認証情報
- コンソールパスワード
- アクセスキー

MFAを有効化しよう

MFA（Multi-Factor Authentication:多要素認証）
- パスワードやアクセスキーとは別に、セキュリティを強化する仕組み
ルートユーザ、IAMユーザの各IDに個別設定可能
MFA条件を指定したポリシーを関連付け可能対象
- IAMユーザ、IAMグループ
- S3バケット、SQSキュー、SNSトピック等
- IAMの信頼ポリシー

不要な認証情報を削除しよう

社員の入社、退社、部署異動、役割変更など人員のライフサイクルと連動させて、最近使用していないパスワードやアクセスキー等は削除対象とする

認証情報を定期的にローテーションしよう

IAMユーザのパスワード
アクセスキー

ポリシー

IAMアイデンティティやAWSリソースに関連づけることによってアクセス許可を定義することができるオブジェクト

ポリシータイプとして分類されている。⁴
- 有効権限については、割愛⁵

ポリシータイプ	概要	有効権限（同一アカウント）	有効権限（クロスアカウント）
アイデンティティベースポリシー	管理ポリシー、インラインポリシーに分類	OR	OR
リソースベースポリシー	IAMロールの信頼ポリシー、S3バケットポリシーとか	OR	AND
パーミッションパウンダリー	IAMアクセス許可の境界、Organizationサービスコントロールポリシー（SCP）	AND	AND
アクセスコントロールポリシー（ACL）	S3バケットのACL、VPCサブネットのACL
セッションポリシー	一時セッションをプログラムで作成する際にパラメータとして渡すポリシー	AND	AND

AWS管理ポリシー

AWSにより事前定義されたポリシー
- AWSが作成、管理しており、編集は不可能
- AWSが更新する
すべてのAWSアカウントで利用可能
- 例）AmazonEC2FullAccess、AdministratorAccess
多くのユースケースで、すぐにポリシーの適用が開始できる

カスタマー管理ポリシー

AWSアカウントで管理できるカスタムポリシー
AWS管理ポリシーでは要件を満たせない場合等で使用する

インラインポリシー

１つのIAMエンティティ（ユーザ、グループ、ロール）に、直接埋め込まれるポリシー
- IAMエンティティに紐付いた固有のオブジェクト
- IAMエンティティを削除すると、インラインポリシーも削除される
IAMエンティティとポリシーが厳密な１対１の関係を維持する場合等に使用する

インラインポリシーではなく、カスタマー管理ポリシーを使おう

カスタマー管理ポリシーは・・・
- カスタマイズ可能
- 再利用性も高い
- すべての管理ポリシーを一箇所で確認できる
インラインポリシーは、カスタマー管理ポリシーに変換可能

IAMグループ

IAMユーザの集合
- IAMグループやIAMロールをIAMグループに所属させることは不可
- IAMグループに関連付けられたIAMポリシーは、所属するIAMユーザに継承される

IAMグループを使用して、IAMユーザにアクセス許可を割り当てよう

組織やジョブ機能に関連したIAMグループを作成して、IAMグループに対してアクセスIAMポリシーを関連付ける
会社内で組織移動があった場合は、対象のIAMユーザが所属するグループを変更するだけ！

IAMロール

AWSサービスやアプリケーション等のエンティティに対して、AWSリソースの操作権限を付与するための仕組み
- IAMユーザやIAMグループには紐付かない
- ロールを一時的に引き受けることで関連付けられたアクセス許可を受けることができる
一時的なセキュリティ認証情報
- 短期的な有効期限付きのアクセスキーID・シークレットアクセスキー・セキュリティトークンで構成
  - ローテーションしたり、明示的に削除する必要なし
- ユーザのリクエストでSTSを動的に作成

STS

一時的なセキュリティ認証情報を生成するサービス
- 期限付きのアクセスキーID・シークレットアクセスキー・セッショントークン

ロールを使用してアクセス許可を委任しよう

アカウント間でのセキュリティ認証情報の共有は御法度
EC2上のアプリにロールを適用
- 認証情報をEC2に持たせる必要なし
- 認証情報は自動的にローテーション
- SDKで認証情報取得とお有効期限切れ前の再取得を自動的に実施

IAMロールのユースケース

クロスアカウントアクセス
Swich Role
IDフェデレーション

おわりに

さくっと書くつもりが、思いの外、大容量になってしまいました。
次回からは、スッキリ書けるように気をつけます。

今回はここまでです。
ありがとうございました。