Stripeなどのクレジットカード決済サービスの利用者（加盟店）のセキュリティ対策要求について調べてみた

Last updated at 2025-11-19Posted at 2025-11-19

tl;dr

元情報は「一般社団法人　日本クレジット協会ークレジット取引セキュリティ対策協議会」の「2025-03月協議会発行クレジットカード・セキュリティガイドライン6.0版」で、「EC加盟店のシステム及びWebシステムの脆弱性対策の実施」が追加指針対策となったことに起因する
Stripe社などクレカ決済事業者が顧客である「加盟店」にメールで回答（申告）や対策をするよう要請するメールが送られ始めていて、状況によっては加盟店の決済を停止することが示されている
まずは、決済事業者にセキュリティ対策を実施している状況の「申告」することが求められている
エンジニアにこれを起因とした発注機会が増加する可能性があり、背景を把握し、チェックリスト・アクションリストを持っておくことがアドバンテージになる
要するに以下を確認、または実装する
- カード情報の非保持
- 3Dセキュア 2.0 (EMV 3DS)
- ログイン・管理画面のIP制限やMFAなどの防御策
- Web/インフラの脆弱性検出の取り組みやモニタリングと継続的な是正対応
- 上記の確認や実施をしたうえで、決済サービス事業者にセキュリティチェックリスト実施状況の申告
- 申告した内容の維持

この Qiita 記事でやること

この記事では、Stripe を使っている EC / SaaS 事業者を主な対象として、

なぜ「日本のセキュリティチェックリストに答えてください」というメールが飛んでくるのか
その大本にある クレジットカード・セキュリティガイドライン 6.0 版 では何が変わったのか
Stripe 加盟店として、結局なにを実装・運用しないといけないのか

を、エンジニア目線のチェックリストに落として整理します。

※ GMO-PG や SBPS など他社 PSP にも共通する話ですが、この記事では説明をシンプルにするため Stripe 前提 で書きます。

背景：何が「大本」の話なのか

ガイドライン 6.0 版と「脆弱性対策」追加

日本のクレジットカード取引におけるセキュリティ対策は、主に次の文書に整理されています。

6.0 版の改訂ポイントの中でも、今回のテーマに直結するのが：

「EC加盟店のシステム及びWebシステムの脆弱性対策の実施」が明示されたこと

です。

これにより、EC 加盟店のシステム／Web に対して、

脆弱性を突かれてカード情報が抜かれる事案を防ぐための 具体的な 5 つの対策（管理画面アクセス制限、Web アプリ脆弱性対策、マルウェア対策、クレジットマスター対策など）

が、追加指針として明文化 されました。

なぜ Stripe から等クレジットカード決済代行事業者から、「いま」メールが来るのか

JCA や経産省の資料では、EC 加盟店に対し：

加盟店（=あなたのサービス）が自らセキュリティ対策を実施し、
アクワイアラー（カード会社等）や PSP（Stripe や GMO-PG など）に対して、
「セキュリティ・チェックリストに基づく対策状況申告書」を提出する

ことが求められています。

Stripe 側もこれを踏まえて、次のようなサポート記事を出しています。

特に「日本のセキュリティチェックリスト」では：

セキュリティ・チェックリストは、インターネット経由でカードを扱う加盟店の必要な取り組みを示すもの
Stripe や他の PSP は、新規契約の際に加盟店から申告書を回収することが義務付けられている

ことが明示されています。

結果として：

JCA のガイドライン → セキュリティチェックリスト → PSP による「申告してくださいメール」

という流れで、エンジニアのところに 「これ、どう答えればいい？」 という相談が飛んできます。

4 つの対応レベルを定義する

JCA のセキュリティチェックリストは、基本的にすべて「要対応」の温度感で書かれています。ただし、その中には：

今すぐ対応しないと 法令違反や決済停止に直結 しうるもの
時間をかけてでも 計画的に実施すべきもの
ベストプラクティスとして やっておくと強いもの

など、重さの違いがあります。

この記事では、理解しやすくするために次の 4 レベルに分けて整理します。

法令ベースの「必須対応」

割賦販売法や個人情報保護法など、法令上の義務として位置づけられているもの
例：カード情報の非保持化 / PCI DSS 準拠、漏えい時の報告・対応責任など

PSP運用上の「要対応」

Stripe などの PSP が、利用規約・運用ポリシー上、
- 「未対応だと決済停止／契約終了の対象になり得る」 としているもの
「違法かどうか」よりも、その PSP を使い続けられるかどうか の観点で重いもの

業界ガイドラインとしての「優先度高対応」

クレジットカード・セキュリティガイドライン 6.0 版や導入ガイドで、
- 「優先度高」「EC 加盟店が実施すべき」などとされているもの
すぐに未対応＝違法とまでは言い切れないが、
- ガイドライン準拠を名乗るなら必須級 な位置づけ

ベストプラクティスとしての「推奨対応」

ガイドラインや PSP 記事で「望ましい」「推奨」とされる、あるいは
- セキュリティベンダーが提案する高度な対策
当面は代替策で凌げるが、
- 中長期的にはここまでやれると安心 というレベル

結局、Stripe 加盟店は何をやらないといけないの？

Stripe の公式ドキュメントやサポート記事をベースに、Stripe 加盟店として “最低限ここは押さえたい” というポイントを、4 つの対応レベルにマッピングすると次のようになります。

Stripe 加盟店向け対応レベル一覧

対応レベル	内容	具体例 / Stripe 文脈でのポイント	参考URL（一例）
法令ベースの「必須対応」	カード情報の適切な管理（非保持化 or PCI DSS）	・Stripe Checkout / Payment Element / Link など、Stripe 側でカード情報を預かる構成にすることで、自社サーバでカード番号を保持しない・どうしても保持が必要な場合は PCI DSS 準拠が前提	クレジットカード・セキュリティガイドライン徹底解説
法令ベースの「必須対応」	情報漏えい発生時の対応	・漏えい疑いの時点で決済を一時停止し、ログ保全・原因調査・再発防止策を実施・必要に応じてカード会社 / PSP / 利用者への通知	クレジットカード・セキュリティガイドライン徹底解説
PSP運用上の「要対応」	Stripe へのセキュリティ・チェックリスト申告	・「日本のセキュリティチェックリスト」に沿って、自社の対策状況を Stripe に申告する・Stripe を含む決済代行会社は、加盟店からの申告回収が求められている	日本のセキュリティチェックリスト Connect プラットフォームにおける日本のセキュリティ・チェックリスト
PSP運用上の「要対応」	EMV 3-D セキュア（3DS2）の導入・運用	・日本向けアカウントは、新しい 3DS 要件に従う必要がある・オンライン取引フローに 3DS を組み込み、必要な取引で認証をかける	日本における 3DS の導入の義務化について 3D セキュア関連トピック
PSP運用上の「要対応」	ログイン対策と 3DS 例外ルールの関係整理	・ログイン機能がセキュリティチェックリスト要件を複数満たしていない場合、各取引で 3DS が必要になる・不正ログイン対策と 3DS 運用ルールをセットで設計する	日本における 3DS の導入の義務化について日本のセキュリティチェックリスト
業界ガイドラインとしての「優先度高対応」	管理画面・運用アカウントの保護	・Stripe ダッシュボードを含む管理系へのアクセスに 2FA を必須化・権限分離・退職者アカウントの即時無効化などの運用ルールを整備	2 段階認証の要件 2 段階認証 : トピック
業界ガイドラインとしての「優先度高対応」	Web アプリ / API の脆弱性対策	・XSS / SQLi / CSRF などの基本的対策の実装・年 1 回以上、もしくは大規模改修時に脆弱性診断を実施	クレジットカード・セキュリティガイドライン 6.0 版 EC 加盟店におけるセキュリティ対策導入ガイド（要約版）
業界ガイドラインとしての「優先度高対応」	クレジットマスター / カードテスト対策	・同一 IP / アカウントからのカード試行回数制限・Stripe Radar やアプリ側レート制限によるカードテスト検知	クレジットカード・セキュリティガイドライン徹底解説 Stripe Radar
業界ガイドラインとしての「優先度高対応」	会員登録/ログイン/属性変更の不正ログイン対策	・多要素認証、ログイン通知、IP 制限、試行回数制限などを複数組み合わせる・3DS 例外を活用する場合の前提となる	日本のセキュリティチェックリスト EC 加盟店におけるセキュリティ対策導入ガイド（要約版）
ベストプラクティスとしての「推奨対応」	Stripe Radar / 不正検知の高度な活用	・チャージバック発生時にルールを見直すなど、Radar の運用サイクルを回す・業種特有のリスクをカスタムルールで表現する	Stripe Radar
ベストプラクティスとしての「推奨対応」	ログ監視・アラート・運用プロセス整備	・Stripe のイベントログ / Webhook ログを監視基盤に集約し、異常時にアラート・不正検知とインシデントレスポンスの手順をドキュメント化	EC 加盟店におけるセキュリティ対策導入ガイド（要約版）
ベストプラクティスとしての「推奨対応」	開発プロセスへのセキュリティ組み込み	・仕様レビュー時に「ガイドライン 6.0 対応チェック」をする・セキュリティ修正を定常タスク化する	クレジットカード・セキュリティガイドライン 6.0 版

エンジニアが Stripe でまず確認すべきチェックポイント

上の表はどうしても情報量が多くなるので、ここからは エンジニア視点での最初のチェックリストに落とします。

1. カード情報の非保持化まわり

自社のサーバ／アプリが「カード番号・有効期限・CVC」を一切受け取っていないか
（受け取っているなら 最優先でアーキテクチャの見直し候補）
決済画面は Stripe Checkout / Payment Element / Link などの Stripe 提供 UI で完結しているか（あるいは要件を満たす代替対応ができているか）
ログ・アクセスログ・エラーログ・監視ツールに カード番号が残らない ことを確認したか
以上すべてチェックついているか

2. 3D セキュア（EMV 3DS）の導入状況

日本向けアカウントで、3D セキュア 2.0 対応の決済フローが動いているか
初回決済／高額決済／リスク高そうな取引で 3DS を必ずかける設計になっているか
定期課金・継続課金など、3DS 例外に該当しうるフローを 仕様として整理しているか
以上すべてチェックついているか

3. ログイン・会員機能まわりの防御

ログインの 試行回数制限（ロック／クールダウン）が入っているか
怪しい IP ／地域からのアクセスを IP 制限／レート制限しているか
重要操作（ログイン、メールアドレス変更、パスワード変更）に対して
メール or SMS 通知を飛ばしているか
管理者・社内アカウントには **二要素認証（2FA）**を必須にしているか
（Stripe ダッシュボードの 2FA も含めて）
以上できるだけ多くチェックついているか

4. Stripe の「日本のセキュリティチェックリスト」対応

日本のセキュリティチェックリストの全設問を エンジニア視点で一度読み込んだか
「実施済み」と回答する項目について、 コード／設定／運用手順で裏が取れる状態になっているか
未実施・部分的対応の項目について、「いつまでに・どうやって対応するか」の 社内メモ／計画があるか
以上すべてにチェックがついているか

5. Web アプリ／インフラの脆弱性対策

フレームワークやミドルウェアの セキュリティアップデート方針（いつ／誰が／どうやって）が決まっているか
XSS / SQLi / CSRF などの 典型的な脆弱性対策をフレームワーク＋コーディング規約でカバーできているか
年 1 回程度、または大規模改修時に **脆弱性診断（手動 or 自動）**を行っているか
以上最低１つ「自信をもって」チェックがついているか

6. 不正利用・カードテスト対策

同一 IP ／同一ユーザーからの 連続決済エラーにレート制限をかけているか
明らかにカードテストっぽい動き（少額決済を大量試行など）を アプリ側 or Stripe Radar のルールで抑止しているか
チャージバックが発生したときに、「ログ調査 → ルール修正」を行う 運用フローが決まっているか
以上最低１つ「自信をもって」チェックがついているか

7. ログと監視・アラート

Stripe のイベント／Webhook ログを、 アプリケーションログや監視基盤と紐づけて追えるようになっているか
ログイン失敗急増・決済失敗急増などを検知する アラート条件が（少なくともざっくりでも）設定されているか
ログの保存期間が、事後調査に耐えられる長さになっているか（例：1 年～数年単位）
以上最低１つ「自信をもって」チェックがついているか

8. インシデント対応の初動フロー

「不正利用や情報漏えいが疑われたときに“まず誰が何をするか”」が 1 ページ程度でドキュメント化されているか
Stripe サポート／カード会社／社内関係者への 連絡フローが決まっているか
本番環境のログ保全・サービス一時停止・原因切り分けを 技術的にすぐ実行できるか（権限／手順が用意されているか）
以上最低１つ「自信をもって」チェックがついているか

9. 「仕様変更するとき」のルール

3DS のかけ方やログインまわりの仕様を変更するときに、 JCA のガイドライン＋ Stripe のチェックリストを見直すルールがあるか
一度「実施」と申告した対策を弱める／外す場合、 Stripe に事前相談するという方針が社内で共有されているか
以上すべてチェックがついているか

Stripe に限らず PSP 全体で共通する実務 ToDo

ここまで Stripe 中心で書いてきましたが、やるべきことの多くは PSP 共通です。Stripe 以外の PSP（GMO-PG, SBPS など）を併用している場合も、基本的な ToDo はあまり変わりません。

代表的なものだけ挙げておきます。

1. カード情報の「データフロー」を図にする

どの画面でカード番号が入力されるか
どのサーバに、どの経路で送信されるか
ログやバックアップにカード情報が残らないか

を図にして、自社でカード情報を持っていないと言い切れるかを確認します。

2. ログイン / 会員管理まわりの対策を洗い出す

セキュリティ・チェックリストや 3DS 関連ドキュメントでは、ログイン対策として例えば次のような項目が挙げられています。

ログイン試行回数制限
不審 IP からのアクセス制限
多要素認証（二要素認証）
ログイン時やパスワード変更時のメール / SMS 通知

これらのうち、どれをどこまで実装しているかを棚卸しし、不足分の実装計画を作ります。

3. 脆弱性対策（5 つの基本対策）をチェックする

ガイドライン 6.0 では、EC 加盟店のシステムに対して次のような脆弱性対策が明示的に求められています（要約）：

OS / ミドルウェアなどのセキュリティアップデート
Web アプリケーションの脆弱性対策（XSS / SQLi / CSRF など）
管理者権限の適切な管理
ログの取得と保管・監視
マルウェア / ウイルス対策、端末管理

エンジニア視点では、

インフラのパッチ適用サイクル
Web アプリのセキュアコーディングとレビュー
権限管理の設計（最小権限、退職者アカウント削除）
ログの保存期間と検索性、アラート設定
管理端末の管理方針（MDM / アンチウイルス等）

を、自社サービス単位で見直す必要があります。

4. 脆弱性診断と改善サイクルを回す

大きな機能追加やリプレイスのタイミング
1 年に 1 回程度の定期診断

を目安に、Web アプリケーション診断 / ネットワーク診断を実施し、発見された脆弱性について、

リスク評価
対応方針の決定（修正 / WAF 等での暫定対応 / 受容）
修正の実装と再テスト

というサイクルを回せるようにしておきます。

5. 不正利用が起きたときの「動き方」を決めておく

不正利用疑いの検知（PSP からの通知、不正検知サービス、社内のモニタリングなど）
当該アカウントのロックや利用停止
ログの保存・エクスポート
PSP / カード会社との情報共有

など、インシデント対応フローを事前にドキュメント化しておくと、いざというときに動きやすくなります。

「まだ全部できない」場合にどう動くか

現実問題として：

予算・人員が限られている
レガシーシステムの制約が大きい
すぐには 3DS やログイン強化を入れられない

といった状況もあると思います。

その場合に大事なのは、

「やっていないことを隠してチェックリストを埋める」のではなく、
未実施の事実と代替策・今後の計画を正直に説明する こと

です。

チェックリスト回答の基本方針

実施している項目だけを「実施」としてマークする。
未実施項目については、
- なぜ未実施なのか（技術的・コスト的な理由）
- 代替として何を行っているか
- いつまでにどのような形で対応予定か

などをメモ・社内資料として整理し、必要に応じて PSP の担当者に共有します。

Stripe の「日本のセキュリティチェックリスト」記事でも、申告内容と実際の対策が食い違わないことが重視されており、対策が不足している場合には、サポートへの相談が推奨されています。

「対策してから申告せよ」の現実的な解釈

PSP のドキュメントには、

対策が完了してから申告すること
申告した対策は継続して維持すること

といった趣旨の記載があります。

現実的には、

まずは 最低限の必須対応（非保持化 / 3DS 導入など）を先に実装し、
それが終わった段階で、残りの項目について
- 「実施済み」
- 「○年○月までに実施予定」
  を整理したうえで申告する

というステップを踏むのが現実解だと考えています。

申告後に仕様変更する場合の注意

一度「実施」と申告した対策を後からオフにする場合、
- セキュリティ・チェックリストの内容と実態がずれる
- インシデント発生時に「なぜ弱体化したのか」が問われる

ため、事前に PSP の担当者に相談し、代替策やリスク評価を共有しておくのが安全です。

まとめ

元ネタは JCA の クレジットカード・セキュリティガイドライン 6.0 版 と、その改訂ポイントにある「EC加盟店のシステム及びWebシステムの脆弱性対策の実施」。
このガイドラインを実務に落とすために、セキュリティ・チェックリスト と 導入ガイド が整備され、PSP（Stripe や GMO-PG など）が加盟店から対策状況の申告を回収することになった。
Stripe 加盟店としては、
- カード情報の非保持化 / PCI DSS
- 3D セキュア 2.0（EMV 3DS）の導入
- ログイン・管理画面の防御
- Web / インフラの脆弱性対策
- セキュリティ・チェックリストへの正直な回答と、その裏付け
といったポイントを、実装レベルの ToDo として潰していく必要がある。
すべてを一気に完璧にする必要はないが、
- 法令ベースの「必須対応」
- PSP運用上の「要対応」
から優先的に対応しつつ、余力に応じて「優先度高対応」「推奨対応」に広げていくのが現実的な進め方だと思う。

参考リンク集

JCA / 経産省関連

Stripe 関連

※ 本記事は、公開されている JCA 資料および Stripe の公開ドキュメントをもとに、筆者の理解に基づいて整理したものです。最終的な義務・運用条件については、必ず 最新の公式ドキュメント を参照してください。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up