公開資産の是正SLAとは？外部公開リスクの対応期限を決める方法を徹底解説

公開資産の是正SLAとは何か

外部公開資産は、見つけた瞬間から外部到達面なので期限を決めないと止まります

公開資産の是正 SLA とは、外から届く資産や接点に問題が見つかったとき、何日以内に判断し、何日以内に閉じるかを決める運用ルールです。一般的な脆弱性管理と似ていますが、外部公開資産では見つかった時点で外から届くため、社内限定資産より判断を早く切る必要があります。

たとえば、認証なしの管理画面、用途不明の login page、悪用実績のある edge device、公開 API の認可不備、古い callback URL などは、severity の数字だけでなく、外部からの到達性そのものがリスクを押し上げます。だから外部公開資産の SLA は、CVSS や severity の一般論を流用するだけでは足りず、露出面の性質を織り込む必要があります。

CISA Cross-Sector Cybersecurity Performance Goals↗も、インターネット向け資産の inventory と迅速な remediation を強い優先事項として扱っています。公開資産の SLA はまさにその延長で、見つけた後に放置しないための経営ルールと考えると位置づけやすくなります。

severity だけではなく、KEV と外部露出で上書きする必要があります

外部公開資産の SLA でよくある失敗は、severity 表だけを作って終えることです。たとえば high は 14 日、medium は 30 日と決めても、悪用実績がある edge device や公開管理面にそのまま当てはめると遅すぎることがあります。CISA KEV Catalog↗のように、現に悪用されている脆弱性は、CVSS より優先して扱う必要があります。

つまり外部公開資産の SLA は、severity を基準にしつつも、KEV 該当、認証なし、外部到達、用途不明、owner 不明といった条件で即時対応へ繰り上げる設計が必要です。これがないと、表面上はルールがあっても実害に追いつきません。

なぜ対応期限を決めないと直らないのか

最も放置されやすいのは medium ではなく、owner 不明と例外残です

実務で長く残るのは、必ずしも severity が低い finding ではありません。むしろ多いのは、owner 不明で戻し先が決まらないものと、例外承認したまま期限が切れていないものです。つまり SLA が必要なのは、critical を速く閉じるためだけではなく、曖昧な項目を永続化させないためでもあります。

とくに公開資産では、用途不明の login page、古い subdomain、委託先導線、管理画面の一時公開など、すぐに消せないが残す理由も曖昧な項目が多く出ます。SLA は、そうした項目に「いつまでに owner を決めるか」「いつまでに残す理由を更新するか」を与えるための仕組みでもあります。

SLA は期限表ではなく、判断と escalation のルールです

公開資産の SLA は、critical 1 日、high 7 日といった表だけを作っても機能しません。重要なのは、その期限を過ぎたときに誰へ escalation するか、例外を誰が承認するか、閉じたことを誰が再確認するかを決めることです。つまり SLA は期限表ではなく、判断と escalation のルールです。

ここまで決まって初めて、「外部公開資産の問題は何日以内に直すべきか」が実務で回ります。期限の数字だけでなく、超過時の扱いまでセットにしてください。

severity ごとに期限をどう切るか

KEV と既知悪用があるものは、severity より優先して即時へ寄せます

CISA KEV に載っているものや、現実に攻撃で悪用されている公開面は、内部評価の severity より先に即時対応へ寄せるべきです。たとえば edge device の脆弱性や認証なし管理面は、medium 相当の内部評価であっても、外部露出と悪用実績が重なれば短期では遅いことがあります。

したがって、SLA の表には「CVSS / severity ベース」と「KEV / 悪用実績 / 外部露出による繰り上げ条件」の二段構えを入れてください。これだけで、現場が「表どおりだから 14 日後でいい」と誤解するのを防げます。

owner 不明と例外残にも期限を付けるべきです

SLA の対象は技術修正だけではありません。owner 不明、承認待ち、例外継続といった管理状態にも期限を付ける必要があります。たとえば owner 不明は 5 営業日以内に社内窓口を決める、例外継続は 14 日ごとに approver 再確認、といった形です。

こうした期限がないと、最終的に最も長く残るのは技術的に難しい項目ではなく、判断が宙に浮いた項目になります。公開資産の是正 SLA は、技術作業と管理作業の両方へ期限を付けるべきです。

owner 不明と例外承認をどう扱うか

owner 不明は technical finding と同じように期限を切るべきです

公開資産の是正 SLA で見落とされやすいのが、owner 不明の扱いです。管理画面や用途不明 subdomain が見つかっても、戻し先が決まらなければ技術修正は始まりません。したがって owner 不明は「保留」ではなく、期限付きで解消すべき管理上の findingとして扱う必要があります。

実務では、owner 不明は 3〜5 営業日以内に一次窓口を決める、そこから approver を 10 営業日以内に確定する、といった段階的な期限が機能しやすくなります。技術 remediation の表とは別に、管理責任の戻し先へも SLA を付けることで、最も放置されやすい項目を減らせます。

とくに委託先や子会社が関わる接点では、社内 owner が空欄のままでも外部実務担当だけが見えていることがあります。この状態は一見管理されているように見えて、停止判断や例外承認の主体が不明なので危険です。owner 不明の扱いを SLA に組み込むことは、外部公開資産運用では必須です。

この観点を欠くと、表面上は SLA があっても最も危ない項目が後回しになります。公開面では、技術的に直しにくいものより、誰が引き取るか分からないものの方が長く残ります。だからこそ、owner 不明や例外承認を severity 表の外へ置かず、同じ運用ルールの中で期限管理する必要があります。

例外承認は期限、代替策、再承認日までそろえて初めて成立します

外部公開資産では、「今すぐ閉じられない」「業務都合で一時的に残す」といった例外が必ず発生します。問題は例外そのものではなく、理由と期限が曖昧なまま永続化することです。例外承認を安全に運用するには、残す理由、期限、代替策、再承認日を必ずセットで持つ必要があります。

たとえば vendor portal や旧システムの login page を残す場合、MFA 追加、IP 制限、監視強化などの代替策を付けたうえで、次回 review 日を決めるべきです。単に「業務都合で残す」と書くだけでは、後から説明できません。是正 SLA は、技術期限の表であると同時に、例外承認の品質を担保するルールでもあります。

ticket 完了と再確認の基準をどう決めるか

公開資産では『設定変更済み』より『外から閉じた』を完了条件にします

公開資産の remediation では、ticket が closed になっただけでは不十分です。設定変更が完了していても、DNS キャッシュ、古い endpoint、redirect の残存などで、実際には外から到達できることがあります。そのため完了条件は、内部システムのステータスではなく、外部観点で再確認して閉じたことに置く必要があります。

これは管理画面露出、dangling DNS、証明書、公開 API のどれでも同じです。closed の定義を「設定変更完了」と「外部再確認済み」に分けるだけでも、閉じたつもりの残存をかなり減らせます。ASM の結果を ticket に戻す場合も、最後に外部観点の再確認を入れる運用が重要です。

月次レビューでは、超過案件と再発案件を別々に見ると改善しやすくなります

SLA を回す組織でよくある失敗は、未対応、超過、再発、例外継続をすべて一つの一覧で見てしまうことです。これだと、どこにボトルネックがあるのか分かりません。月次レビューでは、「期限内に終わらなかった案件」と「一度閉じたのに再発した案件」を分けると、改善すべき運用ポイントが見えやすくなります。

超過案件が多いなら owner や approver の流れに問題があり、再発案件が多いなら設定標準化や変更管理が弱い可能性があります。SLA は期限表だけではなく、改善サイクルの観測装置でもあるため、レビュー時の分類方法が重要です。

公開資産ごとに期限をどう切り分けるか

管理画面、edge device、古い subdomain では同じ期限表を使わない方が安全です

公開資産の是正期限は、すべてを一律に扱わない方が安全です。認証なし管理画面、KEV 該当の edge device、用途不明の古い subdomain では、到達性、悪用実績、業務影響が異なるからです。したがって、資産タイプごとに「即時」「短期」「計画対応」の条件を少しずつ変えると、現実に即した SLAになります。

たとえば、認証なし管理画面や既知悪用の edge device は当日から 24 時間、用途不明の login page や vendor portal は 3〜7 日、証明書や DNS の整理系は 14〜30 日のように、露出面の性質で切る考え方が有効です。ここで重要なのは、CVSS を否定することではなく、外部公開面の条件で優先度を上書きするルールを持つことです。

KEV と SSVC を合わせて見ると、短すぎる期限と長すぎる期限を避けやすくなります

CISA KEV は現実に悪用されている脆弱性の判断材料になり、SSVC は stakeholder 観点で優先順位を整理する助けになります。外部公開資産の SLA では、この二つを severity の補助として使うと、根拠のある期限設定がしやすくなります。とくに経営層や現場が「なぜそれを 24 時間で直すのか」を共有するうえで有効です。

逆に、KEV や悪用実績を見ずに一般論の severity 表だけで運用すると、外部到達面の高い項目を過小評価しやすくなります。是正 SLA は、数字のルールではなく、現実の脅威と到達性を反映した判断基準として設計してください。

SLA を月次レビューと経営報告へつなぐ方法

経営層へは件数より『期限超過の理由』を見せた方が判断しやすくなります

公開資産の是正 SLA を経営層へ報告するとき、単なる件数一覧では意思決定につながりません。重要なのは、どの項目がなぜ超過したのか、owner 不明なのか、例外承認で残しているのか、再発なのかを分類して見せることです。これにより、単なる backlog ではなく、どこに運用ボトルネックがあるかを共有しやすくなります。

たとえば、high severity の件数が同じでも、owner 不明で止まっているのか、委託先調整で遅れているのか、例外承認で残しているのかでは対策が違います。経営報告では、期限超過そのものより、超過理由の分布を見せる方が改善判断につながります。

そのため報告資料では、critical / high の件数だけでなく、超過理由、owner 未確定件数、例外承認の継続件数、再発件数を同じ表で並べると有効です。数字を並べるだけで終わらせず、「どこで止まりやすいか」を見せることで、追加要員、委託先調整、例外ルールの見直しといった経営判断につながりやすくなります。

期限超過の理由が見えるだけで、SLA は責めるための数字ではなく改善の材料になります。

この粒度まで出せると、翌月の見直しが具体的になります。

現場レビューでは『閉じた件数』より『再発しない型』を作れたかを見るべきです

現場レビューで大切なのは、何件閉じたかだけではありません。同じ種類の公開面が来月も再発しないように、設定標準、owner 付与、例外承認の型ができたかを見る方が重要です。つまり SLA は、単に期限を守るための仕組みではなく、再発しない運用へ寄せるための観測装置として使うべきです。

その観点で monthly review を回すと、ticket の消化だけでは見えない改善が見えてきます。超過案件を責めるのではなく、「なぜこの種類の公開資産は毎回遅れるのか」「どの条件なら期限内に閉じられるのか」を会話できるようになると、是正 SLA は規程から実務へ変わります。

経営報告と現場 review がつながると、SLA は単なる監査向けの数字ではなくなります。どの公開面が遅れやすいか、例外がどこで固定化するか、再発がどこで起きるかが見えるようになるため、翌月の改善策も決めやすくなります。つまり是正 SLA は、期限表ではなく公開面改善の観測と対話の装置として使うべきです。

とくに公開資産の運用では、遅延や超過の背景が部門横断になりやすく、現場だけでは解けない課題が混じります。だからこそ、SLA を経営報告へつなぎ、「どこで owner が詰まるか」「どこで例外が長期化するか」を共有できる状態が必要です。期限を守るためのルールであると同時に、改善投資の優先順位を決める材料として使えるようになると、SLA は現場の負担ではなく支えになります。

その結果、SLA は単なる compliance の数字ではなく、公開面の改善をどう進めるかを示す共通言語になります。月次レビュー、例外承認、経営報告が同じ指標でつながると、期限管理はかなり実効性を持ちやすくなります。

だからこそ、SLA をレポートへ落とすときは、件数と期限だけでなく、超過理由と次の打ち手まで残してください。そこまで見えると、期限管理は監査対応ではなく改善の実務へ変わります。

ASM診断 PROで是正SLAを回すなら

ASM診断 PRO は ticket システムそのものではありませんし、例外承認ワークフローを直接持つ製品でもありません。それでも是正 SLA の起点として有効なのは、外部公開資産の問題を外から見える事実に基づいて並べ直せるからです。管理画面、公開 API、古い subdomain、証明書、用途不明の login page を一つの一覧で見られると、どれを即時、どれを短期、どれを計画対応へ置くかを決めやすくなります。

実務では、是正 SLA が機能しない理由の多くが「そもそも何が外に出ているか分からない」「問題が分散していて期限を切れない」ことにあります。ASM診断 PRO を使うと、外部公開面の差分と優先度を起点に、owner 付与、期限設定、再確認へつなぎやすくなります。つまり価値は findings の件数ではなく、期限を切って実際に閉じる対象を整理できることにあります。

とくに月次レビューで見るべきなのは、新規、未対応、期限超過、例外継続の4つです。ASM診断 PRO の結果を使えば、外から見える接点をベースにこの4分類を作りやすく、レポートや summary へも戻しやすくなります。公開資産の是正 SLA を机上の規程で終わらせず、実際の公開面と結び付けて回したいなら、まずは現状の外部露出を整理するところから始めてください。

よくある質問（FAQ）

公開資産の SLA は CVSS だけで決めてよいですか

いいえ。CVSS や severity だけでは不十分です。KEV 該当、認証なし、外部到達、owner 不明といった条件で繰り上げるルールが必要です。

owner 不明項目にも SLA を付けるべきですか

はい。owner 不明は最も長く残りやすいので、「何日以内に戻し先を決めるか」を技術修正と同じように期限管理した方がよいです。

例外承認はどれくらいの頻度で見直すべきですか

外部公開資産では短めが安全です。14 日から 30 日単位で再承認し、継続理由と代替策を更新する運用にすると、恒久化を防ぎやすくなります。

ticket を閉じたら対応完了でよいですか

いいえ。公開資産では、外から見て閉じたかの再確認まで含めて完了にした方が安全です。設定変更済みでも実際には露出が残ることがあります。

どの記事と合わせて読むと理解しやすいですか

運用全体は ISMSで外部公開資産をどう管理するか、台帳の型は 外部公開資産台帳テンプレート、報告の型は セキュリティレポートテンプレート がつながります。

まとめ

公開資産の是正 SLA で重要なのは、severity ごとの期限表を作ることだけではありません。KEV や悪用実績で繰り上げる条件、owner 不明に何日以内で答えを出すか、例外承認を誰が持つか、期限超過を誰へ escalation するか、外部観点の再確認をどう完了条件にするかまで含めて決めることが必要です。これが揃って初めて、外部公開資産の問題は「見つかったまま残る状態」から抜け出せます。

外部公開資産は、見つかった時点でインターネットから届くため、一般的な社内 IT 資産より短い判断が必要になることが多くあります。だからこそ、CVSS や severity の一般論をそのまま当てるのではなく、認証有無、到達範囲、owner 有無、悪用実績を重ねて期限を切るべきです。とくに owner 不明や例外継続は長く残りやすいので、技術修正と同じくらい強く期限管理してください。

まずは外から見える接点をそろえ、どの項目を即時、短期、計画対応へ置くのかを決めるところから始めてください。SLA は規程文書だけでは回りません。見えている公開面、owner、ticket、再確認をつなぎ、月次レビューで超過案件を処理する流れまであって、はじめて運用になります。公開資産の是正 SLA を作るなら、期限表より先に、期限を守れる運用の型を作ることが重要です。