Instiq
第3章 · 既存ソリューションの継続的な改善·v2.1.0·更新 2026/6/28·読了目安 約11分

変更要約: 軸B網羅: 開発者ツール/運用管理(CI-CD・Grafana/Prometheus・Proton・Amplify/Device Farm)のカタログ節(s4)を追加

3.3信頼性とセキュリティ態勢の改善

この節の要点

既存環境の堅牢化——Well-Architected、障害の分離（フォールト分離）、GuardDuty／Security Hub／Config、WAF／Shield、自動修復——を理解します。脅威検知とコンプライアンスを継続的に高めます。

堅牢化は継続的な営みです。脅威を検知し、構成のコンプライアンスを評価し、逸脱を自動修復します。

3.3.1セキュリティと信頼性の継続改善

セキュリティと信頼性の継続改善を示した図。脅威検知として GuardDuty（不審なアクティビティを機械学習で検知）、構成コンプライアンス評価として AWS Config（ルールに対する準拠状況・逸脱検出）、検出結果の集約として Security Hub（複数サービスのアラートを一元化・スコア化）を並べ、アプリ保護として WAF（L7 の悪意あるリクエストをブロック）と Shield（DDoS 防御）、逸脱時には EventBridge から Lambda/SSM Automation を起動して自動修復し、Well-Architected の柱（信頼性・セキュリティ・コスト・性能・運用・持続可能性）に照らしてレビューする様子を示した図。
セキュリティと信頼性の継続改善
  • GuardDuty：ログを機械学習で分析し、脅威・不審なアクティビティを検知する。
  • Config：リソース構成をルールで評価し、コンプライアンス逸脱を検出・記録する。
  • Security Hub：複数サービスの検出結果を一元集約・スコア化し、態勢を可視化する。
  • WAF/Shield：WAF=L7 の悪意ある HTTP リクエストをブロック、Shield=DDoS 防御。
  • 自動修復：検出→EventBridge→Lambda/SSM Automation で逸脱を自動で是正する。
試験ポイント

「脅威検知＝GuardDuty」「構成コンプライアンス評価/逸脱検出＝AWS Config」「検出結果の一元集約＝Security Hub」「L7 攻撃ブロック＝WAF・DDoS 防御＝Shield」「設計レビューの基準＝Well-Architected」 は SAP-C02 で頻出です。Config ルール違反を EventBridge＋Lambda で自動修復する設計が定番です。

注意

GuardDuty は「検知」、WAF/Shield は「防御」、Config は「コンプライアンス評価」と役割が異なります。混同しないこと。検知だけでは守れないため、自動修復や防御サービスと組み合わせます。

SAP-C02 のセキュリティ設問は「検知・評価・集約・防御・是正」のどの層の話かを見極めるのが鍵です。GuardDuty は VPC フローログ・DNS ログ・CloudTrail を取り込み、機械学習と脅威インテリジェンスで侵害の兆候（C2 通信・異常な API 使用など）を検知します。AWS Config はリソースを構成項目（configuration item）として継続記録し、マネージドルールや Lambda カスタムルールで準拠を評価、逸脱時には修復アクション（SSM Automation ドキュメント）を紐づけられます。Security Hub は GuardDuty・Inspector・Macie・Config などの検出結果を ASFF 形式で集約し、CIS や AWS 基礎セキュリティ標準に対するスコアを出します。組織横断では GuardDuty/Security Hub/Config を委任管理者アカウントで集約し、メンバーアカウントを一元管理するのが定石です。防御層は WAF（マネージドルール/レート制限/地理ブロック）と Shield Advanced（高度な DDoS 緩和と DDoS コスト保護）で、検出から EventBridge→Lambda/SSM Automation へ流して是正を自動化します。最後に Well-Architected（6 つの柱）でレビューし、継続的に改善のループを回します。

役割サービス代表的な用途
脅威検知GuardDuty侵害の兆候を機械学習で検知
構成コンプライアンスAWS Configルール評価＋逸脱の自動修復
検出結果の集約Security Hub横断集約・標準準拠スコア
アプリ防御WAF / ShieldL7 攻撃ブロック・DDoS 緩和
補足

シナリオ：マルチアカウント環境で「S3 バケットが暗号化なし/パブリック公開」を組織全体で禁止し、違反を自動で直したい。→ AWS Config のマネージドルール（s3-bucket-server-side-encryption-enabled 等）を組織全体に配信し、違反検出時に SSM Automation の修復アクションで暗号化を有効化。検出結果は Security Hub に集約し、委任管理者アカウントで横断監視します。

補足

FAQ：GuardDuty と Inspector と Macie の違いは？ GuardDuty は脅威検知（不審な振る舞い）、Inspector は EC2/コンテナ/Lambda の脆弱性スキャン、Macie は S3 内の機密データ（PII 等）検出です。いずれも検出結果は Security Hub に集約できます。

注意

ひっかけ：「DDoS 攻撃からの保護」に WAF "だけ" を選ぶのは不十分なことがあります。L3/L4 の大規模な体積型 DDoS には Shield（Advanced） が主役で、WAF は L7 のリクエストルールを担います。両者は補完関係で、設問の攻撃レイヤを見極めましょう。

3.3.2この節のまとめ

  • 検知＝GuardDuty／評価＝Config／集約＝Security Hub
  • 防御＝WAF（L7）/Shield（DDoS）／是正＝EventBridge→Lambda/SSM

進捗の記録にはログインが必要です。

理解度チェック

（軽い確認用）

Q1. アカウント内の不審な API 利用や侵害の兆候を、ログから機械学習で継続的に検知したい。何を使いますか？

Q2. リソース構成が社内ルール（例: S3 は暗号化必須）に準拠しているか継続評価し、逸脱を検出したい。何を使いますか？

Q3. Web アプリへの SQL インジェクションや不正な L7 HTTP リクエストをブロックしたい。何を使いますか？

理解度を確認第3章「既存ソリューションの継続的な改善」の問題を解く