Security要件から最適なControlを選択する

ゴール

複数のセキュリティ要件が同時に与えられたとき、個別サービスを並べるのではなく、必要な結果を制御へ対応付け、不足・重複・迂回・適用漏れを確認して最終構成を選べるようにします。

セキュリティ要件一覧
↓
必要な結果へ分解
↓
予防 / 保護 / 検知 / 評価 / 維持
↓
必要な制御を対応付け
↓
必要範囲へ本当に適用済み？
↓
依存関係・迂回経路
↓
適用範囲の不足
↓
不要な重複
↓
残存リスク
↓
最終構成

1. サービス名ではなく要件一覧から始める

「AWS WAFを使う」「Amazon GuardDutyを有効化する」から始めると、別の要件が抜けやすくなります。まず要件を役割へ分解します。

2. 1つの制御で別の責任を代替しない

Amazon GuardDutyは脅威検知を担いますが、不要な通信をセキュリティグループで許可したままでよい理由にはなりません。AWS WAFもデータ暗号化や認証情報管理を代替しません。

制御Aが存在
↓
制御Bは不要？
↓
いいえ。
それぞれがどのセキュリティ要件を満たすか個別に確認

3. 既習の制御を役割別に制御マップへ配置する

個々のAWSセキュリティサービスの基本機能は既習です。ここでは再説明せず、要件ごとに予防・検知・評価・維持のどこを既存制御が担当しているかを制御マップへ配置します。

セキュリティ要件
        ↓
既存制御へ対応付け
        ↓
担当なし   → 適用漏れ
重複のみ   → 別要件の漏れを確認
迂回可能   → 強制経路を確認

4. 検知制御は残存リスクへ対応付ける

予防制御を設計した後も残る脅威について、既習のAmazon GuardDutyなどの検知制御を配置します。判断の中心はサービス名ではなく、どの残存リスクを、どの範囲で検知する必要があるかです。

予防後に残る脅威
        ↓
必要な検知結果
        ↓
対象アカウント / リージョン / ワークロード
        ↓
検知制御の適用範囲を確認

5. 採用済み検知制御は要件単位で適用範囲を確認する

検知サービスを有効化済みでも、必要な資産・アカウント・リージョン・ワークロードへ機能が届いているとは限りません。制御マップでは「有効 / 無効」だけでなく、要件対象を実際に網羅しているかを確認します。

例えば実行時脅威の検知が要件なら、対象ワークロードに必要なRuntime Monitoringが適用されているかを確認します。

6. Security Hubは制御の適用範囲の中央評価へ接続する

AWS Security Hub / Security Hub CSPMの基本的な役割は既習です。ここでは、各検知元や設定評価を置き換えるのではなく、制御マップの適用漏れ・検出結果・セキュリティ状態を中央で評価する層として配置します。

検知元 / 設定評価
        ↓
Security Hubで中央評価
        ↓
適用漏れ / 優先対応を確認
        ↓
不足している元制御を修正

7. カバレッジ検出結果は適用漏れの証拠として使う

対応している機能についてカバレッジ検出結果を確認し、組織標準で必要な制御が対象範囲へ適用されているかを検証します。カバレッジ対象外の機能まで自動的に確認できるとは考えず、必要なら各サービス側の設定も確認します。

8. 露出の検出結果は対応優先度へ接続する

複数の脆弱性・設定・脅威・リソース関係が同じ資産へ集まる場合、露出の検出結果を使って複合リスクとして評価します。ここでの目的は機能説明ではなく、多数のシグナルからどの適用漏れ / リスクを先に是正するかを決めることです。

9. 制御マップで要件と制御を1対1以上に対応付ける

公開ウェブアプリケーションを例に、各要件へ少なくとも1つの責任ある制御があるかを確認します。

10. 制御間の依存関係と迂回経路を確認する

制御を選んでも、組み合わせ方が悪ければ要件を満たしません。

CloudFront + AWS WAF
↓
オリジンへ直接到達可能？
→ はいなら迂回経路あり

AWS Secrets Manager
↓
アプリケーションの取得権限は適切？
→ なしなら動作しない
→ 広すぎれば最小権限違反

GuardDuty
↓
必要な検知機能は対象範囲で有効？
→ いいえなら適用範囲の不足

11. パッチコンプライアンスと脅威検知を混同しない

全EC2がパッチ標準へ準拠していても、現在進行中の不審なプロセス実行やネットワーク活動を検知できるとは限りません。逆にGuardDuty 検出結果が0でも、パッチや設定がすべて適切とは限りません。

パッチコンプライアンス
→ 既知の更新への準拠

脅威検知
→ 現在の不審な挙動を検知

セキュリティ状態
→ 設定・標準への準拠を評価

別のシグナルとして組み合わせる

12. 制御数ではなく要件の充足で決める

サービスを増やすほど安全になるわけではありません。要件に関係しない制御は、コスト・運用複雑性・誤検知・変更リスクを増やします。一方で「サービス数を最小化する」こと自体も目的ではありません。

最小サービス数 ×
最大サービス数 ×

要件を満たす必要十分な制御 ○

13. 最終判断フロー

セキュリティ要件一覧
        ↓
制御マップを作る
        ↓
予防制御は足りる？
        ↓
データ保護 / 認証情報管理は足りる？
        ↓
攻撃緩和 / パッチ維持は足りる？
        ↓
脅威検知は足りる？
        ↓
セキュリティ状態を評価できる？
        ↓
必要範囲へ実際に適用済み？
        ↓
依存関係 / 迂回経路
        ↓
適用範囲の不足
        ↓
不要な重複
        ↓
残存リスク
        ↓
最終構成

14. 混同ポイント

まとめ

セキュリティ要件
↓
必要な結果へ分解
↓
アイデンティティ / ネットワーク / 暗号化 / 認証情報
攻撃緩和 / パッチ管理
脅威検知 / セキュリティ状態
↓
制御マップ
↓
適用範囲・依存関係・迂回
↓
適用範囲の不足
↓
不要な重複
↓
残存リスク
↓
最適な制御の組み合わせ

個別サービスを覚えるだけでなく、要件に対して不足なく、過剰でもなく、実際に適用可能な制御の組み合わせを選びます。

主要AWS公式資料

• AWS Certified Solutions Architect - Professional（SAP-C02）試験ガイド
• Amazon GuardDuty — 保護プラン / Runtime Monitoring
• AWS Security Hub — カバレッジ検出結果
• AWS Security Hub — 露出の検出結果
• AWS Security Hub CSPM
• Amazon GuardDuty と AWS Security Hub の統合