Article 03
クレジットマスター攻撃とその対策
急増するカード不正利用の手口と、EC事業者が取り組むべき防衛策
他人のカード番号を「自動生成して通るか試す」攻撃
クレジットマスター攻撃（通称：クレマス）とは、カード番号の規則性を悪用し、プログラムで架空のクレジットカード番号を大量に自動生成させ、ECサイトの決済画面で「実際に使えるかどうか」を総当たりでテストするサイバー攻撃です。これにより、EC事業者は莫大なオーソリ手数料や不正利用の被害を被ります。
詳しく言うと？（仕組みと具体例）
なぜ「適当に作った番号」が実在するカード情報と一致してしまうのでしょうか？ クレジットカードの16桁の番号は完全にランダムではなく、「どの会社のカードか」などを示す計算ルール（アルゴリズム）が存在します。
これを「鍵の形を推測して、無数の合鍵を作る空き巣」に例えてみましょう。
- 現実のシリンダー錠などの凹凸に決まったパターンがあるように、カード番号にも規則（パターン）がある。
- 空き巣（攻撃者）は、その規則をもとに数万パターンの偽物の鍵（架空のカード番号）をプログラムで自動作成する。
- 作ってきた無数の鍵を、手当たり次第に鍵穴（決済フォーム）に挿し込んで回してみる。
- 「ガチャッ」と回って鍵が開いたもの（決済OKの返答）があれば、「この鍵（カード）は実在して使える！」とリストアップし、後で本当に高額な商品を不正購入する。
🏢 【当社の見解】私たちが考える対策方法と、不正検知の実装の重要性について
当社の対策：システムの最前線でボットを弾く仕組み
クレマス攻撃は「人間の目が届きにくく、気づきにくいタイミング」に機械（ボット）で高速に行われるため、人間が目視で気づいた頃には手遅れになります。
だからこそ、タイガーテックのEC構築ではシステムの最前線に「reCAPTCHA 等のボット検知技術（目立たないが現行犯を捕まえる優秀な警備員）」を配置してボットを弾く仕組みや、同一IPからの異常な決済試行をシャットアウトする「レートリミット機能を持つWAF（大量の鍵を試す不審者を検知・遮断する防犯カメラとゲート）」の導入などを標準技術スタックとして採用しています。これにより、気づかぬうちに参加させられてしまう「犯罪の温床」リスクを絶ち、大切なお客様からのブランドの信頼（安心・安全）を守り抜きます。
なぜクレマス対策（不正検知の実装）が重要なのか？
攻撃者は自らの身を隠すため、セキュリティの甘いECサイト（会員登録なしで決済できるサイトやボット検知がないサイト）を標的にします。この攻撃を受けると、事業者は以下の甚大な被害を受けます。
- 莫大なオーソリ手数料： 1万回のテストをボットで行われると、決済が失敗しても「承認照会テスト」の数円×1万回＝数万円〜数百万円単位の手数料だけを事業者が請求されます。 ※参考：Stripe「日本で被害が急増するクレジットマスターアタックとは？攻撃手口と対策を解説」
- チャージバック（売上取消）： その後、割り出された本物のカードで不正購入が行われ、本来の持ち主から申告があった場合、事業者の売上は取り消され商品は戻りません。 ※参考：SBペイメントサービス「チャージバックとは？クレジットカード不正利用の対策を解説」
- 加盟店契約の解除： 攻撃の標的にされ続けると、カード会社からの信用を失い、決済自体の契約を打ち切られるリスクがあります。 ※参考：GMOペイメントゲートウェイ「クレジットマスターとは？― 発生の仕組みとEC事業者のリスクを解説」
💡 【もっと詳しく知りたい方へ】攻撃を防ぐための具体的な技術的防衛レイヤー
多層的なシステム防衛
- WAFによるレートリミット（入口対策）： 「同一IPアドレスから1分間にN回以上の決済用APIへの通信（POST）があった場合、その通信を1時間ブロックする」といった制限ルール（WAF）をインフラレイヤーで記述し、攻撃の波を物理的に遮断します。 ※参考：AWS WAF Bot Control / Cloudflare Bot Management
- リスクベース認証・スコアリング（振る舞い検知）： reCAPTCHA等の技術をバックエンドと連携させ、クライアントの操作履歴やマウスポインタの動きから「Botスコア」を算出。スコアが低い通信の決済リクエストはサーバー側で破棄します。 ※参考：Google Cloud reCAPTCHA Enterprise
関連するサービス
疑問は解決しましたか？