個人で使うケースしかなかったので、
考慮しないといけない点にいろいろ気づかせてくれた本。
ありがたいっすね。おすすめです。
第１章 AWSとIAM
認証と認可
- 認証は本人性の確認（Authentication)
- 認可はリソースに対する利用権限の付与（Authorization)
AWSアカウントの種類
- AWSアカウント
ルートユーザ。AWSサービスに対してネットワーク上のどこからでも操作できる権限を持つ
構築・運用をする場合での利用は避ける - IAMユーザ
WebコンソールやAPIを通じてのAWS操作に使用
各IAMユーザに対して操作を許可する、しないサービスが定義
IAMユーザ管理はセキュリティの要
第2章 IAMの機能
IAMユーザの認証は２種類あり
- ID・パスワードの組み合わせ
- アクセスキーID・シークレットアクセスキー
AWSマネージメントコンソールへのログインはID・パスワードを利用
API操作についてはアクセスキーIDとシークレットアクセスキーを利用
認証をより安全にするために、Multi-Factor Authentication(MFA)をオプションとしてつけることが可能
IAMグループ
同一の役割を持つIAMユーザをグループ化する機能
IAMユーザは複数のグループに所属することも可能
一般的な運用として、IAMユーザには直接権限を付与せず、IAMグループに権限を付与することを推奨
IAMポリシー
AWSリソースへのアクセス権限を制御権限をまとめたもの
ポリシーはJSON形式、AWSのビジュアルエディターにより選択式で作成可能
AWSが最初から設定している管理ポリシーもあり
AWS管理ポリシーとカスタマー管理ポリシーの使い分け
足し算（管理ポリシーで基本的な権限を付与）、引き算（カスタマー管理ポリシーで権限を制限）の組み合わせで使用する
AdministratorAccessとIP制限を組み合わせて、
全権限を持っているが特定のネットワークからのみAWSを操作できない権限を持ったグループ作成が可能
IAMロール
AWSサービスやアプリケーションに対してAWSの操作権限を与える仕組み
EC2にIAMロールを与えることにより、アクセスキーID・シークレットアクセスキーを設定することなく、
割り与えられたAWSの操作権限を利用することができる
IAMロールを正しく使うことで、安全性も利便性も格段に高まる
パーミッション・バウンダリー
IAMユーザまたはIAMロールに対するアクセス権限として動作
許可した権限とBoundaryで許可した権限と重なり合う部分のみ有効な権限として動作する
第３章 IAMチュートリアル
ここは割愛
第４章 IAMポリシーのデザインパターン
ホワイトリスト・パターンのメリット
必然的に最小権限を付与することになり、セキュリティ面での信頼性が高い
設計・運用するには、事前に充分な設計が必要となる
ホワイトリスト・パターンのデメリット
事前に役割が決まっていないと権限が付与できない
新たなアクションが必要な場合、都度増やしていくため負荷が高い
ホワイトリスト・パターンのユースケース
業務・運用設計が確率している本番環境に適用すべき
監査証跡など求められるようなシステムであれば、必須とも言える
ブラックリスト・パターンのメリット
禁止事項のみを定義すればよいので、設計・設定が最小限で済む
利用者に高い自由度を与えながら、組織として許容するセキュリティレベルを保つポリシー戦略となる
ブラックリスト・パターンのデメリット
Admin権限にブラックリストを加えて運用している場合、AWSに新しいサービスが始まると自動的に新しい機能も使えるようになる
ブラックリスト・パターンのユースケース
AWSの進化のスピードが速いため、一般的なIAMの運用としてはブラックリスト・パターンの利用が多くなる
ハイブリット・パターンのメリット
AWSの定義済みのポリシーと自分で作ったブラックリストを組み合わせて利用することにより、
最小の労力で実用的なポリシーを作ることが可能
ポリシーを組み合わせて権限を実現するため、個々のポリシーはシンプルに作ることができる
ハイブリット・パターンのデメリットは特になし
しいて言うなら、許可のIAM Policyと拒否のIAM Policyをグループで組み合わせる前提で作っておいて、拒否をつけ忘れる可能性がある
ハイブリット・パターンのユースケース
あらゆる環境で適用が可能
最初に適用するのがFullAccessだと、権限が大きくなりがちのため、ハイブリット・パターンで一定の制限を付け加えるのをお勧め
第５章 IAMグループのデザインパターン
以下のシチュエーションを想定したグループのデザインパターンを掲載
- 複数グループに所属
- グループ内に複数ポリシー
第６章 IAMとセキュリティ
IAMベストプラクティスの遵守
IAMベストプラクティスのリスト
- AWSアカウントのルートユーザのアクセスキーをロックする
- 個々のIAMユーザの作成
- IAMユーザへのアクセス許可を割り当てるためにグループを使用する
- 最小権限を付与する
- AWS 管理ポリシーを使用したアクセス許可の使用開始
- インラインポリシーではなくカスタマ管理ポリシーを使用する
- アクセスレベルを使用して、IAM権限を確認する
- ユーザの強力なパスワードポリシーを設定
- 特権ユーザに対してMFAを有効化する
- EC2インスタンスで実行するアプリケーションに対し、ロールを使用する
- ロールを使用したアクセス許可の委任
- アクセスキーを共有しない
- 認証情報を定期的にローテーションする
- 不要な認証情報を削除する
- 追加セキュリティに対するポリシー条件を使用する
- AWSアカウントのアクティビティの監視
- IAMベストプラクティスについてビデオで説明する
その他、考えるべきポイント
ルートユーザを使わない
IAMに関する権限付与
IAM権限は自他にAWSの権限を付与できる機能なので、実質Administrator権限と同義
AWSのアカウント管理者以外にはIAM権限を与えない
→ IAM権限剥奪をすると、ユーザー自身でパスワード変更やMFAの設定ができなくなる
ユーザ自身でパスワード変更やMFA設定、アクセスキー設定のポリシーを作成する必要あり
Lamdaのリソースベースの権限
Lamdaアクションの中には、アクセス権限の管理に関するものがあり
→ AWS Lamda リソースベースのポリシー
リソースごとに他のアカウントに使用許可を付与すること
この権限を利用するとIAM権限を利用せずともAWSのリソースのアクセス権を自由にコントロールすることができる
Lambdaに権限を付与する際は、FullAccessではなく必要な権限を選択して付与する
インターネット公開系の権限
読んでいて特に驚いたのが以下
EC2のルートデバイスボリュームに機密情報を入れたままAMIを作成
それを一般公開化（パブリック・イメージ）にしてしまうと他のアカウントから簡単にその情報を抜き出せる EBSのスナップショットについても同様
VPC内からのアクセス
アクセスキーの原則禁止
IAMロールを使用する
これ以降は割愛。