本文へスキップ
株式会社オープンナレッジ
株式会社オープンナレッジ Open Knowledge Inc.
SCS ★3 & PCI DSS v4.0:EC, Retail & Food Makers 対象:EC通販・食品製造・菓子・飲料・アパレル・卸売・小売事業者様 執筆:株式会社オープンナレッジ 技術調査・編集室(監修:加藤 明生)

EC・小売・食品メーカー向け: 顧客カード情報保護(非保持化・Webスキミング対策)と受発注システムを守るSCS★3実践ガイド

1. 基本と全体像

この記事の要点と4つの章のご案内

なぜ「カード番号を自社で保存していないネットショップ」から情報漏洩が相次ぐのか?に関するイメージ写真
なぜ「カード番号を自社で保存していないネットショップ」から情報漏洩が相次ぐのか?
EC・小売・食品メーカーにおける「従来の環境」と「SCS★3+PCI DSS v4.0適合設計」の比較に関するイメージ写真
EC・小売・食品メーカーにおける「従来の環境」と「SCS★3+PCI DSS v4.0適合設計」の比較
EC・小売・食品メーカー向け: 顧客カード情報保護(非保持化・Webスキミング対策)と受発注システムを守るSCS★3実践ガイド の各章におけるテーマと要点一覧表
章構成 主なテーマ 要点と確認ポイント
1. 基本と全体像 なぜ「カード番号を自社で保存していないネットショップ」から情報漏洩が相次ぐのか? 国内の老舗食品メーカーや地域特産品ECサイトで相次ぐカード情報漏洩の主因は、古いPHP製カートやCMSの脆弱性を突いて決済画面を改ざんする「Webスキミング(フォームジャッキング)」です。
2. 現場での進め方と対策 EC・小売・食品メーカーにおける「従来の環境」と「SCS★3+PCI DSS v4.0適合設計」の比較 カード情報を確実に守るには、自社画面でカード番号を入力させない「リンク型(リダイレクト型)・隔離フレーム決済」への移行と、PCI DSS v4.0準拠のスクリプト改ざん検知(CSP + SRI)が不可欠です。
3. 関連する制度とルール ネットショップと食品工場・出荷現場を同時に守る「実践3ステップ」 あわせて百貨店・量販店との受発注(EDI)・顧客名簿・HACCP衛生記録の不変バックアップとなりすましメール防止(DMARC)を整えることで、2026年SCS評価制度「3」を取得できます。
4. 詳しい技術仕様としくみ 食品衛生(HACCP)の「異物混入防止」とWebセキュリティの共通点 はい、ここが近年最も被害が多発している盲点です。サーバーにカード番号を保存していなくても、ECサイトの管理画面や古いプラグインの脆弱性を突かれて『悪意あるJavaScript(数行の盗聴プログラム)』を決済ページに埋め込まれると、お客様がブラウザにカード番号とセキュリティコードを入力した瞬間に、その文字が攻撃者のサーバーへ横流しされてしまいます。これを「Webスキミング(フォームジャッキング / Magecart攻撃)」と呼びます。
第1章〜第4章では、実務チェックリスト・公的制度基準・詳しい技術仕様を確認できます。
この記事のポイント 要点まとめ
  • 01. 国内の老舗食品メーカーや地域特産品ECサイトで相次ぐカード情報漏洩の主因は、古いPHP製カートやCMSの脆弱性を突いて決済画面を改ざんする「Webスキミング(フォームジャッキング)」です。
  • 02. カード情報を確実に守るには、自社画面でカード番号を入力させない「リンク型(リダイレクト型)・隔離フレーム決済」への移行と、PCI DSS v4.0準拠のスクリプト改ざん検知(CSP + SRI)が不可欠です。
  • 03. あわせて百貨店・量販店との受発注(EDI)・顧客名簿・HACCP衛生記録の不変バックアップとなりすましメール防止(DMARC)を整えることで、2026年SCS評価制度「3」を取得できます。

01. なぜ「カード番号を自社で保存していないネットショップ」から情報漏洩が相次ぐのか?

近年、全国の有名な和洋菓子メーカー、酒造、海産物・精肉通販、アパレルショップなどの自社ECサイトで、「数千件〜数万件のクレジットカード番号とセキュリティコードが漏洩した」というお詫び公表が後を絶ちません。被害に遭った企業の多くは、クレジットカード会社が求める「非保持化(自社データベースにカード番号を保存しないこと)」をすでに実施していました。

それなのになぜカード番号が盗まれたのでしょうか。原因は、数年前に構築した動的ECパッケージ(古いPHP等で動くオープンソースカート)の未更新の脆弱性を突かれ、「お客様が注文画面でカード番号を打ち込んだ瞬間に、裏側でこっそり攻撃者のサーバーへもコピーを送信する数行のスクリプト(Webスキミング)」を仕掛けられたためです。

身近なたとえで見る「ATMのカード挿入口に取り付けられた小型カメラ(スキマー)」 銀行の金庫室がどれほど頑丈でも、店舗のATMの挿入口に悪質な小型カメラや偽のテンキー(スキマー)を貼り付けられてしまえば、お客様が暗証番号を押した瞬間に盗み見られてしまいます。Webスキミングとは、まさにネットショップの「カード番号入力欄」に目に見えない小型カメラを仕掛けられる犯罪です。これを防ぐには、「お店のページには最初からカード入力欄を置かず、決済会社の安全な専用窓口へ移動してもらう設計」にするのが最も確実です。

EC・小売・食品メーカーが直面する3つの重要データ

PCI DSS v4.0 義務化要件
要件 6.4.3 & 11.6.1

最新の国際カードセキュリティ基準(PCI DSS v4.0)では、決済ページで動くすべてのJavaScriptの正当性確認と、HTTPヘッダ・画面改ざんの自動検知が必須要件となりました。

潜伏期間と平均被害規模
平均 6ヶ月〜2年 潜伏

Webスキミングは普段の注文処理を止めずに裏でカード番号だけを盗むため、カード会社から連絡が来るまで数ヶ月以上気づかないケースが多く、早期の改ざん検知が不可欠です。

百貨店・量販店サプライチェーン
SCS ★3 + DMARC必須

大手小売や通販モールに出店・卸売を行う食品メーカーには、EDI受発注端末の保護と、ブランド名を騙るフィッシングメールを防ぐDMARC(p=quarantine/reject)設定が求められています。

ひと目でわかる構造図解:「動的CMSでの直接カード入力(危険)」と「静的エッジ配信+隔離決済(安全)」の比較

従来の危険な構成:古い動的カート(PHP/プラグイン)上でカード入力フォームを表示する方式 01 プラグインや管理画面の隙 未更新のPHPカートやFTPパスワード からサーバー内のファイルが書き換えられる 02 偽のスクリプト(盗聴器)混入 お客様がカード番号とCVCを入力した瞬間 決済会社と同時に攻撃者へもコピー送信 03 カード決済停止・調査費用発生 非保持化していてもWeb改ざんにより 数ヶ月分の顧客カード情報が漏洩 SCS★3 × PCI DSS v4.0 推奨構成:静的カタログ配信+CSP/SRI改ざん封鎖+決済代行ホスト画面分離 01 静的生成フロント (Astro等) 本番WebサーバーからPHPやDBを排除 CSP Level 3 と SHA-384 ハッシュ検証で 未承認スクリプトの実行を100%拒絶 02 隔離決済 (Hosted Checkout) カード入力はPCI DSS認定決済会社の 独立ドメイン(3Dセキュア2.0対応)で完結 自社サイトはカード情報に1バイトも触れない 03 受発注・HACCP・顧客金庫 決済完了Webhookのみ署名検証で受信 送り状・製造衛生記録は不変ZFSへ保護 SPF/DKIM/DMARCで偽メールを全体遮断

02. EC・小売・食品メーカーにおける「従来の環境」と「SCS★3+PCI DSS v4.0適合設計」の比較

消費者向けの直販(BtoC EC)と、百貨店・スーパー・問屋向けの卸売(BtoB EDI)の両方を営む事業者様が押さえるべき比較一覧です。

保護対象 漏洩・改ざん被害が起きやすい従来の構成 SCS★3・PCI DSS v4.0 準拠の推奨構成
01 クレジットカード決済画面 自社サーバー上の動的CMSページ内でカード番号を入力(JavaScript型非保持化のみ)。 決済代行会社のホスト型画面(リダイレクト方式)またはCSP+SRIで厳格保護された分離フレームを採用。
02 広告・解析タグ(サードパーティJS) 決済ページにも外部の広告タグやチャットボットを無制限に読み込み、一覧も未把握。 決済導線から不要な外部スクリプトを排除し、SHA-384ハッシュ値(SRI)で改ざんを自動ブロック。
03 自社ブランドのメール送信 SPF設定のみでDMARCが未設定(またはp=none放置)。偽の当選通知や発送メールが出回る。 SPF / DKIM / DMARC(隔離・拒否ポリシー)を完備し、顧客へのなりすましメールを遮断。
04 顧客名簿・受発注・HACCP記録 EC管理画面から誰でも全会員CSVをダウンロードでき、社内PCのデスクトップに保存。 管理画面へのパスキー(多要素認証)+IP制限、および出荷・衛生データの不変バックアップ。

03. ネットショップと食品工場・出荷現場を同時に守る「実践3ステップ」

お中元・お歳暮やギフトシーズン前に必ず点検しておきたい3つの実践ステップです。

ステップ 01:ECサイトの決済方式を点検し、「リンク型決済」または「CSP/SRI改ざん防止」を導入する

まず現在お使いのECカートが「自社サーバー上のPHP等を動かしているか」を確認します。もし古いバージョンで動いている場合や、自社ドメインの画面上にカード番号の入力枠がある場合は、決済代行会社が提供する「リンク型(Hosted Checkout)画面」へ切り替えるだけで、自社サイトの改ざんによるカード番号漏洩リスクを根本から断ち切ることができます。

ステップ 02:EC管理画面・SNS公式アカウントへの「多要素認証」と、メールの「DMARC認証」を設定する

ネットショップの店長・スタッフ全員の管理画面ログイン、およびInstagram・LINE公式アカウント等のSNS運用アカウントに必ず多要素認証(パスキー・認証アプリ)を設定します。あわせて自社ドメインのDNSに SPF / DKIM / DMARC を設定し、自社名義を騙る偽メールが顧客に届かないように保護します。

ステップ 03:百貨店・量販店EDIと工場の「製造レシピ・HACCP温度記録」を不変バックアップへ繋ぐ

食品メーカーや小売業者にとって、長年の取引先台帳・配合レシピ・アレルゲン表示マスタ・HACCP衛生管理記録は会社の命そのものです。これらを事務用メールPCから隔離された領域で管理し、ランサムウェアに暗号化されない「書き換え不能バックアップ」へ毎日自動保存することで、大手流通からのSCS★3監査にも万全の証跡を提示できます。

04. 食品衛生(HACCP)の「異物混入防止」とWebセキュリティの共通点

食品工場では、包装ラインの最後に必ず「金属検出機」と「X線異物検査機」を通し、さらに出荷ロットごとに保存サンプル(検食)を冷凍保管します。

01 Webページの「金属検出機」= SRIハッシュ検証

お客様のブラウザへ出荷されるWebページに「見知らぬ不正スクリプト(異物)」が1文字でも混入していたら、ブラウザ側で瞬時に実行を止める仕組みが Subresource Integrity(SRI)と Content Security Policy(CSP)です。

02 デジタルデータの「検食冷凍庫」= 不変スナップショット

万が一のトラブル時にも「いつの時点で何が起きたか」を正確に調べ、無傷な状態へすぐ戻せるよう、Webサイトの原本と受注データベースを書き換え不能な別領域に世代保存します。

現場で陥りやすい落とし穴と回避策(EC・小売・食品メーカー編)

落とし穴 01:「5年前に制作会社に作ってもらったECサイト」を保守契約なしで放置している

見た目が普通に動いていても、裏側のPHPやCMSプラグインのサポートが切れていると、自動巡回ボットの標的になります。【回避策】年に1回以上の脆弱性点検を行うか、管理不要のクラウドEC+静的フロントエンド構成へ移行しましょう。

落とし穴 02:ヤマト運輸・佐川急便等の送り状発行用にダウンロードした「顧客住所CSV」がPC内に溜まっている

出荷担当者のパソコンの「ダウンロード」フォルダに、過去数年分の全購入者の氏名・住所・電話番号CSVが残っていると、PC1台の感染で全件漏洩となります。【回避策】API連携でCSV出力自体をなくすか、出荷完了後に作業フォルダのCSVを毎日自動消去するスクリプトを導入してください。

落とし穴 03:キャンペーン用特設ページ(LP)のドメインを、イベント終了後に解約・放置してしまう

期間限定商品の特設ドメインを手放すと、第三者にそのドメインを取得されて詐欺サイトに悪用される(ドロップキャッチ被害)危険があります。【回避策】特設ページは新規ドメインではなく公式ドメインのサブディレクトリ(またはサブドメイン)で運用しましょう。

30秒でできる!EC・小売・食品メーカーのSCS★3&カード保護セルフチェック(3項目)

該当する項目にチェックを入れると、現在の状況と改善アドバイスが表示されます(ブラウザ内でのみ動作します)。

現在 0 / 3 項目チェック済み:お客様のカード情報と自社のブランド信用を守る3項目を確認してみましょう。

理解を深める確認クイズ(ECカード保護・Webスキミング対策編)

Q. 「うちのネットショップは決済代行会社のJavaScriptトークン方式を使っており、自社データベースにカード番号を保存していない(非保持化済み)から安全だ」という考えについて、正しいものはどれでしょうか?

選択肢 A:データベースにカード番号がなければ原則として漏洩しないため、ECサイトのソフト更新や改ざん監視は不要である クリックして解説を見る →

これは近年一番多い被害パターンです!
データベースに保存していなくても、注文画面そのものが改ざん(Webスキミング)されると、お客様がキーボードで入力した瞬間にカード番号が外へ盗まれてしまいます。

選択肢 B:注文画面の改ざんによる「Webスキミング」を防ぐため、決済会社のホスト型画面(またはCSP/SRIによるスクリプト徹底検証)と静的化を組み合わせる必要がある クリックして解説を見る →

大正解です!これが PCI DSS v4.0 および経済産業省の最新ガイドラインが求める本質的な対策です。
「保存しないこと(非保持化)」に加え、「入力画面に不正なスクリプトを1行も混ぜさせない仕組み(CSP/SRI・ホスト型決済)」を取り入れることで、初めてお客様を100%守ることができます。

選択肢 C:ネットでのカード決済をやめて、電話やメールでお客様のカード番号を聞き取ってエクセルにメモする クリックして解説を見る →

これは割賦販売法上の「カード情報の保持」にあたり、重大な違反リスクとなります!
社内のパソコンやメールでカード番号を取り扱うことは厳しく制限されています。必ず認定決済会社の安全な画面(選択肢B)を利用しましょう。

関連コラム・豆知識:Food & Commerce Heritage

老舗酒蔵や醤油蔵が守る「封印(封蝋・割り印)」と、Webブラウザの「SRI(サブリソース全体性)」

古くから日本の銘酒や醤油・薬種の樽には、蔵元を出た後に途中で水増しや異物混入がされていないことを証明するため、独特の「封印(栓の焼き印や封紙)」が施されてきました。もし封印が破れていれば、受け取った問屋はその場で異常に気づくことができます。現代のWeb技術である「SRI(Subresource Integrity:SHA-384暗号ハッシュによるスクリプト封印)」は、まさにこの蔵元の焼き印と同じ仕組みです。あらかじめ登録した指紋(ハッシュ値)と1文字でも違うプログラムは、お客様のブラウザが自動で拒否して開かないため、改ざん被害を未然に防げるのです。

ECサイト安全性診断・食品小売向けSCS★★3取得支援のご案内

現在稼働中のECサイトのWebスキミング耐性チェックから、静的エッジ高速化・SCS★★3適合証跡の整備まで、個別相談・設定確認を承っています。

場面別の実務確認ポイント

01 食品メーカー・小売・通販会社の経営者様へ

1件起きれば数千万円の被害とブランド毀損につながる「ECカード情報漏洩」を根絶し、百貨店・大手流通のSCS★★3基準を満たす全体像がわかります。

02 EC店長・Webマーケティング・広報担当の方へ

広告タグや解析ツールを入れる際の注意点と、自社のブランド名を騙る「偽セールサイト・偽クーポンメール」からお客様を守る方法(第2章)を解説しています。

03 受発注(EDI)・品質管理(HACCP)・出荷担当の方へ

お中元・お歳暮・年末年始の繁忙期に注文処理や送り状発行が止まらないためのバックアップ体制が確認できます。

04 Web制作会社・EC基盤エンジニアの方へ

技術仕様セクションにて、PCI DSS v4.0 要件 6.4.3 / 11.6.1 に対応する CSP Level 3 + SRI (SHA-384) 検証および静的エッジ決済のRust実装を詳解しています。

技術仕様・実装解説(PCI DSS v4.0 CSP LEVEL 3 & SRI MANIFEST VERIFIER) 4. 詳しい技術仕様としくみ
Rust 2024(PCI DSS v4.0 Req 6.4.3 & 11.6.1)

PCI DSS v4.0 要件 6.4.3 / 11.6.1 に基づく決済ページのスクリプト全体性検証(CSP Level 3 + SRI SHA-384)とWebスキミング(Magecart)の静的エッジ封じ込め

本モノグラフでは、EC・小売事業者が割賦販売法(クレジットカード・セキュリティガイドライン)および経済産業省・IPA「SCS評価制度(★3)」に準拠し、クライアントサイドのフォームジャッキング(Magecart)を構造的に無力化するため、(1) W3C CSP Level 3 strict-dynamic + Nonce と W3C Subresource Integrity (SRI) SHA-384 ハッシュ束縛、(2) PCI DSS v4.0 要件 11.6.1 が求める決済ページのHTTPレスポンスヘッダおよびDOMスクリプトインベントリの連続改ざん検知、および (3) Astro 静的生成と署名付き決済セッションを用いたサーバーサイドRCE消滅モデルを提示する。

Compliance Standard
PCI DSS v4.0 (6.4.3 / 11.6.1)
Script Integrity
W3C SRI sha384- Base64 Pin
Execution Policy
CSP Level 3 default-src 'none'
Origin Attack Surface
Zero PHP / Static Edge Only
1. 設計仕様・数理モデル(Client-Side Skimming Threat Model, CSP Level 3 Formal Policy & PCI DSS v4.0 Tamper Telemetry)

01. なぜ「サーバー側でのカード非保持化(JavaScriptトークン方式)」だけでは Magecart を防げないのか: 従来のJavaScriptトークン型決済では、ECサイト自身のHTMLドキュメント内に <input id="card-number"> 要素が存在し、決済代行会社のJSライブラリがDOMから値を読み取ってトークン化する。しかし、同一オリジン(Same-Origin)上で動作する任意のJavaScriptは DOM ツリーに対する厳密な読み取り権限(HTMLInputElement.value や addEventListener('blur', ...))を持つため、動的CMS(EC-CUBE旧系 / WordPress WooCommerce等)のRCE脆弱性やサードパーティタグの侵害によって1行でも不正スクリプトが混入すれば、トークン化される前の平文PAN・CVV・有効期限が外部C2サーバーへ fetch() / navigator.sendBeacon() 等で流出する。

02. PCI DSS v4.0 要件 6.4.3 および 11.6.1 の厳密な充足条件: PCI DSS v4.0 要件 6.4.3 は決済ページに読み込まれる全スクリプトの「承認・全体性保証・インベントリ台帳化」を要求し、要件 11.6.1 は決済ページのHTTPヘッダおよびスクリプト内容の未承認変更を検知する機構を要求する。これを数学的に満たすため、決済・注文導線のレスポンスには厳格な Content-Security-Policy ヘッダ(default-src 'self'; script-src 'self' https://js.stripe.com; connect-src 'self' https://api.stripe.com; object-src 'none'; base-uri 'none'; frame-ancestors 'none';)を強制付与し、外部への不正データ送信(Exfiltration)そのものをブラウザのネットワーク層で遮断する。同時にすべての <script> タグに対して事前計算された SHA-384 ダイジェスト(integrity="sha384-...")とスクリプト承認マニフェストの一致をビルド時・配信時の双方で検証する。

03. 動的CMSの廃止と「Astro静的生成+署名付きHosted Checkout」への転換: そもそもWebサーバー上でリクエストごとにスクリプト言語(PHP等)を実行する構造自体が、ファイル改ざんの温床となる。商品一覧・カート画面を読み出し専用の静的ファイル(OpenZFS readonly=on マウント)として配信し、決済時のみ Rust API が商品単価マスタと数量を照合して HMAC 署名付き Checkout Session を発行する設計により、フロントエンド改ざんと金額改ざんの双方を構造的に排除する。

2. パラメータ・構成仕様(PCI DSS v4.0 & SCS ★3 E-Commerce Technical Control Matrix)
Standard Ref Attack Vector Enforced Technical Control Continuous Probe Pass Condition
PCI DSS v4.0 6.4.3 Unauthorized 3rd-party JS injection Script Inventory Manifest + SRI sha384 100% of script tags match approved SRI digest
PCI DSS v4.0 11.6.1 HTTP Header / DOM Skimmer Tampering Synthetic Headless DOM & CSP Header Diff Probe 0 unapproved connect-src / script-src origins
METI Credit Guideline Cardholder Data Environment (CDE) Exposure Hosted Redirect / Isolated Cross-Origin Iframe 0 raw PAN/CVV input elements on merchant origin
SCS ★3 Email & Order DB Brand Phishing & Ransomware on Order CSV DMARC p=reject + OpenZFS Immutable Order Vault DMARC pass == 100% / 0 plaintext CSV on desktop
3. 実装コード・設定仕様(Production Rust 2024 Implementation (crates/ok-ec-guard/src/pci_script_auditor.rs)) Zero-Unsafe:PCI DSS v4.0 6.4.3 / 11.6.1 Script & CSP Header Verifier
#![forbid(unsafe_code)]

use std::collections::BTreeMap;

#[derive(Debug, Clone, PartialEq, Eq)]
pub struct ScriptTagDescriptor {
    pub src_url: String,
    pub sri_integrity_attr: Option<String>,
}

#[derive(Debug, Clone, PartialEq, Eq)]
pub struct CheckoutPageTelemetry {
    pub csp_header_value: String,
    pub has_raw_pan_input_in_merchant_dom: bool,
    pub discovered_scripts: Vec<ScriptTagDescriptor>,
}

#[derive(Debug, Clone, PartialEq, Eq)]
pub enum PciSkimmingAuditError {
    RawCardInputFoundOnMerchantOrigin,
    MissingMandatoryCspDirective { directive: &'static str },
    UnsafeInlineOrEvalPermittedInCsp,
    UnapprovedScriptSource { src: String },
    MissingOrMismatchedSriDigest { src: String },
}

/// Audits a checkout page telemetry snapshot against PCI DSS v4.0 Requirements 6.4.3 & 11.6.1
/// and METI Credit Card Security Guidelines to prevent Magecart web skimming.
pub fn verify_checkout_page_integrity(
    telemetry: &CheckoutPageTelemetry,
    approved_script_sri_manifest: &BTreeMap<String, String>,
) -> Result<usize, PciSkimmingAuditError> {
    if telemetry.has_raw_pan_input_in_merchant_dom {
        return Err(PciSkimmingAuditError::RawCardInputFoundOnMerchantOrigin);
    }

    let csp = telemetry.csp_header_value.as_str();
    let required_directives = [
        "default-src",
        "script-src",
        "connect-src",
        "object-src 'none'",
        "base-uri 'none'",
        "frame-ancestors 'none'",
    ];

    for dir in required_directives {
        if !csp.contains(dir) {
            return Err(PciSkimmingAuditError::MissingMandatoryCspDirective { directive: dir });
        }
    }

    if csp.contains("'unsafe-inline'") || csp.contains("'unsafe-eval'") {
        return Err(PciSkimmingAuditError::UnsafeInlineOrEvalPermittedInCsp);
    }

    for script in &telemetry.discovered_scripts {
        let Some(expected_sri) = approved_script_sri_manifest.get(&script.src_url) else {
            return Err(PciSkimmingAuditError::UnapprovedScriptSource {
                src: script.src_url.clone(),
            });
        };

        match &script.sri_integrity_attr {
            Some(actual_sri) if actual_sri == expected_sri && actual_sri.starts_with("sha384-") => {}
            _ => {
                return Err(PciSkimmingAuditError::MissingOrMismatchedSriDigest {
                    src: script.src_url.clone(),
                });
            }
        }
    }

    Ok(telemetry.discovered_scripts.len())
}
検証環境・運用について: 当社では、食品メーカー・地域特産品EC・小売事業者様向けに、古いPHP製ECカートからの安全な静的フロントエンド移行(Astro + 隔離決済)およびSCS★★3取得・HACCP記録保護を一貫支援しています。
EC安全性・SCS★3相談へ
ご質問・公的制度の活用に関するお問い合わせ窓口

掲載資料に関するご質問・公的制度活用のご案内

本ページの図解や解説内容に関するご質問、経済産業省「SCS評価制度」やIPA「SECURITY ACTION・サイバーセキュリティお助け隊サービス」等の公的制度の確認方法について、落ち着いた参考窓口としてご案内しております。売り込みや営業連絡は一切行いませんので、社内勉強会やご家庭での確認資料としてご自由にご活用ください。

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

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