本文へスキップ
株式会社オープンナレッジ
株式会社オープンナレッジ Open Knowledge Inc.
経済産業省・IPA 公的制度解説 SCS評価制度 ★3(26要件)・★4 / NIST SP 800-171・CSF 2.0対応 図解7点収録(クリック拡大対応)

サプライチェーン強化に向けたセキュリティ対策評価制度(★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)の全体像
Step 1:全体像をビジュアルで直感理解

経済産業省・IPA サプライチェーン強化に向けたセキュリティ対策評価制度(SCS評価制度 ★3・★4)の全体像(写真・図表はすべてクリック/タップで拡大表示できます)

1. 基本と全体像(図解と3つの要点)

SCS評価制度(★3・★4)とは何か? なぜ今すべての取引先に求められているのか?

まずは制度ができた背景と、★3・★4の違い、そして「何から手をつければよいか」の全体像を3枚の図解で直感的に把握しましょう。

要点 1:共通のモノサシ

取引先ごとのバラバラな調査票を「★3・★4」に統一

これまで発注企業ごとに独自のエクセル調査票が送られていましたが、国が共通基準(★3=標準26要件、★4=重要領域向け高水準)を定めることで、1回の対策・評価で複数の取引先に証明できるようになります。

要点 2:★3の到達ライン

中小・中堅企業の基本目標は「★3(26要件)」

既存のSECURITY ACTION(一つ星・二つ星)を土台としつつ、一歩進んで「実際に設定されているか(多要素認証・パッチ更新・隔離バックアップ・初動手順)」を確認するのが★3です。

要点 3:過剰投資の回避

「UTMを置けば★3取得」という誤解に注意

高価なネットワーク機器をリースしても、パスワード使い回しや古いVPN放置、バックアップ未分離があれば★3は満たせず被害も防げません。OS標準機能と運用ルールの整備が主役です。

図1:サプライチェーン強化に向けたセキュリティ対策評価制度(SCS評価制度)の階層構造と★3・★4の位置づけ
サプライチェーン全体のリスクに応じた段階的評価制度(基礎宣言から★3・★4まで) 基礎段階(★1・★2相当の土台) SECURITY ACTION(一つ星・二つ星) ・情報セキュリティ5か条の実践 ・自社診断と基本方針の外部公開 ★3(標準セキュリティ:26要件) 最も多くの取引先が求める実務標準 ① 組織体制・IT資産/アカウント把握 ② 外部公開機器(VPN等)の脆弱性管理 ③ 多要素認証(MFA)と最小権限付与 ④ EDR/マルウェア防御とログ保全 ⑤ 隔離バックアップと72時間復旧訓練 対象:サプライチェーン参加企業全般 ★4(高セキュリティ水準) 重要インフラ・機密技術保有先 ・★3の全26要件の完全実装に加え、 ・24時間365日の高度な異常検知 ・ネットワークマイクロセグメント化 ・特権ID管理(PAM)と厳格監査 ・再委託先(Tier 2/3)の継続監査 ・NIST SP 800-171 相当の完全準拠 ・第三者機関による実地・技術審査 対象:基幹部品・機密設計データ取扱 なぜ今「★3」が重要なのか? 警察庁統計でランサムウェア侵入経路 の約8割が「VPN・リモート機器」です。 ★3の26要件は、まさにこの「実際の 侵入口」と「感染後の早期復旧」を ピンポイントで塞ぐ実践項目で構成 されています。
図2:被害に遭いやすい従来の状態(形だけの対策)と、SCS★3準拠の守られた状態の比較
❌ 被害に遭いやすい状態(形だけの対策) 1. 「UTMを入れたから安全」と信じている 高額リース機器を設置したままファームウェアが未更新、 VPNがID・パスワードのみで突破される 2. バックアップ用NASが社内LANに常時接続 ランサムウェア侵入時に本番サーバーと一緒に バックアップまで暗号化・削除される(約73%が復旧失敗) 3. 退職者や委託先の共有IDがそのまま残存 誰がどの端末からアクセスしたか追跡できず、 管理者権限(Admin)が日常業務で使われている 4. 取引先の調査票に「たぶん○」で回答 事故発生時に「虚偽報告(善管注意義務違反)」を問われるリスク ⭕ 守られた状態(SCS★3 26要件の実効実装) 1. 外部公開ポート最小化 + パスキー多要素認証 不要なVPNポートを閉じ、FIDO2パスキーと端末証明書で フィッシング・パスワード総当たりを入口で無力化 2. 書き換え不能(イミュータブル)バックアップ 万一管理者権限が奪われても消去できない領域に世代保存し、 年1回以上の復元テストで確実な復旧を担保 3. 1人1IDの徹底と特権アカウントの分離 入退社・異動時のアカウント棚卸しを自動化し、 操作ログを改ざん不能な状態で90日〜1年以上保全 4. 設定値と証跡に基づく客観的な適合証明 親事業者・取引先に対して自信を持って安全性を提示可能
図3:【重要ファクトチェック】「高額なUTM機器リース」だけではSCS★3の何割しかカバーできないか?
SCS★3(全26要件)の内訳と、機器設置だけでは埋まらない「22の必須領域」 ケースA:出入り口にUTM(統合脅威管理機器)を1台設置しただけの場合 約4要件のみ 残り22要件(ID管理・MFA・端末EDR・不変バックアップ・訓練・取引先管理)は未達成のまま ※ さらにUTM自体のVPN機能に脆弱性が生じた場合、パッチ未適用だと逆に「侵入口」になってしまいます。 ケースB:OS・クラウド標準機能の適正設定 + 隔離バックアップ + 15分緊急手順(SCS★3アプローチ) ガバナンス・資産管理(6) ID・多要素認証・通信(7) 端末保護・脆弱性・ログ(7) 初動対応・不変復旧(6) → 不要な5年リース契約を結ばなくても、今あるWindows/Mac標準防御、クラウドMFA、お助け隊サービス、   そして書き換え不能バックアップを組み合わせることで、最小コストで全26要件を実質的に満たせます。
SCS★3(全26要件)を4つの実務ブロックに整理し、専任担当者不在でも着実に進める手順
Step 2:現場で迷わない4ブロック実践手順

SCS★3(全26要件)を4つの実務ブロックに整理し、専任担当者不在でも着実に進める手順

Step 2:現場の実務手順と具体的な対策

SCS★3(全26要件)を4つのブロックに分け、専任担当者がいなくても進める手順

26個の要件を1つずつバラバラに読むと難しく感じますが、現場の作業に置き換えると「①台帳とルール」「②入口とID」「③端末とログ」「④緊急連絡とバックアップ」の4ブロックに整理できます。

図4:SCS★3(標準26要件)を現場の4つの実務ブロックに整理した全体マップ
ブロックA:組織体制・資産把握・委託先管理(6要件) ・経営者によるセキュリティ基本方針の策定と宣言 ・最高責任者(CISO等)と実務担当・連絡窓口の指名 ・PC・サーバー・クラウド・外部公開IPの台帳管理 ・サポート終了(EOS)OS・ソフトの計画的廃止 ・業務委託先・クラウド利用時のセキュリティ条件確認 → 「守るべき機器とデータの場所」を漏れなく把握 ブロックB:ID管理・多要素認証・境界通信防御(7要件) ・共用IDの廃止(1人1ID)と退職者IDの即日停止 ・管理者権限(Admin)の分離と最小権限の原則 ・外部からのアクセス・クラウドへの多要素認証(MFA) ・不要な外部公開ポート(RDP 3389等)の完全閉鎖 ・業務用Wi-Fiと来客用Wi-Fiのネットワーク分離 → 攻撃者の8割が使う「VPN・ID侵入」を入口で遮断 ブロックC:端末保護・脆弱性パッチ・ログ保全(7要件) ・OS・ブラウザ・Office・VPN機器の自動アップデート ・次世代アンチウイルス/EDRによる不審挙動の検知 ・メールの送信元認証(SPF/DKIM/DMARC)と添付警戒 ・USBメモリ等の私物媒体接続制限・持ち出し暗号化 ・認証ログ・操作ログ・通信ログの時刻同期と長期保存 → 万一の侵入時も横展開(ラテラルムーブメント)を阻止 ブロックD:緊急時対応・72時間連絡・不変復旧(6要件) ・「電源を切らずLANを抜く」現場初動ルールの周知 ・緊急連絡網(社内・お助け隊・取引先・警察・PPC)整備 ・3-2-1-1-0原則に基づく隔離・書き換え不能バックアップ ・バックアップからの実際の復元テスト(年1回以上) ・年1回以上のインシデント対応訓練・教育の実施記録 → 被害を受けても事業と取引先供給を止めずに復旧
図5:専任IT担当者がいない企業でも90日間でSCS★3水準へ到達する実践ロードマップ
「緊急性の高い入口とバックアップ」から先に固める90日間の優先順位 1ヶ月目:侵入口の止血(最優先) ① 外部公開機器とVPNの点検 ・使っていないVPN/RDPを即停止 ・ルーター/VPNの緊急パッチ適用 ② 多要素認証(MFA)の有効化 ・Microsoft 365 / Google Workspace  およびリモート接続へMFA強制 到達効果:侵入リスクの約8割を低減 2ヶ月目:不変バックアップと端末 ③ バックアップのネットワーク分離 ・LAN常時接続の共有フォルダを改め、  書き換え不能スナップショットを有効化 ④ 端末の自動更新とアカウント整理 ・退職者・共用アカウントの削除 ・Windows Update等の自動適用確認 到達効果:万一の感染時もデータ消失ゼロ 3ヶ月目:朝礼訓練と証跡パッケージ ⑤ 15分間の初動・連絡訓練 ・「LANを抜く→報告する」訓練と  バックアップ復元テストの実施 ⑥ 26要件の証跡整理と適合宣言 ・設定画面キャプチャやログ保存状況  をまとめ、取引先回答シートを完成 到達効果:取引先審査へいつでも即答可能 ヒント:分厚い規程集を最初から作る必要はありません。まずは1ヶ月目の「VPN点検とMFA設定」から始めましょう。

その場でわかる「SCS★3 重要5項目」セルフチェック(会員登録・送信不要)

ブラウザ内のみで計算されます

あてはまる項目にチェックを入れると、現在の到達目安と次に優先すべき対策が表示されます。

現在のチェック数:0 / 5 項目(0%) ── まずは「1. 外部接続・VPNの保護」と「2. 書き換え不能バックアップ」から確認を始めましょう。
TABLE: PROCUREMENT REALITY 悪質7年高額UTMリース vs 適正調達(オープンソース / 月額マネージド / クラウド防御)の徹底比較
比較項目 ❌ 悪質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要件すべてに確固たる証跡を提供。
Step 3:公的制度・標準規格・ガバナンス

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ガイドライン)、防衛産業、医療機器、海外取引先の要請にもそのまま応えられる共通資産になります。

図6:NIST CSF 2.0(6機能)× SCS評価制度(★3・★4)× 国内関連制度の対応マトリクス
国際標準 NIST CSF 2.0 の6機能と SCS★3(26要件)・国内公的制度の対応関係 1. 統治 (Govern) ・経営方針の宣言 ・責任者と役割分担 ・委託先リスク管理 ・規程と教育計画 SECURITY ACTION 2. 特定 (Identify) ・ハードウェア台帳 ・ソフトウェア台帳 ・重要データ分類 ・外部公開資産把握 EASM / 資産棚卸 3. 防御 (Protect) ・多要素認証(MFA) ・最小権限/特権分離 ・迅速なパッチ適用 ・通信暗号化/分離 パスキー / ゼロトラスト 4. 検知 (Detect) ・EDR/マルウェア検知 ・不正ログイン監視 ・改ざん不能ログ保存 ・24h監視アラート お助け隊監視連携 5. 対応 (Respond) ・LAN抜線初動手順 ・緊急連絡網の発動 ・証拠保全(RFC3227) ・72時間法定報告 お助け隊駆けつけ 6. 復旧 (Recover) ・不変バックアップ ・クリーン環境復元 ・年1回以上の訓練 ・再発防止の反映 3-2-1-1-0 ZFS復旧 中小企業向け公的支援策との組み合わせ方 ・基本宣言は「SECURITY ACTION(二つ星)」、平時の見守りと緊急初動は「サイバーセキュリティお助け隊サービス」、 ・そして取引先への客観的な対策証明として「SCS評価制度 ★3(26要件)」を位置づけることで、無駄のない防衛体制が完成します。
ホワイトハッカー視点による「UTM過信の盲点(TLS 1.3 / AiTM)」解剖とOpenZFS・Rust監査証明
Step 4:WHITE-HAT SCS & UTM BLIND-SPOT LAB

ホワイトハッカー視点による「UTM過信の盲点(TLS 1.3 / AiTM)」解剖とOpenZFS・Rust監査証明

Step 4:深層実装・数理モデル・ホワイトハッカー検証

ホワイトハッカー視点のEASM(外部攻撃面管理)、OpenZFS Merkle木による不変バックアップ証明、およびRust Policy-as-Code自動監査

ここからは、セキュリティ技術者・監査人向けに、人手によるエクセル自己申告の限界(設定ドリフト・形骸化)を解決するため、外部攻撃面(EASM)スキャン、FreeBSD 15.1 + OpenZFS + db01.ok.st(PostgreSQL 19)による不変証跡、およびRust 2024による26要件の自動検証(Policy-as-Code)の実装を示します。

図7:SCS★3・★4の「設定ドリフト」をゼロにする継続的技術検証(Continuous Compliance / Policy-as-Code)アーキテクチャ
「年1回のアンケート回答」から「毎日の暗号学的・自動検証」への転換 1. 外部攻撃面 (EASM) プローブ ・グローバルIPの開放ポート監査  (RDP 3389 / SMB 445 / 旧VPN) ・TLS証明書有効期限・暗号スイート ・SPF / DKIM / DMARC (p=reject) → 外から見える弱点を毎日自動点検 2. ID・端末姿勢 (Posture) 検証 ・全アカウントのFIDO2/MFA登録率 ・90日以上未ログイン休眠IDの検知 ・OSカーネル/ブラウザのパッチ鮮度 ・EDRエージェント稼働死活監視 → 特権昇格やパッチ漏れを即時検知 3. OpenZFS 不変バックアップ検証 ・256-bit Merkle木チェックサム検証 ・zfs hold + securelevel=2 ロック ・RPO(最新スナップショット経過秒) ・サンドボックス自動マウント試験 → 「確実に復元できること」を数学証明 4. Rust 2024 Policy-as-Code 評価器 × db01.ok.st(PostgreSQL 19)証跡台帳 • 26要件のテレメトリを Rust で型安全に評価し、BLAKE3 署名付き適合スナップショットを生成 • PostgreSQL 19: COPY (SELECT ... FROM scs_compliance_ledger) TO STDOUT (FORMAT JSON) • 発注元・監査人へ提出する「SCS★3 26要件適合レポート(JSON/PDF)」を改ざん不能な証跡から出力 ※ 調査票の質問項目が取引先ごとに異なっても、単一の基礎証跡(Single Source of Evidence)から自動変換できます。

1. Rust 2024による SCS★3 必須コントロールの Policy-as-Code 検証実装

下記のRustコードは、サプライチェーン攻撃で最も悪用される「外部公開危険ポートの残存」「多要素認証(MFA)の未適用」「休眠アカウントの放置」「不変バックアップの鮮度切れ(RPO超過)」を機械的に検査し、1つでも違反があれば明確な是正理由とともに不適合(Fail-Closed)を返す決定論的検証器の例です。

// Rust 2024: SCS★3 コア技術要件の自動適合判定(Policy-as-Code)
#![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形式で出力できます。

-- PostgreSQL 19 (db01.ok.st): SCS★3/★4 継続的適合証跡台帳
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箱売り(境界防御のみ)」と「SCS★3・★4 実質準拠(ID・端末・不変バックアップ)」の防御力比較
現代の主要攻撃ベクトル 攻撃の技術的メカニズム 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%保全
よくあるご質問(FAQ) 検索エンジン・AI要約向け構造化データ(Schema.org FAQPage)対応

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回の適合性レビューを受けることで、取引先からの監査要求に対して信頼性の高い回答が可能です。

あわせて読みたい関連ナレッジ・公的制度ガイド

図解・ビジュアルの拡大表示

図表内のテキストもそのまま選択・検索可能です(ベクターSVG描画) 枠外クリックまたは ESC キーで閉じます