AWSの薄い本シリーズ（IAMのマニアックな話など）の読書メモ

年明けから IAM 周りの整理をいろいろしなければいけなくなったので、佐々木拓郎さんの「AWSの薄い本」シリーズ2冊を読みました。今回はその読書メモです。

booth.pm

AWS は普段から使っているので、IAM の基本的な機能はもちろん知っているのですが、最近追加された機能（特にマルチアカウント管理に関する機能）については全然追えてなかったので勉強になりました。

以下、勉強になった点をまとめたメモです。AWS の情報は日々変わっていってしまうので、発行日も併せて記載しました。

AWSの薄い本 IAMのマニアックな話（発行日：2019年9月22日）

第1章 AWSとIAM

AWS Organizations は本書の対象外
ポリシー記述の文法的な部分は本書では扱わない。詳細は公式のIAM JSON ポリシーのリファレンスを参照

第2章 IAMの機能

IAMの機能のうち、まず次の5つの機能の認知と理解をしておくことが重要
- IAM ユーザー
- IAM グループ
- IAM ポリシー
- IAM ロール
- パーミッション・バウンダリー
アクセスキーの発行は原則しないほうがいい。必要になったときに最小の権限で発行する
IAMユーザーに権限を直接付与こともできるが、管理上の複雑さが増すので、IAMグループで管理することを推奨
管理ポリシーとインラインポリシー
- インラインポリシーは管理ポリシーができる前の古い機能
- AWSが最初から設定しているポリシーをAWS管理ポリシー（AWS Managed Policies）、各ユーザーが独自に作成したポリシーをカスタマー管理ポリシー（Customer Managed policies）と呼ぶ
- AWS管理ポリシーで大まかな権限を足した後、不要な権限をカスタマー管理ポリシーで引く
Permissions Boundary（パーミッション・バウンダリー）
- 2018年7月に登場した、IAMの移譲権限を制限する機能
- 他者にIAMユーザーやIAMロールを貸与する際に、それらが持つ権限の一部（パーミッション・バウンダリーで設定した権限）しか使えない状態にすることができる

第3章 IAMチュートリアル

Condition で aws:SourceIp を指定するときに、プライベート IP の範囲を指定しても意味がない。VPC 内のリソースを制限するには VPC ID もしくは VPC Endpoint ID を指定する必要がある（6章）
IAM ポリシーの基本的な動作は「明示的な Deny ＞明示的な Allow ＞暗黙的な Deny（デフォルト）」
クロスアカウントロール（IAM ロール）を使って、設定変更時のみ、変更権限を持つ IAM ロールにスイッチする例
- スイッチ元は sts:AssumeRole で制限
- Principal に、IAM グループでの指定はできない

第4章 IAMポリシーのデザインパターン

ホワイトリストパターン
- 最小権限を付与するのに適している
- 事前に役割を決めて権限を付与するため、探索的な開発の場合には効率が悪くなる
- 本番環境、かつ高いセキュリティを求められるエンタープライズ向け
ブラックリストパターン
- 禁止事項のみを定義すればよいので、IAM ポリシーの設計・設定が最小で済む
- AWS に新しいサービスが始まると、予期せぬ機能が突然使えるようになる
- 探索的な開発環境、もしくは比較的大きな権限が必要な管理者向け
ハイブリッド・パターン
- AWS の定義済みのポリシーと、自分で作ったブラックリストを組み合わせて利用することで、最小の労力で実用的なポリシーを作ることができる
- 組み合わせに使われる個々のポリシーは、シンプルに作ることができる

第5章 IAMグループのデザインパターン

以下の2つのパターンが考えられるが、機能的な優劣はない
- ユーザーが複数グループに所属し、グループ間のポリシーの重複はないパターン
- ユーザーが1つのグループに所属し、グループ間でポリシーの重複があるパターン
IAMグループは、path オプションを使って階層構造を表現できるが、権限の継承のような機能はない

第6章 IAMとセキュリティ

AWS が公開している IAM のベストプラクティス
特権ユーザーに関わらず、すべての IAM ユーザーに対して MFA の有効化を原則にすべき
ユーザー自身のパスワードと MFA の設定を許可する例
- ${aws:username} は IAM ポリシーエレメントと呼ばれる変数で、ログインしている IAM ユーザー名に置き換えられる
- AWS アカウント ID の変数は、IAM ポリシーエレメントに無い。代わりに、CloudFormation の疑似パラメーター参照に AWS::AccountId として存在する
Lambda のリソースベースポリシー
- AWS Lambda のリソースベースのポリシーを使用する
- この権限を利用すると、IAM 権限を利用せずとも AWS のリソースのアクセス権を自由にコントロールすることができる
- Lambda のアクセス権限の付与は、AddPermission や AddLayerVersionPermission で行える
インターネット公開系の権限（EC2のインスタンスへの通信許可など）は、ホワイトリストで管理するのは大変。そういった際には、ネットワーク系の操作を明示的に拒否する方法と併用するといい
S3 へのアクセス元制限は、IAM ポリシーを使うより S3 側のバケットポリシーを使うのが一般的
- Amazon S3 の VPC エンドポイント用のバケットポリシーの例
IAM ユーザーを作成する際の原則として、アクセスキー、シークレットアクセスキーを作らないことを推奨
Capital One の情報流出事件（S3 からの情報流出）を防ぐために必要だった設定
- IAM ロールのクレデンシャルが漏洩した際の影響を最小化するため、IAM ロールに付与する権限を絞り込む
- バケットポリシーで接続元 VPC を制限する

第7章 IAMの運用

IAM 運用の目的
- AWS を安全な状態に保ち続ける
目的の達成のために
- 維持するために手間が掛からない（現実に許容できるコスト）
- 利用者によってセキュリティレベルの差異がでないようにする（標準化）
まずは利用者（人間、プログラム）を洗い出す
AWS を利用する人ごとに適切な最小権限を付与し、必要でなくなったら権限をなくす
- CloudTrail で AWS コンソール、API 利用履歴のログを取得する
- Config を利用し、IAM 関係の設定の変更を監視する
  - AWS Config マネージドルールのリスト
- Config Rules で設定値を監視
- （月次等の）定期的な IAM ユーザーの棚卸し
CLI やプログラムから利用する IAM ユーザーも、棚卸しが必要
- IAM ユーザーごとの担当者を明確化する
  - 例えば、IAM ユーザーのタグに担当者を書く
- 最終利用日から一定時間が過ぎた IAM ユーザーは継続の確認をする
  - 使われていなければ、まず無効化して、しばらくして問題がなければ消す
CLI 利用のためにアクセスキーを発行する場合、アクセスキーの流出対策が必要
- CLI 利用時にも IAM ロールへの切り替えが可能
- IAM ユーザー側に IP アドレスによる利用制限をした上で、必要な場合にスイッチロールで権限を切り替えるという運用をしておけば、万が一流出しても直接の被害を防げる
マルチアカウント利用時は、各アカウントに IAM ユーザーを作るのではなく、踏み台 AWS アカウントを1個作り、そこの IAM ユーザーから、他のアカウントのロールにスイッチする

第8章 IAMとCloudFormation

複数の AWS アカウントに、同じようなポリシーやロールを作る場合、CloudFormation 化しておけば人的ミスを排除できる
IAM ユーザーは基本的に一度作っておしまいなので、CloudFormation のライフサイクルで管理するメリットがほとんどない。そのため管理対象から外すことを推奨する

第9章 IAMのテンプレート集

本書のテンプレート集のダウンロード URL
管理者グループには IP 制限を加えるべきだが、IP 制限があると CloudFormation 等の一部の機能が使えない場合がある。そのため、スイッチロールを指定して IP 制限を解除できるようにしておく
管理者ロールへスイッチできるユーザーを限定する方法としては、以下の2通りがある
- ロールに、スイッチ可能なユーザーを記載する（本書のテンプレートはこちらを採用）
- スイッチロールを原則拒否し、必要なユーザーのみスイッチロールの権限を付与する
ネットワークに関連する権限は多岐に渡るため、自分でリストアップするのは難しい。職務機能の AWS 管理ポリシー（AWS managed policies for job functions）にある NetworkAdministrator の利用を推奨する
開発者に、EC2 インスタンスを立ち上げるための権限を付与しようとすると、いまや EC2 に IAM ロールを付与するのは必須であるため、IAM ロールの作成・更新に関する権限が必要。そうすると、実質的に何でもできてしまう
- 現実的な対応としては、開発環境では管理者権限を付与した上でしっかり監査証跡を残す

第10章 IAM以外のAWSサービスの活用

AWS Organizations（組織アカウント）
- ルートと呼ばれるマスターアカウントと、それに紐づく子アカウントがある。また、子アカウントを階層化するための組織単位がある
- アカウントに対するポリシーと言う形で、ホワイトリスト／ブラックリスト形式で権限の管理ができる
- 上位で決めたポリシーは、個々のアカウント単位で打ち消すことはできない（強力な統制）
CloudTrail と Config
- CloudTrail と Config は対となるようなサービス
- CloudTrail は操作ログの記録
- Config は操作の結果どういう状態になったのかの記録、および状態変更に対するアクションの定義
Amazon GuardDuty
- 脅威検出と継続的なモニタリングサービス
AWS Control Tower と AWS Security Hub
- AWS Control Tower は複数アカウントの設定および管理
- Security Hub は複数のアカウントの状況を一括してモニタリング

付録A アカウント開設時の設定チェックリスト

セキュリティの強化
- 1) ルートアカウントの MFA 設定
- 2) IAM Group と IAM ユーザーの作成
- 3) IAM パスワードポリシーの適用
状況の出力・見える化
- 4) CloudTrail の有効化
- 5) Config の有効化
- 6) GuardDuty の有効化
- 7) Trusted Advisor の E メール通知設定
- 8) Cost Usage Report の出力
機能を使うための設定
- 9) ルートアカウントで IAM User への請求情報へのアクセス許可
- 10) 支払い通貨を日本円に変更
- 11) コスト配分タグの設定
- 12) 代替連絡先の設定

AWSの薄い本Ⅱ アカウントセキュリティのベーシックセオリー（発行日：2020年3月22日）

第1章 AWSアカウントセキュリティ

AWS のセキュリティを3つの観点から分類
- 1) AWS 上に構築するシステムのセキュリティ
- 2) AWS アカウント自体の管理(IAM の設計・運用)
- 3) セキュリティを維持管理するための施策
3は、いわゆる AWS アカウントのガードレール設計。本書の中心テーマの一つ
- IAM を運用しているうちに抜け漏れが出てきたり、カバーしきれない部分がでてきたときに、それらを予防・検知するための施策がガードレール設計
本書では AWS Organizations は基本的には解説せず、その一部の機能であるサービスコントロール Policy（SCP）のみを扱う

第2章ガードレールという設計と思想

Control Tower にはガードレールという機能がある
ガードレール設計の思想と、Control Tower が実際にそれをどのように実現しているのか
Control Tower は最小構成で3つの AWS アカウントで構成される
- マスターアカウント
- ログ管理用アカウント
- 監査用アカウント
一元管理と改ざん防止のため、ログ管理用アカウントと監査用アカウントが、その他のアカウント（開発環境用や本番環境用）から分離されている
Control Tower は、道から踏み外さないための予防と検知を提供する
- 予防：自分の権限外の操作（例えばログの削除）を禁止する
- 検知：ルールから外れた操作（例えばルートアカウントの利用）を検知する
Control Tower における予防と検知の実態は、Organization の SCP（Service Control Policy）と Config Rules
- ただし、Control Tower の個々のガードレール名を見ても、予防なのか検出なのかの区別がつかないという欠点がある

第3章 AWSのセキュリティサービス

NIST Cybersecurity Framework
CSF コア
- 特定（Identity）
- 防御（Protect）
- 検知（Detect）
- 対応（Respond）
- 復旧（Recover）
NST CSF コアを参照しながら、AWS のセキュリティサービスを整理する
CloudTrail のおすすめの設定の一つに、クロスアカウントロールを利用して他のアカウントに対してログを保存するという方法がある
- システム内で使う証跡情報はローカルの S3 バケットに保存し、監査用に集積する証跡情報は監査用 AWS アカウントのバケットに保存する
- こうすることにより、プロジェクトごとの利便性と、組織全体のガバナンスの両方を確保できる
GuardDuty の分析対象は、CloudTrail、VPC フローログ、DNS ログの3種類
Trusted Advisor は便利だが、現在は通知方法がEメールしか使えない

第4章サンドボックスアカウントの作成のチュートリアル

実験や検証に使う AWS アカウントのことを、本書ではサンドボックスアカウント（サンドボックス環境）と定義する
今回作るサンドボックス環境の要件
- 1) アカウントの利用者は一人(多人数でアカウントを共有しない)
- 2) 利用者はそのアカウント内では、ほぼ全ての権限を持つ(管理者権限)
- 3) 外部への情報漏えいにつながる行為、権限付与を禁止する
- 4) 問題となる行為を定義し、自動で検知・通知できるようにする
- 5) 問題検知時に通知だけでなく自動復旧を目指す
3の設定項目については、以下の4項目に具体化して考える
- IAM ユーザーの新規作成禁止
- アクセスキーの作成禁止
- S3 のパブリックアクセス禁止
- 不特定多数へのセキュリティグループ開放禁止
IAM Access Analyzer を有効にする
マスターアカウント側で CloudTrail の設定をして、メンバーアカウントから設定や削除ができないようにする
Config アグリゲータの設定をして、マルチアカウント・マルチリージョンで Config のデータを集約する
Security Hub を有効化する
Config Rule は登録時に設定した間隔で定期的にチェックされる（デフォルト12時間、最短1時間）
自動復旧は、複雑な処理が必要な場合は Lambda でスクリプトを書き、定形処理で済む場合は AWS System Manager（SSM）の Automation を使う
SCP の使い方としては、現状の仕様では "Effect": "Allow" を利用せず、"Effect": "Deny" で禁止すべき項目を設定していくほうがよい

第5章 CloudFormation を利用した構成管理

CloudFormation StackSets は、1つのテンプレートから複数の AWS アカウント・リージョンに対してスタックの作成・実行ができる機能
2020年2月12日に機能が追加され、Organizations からアカウントの作成・削除時や OU の移動時に指定しておいた StackSets を自動で実行できるようになった

第6章アカウントセキュリティの設計の考え方の原則

AWS Well-Architected フレームワーク（現時点の最新版は2020年7月）
NIST CSF コアと、AWS Well-Architected Framework を比べながらの解説
SEC 8「データをどのように分類していますか？」に該当する機能に、AWS Macie（機密データを検出、分類、保護するサービス）がある

第7章障害の検知と復旧の考え方

AWS に多数あるセキュリティ関係のサービス同士の関係についての解説
- 似たようなサービスもあるが、それをどう取捨選択するか
Security Hub と個別サービスの使い分けはシンプル
- システムの運用に関わる障害は、アカウント個別に設定
- AWS アカウントに対する攻撃については、複数のアカウントで共通設定