AWSセキュリティ成熟度モデルv2による段階的なセキュリティ強化のススメ
こんにちは、臼田です。
みなさん、AWSのセキュリティ対策できてますか？(挨拶
といっても具体的にどれくらいできているかって判断するのが難しいですよね。
今回はAWSから提供されているAWSセキュリティ成熟度モデル(AWS Security Maturity Model)を活用した、どれくらいできているのかを確認する方法を紹介します。こんな感じになります。
ぱっと見いい感じじゃないですか？これはちょっと作り込んでありますが、ベースはAWSセキュリティ成熟度モデルを活用しています。まずはAWSセキュリティ成熟度モデルがなんなのか、というところから説明していきます。
ちなみに、以前下記ブログでAWSセキュリティ成熟度モデルについて解説しておりますが、AWSセキュリティ成熟度モデルもv2になりましたので、本記事ではv2の内容に合わせて刷新しています。
AWSセキュリティ成熟度モデルとは
AWSセキュリティ成熟度モデル(AWS Security Maturity Model)はAWSから提供されている、組織がAWSのセキュリティ対策をどの程度実現できているかを定量的に測るためのフレームワークです。
以下の図ようにCAFをベースとした10個のセキュリティカテゴリと、それぞれ4つのフェーズで分類されています。
10個のカテゴリは下記のとおりです。
- セキュリティ ガバナンス
- セキュリティ保証
- アイデンティティとアクセス管理
- 脅威検出
- 脆弱性管理
- インフラ保護
- データ保護
- アプリケーションセキュリティ
- インシデント対応
- レジリエンス
v2となり、CAFにあったカテゴリに加えて「レジリエンス」が10個目のカテゴリとなりました。
4つのフェーズはこのようになっています。
- クイックウィン(Quick Wins)
- 基礎(Foundational)
- 効率化(Efficient)
- 最適化(Optimized)
なお、このドキュメントは次のように書かれており、公式のドキュメントではないということを補足しておきます。とはいえ、十分活用できるものです。
このモデルは 意見に基づく規範的なガイダンス のセットであり、私たちの経験上、ほとんどの組織を安全にする最も効率的な方法に焦点を当てています。
このモデルは、AWS のセキュリティスペシャリストのチームによって作成され、数十回のピアレビューを通じて検証されました。 現在、100 名以上の AWS ソリューションアーキテクトがお客様のセキュリティポスチャを改善するために使用しており、過去 12 ヶ月で 50,000 以上のユニークユーザーがいます。
優先順位付けの基準を理解するために、入門編のセクションを確認してください。典型的な成熟度モデルのアプローチとは異なります。AWS セキュリティ成熟度モデルは、はるかに実践的です。
このような成熟度モデルの概念は、有名なものだとCMM/CMMIやサイバーセキュリティの分野ではCMMCなどがありますが、これと似たようなものだと考えると良いと思います。ただし、めちゃくちゃAWSナイズされていてより現実的で、AWSをスコープに見るならすごく使いやすいです。
AWSセキュリティ成熟度モデルでは、各セキュリティのカテゴリとフェーズに応じて、どのような取り組みができているといいかが定義されています。
例えば「アイデンティティとアクセス管理」カテゴリの「Phase 1: クイックウィン」では下記の4つが推奨事項として書かれています。
- 多要素認証 (MFA)
- ルートの保護
- ID フェデレーション
- 意図しないアクセス権限の削除
これらが実現できていればOKということですね。わかりやすい基準です。
このように各カテゴリとフェーズにある推奨事項を確認していき、どこまでできているかマルバツつけていくと、自分たちが今どれくらいできているかわかるということです。
そして、そのためのシートも一緒に公開されています！うれしい！評価ツールのページにエクセルが置いてあります。
まとめると、AWSセキュリティ成熟度モデルは体系的にまとめられたセキュリティカテゴリとそのフェーズ毎の推奨事項の実現度をチェックすることで、自分たちのAWSセキュリティの現在地がわかるツールということです。
現在地がわかったら、その次の活用方法は様々で、足りないところを補うためにその洗い出し方法として活用したり、組織の中でベースラインとなるレベル感を定義するのに使う事もできます。
また、推奨事項の数は結構ありますが、それらを一通り確認することで、単純にAWSセキュリティへの理解を深める読み物としても活用できます。
AWSセキュリティ成熟度モデルを使う上での勘所
と、一通り概要やメリットについて説明したところで、実際にこれを活用していく上での勘所をザッと箇条書きで共有します。
AWSセキュリティ成熟度モデルを使った取り組みの姿勢
- この成熟度モデルはあくまで指標です
- この推奨事項に必ずしも寄せすぎる必要はありません
- この推奨事項で完全なセキュリティ対策ができる、ということでもありません
- 有効に活用できますが、過信し過ぎないようにしましょう
- もともと組織単位で適用することが想定されていますが、プロジェクト単位で評価してもOKです
- むしろプロジェクト単位でAWSアカウントが別れていることも多いので、プロジェクト単位の評価に使うほうがいいかも
- しっかり取り組むとアセスメントはぼちぼち重たいです
- 最初のアセスメントは現在地確認をするつもりで深く考えずに、推奨事項を概要レベルで理解したら「できてる、できてない」の2択でさっくり付けていくぐらいがちょうどいいです
- 「Phase 1: クイックウィン」は文字通り、すぐにできる取り組みです
- だいたいAWSのマネージドセキュリティサービスを有効化する、とかなのですぐやりましょう
- 私のレコメンドとしては「Phase 2: 基礎」まですべてのカテゴリで実施するところが最低ラインです
- ここまでできていない項目を洗い出して、その改善から着手するといいでしょう
- 「Phase 4: 最適化」はかなり高いレベルですが、込み入ったレベルでもあるので必ずしもやらなくて良いです
- 「一般的な目指すべき理想の状態の1つ」でありすべての環境での正解ではありません
- 各推奨事項を詳細まで理解しようとするとある程度AWSセキュリティの専門性が必要になってきます
- ドキュメントを読んでもわからない、ドキュメントが足りないこともあります
- 社内にいるAWS Certified Security - Specialty有資格者などにも頼りましょう
- いなければ取得しましょう
- このブログ後半の解説も合わせて参照してください
- 推奨事項によっては私の見解では必須ではないものもあります
- あくまで指標です
- 具体的な項目は後半に解説します
評価ツールの使い方
- このツールを直接使うのもよいですが、一度試してみた後使いやすいように調整しましょう
- 調整したら、使い回せるようにマスターデータとして保管しておきましょう
- Googleスプレッドシートなどに変換しちゃうのもありです
- アセスメントを始めるときは、どのようなスコープを対象にして評価するかを定義しましょう
- 組織全体 or プロジェクトどちらか
- 対象のAWSアカウントはどれか
- データを入力するシートで、各推奨事項毎に整合性(どれくらいできているか)を入力します
- できていない部分はコメントに具体的な理由や状況を書いておきます
- 上から順に進めて、「Phase 2: 基礎」まで一通り入力できればそこで止めても問題ないです
- だいたいここまでで問題があれば、それに対応していくことを優先します
- 入力したあとリザルトシートを確認するとマトリクスの状態で確認できます
- 特に一番下のPhase毎の合計がPhase1,2共に100%になるところを最初のゴールに設定するのがちょうどいいでしょう
- このリザルトの表でも直感的に分かりづらいので、より見やすい簡易的なグラフとして先程掲載したようなグラフを作ると、他者に対して説明しやすくなります
AWSセキュリティ成熟度モデルの推奨事項の解説
ここからは実際にチェックをしていく推奨事項について解説します。項目が74個ありますが、すべてを解説するのは大変なのでPhase 1,2をすべてと、3,4については特筆すべきところをピックアップして解説します。主にその推奨事項で何を考慮するのかという「検討内容」とOKとする基準である「完了条件」を記述しています。
なお、解説の内容は主に弊社のお客様向けの解説になっているので、弊社寄りの話がちらほらありますが気にしないでください。また、あくまで私の一般的な環境に対する見解であり、推奨事項に対する様々な見解や個別の環境における判断があることも考慮して読んでください。
項目一覧
- Phase 1: クイックウィン
- 1.1.1 セキュリティ連絡先の割当て
- 1.1.2 リージョンの選択と無効化
- 1.2.1 クラウドセキュリティポスチャ管理 (CSPM)
- 1.3.1 多要素認証 (MFA) の設定
- 1.3.2 ルートの保護
- 1.3.3 ID フェデレーション
- 1.3.4 意図しないアクセス権限の削除
- 1.4.1 基本の脅威検出
- 1.4.2 API 呼び出し監査
- 1.4.4 請求アラーム
- 1.6.1 危険な通信ポートのブロック
- 1.7.1 パブリックアクセスのブロック
- 1.7.2 データセキュリティポスチャの分析
- 1.8.1 WAF とマネージドルールの活用
- 1.9.1 重大なセキュリティ検出結果への対応
- 1.10.1 レジリエンスの評価
- Phase 2: 基盤
- 2.1.1 コンプライアンスと規制要件の特定
- 2.1.2 セキュリティ研修計画
- 2.2.1 インベントリと設定モニタリング
- 2.3.1 組織のアクセス許可ガードレール
- 2.3.2 一時的な認証情報の使用
- 2.3.3 IMDSv2
- 2.4.1 高度な脅威検出
- 2.5.1 インフラの脆弱性管理
- 2.5.2 アプリケーションの脆弱性管理
- 2.6.1 ネットワークアクセスの制限
- 2.6.2 EC2 インスタンスの安全な管理
- 2.6.3 ネットワークのセグメント化
- 2.6.4 マルチアカウント管理
- 2.7.1 保存時のデータ暗号化
- 2.7.2 データのバックアップ
- 2.7.3 機密データの検出
- 2.8.1 セキュリティチームの関与
- 2.8.2 コード内のシークレット管理
- 2.9.1 インシデント対応プレイブック
- 2.10.1 マルチ AZ による可用性向上
- Phase 3: 効率化
- 3.1.1 セキュアなアーキテクチャ設計
- 3.1.2 Infrastructure as Code の活用
- 3.1.3 タグ付け戦略
- 3.2.1 コンプライアンスレポートの作成
- 3.3.1 最小権限の見直し
- 3.3.2 顧客 ID とアクセス管理(CIAM)
- 3.4.1 カスタム脅威検出 (SIEM/SecLake)
- 3.5.1 セキュリティチャンピオンの配置
- 3.5.2 DevSecOps とパイプライン
- 3.6.1 ゴールデンイメージパイプライン
- 3.6.2 マルウェア対策
- 3.6.3 アウトバウンド通信の制御
- 3.7.1 通信の暗号化
- 3.8.1 脅威モデリングの実施
- 3.8.2 WAF とマネージドルールの活用
- 3.8.3 DDoS 攻撃 (レイヤー7) の緩和
- 3.9.1 インシデント机上演習の実施
- 3.9.2 重要なプレイブックの自動化
- 3.9.3 セキュリティ調査と原因分析
- 3.10.1 ディザスタリカバリプラン
- Phase 4: 最適化
- 4.1.1 セキュリティタスクの責任分担
- 4.1.2 監査証拠の収集自動化
- 4.3.1 IAM データ境界の活用
- 4.3.2 IAM ポシリー生成パイプライン
- 4.3.3 一時的な昇格アクセスの管理
- 4.4.1 脅威インテリジェンスの活用
- 4.4.2 VPC フローログの分析
- 4.5.1 脆弱性管理チームの組成
- 4.6.1 ゼロトラストアクセスの実装
- 4.6.2 抽象化サービスの利用
- 4.7.1 生成 AI データの保護
- 4.8.2 レッドチームの編成
- 4.9.1 ブルーチームの編成
- 4.9.2 高度なセキュリティ自動化
- 4.9.3 SOAR の活用とチケット管理
- 4.9.4 設定不備の自動修正
- 4.10.1 ディザスタリカバリの自動化
- 4.10.2 カオスエンジニアリングの実施
Phase 1: クイックウィン
1.1.1 セキュリティ連絡先の割当て
検討内容
AWSアカウントの連絡先情報で「セキュリティ問い合わせ先」を登録します。万が一AWSアカウントで不正利用等が発生した場合に、この連絡先に通知されるため、常にこれを受け取れるようにして確認する必要があります。
連絡先は特定の個人のメールアドレスではなく、メーリングリストなど複数人が受信できる宛先を指定することを推奨します。これにより、1 人の従業員が休暇等で不在の場合であっても、別の人がアラートを受け取ることができます。
完了条件
クラスメソッドメンバーズのお客様はCMP(クラスメソッドメンバーズポータル)にて「AWSアカウント通知先」で「セキュリティ通知先」を登録してください。
複数人が通知を受信できるようにするため、メーリングリストもしくは複数人の個人のメールアドレスを登録できていればOKです。
クラスメソッドメンバーズでない場合は、ルートユーザーでAWSアカウントにログインし、右上の[Contact information] (連絡先情報)から「主要連絡先」「セキュリティ問い合わせ先」を登録してください。
複数人が通知を受信できるようにするため、メーリングリストを登録できていればOKです。
1.1.2 リージョンの選択と無効化
検討内容
攻撃者によるアクセス侵害の影響を軽減するため、運用上使用しないリージョンで実行するAPIは禁止すべきです。
リージョンの利用制限はAWS OrganizationsのSCPを利用する必要があり、AWSアカウント単体やプロジェクトレベルの取り組みではなく、組織全体のレベルで行う必要があるため、オプションの対策です。
すでにAWS OrganizationsやAWS Control Towerを利用している場合はこれを行うことを強く推奨します。
完了条件
SCPによりリージョン制限を設定すればOKです。
AWS Control Towerを利用していればマネージドの機能を利用を推奨します。利用していなければ「SCPの例」を参考に設定します。
クラスメソッドメンバーズで組織管理プランをご利用のお客様はAWS OrganizationsのSCPを直接ご利用いただけます。
クラスメソッドメンバーズで通常のプランをご利用のお客様はセキュアアカウント リージョン制限機能を設定すればOKです。
1.2.1 クラウドセキュリティポスチャ管理 (CSPM)
検討内容
セキュリティチェックは手動で対応すると膨大な労力が必要なので自動化することが推奨されます。
AWS Security Hubを利用するとAWS基礎セキュリティベストプラクティスのスタンダードによるAWS環境のセキュリティチェックを自動化できます。
AWS Security Hubのセキュリティチェック基準を「スタンダード」と呼びます。複数あるスタンダードのうち「AWS 基礎セキュリティのベストプラクティス v1.0.0」を利用することを推奨します。このスタンダードはAWSがメンテナンスを行い、新しいサービスやポリシーがどんどん追加されます。
AWS Security Hubを利用することで、AWS環境の危険な設定を検知して是正するフローを回すことが可能になります。
AWS Security Hubは従量課金で利用できる有償のサービスですが、無償でセキュリティチェックが利用できるサービスにAWS Trusted Advisorがあります。
AWS Trusted AdvisorはAWSのベストプラクティスに従っているか環境をチェックして是正のレコメンデーションを作成する無料のサービスです。
AWSのサポートプランに応じてチェックできる範囲が変わります。クラスメソッドメンバーズを利用している場合、すべての項目が利用可能です。
複数あるレコメンデーションのうちセキュリティのカテゴリを確認してください。
完了条件
原則はAWS Security Hubを利用し、完了条件を満たしてください。両方使っている場合はAWS Security Hubのみ対応できていればOKとします。コストの問題でAWS Security Hubを利用できない場合はAWS Trusted Advisorの要件を確認します。
・AWS Security Hub
サービスを全リージョンで有効化し、「AWS 基礎セキュリティのベストプラクティス v1.0.0」のスタンダードを有効にします。
ここまでで最低限OKとしますが、検知された項目のうちCritical(重大)のものは即時対応をすることを強く推奨します。
是正には参考としてClassmethod Cloud Guidebook(CCG)が活用できます。
「セキュアアカウント」により自動的にこれらの設定を有効化できます。
・AWS Trusted Advisor
検出されたアラートのうちセキュリティの項目で赤(推奨されるアクション)のものを中心に確認します。
やや煩雑に検出されるため、内容を理解し、重大だと思われるものに対応すればOKとします。
1.3.1 多要素認証 (MFA) の設定
検討内容
rootユーザーとIAMユーザー/IAMロールあるいは連携しているIdPですべての利用者がMFAを設定しそれを必須としている必要があります。
クラウドサービスはインターネットを経由して利用するため、ユーザーID/パスワードのみの認証は極めて危険です。
現代では例外なくすべてのユーザーがMFAを利用します。
利用するMFAの種類は仮想MFAの利用で問題ありません。
アドオンの対策として、IAMユーザーをほぼ作成しないことを検討します。
完了条件
rootユーザーとすべてのIAMユーザーでMFAを有効化し、人が利用するすべてのIAMロールでMFAを前提としたポリシーを記述すればOKです。
クラスメソッドメンバーズを利用している場合、通常rootユーザーはクラスメソッドが管理しているため委任できます。
IdPを利用している場合にはそちらでMFAが有効になっており、IAMロールでそれを必須の条件として確認できると理想的です。
1.3.2 ルートの保護
検討内容
rootユーザーはAWSアカウントで特権を持つユーザーで、特別なユーザーのため通常は利用せず封印することがベストプラクティスです。
完了条件
rootユーザーにMFAが設定され、基本的に使わないようになっていればOKです。
更にCloudTrailを活用してログインしたことをアラートしてもいいですが、コストパフォーマンスは良くないので基本的には必要ありません。
クラスメソッドメンバーズを利用していれば、通常rootはクラスメソッドが管理しているため自動的にOKです。
1.3.3 ID フェデレーション
検討内容
組織の中で、ITシステムに対するアクセス制御は一元管理されることが望ましく、AWS環境もそのうちの1つです。ベストプラクティスに基づいて環境分離することで、利用対象のAWSアカウントは増えていくため、個別にIAMユーザーを作成することはアンチパターンになります。
Microsoft Entra ID (旧称 Azure Active Directory)やOktaなど、一元的なIdPにユーザー情報が集約され、組織全体のガバナンスを適用します。
AWSのみのスコープでユーザーリポジトリの集約を検討する場合、大きく2つの方法があります。
ベーシックな方法としては、1つのAWSアカウントにIAMユーザーを集約し、他のAWSアカウントにはスイッチロールしてアクセスする、Jumpアカウント方式です。これは環境条件もほぼ無く始めやすい手段です。
より発展的な手法として、AWS Organizationsと連携してAWS IAM Identity Centerを利用したSingle Sign-Onです。これは関連するAWS環境を束ねるAWS Organizationsを利用する必要があるため、その他の要件と合わせて検討します。
いずれの方式を採用する場合でも、適切な運用体制の確立も重要です。特に以下の点について確認をしてください。
- 認証情報のローテーション管理: アクセスキーやパスワードなどの認証情報が定期的にローテーションされているか
- 退職者のID管理プロセス: 従業員が退職した際、IdPのユーザー情報が自動的に更新・削除される仕組みが整備されているか
- 人事連携のタイムラグ: 人事部門が従業員情報の削除処理を行ってから、IdPのユーザー情報が実際に削除されるまでの所要時間はどの程度か
- 運用の実効性: これらのプロセスが形骸化せず、継続的に運用されているか
完了条件
Entra IDなど組織で従業員のIdentityを一元管理する仕組みがあり、これと連携してAWS環境へのアクセスが提供されていることが理想の状態でOKです。
組織全体のIdentityを利用できない場合には、限定的な集約がされればよく、例えばJumpアカウント方式やIAM Identity Centerで集約する手法が利用できていればOKです。
IDを管理するレイヤーと、それを継続的にメンテナンスする体制があり、各ユーザーには効率的に、かつ最小権限でアクセスが提供されていればOKです。特に、認証情報のローテーション、入退社時のID更新プロセス（人事システムとの連携含む）、定期的なアクセス権限の棚卸しが実施されていることを確認します。
1.3.4 意図しないアクセス権限の削除
検討内容
退職した従業員や アカウントを侵害した不正ユーザーによる侵害のリスクを低減するため、未使用および意図しない外部アクセス権限の削除が重要です。
IAM Access AnalyzerはAWSアカウント外部から利用できるリソースを検知し一覧表示することで、意図せず公開していないか管理することができるサービスです。
IAM Access Analyzerを有効化し、すべての項目を確認していきます。
完了条件
すべてのリージョンでIAM Access Analyzerのアナライザーを作成します。
「セキュアアカウント」を利用することでアナライザーの作成と維持をクラスメソッドに委任できます。
検知されたリソースが外部からアクセスできて問題ない場合はアーカイブ、そうではない場合は是正をする。
すべて対応できたらOKです。
1.4.1 基本の脅威検出
検討内容
攻撃者の脅威は早期に検出することが重要です。
Amazon GuardDutyはAWS環境上の様々な脅威を検出します。
例えばEC2がマルウェアに感染したり、コインマイニングしたり、不正なIAMのログインがあったり、S3のデータの漏洩など幅広いレイヤーの検出が可能です。
まず有効化するだけで非常に効果を発揮するため必須のサービスです。旧来のオンプレミスのような環境では、このような仕組みのために大規模な基盤やシステムが必要でしたが、AWSではポチッと有効化するだけでその恩恵を受けられます。
完了条件
Amazon GuardDutyを全リージョンで有効化していればOKです。
「セキュアアカウント」を利用することで有効化と維持をクラスメソッドに委任できます。
必須ではありませんが、今後の運用のためチーム全体がAmazon GuardDutyの検出結果を理解していることも重要です。
「インシデント自動調査」を利用することで検出結果を日本語化したアラートを受信できるので、チーム全体の検出結果の理解を促進できます。
1.4.2 API 呼び出し監査
検討内容
ログの取得と保護は極めて重要です。セキュリティ調査においてログを調査することで、攻撃者の行動を把握し、根本原因や被害範囲を特定し、迅速な対応や復旧、不正作成されたアクセス権の削除といったことが可能になります。
AWS CloudTrailを有効化するとすべてのAPIコールを記録できます。AWS CloudTrailはAWSで実行したAPIの証跡をとり監査することが可能です。AWS利用に必須のサービスです。
完了条件
AWS CloudTrailを有効化し、S3バケットにログを保存すればOKです。
管理ログのみで問題ありません。
クラスメソッドメンバーズを利用している場合デフォルトで有効化されています。
「セキュアアカウント」を利用している場合はよりセキュアな設定になります。
1.4.4 請求アラーム
検討内容
従量課金で利用するクラウド環境では、課金のモニタリングが必須です。これはセキュリティの文脈としても有効で、不正な利用があった場合などにも、資産を守る意味合いで想定される金額を超えた場合の検知が有効です。
AWS BillingやAWS Cost Explorerを活用して料金アラートを設定したり詳細を確認したりできます。
クラスメソッドメンバーズではAWSマネジメントコンソールで正確な利用費を確認できないため、代わりにクラスメソッドメンバーズポータルで利用費を確認し、料金アラームを設定できます。
完了条件
料金アラームを設定したらOKです。
1.6.1 危険な通信ポートのブロック
検討内容
管理ポート(22と3389) への無制限のインバウンドトラフィックを許可することは重大なリスクです。ホストが適切にパッチ適用や強化されていない場合、攻撃者が脆弱性を利用してアクセスし制御権を奪取したり、SSH や RDP のブルートフォース 攻撃によってアクセスを取得したりするリスクがあります。管理ポートをクローズすることでこれらのリスクを回避できます。
セキュリティグループで制限なしの送信元(0.0.0.0/0)からの管理サービス用ポート(22/SSH, 3389/RDP)へのインバウンド通信を設定しないでください。
更に現在では管理アクセスポートを開放しなくても、AWS Systems Manager Session Managerなどを利用して管理アクセスが可能であるため、ポートを開放せずに利用することがベストプラクティスです。
完了条件
すべてのEC2インスタンスにアタッチしたセキュリティグループでSSH/RDPポートを許可していなければOKです。
許可する場合、送信元IPを/32レベルで制限します。
この確認はAWS Security Hubのチェック項目「[EC2.21] ネットワーク ACL は、0.0.0.0/0 からポート 22、またはポート 3389 への侵入を許可しないようにする必要があります」が全て対応できていることでも確認可能です。
1.7.1 パブリックアクセスのブロック
検討内容
「ブロックパブリックアクセス(BPA)」はAWSリソースが誤って公開されてしまうのを防ぐ機能です。
Amazon S3はデフォルトでアカウントレベルのブロックパブリックアクセスが有効になっています。これはS3バケットの設定に関わらず、オーバーラップしてS3バケットの公開を抑制する設定です。
通常S3バケットを公開することは殆どないため、アカウントレベルのブロックパブリックアクセスを有効にした状態で利用します。
S3バケットを直接公開する必要がある場合には、アカウントレベルのブロックパブリックアクセスの代わりに、バケットレベルのブロックパブリックアクセスを活用し、必要なバケット以外を保護します。
CloudFrontを利用してS3を公開する場合、S3バケット自体は非公開で利用可能なためブロックパブリックアクセスを有効にしたままにします。
Amazon EC2ではAMIとEBSのパブリック公開が可能ですが、基本的には不要です。それぞれのBPA機能をリージョン単位で有効化することで、公開を抑制できます。
完了条件
以下を有効にしていればOKです。
- S3のアカウントレベルのブロックパブリックアクセス
- 利用している各リージョンでのEC2 AMIのブロックパブリックアクセス
- 利用している各リージョンでのEBSスナップショットのブロックパブリックアクセス
公開するS3バケットが存在する場合には、そのコンテンツの内容とリスクを適切に判断し、それ以外のS3バケットでブロックパブリックアクセスが有効になっていればOKです。
EC2 AMI、EBSスナップショットを他アカウントに共有するときは、パブリック公開ではなくプライベート公開で共有先のAWSアカウントやOrganizations組織を直接指定するようにしてください。
1.7.2 データセキュリティポスチャの分析
検討内容
機密データの保存場所は明確に定義することが重要です。安全な場所を指定しないと、ユーザーや開発者がより危険な場所にデータを保存してしまう可能性があります。
Phase 1では、まず現状のデータセキュリティ体制を把握することから始めます。
以下の観点で、対象のAWSアカウント上のデータの取り扱い状況を確認してください。
■ 機密データの有無の確認
対象のAWSアカウント上で機密データ（個人情報、認証情報、決済情報など）を取り扱っているかを確認します。
取り扱っている場合、どのサービス（S3、RDS、DynamoDB等）にどのようなデータが保管されているか把握します。
■ 基本的なデータ保護状況の確認
- S3バケットが意図せずパブリック公開されていないか
- データストアに保管時の暗号化が適用されているか
- 不要なデータが放置されていないか
■ Amazon Macieの活用（オプション）
Amazon MacieはS3に保管されている機密データの検出と保護を行うサービスです。
Macieを有効化することで、S3バケットに保存されている機密データを自動的に発見してラベリングが可能になります。
データ設計通りに保管されているか、あるいは不用意に機密データが混入していないかの確認に活用できます。
Macieは利用に関する費用と運用の難易度でハードルがあるため、オプションとします。
完了条件
以下が確認できていればOKです。
- 対象のAWSアカウント上で機密データを取り扱っているかどうかが明確になっている
- 機密データを取り扱っている場合、どのデータストアに保管されているか把握できている
- パブリック公開や暗号化未適用など、明らかなリスクがないことを確認している
Amazon Macieを有効化して上記の確認に活用することも有効です。
1.8.1 WAF とマネージドルールの活用
検討内容
多くの Web アプリケーションはサービス提供のためにインターネットに公開する必要があるため、アプリケーションや基盤となるミドルウェアの脆弱性に攻撃者がアクセスできるリスクがあります。
セキュアコーディングプラクティスはアプリケーションの侵害を防ぐために不可欠ですが、ほとんどの開発チームはセキュリティの専門家ではないか、セキュアコーディングプラクティスに優先順位をつける時間がなく、脆弱性が発生する可能性があります。
Webアプリケーションファイアウォール(WAF) はこれらの脆弱性の悪用をブロックするのに非常に役立ちます。
AWS WAFはAWS環境で透過的に、簡単に導入できるWAFです。AWS WAFはマネージドルールが提供され、OWASP トップ 10に対する保護などが可能になります。
定常的なアプリケーションに対する攻撃の対策のほか、新規に発見された脆弱性への即時対応やDDoSからの保護、高度なBOTや標的型攻撃からの保護など、いざという時にすぐに使えるように基本構成として導入すべきです。
完了条件
外部向けに公開しているAmazon CloudFront / ALB / API Gateway / AWS AppSyncに対してAWS WAFのWeb ACLをアタッチし、有用と思えるマネージドルールを適用していればOKです。
1.9.1 重大なセキュリティ検出結果への対応
検討内容
リスクを特定するセキュリティ制御や検出制御は、誰か (人間) または何か (自動化) が脅威を調査して封じ込めるアクションを実行しないと、追加のセキュリティは提供されません。
Amazon GuardDutyにより検出された脅威がある場合、これに対応します。緊急度が高のものは、非常に危険であり攻撃者からの影響を受けている可能性が高いです。即時封じ込めを行います。
緊急度が中低のものはPhase2の脅威検出の範囲とします。
完了条件
1週間Amazon GuardDutyが緊急度高のものを検知しない状況になっていればOKです。
1.10.1 レジリエンスの評価
検討内容
重要なアプリケーションやデータのレジリエンスを評価し、本番環境の重要データがロストしないようにバックアップが適切に取得・管理されているかを確認します。
評価には AWS Resilience Hub または AWS Security Hub CSPM を活用できます。
Resilience Hub では RTO/RPO に基づいた耐障害性スコアを算出できます。
Security Hub CSPM では、有効化されたスタンダード（AWS Foundational Security Best Practices など）に含まれるバックアップ関連コントロールを通じて、バックアップの設定状況を継続的に監視・評価できます。
完了条件
以下いずれかの方法で、重要ワークロードのバックアップ状況が評価・可視化できていればOKです。
- Resilience Hub を有効化されており、重要ワークロードを分析してResiliency Score が確認できている
- Security Hub CSPM が有効化されており、重要ワークロードにおいて以下のようなバックアップ関連コントロールの準拠状況を確認できている
(コントロール例)- バックアップ(PITR)
- DynamoDB.2：DynamoDB テーブルでは、ポイントインタイムリカバリが有効になっている必要があります
- DynamoDB.4：DynamoDB テーブルはバックアッププランに含まれている必要があります
- EC2.28：EBS ボリュームはバックアッププランに入っている必要があります
- マルチ AZ・高可用性構成
- AutoScaling.2：Amazon EC2 Auto Scaling グループは、複数のアベイラビリティーゾーンをカバーする必要があります
- ELB.13：Application、Network、Gateway Load Balancer は、複数の AZ にまたがっている必要があります
- 削除保護
- ELB.6：アプリケーション、ゲートウェイ、Network Load Balancer で削除保護を有効にする必要があります
- DynamoDB.6：DynamoDB テーブルで、削除保護が有効になっている必要があります
- バックアップ(PITR)
※いずれの場合も、ビジネス側で SLA / RTO / RPO が定義されていることが望ましい
Phase 2: 基盤
2.1.1 コンプライアンスと規制要件の特定
検討内容
対象のAWS環境及びサービスなどのアセスメント対象のワークロードや組織自体に求められるコンプライアンス要件を確認します。
例えば金融系のサービスであればFISCの要件があるとか、自社の情報セキュリティポリシーや準拠すべきスタンダード・セキュリティチェックリストなどの要件などが対象です。
特にない場合には、クラスメソッド推奨としてまずはAWS Security Hubを利用したセキュリティチェックの運用をルールにすることを推奨とします。
完了条件
ここでは満たすべき要件を決めたらOKです。
サードパーティのCSPM製品などでルールを決めてもOKです。
2.1.2 セキュリティ研修計画
検討内容
AWSの利用者とAWSの管理者向けにAWSセキュリティの前提知識を身につけるためのトレーニングメニューを構成します。
AWSはインターネットの先に存在するサービスです。プライベートな社内の検証環境とは異なるため、AWSの利用者はAWS利用の前に最低限のセキュリティの教育を受ける必要があります。
AWSの管理者はAWSの特徴とその上に構築するワークロード、自社のセキュリティポリシーを理解してそのセキュリティに責任を持つ必要があります。AWSのセキュリティ機能をよく理解し、これを管理運用するための知識が求められます。
完了条件
-
すべてのAWS利用者にIAMの扱いについて基本的な教育を実施する規則などを定め、これを運用できていればOKです。
-
プロジェクトのAWS管理者や組織全体のAWS管理者に対するAWSセキュリティ知識を習得する機会が整備されていればOKです。資格としてはAWS Certified Security - Specialty相当の知識を基準とします。
2.2.1 インベントリと設定モニタリング
検討内容
基本的にはAWS ConfigをマネージドしているAWS Security Hubの運用により構成管理が行われることを前提とします。各種AWSの基本的なセキュリティ設定が満たされていることを確認していきます。
完了条件
例えば以下のような項目の監視と是正が適切に運用できていることでOKとします。
- [ACM.2] ACM が管理する RSA 証明書は、少なくとも 2,048 ビットの鍵長を使用する必要があります
- [AutoScaling.3] Auto Scaling グループは、EC2インスタンスが Instance Metadata Service Version 2 (IMDSv2) を必要とするように設定すべき
- [AutoScaling.5] Auto Scalingグループに関連付けられた起動設定はパブリックIPを割り当てる設定であってはならない
- [CloudFront.1] CloudFrontのディストリビューションでは、デフォルトのルートオブジェクトが設定されている必要があります
- [CloudFront.12] CloudFront ディストリビューションは、存在しない S3 オリジンをポイントしない必要があります
- [CloudTrail.1] CloudTrail を有効にして、少なくとも 1 つのマルチリージョンの追跡で、読み取りと書き込みの管理イベントを含めた設定をする必要があります
- [CodeBuild.1] CodeBuild Bitbucket ソースリポジトリ URL には機密性の高い認証情報を含めないでください
- [CodeBuild.2] CodeBuild プロジェクトの環境変数には、クリアテキストの認証情報を含めないでください
- [DMS.1] Database Migration Service のレプリケーションインスタンスはパブリックであってはなりません
- [EC2.1] Amazon EBS スナップショットはパブリックに復元可能であってはなりません
- [EC2.2] VPC のデフォルトのセキュリティグループはインバウンドトラフィックまたはアウトバウンドトラフィックを許可しない必要があります
- [EC2.8] EC2 インスタンスでは、Instance Metadata Service Version 2 (IMDSv2) を使用する必要があります
- [EC2.9] EC2インスタンスはパブリックIPv4アドレスを持つべきではない
- [EC2.18] セキュリティグループは、許可されたポートに対する無制限の受信トラフィックのみを許可する必要がある
- [EC2.19] セキュリティグループは、リスクの高いポートへの無制限のアクセスを許可してはならない
- [EC2.23] EC2 Transit Gateway はVPCアタッチメントのリクエストを自動承諾すべきではない
- [EC2.25] EC2の起動テンプレートは、ネットワークインターフェイスにパブリックIPを割り当てるべきではありません
- [ECS.1] Amazon ECSのタスク定義には、安全なネットワークモードとユーザー定義が必要です
- [ECS.2] Amazon ECSサービスは、パブリックIPアドレスを自動的に割り当ててはいけません
- [ECS.3] ECS タスクの定義では、ホストのPID Namespaceを共有しないでください
- [ECS.4] ECSコンテナは、非特権モードで実行する必要がある
- [ECS.8] シークレットはコンテナ環境変数へ渡すべきではない
- [ECS.16] ECSタスクセットは、パブリックIPアドレスを自動的に割り当てるべきではありません
- [ElastiCache.7] ElastiCache クラスターは、デフォルトのサブネットグループを使うべきではありません
- [EMR.1] Amazon Elastic MapReduce クラスターのプライマリーノードにはパブリック IP を使用できません
- [EMR.2] Amazon EMR ブロックパブリックアクセス設定を有効にする必要があります
- [ES.2] Amazon Elasticsearch Serviceのドメインはパブリック公開してはいけません
- [GuardDuty.1] GuardDuty を有効にする必要があります
- [IAM.1] IAM ポリシーは完全な「*」管理権限を許可してはなりません
- [IAM.4] IAM ルートユーザーアクセスキーは存在してはなりません
- [KMS.3] AWS KMSのキーは意図せずに削除してはいけない
- [KMS.5] KMSキーはパブリックに公開すべきではありません
- [Lambda.1] Lambda 関数は、他のアカウントによるパブリックアクセスを禁止する必要があります
- [Opensearch.2] OpenSearchドメインはパブリック公開してはいけません
- [RDS.1] RDS スナップショットはプライベートにする必要があります
- [RDS.2] RDS DB インスタンスは、PubliclyAccessible 設定によって判断される、パブリックアクセスを禁止する必要があります
- [RDS.18] RDSインスタンスはVPC内に配置すべき
- [Redshift.1] Amazon Redshiftクラスターはパブリックアクセスを禁止すべき
- [Redshift.15] Redshift セキュリティ グループは制限されたオリジンからのみクラスター ポートへの進入を許可する必要があります
- [RedshiftServerless.1] Amazon Redshift Serverless ワークグループは Enhanced VPC Routing を使用する必要があります
- [S3.2] S3 汎用バケットはパブリック読み取りアクセスを禁止する必要があります
- [S3.3] S3 汎用バケットはパブリック書き込みアクセスを禁止する必要があります
- [S3.6] S3 汎用バケットポリシーは他のAWSアカウントへのアクセスを制限する必要がある
- [S3.8] S3 汎用バケットはパブリックアクセスをブロックする必要がある
- [S3.19] S3 アクセスポイントではブロックパブリックアクセス設定を有効にする必要があります
- [S3.24] S3マルチリージョンアクセスポイントは、パブリックアクセスのブロック設定を有効にする必要があります
- [SNS.4] SNS トピックアクセスポリシーはパブリックアクセスを許可するべきではありません
- [SQS.3] SQS キューアクセスポリシーではパブリックアクセスを許可しないでください
- [SSM.4] SSMドキュメントはパブリック公開してはいけません
何を対応すべきかについては、クラスメソッドメンバーズを利用しているお客様はClassmethod Cloud Guidebookの「AWS 基礎セキュリティのベストプラクティス v1.0.0」ガイドで重要度やCM推奨対応などを参考にしてください。
新しい項目が検知された際に通知できるようになっているとより適切です。
「セキュアアカウント」を利用すればAWS Security Hubの有効化と適切な設定が自動的に完了し、通知を簡単に始めることができます。
2.3.1 組織のアクセス許可ガードレール
検討内容
AWS OrganizationsのSCPを駆使して組織のガードレールを整備します。SCPを利用すれば、組織内のガードレールを展開していくことが可能です。利用するリージョンの制限や整備したCloudTrailやGuardDutyなどのサービスの停止を禁止するなどが可能です。
RCPをガードレールに適用することもできます。RCPはリソースベースの制御で、組織内のリソース全体にわたって、誰がそのリソースにアクセスできるかを一元的に制御します。
RCPの具体的な利用例
- 特定のIAMロールからの設定変更のみ許可: 本番環境のリソースに対して、承認された特定のIAMロールからのAPI操作のみを許可し、それ以外のプリンシパルからの操作を拒否
DP（Declarative Policies）を活用することで、特定のAWS サービスのベースライン構成を指定でき、組織全体へ適用できます。
DPでサポートしている属性
- VPC
- VPC のブロックパブリックアクセス
- EC2
- シリアルコンソールアクセス
- AMI のブロックパブリックアクセス
- 許可されたAMI の利用
- IMDS のデフォルト設定
- EBS
- EBS スナップショットのブロックパブリックアクセス
AWS Organizationsが必要なためオプションとします。クラスメソッドメンバーズを利用していてAWS Organizationsを利用される場合は組織管理プランをご利用ください。マルチアカウント管理、CCoE支援にてこの項目を満たすための支援が可能です。
完了条件
リージョン制限やベースラインサービスの停止禁止などのポリシーを検討して、SCP、RCP、DPを利用してこれを実装できていればOKです。
2.3.2 一時的な認証情報の使用
検討内容
IAMユーザーやアクセスキーの使用は、認証情報の漏洩リスクがあるため推奨されません。
ユーザーによるコンソールアクセスは、IAM Identity CenterまたはJumpアカウント方式のみ許可します。（JumpアカウントはIAMユーザーを作成しますが、IAMユーザー自体には権限を付与しないため例外とします。）
特にアクセスキーは、コードへのハードコーディングや誤ったGit管理により流出する危険性があります。
EC2インスタンスからAWSリソースにアクセスする場合は、アクセスキーを使用せず、インスタンスプロファイル（IAMロール）を利用してください。IAMロールは一時的な認証情報を自動的に取得・更新するため、認証情報の管理が不要となり、安全性も向上します。
同様に、Lambda関数には実行ロールを、ECSタスクにはタスクロールを割り当てることで、セキュアなアクセス制御を実現できます。可能な限りIAMロールベースの認証を採用することが、AWSセキュリティのベストプラクティスです。
ローカル環境で開発する場合も、aws loginを利用すれば、AWSマネジメントコンソールにログイン済みのブラウザで承認するだけで、ローカルのAWS CLIを使用できます。
完了条件
IAMユーザーとアクセスキーが存在しない運用になっていれば完了です。（JumpアカウントのIAMユーザーを除く）
アプリケーションからAWSリソースへアクセスする際は、IAMロール（EC2インスタンスプロファイルやLambda実行ロールなど）を活用し、永続的な認証情報の使用を最小化できていれば問題ありません。
SaaS連携についても、アクセスキーを使用せず、OIDC連携やExternalId付きのIAMロールを利用できていれば問題ありません。
また、データベースパスワードなどのシークレットはAWS Secrets Managerで管理し、コードにシークレットを保存しないことを徹底してください。
2.3.3 IMDSv2
検討内容
Amazon EC2インスタンスメタデータサービス(IMDS)は、インスタンスに関する情報や一時的な認証情報へのアクセスを提供する機能です。IMDSを利用することで、機密性の高い認証情報をインスタンスに手動またはプログラムでハードコードする必要がなくなり、セキュリティが向上します。
インスタンスメタデータサービスにはバージョン1(IMDSv1)とバージョン2(IMDSv2)があります。IMDSv1はシンプルなリクエスト/レスポンス方式ですが、IMDSv2はセッション指向のリクエスト方式を採用しており、SSRF(Server-Side Request Forgery)攻撃などによる認証情報の不正取得を防ぐ保護機能が強化されています。セキュリティ向上のため、IMDSv2の使用を強く推奨します。
AWS Security Hubの以下のコントロールや
- [EC2.8] EC2インスタンスは、インスタンスメタデータサービスバージョン2(IMDSv2)を使用する必要があります
- [ EC2.170 ] EC2 起動テンプレートでは、Instance Metadata Service Version 2 (IMDSv2) を使用する必要があります
- [AutoScaling.3] Auto Scaling グループの起動設定は、EC2インスタンスが Instance Metadata Service Version 2 (IMDSv2) を使用するように設定する必要があります
AWS Configルールの「ec2-imdsv2-check」を使用して、IMDSv2のみを使用していることを確認することが可能です。
IMDSv1からv2への移行については以下のブログを参照ください
完了条件
新しく起動される全てのEC2インスタンスがデフォルトでIMDSv2のみを使用する設定になっており、既存のインスタンスについてもIMDSv2のみが使用されるように設定できていればOKです。
2.4.1 高度な脅威検出
検討内容
Amazon GuardDutyの検出結果が出ているものを調査し是正します。
緊急度が中低のものが頻繁に出る場合にはアーキテクチャに問題があります。根本的に構成を変えることを検討しましょう。
GuardDutyには、特定のAWSサービスやリソースに対する脅威検出を強化する保護プランが用意されています。利用しているサービスに応じて、以下の保護プランの有効化を検討してください。
- S3 Protection: Amazon S3 バケットへの不正なアクセスやデータの改ざんを検出
- EKS Protection: Amazon EKS クラスターの Kubernetes 監査ログを分析して、潜在的に悪質で疑わしいアクティビティを検出
- 拡張脅威検出: AWS アカウント、ワークロード、データを標的とする高度な多段階攻撃を一意に識別
- Runtime Monitoring: Amazon EKS、Amazon ECS (AWS Fargate を含む)、および Amazon EC2 のオペレーティングシステムレベルのイベントを監視および分析して、潜在的な脅威を検出
- EC2 の Malware Protection: EC2 上のマルウェアをシグネチャと挙動から検出し、隔離を支援します。
- S3 の Malware Protection: 取り込み時にスキャンし、結果に応じてオブジェクトへタグ付けしてダウンロード制御・隔離・通知を実現します。
- RDS Protection: RDS ログインアクティビティを分析してプロファイリングし、潜在的なアクセス脅威を特定
- Lambda Protection: VPC フローログをはじめとするネットワークアクティビティを継続的に監視して、AWS Lambda 関数に対する脅威を検出
S3 の Malware Protection は任意のバケットを選択し、そのバケットに新たなオブジェクトが追加された場合にスキャンを行い、スキャン結果に基づいてオブジェクトにタグづけされるような機能となります。そのためアプリケーション側での作り込みなどが必要です。
各保護プランには独立した無料試用期間と料金が設定されています。利用しているサービスに応じて、必要な保護プランを有効化することで、より詳細な脅威の可視化が可能になります。
クラスメソッドメンバーズでは「インシデント自動調査」を利用することでよりわかりやすい解説とレコメンデーションを受けることが可能です。
完了条件
1週間Amazon GuardDutyが何も検知しない状況になっていればOKです。
保護プランは以下の2つを除き、原則として全て有効化してください。ただし、サードパーティ製品で同等の機能を既に実装している場合は、コストを考慮して個別に判断してください。
- GuardDuty Runtime Monitoring：VPCエンドポイント作成 / エージェントインストールなど既存環境への適用が必要なるため、必須としません
- S3 の Malware Protection：バケットを外部公開し、ユーザーがオブジェクトをアップロード可能な場合のみ有効化を検討してください
2.5.1 インフラの脆弱性管理
検討内容
脆弱性診断・管理のソリューションを利用し、システムや組織全体の脆弱性を発見し対応する環境を構築します。
プロが定期的に実行する脆弱性診断と、常にシステム全体の脆弱性をツールでチェックし対応する脆弱性管理の2つのアプローチを組み合わせます。
一般に組織内には脆弱性診断のプロが在籍していないため、サービスリリース前や定期的(1年や3か月に一度など)に外部の脆弱性診断サービスを利用する必要があります。
これと合わせて、組織内で自分たちで常に脆弱性の管理を定常的に実行するために脆弱性管理ツールを用います。
インフラストラクチャの脆弱性診断はプラットフォーム診断あるいはネットワーク診断とも呼ばれ、OS/ミドルウェア/ソフトウェアパッケージ等に存在する既知の脆弱性を発見し対応していく必要があります。
AWSのサービスでインフラストラクチャの脆弱性管理を行うする場合、Amazon Inspectorを利用した脆弱性情報の収集と管理を行います。
Amazon Inspectorは、2つのスキャン方式をサポートしています。
- エージェントベースのスキャン（推奨） AWS Systems Manager Agent (SSM Agent) を活用し、インスタンス内部から継続的にリアルタイムで脆弱性情報を収集します。
- エージェントレススキャン（ハイブリッドスキャン） EBS ボリュームのスナップショットを使用してスキャンを実施します。仮想アプライアンスや SSM Agent をインストールできないインスタンスに有効ですが、スナップショットベースのため、エージェントベースと比較してリアルタイム性に劣ります。
可能な限りエージェントベースのスキャンを使用し、技術的な制約がある場合にのみエージェントレススキャンを活用してください。
完了条件
脆弱性管理としてはAmazon Inspectorにより発見された、EC2/ECR/Lambdaに関する脆弱性を適切にハンドリングして対処できていればOKです。同様のツールを利用している場合も、すべての項目を潰しこむことは難しいため、重大度の高い問題をハンドリングできていればOKです。
合わせて、定期的な外部の脆弱性診断を利用できていればOKです。
2.5.2 アプリケーションの脆弱性管理
検討内容
アプリケーションの脆弱性診断はインフラストラクチャの脆弱性のようにパッケージ等に含まれる既知の脆弱性も扱いつつも、メインはアプリケーション実装に伴い作り込まれる脆弱性パターン(CWE)を発見します。Webアプリケーションの他、iOS/Android/Windows/Mac等ネイティブアプリケーションや生成AI/LLMを利用したアプリケーションなども対象です。
基本的にツールによる診断と専門家による診断を併用してください。
専門家によるアプリケーションの脆弱性診断は、自組織でカバーできない領域まで確認ができます。サービスリリース前や大きな更新をする際、年に1度などのタイミングで実施することを推奨します。
ツール利用ではSAST/DAST/SCAをソフトウェア開発ライフサイクルのいずれかのプロセスでセキュリティチェックを実施してください。
- SAST: 静的アプリケーションセキュリティテスト。ソースコードを解析して、実行前に脆弱性を見つけ出します。
- DAST: 動的アプリケーションセキュリティテスト。アプリを実際に動かし、外部からの攻撃シミュレーションによって脆弱性を診断します。
- SCA: ソフトウェア構成分析。使用しているライブラリなどのオープンソースコンポーネントに、既知の脆弱性やライセンス違反がないかを確認します。
スキャンをする場所・タイミングですが、多層防御の観点からIDE内やパイプライン、デプロイされたアプリケーションなど複数箇所でスキャンをすることが重要です。
AWS のサービスによる対応例
- 開発 UI 内: Kiro CLI (旧 Amazon Q Developer / Amazon CodeWhisperer) は、開発者がコードを書く際に脆弱性を検出し、修正の推奨事項を提供します。
- パイプライン内: Amazon Inspector でコードスキャン (SAST) を実行できます。
- イメージリポジトリ内: Amazon Inspector で Amazon Elastic Container Registry 上のイメージをスキャンできます。
AWS上のアプリケーションとしては特にAmazon Cognitoなど、AWS特有のサービスやアーキテクチャの利用による脆弱性の作り込みなども懸念となります。
クラスメソッドでは「GMOサイバーセキュリティ脆弱性診断」にて適切な脆弱性診断や管理方法の提示と支援が可能です。
完了条件
専門家によるアプリケーション全体の脆弱性診断を定期的に受ける仕組みが整っていればOKです。
SAST、DASTなどのツールの検討を行い、手動などでスポット的に利用できてきればOKです。
将来的にパイプラインや開発フローに組み込み、シフトレフトでの開発が出来ると理想系です。
2.6.1 ネットワークアクセスの制限
検討内容
セキュリティグループでは、常に必要最小限のネットワークアクセスのみを許可してください。
特に、Web ポート以外のオープンポートや、どこからでもアクセスできる内部向けの Web アプリケーションには注意が必要です。
なるべくセキュリティグループの参照を利用することで、最小権限を許可することが可能です。
完了条件
セキュリティグループが最小限のポートのみを許可する形になっていればOKです。
2.6.2 EC2 インスタンスの安全な管理
検討内容
EC2インスタンス等の構築したAWSインフラに対するSSH/RDPなどの管理アクセスには、直接ネットワーク的にアクセスせずに、代わりにAWS Systems Manager Session ManagerやFleet Managerを利用してアクセスします。
ジャストインタイムノードアクセス (JITNA)を利用することで運用者が EC2 などのノードにアクセスする際に、承認フローを通じて一時的なアクセス権を得る仕組みを導入することも可能です。
完了条件
Session ManagerやFleet Managerを利用し、SSH/RDPのポートを一切インターネットに公開しなければOKです。
2.6.3 ネットワークのセグメント化
検討内容
VPC内の各リソースは適切なサブネットに分割して配置する必要があります。
役割や必要性に応じて分離することで、外部から受ける影響(アタックサーフェイス)を減らし、影響があっても爆発半径(Blast Radius)を小さくできます。
基本的にパブリックサブネットにはEC2インスタンスなどを設置する必要性はありません。現在ではSystems Manager Session ManagerやEC2 Instance Connectを活用してプライベートサブネットのEC2インスタンスに直接管理アクセスすることが可能です。
またアカウント内のリソースの競合を避け、アカウント単位のサービス制限の影響を受ける可能性を減らすため、環境 (開発/テスト/本番) やワークロードなどアカウントレベルで分割することをお勧めします。
完了条件
VPCでパブリックサブネットにEC2インスタンスを設置していなければOKです。
RDSなども別のサブネットに分離できているとより良いです。
別の環境やワークロードであればアカウントレベルで分離が出来ていればOKです。
2.6.4 マルチアカウント管理
検討内容
AWS Control Towerを利用することで、マルチアカウント管理を円滑に行うための初期セットアップや運用が可能になります。
ID管理、ガードレールの整備、アカウント発行フロー整備、ログ管理監視などの機能をAWS Control Towerを利用することで簡単にできます。
AWS Control Towerの利用自体にハードルが高いためオプションとします。マルチアカウント管理、CCoE支援にてこの項目を満たすための支援が可能です。
完了条件
AWS Control Towerを利用するためのマルチアカウント管理に関する設計を行い、全体で守るべき要件が決められ、AWSアカウントの発行から利用まで運用のフローができている状態でOKです。
2.7.1 保存時のデータ暗号化
検討内容
AWS上に配置するすべてのデータはユーザーの責任により管理されます。これはAWSの責任共有モデルにより定義されています。
AWSの各種ストレージ上で保管するデータ(Data at Rest)については、ユーザーが設定することで保管時の暗号化が可能です。これにより物理的な経路でのデータアクセスを防止し、またコンプライアンスを満たすことが可能です。
データの保管時の暗号化について検討する際は、「なぜ暗号化するのか？」ではなく「なぜ暗号化しないのか？」から検討します。少なくともAWSの上では低コストで保管時の暗号化が実現でき、組織が扱うデータを管理する説明責任を果たすためには暗号化しない選択肢はありません。
AWS KMSを利用するとデータへのアクセスをユーザー側で管理することが可能になります。鍵を破棄することによる暗号化消去(Cryptographic Erase: CE)も可能になり、顧客に対する説明責任を果たせます。
個人情報や機密データを扱うストレージではAWS KMSを利用して保管時のデータを暗号化し、最終的にデータを削除する際には暗号化消去を実施できるようにします。
AWSマネージドキーとカスタマーマネージドキーの使い分けですが、以下の要件がある場合はカスタマーマネージドキーを検討してください
- キーを自分で管理する必要がある(鍵の無効化やアクセス制御)
- アカウント間でキーを共有する必要がある(インシデント対応チームとスナップショットを共有する際に便利)
- コンプライアンスのニーズに応じてローテーション間隔をカスタマイズできる必要がある
完了条件
AWS上で保存するすべてのデータに保管時の暗号化が適用されていること。
S3などでデフォルトのサービスの鍵を使用して暗号化をしていてもOKですが、個人情報や機密データを扱うものはAWS KMSで個別に鍵を作成してこれを適用していればOKです。
2.7.2 データのバックアップ
検討内容
データのバックアップは様々な目的で必要になります。データやシステムの可用性の確保したり、ランサムウェアの対策としてデータの喪失を防いだりします。その要件も対象毎に異なり、復旧までの許容できる時間やデータの範囲(期間など)を、BCDR等目的のために定義をしていきます。
AWS Backupは各種リソースのバックアップを一括で管理し復元までサポートします。まとめて設定できる部分は積極的にAWS Backupを利用しましょう。
従業員データをNFSなどでEFS/FSx/s3fs/Mountpoint for Amazon S3等につなぎ込んでいる場合には、特にこのデータのランサムウェア対策が重要で、WORMやVaultLockなどの変更不可のバックアップ・クロスアカウントバックアップによる退避・Amazon GuardDuty等による検出・AWS外のサードパーティのバックアップ・ランサムウェア対策ソリューションも活用しつつ汚染されていないデータを保持し復旧できるようにしましょう。
完了条件
以下のような質問に回答できればOKです。
- 重要なアプリケーションのバックアップを全て取得できているか
- バックアップデータが別のアカウントで管理できているか
- バックアップの保持ポリシーがあるか（例: 日次、週次、月次など）
- バックアップがリカバリポイント目標（RPO）およびリカバリ時間目標（RTO）に沿って取得できているか
- ランサムウェア等によるバックアップデータの汚染を防止・復旧できるか
また、実際に想定通りに復旧できるか訓練していると尚良いです。
2.7.3 機密データの検出
検討内容
Amazon Macieを利用することで、S3バケットに保存されたデータから機密情報を発見することができる。これにより、正しく想定通りのデータが格納されているか、あるいは想定外の機密データを保管していないか確認できます。
完了条件
組織あるいはプロジェクトで守るべき情報とその重要度が定義されている。
その上でAmazon Macieが有効化されて以下の運用があるとOK
- 機密データ自動検出を利用して機密データが保持されているS3バケットを特定している
- 公開されていたり暗号化されていないS3バケットを特定している
- それらがポリシーに照らし合わせて適切か、必要外の場所に機密データが無いかを定期的にチェックできている
2.8.1 セキュリティチームの関与
検討内容
セキュリティはすべての物事に必要となる基本項目であり、アプリケーション開発においても初期から検討すべき内容です。
しばしばアプリケーション開発では、セキュリティに関する考慮が蔑ろにされ、リリース直前になってからしか、あるいはリリースされてからもセキュリティ対策について考慮されていない場合があります。
そのようなことが無いよう、開発の初期段階からセキュリティのプロフェッショナルが参画する必要があります。
具体的には、以下のような質問に回答できるようにすべきです。
- セキュリティチームは開発チームとどのように連携しているか（例: 予防型、事後対応型）
- アプリケーションの設計段階で、セキュリティチームのメンバーと連携してアーキテクチャ上の決定を行っているか
- セキュリティチームが、開発チームに対してセキュリティのベストプラクティスに関する早期のガイダンスを提供しているか
- セキュリティチームが、アプリケーションのセキュリティレビューの初期段階から関与しているか
- セキュリティチームがリリースのどのくらい前からアプリケーションに関与しているか
- 開発者が疑問点を質問する際に、セキュリティチームに簡単に連絡を取ることはできるか
完了条件
スコープがプロジェクトの場合、該当プロジェクトでセキュリティ部門が設計に関与できているか、あるいは開発チームに、セキュリティを主導しながら開発できるセキュリティチャンピオンが在籍していればOKです。
スコープが組織の場合、上記のような取り組みが組織の仕組みで常に適用されるようになっていればOKです。
2.8.2 コード内のシークレット管理
検討内容
アプリケーションコードにクレデンシャル(シークレット)を直接記述することは、意図せず認証情報が漏洩する原因となるためアンチパターンです。
AWS Secrets Managerを利用するとシークレットを外部管理できます。また、オープンソースのgit-secretsなどを利用すると、コード内のシークレットを特定することが可能です。
完了条件
以下の項目をアプリケーションコードに直接埋め込まないようにします。
- IAMアクセスキー
- SSH鍵
- データベースユーザー/パスワード
- OAuthトークン
- APIキー
- その他連携サービスの認証情報
環境変数の利用も基本はNGとし、リスクベースで例外判断します。
シークレットの格納先はAWS Secrets Managerを基本とし、AWS Systems Manager Parameter Storeのみでの格納する場合はローテーションが不要かなど確認します。
データベースや自分たちで管理できるAPIキーなどステークホルダーに依存しにくい・ローテーションしやすいものはローテーションすることを原則とします。外部依存が強かったりAPIによる更新が難しいシークレットなどはローテーションしなくてもよしとします。
コードにシークレットが保存されていないことを担保する仕組みが出来ていると尚良しです。
2.9.1 インシデント対応プレイブック
検討内容
Amazon GuardDutyの検知をトリガーとしてどのようにそのトリアージ・調査・対応を行うか想定して訓練します。
クラスメソッドメンバーズでは「インシデント自動調査」機能を利用すると、トリアージ・調査が自動化され、受け取った調査結果を元に最終判断をして対応するだけになるためおすすめ。
AWSインフラのセキュリティインシデントの他に、対象ワークロードの可用性の問題など、他の領域のインシデントに対する対応手順や訓練も検討できるとなお良いです。
完了条件
Amazon GuardDutyによる検知を受け取った際の通知が受け取れるようになっていて、これをどのように対応するか担当者やフローが決まっていて、実際にGuardDutyのFindingsを発生させて対応できればOKです。
2.10.1 マルチ AZ による可用性向上
検討内容
アプリケーションの可用性を確保する場合、Multi-AZでの構成を意識する必要があります。
VPCサービスの場合にはその要件に合わせて、SPOFを作り込んでいないかやフェイルオーバーが許容できる時間やサービス停止で実現できるのかを確認します。
完了条件
サービスの可用性要件が定義され、それを実現するための構成がされていればOKです。
復旧の訓練ができているとなお良いです。
ここまでPhase 1,2の解説でした。以下はいくつかPhase 3,4から抜粋して解説します。
3.5.1 セキュリティチャンピオンの配置
検討内容
セキュリティの課題は組織の様々な場所に存在し、各アプリケーションにはそのビジネスコンテキストを把握したセキュリティ対策が必要になります。そのため、情報システム部門など組織の中央でセキュリティをコントロールすることも重要ですが、各開発チームの中にも開発者としてセキュリティをリードするメンバーが必要です。このメンバーは組織の中央や組織内のセキュリティコミュニティと連携しながら、自身の開発チームでビジネスコンテキストを理解し、開発のアジリティを確保しながらセキュリティも担保する役割が期待されます。
AWSをはじめとした多くの企業ではこのような役割をセキュリティチャンピオンと呼ばれており、実際にAWS社内でもセキュリティチャンピオン育成の取り組みが行われています。
また、近年では株式会社メルカリやサイボウズ株式会社など日本国内の事業会社でも同様の取り組みを実施している企業が増えています。
この取り組みを実現するためには、組織全体の構造的な仕組みづくりに対する経営層のコミットと、育成が必要です。
この取り組みの始め方の1つのアプローチとしては、まずAWSセキュリティの機能に絞って、CCoE組織が各開発チームのAWSセキュリティ人材を支援・育成することでAWSセキュリティチャンピオンとするところから始める方法が考えられます。これにより権限を各チームに委任していくことができます。
下記が参考になります。
完了条件
組織の中でセキュリティチャンピオンの取り組みが回っていればOKです。
3.5.2 DevSecOps とパイプライン
検討内容
アプリケーションにおける脆弱性の混入は開発プロセスでツールを活用し自動化してある程度防ぐことができます。
アプリケーションコードの静的診断(SAST)やアプリケーションを動かして攻撃をシミュレートする動的診断(DAST)、OSSライブラリや3rd Partyコンポーネントの既知の脆弱性を検出するソフトウェア構成解析(SCA)のツールを活用すると良いです。
これらを開発プロセスに導入して自動化することで安全な開発が実現できます。
オープンソース（OSS）のツールを活用してもいいですし、Snykなどサードパーティソリューションを活用することも推奨します。クラスメソッドではSnykの導入支援が可能です。
OSSとしてはAWSが公開するAutomated Security Helper（ASH）や、アプリケーションスキャンツールとしてBurp Suiteなどがあります。
また、参考リンク「Security for Developers」を活用することで、SAST、DAST、SCAなどのセキュリティ機能をパイプラインの中で動作させることが可能になります。
OSSを利用したり、Snykなどのサードパーティを活用してこれを実現しましょう。
完了条件
アプリケーションのデプロイパイプラインに以下のような仕組みが組み込まれていて、運用できていればOKです。
- アプリケーションの脆弱性やシークレット/認証情報をスキャンする
- 重大な脆弱性が見つかった場合、デプロイを停止する
3.9.3 セキュリティ調査と原因分析
検討内容
Amazon Detectiveを有効化し、Amazon GuardDutyで検知されたインシデントの調査ができる体制を作ります。
完了条件
セキュアアカウント 初期設定 or 設定維持か、インシデント自動調査機能によりこの項目の有効化は自動的にOKとなります。
インシデント自動調査機能では調査結果をそのまま受け取ることができるようになりOKです。
その他の場合はAmazon Detectiveを実際に活用して分析できる体制を作ればOKです。
3.10.1 ディザスタリカバリプラン
検討内容
グローバルでのサービス展開や大規模災害時においてもビジネスを継続するため、マルチリージョンでのBCDR（事業継続・災害復旧）戦略が重要です。
重要なアプリケーションとデータを別リージョンに継続的に複製し、障害時に自動フェイルオーバーできる仕組みを構築します。
これにより、リージョン障害だけでなく、ランサムウェアやデータ破壊といった特定時点への復旧も可能になります。
AWS Elastic Disaster Recovery（AWS DRS）やAWS Resilience Hubを活用することで、RTO・RPOの短縮と運用負担の軽減を実現できます。
必ず実際にフェイルオーバーテストを実施し、復旧手順を検証することが不可欠です。
完了条件
重要なアプリケーションについて、以下が実装・運用できていればOKです。
- 事業部門とSLAを協議し、マルチリージョンDRの必要性を合意している
- 別リージョンへのデータ・構成の継続的な複製の自動化ができている
- セカンダリリージョンでの復旧プロセスが自動化できている
- 定期的にリージョン切り替えテスト（演習）を実施している
4.3.3 一時的な昇格アクセスの管理
検討内容
トラブルシューティングなどの一時的な作業に対して永続的なアクセス権を付与せず、必要な時だけ昇格アクセスを許可する仕組みを構築します。
例えば承認ワークフローを通じて一時的な権限を付与する仕組みや、CloudTrailで昇格セッションのアクティビティを監視し必要に応じてセッションを取り消せる体制などです。
既存の昇格アクセス管理の仕組みがなく、新規に構築する場合には参考リンクの「Temporary Elevated Access Management (TEAM)」ソリューションの活用がおすすめです。AWSが提供するこのソリューションは一時的なアクセスの許可、監視、取り消しを統合的に管理できます。
サードパーティPAMソリューションを使用している場合は、IAM Identity Centerとの統合や一時的な認証情報の使用を確認しましょう。アクセスキーなどの永続的な認証情報を使用していないことが重要です。
完了条件
一時的な昇格アクセスが適切に管理され、永続的な高権限付与が最小化できていればOKです。
また、定常的にアクセスログを確認し、不正な昇格アクセスや永続権限の残存を監視できるようになっているとより良いです。
4.7.1 生成 AI データの保護
検討内容
生成AIアプリケーションでは、プロンプトインジェクション攻撃による機密情報の漏洩や、基盤モデルプロバイダーによる学習データの意図しない利用といったリスクが存在します。利用規約のみでは十分な保証にならないため、技術的な保護措置の実装が必要です。
具体的には、転送中・保存時のデータ暗号化の実装やVPCエンドポイントを使用したプライベートアクセスの構成などです。また、プロンプトと応答を分析して望ましくないコンテンツを制御する仕組みも重要です。
生成AIサービスを新規に利用する場合には、Amazon Bedrockの活用がおすすめです。
Amazon Bedrockでは以下のようなセキュリティ機能を提供します。
[データ保護]
・モデルプロバイダーが顧客のデータやプロンプトから学習することを防止
・転送中・保存時のデータ暗号化を標準実装
[プライベートアクセス]
・VPCエンドポイントを使用したインターネットを経由しないアクセス
・オンプレミス環境からはAmazon DirectConnect経由での接続が可能
[コンテンツ制御]
・Amazon Bedrock Guardrailsによるプロンプトと応答の自動分析
・望ましくないリクエストや出力の自動制御
完了条件
生成AIアプリケーションのデータ保護とコンテンツ制御が適切に実装され、運用できていればOKです。
特に以下の項目が整備されていることを確認します。
・転送中・保存時のデータ暗号化が実装されている
・VPCエンドポイントなどによるプライベートアクセスが構成されている
・プロンプトと応答を分析する仕組み（Amazon Bedrock Guardrailsなど）が導入されている
・モデルプロバイダーが顧客データから学習できない環境が確保されている
また、運用面では定常的にプロンプトインジェクション攻撃のログを分析し、保護措置の有効性を評価できるようにするといいでしょう。
4.9.2 高度なセキュリティ自動化
検討内容
AWS Security Hub CSPMの自動修復に始まり、様々なセキュリティオペレーションは自動化していくことが可能です。
インシデントが発生した際の初動の通知、トリアージや調査、隔離や封じ込めのアクションなど、自動で実現できれば非常に心強いです。
プレイブックはこれらが手順化されたものや、更にそれが自動化されたものです。例えば重大なインシデントが発生した際に自動的にSlackチャンネルが作成され、関係者が収集され、やるべきことのチェックリストと手順の一覧が投下され対応を始める、などが想定されます。
より広範囲を自動化し、人はクリエイティブな仕事に専念しましょう。
完了条件
インシデント対応における以下のような自動化の仕組みが実装されていて、運用できていればOKです。
- 必須の自動化:
- 侵害されたコンピューティングリソース（EC2インスタンスなど）のフォレンジック情報を自動収集する
- 侵害されたリソースを自動的に隔離する
- 運用要件:
- 自動化を定期的にテストしている
- 承認プロセス（該当する場合）:
- 人間の承認が必要な場合: 複数の承認者、SLA、エスカレーションルールがある
- 人間の承認が不要な場合: ビジネスへの影響を評価済みで、隔離による影響 < 侵害による被害 となっている
Phaseやカテゴリの変更を検討する推奨事項
私の推奨として、下記の変更を検討するとより現実的な分類になると思います。
- 3.9.3 セキュリティ調査と原因分析(Amazon Detective)はPhase 2へ
- 2.5.2 アプリケーションの脆弱性管理はPhase 3へ
- 3.6.3 アウトバウンド通信の制御はPhase 4へ
追加の検討事項
私の推奨として、下記を追加項目として含めるとより良くなると思います。
- 1.7.2 データセキュリティポスチャの分析では最低限機密データの扱いを検討するが、Phase 2として組織/プロジェクトにおけるデータ分類を行っていくことも追加してもいいかも
- 2.5.1 インフラの脆弱性管理の内、Amazon Inspectorは有効化するだけで様々な脆弱性のチェックができるのでPhase 1に追加してもいいかも
- コンテナセキュリティは特殊な対応が必要になる項目のため「インフラ保護」のPhase3とかに追加してもいいかも
まとめ
AWSセキュリティ成熟度モデルを紹介して、実際にどうやって使っていくかの勘所を解説しました。
AWSのセキュリティ対策はたくさんの観点を検討して取り組んでいく必要がありますが、AWSセキュリティ成熟度モデルを活用するとその優先順位を整理し、順序立てて段階的に強化していくことができます。
ぜひ使ってみてください。
