経済産業省が主導するセキュリティ対策評価制度(SCS評価制度)の具体的な要件が、2026年3月に公開されました。SCS評価制度は2026年度末からの開始が予定されており、対応に向けた検討を本格化させている組織も増えています。

引用:経済産業省ウェブサイト『「サプライチェーン強化に向けたセキュリティ対策評価制度に関する制度構築方針」(SCS評価制度の構築方針)を公表しました』(2026/4/17参照)
https://www.meti.go.jp/press/2025/03/20260327001/20260327001.html
一方で、「どの対策をどのレベルまで実施すればよいのか」「自組織の環境でどのように実現すべきか」といった具体的な対応に悩まれている方も多いのではないでしょうか。
特に、特権アカウントに関する対策は、影響範囲の大きさから重要度が高い一方で、既存環境との関係や運用面の制約もあり、どのように対応すべきか判断が難しい領域のひとつです。
本ブログでは、SCS評価制度の中でも特に重要な対策のひとつである「特権アカウント管理」に焦点を当て、求められている要件と、その実現に向けた考え方を整理します。
なお、本記事はSCS評価制度における各対策領域を解説するシリーズの一部として、今回は特権アカウント管理をテーマにご紹介します。そのほかのシリーズは以下をご参照ください。
| 関連記事はこちら |
|
SCS評価制度の全般解説はこちら: |
SCS評価制度とは
「サプライチェーン強化に向けたセキュリティ対策評価制度(SCS評価制度)」は、組織の情報セキュリティ対策状況を“見える化”することを目的とした評価制度です。2024年7月からワーキンググループによる議論が開始され、サプライチェーン全体の安全性を高める枠組みとして注目を集めています。

引用:経済産業省「サプライチェーン強化に向けたセキュリティ対策評価制度(SCS評価制度※1)の概要」(2026/4/17参照) https://www.meti.go.jp/press/2025/03/20260327001/20260327001-a.pdf
2026年3月には制度の具体的な方針が公表され、現在は星3および星4の評価基準が示されています。制度は2026年度末までに開始され、情報処理推進機構(IPA)による運営が予定されています。

引用:経済産業省「サプライチェーン強化に向けたセキュリティ対策評価制度に関する制度構築方針」p.16
(2026/4/17参照) https://www.meti.go.jp/shingikai/mono_info_service/sangyo_cyber/wg_seido/wg_supply_chain/pdf/20260327_2.pdf
評価基準と認定方法については、星3では基礎的な対策水準を満たすことが求められ、自己評価に加えて専門家による確認を通じて認定されます。一方、星4ではより高度な対策水準が求められ、第三者機関による認証を前提とした評価となる予定です。
評価基準の中には、その準拠にあたって特定のソリューションの導入が必要となる項目も含まれます。一方で、多くは組織のセキュリティ運用体制やポリシー、運用フローの整備を求めるものであり、自組織の現状を踏まえた計画的な体制整備が重要となります。
SCS評価制度の全体像や背景については、別記事で詳しく解説しています。制度の全体像を把握したい方は、あわせてご参照ください。
SCS評価制度における特権アカウント対策の要求事項
本ブログのテーマである「特権アカウント対策」の要求事項について見ていきましょう。
現在のSCS評価制度の評価基準では、特権アカウント(*)に関する要求が複数の項目に分散して定義されています。主な該当項目は以下の通りです。
* 制度内では「管理者ID」と記載。本ブログでは一般的な表記である“特権アカウント”と表記します。
表1:SCS評価制度における特権アカウント対策に関連する評価基準まとめ
|
区分 |
評価基準No. |
|
★3 |
4-1-2-2 ~ 4-1-2-8 / 4-1-3-1 / 4-1-3-2 / 4-1-5-1 |
|
★4 |
4-1-3-5 / 4-1-7-3 ~ 4-1-7-5 |
※各項目の詳細については、公式資料をご参照ください。
これらの要求事項は、大きく以下の2つの側面に分けることができます。
-
運用体制やルール整備に関するもの
-
具体的な設定や対策ソリューションの導入による対策状況に関するもの
特に後者については、既存の対策だけでは要件を満たすことが難しいケースも想定されるため、もう少し具体的に見ていきます。
特権アカウント対策として求められるポイントを整理すると、以下の通りです。
表2:SCS評価制度における特権アカウント対策の要求ポイントと区分まとめ
|
ポイント |
区分 |
評価基準No. |
|
特権アカウントを共有しない * |
★3 |
4-1-2-2 |
|
最小権限の原則の適用 |
★3 |
4-1-2-3 / 4-1-2-8 |
|
開発環境の特権を本番環境で利用できないように制御 |
★3 |
4-1-2-4 |
|
特権アカウントの可視化と管理者の明確化 |
★3 |
4-1-2-5 |
|
不要な特権アカウントの削除 |
★3 |
4-1-2-6 |
|
利用しない特権アカウントの無効化 (JiT/ジャストインタイム) |
★3 |
4-1-2-6 |
|
アカウント利用時に必ず認証を行う |
★3 |
4-1-3-1 |
|
重要な情報を扱うクラウドサービスへのアクセス時のMFA |
★3 |
4-1-3-2 |
|
インターネット経由での社内システムへの管理者アクセス時のMFA |
★4 |
4-1-3-5 |
*回避策が示されており、アカウント共有が認められるケースもあります。
このように、SCS評価制度では特権アカウント対策として、「権限の適切な管理」と「利用時の認証強化」の両面が求められていることがわかります。
対応の考え方:特権アカウント対策編
SCS評価制度における特権アカウント対策の要求を満たす上では「アカウントの管理」と「アカウントの利用時の制御」を分けて整理することが重要です。
アカウント管理の要件
特権アカウントの管理に関する評価基準は以下の5要件です。
表3:SCS評価制度における特権アカウント管理の要求事項まとめ
|
ポイント |
区分 |
評価基準No |
|
特権アカウントを共有しない * |
★3 |
4-1-2-2 |
|
最小権限の原則の適用 |
★3 |
4-1-2-3 / 4-1-2-8 |
|
特権アカウントの可視化と管理者の明確化 |
★3 |
4-1-2-5 |
|
不要な特権アカウントの削除 |
★3 |
4-1-2-6 |
|
利用しない特権アカウントの無効化 (JiT/ジャストインタイム) |
★3 |
4-1-2-6 |
*回避策が示されており、アカウント共有が認められるケースもあります。
いずれも、適切に組織内のID管理がすでに行われている場合には、運用フローを整備することで一定の対応は可能です。
しかしながら、これらの対策を運用のみで維持することは現実的ではないケースも少なくありません。組織のIT環境は日々変化しており、人手による管理には限界があります。特に特権アカウントの無効化や権限管理については、システムによる自動化が前提となる領域といえるでしょう。
アカウント利用に対する制御要件
一方で、特権アカウントの「利用」に関する評価基準は以下の4要件です。
表4:SCS評価制度における特権アカウント利用制御の要求事項まとめ
|
ポイント |
区分 |
評価基準No |
|
開発環境の特権を本番環境で利用できないように制御 |
★3 |
4-1-2-4 |
|
アカウント利用時に必ず認証を行う |
★3 |
4-1-3-1 |
|
重要な情報を扱うクラウドサービスへのアクセス時のMFA |
★3 |
4-1-3-2 |
|
インターネット経由での社内システムへの管理者アクセス時のMFA |
★4 |
4-1-3-5 |
多要素認証(MFA)に関する要件については、オンプレミスのActive Directory(AD)認証を活用する場合、技術的な制約によりAD単体の機能のみで対応することはできません。そのため、ADに関しては専用の対策ソリューションの導入が前提となります。
また、その他の要件についても、既存の認証フローの見直しやシステム改修が必要となるケースが多く、維持が難しくなるケースもあります。結果として、専用ソリューションの活用を前提に検討することが現実的な選択肢となるでしょう。
このように整理すると、SCS評価制度における特権アカウント対策は、「管理」だけでなく「利用時の制御」、特に認証を含めて考える必要があるといえるでしょう。
一般的な特権アカウント対策としては、特権アクセス管理(PAM:Privileged Access Management)ソリューションが検討されることが多いですが、これらは比較的高価であり、運用負荷も高いことが知られています。また、今回の要求事項との関係を踏まえると、必ずしも最適なアプローチとは言えないケースもあります。
実現方法:特権アカウント対策編
それでは、SCS評価制度の要求基準に準拠するために、どのようなソリューションが適しているのでしょうか。
特権アカウントの管理と、その利用の制御を実現する手段の一つとして、弊社では「Silverfort」をご紹介しています。
Silverfortはアイデンティティセキュリティソリューションです。既存のID基盤や認証基盤と連携し、追加のインフラ構築を伴わずに導入できる点が特徴です。
組織内のあらゆるアイデンティティや認証の情報を収集し、可視化および分析を行うことができます。AD認証に対してはインラインでの追加制御を行うことで、SCS評価制度の要求事項への対応を実現します。

具体的な特権アカウントに対する「管理」と「利用」の制御機能は以下の通りです。
Silverfortが提供する特権アカウントの「管理」機能
収集した認証ログの分析をもとに、組織内で利用されている特権アカウントを可視化します。これにより、本来管理対象とすべきシャドーアドミン(管理漏れの特権アカウント)の発見が可能となります。
また、AD上の特権アカウントに対するJiT機能も提供しており、ます。不要な特権アカウントを無効化し、利用するタイミングで一時的に有効化する運用を自動化することができます。
Silverfortが提供する特権アカウントの「利用」の制御機能
特権アカウントによるAD認証に対して追加の制御を行うことが可能です。
開発環境用アカウントによる本番環境システムの利用の一律禁止や、特権アカウント利用時のMFAの適用など、認証ベースでのアクセス制御を実現します。
このように、Silverfortを活用することで、SCS評価制度への準拠に必要な対策の実現と、運用負荷の軽減を両立することが可能です。
なお、これらの要求事項に対しては、特権アクセス管理(PAM)ソリューションの導入による対策も検討されることがあります。一方で、今回のSCS評価制度では一般アカウントへのMFA要求も含まれており、特権アカウントに限定した対策では対応が難しいケースもあります。また、導入や運用の負荷を踏まえると、要件に対して過剰となるケースも考えられます。
PAMソリューションの特徴や、Silverfortとの違いについて詳しく知りたい方は、以下の記事もあわせてご参照ください。
| 関連記事はこちら |
まとめ
SCS評価制度の開始に向けて、各組織での対応検討は今後さらに進んでいくことが想定されます。一方で、今回ご紹介したような対策は短期間で実現できるものではなく、特に認証基盤に関わる領域については、計画的に進めていくことが重要です。
また、特権アカウントへの対策は、SCS評価制度への対応という観点に限らず、サイバー攻撃対策としても重要な要素です。制度対応とあわせて、今から段階的に取り組みを進めていくことが求められます。
本ブログでご紹介したように、特権アカウントの「管理」と「利用時の制御」を認証レイヤーから実現するアプローチとして、Silverfortを活用することで、既存環境を活かしながら現実的な対策を進めることが可能です。
SilverfortによるAD認証へのMFA適用については、「実際にどのように導入できるのか」「既存環境でどこまで対応できるのか」といった点が気になる方も多いのではないでしょうか。 より具体的な実現方法や活用イメージを知りたい方は、以下の資料もぜひご覧ください。
また、弊社ではSCS評価制度への準拠に向けたアセスメントサービス(NVC Essentialサービス)も提供しています。自組織でどこまで対応できているのか、どのように制度への準備を進めるべきかを整理したい場合は、お気軽にご相談ください。








