Amazon SCS-C02: 脆弱性、パッチ、ホストセキュリティ — 学習ガイド
こちらの一部です： AWS Security Specialty SCS-C02 — 学習ガイド. 検証済みの解答で練習： Amazon試験ハブ, または時間制限付き模擬試験に挑戦： ExamRoll.io.
Amazon Inspector: EC2、Lambda、ECRにわたる拡張スキャン
Amazon Inspectorは、継続的でエージェントをサポートする脆弱性管理サービスであり、EC2インスタンス、ECRに保存されたコンテナイメージ、およびLambda関数（アプリケーションコードと依存関係レイヤーの両方）のCVEを検出します。アカウントレベルでInspectorを有効にすると、対象となるリソースが自動的に登録され（リソースごとのオプトインワークフローはありません）、検出結果は標準化されたASFF形式で自動的にAWS Security Hubにプッシュされます。これは、一元的なセキュリティ体制のダッシュボードが必要な場合に正しい統合パターンです。
EC2の場合、Inspectorはハイブリッドスキャンモデルを使用します。SSMエージェント（AWS提供のアソシエーションを使用）が、エージェントレス形式のネットワーク到達可能性評価とパッケージ評価に使用されるソフトウェアインベントリを収集する一方、詳細なホスト評価にはエージェントが実行中であり、インスタンスがSSM経由で到達可能である必要があります。これが「エージェントレスのみ」のアプローチが落とし穴である理由です。SSMエージェントのパス（または必要に応じてInspectorのエージェントベースの詳細な検査）がなければ、ネットワークの露出やマニフェストから派生したCVEといった表層的な検出結果しか得られず、ランタイムライブラリのインベントリ、管理外のパッケージ、および設定を見逃してしまいます。ほとんどの本番環境が必要とするのはハイブリッドモードです。
Lambdaの場合、Inspectorは2種類のスキャンを実行します。標準スキャン（レイヤーと関数の依存関係におけるパッケージの脆弱性）とコードスキャン（インジェクションの欠陥、ハードコードされたシークレット、安全でないAPIについて関数コードを静的分析）です。重要な対象条件として、スキャンされるためにはLambda関数が過去90日以内に少なくとも1回呼び出されている必要があります。アイドル状態またはアーカイブされた関数は、Inspectorのスキャン対象から静かに除外されます。「Inspectorを有効にしたから、すべての関数がカバーされている」と思い込んでいるチームは、監査人からめったに実行されない関数の証拠を求められたときに痛い目を見ます。対処法は、スケジュール（EventBridge）で関数を呼び出すか、除外を受け入れてそれを文書化することです。
ECRの場合、拡張スキャン（Inspectorを利用）が、Clairをベースとした古い基本スキャンを置き換えます。拡張スキャンは、プッシュ時のスキャンと、すでにレジストリにあるイメージの継続的スキャンの両方をサポートしているため、以前にプッシュされたイメージに対して新たに公開されたCVEは、再プッシュすることなく新しい検出結果を生成します。レジストリレベルで拡張スキャンを有効にし、リポジトリごとのフィルター（例: prod/* は継続的スキャン、sandbox/* はプッシュ時のスキャンのみ）を設定してコストを管理します。
委任管理者と抑制ルール
複数のアカウントを持つAWS Organizationsのセットアップでは、管理アカウントからInspectorの委任管理者アカウントを指定します。委任管理者は、メンバーアカウント全体の集約された検出結果を閲覧し、組織全体のスキャン設定を管理します。これにより、検出結果を取得するためのクロスアカウントIAMロールを付与する必要がなくなり、アカウントごとに個別にInspectorを有効にするというアンチパターンを防ぐことができます。
抑制ルールを使用すると、セキュリティチームは検出結果を削除することなくノイズをフィルタリングできます。ルールは、リソースタグ、重大度、CVE ID、ECRリポジトリなどの属性に基づいて一致します。開発/テスト用Lambdaの検出結果を本番ダッシュボードに表示しないようにするには、タグ Environment=dev をキーとする抑制ルールを適用します。検出結果は監査のために基盤となるデータストアに存在し続けますが、デフォルトのビューや、設定されていればSecurity Hubからも除外されます。これを実現するために開発アカウントでInspectorを無効にしてはいけません。脆弱なアーティファクトが開発環境から本番環境へ昇格するのを検知する能力を失ってしまいます。
イメージ昇格のためのCI/CDゲーティング
ECRの拡張スキャンは、（単なるタグではなく）イメージダイジェストに紐付いた検出結果を生成します。パイプラインがクエリすべきなのはこのダイジェストです。標準的なパターンは次のとおりです: イメージをビルド → ECRにプッシュ（プッシュ時にスキャンをトリガー）→ スキャンの完了をポーリングまたは待機 → 重大度「高」または「クリティカル」の検出結果が存在すればビルドを失敗させる → そうでなければECS/EKSのタスク/デプロイメントを更新。
buildspec.yml 内の最小限のCodeBuildステップ:
post_build:
commands:
DIGEST=$(aws ecr describe-images --repository-name $REPO \
--image-ids imageTag=$TAG --query 'imageDetails[0].imageDigest' -o text)
aws inspector2 list-findings \
--filter-criteria "{\"ecrImageHash\":[{\"comparison\":\"EQUALS\",\"value\":\"$DIGEST\"}],\"severity\":[{\"comparison\":\"EQUALS\",\"value\":\"HIGH\"},{\"comparison\":\"EQUALS\",\"value\":\"CRITICAL\"}]}" \
--query 'findings[].findingArn' --output text > findings.txt
- if [ -s findings.txt ]; then echo "Blocking - CVEs found"; exit 1; fi
この段階でゲーティングを怠ること、つまり「Inspectorがアラートをくれるだろう」と信頼することは、典型的な間違いです。アラートは非同期に、そして脆弱なイメージがすでに実行された後に届きます。ゲートは昇格と同期している必要があります。同様に、ダイジェストではなくタグのみでゲーティングを行うのは安全ではありません。なぜならタグは可変であり、同じタグで2回プッシュするとスキャン結果が混同されてしまうからです。
Patch Manager、ベースライン、パッチグループ
SSM Patch Managerは、3つの基本要素で動作します。
パッチベースライン: 自動承認ルール、承認済みパッチ、拒否されたパッチ、および重大度/分類ごとのコンプライアンスレベルを定義します。
パッチグループ: キーが正確に
Patch Groupであるタグで、その値によってインスタンスが特定のベースラインに登録されます。メンテナンスウィンドウ:
AWS-RunPatchBaselineがスキャンまたはインストールタスクを実行するスケジュール。
開発環境ではすべてのセキュリティパッチを即座に自動承認し、本番環境ではカーネルパッケージを拒否しつつ、7日間の据え置き期間の後に「クリティカル」および「重要」なパッチのみを自動承認する必要がある環境では、2つのベースラインを作成します。開発環境のベースラインでは、すべてのセキュリティ分類を対象とする ApproveAfterDays: 0 の承認ルールを使用します。本番環境のベースラインでは、ApproveAfterDays: 7、ComplianceLevel: CRITICAL を使用し、Classification=Security と Severity in [Critical, Important] でフィルタリングし、BlockAllPatchesFromRejectedList を使って拒否されたパッチリストに kernel* を追加します。インスタンスには Patch Group=Dev または Patch Group=Prod のタグが付けられ、各パッチグループは対応するベースラインに登録されます。コンプライアンスはパッチコンプライアンスレポート経由で集計され、中央監査のためにS3にエクスポートできます。
「ロジックを持つ」単一のベースラインでは、開発環境と本番環境の違いを表現することはできません。ベースラインは登録されたグループごとに静的です。異なるメンテナンスウィンドウを使用してこの動作を模倣しようとしないでください。ウィンドウが制御するのはパッチ適用のタイミングであり、どのパッチが承認されるかではありません。
リアルタイム通知パイプライン
SlackやMicrosoft Teamsで新しい検出結果についてアラートを出す場合、運用上効率的な一連の流れは次のようになります。
Inspectorが
aws.inspector2イベントソースでEventBridgeに検出結果を発行します。EventBridgeルールが重要度（例：
HIGH、CRITICAL）でフィルタリングし、SNSトピックをターゲットとします。SNSトピックには、SlackチャネルまたはTeamsワークスペースにマッピングされたAWS Chatbotのサブスクリプションがあります。
ChatbotはSNSに直接サブスクライブします。ChatbotはInspectorの検出結果をネイティブにレンダリングするため、メッセージを再フォーマットするために間にLambdaを挟まないでください。EventBridgeパターンの例は次のとおりです。
{
"source": ["aws.inspector2"],
"detail-type": ["Inspector2 Finding"],
"detail": { "severity": ["HIGH", "CRITICAL"] }
}
ここで避けるべき2つの落とし穴があります。Security Hub経由でルーティングすると、レイテンシーが追加され、カスタムインサイトの設定が誤っていると重要度の粒度が失われる可能性があります。また、SESやカスタムのWebhook Lambdaを使用すると、Chatbotがすでにネイティブで提供している機能を追加することなく、運用上のオーバーヘッドが増加します。
実践的な問題：ユースケースシナリオ
シナリオ： Meridian Financialは、顧客向けのウェブサービス、バッチ分析、サーバーレスイベントプロセッサをサポートするマルチアカウントのAWS Organizationを運営しています。彼らのCI/CDパイプラインはコンテナイメージをAmazon ECRにプッシュし、レガシーワークロードのためにEC2フリートをホストし、新しいサービスにはLambdaを使用しています。セキュリティアカウントの中央セキュリティチームが、アカウント全体の脆弱性の可視性とパッチ適用を管理する必要があります。
課題： CI/CDでスキャンが強制されていなかったため、重大度の高いライブラリを含むイメージが本番環境にプロモートされてしまいました。また、EC2インスタンスのパッチ適用が環境によって一貫しておらず、脆弱性が存在する期間が生まれ、ノイズの多い検出結果がチームを圧倒しています。
推奨アプローチ：
- AWS Organizationsで委任管理者を設定し、セキュリティアカウントからEC2、Lambda、ECRにわたってAmazon Inspector拡張スキャンを有効にします。これにより、スキャン、検出結果、抑制ルールを中央で管理できるようになります。
- プッシュ時のECRイメージスキャンを設定し、スキャンゲートをCodePipeline/CodeBuildに統合します。Inspector/ECRのスキャン結果が重要度のしきい値を満たすまでイメージのプロモーションをブロックし、ビルドステップを通じて検出結果を表面化させます。
- AWS Systems Manager Patch Managerを実装し、環境ごとに定義されたパッチベースラインとパッチグループを設定します。非本番環境から先に展開するためのメンテナンスウィンドウをスケジュールし、SSM Automationドキュメントを使用して重要なCVE修正の承認を自動化します。
- Amazon EventBridgeを使用してリアルタイム通知パイプラインを作成し、Inspectorの検出結果とSSMのコンプライアンスイベントをキャプチャします。それらをAmazon SNSと、情報を付加し、重複排除を行い、優先順位付けされたアラートをSlackに投稿して追跡チケットを作成する軽量なAWS Lambdaにルーティングします。
- 封じ込めと修復を自動化します。EventBridgeによってトリガーされるSSM AutomationまたはLambdaのランブックを使用して、影響を受けるEC2/Lambdaのバージョンを隔離したり、イメージの再ビルドをトリガーしたりします。また、委任管理者アカウントを介して追跡された誤検知に対してのみInspectorの抑制ルールを適用し、ノイズを削減します。
論理的根拠： Inspectorの一元管理、CI/CDでのゲート設定、Patch Managerのベースライン、そしてEventBridge駆動のパイプラインは、自動化された予防、一貫したパッチ適用、優先順位付けされた監査可能な対応を強制し、同時にアラート疲れを軽減するというAWSのベストプラクティスに従っています。
Amazon Inspectorによる脆弱性の発見
Amazon Inspectorは、AWSにおける主要なマネージド脆弱性評価サービスであり、ホストセキュリティに関連する3つの対象領域で動作します。EC2インスタンス、Amazon ECR内のコンテナイメージ、そしてLambda関数です。アカウントまたはOrganizationsレベル（Inspectorコンソールで委任管理者を介して）で有効にすると、スケジュールされたポイントインタイムのスキャンではなく、継続的な、エージェントレスまたはSSMベースのスキャンを実行します。CVEフィードは毎日変更されるため、この継続的な態勢は重要です。先週のスナップショットはすでに古い可能性があります。
EC2の場合、InspectorはSSM Agentに依存して、インストールされているパッケージとカーネルのバージョンを列挙し、それらをベンダーのアドバイザリやNational Vulnerability Databaseと照合します。検出結果には、CVE識別子、CVSSスコア、影響を受けるパッケージ、修正済みバージョン、およびネットワーク到達可能性のコンテキスト（ネットワーク到達可能性ルールは、ENI、セキュリティグループ、NACL、ルートテーブルを介してインターネットに公開されているポートを識別します）が含まれます。スキャンはSSMに依存するため、インスタンスプロファイルにAmazonSSMManagedInstanceCoreマネージドポリシーがないEC2インスタンスは、Inspectorの結果に表示されません。これは覚えておくべきサイレントな障害です。
ECRの場合、Inspectorは2つのスキャンモードをサポートしています。
基本スキャン： 無料で、オープンソースのClairエンジンを使用し、プッシュ時またはオンデマンドでのみ実行されます。
拡張スキャン： Inspectorを利用し、プッシュイベントからかなり時間が経過した後でも、新しいCVEが公開されるたびにイメージ（OSパッケージとPython、Node、Javaなどのアプリケーション言語パッケージの両方）を継続的に再スキャンします。
よくある落とし穴は、ECRのプッシュ時スキャンを十分なホストセキュリティ対策として扱うことです。そうではありません。プッシュ時スキャンはビルド時にイメージを検証しますが、実行中のコンテナはイメージに加えてあらゆるドリフトを継承し、基盤となるEC2またはFargateホストには、独立してパッチを適用する必要がある独自のカーネルとOSパッケージがあります。拡張スキャンとEC2ホストスキャンを組み合わせることで、そのギャップを埋めることができます。すべてのInspectorの検出結果はAWS Security Hubにルーティングされるべきです。Security HubはそれらをASFF形式に正規化し、クロスアカウントでの集約、重複排除、およびEventBridgeを介した下流の自動化を可能にします。
Patch Managerとフリート全体での修復
AWS Systems Manager Patch Managerは、Inspectorが発見したものを実際に修復することで、Inspectorを補完します。Inspectorが「どのCVEが私に影響を与えているか？」に答えるのに対し、Patch Managerは「どのパッチが不足しており、どうすれば安全にインストールできるか？」に答えます。
Patch Managerはパッチベースラインを通じて動作します。これは、分類（セキュリティ、クリティカル、バグ修正）、重要度、および自動承認の遅延（例えば、ベンダーの安定性を考慮して、セキュリティパッチをリリースから7日後に承認するなど）に基づいて、どのパッチを承認するかを定義する宣言的なルールです。AWSはOSごとにデフォルトのベースライン（AWS-AmazonLinux2DefaultPatchBaseline、AWS-WindowsPredefinedPatchBaselineなど）を提供しますが、本番環境のフリートでは通常、インスタンスのPatch Groupタグを介してパッチグループに紐付けられたカスタムベースラインを使用します。
典型的なスキャンとパッチ適用のワークフローでは、2つのオペレーションが使用されます。
スキャン: 何もインストールせずにコンプライアンスを報告します。結果はPatch ManagerのコンプライアンスダッシュボードとConfigに表示されます。
インストール: 承認されたパッチを適用し、多くのOSでは再起動します。
これらのオペレーションは通常、AWS-RunPatchBaselineドキュメントをターゲットとするメンテナンスウィンドウを通じてスケジュールされます。緊急のゼロデイシナリオの場合、Patch ManagerはメンテナンスウィンドウのスケジュールをバイパスするオンデマンドアクションであるPatch Nowを提供します。推奨されるパターンは、脆弱性を修正する特定のKBまたはパッケージのみを承認する限定的なパッチベースラインを作成し、影響を受けるパッチグループをターゲットにし、Patch Nowを実行し、実行出力を中央のS3バケットとCloudWatch Logsのロググループにストリーミングすることです。その一元化されたログが、監査人やインシデントレスポンスのための修復の証明、つまり監査アーティファクトになります。
実践的な問題：ユースケースシナリオ
シナリオ: Meridian Financialは、数百台のEC2インスタンス（WindowsおよびAmazon Linux）と、顧客向けサービスをサポートする小規模なEKSクラスターを持つ、マルチアカウントのAWS環境を運用しています。同社はAWS Organizations、運用ツールとしてAWS Systems Managerを使用し、共有イメージアカウントでAMIを管理していますが、一貫した自動脆弱性スキャンや、アカウントを横断した協調的なパッチのロールアウトは行われていません。
課題: OpenSSLに影響を与える公開CVEが公開され、Amazon Inspectorが複数のインスタンスにわたって重大度の高い検出結果を報告しましたが、パッチ適用は不均一で、修復の遅れが原因で1つの本番サービスが短時間の不正利用の試みを経験しました。
推奨アプローチ:
- すべてのアカウントとリージョンでAmazon Inspectorを有効にして、イメージと実行中のインスタンスの両方の脆弱性スキャンを実行し、重大度の高い検出結果をAWS Security HubとEventBridgeのカスタムイベントバスに転送します。
- AWS Systems Manager Inventoryを使用して影響を受けるインスタンスを特定し、重要度に応じてタグ付けします。必要なOpenSSLの修正を含むPatch Managerベースラインを作成し、Windows/Linuxのルールをターゲットにします。
- Inspectorの検出結果が定義された重大度に達したときにSSM AutomationドキュメントをトリガーするEventBridgeルールを作成し、インスタンスIDのリストをAutomationランブックに渡します。このランブックはPatch ManagerまたはRun Commandを呼び出してパッチを適用し、必要に応じて再起動します。
- ステートフルまたはリスクの高いサービスについては、EC2 Image Builderを使用してパッチ適用済みのAMIをベイクし、管理されたブルー/グリーンまたはローリングデプロイメントでAuto ScalingグループまたはEKSノードグループを更新し、Route 53/ALBのヘルスチェックでサービスの正常性を検証することで、ローリングアップデートをオーケストレーションします。
- 修復後、Amazon Inspectorを再実行して検出結果が解決されたことを検証し、SSM Complianceのレポートを更新して、SNSを通じてセキュリティチームに概要を送信します。フリート全体で繰り返し対応できるように、AutomationランブックをSystems Manager Automationライブラリに保持します。
理論的根拠: このアプローチは、継続的な発見のためにAmazon Inspectorを、制御された自動修復のためにSystems Manager Patch ManagerとAutomationを、イミュータブルインフラストラクチャのためにイメージベースの再構築を使用し、検出、自動応答、および爆発半径の最小化に関するAWSのベストプラクティスに沿っています。
# Example: focused baseline for an urgent CVE
Name: emergency-openssl-cve
OperatingSystem: AMAZON_LINUX_2
ApprovalRules:
PatchRules:
- PatchFilterGroup:
PatchFilters:
- Key: PRODUCT
Values: [AmazonLinux2]
- Key: CVE_ID
Values: [CVE-2024-XXXXX]
ApproveAfterDays: 0
ComplianceLevel: CRITICAL
Systems Manager Explorerで委任管理者アカウントを設定し、リソースデータ同期を有効にすることで、一元的なコンプライアンスが可能になります。これにより、すべてのアカウントからのパッチコンプライアンスの状態が単一のS3バケットに集約され、Athenaでクエリしたり、QuickSightで可視化したりできます。
監査可能な管理のためのSession Manager
従来のSSHベースのアクセスには3つの構造的な弱点があります。長期間有効なキーマテリアルがオペレーターのラップトップに存在すること、ポート22が（たとえ踏み台サーバー経由であっても）到達可能である必要があること、そしてシェルアクティビティが追加のツールなしでは一元的に記録されないことです。Session Managerはこれら3つすべてを排除します。
Session Managerは、SSM AgentからSSMエンドポイントへのアウトバウンドHTTPS接続を介して、インタラクティブなシェルをトンネリングします。インバウンドポートも、SSHキーペアも、踏み台サーバーもありません。アクセスはIAMポリシー（インスタンスタグまたはARNでスコープが限定されたssm:StartSession）によって認可され、すべてのセッションはCloudWatch LogsまたはS3に記録でき、オプションでKMS暗号化も利用できます。Linuxでは、セッションはデフォルトでssm-userとして実行されます。sudoの動作はIAMではなく、インスタンスのsudoers設定によって制御されます。
新しいフリートに対する正しい強化パターンは、EC2キーペアを使用せずにインスタンスを起動し、AmazonSSMManagedInstanceCoreを持つインスタンスプロファイルをアタッチし、インスタンスをssm、ssmmessages、およびec2messages用のVPCエンドポイントがあるプライベートサブネットに配置し、Session Managerのプリファレンスレベルでセッションロギングを強制することです。Session Managerと並行してSSHキーを配布し続けることは罠です。それは、Session Managerが排除するために採用されたまさにその攻撃対象領域を維持し、ログに記録されないアクセスチャネルを残すことになります。AMIのベイクプロセスからauthorized_keysのプロビジョニングを削除してください。
CloudWatchエージェントによるホストテレメトリー
統合CloudWatchエージェントは、EC2ハイパーバイザーからは見えないOSレベルのメトリクス（メモリ、ディスク、プロセスごとのCPU）とログファイルを収集します。設定は、通常Parameter Storeに保存されるJSONファイルで行い、amazon-cloudwatch-agent-ctl -a fetch-config -m ec2 -s -c ssm:AmazonCloudWatch-linux を使って適用します。
エージェントに関する最も一般的な運用上の障害は、インスタンスプロファイルでのIAM権限の不足です。エージェントには、最低限以下の権限が必要です。
logs:CreateLogGroup （グループが事前に作成されていない場合）
logs:CreateLogStream
logs:PutLogEvents
logs:DescribeLogStreams
cloudwatch:PutMetricData （カスタムメトリクス用）
ssm:GetParameter （Parameter Storeから設定を取得するため）
マネージドポリシーのCloudWatchAgentServerPolicyは、これらの権限をまとめて提供します。権限が不足している場合、エージェントは正常に起動し、systemctl statusでは健康に見えますが、ログがCloudWatchに届くことはありません。この障害は/opt/aws/amazon-cloudwatch-agent/logs/amazon-cloudwatch-agent.logでのみ確認できます。ログの一元化を前提とするホストセキュリティ設計では、単にエージェントのステータスだけでなく、ログが実際に転送されていることを検証する必要があります。
まとめ
防御のループは次のようになります。InspectorがホストとコンテナイメージのCVEを検出し、その検出結果は集約のためにSecurity Hubに送られます。Patch Managerは、スケジュールされたメンテナンスウィンドウ、または緊急時には「今すぐパッチ」機能で修正を行います。Session Managerは唯一の管理アクセスパスを提供し、CloudWatchエージェントはパッチ適用の証跡とランタイムログの両方を一元管理アカウントにストリーミングします。各コントロールは互いに他のコントロールを前提としています。Patch ManagerのないInspectorは、誰も対応しないレポートを生成するだけです。一元化されたロギングのないPatch Managerは、監査証跡を残せません。適切なIAMがないSession Managerは、過剰または過小なアクセス権限を与えてしまいます。そして、正しいログ権限のないCloudWatchエージェントは、可視性があるかのような錯覚を生み出します。
← ガバナンス、構成、自動化 · すべてのドメイン · コンテナとサーバーレスセキュリティ →
これらの問題を練習する → · ExamRoll.ioで時間制限付き練習 →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
試験に合格する →