EDIとサプライチェーン攻撃の関係
EDI（Electronic Data Interchange：電子データ交換）とは、企業間で受発注、請求、出荷、在庫などのビジネスデータを、標準化されたフォーマットで電子的にやり取りする仕組みです。製造業、流通業、小売業など、多くの業界でサプライチェーンの中核インフラとして利用されています。
EDIシステムはサプライチェーン攻撃の重要な標的となります。その理由は、EDIが企業間の「信頼された接続」を提供しているからです。攻撃者がEDIシステムを侵害すれば、その信頼関係を悪用して、取引先企業への攻撃や不正な取引データの送信が可能になります。
- EDIの役割
- 企業間の受発注、請求書、出荷通知、在庫情報などを電子的に交換。サプライチェーンの効率化と自動化を実現。
- サプライチェーン攻撃における位置づけ
- EDIは企業間の「信頼された接続」を提供。この信頼関係が悪用されると、取引先全体に被害が波及する可能性がある。
| EDIの特徴 | ビジネス上のメリット | セキュリティリスク |
|---|---|---|
| 企業間の自動連携 | 業務効率化 | 不正データの自動処理 |
| 信頼された接続 | 取引の安定性 | 信頼関係の悪用 |
| 基幹システムとの連携 | データ一元管理 | 侵入経路としての悪用 |
| 長期間の稼働 | 安定したサービス | レガシーシステムの脆弱性 |
ビジネスサプライチェーン攻撃では、取引関係を悪用した攻撃が解説されています。EDIはまさにその攻撃経路となり得ます。
EDI経由の攻撃手口
EDIシステムを経由した攻撃には、様々な手口があります。
不正データ送信
EDI接続を悪用して、偽装された取引データを送信する攻撃です。
- 偽装された発注データ
- 取引先を装った不正な発注データを送信。自動処理されると、意図しない商品の発送や支払いが発生する可能性がある。
- 請求書詐欺
- 偽の請求データを送信し、不正な支払いを誘発。ビジネスメール詐欺（BEC）のEDI版とも言える。
- データの改ざん
- 正規の取引データを傍受し、金額、数量、送付先などを改ざんして再送信。
これらの攻撃は、EDI接続が「信頼された」ものとして自動処理されることを悪用しています。
接続経路の悪用
EDI接続経路を利用して、内部ネットワークへ侵入する攻撃です。
- VPN/専用線の脆弱性：EDI接続に使用するVPNや専用線の脆弱性を悪用して侵入
- 認証情報の窃取：EDI接続に使用する認証情報をフィッシング詐欺やパスワードリスト攻撃で窃取
- 信頼関係の悪用：取引先のネットワークが侵害された場合、そこを踏み台にして自社ネットワークに侵入
トヨタ自動車のサプライヤー（小島プレス工業）が攻撃を受けた2022年の事例では、サプライチェーンの接続関係が攻撃の影響拡大に関係していたと報告されています。
EDIシステムの脆弱性
EDIソフトウェア自体の脆弱性を突いた攻撃です。
- レガシーシステムのリスク
- 長年稼働しているEDIシステムは、古いソフトウェアやOSを使用していることが多い。サポート終了（EoL/EoS）製品には、脆弱性が修正されないリスクがある。
- パッチ未適用の問題
- 24時間365日稼働が求められるEDIシステムでは、パッチ適用のためのダウンタイム確保が困難。結果として脆弱性が放置されやすい。
- 設定不備
- デフォルト設定のまま運用、不要なサービスの有効化、過剰な権限付与などの設定不備が攻撃の足がかりとなる。
ランサムウェア攻撃者は、このような脆弱性を悪用してEDIシステムを含む基幹システムを暗号化し、身代金を要求することがあります。
アクセス制御の強化
EDIセキュリティの基本は、適切なアクセス制御です。
接続先の認証
EDI接続先が正規の取引先であることを確認する仕組みが必要です。
- 証明書ベースの認証
- クライアント証明書を使用して接続元を認証。なりすましを防止。PKI（公開鍵基盤）の活用。
- 認証キー・APIキー
- 事前に共有した認証キーを使用して接続を認証。定期的なキーローテーションが重要。
- 多要素認証（MFA）の導入
- Web-EDIなど対話型の接続では、多要素認証の導入を検討。パスワードだけでなく、追加の認証要素を要求。
| 認証方式 | 特徴 | 適用場面 |
|---|---|---|
| 証明書認証 | 高いセキュリティ、PKI必要 | 大規模EDI、B2B接続 |
| APIキー | 実装が容易、管理が必要 | API連携、クラウドEDI |
| ID/パスワード+MFA | 対話型に適する | Web-EDI |
IPアドレス制限
接続元IPアドレスを制限することで、不正な接続を防止できます。
- 許可されたIPアドレス（取引先のグローバルIP）のみ接続を許可
- ファイアウォールでEDIポートへのアクセスを制限
- IPアドレスの変更時は事前に連絡を受ける運用ルールを確立
ただし、IPアドレス制限だけでは不十分です。取引先のネットワークが侵害された場合、正規のIPアドレスから不正アクセスが行われる可能性があります。
権限管理
EDIシステムへのアクセス権限を最小権限の原則に基づいて管理します。
- 役割ベースのアクセス制御（RBAC）
- ユーザーの役割（発注担当、経理担当、システム管理者等）に応じて、必要最小限の権限を付与。
- 職務分掌
- 発注と承認、入金確認と出金処理など、相反する権限を同一人物に与えない。不正の機会を減らす。
- 定期的な権限見直し
- 人事異動、退職時に速やかに権限を削除。定期的な棚卸しで不要な権限を特定。
通信の暗号化
EDI通信は、暗号化によって盗聴や改ざんから保護する必要があります。
- TLS（Transport Layer Security）
- 最も一般的な通信暗号化方式。TLS 1.2以上を使用し、古いバージョン（SSL、TLS 1.0/1.1）は無効化すること。Web-EDI、AS2、REST APIなどで広く使用。
- VPN（Virtual Private Network）
- インターネット上に暗号化されたトンネルを構築。拠点間接続やリモートアクセスに使用。IPsec VPNやSSL VPNが一般的。
- AS2（Applicability Statement 2）
- EDI向けに設計されたセキュアなプロトコル。HTTP/HTTPS上で動作し、暗号化、電子署名、受領確認（MDN）をサポート。大手小売業者との取引で広く使用。
- SFTP（SSH File Transfer Protocol）
- SSHプロトコル上でファイル転送を行う。FTPの代替として、ファイルベースのEDIで使用。暗号化と認証を提供。
| 暗号化方式 | 特徴 | 主な用途 |
|---|---|---|
| TLS | 広く普及、実装容易 | Web-EDI、API連携 |
| VPN | ネットワークレベル保護 | 拠点間接続、専用線代替 |
| AS2 | EDI特化、受領確認 | 大手小売・製造業 |
| SFTP | ファイル転送向け | バッチ処理、ファイル連携 |
中間者攻撃（MITM）を防ぐため、証明書の検証を適切に行うことが重要です。
データの検証
受信したEDIデータを検証することで、不正なデータの処理を防止できます。
形式チェック
受信データが期待される形式に従っているかを検証します。
- スキーマ検証
- EDIFACTやX12などのEDI標準に準拠しているか、XMLスキーマやJSONスキーマに適合しているかを検証。
- 必須項目チェック
- 必須フィールドが存在し、適切な値が設定されているかを確認。
- データ型・範囲チェック
- 数値フィールドに文字が含まれていないか、日付が有効な範囲か、金額が妥当な範囲かなどを検証。
形式チェックは、攻撃だけでなく、システム障害やデータ入力ミスによる問題も防止できます。
異常検知
通常と異なるパターンを検出し、不正な取引を早期に発見します。
- 急激な取引量の変化：通常の数倍の発注、異常に高額な取引など
- 不審な取引先からのデータ：新規取引先、休眠取引先からの突然の大量発注
- 通常と異なる時間帯：深夜や休日の異常な取引
- 送付先・振込先の変更：通常と異なる宛先への送付・振込指示
これらの異常検知は、ビジネスメール詐欺（BEC）対策としても有効です。
電子署名
データの完全性と送信元の真正性を確認するため、電子署名を活用します。
- 電子署名の目的
- データが改ざんされていないこと（完全性）、正規の送信元からのデータであること（真正性）を検証。
- AS2での電子署名
- AS2プロトコルでは、メッセージへの電子署名が標準でサポートされている。送信側が秘密鍵で署名し、受信側が公開鍵で検証。
EDIシステムのセキュリティ監査
EDIシステムのセキュリティを維持するには、定期的な監査と見直しが必要です。
| 監査項目 | 確認内容 | 頻度 |
|---|---|---|
| アクセスログ | 不審なアクセス、失敗した認証 | 日次/週次 |
| 権限設定 | 不要な権限、過剰な権限 | 四半期 |
| 脆弱性 | パッチ適用状況、設定不備 | 月次/四半期 |
| 暗号化設定 | TLSバージョン、証明書有効期限 | 月次 |
| 取引先接続 | 不要な接続、セキュリティ要件 | 年次 |
- アクセスログの監視
- EDIシステムへのアクセスログを定期的に確認。不審なアクセスパターン、認証失敗の急増などを検知。SIEMとの連携も有効。
- 取引先との連携
- 取引先のセキュリティ状況も影響する。取引先管理の一環として、EDI接続先のセキュリティ評価を実施。セキュリティインシデント発生時の連絡体制を確認。
- ペネトレーションテスト
- 外部の専門家によるEDIシステムの脆弱性診断。実際の攻撃を模擬して、セキュリティホールを発見。
レガシーEDIとWeb-EDI
EDIシステムには、従来型のレガシーEDIと、WebブラウザベースのWeb-EDIがあります。それぞれにセキュリティ上の特徴があります。
| 項目 | レガシーEDI | Web-EDI |
|---|---|---|
| 接続方式 | 専用線、VAN、VPN | インターネット（HTTPS） |
| 初期コスト | 高い | 低い |
| セキュリティ | 閉域網で高い | インターネット経由のリスク |
| 柔軟性 | 変更が困難 | 変更が容易 |
| レガシーリスク | 古いシステムの脆弱性 | 比較的新しい |
- レガシーEDIのセキュリティ課題
- 専用線やVANを使用するため、外部からの直接攻撃には強い。しかし、古いソフトウェア、サポート終了OS、パッチ未適用などのリスクがある。内部犯行や取引先経由の攻撃には脆弱な場合がある。
- Web-EDIのセキュリティ課題
- インターネット経由のため、フィッシング詐欺、XSS、CSRFなどWebアプリケーションの脆弱性リスクがある。一方、TLS暗号化やMFAなど、現代的なセキュリティ対策を適用しやすい。
どちらの方式でも、適切なセキュリティ対策を講じることが重要です。レガシーEDIでも定期的な脆弱性診断とパッチ適用を、Web-EDIでもWebアプリケーションセキュリティのベストプラクティスを適用しましょう。
中小企業のEDIセキュリティ
中小企業にとって、EDIセキュリティへの投資は負担になることがあります。しかし、大手取引先からセキュリティ要件を求められるケースも増えています。
- 限られたリソースでの対策
- 優先順位を付けて、リスクの高い領域から対策を実施。まずは基本的な認証強化、暗号化、ログ取得から始める。
- クラウドEDIサービスの活用
- 自社でEDIシステムを構築・運用する代わりに、クラウドEDIサービスを利用。セキュリティ対策の多くをサービス提供者に委託できる。
- 取引先からの要求への対応
- 大手取引先からセキュリティ要件を提示されることがある。要件を確認し、段階的に対応計画を立てる。必要に応じて専門家に相談。
- クラウドEDIサービス（EDIプラットフォーム）の利用を検討
- IPA（情報処理推進機構）のセキュリティガイドラインを参照
- 業界団体のセキュリティ基準を確認
関連する攻撃手法
EDI関連で注意すべき攻撃手法を紹介します。
| 攻撃手法 | EDI関連での影響 |
|---|---|
| ビジネスサプライチェーン攻撃 | 取引関係を悪用した攻撃全般 |
| ビジネスメール詐欺（BEC） | EDIと組み合わせた請求詐欺 |
| 不正アクセス | EDIシステムへの侵入 |
| 中間者攻撃（MITM） | EDI通信の傍受・改ざん |
| ランサムウェア | EDIシステムの暗号化による業務停止 |
| 内部不正 | EDIデータの不正操作 |
| EoL/EoSの攻撃 | サポート終了EDIシステムの脆弱性 |
よくある質問
- Q: 専用線を使っていれば安全ですか？
- A: 専用線はインターネット経由の攻撃には強いですが、完全に安全とは言えません。取引先のネットワークが侵害された場合、専用線経由で攻撃が波及する可能性があります。また、内部犯行や物理的なアクセスによる攻撃には脆弱です。専用線であっても、認証、暗号化、ログ監視などの対策は必要です。
- Q: Web-EDIはセキュリティが弱いですか？
- A: 一概にそうとは言えません。Web-EDIはインターネット経由のため、フィッシングやWebアプリケーションの脆弱性などのリスクがありますが、適切に設計・運用されていれば十分なセキュリティを確保できます。TLS 1.2以上の暗号化、多要素認証、WAF（Webアプリケーションファイアウォール）の導入、定期的な脆弱性診断などを実施しましょう。
- Q: 取引先のセキュリティレベルが低い場合はどうすべきですか？
- A: 取引先のセキュリティ状況は、自社のリスクにも影響します。まず、取引先のセキュリティ状況を評価し、リスクを把握してください。リスクが高い場合は、EDI接続の範囲を限定する、追加の認証を要求する、セキュリティ改善を要請する、といった対応を検討します。契約条項にセキュリティ要件を含めることも有効です。詳しくはサードパーティリスク管理をご参照ください。
- Q: EDIシステムの更新は必要ですか？
- A: はい、定期的な更新が必要です。レガシーEDIシステムは、古いOSやソフトウェアを使用していることが多く、サポート終了製品には脆弱性が修正されないリスクがあります。完全なシステム更新が困難な場合でも、セキュリティパッチの適用、暗号化方式の更新、認証の強化などは実施すべきです。更新計画を立て、段階的に対応しましょう。
- Q: EDIデータのバックアップは必要ですか？
- A: 必要です。ランサムウェア攻撃やシステム障害に備えて、EDIデータの定期的なバックアップを取得してください。バックアップは、本番システムとは別の場所（オフサイト、クラウド等）に保管し、定期的にリストアテストを実施して復旧可能性を確認しましょう。バックアップの破壊・改ざん対策も重要です。
まとめ
本記事では、EDI（電子データ交換）におけるサプライチェーン攻撃対策について解説しました。主なポイントは以下の通りです。
- EDIはサプライチェーンの中核を担い、企業間の「信頼された接続」を提供するが、攻撃の標的にもなる
- EDI経由の攻撃には、不正データ送信、接続経路の悪用、システムの脆弱性悪用がある
- アクセス制御では、証明書認証、IPアドレス制限、最小権限の原則を適用
- 通信の暗号化では、TLS 1.2以上、VPN、AS2、SFTPなどを適切に選択
- データの検証では、形式チェック、異常検知、電子署名で不正データを防止
- セキュリティ監査を定期的に実施し、脆弱性や設定不備を発見・修正
- 中小企業はクラウドEDIサービスの活用も検討
次のステップとして、サプライチェーンリスクを体系的に分析する手法を解説したサプライチェーン攻撃の脅威モデリング｜攻撃面・依存関係の分析手法をご参照ください。
技術者向けカテゴリの全体像については、サプライチェーン攻撃の技術対策｜SBOM・CI/CD・OSS・EDIをご覧ください。
サプライチェーン攻撃の総合的な理解には、サプライチェーン攻撃とは｜仕組み・事例・対策を初心者にもわかりやすく解説もあわせてご参照ください。
重要なお知らせ
- 本記事は一般的な情報提供を目的としており、個別の状況に対する助言ではありません。
- 実際にサイバー攻撃の被害に遭われた場合は、警察（#9110）やIPA（03-5978-7509）などの公的機関にご相談ください。
- 法的な対応が必要な場合は、弁護士などの専門家にご相談ください。
- 記載内容は作成時点の情報であり、攻撃手法は日々進化している可能性があります。
サプライチェーン攻撃 完全ガイド ナビゲーション
総合ガイド
目的別に探す
役職・立場別に探す
技術対策（技術者向け）
- SBOM
- CI/CD・SLSA
- OSSセキュリティ
- npmセキュリティ
- EDIセキュリティ（現在のページ）
- 脅威モデリング
業種別に探す
人気のページ
更新履歴
- 初稿公開
