Amazon Inspectorによる脆弱性管理のシナリオ判断
検査対象外、修正版の未配備、通知と修復の取り違えなどの事例から、Inspectorを使う脆弱性管理を練習します。検査の成功条件と更新の実施結果を対応付けます。
この単元で学ぶこと
- 脆弱性管理の事例で検査と修復を判断する
- 対象範囲・個別状態・方式の条件を確認する
- スコアと所見数を過大に解釈せず優先度を決める
本文解説
1. 古いパッケージを探す 複数EC2にどの既知脆弱性があるか調べたい場合、Inspectorの検査が適します。悪意ある通信の兆候を見つける目的とは異なります。検査では対象資源に必要な情報が取得できているかを確認し、所見がある資源と未検査の資源を区別します。
2. 未検査の原因を調べる エージェント方式を使うEC2ならSSMによる管理や権限を確認します。エージェントレス方式ならOSやEBS等の対応条件を確認します。方式ごとの前提があるため、「Agentがないから検査できない」「Agentがあるから必ず検査済み」の両方を避けます。
3. 更新の公開と適用 修正版が公表されても対象が古いままなら脆弱性は残り得ます。変更の影響を確認して適用し、実際の版と再評価を確認します。管理チケットの作成や承認、担当者の割当ては準備であって、更新そのものではありません。
4. イメージの入れ替え コンテナでは新しいイメージをECRへ保存しても、実行中の処理が旧イメージを使い続ける場合があります。対象のダイジェスト等を確認して修正版を配備します。同じタグ名で運用している場合も、名称の一致だけを実体の一致の証拠にしません。
5. 関数も利用者の更新を確認 Lambdaで対応する検査が脆弱性を示した場合、対象のコードや依存関係を修正して配備する作業が必要です。サーバー管理をAWSが担うことを、自作コードの欠陥まで自動修正されることと混同しません。検査対象と配備済みの版を対応させます。
6. 件数の減少を読み解く 所見を抑制して100件から60件へ表示が減っても、40件を修復した証拠にはなりません。資源削除や対象範囲の変更でも件数は変わります。何を変更した結果なのかを記録し、実際の修正と再評価が一致するか確認します。
7. 露出と重要度 同じ脆弱性でもインターネットから到達できる資源と隔離された資源では評価が異なり得ます。また業務の重要度も優先判断に影響します。ただし外部経路を閉じただけでソフトウェアの欠陥そのものが消えたとは考えず、必要な修正計画を続けます。
8. 報告の範囲をそろえる 対象20資源のうち18が検査済み、2が未検査ならカバレッジは90%です。所見ゼロでも残り2を安全判定へ含めません。検査範囲、更新の実施、再評価の結果をそろえて報告し、必要なら他の所見と集約して判断します。この数量は練習用の仮例です。
図解
重要ポイント
- 方式ごとの前提と実際の検査状態を確認する。
- 修正版の公開・保存・配備を区別する。
- 件数変化の理由を説明して修復を報告する。
間違えやすい点
- 同じタグ名なら稼働イメージも新しいと思う。
- ネットワーク露出の低下を欠陥の除去と同一視する。
用語解説
- パッケージ情報
- インストールされているソフトウェアの名前や版等の情報。
- イメージダイジェスト
- コンテナイメージの内容を識別するために使う値。
- 修復の再確認
- 実際の更新・設定変更後に、対象状態と検査結果を確かめること。
関連教材
参考資料
教材データに登録された参考リンクです。リンク先の内容や更新日は提供元でご確認ください。
確認問題の出題・採点や学習履歴の保存にはログインが必要です。