2026年2月6日未明、米フロリダ州に本社を置く決済技術プロバイダーBridgePay Network Solutionsがランサムウェア攻撃を受け、Gateway API・仮想端末・ホスティング決済ページを含む全サービスが機能不全に陥った。同社は月間約4,000万件のトランザクションを処理しており、攻撃の影響は全米の小売店・飲食店・自治体の決済窓口に波及した。本稿では、この事例を技術的に分析し、決済インフラが備えるべきレジリエンス設計の要件を論じる。

事件の経緯 ── 3時間で判明したランサムウェアの痕跡

BridgePayの公式発表によれば、2026年2月6日午前3時29分（EST）に同社のシステムでパフォーマンスの低下が検知された。その約3時間後の午前6時34分、社内調査と外部専門家の分析により、サイバーセキュリティ・インシデントであることが確認された。同日午後7時8分、BridgePayは攻撃がランサムウェアによるものであると公式に発表した。

攻撃により停止したサービスは多岐にわたる。決済ゲートウェイAPIであるBridgeCommとPayGuardian Cloud API、加盟店向けの仮想端末・レポーティングシステムであるMyBridgePay、ホスティング決済ページ、さらにPathwayLinkゲートウェイとボーディングポータルが一斉に機能停止した。単一のコンポーネント障害ではなく、基盤全体が影響を受けた「全面停止」であったことが、この事件の深刻さを物語っている。

BridgePayはFBIおよび米国シークレットサービスと連携し、感染システムの隔離とクリーンバックアップからの復旧作業を開始した。しかし、2月9日時点でも完全復旧の見通しは示されず、同社は復旧が「長期にわたるプロセスになる」との見解を示した。なお、同日までにいずれのランサムウェアグループも犯行声明を出しておらず、使用されたランサムウェアの種類や初期侵入経路も公表されていない。

影響範囲 ── 自治体から飲食店まで波及した決済停止

BridgePayは30以上の国内外のプロセッサー、5つのACHプロバイダー、16のギフト・ロイヤルティプログラムへの接続を提供する中間レイヤーとして機能している。この「ハブ」としての性質が、攻撃の影響を増幅させる構造的要因となった。

加盟店への影響は即座に現れた。全米各地のレストランや小売店がカード決済を受け付けられなくなり、「現金のみ」での営業を余儀なくされた。フロリダ州パームベイ市やテキサス州フリスコ市では、水道料金などのオンライン請求書支払いポータルが停止し、住民は窓口での対面支払いを求められた。Lightspeed CommerceやThriftTracなどのPOS統合ソリューションにも障害が波及している。

BridgePayの年間売上高は約750万ドル、従業員数は約23名と報じられており、決済インフラ企業としては中規模である。しかし、その接続先の多さと処理件数の規模から、障害の影響は同社の企業規模とは不釣り合いに大きなものとなった。これは決済エコシステムにおける「SPOF（Single Point of Failure）」リスクの典型例である。

技術的分析 ── なぜ「全面停止」に至ったのか

BridgePayのアーキテクチャ詳細は公開されていないが、全サービスが同時に停止した事実から、いくつかの構造的課題を推定できる。第一に、Gateway API、仮想端末、ホスティング決済ページが共通のインフラストラクチャ上で稼働していた可能性が高い。共有ネットワークセグメントや共通の認証基盤が存在し、ランサムウェアの横展開（ラテラルムーブメント）を許容する構成であったと考えられる。

第二に、復旧が長期化していることから、バックアップシステム自体が攻撃の影響を受けたか、あるいはバックアップからの復元手順が十分にテストされていなかった可能性がある。PCI DSS準拠の決済事業者であっても、ランサムウェアを想定した復旧訓練が不十分なケースは少なくない。

第三に、BridgePayのフォレンジック調査では「決済カードデータの漏洩はない」との初期見解が示されている。攻撃者がアクセスしたファイルは暗号化されており、利用可能なデータの流出証拠はないとされる。これはPCI DSSにおけるカード会員データの暗号化要件（要件3）が機能していた可能性を示唆するが、運用基盤そのものの防御には十分でなかったことを意味する。

レジリエンス設計 ── 決済インフラに求められる5つの原則

BridgePay事件は、決済インフラのレジリエンス設計に関して重要な教訓を提供している。以下の5つの原則は、この事例から導出される設計要件である。

1. マルチパス決済ルーティング：加盟店は単一のゲートウェイに依存せず、複数の決済経路を確保すべきである。プライマリゲートウェイの障害時に自動的にセカンダリゲートウェイへフェイルオーバーするルーティング機構を実装することで、単一障害点を排除できる。クラウドネイティブなロードバランサーやAPIゲートウェイレイヤーでの冗長化が有効である。

2. ネットワークセグメンテーションとマイクロセグメンテーション：決済処理系、管理系、レポーティング系を厳格にネットワーク分離し、ゼロトラスト・アーキテクチャを適用する。BridgePayの事例では全サービスが同時停止したが、適切なセグメンテーションがあれば、少なくとも一部サービスの継続が可能であった。

3. イミュータブル・バックアップとリカバリ訓練：バックアップデータは書き換え不可能な形式（イミュータブルストレージ）で保管し、ランサムウェアによる暗号化から保護する。加えて、バックアップからの完全復旧を定期的に訓練し、RTO（目標復旧時間）を実測値として把握しておく必要がある。

4. 段階的復旧計画（Tiered Recovery Plan）：全サービスの同時復旧ではなく、ビジネスインパクト分析（BIA）に基づいて復旧優先順位を定義する。決済トランザクション処理を最優先とし、レポーティングや管理機能は後続フェーズで復旧する段階的アプローチが現実的である。BridgePayが「安全かつ責任ある方法で復旧を進める」と述べた姿勢は正しいが、事前に段階的復旧の手順書が整備されていれば、復旧の見通しをより早期に示せたはずである。

5. サプライチェーン・リスクの可視化：加盟店とアクワイアラーは、自社の決済フローにおけるサードパーティ依存関係を継続的に監視・評価すべきである。BridgePayのような中間レイヤーが停止した場合の代替手段を事前に確保し、定期的に切り替え訓練を実施することが求められる。

業界への示唆 ── 金融インフラ攻撃の構造的リスク

BridgePay事件は、2023年のNCRランサムウェア攻撃（レストランPOSシステムに影響）に続く、決済インフラを標的としたランサムウェア攻撃の事例である。フィンテック企業へのランサムウェア攻撃は過去1年で50%以上増加しているとされ、この傾向は今後も続くと予測される。

攻撃者にとって決済インフラは高価値の標的である。データ窃取による直接的な金銭利益だけでなく、業務停止による間接的な圧力が身代金交渉を有利に進める材料となるためである。BridgePayのケースでは、23名の従業員で4,000万件/月のトランザクションを処理するという「レバレッジの高さ」が、攻撃者にとっての魅力を高めていた可能性がある。

規制面では、PCI DSSの準拠がカード会員データの保護に一定の効果を発揮したとみられるが、運用システム全体のレジリエンスまではカバーしていない。今後、決済事業者にはPCI DSSに加えて、NISTサイバーセキュリティフレームワークやDORA（Digital Operational Resilience Act）に準じた包括的なレジリエンス基準の適用が求められるだろう。

加盟店にとっての最大の教訓は、決済ゲートウェイは「ユーティリティ」ではなく「サプライチェーンの一部」であるという認識の転換である。電力や通信と同様に、冗長性の確保とコンティンジェンシープランの策定が、ビジネス継続性の前提条件となる時代に入っている。

FAQ

BridgePay攻撃で決済カード情報は漏洩したのか？

BridgePayの初期フォレンジック調査では、決済カードデータの漏洩は確認されていない。攻撃者がアクセスしたファイルは暗号化されており、利用可能なデータの流出証拠はないとされている。

攻撃の犯行グループは特定されたのか？

2026年2月9日時点で、いずれのランサムウェアグループも犯行声明を出しておらず、使用されたランサムウェアの種類や初期侵入経路も公表されていない。FBIおよび米国シークレットサービスが捜査を継続中である。

加盟店はBridgePay停止中にどう対応したのか？

多くの加盟店は現金・小切手のみの対応を余儀なくされた。一部の事業者は代替の決済ゲートウェイへの切り替えを試みたが、BridgePayとの統合に依存していたシステムでは即座の移行が困難であった。

同様の攻撃を防ぐために加盟店は何をすべきか？

複数の決済ゲートウェイとの接続を事前に確保し、プライマリゲートウェイ障害時の自動フェイルオーバー機構を実装することが推奨される。また、定期的な切り替え訓練とサプライチェーンリスク評価の実施が重要である。

PCI DSS準拠でもランサムウェアを防げないのか？

PCI DSSはカード会員データの保護に焦点を当てた基準であり、運用システム全体のランサムウェア耐性をカバーするものではない。カードデータの暗号化は有効に機能したが、業務システムの可用性確保には別途、包括的なサイバーレジリエンス対策が必要である。

参考文献