はじめに
どーも、のぶこふです。
この記事はGFAMアドベントカレンダー2021の2日目の記事です。
AWSを触っていくにあたり、なにはともあれ、アカウントの作成ですよね。
今回は、アカウント周りについて、まとめていこうと思います。
参考資料は、みんな大好きBlack Beltより拝借しております。1 2
今回のサービス一覧
| Service名とか | 概要 |
|---|---|
| ルートユーザ | アドミン |
| アクセスキー | IDとパスワード |
| IAMユーザ | ユーザ |
| IAMポリシー | アクセス許可の定義 |
| IAMグループ | IAMユーザの集合 |
| IAMロール | 一時的なアクセス権限 |
| STS | IAMロールが生成する |
※IAM（AWS Identity and Access Management）
※STS（AWS Security Token Service）
関係性
名前とか文章だけだと分かりづらいので、図にしてまとまっているのがコチラです。3
各サービスについて、もう少し掘り下げます。
ルートユーザ
- アカウントの全ての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を動的に作成
- 短期的な有効期限付きのアクセスキーID・シークレットアクセスキー・セキュリティトークンで構成
STS
- 一時的なセキュリティ認証情報を生成するサービス
- 期限付きのアクセスキーID・シークレットアクセスキー・セッショントークン
ロールを使用してアクセス許可を委任しよう
- アカウント間でのセキュリティ認証情報の共有は御法度
- EC2上のアプリにロールを適用
- 認証情報をEC2に持たせる必要なし
- 認証情報は自動的にローテーション
- SDKで認証情報取得とお有効期限切れ前の再取得を自動的に実施
IAMロールのユースケース
- クロスアカウントアクセス
- Swich Role
- IDフェデレーション
おわりに
さくっと書くつもりが、思いの外、大容量になってしまいました。
次回からは、スッキリ書けるように気をつけます。
今回はここまでです。
ありがとうございました。