昨日の続き。
IAM
IAMを考えるためには、どんなステークホルダーがいてそれぞれどんな責務で、どんなユースケースを持っているか、を情報として整理する。
それによって、どこまでを管理者の権限で許し、どこからは開発者（ユーザー）の自由とするかを決定し、誰の担当かが不明確な作業を減らしていく。
Black Beltの内容を見ていると、アーキテクティングそのものだなと思う。
ちなみに、IAMはそのサービスの性質上、権限の話を中心にすることになるので、ホワイトリスト方式・ブラックリスト方式、どちらでいくのか、というあたりは慎重に判断をしないといけないのだけれど、どちらにせよ「必要最小限」を最初から与えることは難しいので進めながら調整するしかない、という記載があって、現実的で好感が持てた。
AWS Black Belt Online Seminar AWSサービスの権限管理 https://www.slideshare.net/AmazonWebServicesJapan/aws-black-belt-online-seminar-aws
IAMのベストプラクティスについては、4つの観点から整理できるみたい。
- IDと認証情報の管理
- ルートユーザーのアクセスキーを使わない（ルートじゃないとできないのは課金情報へのアクセス権設定、サポートプランの変更、脆弱性診断フォーム提出、逆引きDNS申請、CloudFrontキーペアの作成、解約あたりだけ）
- パスワードポリシーを強力にする
- アクセスキーを共有しない
- 強い権限を持つユーザーはMFAを有効にする
- アクセス権限の管理
- AWS管理ポリシーを適用する（詳細な知識がないと難しいらしい？）
- 個別のユーザー（IAMエンティティ）へのアクセス権設定をする（インラインポリシー設定する）のではなく、グループへの設定をする（カスタマー管理ポリシー設定する）
- 権限の委任
- EC2上で実行するアプリへはIAMロールを使って権限を与えればセッションとして一定のタイミングで認証が切れるので安全性が高く、その上、AWS SDKを使用することで認証情報の取得や期限切れに伴う再取得を自動実行できる
- IAMロールを一時的に昇格させるようなことができ、開発用のアカウントが本番用のアカウントの権限のロールを一時的に取得して本番環境のS3にアクセス、といった使い方ができる
- 組織内の全員についてIAMユーザーを作らなくてもAWSを使える仕組みをSAMLを使ったIDフェデレーションで実現できる
- IDと権限のライフサイクル管理
- アクセスレベルはリスト、読み込み、書き込み、権限の管理の4分類
- Service Last Accessed Dataを使用して、つかっわれていない権限を確認する
- Credential Reportでユーザーの作成日時や最後に使われた日、最後に利用したAWSサービスなどが見れる、AWS CLIならaws iam generate-credential-report、aws iam get-credential-report
その他Tipsとして、
* 初期設定で全社員が入ったグループ、管理者のみが入ったグループ、個別に必要なグループなどを作って個別に権限を、必要なレベルでのみ付して、定期的に見直すのが良い
* IAMリソースを探すにはダッシュボード上部の検索BOXから検索するのが早い
* IAMの設定はJSONだけでなくビジュアルエディターもある（最後は全部JSONになるんだろうけど......）
* IAMロール名は大文字小文字が区別される
WAFとセキュリティ周り
この概念整理がとても分かりやすくてよかった。
出所：AWS Black Belt Online Seminar 2017 AWS WAF https://www.slideshare.net/AmazonWebServicesJapan/20171122-aws-blackbeltawswafowasptop10
WAFだけでは全ては守れない、守れる範囲守れない範囲はこんな感じ、というのがぱっと見てわかる。
これまでのWAFは設定が複雑で、擬陽性の発生が増えていく、APIもない、（人的にも導入にも）コストも高い、ということで、AWS WAFだとその辺りを解決している。
AWS WAF以外の選択肢として、Marketplace WAFsも選択肢として取れる。
EC2インスタンス上に立てることになり、また設定等々にはある程度作業が必要になることもあるが、オンプレの環境をクラウドにリフトするときには便利。
また、AWS WAFを使用しながら、Marketplace WAFsで適用されているManagedなルールセットを適用することも可能。（従量制課金）
設定時にAllow/Blockだけではなく、Countも選べるので、
ルールを設定、Countで誤検知がないか確認、Blockに変更、という流れを取ることができる。
課金はWeb ACLの数、Ruleの数、リクエストの数、からそれぞれ。（資料内だと$5/Web ACL, $1/Rule, $0.60/mil Requests）
Conditionを作って、RuleでAND/OR等々の組み合わせを作って、それを保護リソースなどを指定するWeb ACLに追加することで適用する流れみたい。
あとは、Amazon Inspector（脆弱性分析）とAmazon Macie（ユーザーの振る舞い分析から特異値発見）あたりも併用するとよりよいかも。
ちなみに、2020年に更新されたBlack Beltだと次の図に更新されていた。（著者が違うから当たり前だけど）
出所：[AWS Black Belt Online Seminar] AWS WAFアップデート 資料及び QA 公開 | Amazon Web Services ブログ https://aws.amazon.com/jp/blogs/news/webinar-bb-aws-waf-update-2020/
この更新にまとまっていたけど、従来だとALBとCloudFrontにしか適用できなかったWAFが、API Gatewayにも対応した模様。また書き方や書けるルールの数なども更新があった。
あとは、WCU（WAF Capacity Unit）という、条件の組み合わせの重さを量る概念ができていて、複雑な条件文を処理させる場合はこの値の使用量が多くなり、トータルでは1500を超えられないように決まっている模様。
運用していくにあたっては、次の2点は考慮する必要がある様子。
* ルールポリシー（Allow listでいくかBlock listでいくか）
* ルールの運用（セルフサービスでいくか、Marketplace or AWS Managedのルールでいくか）
CloudWatchとの連携とか、インシデントレスポンス、Amazon SNS/Amazon SESとかで飛ばしていくとか、Kinesis Data Firehoseで飛ばしてElasticsearchで分析するとかもあったけど、どこまでやるかな。それこそリスクベースのアプローチになると思うんだけど。
とりあえずお腹いっぱいになりました。