◆監修・編集責任者
B2B EC-COLUMN
この記事のポイント
- BtoB ECのセキュリティ対策を、守る資産の定義・責任分界・構築時の実装・運用時の点検・漏えい時の手順という5つの決め事として整理します。
- 経済産業省とIPAが公表するガイドラインをもとに、構築時と運用時それぞれで確認すべき対策の枠組みを示します。
- 取引先担当者の情報は個人データであり、漏えい時の報告義務はBtoB ECでも変わらない点を、期限とあわせて解説します。
目次
- BtoB ECのセキュリティ対策は、資産の定義と運用の点検、漏えい時の手順を先に決める取り組みである
- 「BtoBだから狙われない」という思い込みが、被害実態20社の数字で崩れる
- 取引先別価格や与信枠まで、BtoB ECが守るべき資産である
- 通信の暗号化と権限設計が、構築時に満たす実装の骨格である
- 取引先アカウントの棚卸しが、運用時点検で最優先の項目である
- 決済情報を自社が保持しているかどうかで、対策範囲が変わる
- 漏えいの検知から本人通知まで、5段階と期限で対応が進む
- 予算・責任者・委託先管理・事業継続は、経営が引き受ける4つの論点である
- そのまま使えるBtoB ECセキュリティ・チェックリスト
- まとめ:対策の成否は「資産の定義」と「運用の棚卸し」で決まる
- よくある質問
BtoB ECのセキュリティ対策は、ツールの導入から始めるものではありません。守るべき資産を決め、自社とベンダーの責任範囲を分け、構築時と運用時にそれぞれ何をするかを定め、漏えいが起きたときの手順と期限をあらかじめ決めておく取り組みです。本記事では、経済産業省とIPAが公表するガイドラインを軸に、BtoB EC固有の守る資産と運用の要点を解説します。
BtoB ECのセキュリティ対策は、資産の定義と運用の点検、漏えい時の手順を先に決める取り組みである
BtoB ECのセキュリティ対策とは、取引先の情報と取引条件を守るために、構築時の実装と運用時の点検、漏えい時の手順をあらかじめ決めておく取り組みです。経済産業省とIPAが2023年3月16日に公表したガイドライン*1は、経営者向けの第1部と実務者向けの第2部からなり、実務者向けには構築時14項目・運用時7項目の対策要件が示されています*1。本記事は、この要件をBtoB ECの実務に合わせて5つの決め事へ組み替えたものです。
用語の整理:脆弱性・不正アクセス・多要素認証・責任分界
本記事で扱う用語を先に整理します。脆弱性(プログラムやシステムに存在する、悪用されうる設計上・実装上の欠陥)、不正アクセス(権限を持たない第三者がシステムへ侵入する行為)、多要素認証(パスワードに加えて別の要素で本人確認をする仕組み)、WAF(Web Application Firewall、Webアプリケーションへの攻撃を検知・遮断する仕組み)、SaaS(Software as a Service、事業者が提供するソフトウェアをネットワーク経由で利用する形態)、責任分界(システムの安全性について、どこまでを提供事業者が担い、どこからを利用企業が担うかの線引き)です。これらは以降の章で繰り返し登場します。
公表された基準がある:経済産業省・IPAのガイドライン
BtoB ECのセキュリティ対策には、公表された基準が存在します。経済産業省とIPAが2023年3月16日に公開した「ECサイト構築・運用セキュリティガイドライン」*1*2です。第1部は経営者向けにセキュリティ対策の必要性を伝える内容で、第2部は実務者向けに、構築時14項目・運用時7項目という要件の枠組みを示しています*1。対象読者は、ECサイトを新規に構築する経営者だけでなく、SaaS型サービスを利用する経営者や委託先事業者も含む広さです*2。付録として構築時・運用時のチェックリスト(Excel形式)も公開されています*2。
対策を決める工程は、導入プロセスの一部でもある
BtoB ECの導入では、要件定義の段階で非機能要件の一つとしてセキュリティ対策を検討します。導入全体の進め方は、別記事「BtoB EC 導入の進め方」で6つの工程として解説済みです。本記事では、その中でもセキュリティに絞り、設計と運用の中身を掘り下げます。
「BtoBだから狙われない」という思い込みが、被害実態20社の数字で崩れる
被害事業者20社の実態:平均漏えい約3,800件、事故対応費用は約2,400万円
IPAは、サイバー被害を受けたECサイト運営事業者20社へのヒアリング調査を実施しました*1。1社あたりの顧客情報の平均漏えい件数は約3,800件であり、事故対応費用を支出した19社では、その平均額が約2,400万円に上っています*1。この調査はECサイト全般を対象としたものであり、BtoB ECに限定した数値ではない点には注意が必要です。それでも、事故が起きた場合の影響規模を示す一次情報として参考になります。
入口は高度な攻撃ではなく、放置と未実施だった
同じ調査では、被害を受けた20社のうち75%がECサイト構築プログラムやCMS等の脆弱性を放置または最新版へのアップデートを怠っていました*1。さらに90%は、保守など運用時のセキュリティ対策を実施していませんでした*1。つまり被害の入口となったのは、高度な標的型攻撃ではなく、公表されている対策を実施していなかったことです。この事実は、対策の優先順位を考えるうえで重要な出発点になります。
取引先担当者の氏名・メールアドレスは個人データである
「BtoBだから個人情報は扱っていない」という認識は誤解です。取引先担当者の氏名・所属・メールアドレス・電話番号は個人情報保護法上の個人データにあたり、後述する漏えい等報告義務の対象になりえます*5。カード情報を保持していないECであっても、この点は変わりません。
脅威の最新版:組織を狙う攻撃の2位はサプライチェーン
IPAは2026年1月29日、「情報セキュリティ10大脅威 2026」を公表しました*3。組織編の1位はランサム攻撃による被害、2位はサプライチェーンや委託先を狙った攻撃、3位はAIの利用をめぐるサイバーリスクで、これは今回初めて選出された項目です*3。この順位は、約250名で構成する「10大脅威選考会」の投票を経て決定されています*3。BtoB ECは取引先とシステムがつながる接点であり、2位のサプライチェーン攻撃は本記事の中心的な論点になります。
取引先別価格や与信枠まで、BtoB ECが守るべき資産である
BtoB ECが守るべき資産は、個人情報やカード情報だけではありません。取引先別価格・与信枠・仕入原価・発注履歴といった取引条件は、法的な保護義務の外側にあっても、漏えいすれば取引関係そのものを損ないます。この整理はBtoC向けの解説記事には出てこない、BtoB EC固有の論点です。
| 資産 | 持ち主 | 漏えい時の影響 | 法的義務の有無 | 主な保管場所 |
|---|---|---|---|---|
| 個人データ(担当者の氏名・所属・メール・電話) | 取引先企業の担当者 | 個人情報保護委員会への報告対象になりうる*5 | あり(個人情報保護法) | 顧客管理データベース・会員情報 |
| 取引条件(取引先別価格・与信枠・仕入原価・発注履歴) | 自社 | 価格交渉力の低下、取引関係の毀損 | 法令上の報告義務の対象外だが、商取引上の重要情報 | 受発注システム・基幹システム |
| 決済情報(カード番号等) | 自社または決済代行事業者 | 不正利用の被害、報告対象になりうる*5 | 保持する場合はあり | 決済代行システムまたは自社データベース |
| 在庫・受注データ | 自社 | 誤出荷・誤請求、基幹システムへの波及 | 直接の個人データではないが管理を要する | 受発注システム・基幹システム |
個人データは、報告義務が発生しうる層である
取引先担当者の氏名・所属・メール・電話番号は、個人情報保護法上の個人データです。漏えいの内容が後述する4類型に該当すれば、個人情報保護委員会への報告義務が発生します*5。BtoBだから対象外という理解は成り立ちません。
取引条件は、法的義務の外側にある商売そのものの情報である
取引先別価格・与信枠・仕入原価・発注履歴は、法律上の個人データではありません。しかし漏えいすれば、価格戦略や与信の考え方が取引先や競合に知られてしまいます。BtoB ECにとって、この層こそ最も守る動機の強い資産だと言えるでしょう。
決済情報は「自社が持っているか」の確認が出発点になる
カード情報を自社で保持しているかどうかによって、適用される基準は変わります。BtoB取引では掛売りや請求書払いが中心の場合もあり、カード情報を保持しない構成を選べる場合もあるでしょう。まず自社が保持しているかを確認することが出発点であり、詳細は後述の決済の章で扱います。
在庫・受注データは、基幹システムへ波及する経路になる
ECで扱う在庫・受注データは、基幹システムと連携している構成が一般的です。EC側で侵害が起きると、この連携を経由して基幹システム側の業務にも影響が及ぶおそれがあるでしょう。連携の設計そのものについては、別記事「BtoB EC 基幹システム 連携」で解説しています。
通信の暗号化と権限設計が、構築時に満たす実装の骨格である
前章で守る資産を整理しました。本章で扱うのは、構築時に満たすべき実装の中身です。ガイドラインは、実務者向けに構築時14項目・運用時7項目という要件をまとめています*1。個別の項目名までは公表資料で確認できていないため、本記事では列挙せず、代表的な実装の考え方にとどめます。
代表的な実装:通信の暗号化・認証と権限設計・入力値の扱い・ログの取得
構築時に押さえる代表的な実装は、通信の暗号化、認証と権限の設計、入力値の扱い、ログの取得です。これらはガイドラインが実務者向けに示す枠組みの中核にあたります*1。どれも公開後に後付けすると手戻りが大きく、設計段階で組み込むほうが効率的です。
脆弱性の種類は公表されている:アクセス制御の欠落が影響大
IPAの「安全なウェブサイトの作り方」改訂第7版は、代表的な脆弱性としてSQLインジェクション、クロスサイト・スクリプティング、CSRF(クロスサイト・リクエスト・フォージェリ、利用者になりすまして意図しない操作を実行させる攻撃)、セッション管理の不備、アクセス制御や認可制御の欠落などを挙げています*4。攻撃手法の再現手順には立ち入りませんが、BtoB ECで特に影響が大きいのはアクセス制御や認可制御の欠落です*4。この欠落があると、他社の価格や受注情報が見えてしまうおそれがあります。
SaaS・パッケージを使う場合も、責任は自社に残る部分がある
SaaSやパッケージ製品を使えば、セキュリティはすべてベンダー任せでよいという考え方には注意が必要です。基盤側の脆弱性対応は提供事業者が担う一方、アカウントの発行・棚卸しや権限設計は利用企業側に残ります。この境界を事前に確認しておくことが、運用段階でのトラブルを防ぐ鍵です。選定の比較軸としてセキュリティを扱う視点は、別記事「受発注システム 比較 選び方」でも解説しています。
取引先アカウントの棚卸しが、運用時点検で最優先の項目である
構築が終わっても対策は完了しません。ガイドラインが示す運用時7項目のうち*1、BtoB EC特有の重みを持つのがアカウントの棚卸しです。取引先1社に対して発注者・承認者・経理など複数のユーザーが発行されるため、先方の異動や退職、取引終了の情報は自社に自動的には届きません。放置されたアカウントが構造的に溜まりやすいのは、BtoC(利用者1人につき1アカウント)にはない穴です。
運用時に優先して点検する5項目(順位根拠:影響度の大きさ)
- 取引先アカウントの棚卸し:異動・退職・取引終了の情報を反映し、不要なアカウントを止めます。
- 権限の最小化:発注者・承認者・経理で見える範囲を分け、承認権限と与信の閲覧を同一にしません。
- 更新の適用:脆弱性の放置は被害の入口になりやすいため*1、適用の担当と期限を決めます。
- ログの保全と気づく仕組み:誰がいつログを確認するか、通知先と当番を決めておきます。
- バックアップと復旧の確認:取得の有無だけでなく、実際に戻せるかを試します。
棚卸しの運用は、契機と確認者を先に決めておく
棚卸しを機能させるには、いつ・誰が確認するかを先に決めておく必要があります。棚卸しの頻度そのものについて、一般的な推奨を示す一次情報は確認できていないのが実情です。断定はせず、取引先の異動・退職・取引終了を契機とした運用として整理します。
| 契機 | 対象 | 確認者 | 記録 |
|---|---|---|---|
| 取引先から異動・退職の連絡を受けた時 | 該当ユーザーのアカウント | 発注元の管理担当者 | 停止日と対応者を台帳に記録 |
| 取引が終了した時 | 当該取引先の全アカウント | 営業担当と情報システム部門 | 停止日を台帳に記録 |
| 自社で定めた頻度での定期棚卸し | 全取引先アカウント | 情報システム部門 | 棚卸し結果を台帳で保存 |
棚卸しの運用を自社の要件に落とし込む際、権限設計と既存システムとの境界の整理は判断が分かれやすい部分です。自社の状況を整理するには、無料相談で権限設計を確認するのも一つの方法です。
決済情報を自社が保持しているかどうかで、対策範囲が変わる
掛売り・請求書払い中心なら、カード情報を保持しない構成もある
BtoB ECは掛売りや請求書払いが中心になる場合が多く、カード情報を自社で保持しない構成を選べることがあります。まず自社の決済フローでカード情報を保持しているかどうかを確認し、保持していなければ後述の基準の適用範囲も変わってきます。
カード決済を扱う場合の基準の所在
カード決済を扱う場合の対策基準は、クレジット取引セキュリティ対策協議会(事務局:一般社団法人日本クレジット協会)が「クレジットカード・セキュリティガイドライン」として公表しています*8。版数や具体的な要件までは公表資料で確認できていないため、本記事は断定を避け、基準の所在を案内するにとどめる方針です*8。カード情報を扱う場合は国際的な基準(PCI DSS)も存在しますが、要件やバージョンの詳細はここでは扱いません。実際の適用可否は、決済代行事業者や専門家に確認することをおすすめします。
決済代行事業者は「委託先」として管理対象に含める
決済を代行事業者に委ねる場合、その事業者は委託先にあたります。前述した10大脅威2位のサプライチェーンや委託先を狙った攻撃*3という観点からも、決済代行事業者は委託先管理の対象に含めておくべきでしょう。
漏えいの検知から本人通知まで、5段階と期限で対応が進む
ここまでは平常時の対策を扱いました。本章では、漏えいが起きた場合の対応を、検知から本人通知までの5段階として整理します。これらの手順は事後に決められないため、平時のうちに連絡体制と判断者を用意しておく必要があるのです。
第1段・第2段:検知して切り分け、報告要否を4類型で判定する
まず検知し、被害範囲を切り分け、システムを止めるかどうかを判断します。次に、個人情報保護委員会が示す4類型に該当するかを判定します。4類型とは、要配慮個人情報が含まれる事態、財産的被害が生じるおそれがある事態、不正の目的をもって行われたおそれがある事態、1,000人を超える漏えい等が発生した事態です*5*6。いずれかに該当すれば、報告義務が生じます。
第3段・第4段:速報は概ね3〜5日以内、確報は30日または60日以内
該当すると判定した場合、速報を概ね3〜5日以内に個人情報保護委員会へ提出します*5*6。確報は30日以内が基本で、不正の目的をもって行われたおそれがある場合は60日以内です*5。この期限は令和4年4月1日に施行された報告義務の枠組みで定められています*6。
第5段:本人への通知は「速やかに」であり、日数の定めはない
本人への通知は、事態の状況に応じて速やかに行うとされています*6。具体的な日数の定めはなく、「◯日以内に通知」という決まりはありません。取引先企業への説明とあわせて、通知方法や文面をあらかじめ準備しておくと対応が早くなるでしょう。
| 段階 | 期限 | 根拠 |
|---|---|---|
| 速報 | 発覚から概ね3〜5日以内 | 個人情報保護委員会*5*6 |
| 確報(通常) | 発覚から30日以内 | 同上*5 |
| 確報(不正の目的をもって行われたおそれがある場合) | 発覚から60日以内 | 同上*5 |
| 本人通知 | 事態の状況に応じて速やかに(日数の定めなし) | 同上*6 |
予算・責任者・委託先管理・事業継続は、経営が引き受ける4つの論点である
ここまでの対策は、担当者だけでは完結しません。経済産業省とIPAが2023年3月に発行した「サイバーセキュリティ経営ガイドラインVer3.0」は、経営者が引き受けるべき論点を示しています*7。実践のためのプラクティス集は、2023年10月31日公開の第4版が最新です*7。
予算と優先順位は、経営者向けの指針として示されている
対策の実装費用や脆弱性診断の相場について、一次情報で裏づけられる具体的な金額は確認できていません。決まり方の要因としては、守る資産の量、自社構築かSaaS利用かという方式の違い、取引先数などが挙げられます。費用の相場については、別記事「BtoB EC 費用 相場」もあわせてご確認ください。
責任者を置き、意思決定できる体制にする
対策の実施可否や優先順位を、担当者レベルの判断だけに委ねない体制が必要です。経営ガイドラインは、経営者が担うべき対応の枠組みを示しています*7。責任者を明確にしておくことで、インシデント発生時の初動判断も早くなります。
委託先の管理を契約に落とし込む
構築ベンダー・決済代行事業者・物流事業者などの委託先は、サプライチェーン攻撃の経路になりえます*3。委託先の管理範囲や報告義務を契約書に明記しておくことが、平時からの備えになります。
止まったときの事業継続を考えておく
ECが停止した場合の受注の代替手段をあらかじめ検討しておくことも、経営として決めるべき論点です。電話やFAXなど代替チャネルの位置づけを整理しておくと、停止時の混乱を抑えられるでしょう。
自社ですべてを内製で回すには、暗号化・認証設計・脆弱性対応・ログ監視といった専門知識に加え、これらを継続的に運用し続ける体制が必要です。外部パートナーに依頼する場合との違いは、内製では体制の維持そのものが継続的な負担になる点にあります。難しいからではなく、対応漏れのリスクを最小化するために、外部の知見を取り入れるという選択肢もあります。
そのまま使えるBtoB ECセキュリティ・チェックリスト
ここまでの内容を、構築時・運用時・漏えい時の3つに分けたチェックリストとして整理します。読了後に別途チェックリストを探す必要がないよう、本文だけで完結する形にしています。
構築時チェック
- 通信の暗号化を設定しているか確認します。
- 認証と権限の設計を、利用者の役割ごとに分けて設計します。
- 入力値の扱いを見直し、アクセス制御や認可制御の欠落がないか確認します*4。
- ログの取得範囲と保存期間を決めます。
- SaaS・パッケージを使う場合、ベンダーとの責任分界を文書化します。
運用時チェック
- 取引先アカウントの棚卸しを、異動・退職・取引終了を契機に実施します。
- 権限を最小化し、承認権限と与信の閲覧を分けます。
- 脆弱性の情報を確認し、更新の担当と期限を決めます*1。
- ログを定期的に確認する当番と通知先を決めます。
- バックアップから実際に復旧できるかを試します。
漏えい時チェック(期限つき)
- 検知後、被害範囲を切り分け、システムを止めるかを判断する担当者を決めておきます。
- 4類型に該当するかを判定します*5*6。
- 該当する場合、速報を概ね3〜5日以内に提出します*5。
- 確報を30日以内、不正の目的をもって行われたおそれがある場合は60日以内に提出します*5。
- 本人への通知と取引先企業への説明を、状況に応じて速やかに行います*6。
公的なチェックリストの所在
より詳細な確認に使えるのは、公的機関が公開するチェックリストです。経済産業省・IPAのガイドラインには構築時・運用時チェックリスト(Excel形式)が付録として公開されています*2。IPAの「安全なウェブサイトの作り方」にも、セキュリティ実装チェックリスト(Excel形式)が用意されています*4。
まとめ:対策の成否は「資産の定義」と「運用の棚卸し」で決まる
本稿では、BtoB ECのセキュリティ対策を、守る資産の定義から構築時・運用時の実装、漏えい時の手順までの一続きとして整理しました。要点は次の3つです。第一に、対策はツールの導入ではなく、個人データと取引条件の両方を含めた資産の定義から始まります。第二に、構築時と運用時ではガイドラインに沿った実装と点検を行い、特にアカウントの棚卸しはBtoB EC特有の重要項目です*1。第三に、漏えい時の手順と期限は事後に決められないため、平時のうちに準備しておく必要があります*5*6。この3点を押さえることが、対策の成否を分けます。
ご不明な点はお問い合わせフォームからもご連絡いただけます。
よくある質問
BtoB ECでも個人情報保護法の漏えい報告は必要ですか。
必要になる場合があります。取引先担当者の氏名・メールアドレスなどは個人データにあたり、要配慮個人情報を含む事態など4類型のいずれかに該当すれば、個人情報保護委員会への報告義務が生じます*5*6。BtoBだから対象外という理解は誤りです。
情報が漏えいした場合、何日以内に報告する必要がありますか。
速報は発覚から概ね3〜5日以内、確報は30日以内が基本です。不正の目的をもって行われたおそれがある場合、確報の期限は60日以内になります*5*6。本人への通知には具体的な日数の定めはなく、状況に応じて速やかに行うとされています*6。
SaaS型のBtoB ECを使えばセキュリティはベンダー任せでよいですか。
基盤側の対応はベンダーが担いますが、すべてを任せられるわけではありません。取引先アカウントの棚卸しや権限設計、利用者の運用ルールは利用企業側に残ります。契約前に責任分界を確認しておくとよいでしょう。
BtoB ECのセキュリティ対策は何から手を付ければよいですか。
経済産業省とIPAが公表するガイドラインと、その付録チェックリストの確認から始めるとよいでしょう*1*2。ガイドラインは構築時14項目・運用時7項目という枠組みを示しており、自社の対応状況を照らし合わせる出発点になるはずです。
取引先のアカウントはどのくらいの頻度で見直すべきですか。
頻度についての一般的な推奨を示す一次情報は確認できていないため、断定はできません。確実なのは、取引先の異動・退職・取引終了を契機に、その都度アカウントを停止する運用を組み込むことです。あわせて自社で定めた頻度での定期棚卸しを併用すると、抜けを防ぎやすくなります。
- *1 出典:独立行政法人情報処理推進機構(IPA)・経済産業省「「ECサイト構築・運用セキュリティガイドライン」を公開」(2023年3月16日)
- *2 出典:独立行政法人情報処理推進機構(IPA)「ECサイト構築・運用セキュリティガイドライン」(2023年3月16日)
- *3 出典:独立行政法人情報処理推進機構(IPA)「「情報セキュリティ10大脅威 2026」を決定」(2026年1月29日)
- *4 出典:独立行政法人情報処理推進機構(IPA)「安全なウェブサイトの作り方(改訂第7版)」
- *5 出典:個人情報保護委員会「漏えい等の対応とお役立ち資料」
- *6 出典:個人情報保護委員会「漏えい等報告・本人への通知の義務化について」(令和4年4月1日施行)
- *7 出典:経済産業省・独立行政法人情報処理推進機構(IPA)「サイバーセキュリティ経営ガイドラインVer3.0 実践のためのプラクティス集」(ガイドライン2023年3月、プラクティス集第4版2023年10月31日)
- *8 出典:クレジット取引セキュリティ対策協議会(事務局:一般社団法人日本クレジット協会)「クレジットカード・セキュリティガイドライン関連文書」
画像の出典元
- 手順のイメージ/Photo by Erik Mclean on Unsplash
- 取引先のイメージ/Photo by Ambre Estève on Unsplash
- 与信のイメージ/Photo by Markus Winkler on Unsplash
- 決済のイメージ/Photo by Towfiqu barbhuiya on Unsplash
- 管理のイメージ/Photo by Vladimir Mokry on Unsplash
- チェックリストのイメージ/Photo by Jakub Żerdzicki on Unsplash