目次 見出しへ移動 一覧 ▲
サプライチェーン強化に向けたセキュリティ対策評価制度(★3・★4)完全ガイド 高額な専用機器のリースに頼らず、実質的な26要件で取引先からの信頼と安全を守る実践手順
近年、発注元の大手企業や中堅企業から「セキュリティ対策状況の調査票」や「SCS評価制度の★3相当の対策」を求められる場面が急増しています。これは、強固に守られた大企業を直接狙うのではなく、取引先の中小企業のVPN機器や端末を踏み台にしてサプライチェーン全体を止める攻撃が多発しているためです。 本ページでは、経済産業省とIPA(情報処理推進機構)が策定を進める「サプライチェーン強化に向けたセキュリティ対策評価制度(SCS評価制度)」の全体像から、現場で無理なく進める26要件の対策、誤解されやすい機器リースの注意点、そしてホワイトハッカー視点での証跡自動化(Policy-as-Code)までを4ステップで解説します。
3秒でわかる本ページの要点
① 多くの取引先が求める標準水準は「★3(全26要件)」であり、② 高額な箱物機器(UTM等)を1台置けば満たせるものではなく、③ 「通信の入口(VPN/ID)」「書き換え不能バックアップ」「緊急時の連絡手順」の3点を固めることが最も効果的です。
知りたい深さに合わせてステップを切り替えられます(図表はすべてクリックで拡大表示できます)
経済産業省・IPA サプライチェーン強化に向けたセキュリティ対策評価制度(SCS評価制度 ★3・★4)の全体像(写真・図表はすべてクリック/タップで拡大表示できます)
SCS評価制度(★3・★4)とは何か? なぜ今すべての取引先に求められているのか?
まずは制度ができた背景と、★3・★4の違い、そして「何から手をつければよいか」の全体像を3枚の図解で直感的に把握しましょう。
取引先ごとのバラバラな調査票を「★3・★4」に統一
これまで発注企業ごとに独自のエクセル調査票が送られていましたが、国が共通基準(★3=標準26要件、★4=重要領域向け高水準)を定めることで、1回の対策・評価で複数の取引先に証明できるようになります。
中小・中堅企業の基本目標は「★3(26要件)」
既存のSECURITY ACTION(一つ星・二つ星)を土台としつつ、一歩進んで「実際に設定されているか(多要素認証・パッチ更新・隔離バックアップ・初動手順)」を確認するのが★3です。
「UTMを置けば★3取得」という誤解に注意
高価なネットワーク機器をリースしても、パスワード使い回しや古いVPN放置、バックアップ未分離があれば★3は満たせず被害も防げません。OS標準機能と運用ルールの整備が主役です。
SCS★3(全26要件)を4つの実務ブロックに整理し、専任担当者不在でも着実に進める手順
SCS★3(全26要件)を4つのブロックに分け、専任担当者がいなくても進める手順
26個の要件を1つずつバラバラに読むと難しく感じますが、現場の作業に置き換えると「①台帳とルール」「②入口とID」「③端末とログ」「④緊急連絡とバックアップ」の4ブロックに整理できます。
その場でわかる「SCS★3 重要5項目」セルフチェック(会員登録・送信不要)
ブラウザ内のみで計算されますあてはまる項目にチェックを入れると、現在の到達目安と次に優先すべき対策が表示されます。
| 比較項目 | ❌ 悪質7年高額UTMリース(電話勧誘・訪問販売) | ⭕ 適正調達・オープンアーキテクチャ(推奨) |
|---|---|---|
| 総支払費用 | 月額2.5万〜3.5万円 × 84ヶ月 = 総額210万〜294万円(本体定価の3〜5倍) | 月額数千円〜1.5万円台の公的お助け隊 / クラウド標準機能活用で 年間数万〜20万円程度 |
| 契約拘束と中途解約 | 信販会社の動産ファイナンスリース。中途解約不可、倒産時も残債一括請求。 | 月額サブスクリプションまたは買い切り。事業環境の変化に応じていつでも見直し・解約可能。 |
| TLS 1.3 暗号化検査(DPI) | 復号処理が重すぎてCPUが耐えられず、初期設定でHTTPSスキャン無効化。暗号化パケット素通り。 | エンドポイント(端末側)保護(EDR / ブラウザ分離 / DNSフィルタリング)で暗号化を問わず確実に遮断。 |
| ハードウェア寿命(EOL) | 4〜5年でメーカーサポート(定義ファイル更新)終了。残りの2〜3年間は無防備な置物と化す。 | クラウド型サービスのため常に最新シグネチャ・OSへ自動更新。ハードウェア陳腐化の罠がゼロ。 |
| SCS★3(26要件)適合性 | 箱を置くだけでは要件の1割未満しか満たせず、取引先監査で「不適合」判定の事例が頻発。 | MFA必須化、不変バックアップ、端末台帳、連絡体制表を網羅し、26要件すべてに確固たる証跡を提供。 |
NIST CSF 2.0・NIST SP 800-171・サイバーセキュリティお助け隊との国際・国内制度マッピング
SCS評価制度は国内独自のガラパゴス規格ではなく、米国国立標準技術研究所(NIST)の「NIST Cybersecurity Framework (CSF) 2.0」および「NIST SP 800-171」と整合するように設計されています。そのため、SCS★3・★4に沿って対策を整えることは、自動車(JAMA/JAPIAガイドライン)、防衛産業、医療機器、海外取引先の要請にもそのまま応えられる共通資産になります。
ホワイトハッカー視点による「UTM過信の盲点(TLS 1.3 / AiTM)」解剖とOpenZFS・Rust監査証明
ホワイトハッカー視点のEASM(外部攻撃面管理)、OpenZFS Merkle木による不変バックアップ証明、およびRust Policy-as-Code自動監査
ここからは、セキュリティ技術者・監査人向けに、人手によるエクセル自己申告の限界(設定ドリフト・形骸化)を解決するため、外部攻撃面(EASM)スキャン、FreeBSD 15.1 + OpenZFS + db01.ok.st(PostgreSQL 19)による不変証跡、およびRust 2024による26要件の自動検証(Policy-as-Code)の実装を示します。
1. Rust 2024による SCS★3 必須コントロールの Policy-as-Code 検証実装
下記のRustコードは、サプライチェーン攻撃で最も悪用される「外部公開危険ポートの残存」「多要素認証(MFA)の未適用」「休眠アカウントの放置」「不変バックアップの鮮度切れ(RPO超過)」を機械的に検査し、1つでも違反があれば明確な是正理由とともに不適合(Fail-Closed)を返す決定論的検証器の例です。
#![forbid(unsafe_code)]
#[derive(Debug, Clone, PartialEq, Eq)]
pub struct TenantSecurityPosture {
pub exposed_tcp_ports: Vec<u16>,
pub total_active_users: u32,
pub mfa_enforced_users: u32,
pub dormant_accounts_over_90d: u32,
pub latest_immutable_snapshot_age_hours: u32,
pub zfs_hold_active: bool,
pub dmarc_policy_enforced: bool,
}
#[derive(Debug, Clone, PartialEq, Eq)]
pub enum ScsFinding {
DangerousPortExposed(u16),
MfaCoverageIncomplete { enforced: u32, total: u32 },
DormantAccountsRemaining(u32),
ImmutableBackupStaleOrUnlocked { age_hours: u32, zfs_hold: bool },
DmarcNotEnforced,
}
#[derive(Debug, Clone, PartialEq, Eq)]
pub enum ScsStar3Verdict {
Compliant,
NonCompliant(Vec<ScsFinding>),
}
const FORBIDDEN_WAN_PORTS: [u16; 5] = [21, 23, 445, 1433, 3389]; — FTP, Telnet, SMB, MSSQL, RDP
pub fn evaluate_scs_star3_posture(posture: &TenantSecurityPosture) -> ScsStar3Verdict {
let mut findings = Vec::new();
// 1. 境界防御:危険ポート(RDP/SMB等)のWAN直接公開禁止
for &port in &posture.exposed_tcp_ports {
if FORBIDDEN_WAN_PORTS.contains(&port) {
findings.push(ScsFinding::DangerousPortExposed(port));
}
}
// 2. ID・認証:全アクティブユーザーへの多要素認証(MFA)100%強制
if posture.total_active_users == 0 || posture.mfa_enforced_users < posture.total_active_users {
findings.push(ScsFinding::MfaCoverageIncomplete {
enforced: posture.mfa_enforced_users,
total: posture.total_active_users,
});
}
// 3. アカウント棚卸:90日以上未利用の放置アカウントゼロ
if posture.dormant_accounts_over_90d > 0 {
findings.push(ScsFinding::DormantAccountsRemaining(
posture.dormant_accounts_over_90d,
));
}
// 4. 復旧性:24時間以内の不変スナップショット+OpenZFS zfs hold ロック
if !posture.zfs_hold_active || posture.latest_immutable_snapshot_age_hours > 24 {
findings.push(ScsFinding::ImmutableBackupStaleOrUnlocked {
age_hours: posture.latest_immutable_snapshot_age_hours,
zfs_hold: posture.zfs_hold_active,
});
}
// 5. メールなりすまし対策:DMARC検証
if !posture.dmarc_policy_enforced {
findings.push(ScsFinding::DmarcNotEnforced);
}
if findings.is_empty() {
ScsStar3Verdict::Compliant
} else {
ScsStar3Verdict::NonCompliant(findings)
}
}
2. db01.ok.st(PostgreSQL 19)による監査証跡の保全とネイティブJSONエクスポート
取引先からセキュリティ監査や証跡の提出を求められた際、db01.ok.st の PostgreSQL 19 では、FORCE ROW LEVEL SECURITY によってテナント間の証跡を完全隔離した上で、COPY ... TO STDOUT (FORMAT JSON) によりCPU負荷をかけずに26要件の適合履歴を即座にJSON形式で出力できます。
CREATE TABLE IF NOT EXISTS scs_compliance_evidence_ledger (
evidence_id UUID PRIMARY KEY DEFAULT uuidv7(),
tenant_id UUID NOT NULL,
evaluation_date DATE NOT NULL,
target_tier TEXT NOT NULL CHECK (target_tier IN ('STAR3', 'STAR4')),
passed_controls INT NOT NULL CHECK (passed_controls BETWEEN 0 AND 26),
zfs_merkle_root TEXT NOT NULL,
posture_jsonb JSONB NOT NULL,
blake3_signature TEXT NOT NULL,
recorded_at TIMESTAMPTZ NOT NULL DEFAULT clock_timestamp(),
UNIQUE (tenant_id, evaluation_date, target_tier)
);
ALTER TABLE scs_compliance_evidence_ledger ENABLE ROW LEVEL SECURITY;
ALTER TABLE scs_compliance_evidence_ledger FORCE ROW LEVEL SECURITY;
CREATE POLICY scs_ledger_tenant_isolation ON scs_compliance_evidence_ledger
USING (tenant_id = (SELECT sovereign_auth.current_tenant_id()));
-- PostgreSQL 19 ネイティブJSONストリーミングによる取引先提出用監査レポート出力
COPY (
SELECT evidence_id, evaluation_date, target_tier, passed_controls,
zfs_merkle_root, posture_jsonb, blake3_signature, recorded_at
FROM scs_compliance_evidence_ledger
WHERE tenant_id = (SELECT sovereign_auth.current_tenant_id())
ORDER BY evaluation_date DESC
LIMIT 90
) TO STDOUT WITH (FORMAT JSON);
4. ホワイトハッカー警鐘:「高額なUTM(7年リース)を置けば安心」という誤解の技術的解剖と2026年取引契約条項
TLS 1.3 ECH / QUIC & SCS ★3/★4 Legal Clause
中小企業の現場では、「これ1台でウイルスもハッカーもすべて防げる」という営業トークで、150万〜250万円(5年〜7年リース)のUTM(統合脅威管理アプライアンス)が販売されるケースが後を絶ちません。しかし、現在のインターネット通信の95%以上は TLS 1.3(RFC 8446) や QUIC(HTTP/3, RFC 9000) で暗号化されており、証明書インスペクション(SSL復号)や端末側のEDR/パスキー(FIDO2)を持たない「箱を置いただけのUTM」では、現代の主流攻撃を構造的に検知できません。さらに、UTM自身が FortiOS CVE-2024-21762 や Ivanti CVE-2024-21887 のような「侵入の入り口(初期侵入ベクトル)」になる事例が多発しています。
| 現代の主要攻撃ベクトル | 攻撃の技術的メカニズム | UTM単体(SSL非復号・箱置き)の限界 | SCS★3・★4 本質対策での防御原理 |
|---|---|---|---|
| AiTM中間者フィッシング(Evilginx3等) | 正規のTLS 1.3通信上でリバースプロキシが認証済みセッションCookieを窃取 | ペイロードがTLS暗号化されており、UTMのDPI(パケット検査)を100%素通り | FIDO2 / WebAuthn パスキーの rpIdHash オリジン束縛により数学的に100%遮断 |
| 正規クラウドストレージ悪用(LOTL / Rclone) | 機密データをMEGA・Dropbox・Google Drive等の正規HTTPS通信で外部へ窃取 | 正規クラウドのIP/SNI宛てTLS 1.3通信のため、シグネチャ型UTMでは遮断不可 | EDRプロセス監視+DNS/CASBホワイトリスト+大量送信レート制限で即時検知 |
| VPN・UTM機器自体のOSゼロデイ脆弱性 | 公開インターフェースのヒープ/スタックオーバーフロー(CVE-2024-21762等) | 防御装置であるはずのUTM自身が攻撃者の侵入拠点(C2中継器)に転落 | 公開ポートゼロ化(閉域網・mTLS)+ EASMによる外部公開資産の常時棚卸し |
| バックアップ領域への横展開・削除 | AD管理者権限奪取後、共有NASおよび vssadmin delete shadows を実行 |
LAN内部の横展開(East-West通信)には外周のUTMは一切関与できず全滅 | FreeBSD 15.1 OpenZFS zfs hold 不変スナップショット(Pull型隔離)で100%保全 |
SCS評価制度(★3・★4)と中小企業のセキュリティ対策に関するよくあるご質問
Q1 SCS評価制度(サプライチェーンセキュリティ評価制度)とは何ですか?★3が標準とされる理由は何ですか? ▼
経済産業省およびIPAが主導する、サプライチェーン全体(元請から下請・協力会社まで)のサイバー防壁を確保するための評価枠組みです。★1(自己宣言)から★4(高度防壁・第三者監査)まで段階があり、自動車・電機・重工・医療などの大手発注元が調達仕様書や取引基本契約で協力会社に求めるデファクトスタンダードが「★3(標準26要件)」です。取引停止やサプライチェーンからの除外を防ぐための必須資格になりつつあります。
Q2 取引先の大手企業から「SCS評価制度★3相当のセキュリティ対策調査票」が届いた場合、何から着手すべきですか? ▼
まず「外部接続機器(VPN・リモートアクセス)の多要素認証(MFA)化」と「ランサムウェアから保護された隔離バックアップの有無」を確認してください。調査票の26項目のうち、大手監査担当者が最も厳格にチェックするのはこの2点です。続いて社内の端末一覧(台帳管理)と、インシデント発生時の連絡体制表を整備することで、多くの要件に客観的証跡を持って回答できます。
Q3 IT業者から「150万〜250万円のUTM(統合脅威管理)を7年リースで契約すれば★3に適合する」と営業されましたが本当ですか? ▼
明確な誤りです。SCS★3は特定の機器導入を義務付けるものではなく、アクセス権限管理、パッチ適用、バックアップ、教育、連絡体制などの「総合的な運用規程と客観的証跡」を評価する制度です。箱物機器を置くだけでは26要件の1割も満たせず、しかもTLS 1.3暗号化通信によりパケットの中身を検査できないため、高額な7年長期リースは重大な経営リスクとなります。
Q4 なぜ現在のインターネット環境(TLS 1.3普及率95%以上)において、安価なUTMのウイルス遮断機能が無効化してしまうのですか? ▼
現在のWeb通信(HTTPS)の95%以上はTLS 1.3暗号化(Forward Secrecy)されています。UTMが通信の中身を復号して検査(DPI: Deep Packet Inspection)するには、社内PC全台にUTMのルート証明書を手動配布し、ブラウザの通信を強制中継させる必要があります。安価なSoho向けUTMではこのSSL復号を行うとスループットが激減して業務が麻痺するため、初期設定でHTTPSスキャンが無効化され、暗号化パケットがそのまま素通りしているのが現場の実態です。
Q5 SCS★3の「多要素認証(MFA)」要件を満たすために、高額な専用認証サーバーの導入は必須ですか? ▼
不要です。現在利用しているクラウドサービス(Google WorkspaceやMicrosoft 365など)の標準機能であるパスキー(FIDO2 / WebAuthn)や認証アプリ(Google Authenticator等)を有効化し、VPN接続やメールへのログイン時に必須化するだけで、追加費用ゼロで完全な多要素認証要件を達成できます。
Q6 SCS★3の「バックアップの隔離・保護」要件において、外付けハードディスクへの日次コピーだけではなぜ不十分なのですか? ▼
ランサムウェアは社内ネットワークに侵入後、Windows管理者権限を奪って接続されているUSB外付けHDDや共有フォルダ(NAS)を真っ先に暗号化・消去(vssadmin delete shadows等)します。SCS★3が求めるのは、万が一社内が全滅しても復旧できる「オフライン隔離(エアギャップ)」または「暗号化管理者でも削除できない不変(イミュータブル / WORM)バックアップ」です。
Q7 経産省・IPAの「サイバーセキュリティお助け隊サービス」とSCS評価制度★3はどのような関係にありますか? ▼
お助け隊サービスは、中小企業が安価(月額数千円〜1万円台)に見守り監視、インシデント初動対応、簡易サイバー保険をパッケージ導入できる公的認定制度です。お助け隊サービスを導入することで、SCS★3の監視・ログ保管・初動体制要件の基礎を低コストで満たすことができ、IT導入補助金の加点措置も活用できます。
Q8 自社にIT専任担当者がいない中小企業が、★3適合の客観的証跡を最小限の負担で維持する方法はありますか? ▼
「手動でのExcel台帳管理」をやめ、クラウドやOSの標準機能(MDMやグループポリシー)で端末状態や更新プログラム適用状況を自動集計する「Policy-as-Code」の考え方を採用するのが近道です。また、国家資格である登録情報処理安全確保支援士(登録セキスペ)のセカンドオピニオンを活用し、年1回の適合性レビューを受けることで、取引先からの監査要求に対して信頼性の高い回答が可能です。