経産省セキュリティ対策評価制度（SCS）とは？★3・★4要件とASMの役割を徹底解説

セキュリティ対策評価制度（SCS）とは何か

SCS は『制度のための制度』ではなく、説明責任を整える仕組みです

経産省が進めるセキュリティ対策評価制度は、企業がどれだけ高価な製品を導入したかを競う制度ではありません。主眼は、サプライチェーンの中で自社がどこまで説明責任を果たせるかにあります。評価対象になるのは、IT資産を把握しているか、重要な外部公開面を認識しているか、脆弱性や例外運用の是正が回っているか、委託先や子会社まで含めて継続管理できているかです。

したがって SCS は、監査書類の作法だけを整えれば通る制度ではありません。実際に資産台帳、owner、最終確認日、是正状況、例外承認者を説明できることが前提になります。既存の経産省 ASM 導入ガイダンスが「外部公開資産を継続監視する理由」を示したのに対し、SCS は「その運用をどこまで組織として説明できるか」を問う制度です。

制度対応の実務で重要なのは、文書の解釈よりも、制度文言を自社の運用票へ翻訳することです。たとえば「IT資産の適切な管理」と書かれていても、現場では「どの台帳を使い、誰が owner で、更新差分をどう確認し、例外をどこへ記録するか」を決めないと運用になりません。この翻訳が弱いままでは、制度説明と現場運用が分離します。

★3・★4は『成熟度の差』であって、製品数の差ではありません

★3・★4という表現を見ると、製品を増やすほど上がるように誤解されがちですが、実際には管理の成熟度と継続性の差を見ます。★3 では最低限の資産把握、責任分界、基本統制が回っているかが重要で、★4 ではそれを継続改善し、取引先や委託先まで含めて運用の再現性を持てているかが重くなります。

この違いを現場目線で言い換えると、★3 は「管理すべきものが見えていて、誰が動くか決まっている状態」、★4 は「変化や例外が出ても崩れず、証跡を残しながら回し続けられる状態」です。ここを理解しないまま制度対応を始めると、台帳を一度作って終わり、診断を一回取って終わり、という単発対応に戻りやすくなります。

ASM と SCS は同義ではないが、外部公開資産管理で強く接続します

ASM は SCS 制度そのものではありません。一方で、SCS が求める「IT資産の適切な管理」「外部に露出する資産の把握」「継続確認できる体制」のうち、特に外部公開資産まわりの実装では ASM の考え方が強く効きます。外から見えるドメイン、サブドメイン、公開ログイン画面、証明書、DNS、公開ストレージ、古い管理画面は、台帳だけでは抜けやすいからです。

つまり本記事で言う ASM の役割は、制度の代替ではなく、制度で問われる資産管理の弱点を埋める補助線です。制度本文を丸暗記するより、「どの資産が外から見え、誰が owner で、いつ確認され、見つかった問題を何日で是正するか」を説明できる状態へ寄せる方が、SCS への準備として実務的です。

★3・★4で何が求められるのか

★3でまず問われるのは『見えているか』と『誰が責任者か』です

★3 の段階で詰まりやすいのは、制度の難しさそのものではなく、資産がそもそも見えていないことです。公開ドメイン、サブドメイン、ログイン画面、VPN、証明書、SaaS、委託先接続などが分散管理されていると、「自社の IT 資産を適切に管理している」と説明しづらくなります。ここで重要なのは、一覧の存在だけでなく、owner と最終確認日が付いているかです。

既存の外部公開資産台帳テンプレートやISMS での外部公開資産管理が役立つのもこの点です。SCS では「台帳があります」と言うだけでは弱く、「誰が見て、いつ更新し、使わなくなった資産をどう閉じるか」まで説明できる必要があります。

★4は『変化に追従できるか』と『継続できるか』が重くなります

★4 に近づくほど、単発の把握ではなく、変化に追従できることが問われます。新しいドメインの追加、子会社や委託先の切り替え、公開管理画面の再露出、証明書切り替え、外部委託先アカウントの残置など、変化が起きても運用が崩れないことが重要です。

ここで差が出るのは、ツールの種類より差分をどう拾い、誰がどの期限で是正するかを持っているかです。つまり、★4 の準備は高機能化よりも、是正 SLA、例外承認、月次レビュー、経営報告の運用整備に近いと言えます。制度要件を読むと抽象的に見えても、実務へ落とすと「台帳」「差分」「期限」「証跡」の4点に集約されます。

制度対応で抜けやすいのは、委託先と外部公開面が交差する場所です

企業が制度対応で見落としやすいのは、社内資産よりも委託先や外部公開面との接点です。具体的には、保守用 VPN、外部公開されたログイン画面、委託先用アカウント、古いサポート導線、子会社が独自に運用するドメインなどです。これらは現場では「業務都合の例外」として残りやすく、制度では「継続管理の弱点」として見られます。

そのため SCS 対応では、保守用 VPN の統制や公開管理画面・開発環境の露出管理のような既存論点を、制度対応の証跡へ戻して説明する設計が必要です。技術対策の列挙ではなく、「なぜその統制が必要か」を制度言語へ翻訳することが重要です。

自社で先に整えるべき項目は何か

最初に整えるべきなのは、公開資産の owner 管理です

制度準拠で最初に効くのは、脆弱性診断の本数を増やすことではなく、どの資産を誰が説明できるかを固めることです。owner 不明の外部公開資産が残っていると、是正判断も例外承認も滞ります。制度の観点では「脆弱性があること」より、「見つかっても誰も責任を持てないこと」の方が深い問題です。

そのため、外部公開資産の一覧には必ず owner、公開目的、委託先有無、認証方式、最終確認日を付けるべきです。SCS では抽象的な表現でも、実務へ落とすとこの粒度がないと運用説明が成立しません。

次に必要なのは、是正と例外を同じレーンで管理することです

制度対応の現場でありがちなのは、脆弱性や公開面の問題を見つけても、例外運用が別ファイル・別会議で管理されることです。これでは「なぜまだ公開のままなのか」「なぜ是正が延びているのか」を説明できません。

したがって、SCS 対応では、発見・優先度・是正期限・例外承認・再確認を一つの管理票で見られるようにすることが重要です。ここが整うと、制度説明だけでなく、日常の remediation governance も一気に進みます。

委託先と子会社は、台帳の外へ追い出さない方が安全です

SCS の文脈では、委託先や子会社の資産を「別組織だから」と切り離しすぎると、説明責任の穴になります。もちろん法的責任や運用責任は分かれますが、少なくとも自社が依存している外部公開面は同じ視界に置く必要があります。

子会社のドメイン、委託先が運用する公開管理画面、ブランド配下のログイン URL が別管理になっていると、制度対応の際に「見ていませんでした」が発生しやすくなります。だからこそ、SCS 準備ではグループ会社と委託先を早い段階から台帳設計へ戻すべきです。

ASM がどこで効くのか

ASM の価値は、制度文書そのものを満たすことではありません。価値が出るのは、外部公開資産の見落としや owner 不明資産があると制度説明が崩れる場面です。サブドメイン、公開ログイン画面、証明書、DNS、古い管理画面、放置された staging 環境は、社内台帳だけでは漏れやすく、SCS の実務準備ではかなりの確率で問題になります。

ここで ASM を使う意味は、外から見える範囲で棚卸しの抜けを減らすことにあります。たとえば既存のサブドメイン監視、証明書監視、外部接続点の可視化のような論点は、制度対応で「見えているか」「変化を追えるか」を説明する時の土台になります。

とくに SCS で効くのは、①外部公開資産の再棚卸し、②owner 不明資産の洗い出し、③再露出や差分の確認、④是正優先度の材料づくりです。逆に、ASM だけで制度準拠が完結するわけではありません。台帳、責任分界、是正 SLA、例外承認、監査証跡までつなげて初めて制度対応になります。

したがって、SCS への備えとしての ASM は「ツールを導入すること」ではなく、「制度で問われる外部公開資産管理を説明できる状態に戻すこと」と捉えるのが正確です。そこまで踏み込むと、制度対応と日常運用が分離しにくくなります。

SCS準備で外部公開資産を整えるなら ASM診断 PRO

ASM診断 PRO は、SCS の制度審査を代行する製品ではありません。また、制度文書のチェックリストを自動で満たしてくれる製品でもありません。それでも SCS 準備で相性が良いのは、制度要件の中でも特に説明が難しい外部公開資産の把握と継続確認を、外から見える範囲で整理しやすいからです。

企業が制度対応で詰まりやすいのは、「台帳に載っていない公開資産が残っていた」「子会社や委託先が運用している公開面を本社が把握していなかった」「古いログイン画面や staging が消えたと思っていたのに残っていた」といった場面です。ASM診断 PRO なら、ドメイン、サブドメイン、公開管理面、証明書、古い露出面を外から確認し、どこから owner 特定と再棚卸しを始めるべきかの起点を作れます。

SCS の本質は、資産を見つけることではなく、見つけた資産を継続管理し、説明できることです。だからこそ、ASM診断 PRO の価値も「見つけて終わり」ではありません。見つかった外部公開資産を台帳へ戻し、owner を付け、是正優先度を決め、レポートへ落とし込むところまでつないで使うと、制度対応と日常運用の距離を縮めやすくなります。制度準拠の準備を単発対応で終わらせたくないなら、外から見える公開面の棚卸しを起点にして、台帳・是正・証跡の流れへ戻してください。

よくある質問（FAQ）

SCS は ASM を入れていれば対応できますか

いいえ。ASM だけで SCS に対応できるわけではありません。SCS では、資産管理、責任分界、委託先統制、是正運用、継続改善、証跡が問われます。ASM はそのうち外部公開資産管理を補強する役割です。

★3 と ★4 の違いは、何を入れたかより運用の差ですか

はい。その理解で概ね合っています。★3 は最低限の管理と責任分界、★4 は差分追跡や継続改善まで含む成熟度の差として捉えると整理しやすいです。製品数よりも、台帳、owner、是正期限、例外承認、証跡の運用が重要です。

制度対応で最初に詰まりやすいのは何ですか

多くの企業で最初に詰まるのは、外部公開資産の owner 不明、委託先接続の分散管理、例外承認の曖昧さです。資産自体より、誰が責任を持つかが曖昧なことが制度対応の弱点になります。

SCS 対応では子会社や委託先も見るべきですか

はい。法的責任や運用責任は分かれていても、自社の事業継続や外部公開面と結びついている子会社・委託先は、少なくとも台帳や説明責任の範囲へ戻すべきです。切り離しすぎると制度説明が弱くなります。

SCS の準備で、最初にやるべき実務は何ですか

外部公開資産を含む台帳へ owner と最終確認日を付けること、重大資産の是正 SLA を決めること、委託先と子会社を含めた責任分界を整理すること、この 3 点が最初の実務として有効です。制度文書の読解だけで始めるより、運用票を先に作る方が進みやすくなります。

まとめ

セキュリティ対策評価制度（SCS）は、製品導入数を競う制度ではなく、企業が自社とサプライチェーンのセキュリティをどこまで継続管理できるかを問う制度です。★3・★4 の違いを実務で言い換えるなら、★3 は「何を守り、誰が責任を持つかを説明できる状態」、★4 は「変化や例外が出ても崩れず、是正と証跡を継続できる状態」です。したがって準備の中心は、制度文言の暗記ではなく、外部公開資産を含む台帳、owner、是正期限、例外承認、月次レビューを運用へ載せることにあります。

とくに制度対応で差が出るのは、外部公開資産、委託先接続、子会社ドメイン、古いログイン画面のような「社内の想定より外にある資産」をどこまで管理票へ戻せるかです。ASM は制度そのものではありませんが、こうした公開面の棚卸し、owner 不明資産の特定、差分確認の土台づくりに強く効きます。SCS 対応を単発の監査準備で終わらせず、日常運用と結びつけるなら、まずは外から見える資産を把握し、それを台帳、是正、証跡へつなげる流れを作ってください。