CSPM（Cloud Security Posture Management）は、クラウド資産のセキュリティ状態を継続的に把握し、設定上の問題やリスクの改善につなげる仕組みです。例えばMicrosoft Defender for Cloudは、クラウド基盤を定めたセキュリティ基準に照らして評価し、改善の推奨事項を示します。Microsoft LearnのCSPM解説
企業で導入する際は、検出結果を誰が受け取り、誰が修正を決め、何を確認して完了とするかまで設計しましょう。本記事では、IT担当者が設定リスクを修正担当へ渡すための手順を整理します。以下の役割分担・優先順位・確認表は編集上の運用案です。自社の対象システムと変更管理のルールに合わせて調整してください。
CSPMで確認する範囲を決める
CSPMの導入を検討するときは、「クラウドを点検する」という説明を、対象と評価項目に分解します。比較時の確認項目は、ストレージの公開設定、ネットワークの接続許可、権限、監査ログなどです。これらを自社で点検したい項目として書き出し、候補製品が実際に対応する範囲と照合します。
製品名だけで機能を判断せず、契約プランも確認してください。Microsoft Defender for Cloudでも、基礎的なCSPMと、攻撃経路分析・リスク優先順位付けなどを含むプランを区別しています。比較の際は、設定の評価、リスクの分析、修正支援を別々の欄にすると判断しやすくなります。Microsoft Learn「CSPM plans」
また、設定評価の結果だけで侵害の有無まで結論づけない運用にします。不審なアクセスなどが見つかったときは、設定の修正依頼と並行して、事故対応窓口へ調査を引き継ぐ手順を用意します。
導入前に対象・権限・担当をそろえる
最初の作業は、対象アカウントやプロジェクトと、管理責任者の一覧を作ることです。次の表を埋め、未確認の項目を残したまま「全社の点検ができた」と扱わないようにします。
| 確認項目 | 自社で記入する内容 | 確認相手 |
|---|---|---|
| 対象範囲 | クラウド名、アカウント・プロジェクト、リージョン、本番・開発の区別 | 基盤管理者 |
| 評価範囲 | 対応リソース、評価ルール、対象外とする項目 | セキュリティ担当・製品担当 |
| 接続権限 | 評価に必要な権限、付与者、見直し方法 | 権限管理者 |
| データの扱い | 収集する情報、保存先、閲覧者 | 情報管理責任者 |
| 修正の責任 | リソース所有者、実施者、変更承認者 | システム責任者 |
| 費用と運用 | 課金対象、見積もり条件、通知先、受付時間 | 契約担当・運用担当 |
点検用の接続権限と、設定を変更する権限は別の項目として確認します。最初は評価と通知の流れを試し、自動修復を採用するかは変更内容ごとに判断する進め方が考えられます。
検出から修正・再確認までの5段階
1. 検出結果を対象リソースに結び付ける
受付時には、検出ID、ルール名、対象リソースの識別子、検出日時、評価された設定値を残します。担当を割り当てる前に、現在の設定と評価時点の情報を照合してください。担当が不明な場合の調査窓口も決め、宛先不明のまま通知を繰り返さない運用にします。
2. 重大度に業務上の条件を加える
対応順は、製品が示す重大度に加え、外部から到達できるか、重要なデータを扱うか、本番業務への影響があるかで検討します。例えば、外部公開された管理用の接続口は、公開の必要性と接続元の制限を優先して確認する対象にできます。
期限を一律に決める前に、即時の判断が必要な条件と、通常の変更枠で扱える条件を分けましょう。修正による停止が懸念される場合は、暫定措置と恒久対応を別の作業として記録します。
3. 修正依頼に判断材料を付ける
通知には、検出内容だけでなく、期待する設定、変更による業務影響、担当者、期限、承認者を添えます。担当者が受領したことも記録してください。
AWS Security Hub CSPMでは、リソース所有者へ問題を通知した状態をNOTIFIEDとして扱います。これを参考に、社内の管理票でも「通知済み」と「修正完了」を分けると進捗を追いやすくなります。AWS公式のワークフローステータス解説
ただし、NOTIFIEDとRESOLVEDは、RecordStateがARCHIVEDからACTIVEへ変わるか、Compliance.StatusがPASSEDからFAILED・WARNING・NOT_AVAILABLEのいずれかへ変わると、自動でNEWへ戻ります。通知した履歴は状態名だけに頼らず、社内の管理票に通知日時・通知先・受領記録を残す運用にします。
4. 変更を承認し、影響を確かめる
実施前に、変更する設定、影響する接続や処理、確認手順、切り戻し方法をそろえます。設定をコードで管理している場合は、その管理元も修正対象に含めるか確認します。
自動修復を検討する場合は、対象ルールを限定し、実行条件・必要権限・承認の要否・失敗時の連絡先を定義します。試行環境で業務確認と切り戻しまで検証してから、適用範囲を広げる順序が考えられます。
5. 再評価と業務確認を完了条件にする
修正後は、CSPMの評価が更新されたか、意図した設定になったか、必要な業務が動作するかを確認します。「設定変更を実行した」という記録に、再評価の日時と結果を加えて完了にします。
評価結果が変わらない場合は、更新時刻や対象リソース、適用したルールを確認し、原因が分かるまでは保留とします。担当者が手動で対応状態を完了にしたことと、設定の評価結果が改善したことを混同しないようにしてください。
AWSでは、コントロール由来の検出でCompliance.StatusがPASSEDなら、ワークフローステータスは自動でRESOLVEDになります。この状態名だけを業務確認の完了証跡とせず、管理票には業務確認の実施日時・確認者・結果を別に保持します。AWS公式の状態管理仕様
誤検知と承認済み例外を分けて管理する
検出に違和感があるときは、まずルールの条件と実際の設定を照合します。判断の整理には、次の区分を使えます。
| 区分 | 判断の内容 | 残す情報 |
|---|---|---|
| 修正対象 | 評価内容を確認し、設定を直す | 実施者、期限、承認者、再評価結果 |
| 誤検知の疑い | 評価が実態と一致しているか未確認 | 設定の証跡、照会先、再確認日 |
| 承認済み例外 | 指摘を認めたうえで、期間や条件を限定して許容する | 理由、承認者、代替策、有効期限 |
公開を意図したリソースであっても、業務上の必要性と公開範囲を確認せずに誤検知とは決めません。例外にする場合は、対象リソースとルールを特定し、期限到来時や用途変更時に見直す条件を付けます。
検出結果を抑制する操作は、設定の修正とは分けて管理します。AWSの仕様でも、SUPPRESSEDやRESOLVEDへ変更するだけでは、同じ問題について新たな検出結果が生成されることを防げません。AWS公式の状態管理仕様
また、SUPPRESSEDは、RecordStateがARCHIVEDからACTIVEへ変わっても状態が変わりません。抑制状態の変化だけで例外の再確認を判断せず、承認済み例外の有効期限と再確認日は社内の管理票で別に管理します。
修正を外部へ依頼する場合の分担
委託を検討するときは、設定評価、一次確認、修正案の作成、実際の変更、再評価のうち、どこまでを依頼するか明記します。社内には、業務への影響を判断する責任者と、例外を承認する担当を置く案が考えられます。
事故の疑いがある場合の連絡先も、通常の修正チケットとは別に用意してください。停止や復旧の判断権限を整理する際は、CSIRTの役割・判断権限・連絡経路の決め方も参照できます。
引き継ぎ時には、次の記入欄を1件の検出結果に対応させます。
| 記入欄 | 記入内容 |
|---|---|
| 対象と根拠 | 検出ID、ルール、リソース、評価日時、設定の証跡 |
| 対応判断 | 業務への影響、優先度、修正・調査・例外の区分 |
| 担当と期限 | 受領者、実施者、承認者、対応期限 |
| 作業計画 | 変更内容、業務確認、切り戻し方法 |
| 完了の証跡 | 実施日時、再評価結果、業務確認結果 |
| 例外の管理 | 許容理由、代替策、承認者、有効期限、再確認日 |
まず管理責任者が明確な範囲を選び、検出から担当者の受領、変更承認、再評価までを一巡させます。担当未定や期限未設定の案件が残る箇所を直してから対象を広げれば、導入時に整えるべき運用が具体的になります。