公開資産の是正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 は、技術作業と管理作業の両方へ期限を付けるべきです。

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 を作るなら、期限表より先に、期限を守れる運用の型を作ることが重要です。