OpsJAWS#13 IAMベストプラクティス

#jawsug #opsjaws

Transcript

1. IAMの運用 ベストプラクティス OpsJAWS #15 クラスメソッド株式会社 AWS事業部 森永 大志
2. 森永 大志（もりなが たいし） • AWS事業部 ソリューションアーキテクト • 地味で大事なサービスがすき（だいたい緑のやつ） • 二人の娘のために生きてます 自己紹介
3. IAM運用どうしてます？
4. まずはAWS公式のベストプラク ティスを見てみる
5. AWS公式ベストプラクティス 1. AWS アカウントのルートユーザーのアクセスキーをロックする 2. 個々の IAM ユーザーの作成 3. IAM ユーザーへのアクセス権限を割り当てるためにグループを使用する 4. AWS 定義のポリシーを使用して可能な限りアクセス権限を割り当てる 5. 最小権限を付与する 6. アクセスレベルを使用して、IAM 権限を確認する 7. ユーザーの強力なパスワードポリシーを設定 8. 特権ユーザーに対して MFA を有効化する 9. Amazon EC2 インスタンスで実行するアプリケーションに対し、ロールを使用する 10. 認証情報を共有するのではなく、ロールを使って委託する 11. 認証情報を定期的にローテーションする 12. 不要な認証情報を削除する 13. 追加セキュリティに対するポリシー条件を使用する 14. AWS アカウントのアクティビティの監視 https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/best-practices.html
6. １．AWS アカウントのルートユーザーの 　　　　　　　　　　　アクセスキーをロックする • ルートユーザのアクセスキーは作らない／削除する ◦ ルートユーザーは制限することが出来ない ◦ IAMユーザ／ロールで出来ないことがほぼない ◦ アクセスキーは原則使うべきではない ⇒ 必ず実施すべき 後述するMFAの登録も忘れずに行う
7. （参考）ルートユーザでしか出来ないこと • アカウント関連の作業（支払い、解約など） • 逆引き設定の申請 • EC2からのメール送信制限の解除申請 • Route53で登録したドメインを別AWSアカウントに移管 • 侵入テスト申請など https://docs.aws.amazon.com/ja_jp/general/latest/gr/aws_tasks-that-require-root.html
8. ２．個々の IAM ユーザーの作成 • 複数人で一つのIAMユーザを使わない ◦ 認可の設定が出来なくなる ◦ CloudTrailであとから追えない ⇒ 必ず実施すべき 特例としてチーム内で参照権限だけならアリ？
9. ３．IAM ユーザーへのアクセス権限を 　　　　　　割り当てるためにグループを使用する • ユーザに直接ではなくグループに割り当てる ◦ ユーザに割り当てると同じ権限ユーザ作成が面倒 ◦ ポリシーでも権限をまとめられる ⇒ なるべくやったほうが良い ポリシーで同様の事が出来るのでそちらでやるのも手
10. ４．AWS 定義のポリシーを使用して可能な限り 　　　　　　　　　　　アクセス権限を割り当てる • なるべくAWSの管理ポリシーを使う ◦ 新しいサービス追加に自動で追随 ◦ 関連するAPIコールも追加してくれる ◦ 要らない権限までつく ⇒ 判断は後ほど
11. ５．最小権限を付与する • ユーザ／ロールが使う最小限の権限のみ与える ◦ やってはいけない操作を防ぐ ◦ 関係ないリソース操作を防ぐ ◦ 運用が死ぬほど大変 ◦ ４番の項目と相反してる ⇒ 判断は後ほど
12. ６．アクセスレベルを使用してIAM 権限を確認する • アクセスレベル（フル、制限など）を確認する ◦ どこまで出来るか概要を確認できる ⇒ 権限管理には使えるので使う どこまで権限管理するかは後ほど
13. ７．ユーザーの強力なパスワードポリシーを設定 • ユーザのパスワードポリシーを強化する ◦ 簡単なパスワードはすぐに突破される ◦ 文字数、大文字、小文字、数字、記号の要件 ◦ 定期的な更新は議論の余地あり ⇒ 必ず実施すべき ただし、ポリシーの内容については要検討
14. ８．特権ユーザーに対して MFA を有効化する • 強い権限を持つユーザーにMFAをつける ◦ パスワードは脆弱 ◦ What you knowとWhat you haveの併用 ⇒ 必ず実施すべき 特権ユーザーに限らずなるべく実施した方が良い
15. ９．Amazon EC2 インスタンスで実行する 　　　アプリケーションに対し、ロールを使用する • IAMユーザのアクセスキーではなくIAMロールを使う ◦ アクセスキーは管理が面倒 ◦ IAMロールは一時的なアクセスキーを発行 ▪ つまり漏れてもすぐに使えなくなる ⇒ 必ず実施すべき アクセスキーは最後の手段！使わない方法を考える！
16. １０．認証情報を共有するのではなく 　　　　　　　　　　　　ロールを使って委託する • IAMユーザを作るのではなくIAMロールでスイッチする ◦ パスワードは脆弱 ◦ １つのアカウントから別アカウントへスイッチ可能 ◦ IAMロールで権限管理も出来る ⇒ 必ず実施すべき 複数アカウントで認証情報管理は人類に向かない １アカウントにIAMユーザー（MFA付き）でスイッチ AD連携などでフェデレーションするのもあり
17. １１．認証情報を定期的にローテーションする • パスワード、アクセスキーを定期的に変更 ◦ パスワードの定期変更は議論の余地あり ◦ アクセスキーは影響範囲が分かりづらい ⇒ 出来ればやりたい アクセスキーを基本的に使わないようにする 影響範囲が狭くなるため、運用しやすくなる
18. １２．不要な認証情報を削除する • 使ってないパスワード／アクセスキーを削除する ◦ アプリでしか使わないユーザはパスワード不要 ◦ コンソールしか使わないユーザはアクセスキー不要 ⇒ なるべくやったほうが良い 頻繁には難しければ、定期的に棚卸しする そもそもアクセスキーは発行せずIAMロールで コンソールアクセスもIAMロールで
19. １３．追加セキュリティに対する 　　　　　　　　　　　　ポリシー条件を使用する • IAMポリシーを細く設定する ◦ API呼び出し元IPアドレスや時間指定が可能 ◦ 管理が死ぬほど面倒 ⇒ 判断は後ほど
20. １４．AWS アカウントのアクティビティの監視 • アクセスログ、監査ログをとる ◦ CloudTrailでAPI呼び出しログ ◦ Configでリソースの変更ログ ◦ CloudFront/ELB/S3などでアクセスログ ⇒ 必ず実施すべき 少しコストが掛かるが誤差レベル Configは変更毎に課金されるので要調整
21. ひとまずの個人的まとめ • ルートユーザは通常運用では使ってはならない • IAMユーザはなるべく使わないでIAMロールにする • アクセスキーは最終手段なのでIAMロールで実現 • ログはちゃんと取る • MFAは基本的に有効化する（仮想でもいい） • とはいえパスワードはなるべく強力に • IAMロール使うとだいたい解決
22. 残った課題
23. AWS公式ベストプラクティス 1. AWS アカウントのルートユーザーのアクセスキーをロックする 2. 個々の IAM ユーザーの作成 3. IAM ユーザーへのアクセス権限を割り当てるためにグループを使用する 4. AWS 定義のポリシーを使用して可能な限りアクセス権限を割り当てる 5. 最小権限を付与する 6. アクセスレベルを使用して、IAM 権限を確認する 7. ユーザーの強力なパスワードポリシーを設定 8. 特権ユーザーに対して MFA を有効化する 9. Amazon EC2 インスタンスで実行するアプリケーションに対し、ロールを使用する 10. 認証情報を共有するのではなく、ロールを使って委託する 11. 認証情報を定期的にローテーションする 12. 不要な認証情報を削除する 13. 追加セキュリティに対するポリシー条件を使用する 14. AWS アカウントのアクティビティの監視 https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/best-practices.html
24. IAMの権限をどうするか
25. 最小権限にした時のよくあるシナリオ 運用者： このIAMユーザを使ってください！ 開発者： 了解でーす
26. 最小権限にした時のよくあるシナリオ 運用者： 権限付与します！！ 開発者： ◯◯しようとすると 権限不足なんですが…
27. 最小権限にした時のよくあるシナリオ 運用者： 権限付与します！！！！ 開発者： まだ、XXの権限が足りないとでます…
28. 最小権限にした時のよくあるシナリオ 運用者： 権限付与します！！！！！！ 開発者： 今度は△△しようとすると権限不足…
29. 最小権限にした時のよくあるシナリオ 運用者： つらい 開発者： またダメだ！！！！！！ やってられるか！！！！！！
30. 問題点 • AWSは一つの操作でも複数のAPIを呼ぶことがある ◦ 完璧な最小権限は難しい（というか無理？） • 何かやるたびに問い合わせが必要だと開発者のモチベーショ ンはだだ下がり • 問い合わせが増えるとIAMの運用者はつらい
31. やれる体制があるならやるべき
32. • ほぼ専門チームを作ってIAMの棚卸し実施 • 見直しだけで１週間かかる • 数が増えたら… （参考）リクルートテクノロジーズさん運用事例 https://www.slideshare.net/recruitcojp/20160517-security-jaws-miyazakisachie
33. やれる体制がない場合どうする
34. レベル１
35. PowerUser権限を渡して一部Deny • 基本的に全てのサービス／リソースを触れる • 触らせたくないサービス／リソースだけDeny • メリット ◦ 運用はほぼなし ◦ 権限不足で悩まなくていい • デメリット ◦ セキュリティ的にイケてない？
36. （Tips）PowerUserはIAMロールを付与できない • PowerUser権限は”iam:*”以外を許可している • リソースへのIAMロール付与ができない • “iam:PassRole”の権限を付ければいけます { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "iam:Get*", "iam:List*", "iam:PassRole" ], "Resource": "*" } ] }
37. レベル２
38. 使うサービスの権限だけAWS管理ポリシーを渡す • EC2FullAccessなどの管理ポリシーを使う • 使う可能性のあるポリシーだけを割り当てる • メリット ◦ 運用は比較的楽 • デメリット ◦ 別のサービスを見にいくサービスがある（特に参照） ◦ 許可したサービスについてはなんでもできちゃう
39. レベル３
40. 職務機能別のAWS管理ポリシーをつかう • データベース管理者、システム管理者など職務別にポリシー が存在している • 足りない部分は適宜付け足す • メリット ◦ 職務に必要そうな権限は付与されるのでそこは楽 • デメリット ◦ 足りない権限が多分にあるので結局運用は必要
41. どれを選択するかは 組織体制や仕組みづくり次第 どれかが正解というわけではないです
42. IAMの権限をガッチガチにするより • 問題発生時に対応できる仕組み作りが重要では？ ◦ CloudTrailでログ分析 ◦ Configで変更監視 ◦ Config Rulesで設定値を監視 • 外部から不正利用されないようにベスプラを守る ◦ 内部犯行はほぼ防げない • そもそも組織が違うならアカウント自体を変える • 不要なユーザは消す
43. （参考）認証情報レポートが棚卸しに便利 • アカウント内の全てのユーザとユーザの認証に関する情報が 一覧にまとめられたレポート • パスワード／アクセスキーが使用されていない、MFAが有効 化されていない、などを見れる • CSVファイルなので分析に回すのも簡単 https://dev.classmethod.jp/cloud/iam-report/
44. まとめ • IAMの権限管理は自分の組織に合わせて方針を決める • 無理して厳しくしすぎずに即座に対応できる仕組みを • 運用者も開発者も疲弊しないように最善を探る • 自動チェックなどはどんどんやるべき ◦ 自動修正は諸刃の剣なので人力は必要…