AWSの薄い本 IAMのマニアックな話
1章 AWSとIAM
2章 IAMの機能
- IAMの機能
- IAMユーザ
- ID と PASSWORD
- アクセスキーID と シークレットアクセスキー
- アクセスキーの発行は原則しない。必要なときに最小権限で発行する。
- IAMユーザの発行単位
- 実際に誰が利用していたのかを把握するため、利用者毎・プログラム・ツール毎に発行する
- IAMグループ
- 同一の役割をもつユーザをグループ化し、権限を付与できる。
- Admin, Developer...
- IAMロール
- AWSサービス、アプリケーションに対して操作権限を付与する
- IAMユーザを割り振れない場合等に使う
- パーミッション・バウンダリー
第3章 IAMチュートリアル
- GUIでの操作の解説
- IAMの許可・拒否ポリシーの挙動
- 明示的なDeny > 明示的なAllow > 暗黙的なDeny(デフォルト)
第4章 IAMポリシーのデザインパターン
ホワイトリストパターン
- 許可する権限のみを付与
- 他はデフォルトの挙動で暗黙的なDenyで制限される
- メリット
- 必要最小限の権限のみを付与するためセキュリティにおける信頼性が高い
- デメリット
- 事前に付与する権限が決まっていないと付与することができない
- 探索的に開発を進めていく場合、都度、権限付与する必要があり、IAMポリシーを管理する手間がある
- 業務や運用設計が確率している場合、高いセキュリティを求められる場合に有効
ブラックリストパターン
- 許可してはいけない権限を剥奪する
- ex. NotActionでIAMの権限以外の権限を許可した後にパスワード変更等の権限を明示的にAllowで設定する。
- メリット
- 禁止事項のみを定義するだけでいいのでIAMポリシーの設計・設定が最小でよくなる
- 利用者は高い自由度を持つことができる
- デメリット
- NotActionで指定するため、AWSに新しいサービスが始めると自動的に新しい機能が使えるようになってしまう。
- AWSの権限は暗黙的なDenyのため、新しいサービスを使いたくても権限がなく、すぐにサービスを利用したくても使えないが、ブラックリストパターンではすぐに利用できる。
- 探索的な開発を行う場合等に適している。
ハイブリットパターン
第5章 IAMグループのデザインパターン
- 以下の2パターンには機能的な優劣は存在せず、運用面で組織やチームにあったものを選択すればよい
- 複数のグループに所属するパターン
- 必須の全ユーザ向けIAMポリシーを持つIAMグループに所属させ、開発者向けまたは運用者向け等の役割毎IAMグループに所属させる。
- グループ内に複数のポリシーを設定するパターン
- ユーザーが一つのグループに所属するという前提に権限を管理する
- 1つのグループにしか所属しないため、シンプルさがある
第6章 IAMとセキュリティ
- すべてのIAMユーザにMFAを設定しておくこと
- 将来的に特権ユーザーになる場合があるため、初期段階ですでにMFAの設定をしておく
- Lambdaリソースベース権限
- AWSリソースへのアクセスはIAMポリシーで管理されていて、Lambda関数の実行ロールとして紐付けることができる。
- Lambdaはリソースベースのポリシーを利用することができ、リソース毎に他のアカウントに使用許可を与えることができる
- リソースベースのポリシーはIAMの権限を利用せずともアクセス権限を得られることになるので最小権限を付与することが望ましい
- インターネット公開系の権限
- EC2のように権限が多岐に渡るものはネットワーク系の操作を明示的に拒否する方法と併用するとよい
- S3へのアクセス元権限はIAMポリシーを使って制限を行うよりも、S3側のバケットポリシーを使うとよい。
- IAMでリソース制限をする際にはプライベートIPを使用することができないため、InternetGatewayを通らない場合は、VPCのIDを元に権限を付与する。
- アクセスキーの原則禁止
- アクセスキー・シークレットアクセスキーの流出防止策はあるものの、作らないに越したことはない。
- Capital Oneは2019/7に1億人を超える個人情報の流出事件
第7章 IAMの運用
- セキュリティ保持のために手間がかかる運用であればいつかは形骸化する
- IAM運用の目的
- AWSを安全な状態の保持
- 維持するために手間がかからず、利用者によってセキュリティレベルの差異がでないように標準化する。
- ツール・プログラム利用・関係者の洗い出し
- AWSアカウント（ルートユーザ）は原則的に使用しない
- アカウント作成後は、ルートユーザを使用せずとも支障がないような設定を行うべき
- IAMユーザの管理
- 最小権限の付与
- 不要になったユーザーの削除
- Croud Trailで利用状況のログを取得、Configで設定変更の監視をするなどして定期的にIAMユーザの棚卸しをすべき
- 人間用のIAMユーザー
- ユーザー毎に作成し、共有アカウントの作成は禁止
- 異動や退職などの入れ替わりに応じて棚卸しルールを作成する
- CLIやプログラムから利用するIAMユーザー
- 人の出入りに関しては比較的わかりやすい
- プログラムから利用されなくなったIAMユーザは観測しにくい
- IAMユーザごとの担当者を明確化する
- 最終利用日から一定期間過ぎたIAMユーザーは継続確認を行う
- アクセスキーの管理とCLI
- アクセスキーは限られたIAMユーザーのみで作成する
- アクセスキーを作成するIAMユーザーの権限は最小にする
- CLIでもスイッチロールは可能なため、必要な場合はIP単位でIAMユーザの制限をし、スイッチロールする
- MFA未利用時に権限を制限し、MFA利用を促す
- MFAを設定していない場合は、IAM以外の権限を拒否するポリシーをアタッチすることでMFAの設定を促す
- マルチAWSアカウントでの運用
- IAMユーザをそれぞれのアカウントで作成するのは手間がかかる
- 踏み台のAWSアカウントを作成し、そのアカウントでIAMユーザーを作成ののちにスイッチロールすることで手間が省ける
第8章 IAMとCloudFormation
- CloudFormaion等のIaCでAWSアカウントを管理しておけば手間を省き、人的なミスを防ぐことができる
第9章 IAMのテンプレート集
- CloudFormationのテンプレートがあったが割愛する
- 共通ポリシー
- 自身のパスワードをMFAの設定権限
- IP制限とMFA必須化のポリシー
- 管理者グループ
- 全権限の付与
- 全ユーザからのSwitchRoleをされることを抑制するポリシー
- ロールにスイッチ可能なユーザを記載するパターン
- 特定ユーザーにスイッチロール可能な権限を付与するパターン
- ネットワーク管理者グループ
- 開発者グループ
- 多くのリソース制御が必要
- 本書ではPowerUserAccessとネットワーク権限、Lambdaの権限付与をしているが、組織に適したポリシーをアタッチすることが必要
- オペレーターグループ
- どこまでが職務範囲かに依存
- AWSサポートに問い合わせが必要な場合は、AWSSupportAccessを付与する
- 経理担当者グループ
- BillngにアクセスするためのAWS管理ポリシーをアタッチ
- お一人様AWS（個人開発等）
- Admin権限を普段扱いせず、参照権限のみを付与
- 必要に応じて管理者ロールにスイッチロールするのが安全
第10章 IAM以外のAWSサービスの活用
CloudTrail
- 誰がどの操作を行ったのか実行履歴ログを取得することができる
Config
- AWSリソースがどういう状態か、状態に対してどのようなアクションをするかを設定できる
- ex. EC2インスタンスにタグでNameをつけることを必須化する運用ルールを策定し、それを満たしていない場合、強制的にシャットダウンさせる
GuardDuty
- 驚異検出と継続的なモニタリングができ、それに対する防御を機械的に実行する
ControlTower
- 複数のアカウントの設定及び管理するサービス
SecurityHub
- 複数のアカウントの状況を一括してモニタリングするサービス
