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

#jawsug #opsjaws

Transcript

1. IAMの運用
   ベストプラクティス
   OpsJAWS #15
   クラスメソッド株式会社 AWS事業部 森永 大志
   

   View Slide

2. 森永 大志（もりなが たいし）
   ● AWS事業部 ソリューションアーキテクト
   ● 地味で大事なサービスがすき（だいたい緑のやつ）
   ● 二人の娘のために生きてます
   自己紹介
   

   View Slide

3. IAM運用どうしてます？
   

   View Slide

4. まずはAWS公式のベストプラク
   ティスを見てみる
   

   View Slide

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
   

   View Slide

6. １．AWS アカウントのルートユーザーの
   　　　　　　　　　　　アクセスキーをロックする
   ● ルートユーザのアクセスキーは作らない／削除する
   ○ ルートユーザーは制限することが出来ない
   ○ IAMユーザ／ロールで出来ないことがほぼない
   ○ アクセスキーは原則使うべきではない
   ⇒ 必ず実施すべき
   後述するMFAの登録も忘れずに行う
   

   View Slide

7. （参考）ルートユーザでしか出来ないこと
   ● アカウント関連の作業（支払い、解約など）
   ● 逆引き設定の申請
   ● EC2からのメール送信制限の解除申請
   ● Route53で登録したドメインを別AWSアカウントに移管
   ● 侵入テスト申請など
   https://docs.aws.amazon.com/ja_jp/general/latest/gr/aws_tasks-that-require-root.html
   

   View Slide

8. ２．個々の IAM ユーザーの作成
   ● 複数人で一つのIAMユーザを使わない
   ○ 認可の設定が出来なくなる
   ○ CloudTrailであとから追えない
   ⇒ 必ず実施すべき
   特例としてチーム内で参照権限だけならアリ？
   

   View Slide

9. ３．IAM ユーザーへのアクセス権限を
   　　　　　　割り当てるためにグループを使用する
   ● ユーザに直接ではなくグループに割り当てる
   ○ ユーザに割り当てると同じ権限ユーザ作成が面倒
   ○ ポリシーでも権限をまとめられる
   ⇒ なるべくやったほうが良い
   ポリシーで同様の事が出来るのでそちらでやるのも手
   

   View Slide

10. ４．AWS 定義のポリシーを使用して可能な限り
    　　　　　　　　　　　アクセス権限を割り当てる
    ● なるべくAWSの管理ポリシーを使う
    ○ 新しいサービス追加に自動で追随
    ○ 関連するAPIコールも追加してくれる
    ○ 要らない権限までつく
    ⇒ 判断は後ほど
    

    View Slide

11. ５．最小権限を付与する
    ● ユーザ／ロールが使う最小限の権限のみ与える
    ○ やってはいけない操作を防ぐ
    ○ 関係ないリソース操作を防ぐ
    ○ 運用が死ぬほど大変
    ○ ４番の項目と相反してる
    ⇒ 判断は後ほど
    

    View Slide

12. ６．アクセスレベルを使用してIAM 権限を確認する
    ● アクセスレベル（フル、制限など）を確認する
    ○ どこまで出来るか概要を確認できる
    ⇒ 権限管理には使えるので使う
    どこまで権限管理するかは後ほど
    

    View Slide

13. ７．ユーザーの強力なパスワードポリシーを設定
    ● ユーザのパスワードポリシーを強化する
    ○ 簡単なパスワードはすぐに突破される
    ○ 文字数、大文字、小文字、数字、記号の要件
    ○ 定期的な更新は議論の余地あり
    ⇒ 必ず実施すべき
    ただし、ポリシーの内容については要検討
    

    View Slide

14. ８．特権ユーザーに対して MFA を有効化する
    ● 強い権限を持つユーザーにMFAをつける
    ○ パスワードは脆弱
    ○ What you knowとWhat you haveの併用
    ⇒ 必ず実施すべき
    特権ユーザーに限らずなるべく実施した方が良い
    

    View Slide

15. ９．Amazon EC2 インスタンスで実行する
    　　　アプリケーションに対し、ロールを使用する
    ● IAMユーザのアクセスキーではなくIAMロールを使う
    ○ アクセスキーは管理が面倒
    ○ IAMロールは一時的なアクセスキーを発行
    ■ つまり漏れてもすぐに使えなくなる
    ⇒ 必ず実施すべき
    アクセスキーは最後の手段！使わない方法を考える！
    

    View Slide

16. １０．認証情報を共有するのではなく
    　　　　　　　　　　　　ロールを使って委託する
    ● IAMユーザを作るのではなくIAMロールでスイッチする
    ○ パスワードは脆弱
    ○ １つのアカウントから別アカウントへスイッチ可能
    ○ IAMロールで権限管理も出来る
    ⇒ 必ず実施すべき
    複数アカウントで認証情報管理は人類に向かない
    １アカウントにIAMユーザー（MFA付き）でスイッチ
    AD連携などでフェデレーションするのもあり
    

    View Slide

17. １１．認証情報を定期的にローテーションする
    ● パスワード、アクセスキーを定期的に変更
    ○ パスワードの定期変更は議論の余地あり
    ○ アクセスキーは影響範囲が分かりづらい
    ⇒ 出来ればやりたい
    アクセスキーを基本的に使わないようにする
    影響範囲が狭くなるため、運用しやすくなる
    

    View Slide

18. １２．不要な認証情報を削除する
    ● 使ってないパスワード／アクセスキーを削除する
    ○ アプリでしか使わないユーザはパスワード不要
    ○ コンソールしか使わないユーザはアクセスキー不要
    ⇒ なるべくやったほうが良い
    頻繁には難しければ、定期的に棚卸しする
    そもそもアクセスキーは発行せずIAMロールで
    コンソールアクセスもIAMロールで
    

    View Slide

19. １３．追加セキュリティに対する
    　　　　　　　　　　　　ポリシー条件を使用する
    ● IAMポリシーを細く設定する
    ○ API呼び出し元IPアドレスや時間指定が可能
    ○ 管理が死ぬほど面倒
    ⇒ 判断は後ほど
    

    View Slide

20. １４．AWS アカウントのアクティビティの監視
    ● アクセスログ、監査ログをとる
    ○ CloudTrailでAPI呼び出しログ
    ○ Configでリソースの変更ログ
    ○ CloudFront/ELB/S3などでアクセスログ
    ⇒ 必ず実施すべき
    少しコストが掛かるが誤差レベル
    Configは変更毎に課金されるので要調整
    

    View Slide

21. ひとまずの個人的まとめ
    ● ルートユーザは通常運用では使ってはならない
    ● IAMユーザはなるべく使わないでIAMロールにする
    ● アクセスキーは最終手段なのでIAMロールで実現
    ● ログはちゃんと取る
    ● MFAは基本的に有効化する（仮想でもいい）
    ● とはいえパスワードはなるべく強力に
    ● IAMロール使うとだいたい解決
    

    View Slide

22. 残った課題
    

    View Slide

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
    

    View Slide

24. IAMの権限をどうするか
    

    View Slide

25. 最小権限にした時のよくあるシナリオ
    運用者：
    このIAMユーザを使ってください！
    開発者：
    了解でーす
    

    View Slide

26. 最小権限にした時のよくあるシナリオ
    運用者：
    権限付与します！！
    開発者：
    ◯◯しようとすると
    権限不足なんですが…
    

    View Slide

27. 最小権限にした時のよくあるシナリオ
    運用者：
    権限付与します！！！！
    開発者：
    まだ、XXの権限が足りないとでます…
    

    View Slide

28. 最小権限にした時のよくあるシナリオ
    運用者：
    権限付与します！！！！！！
    開発者：
    今度は△△しようとすると権限不足…
    

    View Slide

29. 最小権限にした時のよくあるシナリオ
    運用者：
    つらい
    開発者：
    またダメだ！！！！！！
    やってられるか！！！！！！
    

    View Slide

30. 問題点
    ● AWSは一つの操作でも複数のAPIを呼ぶことがある
    ○ 完璧な最小権限は難しい（というか無理？）
    ● 何かやるたびに問い合わせが必要だと開発者のモチベーショ
    ンはだだ下がり
    ● 問い合わせが増えるとIAMの運用者はつらい
    

    View Slide

31. やれる体制があるならやるべき
    

    View Slide

32. ● ほぼ専門チームを作ってIAMの棚卸し実施
    ● 見直しだけで１週間かかる
    ● 数が増えたら…
    （参考）リクルートテクノロジーズさん運用事例
    https://www.slideshare.net/recruitcojp/20160517-security-jaws-miyazakisachie
    

    View Slide

33. やれる体制がない場合どうする
    

    View Slide

34. レベル１
    

    View Slide

35. PowerUser権限を渡して一部Deny
    ● 基本的に全てのサービス／リソースを触れる
    ● 触らせたくないサービス／リソースだけDeny
    ● メリット
    ○ 運用はほぼなし
    ○ 権限不足で悩まなくていい
    ● デメリット
    ○ セキュリティ的にイケてない？
    

    View Slide

36. （Tips）PowerUserはIAMロールを付与できない
    ● PowerUser権限は”iam:*”以外を許可している
    ● リソースへのIAMロール付与ができない
    ● “iam:PassRole”の権限を付ければいけます
    {
    "Version": "2012-10-17",
    "Statement": [
    {
    "Effect": "Allow",
    "Action": [
    "iam:Get*",
    "iam:List*",
    "iam:PassRole"
    ],
    "Resource": "*"
    }
    ]
    }
    

    View Slide

37. レベル２
    

    View Slide

38. 使うサービスの権限だけAWS管理ポリシーを渡す
    ● EC2FullAccessなどの管理ポリシーを使う
    ● 使う可能性のあるポリシーだけを割り当てる
    ● メリット
    ○ 運用は比較的楽
    ● デメリット
    ○ 別のサービスを見にいくサービスがある（特に参照）
    ○ 許可したサービスについてはなんでもできちゃう
    

    View Slide

39. レベル３
    

    View Slide

40. 職務機能別のAWS管理ポリシーをつかう
    ● データベース管理者、システム管理者など職務別にポリシー
    が存在している
    ● 足りない部分は適宜付け足す
    ● メリット
    ○ 職務に必要そうな権限は付与されるのでそこは楽
    ● デメリット
    ○ 足りない権限が多分にあるので結局運用は必要
    

    View Slide

41. どれを選択するかは
    組織体制や仕組みづくり次第
    どれかが正解というわけではないです
    

    View Slide

42. IAMの権限をガッチガチにするより
    ● 問題発生時に対応できる仕組み作りが重要では？
    ○ CloudTrailでログ分析
    ○ Configで変更監視
    ○ Config Rulesで設定値を監視
    ● 外部から不正利用されないようにベスプラを守る
    ○ 内部犯行はほぼ防げない
    ● そもそも組織が違うならアカウント自体を変える
    ● 不要なユーザは消す
    

    View Slide

43. （参考）認証情報レポートが棚卸しに便利
    ● アカウント内の全てのユーザとユーザの認証に関する情報が
    一覧にまとめられたレポート
    ● パスワード／アクセスキーが使用されていない、MFAが有効
    化されていない、などを見れる
    ● CSVファイルなので分析に回すのも簡単
    https://dev.classmethod.jp/cloud/iam-report/
    

    View Slide

44. まとめ
    ● IAMの権限管理は自分の組織に合わせて方針を決める
    ● 無理して厳しくしすぎずに即座に対応できる仕組みを
    ● 運用者も開発者も疲弊しないように最善を探る
    ● 自動チェックなどはどんどんやるべき
    ○ 自動修正は諸刃の剣なので人力は必要…
    

    View Slide