セキュリティ防御はラグビーのディフェンスだ ―― Stripe悪用Magecart事件に学ぶ「15人で守る」設計

2026年6月4日、セキュリティ企業Sansecが、非常に巧妙なカード窃取攻撃を公開した。攻撃者は決済サービスのStripeを、マルウェアの配信元兼データ保管庫として悪用していた。

ただし、この事件から学ぶべきことは「Stripeが危ない」でも、「新しいツールを1つ買えば防げる」でもない。重要なのは、守り方の発想そのものだ。そしてその発想は、ラグビーのディフェンスとほとんど同じである。

ラグビーを知っている人なら、この記事はすっと入ってくるはずだ。知らない人も、3分だけ付き合ってほしい。

まず、ラグビーの防御の話

① 横一列に揃うこと

ラグビーの守備は、選手が横一列に並んで前に出る「ディフェンスライン」が基本だ。なぜ揃えるのか。1人だけ飛び出す（出過ぎる）と、その左右にぽっかり穴（ギャップ）が空く。攻撃側はそのギャップを1つ見つければ抜けられる。守る側はライン全体を保たなければならないのに、攻める側は穴を1つ見つければいい。 この非対称性が守備の難しさだ。だからこそ、誰か一人が突出するのではなく、全員で線を揃えて上がることに意味がある。

② 抜かれた時の備え

では第一線を破られたら終わりかというと、そうではない。後ろにはカバーに回るディフェンダーがいて、最後尾にはフルバックが一人残っている。第一線を抜かれても、二の矢、三の矢で止める。ラインを破られた＝トライ、ではない。 守備に「厚み」があるから、一箇所の綻びが即失点にならない。

③ 奪い返す技術

そしてラグビーの守備は、ただ止めるだけではない。タックルで相手を倒し、ブレイクダウンでボールに絡んで奪い返す（ジャッカル）。一度ボールを奪えば（ターンオーバー）、その瞬間に攻守は入れ替わり、今度はこちらのカウンターが始まる。守りは、どこか一箇所で奪い返せば勝てる。

整理すると、ラグビーの守備には3つの考え方がある。横一列に並ぶ「線」、抜かれても止める「面（厚み）」、そして「奪い返す」だ。

では、今回のセキュリティ事件

Sansecが報告した攻撃の流れはこうだ。攻撃者はまず、ECサイト上で読み込まれるGoogle Tag Manager（GTM）経由のコードに、悪性のローダーを紛れ込ませる。チェックアウトページが開くと、そのローダーがStripeの顧客データ（customer metadata）に分割保存しておいたスキマー本体を取得し、new Function() で実行する。スキマーは購入ボタン（観測された個体はMagento / Adobe Commerceのチェックアウト向けだった）のクリックを待ち、カード番号・有効期限・CVV・請求先情報を抜き取ってXORで難読化し、localStorageに保存する。最後に、別のルーチンがそのデータを攻撃者自身のStripeアカウントに「偽の顧客」として書き戻す。

巧妙なのは、ペイロードも盗難データも、すべて googletagmanager.com と api.stripe.com という、どのECサイトも当然のように信頼しているドメインだけを通る点だ。攻撃者は強い者（信頼されたサービス）の背後に隠れて出入りする。制服を着た警備員のふりをしているから、見咎められない。

横一列に、ギャップが生まれていた

これをラグビーに置き換えるとよく分かる。多くのサイトは、CSP（Content Security Policy）で「api.stripe.com への通信はすべて許可」と設定している。これは、ディフェンスラインの一箇所が大きく空いていた状態だ。攻撃者はそのギャップを正確に突いた。

さらに、「SAST と SCA を回しているから大丈夫」という守りも、この攻撃には効かない。SASTは自分のソースコードを、SCAは依存パッケージを検査する。しかし今回のスキマーは、コードベースの外側（GTM）からブラウザ実行時に注入される。どちらの視界にも入らない。1人が前に出ていても、その横が空いていれば抜かれる。 まさにそれが起きた。

では、誰がカバーするのか

第一線を抜かれた後、誰が止めるのか。ここで効くのが守備の「厚み」だ。

• カバーディフェンス＝ランタイム監視。 ブラウザ実行時に「見覚えのない new Function() が走っていないか」「想定外の宛先へfetchしていないか」を見る層。アプリ内（in-app）で実行時の挙動を捕まえる防御がここに当たる。
• フルバック（最後尾）＝流出段の監視。 たとえ上流をすべて抜かれても、「チェックアウト画面でもないのに api.stripe.com へPOSTが飛ぶ」という最後の不自然さを捕まえる。これが最終防衛線だ。

どう捕まえるのか

各段に「気づく仕掛け（tripwire）」を置く。今回の事件には、わかりやすい決め手がある。配信されたフロントエンドのJavaScriptの中に、sk_test_ で始まるStripeのシークレットキーが直書きされていたのだ。正規の実装で、Stripeのシークレットキーがブラウザ側のJavaScriptに露出することはない。テスト用の sk_test_ であっても同じだ。 これが見えた時点で、侵害――もしくは重大な実装ミス――を疑うべきサインになる。

他にも、自分で追加した覚えのないGTMタグ、localStorageに残る見慣れない暗号化された文字列――どれも「気づける」ポイントだ。問題は、見ようとしていなければ何一つ見えない、ということである。

締め ― 線で守り、面で守り、そして奪い返す

今回の攻撃は5段階で成り立っている。注入 → 配信 → 実行 → 収集 → 流出。攻撃者はこの5段すべてを成功させて初めてカードを盗める。逆に言えば、守る側はどこか1段で断ち切れば攻撃は死ぬ。これはラグビーのターンオーバーと同じ構造だ。守りは、一度奪い返せばいい。

だから守りの設計は、こうなる。

線で守る。 キルチェーンの全段に番兵を置き、横一列を揃える。CSPだけ、SASTだけ、という「1人が突出した守り」はやめる。揃っていない線は、線ではない。

面で守る。 それでも第一線は、いつか必ず破られる前提に立つ。破られた時のために、カバー（ランタイム監視）とフルバック（流出監視）を後ろに置く。一箇所の綻びが即失点にならないだけの厚みを持つ。

そして、奪い返す。 検知したら終わりではない。注入されたタグを除去し、侵入を許した穴（サーバの脆弱性）を塞ぎ、整合性を取り戻す。IOC（侵害指標）を検知ルールに取り込み、同じチェーンが二度と通らないようにする。これがインシデントレスポンスであり、ボールを奪い返して主導権を取り戻す動きそのものだ。

線で守る。面で守って、入られた時に備える。そして奪い返す。――まさに、ラグビーのディフェンスの考えそのものである。

守るのは、15人だ

最後にもう一つ。ラグビーのディフェンスは、誰か1人のスター選手が成立させるものではない。15人がそれぞれのポジションで持ち場と役割を全うし、噛み合って初めて1つの守りになる。

セキュリティも同じだ。SAST、SCA、シークレット検査、ランタイム防御、CSP、タグの統制、サーバ側の整合性スキャン、流出（egress）監視――それぞれが1つのポジションである。最強のツールを1つ買って前線に置いても、その横が空いていれば抜かれる。効くのは、強い個ではなく、ポジションの噛み合わせだ。

だから、SAST/SCAだけで終わらせず、シークレット検査、CSP、ランタイム挙動、外向き通信、そしてインシデント対応までを一つの流れとして見る必要がある。Aikidoのようなall-in-one型の発想が効くのは、まさにこの「15人で守る」構造を、ばらばらにせず一つにまとめて作れるからだ。

攻撃者は、強い者の背後に隠れて入ってくる。制服を着ているから、で信用してはいけない。ならば私たちは、15人で線を組み、面を作り、そして奪い返す。それが、この事件が突きつけた守り方の本質である。