Slide 1
Slide 1 text
2024.7.31
AWS事業本部 松波花奈
どこから始める？
AWSセキュリティ成熟度モデルで
次のアクションを可視化しよう！
Slide 2
Slide 2 text
本セッションの資料は
「DevelopersIO」で公開します
2
事前のご連絡
Slide 3
Slide 3 text
Xへの投稿の際は、
ハッシュタグ
#cm_odyssey
でお願いいたします。
3
お願い
Slide 4
Slide 4 text
⾃⼰紹介
松波 花奈（まつなみ かな）/ おつまみ
● AWS事業本部コンサルティング部
● ソリューションアーキテクト
● 2022年9⽉⼊社
● 2024 Japan AWS Top Engineer (Security)& All Certs
● 好きなAWSサービス：AWS Security Hub
4
Slide 5
Slide 5 text
アジェンダ
● はじめに
● 基礎編
○ AWSにおけるセキュリティの基本
○ AWSセキュリティ成熟度モデルとは
● 実践編
○ AWSセキュリティ成熟度モデル各フェーズでの対策
● まとめ
5
Slide 6
Slide 6 text
アジェンダ
● はじめに
● 基礎編
○ AWSにおけるセキュリティの基本
○ AWSセキュリティ成熟度モデルとは
● 実践編
○ AWSセキュリティ成熟度モデル各フェーズでの対策
● まとめ
6
Slide 7
Slide 7 text
本セッションの対象者
● 既にAWSを利⽤していて、セキュリティ対策に不安を感
じている⽅
● どのセキュリティ対策から始めればいいかお悩みの⽅
レベル200を想定してお話しします
7
● レベル100：⼊⾨セッション、サービスの概要レベル
● レベル200：中級セッション、サービスのベストプラクティスや機能の詳細レベル
● レベル300：上級セッション、トピックの詳細レベル
● レベル400：エキスパートセッション、サービスに精通しており、独⾃ソリューションを実装しているレベル
Slide 8
Slide 8 text
本セッションでお話しすること
お話しすること
● AWSにおけるセキュリティの基本的な考え⽅
● AWSセキュリティ成熟度モデルを利⽤したセキュ
リティレベルの可視化⽅法
お話ししないこと
● フェーズ3,4にあたるセキュリティ対策
8
Slide 9
Slide 9 text
本セッションの⽬的 9
● AWSセキュリティ成熟度モデル
便利だな〜
● このモデルでやるべきセキュリ
ティ対策を洗い出そう！
Slide 10
Slide 10 text
アジェンダ
● はじめに
● 基礎編
○ AWSにおけるセキュリティの基本
○ AWSセキュリティ成熟度モデルとは
● 実践編
○ AWSセキュリティ成熟度モデル各フェーズでの対策
● まとめ
10
Slide 11
Slide 11 text
AWSのセキュリティ対策
ばっちりできていますか？
11
Slide 12
Slide 12 text
どう答えればいいんだろう‧‧ 12
● Security Hub
○ 有効化はできているけど、スコアは
継続的に維持できていない‧‧
● GuardDuty
○ 有効化はできているけど、検知した
脅威に対応できていない‧‧
● インシデント管理
○ ⼿順書はあるけど、最近いつ使った
た？
Slide 13
Slide 13 text
AWS責任共有モデル(1/2) 13
引用: AWS - クラウドセキュリティ - 責任共有モデル
Slide 14
Slide 14 text
AWS責任共有モデル(2/2) 14
引用: AWS - クラウドセキュリティ - 責任共有モデル
この範囲すべてを
対策する責任がある
Slide 15
Slide 15 text
AWS特有のセキュリティリスク 15
● ネットワークセキュリティリスク
○ AWSサービスはインターネットを介して利⽤されるため、外部からの不正
アクセスのリスクがある。
● アクセス権限の設定ミス
○ AWSリソースへのアクセス権限を誤って設定すると、意図せず第三者に
データやリソースが公開されてしまう可能性があります。
● 不正利⽤によるコスト増
○ 従量課⾦制のため、必要以上のリソースをプロビジョニングしてしまう
と、⾼額な請求が発⽣するリスクがある。(ex. コインマイニング）
Slide 16
Slide 16 text
アジェンダ
● はじめに
● 基礎編
○ AWSにおけるセキュリティの基本
○ AWSセキュリティ成熟度モデルとは
● 実践編
○ AWSセキュリティ成熟度モデル各フェーズでの対策
● まとめ
16
Slide 17
Slide 17 text
AWSセキュリティ成熟度モデルとは 17
● AWSセキュリティ対策がどの程度実現
できているか定量的に測るためのフ
レームワーク
● AWS公式ドキュメントではないが、多
くのユーザーで活⽤実績がある
● 9つのセキュリティカテゴリと4段階の
フェーズに区切ってセキュリティ対策
がマッピングされている
引⽤
：https://maturitymodel.security.aws.dev/en/model/
Slide 18
Slide 18 text
9つのセキュリティカテゴリ 18
Slide 19
Slide 19 text
4段階のフェーズ 19
● 「クイックウィン」〜「最適化」まで、4 段階のフェーズ分け
● はじめに⽬指す指針としてはフェーズ 2 の「基礎」
クイックウィン 基礎 効率化 最適化
フェーズ 1 フェーズ 2 フェーズ 3 フェーズ 4
はじめの⽬標
Slide 20
Slide 20 text
評価⽅法(1/2) 20
引⽤：https://maturitymodel.security.aws.dev/en/model/
ダウンロード
Slide 21
Slide 21 text
評価⽅法(2/2) 21
引⽤：https://maturitymodel.security.aws.dev/en/model/
①チェック ②必要に応じてコメント
Slide 22
Slide 22 text
評価結果 22
カテゴリごとに達成レベルが可視化！
不⾜部分のセキュリティ
対策を強化！
Slide 23
Slide 23 text
使⽤する際の注意点 23
● AWSセキュリティ成熟度モデルはあくまで指標
● フェーズ3,4は、より⾼度なセキュリティ対策のため必ずしも満たす必要はない
○ 実際に運⽤する場合には実現が難しいことがある
○ 「⼀般的な⽬指すべき理想の状態の1つ」と捉える
● 各推奨事項を深く理解するためには、AWSセキュリティに関する専⾨的な知識が
必要
○ AWS Certified Security - Specialty有資格者
○ 有資格者がいなければ取得を推進する
Slide 24
Slide 24 text
アジェンダ
● はじめに
● 基礎編
○ AWSにおけるセキュリティの基本
○ AWSセキュリティ成熟度モデルとは
● 実践編
○ AWSセキュリティ成熟度モデル各フェーズでの対策
● まとめ
24
Slide 25
Slide 25 text
フェーズ2まで説明対象 25
● はじめに⽬指す指針としてはフェーズ 2 の「基礎」
● 弊社独⾃の観点を⼊れ替えたクラスメソッド流のセキュリティ成熟
度モデルの対策
クイックウィン 基礎 効率化 最適化
フェーズ 1 フェーズ 2 フェーズ 3 フェーズ 4
はじめの⽬標
Slide 26
Slide 26 text
フェーズ1 26
● クイックウィンは⽂字通りすぐに実施できる設定やサービスの有効
化がメイン
● ここであげられる推奨事項はすべて 1 週間以内に実装できるものな
ので、すぐに完了させましょう！
クイックウィン 基礎 効率化 最適化
フェーズ 1 フェーズ 2 フェーズ 3 フェーズ 4
はじめの⽬標
Slide 27
Slide 27 text
フェーズ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 の検出に対応
Slide 28
Slide 28 text
1.1.1 セキュリティインシデントの連絡先を最新化 28
● 検討内容
○ AWSアカウントの連絡先情報で「セキュリティ問い合わせ先」を登録
○ 万が⼀AWSアカウントで不正利⽤等が発⽣した場合に、この連絡先に通知されるため、常に
これを受け取れるようにして確認する必要がある
● 完了条件
○ クラスメソッドメンバーズご加⼊の⽅
■ CMP(クラスメソッドメンバーズポータル)にて「AWSアカウント通知先」で「セキュリ
ティ通知先」を登録すればOK
○ クラスメソッドメンバーズご加⼊ではない⽅
■ ルートユーザーでAWSアカウントにログインし、右上の[Contact information] (連絡先
情報)から「主要連絡先」「セキュリティ問い合わせ先」を登録すればOK
● 参考
○ クラスメソッドメンバーズポータル - AWSアカウント通知先
○ AWS アカウント連絡先情報を更新 \- AWS アカウント管理
フェーズ1 (1/16)
Slide 29
Slide 29 text
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)
Slide 30
Slide 30 text
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)
Slide 31
Slide 31 text
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)
Slide 32
Slide 32 text
1.3.2 root アカウントを利⽤せず、さらに監査する 32
● 検討内容
○ rootユーザーはAWSアカウントで特権を持つユーザー
○ 特別なユーザーのため通常は利⽤せず封印することがベストプラクティス
● 完了条件
○ rootユーザーにMFAが設定され、基本的に使わないようになっていればOK
○ 更にCloudTrailを活⽤してログインしたことをアラートしてもいいが、コストパフォーマンス
は良くないので基本的には必要なし
○ クラスメソッドメンバーズを利⽤していれば、通常rootはクラスメソッドが管理しているため
⾃動的にOK
● 参考情報
○ AWS ルートユーザーでのサインインをAWS Chatbotを使ってSlackに通知してみた
○ ルートアカウントのクラスメソッドにおける統制（ルートユーザーの管理⽅法や
実際にログインされる際の運⽤⽅法）に関して教えてください
フェーズ1 (5/16)
Slide 33
Slide 33 text
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)
Slide 34
Slide 34 text
1.4.1 Amazon GuardDuty による脅威検出 34
● 検討内容
○ Amazon GuardDutyはAWS環境上の様々な脅威を検出する。例えばEC2がマルウェアに感染
したり、コインマイニングしたり、不正なIAMのログインがあったり、S3のデータの漏洩など
幅広いレイヤーの検出が可能。
○ 有効化するだけで⾮常に効果を発揮するため、有効化必須のサービス。
● 完了条件
○ Amazon GuardDutyを全リージョンで有効化していればOK
● 参考
○ ⼀発でGuardDutyを全リージョン有効化して通知設定するテンプレート作った \|
DevelopersIO
フェーズ1 (7/16)
Slide 35
Slide 35 text
1.4.2 AWS CloudTrail によるAPIコールの監査 35
● 検討内容
○ AWS CloudTrailはAWSで実⾏したAPIの証跡をとり監査することが可能
○ AWS利⽤に必須のサービス
● 完了条件
○ AWS CloudTrailを有効化し、S3バケットにログを保存すればOK
○ 管理ログとデータログ、インサイトログがあるが、管理ログのみで問題なし
○ クラスメソッドメンバーズを利⽤している場合デフォルトで有効化されているので、⾃動で
OK
● 参考
○ CloudTrail 証跡の使⽤ \- AWS CloudTrail
フェーズ1 (8/16)
Slide 36
Slide 36 text
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)
Slide 37
Slide 37 text
1.4.4 異常検出のための課⾦アラーム 37
● 検討内容
○ 従量課⾦で利⽤するクラウド環境では、課⾦のモニタリングが必須。セキュリティの⽂脈と
しても有効で、不正な利⽤があった場合などにも、資産を守る意味合いで想定される⾦額を超
えた場合の検知が有効となる
○ AWS BudgetやAWS Cost Explorerを活⽤して料⾦アラートの設定やコスト詳細を確認可能
○ クラスメソッドメンバーズではAWSマネジメントコンソールで正確な利⽤費を確認できない
ため、代わりにクラスメソッドメンバーズポータルで利⽤費を確認し、料⾦アラームを設定
できる
● 完了条件
○ 料⾦アラームを設定すればOK
● 参考
○ AWS Budgets によるコストの管理 \- AWS コスト管理
○ AWSアカウント 料⾦アラーム — メンバーズポータル ユーザーガイド
フェーズ1 (10/16)
Slide 38
Slide 38 text
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)
Slide 39
Slide 39 text
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)
Slide 40
Slide 40 text
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)
Slide 41
Slide 41 text
1.7.2 Amazon Macie による
データセキュリティの分析
41
● 検討内容
○ Amazon MacieはS3に保管されている機密データの検出と保護を⾏うサービス
○ Amazon Macieを活⽤することで、S3バケットに保存されている機密データを発⾒してラベリ
ングが可能になるため、データ設計通りに保管されているか、あるいは不⽤意に機密データ
が混⼊していないかを確認可能
○ 利⽤に関する費⽤の⾯と運⽤の難易度でハードルが⾼いため、オプション
○ ただし、機密を含む重要データの把握やそのポリシー制定は情報セキュリティの基本である
ため何かしらの⽅法で始めから意識すべき
● 完了条件
○ Amazon Macieが有効化されていれば最低限OK
● 参考
○ AWS⼊⾨ブログリレー2024〜Amazon Macie編〜 \| DevelopersIO
オプション
フェーズ1 (14/16)
Slide 42
Slide 42 text
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)
Slide 43
Slide 43 text
1.9.1 Amazon GuardDutyの検出に対応する 43
● 検討内容
○ Amazon GuardDutyにより検出された脅威がある場合、対応する
○ 緊急度が⾼のものは、⾮常に危険であり攻撃者からの影響を受けている可能性が⾼いため、
即時封じ込めを⾏う
○ 緊急度が中低のものはフェーズ2の脅威検出の範囲とする
● 完了条件
○ 1週間Amazon GuardDutyが緊急度⾼のものを検出しない状況になっていればOK
● 参考
○ Amazon GuardDuty の検出結果について \- Amazon GuardDuty
フェーズ1 (16/16)
Slide 44
Slide 44 text
フェーズ2 44
● フェーズ2ができていれば、⼀通り最低限のセキュリティ対策はでき
ているとしてOK
クイックウィン 基礎 効率化 最適化
フェーズ 1 フェーズ 2 フェーズ 3 フェーズ 4
はじめの⽬標
Slide 45
Slide 45 text
フェーズ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 による冗長構成
Slide 46
Slide 46 text
2.1.1 セキュリティおよび規制要件を特定する 46
● 検討内容
○ 対象のAWS環境及びサービスなどのアセスメント対象のワークロードや組織⾃体に求められ
るコンプライアンス要件を確認する
○ 例えば⾦融系のサービスであればFISCの要件があるとか、⾃社の情報セキュリティポリシー
や準拠すべきスタンダード‧セキュリティチェックリストなどの要件が対象
○ 特にない場合には、クラスメソッド推奨としてまずはAWS Security Hubを利⽤したセキュリ
ティチェックの運⽤をルールにすることを推奨する
● 完了条件
○ 満たすべきセキュリティおよび規制要件を決めたらOK
○ サードパーティのCSPM製品などでルールを決めてもOK
● 参考
○ AWS Foundational Security Best Practices \(FSBP\) 標準 \- AWS Security Hub
フェーズ2 (1/20)
Slide 47
Slide 47 text
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)
Slide 48
Slide 48 text
2.2.1 AWS Config による構成管理 48
● 検討内容
○ 基本的にはAWS ConfigをマネージドしているAWS Security Hubの運⽤により、各種AWSの基
本的なセキュリティ設定が満たされていることを確認する
● 完了条件
○ AWS Security Hubで重要度⾼である項⽬の監視と是正が適切に運⽤できていればOK
○ 新しい項⽬が検出された際にRSSなどで通知できるようになっているとより適切
● 参考
○ セキュリティアラート通知設定 — メンバーズポータル ユーザーガイド
フェーズ2 (3/20)
Slide 49
Slide 49 text
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)
Slide 50
Slide 50 text
2.3.2 組織ポリシーとしてのSCP 50
● 検討内容
○ AWS OrganizationsのSCPを駆使して組織のガードレールを整備する。SCPを利⽤すれば、組
織内のガードレールを展開していくことが可能。フェーズ1の利⽤するリージョン制限や整備
したCloudTrailやGuardDutyなどのサービスの停⽌を禁⽌するなどが可能
○ AWS Organizationsが必要なためオプション
● 完了条件
○ リージョン制限やベースラインサービスの停⽌禁⽌などのポリシーを検討して、SCPを利⽤し
てこれを実装できていればOK
● 参考
○ SCPの⼀般的な例 \- AWS Organizations
フェーズ2 (5/20)
オプション
Slide 51
Slide 51 text
2.4.1 Amazon GuardDuty の findings を調査する 51
● 検討内容
○ Amazon GuardDutyの検出結果が出ているものを調査し是正する
○ 緊急度が中低のものが頻繁に出る場合にはアーキテクチャに問題がある可能性があるため、
根本的に構成を変えることを検討する。
○ 緊急度中の例
■ 不審なIPアドレスからのポート スキャン
■ 既知の脆弱性を持つソフトウェアの使⽤
● 完了条件
○ 1週間Amazon GuardDutyが何も検出しない状況になっていればOK
● 参考
○ Amazon GuardDuty の検出結果について \- Amazon GuardDuty
フェーズ2 (6/20)
Slide 52
Slide 52 text
2.5.1 インフラストラクチャの脆弱性を管理し、
ペネトレーションテストを実施する
52
● 検討内容
○ Amazon Inspectorを利⽤した脆弱性情報の収集と管理を⾏う
○ フェーズ1では収集までだったが、フェーズ2では対処まで
● 完了条件
○ Amazon Inspectorにより発⾒された、EC2/ECR/Lambdaに関する脆弱性を適切にハンドリン
グして対処できていればOK
● 参考
○ AWS⼊⾨ブログリレー2024〜 Amazon Inspector 編〜 \| DevelopersIO
フェーズ2 (7/20)
Slide 53
Slide 53 text
2.5.2 外部からアプリケーション全体の脆弱性診断を
定期的に受ける
53
● 検討内容
○ 専⾨家によるアプリケーションの脆弱性診断は、⾃組織でカバーできない領域まで確認が可
能。サービスリリース前や⼤きな更新をする際、年1などのタイミングで実施することを推奨
○ AWS上のアプリケーションとしては特にAmazon Cognitoなど、AWS特有のサービスやアーキ
テクチャの利⽤による脆弱性の作り込みなども懸念となる。
● 完了条件
○ 外部からアプリケーション全体の脆弱性診断を定期的に受ける仕組みが整っていればOK
● 参考
○ AWS 診断を事例としたクラウドセキュリティ。サーバーレス環境の不備や⾒落としがちな
Cognito の⽳による危険性 \- Flatt Security Blog
フェーズ2 (8/20)
Slide 54
Slide 54 text
2.5.3 AWSリソースインベントリの収集 54
● 検討内容
○ どのようなAWSリソースが存在しているかを管理することは、リスクの把握に繋がる
● 完了条件
○ AWS Resource Explorerを有効化し、リソースの情報を収集できていればOK
○ 異常時のリソースの把握や定常的なリソースの棚卸しに活⽤できるようにしておく
● 参考
○ [新機能] リージョン‧サービスを横断してリソースを検索できる AWS Resource Explorer が
使えるようになっていました \| DevelopersIO
フェーズ2 (9/20)
オプション
Slide 55
Slide 55 text
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)
Slide 56
Slide 56 text
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)
Slide 57
Slide 57 text
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)
オプション
Slide 58
Slide 58 text
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)
Slide 59
Slide 59 text
2.7.2 データバックアップ 59
● 検討内容
○ データのバックアップは様々な⽬的で必要
■ データやシステムの可⽤性の確保
■ ランサムウェアの対策としてデータの喪失を防⽌
○ 要件も対象毎に異なり、復旧までの許容できる時間やデータの範囲(期間など)を、障害復旧計
画（BCDR）等の⽬的のために定義する
○ AWS Backupは各種リソースのバックアップを⼀括で管理し復元までサポートするため、まと
めて設定できる部分は積極的にAWS Backupを利⽤する
● 完了条件
○ それぞれのデータでバックアップの⽬的と要件を定義し、その通りにAWS Backupや各サービ
スの設定を使ってバックアップ設定ができていればOK
○ 実際に想定通りに復旧できるか訓練していると良い
● 参考
○ AWS Backupを使ってEC2のバックアップの設定を⾏い、
ついでに復元までやってみた \| DevelopersIO
フェーズ2 (14/20)
Slide 60
Slide 60 text
2.7.3 Amazon Macie による機密データの発⾒ 60
● 検討内容
○ Amazon Macieを利⽤することで、S3バケットに保存されたデータから機密情報を発⾒するこ
とが可能。これにより、正しく想定通りのデータが格納されているか、あるいは想定外の機
密データを保管していないか確認できる。
● 完了条件
○ フェーズ1では有効化まで、フェーズ2ではプロジェクトで守るべき情報とその重要度が定義
されている
○ その上でAmazon Macieが有効化されて以下の運⽤があるとOK
■ 機密データ⾃動検出を利⽤して機密データが保持されているS3バケットを特定している
■ 公開されていたり暗号化されていないS3バケットを特定している
■ それらがポリシーに照らし合わせて適切か、必要外の場所に機密データが無いかを定期
的にチェックできている
● 参考
○ Amazon Macie によるデータセキュリティとプライバシーの監視 \
- Amazon Macie
フェーズ2 (15/20)
オプション
Slide 61
Slide 61 text
2.8.1 開発時にセキュリティチームも参画する 61
● 検討内容
○ セキュリティはすべての物事に必要となる基本項⽬であり、アプリケーション開発においても
初期から検討すべき内容
○ アプリケーション開発では時折、セキュリティに関する考慮が蔑ろにされ、リリース直前に
なってから、あるいはリリースされてからもセキュリティ対策について考慮されていない場合
がある
○ そのようなことが無いよう、開発の初期段階からセキュリティのプロフェッショナルが参画
する必要がある
● 完了条件
○ 該当プロジェクトでセキュリティ部⾨が設計に関与できているか、あるいは開発チームに、
セキュリティを主導しながら開発できるセキュリティチャンピオンが在籍していればOK
フェーズ2 (16/20)
Slide 62
Slide 62 text
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)
Slide 63
Slide 63 text
2.9.1 インシデント対応⼿順を作成し、テストする 63
● 検討内容
○ Amazon GuardDutyの検知をトリガーとしてどのようにそのトリアージ‧調査‧対応を⾏う
か想定して訓練する
○ AWSインフラのセキュリティインシデントの他に、対象ワークロードの可⽤性の問題など、
他の領域のインシデントに対する対応⼿順や訓練も検討できるとなお良い
● 完了条件
○ Amazon GuardDutyによる検知を受け取った際の通知が受け取れるようになっていること
○ 通知をどのように対応するか担当者やフローが決まっていて、実際にGuardDutyのFindings
を発⽣させて対応できればOK
● 参考
○ Amazon GuardDutyで1つのサンプルイベントのみ発⽣させる⽅法 \| DevelopersIO
フェーズ2 (18/20)
Slide 64
Slide 64 text
2.9.2 Multi-AZ による冗⻑構成 64
● 検討内容
○ アプリケーションの可⽤性を確保する場合、Multi-AZでの構成を意識する必要がある
○ VPCサービスの場合にはその要件に合わせて、単⼀障害点を作り込んでいないかやフェイル
オーバーが許容できる時間やサービス停⽌で実現できるのかを確認する
● 完了条件
○ サービスの可⽤性要件が定義され、それを実現するための構成がされていればOK
○ 復旧の訓練ができているとなお良い
● 参考
○ 【レポート】マルチリージョン、ちょっとその前に…\-サービスの可⽤性について考える
\#AWS\-53 \#AWSSummit \| DevelopersIO
フェーズ2 (19/20)
Slide 65
Slide 65 text
2.9.3 Amazon Detective: 根本原因の分析 65
● 検討内容
○ Amazon Detectiveを有効化し、Amazon GuardDutyで検知されたインシデントの調査ができ
る体制を作ります
● 完了条件
○ Amazon Detectiveを実際に活⽤して分析できる体制を作ればOK
● 参考
○ [神ツール]セキュリティインシデントの調査が捗るAmazon DetectiveがGAしたのでメリット
とオススメの使い⽅を紹介します \| DevelopersIO
フェーズ2 (20/20)
Slide 66
Slide 66 text
フェーズ3の項⽬ 66
CAF カテゴリ 項目
セキュリティガバナンス 脅威モデリング
セキュリティ保証 コンプライアンス用レポートを作成する(PCI-DSS等)
（※オプション）
アイデンティティとアクセス管理
タグ付け戦略
顧客のIAM: 顧客のセキュリティ
最小権限
脅威検出
VPCフローログ分析
SIEM/SOARとの統合
（※オプション）
脆弱性管理
インフラストラクチャの脆弱性を管理し、ペネトレーションテストを実施
アプリケーションの脆弱性を管理
AWSリソースインベントリの収集
インフラ保護
ゴールデンイメージ生成用の継続的パイプラインの構築
Serverlessを使用する
マルウェア対策やEDRの実装
コンテナセキュリティ
（※オプション）
データ保護 転送中の暗号化
アプリケーションのセキュリティ
Shield Advanced: 高度なDDoS攻撃の緩和
WAFのカスタムルール使用
インシデント対応
重要で頻繁に実行されるプレイブックの自動化
AWS Configによる非準拠リソースの自動修復
インフラをコード化する(CloudFormation,CDK)
Slide 67
Slide 67 text
フェーズ4の項⽬ 67
CAF カテゴリ 項目
セキュリティガバナンス
セキュリティタスクと責任の共有
カオスエンジニアリングチームの結成 (レジリエンス)
アイデンティティとアクセス管理
コンテキストベースのアクセスコントロール
IAMポリシー生成パイプライン
脅威検出
Amazon Fraud Detector
インテリジェンスフィードの統合
インフラ保護
Service Catalog によるプロセスの標準化
送信トラフィックの制御
AWS Control Tower によるマルチアカウント管理
アプリケーションのセキュリティ
DevSecOps
レッドチームの結成 (攻撃者の視点)
インシデント対応
ブルーチームの結成 (インシデント対応)
プレイブックの自動化
マルチリージョン ディザスタリカバリ(DR)の自動化
Slide 68
Slide 68 text
フェーズ3,4 68
● フェーズ3：セキュリティを効率的に管理するための制御と推奨事項
● フェーズ4：よりセキュリティを強固するための推奨事項
クイックウィン 基礎 効率化 最適化
フェーズ 1 フェーズ 2 フェーズ 3 フェーズ 4
はじめの目標
Slide 69
Slide 69 text
アジェンダ
● はじめに
● 基礎編
○ AWSにおけるセキュリティの基本
○ AWSセキュリティ成熟度モデルとは
● 実践編
○ AWSセキュリティ成熟度モデル各フェーズでの対策
● まとめ
69
Slide 70
Slide 70 text
まとめ 70
● AWSセキュリティの基本はAWS責任共有モデル、AWSと利⽤
者の責任範囲を明確に理解することが⼤前提
● AWSセキュリティ成熟度モデルは、利⽤者側の責任範囲におけ
るセキュリティ対策の実現度を定量的に測るフレームワーク
● 次のアクションを可視化し、ロードマップに基づいてセキュリ
ティ対策を強化していくことができる
Slide 71
Slide 71 text
こちらのプログラムもぜひ活⽤ください！ 71
引⽤：https://classmethod.jp/aws/services/security-enhancement-program/
Slide 72
Slide 72 text
本セッションの⽬的（再掲） 72
● AWSセキュリティ成熟度モデル
便利だな〜
● このモデルでやるべきセキュリ
ティ対策を洗い出そう！
Slide 73
Slide 73 text
No content
Slide 74
Slide 74 text
No content