TL;DR
Security Hub CSPMの Finding を洗い出した後は、すべてを同じ進め方で扱わず、横展開できるもの・顧客と合意が必要なもの・すぐ直せるものに分類すると計画を立てやすくなります。- 3分類は排他的ではありません。1つの Finding が「横展開できる」かつ「顧客との合意が必要」に該当することもあります。
- Severity だけで順番を決めず、変更影響、判断者、作業量、コスト、ロールバック方法まで含めて優先順位を決めることが重要です。
はじめに
前回の記事では、Security Hub CSPM の Finding から、どの Control ID がどのリソースに対して失敗しているかを特定する方法を整理しました。
対象リソースを特定できれば、次はいよいよ是正です。
ただし、一覧に出てきた Finding を上から順番に直していけばよいとは限りません。実際には、同じコントロールでもリソースの用途や構成が異なり、変更による影響も変わります。
そこで私は、切り分けた Finding を次の3つの観点で整理すると進めやすいと考えています。
- 横展開できるもの
- 顧客と合意が必要なもの
- すぐ直せるもの
この記事では、それぞれをどう判断し、実際の是正計画へ落とし込むかを整理します。
まず前提: 3つは排他的な分類ではない
最初に押さえておきたいのは、この3つが完全に別々の箱ではないことです。
たとえば、同じ Control ID が複数の S3 バケットで失敗していれば「横展開できるもの」に該当します。一方で、バケットポリシーの変更によって外部システムとの連携に影響するなら、「顧客と合意が必要なもの」にも該当します。
つまり、この3つは対象を一意に分けるラベルというより、是正方法を決めるための判断軸として使う方が分かりやすいです。
| 判断軸 | 確認したいこと |
|---|---|
| 横展開できるもの | 同じ原因・同じ手順で複数リソースを是正できるか |
| 顧客と合意が必要なもの | 技術担当者だけでは変更可否を判断できないか |
| すぐ直せるもの | 影響が限定的で、手順とロールバックが明確か |
1. 横展開できるもの
横展開できるものとは
横展開できるものは、同じ原因で失敗している複数リソースに対して、共通の調査方法や是正手順を適用できるものです。
代表的には、次のようなケースです。
- 同じ
Control IDが複数リソースでFAILEDになっている - 同じ Terraform module や CloudFormation template から作られている
- 同じ命名規則や用途を持つリソースで設定差分が発生している
- 同じ AWS Organizations 配下の複数アカウントで同じ設定不備がある
判断するときに見る項目
横展開の可否を判断するときは、次の項目を並べて確認します。
Control ID- リソースタイプ
- 現在の設定値
- 作成元の IaC
- 利用目的
- 変更手順
- 変更後の確認方法
Control ID が同じでも、リソースの用途が違えば同じ手順を適用できない場合があります。そのため、Control 単位でまとめた後に、用途や構成でもう一段階分けるのが安全です。
横展開するメリット
横展開できるものをまとめると、次のメリットがあります。
- 調査結果を再利用できる
- 手順書を共通化できる
- レビュー観点を揃えられる
- 作業時間を見積もりやすい
- 同じ設定不備の取りこぼしを減らせる
特に対象数が多い場合は、1件ずつ個別に進めるより、共通手順を作ってショット単位に分けた方が年間の作業負荷を平均化しやすくなります。
横展開するときの注意点
横展開は効率的ですが、同じ設定を一括適用すること自体が目的にならないよう注意が必要です。
最低限、次を確認します。
- 本番・検証など環境差がないか
- 外部システムとの接続有無が違わないか
- リソースごとに例外要件がないか
- IaC 管理か、手動管理か
- 同じロールバック方法を使えるか
共通化できる範囲と、個別判断が必要な範囲を分けておくことが大切です。
2. 顧客と合意が必要なもの
顧客との合意が必要になるケース
技術的には是正できても、担当者だけでは変更を決められないものがあります。
たとえば、次のようなケースです。
- 通信経路やアクセス元を制限する
- IAM 権限を縮小する
- 暗号化方式や KMS key を変更する
- ログ保存期間を延長する
- 新しいセキュリティサービスを有効化する
- 追加コストが発生する
- 停止や再起動を伴う
- 業務システムや外部ベンダーへ影響する可能性がある
このようなものは、「AWS の推奨設定だから変更する」だけでは進めにくいです。
合意前に整理する内容
顧客へ確認するときは、単に「対応しますか」と聞くのではなく、判断材料を揃えます。
| 項目 | 整理する内容 |
|---|---|
| 現状 | どの設定が、どのコントロールで失敗しているか |
| リスク | 現状のまま残した場合に何が起こり得るか |
| 是正案 | 何をどのように変更するか |
| 影響 | 通信、権限、停止、運用への影響 |
| コスト | 初期費用・継続費用の増減 |
| ロールバック | 問題発生時にどこまで戻せるか |
| 代替案 | 設定変更以外の統制で補えるか |
この形にしておくと、技術的な説明と業務上の判断を分けられます。
「是正しない」という判断も管理する
顧客との合意結果が、必ずしも是正実施になるとは限りません。
状況によっては、次のような判断もあります。
- 業務要件を優先して現状維持とする
- 代替統制でリスクを下げる
- 次回更改時に対応する
- 一定期間だけ例外として扱う
- 対象外と判断する
重要なのは、対応しないこと自体ではなく、判断理由・承認者・見直し時期を記録することです。
3. すぐ直せるもの
すぐ直せるものとは
すぐ直せるものは、単に作業時間が短いものではありません。
私は、次の条件が揃っているものを「すぐ直せるもの」と考えます。
- 変更内容が明確
- 業務影響が限定的
- 依存関係が少ない
- 追加コストがない、または小さい
- 手順が確立されている
- 変更後の確認方法が明確
- ロールバックできる
たとえば、未使用リソースの設定見直しや、影響範囲が限定されたログ設定などは候補になりやすいです。ただし、実際の判断はリソースの用途と顧客環境のルールに依存します。
すぐ直せるものを先に進めるメリット
影響の小さいものから進めると、次の効果があります。
- Findings の総数を早い段階で減らせる
- 作業手順や申請フローを確認できる
- 変更後の再評価にかかる時間を把握できる
- 後続作業に向けた実績を作れる
最初のショットで小さな是正を実施すると、その環境での変更・確認・報告の流れを掴みやすくなります。
「すぐ直せる」と「最優先」は同じではない
注意したいのは、すぐ直せるものが必ずしも最優先ではないことです。
Severity が高く、重大なリスクがあるものを後回しにして、簡単なものだけを消化すると、本来優先すべき課題が残ります。
そのため、優先順位は少なくとも次の観点を組み合わせて決めます。
- Severity
- 想定されるリスク
- 変更影響
- 作業量
- 顧客判断の要否
- 横展開できる件数
3分類を是正計画へ落とし込む
分類した後は、管理表へ落とし込みます。
私なら、最低限次の項目を持たせます。
| 項目 | 内容 |
|---|---|
| Control ID | IAM.1、S3.8 など |
| 対象リソース | ARN、リソース ID、リソース名 |
| アカウント / リージョン | 対象環境を特定する情報 |
| Severity | Finding の重要度 |
| 横展開可否 | 共通手順を適用できるか |
| 顧客合意 | 合意が必要か、合意済みか |
| 即時対応可否 | 影響・手順・ロールバックが明確か |
| 対応方針 | 是正、保留、対象外、代替統制 |
| 実施ショット | いつ、どの単位で対応するか |
| 確認方法 | 再評価やサービス動作確認の方法 |
この一覧があると、Findings の技術情報と、実際の作業計画をつなげやすくなります。
ショットの分け方
年間を通して是正する場合、すべてを一度に実施するのは現実的ではありません。
たとえば、次のように分けられます。
第1ショット: 影響が小さく、すぐ直せるもの
- 手順や申請フローを確認する
- 再評価までの時間を把握する
- 小さく実績を作る
第2ショット: 横展開できるもの
- 共通手順を作る
- リソース単位またはアカウント単位で分割する
- 例外リソースだけ別管理にする
第3ショット以降: 顧客との合意が必要なもの
- 影響調査とコスト試算を行う
- 代替案を含めて方針を決める
- 合意後に手順書とロールバック手順を確定する
実際には Severity や期限もあるため、この順番を固定するのではなく、優先度と作業負荷を見ながら組み替えます。
是正実施後に確認すること
設定を変更しただけでは、是正完了とは言い切れません。
実施後は、少なくとも次を確認します。
- 対象サービスが正常に動作しているか
- 意図しない通信・権限エラーがないか
Security Hub CSPMで再評価されたかCompliance.Statusが期待どおり変わったか- Finding が新たに増えていないか
- 手順書と実施結果に差異がないか
再評価には時間がかかる場合があるため、変更直後の確認と、後日の Finding 確認を分けて計画しておくと進めやすいです。
判断に迷ったときの考え方
分類に迷ったときは、次の順で考えます。
- 同じ手順を別リソースにも適用できるか
- 自分たちだけで変更可否を決められるか
- 影響・確認・ロールバックが明確か
この3つに答えると、対象がどの性質を持っているか見えやすくなります。
同じ手順を適用できる
└─ 横展開できるもの
変更可否を技術担当だけで決められない
└─ 顧客と合意が必要なもの
影響が限定的で、確認とロールバックが明確
└─ すぐ直せるもの
複数に該当する場合は、すべての属性を管理表に残した上で、最終的な実施順を決めます。
まとめ
Security Hub CSPM の Finding から対象コントロールとリソースを特定した後は、次の3つの観点で整理すると、実際の是正計画へ落とし込みやすくなります。
- 横展開できるもの
- 顧客と合意が必要なもの
- すぐ直せるもの
横展開できるものは、共通手順によって効率化できます。顧客と合意が必要なものは、リスク・影響・コスト・代替案を判断材料として揃えます。すぐ直せるものは、影響とロールバックを確認した上で早期に進められます。
ただし、3つは排他的ではなく、Severity だけでも作業量だけでも優先順位は決まりません。
最終的には、技術的な是正内容と、業務影響、意思決定、実施時期を1つの管理表でつなぎ、ショット単位で進めることが重要だと考えています。