どこから始める？AWSセキュリティ成熟度モデルで次のアクションを可視化しよう！

セキュリティ対策をどこから始めればいいの？今の対策は適切なの？
そんなお悩みありませんか？このセッションでは、AWSセキュリティ成熟度モデルを使って、これらの疑問を解決する方法をご紹介します。自分のAWS環境のセキュリティレベルを可視化しながら、次に取るべきアクションを一緒に見つけていきましょう！今すぐに使える実践的なヒントが満載です。

Transcript

1. 2024.7.31 AWS事業本部 松波花奈 どこから始める？ AWSセキュリティ成熟度モデルで 次のアクションを可視化しよう！
2. 本セッションの資料は 「DevelopersIO」で公開します 2 事前のご連絡
3. Xへの投稿の際は、 ハッシュタグ #cm_odyssey でお願いいたします。 3 お願い
4. ⾃⼰紹介 松波 花奈（まつなみ かな）/ おつまみ • AWS事業本部コンサルティング部 • ソリューションアーキテクト • 2022年9⽉⼊社 • 2024 Japan AWS Top Engineer (Security)& All Certs • 好きなAWSサービス：AWS Security Hub 4
5. アジェンダ • はじめに • 基礎編 ◦ AWSにおけるセキュリティの基本 ◦ AWSセキュリティ成熟度モデルとは • 実践編 ◦ AWSセキュリティ成熟度モデル各フェーズでの対策 • まとめ 5
6. アジェンダ • はじめに • 基礎編 ◦ AWSにおけるセキュリティの基本 ◦ AWSセキュリティ成熟度モデルとは • 実践編 ◦ AWSセキュリティ成熟度モデル各フェーズでの対策 • まとめ 6
7. 本セッションの対象者 • 既にAWSを利⽤していて、セキュリティ対策に不安を感 じている⽅ • どのセキュリティ対策から始めればいいかお悩みの⽅ レベル200を想定してお話しします 7 • レベル100：⼊⾨セッション、サービスの概要レベル • レベル200：中級セッション、サービスのベストプラクティスや機能の詳細レベル • レベル300：上級セッション、トピックの詳細レベル • レベル400：エキスパートセッション、サービスに精通しており、独⾃ソリューションを実装しているレベル
8. 本セッションでお話しすること お話しすること • AWSにおけるセキュリティの基本的な考え⽅ • AWSセキュリティ成熟度モデルを利⽤したセキュ リティレベルの可視化⽅法 お話ししないこと • フェーズ3,4にあたるセキュリティ対策 8
9. 本セッションの⽬的 9 • AWSセキュリティ成熟度モデル 便利だな〜 • このモデルでやるべきセキュリ ティ対策を洗い出そう！
10. アジェンダ • はじめに • 基礎編 ◦ AWSにおけるセキュリティの基本 ◦ AWSセキュリティ成熟度モデルとは • 実践編 ◦ AWSセキュリティ成熟度モデル各フェーズでの対策 • まとめ 10
11. AWSのセキュリティ対策 ばっちりできていますか？ 11
12. どう答えればいいんだろう‧‧ 12 • Security Hub ◦ 有効化はできているけど、スコアは 継続的に維持できていない‧‧ • GuardDuty ◦ 有効化はできているけど、検知した 脅威に対応できていない‧‧ • インシデント管理 ◦ ⼿順書はあるけど、最近いつ使った た？
13. AWS責任共有モデル(1/2) 13 引用: AWS - クラウドセキュリティ - 責任共有モデル
14. AWS責任共有モデル(2/2) 14 引用: AWS - クラウドセキュリティ - 責任共有モデル この範囲すべてを 対策する責任がある
15. AWS特有のセキュリティリスク 15 • ネットワークセキュリティリスク ◦ AWSサービスはインターネットを介して利⽤されるため、外部からの不正 アクセスのリスクがある。 • アクセス権限の設定ミス ◦ AWSリソースへのアクセス権限を誤って設定すると、意図せず第三者に データやリソースが公開されてしまう可能性があります。 • 不正利⽤によるコスト増 ◦ 従量課⾦制のため、必要以上のリソースをプロビジョニングしてしまう と、⾼額な請求が発⽣するリスクがある。(ex. コインマイニング）
16. アジェンダ • はじめに • 基礎編 ◦ AWSにおけるセキュリティの基本 ◦ AWSセキュリティ成熟度モデルとは • 実践編 ◦ AWSセキュリティ成熟度モデル各フェーズでの対策 • まとめ 16
17. AWSセキュリティ成熟度モデルとは 17 • AWSセキュリティ対策がどの程度実現 できているか定量的に測るためのフ レームワーク • AWS公式ドキュメントではないが、多 くのユーザーで活⽤実績がある • 9つのセキュリティカテゴリと4段階の フェーズに区切ってセキュリティ対策 がマッピングされている 引⽤ ：https://maturitymodel.security.aws.dev/en/model/
18. 9つのセキュリティカテゴリ 18
19. 4段階のフェーズ 19 • 「クイックウィン」〜「最適化」まで、4 段階のフェーズ分け • はじめに⽬指す指針としてはフェーズ 2 の「基礎」 クイックウィン 基礎 効率化 最適化 フェーズ 1 フェーズ 2 フェーズ 3 フェーズ 4 はじめの⽬標
20. 評価⽅法(1/2) 20 引⽤：https://maturitymodel.security.aws.dev/en/model/ ダウンロード
21. 評価⽅法(2/2) 21 引⽤：https://maturitymodel.security.aws.dev/en/model/ ①チェック ②必要に応じてコメント
22. 評価結果 22 カテゴリごとに達成レベルが可視化！ 不⾜部分のセキュリティ 対策を強化！
23. 使⽤する際の注意点 23 • AWSセキュリティ成熟度モデルはあくまで指標 • フェーズ3,4は、より⾼度なセキュリティ対策のため必ずしも満たす必要はない ◦ 実際に運⽤する場合には実現が難しいことがある ◦ 「⼀般的な⽬指すべき理想の状態の1つ」と捉える • 各推奨事項を深く理解するためには、AWSセキュリティに関する専⾨的な知識が 必要 ◦ AWS Certified Security - Specialty有資格者 ◦ 有資格者がいなければ取得を推進する
24. アジェンダ • はじめに • 基礎編 ◦ AWSにおけるセキュリティの基本 ◦ AWSセキュリティ成熟度モデルとは • 実践編 ◦ AWSセキュリティ成熟度モデル各フェーズでの対策 • まとめ 24
25. フェーズ2まで説明対象 25 • はじめに⽬指す指針としてはフェーズ 2 の「基礎」 • 弊社独⾃の観点を⼊れ替えたクラスメソッド流のセキュリティ成熟 度モデルの対策 クイックウィン 基礎 効率化 最適化 フェーズ 1 フェーズ 2 フェーズ 3 フェーズ 4 はじめの⽬標
26. フェーズ1 26 • クイックウィンは⽂字通りすぐに実施できる設定やサービスの有効 化がメイン • ここであげられる推奨事項はすべて 1 週間以内に実装できるものな ので、すぐに完了させましょう！ クイックウィン 基礎 効率化 最適化 フェーズ 1 フェーズ 2 フェーズ 3 フェーズ 4 はじめの⽬標
27. フェーズ1の項⽬ 27 CAF カテゴリ 項目 セキュリティガバナンス セキュリティインシデントの連絡先を最新化 利用しないリージョンを無効化（※オプション） セキュリティ保証 AWS Security Hub によるベストプラクティスの自動化 アイデンティティとアクセス管理 多要素認証 ルートユーザーを利用せず、さらに監査する IAM Access Analyzer によるアクセスとロールの分析 脅威検出 Amazon GuardDuty による脅威検出 AWS CloudTrail による API 呼び出しの監査 AWS Trusted Advisor で発見した Security findings の修復 異常検出のための課金アラーム 脆弱性管理 Amazon Inspectorを利用した脆弱性情報の収集 
 インフラ保護 セキュリティグループによるアクセス制限 データ保護 Amazon S3 のパブリックアクセスのブロック Amazon Macie によるデータセキュリティの分析（※オプション） 
 アプリケーションのセキュリティ AWS WAF のマネージドルール インシデント対応 Amazon GuardDuty の検出に対応
28. 1.1.1 セキュリティインシデントの連絡先を最新化 28 • 検討内容 ◦ AWSアカウントの連絡先情報で「セキュリティ問い合わせ先」を登録 ◦ 万が⼀AWSアカウントで不正利⽤等が発⽣した場合に、この連絡先に通知されるため、常に これを受け取れるようにして確認する必要がある • 完了条件 ◦ クラスメソッドメンバーズご加⼊の⽅ ▪ CMP(クラスメソッドメンバーズポータル)にて「AWSアカウント通知先」で「セキュリ ティ通知先」を登録すればOK ◦ クラスメソッドメンバーズご加⼊ではない⽅ ▪ ルートユーザーでAWSアカウントにログインし、右上の[Contact information] (連絡先 情報)から「主要連絡先」「セキュリティ問い合わせ先」を登録すればOK • 参考 ◦ クラスメソッドメンバーズポータル - AWSアカウント通知先 ◦ AWS アカウント連絡先情報を更新 \- AWS アカウント管理 フェーズ1 (1/16)
29. 1.1.2 利⽤しないリージョンを無効化 29 • 検討内容 ◦ すでにAWS OrganizationsやAWS Control Towerを利⽤している場合は対応を強く推奨 ◦ ⼀⽅、リージョンの利⽤制限はAWS OrganizationsのSCPを利⽤する必要があり、AWSアカウ ント単体やプロジェクトレベルの取り組みではないため利⽤していない場合はオプション • 完了条件 ◦ SCPによりリージョン制限を設定すればOK ◦ AWS Control Towerを利⽤していればマネージド機能を利⽤を推奨します。利⽤していなけれ ば「SCPの⼀般的な例」を参考に設定 • 参考 ◦ [⼩ネタ]AWS OrganizationsのSCPで特定リージョンのみ使⽤できるようにする ◦ SCPの⼀般的な例 \- AWS Organizations オプション フェーズ1 (2/16)
30. 1.2.1 Security Hub によるベストプラクティスの ⾃動化 30 • 検討内容 ◦ AWS Security Hubを利⽤してAWS基礎セキュリティベストプラクティスのスタンダードによ るAWS環境のセキュリティチェックを実施 ◦ AWS Security Hubを利⽤することで、AWS環境の危険な設定を検出して是正するフローを回 すことが可能 • 完了条件 ◦ AWS Security Hubを「AWS 基礎セキュリティのベストプラクティス v1.0.0」のスタンダード で全リージョンを有効にします。 ◦ フェーズ1では有効化のみでOKだが、検出された項⽬のうちCritical(重⼤)のものは即時対応 がおすすめ • 参考 ◦ Security Hub を有効にする \- AWS Security Hub フェーズ1 (3/16)
31. 1.3.1 多要素認証 31 • 検討内容 ◦ クラウドサービスはインターネットを経由して利⽤するため、ユーザーID/パスワードのみの 認証は極めて危険。rootユーザーとIAMユーザー/IAMロールあるいは連携しているIdPですべ ての利⽤者がMFAを設定しそれを必須とする ◦ 利⽤するMFAの種類は仮想MFAの利⽤で問題なし • 完了条件 ◦ rootユーザーとすべてのIAMユーザーでMFAを有効化し、⼈が利⽤するすべてのIAMロールで MFAを前提としたポリシーを記述すればOK ◦ IdPを利⽤している場合はIdP側でMFAが有効になっており、IAMロールでそれを必須の条件と して確認できると理想的 ◦ クラスメソッドメンバーズを利⽤している場合、通常rootユーザーはクラスメソッドが管理し ているためrootユーザーに関しては対応不要 • 参考情報 ◦ 多要素認証\(MFA\)するまで使えません！なIAMユーザを作成してみた \| DevelopersIO フェーズ1 (4/16)
32. 1.3.2 root アカウントを利⽤せず、さらに監査する 32 • 検討内容 ◦ rootユーザーはAWSアカウントで特権を持つユーザー ◦ 特別なユーザーのため通常は利⽤せず封印することがベストプラクティス • 完了条件 ◦ rootユーザーにMFAが設定され、基本的に使わないようになっていればOK ◦ 更にCloudTrailを活⽤してログインしたことをアラートしてもいいが、コストパフォーマンス は良くないので基本的には必要なし ◦ クラスメソッドメンバーズを利⽤していれば、通常rootはクラスメソッドが管理しているため ⾃動的にOK • 参考情報 ◦ AWS ルートユーザーでのサインインをAWS Chatbotを使ってSlackに通知してみた ◦ ルートアカウントのクラスメソッドにおける統制（ルートユーザーの管理⽅法や 実際にログインされる際の運⽤⽅法）に関して教えてください フェーズ1 (5/16)
33. 1.3.3 IAM Access Analyzer によるアクセスとロール の分析 33 • 検討内容 ◦ IAM Access AnalyzerはAWSアカウント外部から利⽤できるリソースを検出し⼀覧表⽰するこ とで、意図せず公開していないか管理することができるサービス ◦ IAM Access Analyzerを有効化し、すべての項⽬を確認する • 完了条件 ◦ すべてのリージョンでIAM Access Analyzerのアナライザーを作成 ◦ 検出されたリソースが外部からアクセスできて問題ない場合はアーカイブ、そうではない場合 は是正。すべて対応できたらOK • 参考 ◦ IAM Access Analyzer の設定 \- AWS Identity and Access Management フェーズ1 (6/16)
34. 1.4.1 Amazon GuardDuty による脅威検出 34 • 検討内容 ◦ Amazon GuardDutyはAWS環境上の様々な脅威を検出する。例えばEC2がマルウェアに感染 したり、コインマイニングしたり、不正なIAMのログインがあったり、S3のデータの漏洩など 幅広いレイヤーの検出が可能。 ◦ 有効化するだけで⾮常に効果を発揮するため、有効化必須のサービス。 • 完了条件 ◦ Amazon GuardDutyを全リージョンで有効化していればOK • 参考 ◦ ⼀発でGuardDutyを全リージョン有効化して通知設定するテンプレート作った \| DevelopersIO フェーズ1 (7/16)
35. 1.4.2 AWS CloudTrail によるAPIコールの監査 35 • 検討内容 ◦ AWS CloudTrailはAWSで実⾏したAPIの証跡をとり監査することが可能 ◦ AWS利⽤に必須のサービス • 完了条件 ◦ AWS CloudTrailを有効化し、S3バケットにログを保存すればOK ◦ 管理ログとデータログ、インサイトログがあるが、管理ログのみで問題なし ◦ クラスメソッドメンバーズを利⽤している場合デフォルトで有効化されているので、⾃動で OK • 参考 ◦ CloudTrail 証跡の使⽤ \- AWS CloudTrail フェーズ1 (8/16)
36. 1.4.3 AWS Trusted Advisor で発⾒した security findings の修復 36 • 検討内容 ◦ AWS Trusted AdvisorはAWSのベストプラクティスに従っているか環境をチェックして是正の レコメンデーションを作成する無料のサービス ◦ レコメンデーションのうちセキュリティのカテゴリを確認 ◦ AWSのサポートプランに応じてチェックできる範囲が異なる ◦ クラスメソッドメンバーズを利⽤している場合、すべての項⽬が利⽤可能 • 完了条件 ◦ AWS Trusted Advisorにアクセスし、セキュリティのカテゴリにて、アラートが⾚(推奨される アクション)のものを中⼼に確認 ◦ やや煩雑に検出されるため、フェーズ1では内容を理解し、重⼤だと思われるものに対応すれ ばOK（詳細な対応はフェーズ2のセキュリティ保証のスコープ） • 参考 ◦ AWS Trusted Advisor チェックリファレンス セキュリティ \- AWS Support フェーズ1 (9/16)
37. 1.4.4 異常検出のための課⾦アラーム 37 • 検討内容 ◦ 従量課⾦で利⽤するクラウド環境では、課⾦のモニタリングが必須。セキュリティの⽂脈と しても有効で、不正な利⽤があった場合などにも、資産を守る意味合いで想定される⾦額を超 えた場合の検知が有効となる ◦ AWS BudgetやAWS Cost Explorerを活⽤して料⾦アラートの設定やコスト詳細を確認可能 ◦ クラスメソッドメンバーズではAWSマネジメントコンソールで正確な利⽤費を確認できない ため、代わりにクラスメソッドメンバーズポータルで利⽤費を確認し、料⾦アラームを設定 できる • 完了条件 ◦ 料⾦アラームを設定すればOK • 参考 ◦ AWS Budgets によるコストの管理 \- AWS コスト管理 ◦ AWSアカウント 料⾦アラーム — メンバーズポータル ユーザーガイド フェーズ1 (10/16)
38. 1.5.1 Amazon Inspectorを利⽤した脆弱性情報の収集 38 • 検討内容 ◦ Amazon InspectorはAWS環境の各種リソースの脆弱性を検出可能なため、このサービスで脆 弱性情報の収集を⾏う ◦ 具体的にはAmazon EC2インスタンス/ECRリポジトリのコンテナイメージ/Lambda関数の OS/ミドルウェア/アプリケーションパッケージに含まれる既知の脆弱性(CVE)と、Lambda関 数のアプリケーションコードに含まれる脆弱性(CWE) • 完了条件 ◦ Amazon Inspectorを有効化しEC2/ECR/Lambdaの脆弱性情報を収集できていれば最低限OK ◦ 可能であればAmazon Inspectorにより発⾒されたEC2/ECR/Lambdaに関する脆弱性の内、重 ⼤度がHigh以上のものは即時対応を推奨 • 参考 ◦ Amazon Inspector の開始⽅法 \- Amazon Inspector フェーズ1 (11/16)
39. 1.6.1 セキュリティグループによるアクセス制限 39 • 検討内容 ◦ VPCでネットワークのアクセス制御を⾏うにはセキュリティグループを利⽤する。最⼩権限の 原則に従い、必要なアクセスのみに制御する。特にSSHやRDPなどの管理アクセスポートを許 可する場合、必ず送信元IPを限定する必要がある ◦ AWS Systems Manager Session Managerなどを利⽤すると、管理アクセスポートを開放しな くても、アクセス可能であるため、ポートを開放せずに利⽤することがベストプラクティス • 完了条件 ◦ すべてのEC2インスタンスにアタッチしたセキュリティグループでSSH/RDPポートを開放して いなければOK。開放する場合、送信元IPを/32レベルで制限します。 ◦ AWS Security Hubのチェック項⽬「[EC2.21] ネットワーク ACL は、0.0.0.0/0 からポート 22、またはポート 3389 への侵⼊をを許可しないようにする必要があります」が全て対応でき ていることでも確認可能 • 参考 ◦ Amazon Elastic Compute Cloud コントロール \- AWS Security Hub フェーズ1 (12/16)
40. 1.7.1 Amazon S3 のパブリックアクセスの禁⽌ 40 • 検討内容 ◦ Amazon S3はデフォルトでアカウントレベルのブロックパブリックアクセスが有効になって いる。通常S3バケットを公開することは殆どないため、このままの状態で利⽤する ▪ S3バケットを直接公開する必要がある場合は、アカウントレベルのブロックパブリック アクセスの代わりに、バケットレベルのブロックパブリックアクセスを活⽤し、必要な バケット以外を保護する ▪ CloudFrontを利⽤してS3を公開する場合、S3バケット⾃体は⾮公開で利⽤可能なため ブロックパブリックアクセスを有効にしたままにする • 完了条件 ◦ デフォルトのアカウントレベルのブロックパブリックアクセスを有効にしていればOK ◦ 公開するS3バケットが存在する場合には、そのコンテンツ内容とリスクを適切に判断し、そ れ以外のS3バケットでブロックパブリックアクセスが有効になっていればOK • 参考 ◦ Amazon S3 ストレージへのパブリックアクセスのブロック \ - Amazon Simple Storage Service フェーズ1 (13/16)
41. 1.7.2 Amazon Macie による データセキュリティの分析 41 • 検討内容 ◦ Amazon MacieはS3に保管されている機密データの検出と保護を⾏うサービス ◦ Amazon Macieを活⽤することで、S3バケットに保存されている機密データを発⾒してラベリ ングが可能になるため、データ設計通りに保管されているか、あるいは不⽤意に機密データ が混⼊していないかを確認可能 ◦ 利⽤に関する費⽤の⾯と運⽤の難易度でハードルが⾼いため、オプション ◦ ただし、機密を含む重要データの把握やそのポリシー制定は情報セキュリティの基本である ため何かしらの⽅法で始めから意識すべき • 完了条件 ◦ Amazon Macieが有効化されていれば最低限OK • 参考 ◦ AWS⼊⾨ブログリレー2024〜Amazon Macie編〜 \| DevelopersIO オプション フェーズ1 (14/16)
42. 1.8.1 AWS WAF のマネージドルール 42 • 検討内容 ◦ AWS WAFはAWS環境で透過的に、簡単に導⼊できるWebアプリケーションファイアウォー ◦ マネージドルールが提供され、OWASP トップ 10に対する保護などが可能 ◦ 定常的なアプリケーションに対する攻撃対策のほか、新規に発⾒された脆弱性への即時対応 やDDoSからの保護、⾼度なBOTや標的型攻撃からの保護など、いざという時にすぐに使える ように基本構成として導⼊すべき • 完了条件 ◦ 外部向けに公開しているAmazon CloudFront / ALB / API Gateway / AWS AppSyncに対して AWS WAFのWeb ACLをアタッチし、有⽤と思えるマネージドルールを適⽤していればOK • 参考 ◦ AWS のマネージドルール AWS WAF \- AWS WAF フェーズ1 (15/16)
43. 1.9.1 Amazon GuardDutyの検出に対応する 43 • 検討内容 ◦ Amazon GuardDutyにより検出された脅威がある場合、対応する ◦ 緊急度が⾼のものは、⾮常に危険であり攻撃者からの影響を受けている可能性が⾼いため、 即時封じ込めを⾏う ◦ 緊急度が中低のものはフェーズ2の脅威検出の範囲とする • 完了条件 ◦ 1週間Amazon GuardDutyが緊急度⾼のものを検出しない状況になっていればOK • 参考 ◦ Amazon GuardDuty の検出結果について \- Amazon GuardDuty フェーズ1 (16/16)
44. フェーズ2 44 • フェーズ2ができていれば、⼀通り最低限のセキュリティ対策はでき ているとしてOK クイックウィン 基礎 効率化 最適化 フェーズ 1 フェーズ 2 フェーズ 3 フェーズ 4 はじめの⽬標
45. フェーズ2の項⽬ 45 CAF カテゴリ 項目 セキュリティガバナンス セキュリティおよび規制要件を特定 Cloud Security のトレーニングプラン セキュリティ保証 AWS Config による構成管理 アイデンティティとアクセス管理 ユーザーリポジトリの一元管理 組織ポリシーとしての SCP （※オプション）
 脅威検出 Amazon GuardDuty の Findings を調査 脆弱性管理 インフラストラクチャの脆弱性を管理し、ペネトレーションテストを実施 アプリケーションの脆弱性を管理 AWSリソースインベントリの収集 （※オプション）
 インフラ保護 Fleet Manager によるインスタンス管理 VPC 内の Public/Private ネットワーク分離 AWS Control Tower によるマルチアカウント管理 （※オプション） データ保護 AWS KMSによる暗号化 データバックアップ Amazon Macie による機密データの発見 （※オプション） アプリケーションのセキュリティ 開発時にセキュリティチームも参画する AWS Secrets Manager を利用し、コードにシークレットを含めない インシデント対応 インシデント対応手順を用意 Multi-AZ による冗長構成
46. 2.1.1 セキュリティおよび規制要件を特定する 46 • 検討内容 ◦ 対象のAWS環境及びサービスなどのアセスメント対象のワークロードや組織⾃体に求められ るコンプライアンス要件を確認する ◦ 例えば⾦融系のサービスであればFISCの要件があるとか、⾃社の情報セキュリティポリシー や準拠すべきスタンダード‧セキュリティチェックリストなどの要件が対象 ◦ 特にない場合には、クラスメソッド推奨としてまずはAWS Security Hubを利⽤したセキュリ ティチェックの運⽤をルールにすることを推奨する • 完了条件 ◦ 満たすべきセキュリティおよび規制要件を決めたらOK ◦ サードパーティのCSPM製品などでルールを決めてもOK • 参考 ◦ AWS Foundational Security Best Practices \(FSBP\) 標準 \- AWS Security Hub フェーズ2 (1/20)
47. 2.1.2 Cloud Security のトレーニングプラン 47 • 検討内容 ◦ AWS利⽤前に最低限のセキュリティの教育を受ける必要がある ◦ AWSの利⽤者とAWSの管理者向けにAWSセキュリティの前提知識を⾝につけるためのトレー ニングメニューを定義する ◦ AWSの管理者はAWSの特徴とその上に構築するワークロード、⾃社のセキュリティポリシー を理解してそのセキュリティに責任をもつ必要がある • 完了条件 ◦ すべてのAWS利⽤者にセキュリティの基本となるIAMの扱いについて基本的な教育を実施する 規則とし、運⽤できていればOK ◦ AWS管理者に対するAWSセキュリティ知識を習得する機会が整備されていればOK。レベルは AWS Certified Security - Specialty相当の知識が基準 • 参考 ◦ AWS Skill Buildersのセキュリティ学習プラン ◦ AWSトレーニングサービス \| AWS総合⽀援 \| クラスメソッド株式会社 ▪ 「Security Engineering on AWS」を活⽤ フェーズ2 (2/20)
48. 2.2.1 AWS Config による構成管理 48 • 検討内容 ◦ 基本的にはAWS ConfigをマネージドしているAWS Security Hubの運⽤により、各種AWSの基 本的なセキュリティ設定が満たされていることを確認する • 完了条件 ◦ AWS Security Hubで重要度⾼である項⽬の監視と是正が適切に運⽤できていればOK ◦ 新しい項⽬が検出された際にRSSなどで通知できるようになっているとより適切 • 参考 ◦ セキュリティアラート通知設定 — メンバーズポータル ユーザーガイド フェーズ2 (3/20)
49. 2.3.1 ユーザーリポジトリの⼀元管理 49 • 検討内容 ◦ Microsoft Entra ID（旧Azure AD）やOktaなど、⼀元的なIdPにユーザー情報が集約し、組織 全体のガバナンスを適⽤する。 ◦ AWS限定の範囲でユーザーリポジトリの集約を検討する場合、以下2つの⽅法がある ▪ （ベーシックな⽅法）1つのAWSアカウントにIAMユーザーを集約し、他のAWSアカウ ントにはスイッチロールしてアクセスする、Jumpアカウント⽅式 ▪ （発展的な⼿法）AWS Organizationsと連携してAWS IAM Identity Centerを利⽤した Single Sign-On • 完了条件 ◦ Entra IDなど組織で従業員のIdentityを⼀元管理する仕組みがあり、これと連携してAWS環境 へのアクセスが提供されていることが理想の状態 ◦ 組織全体のIdentityを利⽤できない場合には、上記の Jumpアカウント⽅式もしくはSSOなど のいずれかの⼿法が利⽤できていればOK ◦ Identityを管理するレイヤーと、それを継続的にメンテナンスする体制があり、各ユーザーに 効率的、かつ最⼩権限でアクセスが提供されていればOK • 参考 ◦ マルチアカウントな AWS環境のマネジメントコンソールへのアクセス⽅法 をまとめてみた \| DevelopersIO フェーズ2 (4/20)
50. 2.3.2 組織ポリシーとしてのSCP 50 • 検討内容 ◦ AWS OrganizationsのSCPを駆使して組織のガードレールを整備する。SCPを利⽤すれば、組 織内のガードレールを展開していくことが可能。フェーズ1の利⽤するリージョン制限や整備 したCloudTrailやGuardDutyなどのサービスの停⽌を禁⽌するなどが可能 ◦ AWS Organizationsが必要なためオプション • 完了条件 ◦ リージョン制限やベースラインサービスの停⽌禁⽌などのポリシーを検討して、SCPを利⽤し てこれを実装できていればOK • 参考 ◦ SCPの⼀般的な例 \- AWS Organizations フェーズ2 (5/20) オプション
51. 2.4.1 Amazon GuardDuty の findings を調査する 51 • 検討内容 ◦ Amazon GuardDutyの検出結果が出ているものを調査し是正する ◦ 緊急度が中低のものが頻繁に出る場合にはアーキテクチャに問題がある可能性があるため、 根本的に構成を変えることを検討する。 ◦ 緊急度中の例 ▪ 不審なIPアドレスからのポート スキャン ▪ 既知の脆弱性を持つソフトウェアの使⽤ • 完了条件 ◦ 1週間Amazon GuardDutyが何も検出しない状況になっていればOK • 参考 ◦ Amazon GuardDuty の検出結果について \- Amazon GuardDuty フェーズ2 (6/20)
52. 2.5.1 インフラストラクチャの脆弱性を管理し、 ペネトレーションテストを実施する 52 • 検討内容 ◦ Amazon Inspectorを利⽤した脆弱性情報の収集と管理を⾏う ◦ フェーズ1では収集までだったが、フェーズ2では対処まで • 完了条件 ◦ Amazon Inspectorにより発⾒された、EC2/ECR/Lambdaに関する脆弱性を適切にハンドリン グして対処できていればOK • 参考 ◦ AWS⼊⾨ブログリレー2024〜 Amazon Inspector 編〜 \| DevelopersIO フェーズ2 (7/20)
53. 2.5.2 外部からアプリケーション全体の脆弱性診断を 定期的に受ける 53 • 検討内容 ◦ 専⾨家によるアプリケーションの脆弱性診断は、⾃組織でカバーできない領域まで確認が可 能。サービスリリース前や⼤きな更新をする際、年1などのタイミングで実施することを推奨 ◦ AWS上のアプリケーションとしては特にAmazon Cognitoなど、AWS特有のサービスやアーキ テクチャの利⽤による脆弱性の作り込みなども懸念となる。 • 完了条件 ◦ 外部からアプリケーション全体の脆弱性診断を定期的に受ける仕組みが整っていればOK • 参考 ◦ AWS 診断を事例としたクラウドセキュリティ。サーバーレス環境の不備や⾒落としがちな Cognito の⽳による危険性 \- Flatt Security Blog フェーズ2 (8/20)
54. 2.5.3 AWSリソースインベントリの収集 54 • 検討内容 ◦ どのようなAWSリソースが存在しているかを管理することは、リスクの把握に繋がる • 完了条件 ◦ AWS Resource Explorerを有効化し、リソースの情報を収集できていればOK ◦ 異常時のリソースの把握や定常的なリソースの棚卸しに活⽤できるようにしておく • 参考 ◦ [新機能] リージョン‧サービスを横断してリソースを検索できる AWS Resource Explorer が 使えるようになっていました \| DevelopersIO フェーズ2 (9/20) オプション
55. 2.6.1 AWS Systems Managerによる管理アクセス制御 55 • 検討内容 ◦ EC2インスタンス等の構築したAWSインフラに対するSSH/RDPなどの管理アクセスには、直 接ネットワーク的にアクセスせずに、代わりにAWS Systems Manager Session Managerや Fleet Managerを利⽤してアクセスする • 完了条件 ◦ SSH/RDPのポートを⼀切インターネットに公開しなければOK • 参考 ◦ セッションマネージャーを使って鍵ストレスの無いEC2アクセス！ \| DevelopersIO フェーズ2 (10/20)
56. 2.6.2 VPC内の Public/Private ネットワーク分離 56 • 検討内容 ◦ VPC内の各リソースは適切なサブネットに分割して配置する必要がある ◦ 役割や必要性に応じて分離することで、外部から受ける影響(アタックサーフェイス)を減ら し、影響があっても爆発半径(Blast Radius)を⼩さくできる ◦ 基本的にパブリックサブネットにはEC2インスタンスなどを設置する必要性はない、現在では Systems Manager Session ManagerやEC2 Instance Connectを活⽤してプライベートサブ ネットのEC2インスタンスに直接アクセスすることが可能 • 完了条件 ◦ VPCでパブリックサブネットにEC2インスタンスを設置していなければOK ◦ RDSなども別のサブネットに分離できているとより良い • 参考 ◦ セッションマネージャーを使って鍵ストレスの無いEC2アクセス！ \| DevelopersIO ◦ [アップデート]パブリック IP アドレスなしで、EC2インスタンスにSSH接続できる EC2 Instance Connect Endpointがリリースしました \| DevelopersIO フェーズ2 (11/20)
57. 2.6.3 AWS Control Tower による マルチアカウント管理 57 • 検討内容 ◦ AWS Control Towerを利⽤することで、マルチアカウント管理を円滑に⾏うための初期セット アップや運⽤が可能になる ◦ ID管理、ガードレールの整備、アカウント発⾏フロー整備、ログ管理監視などの機能をAWS Control Towerを利⽤することで簡単にできるようになる ◦ AWS Control Towerの利⽤⾃体にハードルが⾼いためオプションとする • 完了条件 ◦ AWS Control Towerを利⽤するためのマルチアカウント管理に関する設計を⾏い、全体で守 るべき要件が決められ、AWSアカウントの発⾏から利⽤まで運⽤のフローができていればOK • 参考 ◦ [2024最新版]AWS Control Towerを使ったセキュアなマルチアカウント環境の作り⽅ \#devio2024 \#cm\_odyssey \| DevelopersIO フェーズ2 (12/20) オプション
58. 2.7.1 AWS KMSによる暗号化 58 • 検討内容 ◦ AWS上に配置するすべてのデータはユーザーの責任 ◦ データの保管時の暗号化について検討する際は、「なぜ暗号化するのか？」ではなく「なぜ 暗号化しないのか？」から検討する。 ◦ AWS KMSを利⽤するとデータへのアクセスをユーザー側で管理することも可能 ▪ 鍵を破棄することによる暗号化消去(Cryptographic Erase: CE)も可能になり、顧客に対 する説明責任を果たせる ▪ 個⼈情報や機密データを扱うストレージではAWS KMSを利⽤して保管時のデータを暗 号化し、最終的にデータを削除する際には暗号化消去を実施できるようにする • 完了条件 ◦ AWS上で保存するすべてのデータに保管時の暗号化が適⽤されていること ◦ S3などはデフォルトの鍵で暗号化をしていてもOKだが、個⼈情報や機密データを扱うものは AWS KMSで個別に鍵を作成して適⽤していればOK • 参考 ◦ AWS Key Management Service \- AWS Key Management Service フェーズ2 (13/20)
59. 2.7.2 データバックアップ 59 • 検討内容 ◦ データのバックアップは様々な⽬的で必要 ▪ データやシステムの可⽤性の確保 ▪ ランサムウェアの対策としてデータの喪失を防⽌ ◦ 要件も対象毎に異なり、復旧までの許容できる時間やデータの範囲(期間など)を、障害復旧計 画（BCDR）等の⽬的のために定義する ◦ AWS Backupは各種リソースのバックアップを⼀括で管理し復元までサポートするため、まと めて設定できる部分は積極的にAWS Backupを利⽤する • 完了条件 ◦ それぞれのデータでバックアップの⽬的と要件を定義し、その通りにAWS Backupや各サービ スの設定を使ってバックアップ設定ができていればOK ◦ 実際に想定通りに復旧できるか訓練していると良い • 参考 ◦ AWS Backupを使ってEC2のバックアップの設定を⾏い、 ついでに復元までやってみた \| DevelopersIO フェーズ2 (14/20)
60. 2.7.3 Amazon Macie による機密データの発⾒ 60 • 検討内容 ◦ Amazon Macieを利⽤することで、S3バケットに保存されたデータから機密情報を発⾒するこ とが可能。これにより、正しく想定通りのデータが格納されているか、あるいは想定外の機 密データを保管していないか確認できる。 • 完了条件 ◦ フェーズ1では有効化まで、フェーズ2ではプロジェクトで守るべき情報とその重要度が定義 されている ◦ その上でAmazon Macieが有効化されて以下の運⽤があるとOK ▪ 機密データ⾃動検出を利⽤して機密データが保持されているS3バケットを特定している ▪ 公開されていたり暗号化されていないS3バケットを特定している ▪ それらがポリシーに照らし合わせて適切か、必要外の場所に機密データが無いかを定期 的にチェックできている • 参考 ◦ Amazon Macie によるデータセキュリティとプライバシーの監視 \ - Amazon Macie フェーズ2 (15/20) オプション
61. 2.8.1 開発時にセキュリティチームも参画する 61 • 検討内容 ◦ セキュリティはすべての物事に必要となる基本項⽬であり、アプリケーション開発においても 初期から検討すべき内容 ◦ アプリケーション開発では時折、セキュリティに関する考慮が蔑ろにされ、リリース直前に なってから、あるいはリリースされてからもセキュリティ対策について考慮されていない場合 がある ◦ そのようなことが無いよう、開発の初期段階からセキュリティのプロフェッショナルが参画 する必要がある • 完了条件 ◦ 該当プロジェクトでセキュリティ部⾨が設計に関与できているか、あるいは開発チームに、 セキュリティを主導しながら開発できるセキュリティチャンピオンが在籍していればOK フェーズ2 (16/20)
62. 2.8.2 AWS Secrets Manager を利⽤し、コードに シークレットを埋め込まない 62 • 検討内容 ◦ アプリケーションコードにクレデンシャルを直接記述することはアンチパターン ◦ AWS Secrets Managerを活⽤し、外出しすることを推奨 • 完了条件 ◦ 以下の項⽬をアプリケーションコードに直接埋め込まないようにする ▪ IAMアクセスキー ▪ SSH鍵 ▪ データベースユーザー/パスワード ▪ OAuthトークン ▪ APIキー ▪ その他連携サービスの認証情報 ▪ 環境変数の利⽤も基本はNGとし、リスクベースで例外判断します。 ◦ シークレットの格納先はAWS Secrets Managerを基本とし、AWS Systems Manager Parameter Storeのみでの格納する場合はローテーションが不要かなど確認する • 参考 ◦ 機密情報を⼀元管理できる「AWS Secrets Manager」とは？ 概要と主要機能、動作原理、各種リソースまとめ \| DevelopersIO フェーズ2 (17/20)
63. 2.9.1 インシデント対応⼿順を作成し、テストする 63 • 検討内容 ◦ Amazon GuardDutyの検知をトリガーとしてどのようにそのトリアージ‧調査‧対応を⾏う か想定して訓練する ◦ AWSインフラのセキュリティインシデントの他に、対象ワークロードの可⽤性の問題など、 他の領域のインシデントに対する対応⼿順や訓練も検討できるとなお良い • 完了条件 ◦ Amazon GuardDutyによる検知を受け取った際の通知が受け取れるようになっていること ◦ 通知をどのように対応するか担当者やフローが決まっていて、実際にGuardDutyのFindings を発⽣させて対応できればOK • 参考 ◦ Amazon GuardDutyで1つのサンプルイベントのみ発⽣させる⽅法 \| DevelopersIO フェーズ2 (18/20)
64. 2.9.2 Multi-AZ による冗⻑構成 64 • 検討内容 ◦ アプリケーションの可⽤性を確保する場合、Multi-AZでの構成を意識する必要がある ◦ VPCサービスの場合にはその要件に合わせて、単⼀障害点を作り込んでいないかやフェイル オーバーが許容できる時間やサービス停⽌で実現できるのかを確認する • 完了条件 ◦ サービスの可⽤性要件が定義され、それを実現するための構成がされていればOK ◦ 復旧の訓練ができているとなお良い • 参考 ◦ 【レポート】マルチリージョン、ちょっとその前に…\-サービスの可⽤性について考える \#AWS\-53 \#AWSSummit \| DevelopersIO フェーズ2 (19/20)
65. 2.9.3 Amazon Detective: 根本原因の分析 65 • 検討内容 ◦ Amazon Detectiveを有効化し、Amazon GuardDutyで検知されたインシデントの調査ができ る体制を作ります • 完了条件 ◦ Amazon Detectiveを実際に活⽤して分析できる体制を作ればOK • 参考 ◦ [神ツール]セキュリティインシデントの調査が捗るAmazon DetectiveがGAしたのでメリット とオススメの使い⽅を紹介します \| DevelopersIO フェーズ2 (20/20)
66. フェーズ3の項⽬ 66 CAF カテゴリ 項目 セキュリティガバナンス 脅威モデリング セキュリティ保証 コンプライアンス用レポートを作成する(PCI-DSS等) （※オプション） アイデンティティとアクセス管理 タグ付け戦略 顧客のIAM: 顧客のセキュリティ 最小権限
 脅威検出 VPCフローログ分析 SIEM/SOARとの統合 （※オプション）
 脆弱性管理 インフラストラクチャの脆弱性を管理し、ペネトレーションテストを実施 アプリケーションの脆弱性を管理 AWSリソースインベントリの収集 
 インフラ保護 ゴールデンイメージ生成用の継続的パイプラインの構築 Serverlessを使用する マルウェア対策やEDRの実装 
 コンテナセキュリティ （※オプション）
 データ保護 転送中の暗号化 アプリケーションのセキュリティ Shield Advanced: 高度なDDoS攻撃の緩和 WAFのカスタムルール使用 インシデント対応 重要で頻繁に実行されるプレイブックの自動化 AWS Configによる非準拠リソースの自動修復 インフラをコード化する(CloudFormation,CDK) 

67. フェーズ4の項⽬ 67 CAF カテゴリ 項目 セキュリティガバナンス セキュリティタスクと責任の共有 カオスエンジニアリングチームの結成 (レジリエンス) アイデンティティとアクセス管理 コンテキストベースのアクセスコントロール IAMポリシー生成パイプライン 脅威検出 Amazon Fraud Detector インテリジェンスフィードの統合 
 インフラ保護 Service Catalog によるプロセスの標準化 送信トラフィックの制御 AWS Control Tower によるマルチアカウント管理 アプリケーションのセキュリティ DevSecOps レッドチームの結成 (攻撃者の視点) インシデント対応 ブルーチームの結成 (インシデント対応) プレイブックの自動化 マルチリージョン ディザスタリカバリ(DR)の自動化 

68. フェーズ3,4 68 • フェーズ3：セキュリティを効率的に管理するための制御と推奨事項
 • フェーズ4：よりセキュリティを強固するための推奨事項
 クイックウィン 基礎 効率化 最適化 フェーズ 1 フェーズ 2 フェーズ 3 フェーズ 4 はじめの目標
69. アジェンダ • はじめに • 基礎編 ◦ AWSにおけるセキュリティの基本 ◦ AWSセキュリティ成熟度モデルとは • 実践編 ◦ AWSセキュリティ成熟度モデル各フェーズでの対策 • まとめ 69
70. まとめ 70 • AWSセキュリティの基本はAWS責任共有モデル、AWSと利⽤ 者の責任範囲を明確に理解することが⼤前提 • AWSセキュリティ成熟度モデルは、利⽤者側の責任範囲におけ るセキュリティ対策の実現度を定量的に測るフレームワーク • 次のアクションを可視化し、ロードマップに基づいてセキュリ ティ対策を強化していくことができる
71. こちらのプログラムもぜひ活⽤ください！ 71 引⽤：https://classmethod.jp/aws/services/security-enhancement-program/
72. 本セッションの⽬的（再掲） 72 • AWSセキュリティ成熟度モデル 便利だな〜 • このモデルでやるべきセキュリ ティ対策を洗い出そう！