eコマースの PCI DSS 準拠: 支払いセキュリティ ガイド

ペイメント カードを伴うすべての e コマース トランザクションには、PCI DSS (ペイメント カード業界のデータ セキュリティ基準) に基づくコンプライアンス義務が生じます。コンプライアンス違反は理論上のリスクではありません。カード ブランド (Visa、Mastercard、Amex) は、買収銀行に対して月額 5,000 ドルから 100,000 ドルの罰金を課す可能性があり、買収銀行は支払い処理契約を通じて加盟店に直接責任を転嫁します。違反が発生した場合、準拠していない加盟店は、侵害されたカード 1 枚につき 50 ～ 90 ドルの罰金、カード ブランドのフォレンジック調査費用、および最も深刻なケースでは加盟店アカウントの停止に直面します。

2022 年 3 月にリリースされ、2025 年 3 月からの準拠が義務付けられた PCI DSS v4.0 では、暗号化要件、認証基準、支払いページでのスクリプトの処理に大幅な変更が導入されました。このガイドは、e コマース チームに完全な実装ロードマップを提供します。

重要なポイント

• PCI DSS v4.0 は 2025 年 3 月 31 日以降必須です — すべての e コマース販売者は新しいバージョンに準拠する必要があります
• スコープ設定は最も重要な最初のステップです。カード会員データ環境 (CDE) を可能な限り削減します。
• 決済処理業者のホスト型決済ページ (Stripe、Braintree、Adyen) を使用すると、範囲が大幅に縮小します
• SAQ A は、ほとんどのホスト型支払いページ加盟店に適用されますが、カード所有者のデータがサーバーにアクセスしていない場合に限ります。
• 新しい v4.0 要件には、すべての CDE アクセスの MFA、支払いページのスクリプト整合性制御、対象を絞ったリスク分析が含まれます
• Web スキミング (Magecart 攻撃) は、支払いページのスクリプト インベントリに関する新しい要件 6.4.3 によって対処されています。
• 毎年の侵入テストと四半期ごとの脆弱性スキャンは引き続き義務付けられます
• 違反のペナルティは、カードブランド→取得銀行→加盟店へと課せられます。

---

PCI DSS フレームワークの基礎

PCI DSS は、American Express、Discover、JCB、Mastercard、Visa によって設立された団体である Payment Card Industry Security Standards Council (PCI SSC) によって維持されています。現在の標準は PCI DSS v4.0 です。

この規格は、6 つの目標にわたる 12 の要件で構成されています。

コンプライアンスは、カード会員データを保存、処理、送信するすべての事業体、またはカード会員データのセキュリティに影響を与える可能性のある事業体に適用されます。これには、販売業者、支払処理業者、取得者、発行者、サービスプロバイダーが含まれます。

---

ステップ 1 — 範囲を定義して縮小する

カード会員データ環境 (CDE) は、カード会員データ (CHD) または機密認証データ (SAD) を保存、処理、または送信するシステムです。範囲を最小限に抑えることは、実行できる最も効果的なステップです。

カード所有者データと機密認証データ:

eコマースの範囲縮小戦略:

1. ホスト型支払いページを使用する: 顧客を決済処理業者のホスト型支払いページ (Stripe Checkout、Braintree Hosted Fields、Adyen Drop-in) にリダイレクトします。カード会員データがサーバーにアクセスされることはなく、最も簡単な自己評価アンケートである SAQ A の対象となります。

2. トークン化: 認証直後に、カード番号をプロセッサーが生成したトークンに置き換えます。トークンのみを保存します。プロセッサのトークン化保管庫にアクセスできない攻撃者にとっては役に立ちません。

3. iFrame ベースの支払いフォーム: 支払い処理業者の JavaScript でレンダリングされたフォームをチェックアウト ページ内に埋め込みます。カード データは、ユーザーのドメインではなく、プロセッサのドメインでホストされているフォームに直接入力されます。

4. ネットワーク セグメンテーション: ファイアウォールを使用して、CDE システム (支払い処理サーバー、データベース) を範囲外のシステムから分離します。ネットワークを適切にセグメント化すると、監査範囲が大幅に縮小されます。

---

ステップ 2 — SAQ タイプを特定する

自己評価アンケート (SAQ) は、認定セキュリティ評価者 (QSA) のオンサイト評価を必要としない販売者およびサービス プロバイダーのための検証ツールです。 SAQ タイプは、支払いの受け入れ方法によって決まります。

SAQ A — PCI DSS 準拠のサードパーティに支払い処理を完全に委託する、カードを提示しない (電子商取引) 加盟店に適用されます。電子カード所有者のデータは、お客様のシステムや敷地内で保存、処理、送信されることはありません。支払いページはすべて支払い処理業者によって配信されます。約22の要件。

SAQ A-EP — 支払い処理を部分的にアウトソーシングしているものの、サードパーティの支払い iframe が埋め込まれた独自のサーバーでホストされている支払いページを保有している e コマース販売者向け。 Web サーバーは、支払い処理のセキュリティに間接的に影響を与えます。 SAQ A よりも多くの要件。新しい v4.0 要件 6.4.3 によって重大な影響を受けます。

SAQ D — 他の SAQ タイプの基準を満たさない販売者、またはカード会員データを保存する販売者向け。 12 の要件すべてをカバーします。独自の支払い処理インフラストラクチャを実行している販売者に必要です。通常、最大 300 以上のサブ要件。

レベル階層 (Mastercard/Visa 標準):

---

ステップ 3 — e コマース向けの PCI DSS v4.0 の主な変更点

PCI DSS v4.0 では、特に e コマース販売者に影響を与えるいくつかの要件が導入されました。 2025 年 3 月 31 日からはすべて義務化されました。

要件 6.4.3 — 支払いページのスクリプト管理

この要件は、Magecart/Web スキミング攻撃を直接ターゲットにしています。攻撃者は、悪意のある JavaScript を e コマースの支払いページに挿入して、カード所有者のデータをリアルタイムで盗みます。 6.4.3 では、SAQ A-EP 以降を使用する販売者は次のことを行う必要があります。

• 支払いページでの実行が許可されているすべてのスクリプトのインベントリを管理します。
• 各スクリプトのビジネス上または技術的な必要性を正当化する
• 各スクリプトの整合性を確認する方法を実装します (サードパーティ スクリプトのサブリソース整合性ハッシュ、またはコンテンツ セキュリティ ポリシー ディレクティブ)。

完全にアウトソーシングされた支払いページを備えた SAQ A 加盟店の場合、この要件は支払い処理業者のページに適用されます。支払い処理業者は、お客様に代わってコンプライアンスを証明する必要があります。

要件 11.6.1 — 支払いページの変更と改ざんの検出

販売者は、支払いページ上の HTTP ヘッダーおよびスクリプト コンテンツに対する不正な変更を検出するためのメカニズム (コンテンツ セキュリティ ポリシー、スクリプト監視サービスなど) を導入する必要があります。アラートは、未承認の変更があった場合は 7 日以内に生成する必要があります。

要件 8.4.2 — CDE へのすべてのアクセスに対する MFA

多要素認証は、リモート アクセスだけでなく、CDE にアクセスできるすべてのユーザー アカウントに必要になりました。これには、企業ネットワーク内から本番決済システムにアクセスする内部ユーザーが含まれます。

要件 3.3.1.1 — 承認後に SAD を保持することはできません

承認後に機密認証データ (フル トラック データ、CVV、PIN) を保存することを明示的に禁止します。これは常に禁止されていましたが、一部のシステムがデバッグ/診断出力に SAD を記録する方法の抜け穴を塞ぐために、より正確に表現されるようになりました。

対象を絞ったリスク分析 (TRA)

v4.0 では、対象を絞ったリスク分析の概念が導入されています。販売者は、同等の保護を示す文書化されたリスク分析を実行すれば、一部の要件に対する代替アプローチを実証できます。これにより、より大規模で複雑な環境に柔軟性が提供されます。

---

ステップ 4 — ネットワーク セキュリティ アーキテクチャ

SAQ A を超える範囲のシステムを扱う販売者にとって、ネットワーク セキュリティはコンプライアンスの中核となるドメインです。

要件 1 — ネットワーク セキュリティ制御をインストールおよび維持する:

• 信頼できないネットワーク (インターネット) と CDE の間にファイアウォールを実装する
• CDE と他の内部ネットワークの間にファイアウォールを実装します (セグメンテーション)
• ビジネス上の正当性を伴うすべてのファイアウォール ルールを文書化する
• ファイアウォール ルールを少なくとも 6 か月ごとに確認します。
• 明示的に必要でないすべてのトラフィックを拒否します（デフォルトの拒否ポスチャ）
• 電子商取引の場合: Web サーバーの前に WAF (Web アプリケーション ファイアウォール) を実装します。

ネットワークセグメンテーションテスト:

よくある誤解は、ネットワークのセグメント化により範囲が自動的に縮小されるということです。 PCI SSC では、セグメンテーションが有効であることをテストする必要があります。侵入テストには、セグメンテーションの境界を越える試みが含まれている必要があります。ペネトレーション テスターが範囲外のネットワークから CDE システムに到達できる場合、セグメンテーションは効果がなく、より広範な環境が範囲内になります。

e コマース用の DMZ アーキテクチャ:

Internet → WAF/Load Balancer → DMZ (Web Servers) → Internal Firewall → CDE (Payment Servers, DB) → Internal Network

DMZ 内の Web サーバーは店頭にサービスを提供します。文書化された特定のトラフィック (HTTPS から支払い API、特定のポートから特定の DB への SQL) のみが DMZ から CDE に送信されます。他のトラフィックはすべてブロックされます。

---

ステップ 5 — アプリケーションのセキュリティ要件

要件 6 — 安全なシステムとソフトウェアを開発および維持する:

• 対象範囲内のすべてのカスタム ソフトウェアおよびサードパーティ ソフトウェアのインベントリを維持する
• 正式な脆弱性管理プロセスの一環として脆弱性に対処する
• Web に接続するアプリケーションを既知の攻撃から保護します (OWASP トップ 10)
• 重要な変更を実稼働環境に導入する前に、セキュリティ コードのレビューまたはアプリケーション侵入テストを実施します。
• コミットメントされたセキュリティパッチプロセスを備えた信頼できるベンダーのソフトウェアのみを使用してください

Web アプリケーション ファイアウォール (WAF) — 要件 6.3.2 および 6.4.2:

WAF は、すべての公開 Web アプリケーションに必須であり、攻撃をブロックするか、アラートを生成して 1 時間以内にレビューするように構成されています。 e コマースの場合、WAF は以下をカバーする必要があります。

• SQLインジェクションの防止
• クロスサイト スクリプティング (XSS) 保護
• クロスサイト リクエスト フォージェリ (CSRF) からの保護
• 悪意のあるボットの検出
• ブルートフォース防止のためのレート制限

依存関係とサードパーティ ソフトウェアの管理:

e コマース プラットフォーム (WooCommerce、Magento、Shopify のカスタマイズ) は、プラグインと拡張機能に大きく依存しています。スコープ内の各プラグインのセキュリティを評価する必要があります。インベントリを維持し、パッチ適用 SLA 内でパッチを適用します (重要: ベンダー パッチ リリースから 7 日)。

---

ステップ 6 — アクセス制御と認証

要件 7 — システム コンポーネントとカード所有者データへのアクセスを制限します:

• 最小権限に基づいたロールベースのアクセス制御を実装する
• 明示的な許可を文書化して、すべてのアクセスをデフォルトで「すべて拒否」に設定
• ユーザーのアクセス権を少なくとも 6 か月ごとに確認します。

要件 8 — ユーザーを識別し、アクセスを認証する:

• CDE にアクセスできる各ユーザーに一意の ID を割り当てます。
• パスワードは最低 12 文字 (v4.0 では v3.2.1 の 7 文字から増加)、複雑さの要件
• 最大 10 回の無効な試行後にアカウントをロックする (v4.0 のデフォルト、または TRA ごと)
• CDE セッションで最大 15 分間非アクティブになった後のセッション タイムアウト
• すべての CDE アクセスに MFA が必要 (リモートのみからの v4.0 拡張)
• サービスアカウントとシステムアカウントはユーザーアカウントとは別に管理する必要があります

---

ステップ 7 — 脆弱性の管理とテスト

要件 11 — システムとネットワークのセキュリティをテストする:

四半期ごとの内部脆弱性スキャン: 対象範囲内のすべてのシステムをスキャンします。次のスキャンの前に、重大度の高い重大な脆弱性をすべて修正します。スキャンは、承認されたツール (Nessus、Qualys、OpenVAS) を使用して内部スタッフが実行できます。

承認されたスキャン ベンダー (ASV) による四半期ごとの外部脆弱性スキャン: 外部からアクセス可能なすべてのシステムの外部スキャンは、PCI SSC 承認の ASV によって実行される必要があります。コンプライアンスを証明するには、スキャンに合格する必要があります (未解決の高/重大な脆弱性がない)。

年次侵入テスト: 資格のある内部リソースまたは評判の高い外部企業によって実施されます。以下をカバーする必要があります:

• 対象となるすべてのシステムとネットワーク
• セグメンテーション制御 (CDE が適切に分離されていることを確認します)
• Web 対応アプリケーションの OWASP トップ 10
• ソーシャル エンジニアリング (リスクの高い環境向け)

すべての侵入テストの結果を修正し、検証テストを実施して修正を確認します。

ファイル整合性監視 (FIM): すべての重要なシステム ファイル、構成ファイル、およびコンテンツ ファイルに FIM を展開します。不正な変更があった場合は 1 時間以内に警告します (v4.0)。

---

eコマースの PCI DSS 準拠チェックリスト

• 支払い処理範囲の定義と縮小 (ホストされた支払いページまたは可能な場合はトークン化を使用)
• 支払い受け入れ方法に基づいて識別された SAQ タイプ
• ネットワーク セグメンテーションが実装され文書化されている
• カード会員データのインベントリが完了しました - SAD はどこにも保存されていません
• すべてのカード所有者のデータ ストレージは暗号化されています (AES-256 または同等のもの)
• すべての支払いデータ送信に TLS 1.2+ を適用
• 支払いページのスクリプト インベントリの文書化 (要件 6.4.3)
• 支払いページに導入された変更/改ざん検出 (要件 11.6.1)
• すべての公開 Web アプリケーションの前に展開された WAF
• すべての CDE アクセスに対して MFA を適用 (要件 8.4.2)
• 固有のユーザー ID、強力なパスワード、アカウント ロックアウトが設定されています
• 四半期ごとの脆弱性スキャン (内部 + ASV 外部) が完了しました
• 年次侵入テストが完了し、結果は修正されました
• CDE システムに展開されたファイル整合性監視
• 過去 6 か月以内にレビューされたファイアウォール ルール
• CDE に触れるすべてのスタッフを対象としたセキュリティ意識向上トレーニングが完了しました
• インシデント対応計画は、支払いカード侵害のシナリオをカバーします
• ベンダー/サービス プロバイダーの PCI DSS 準拠が確認済み

---

よくある質問

ストアに Shopify を使用しています – それでも PCI DSS 準拠が必要ですか?

Shopify は、PCI DSS レベル 1 認定のサービス プロバイダーです。 Shopify の標準的な支払い処理 (Shopify Payments または Shopify がホストするチェックアウト) を使用する場合、コンプライアンスの範囲は大幅に減少します。あなたには、Shopify のサービスの使用をカバーする主に SAQ A の義務がまだあります。 Shopify チェックアウトにカスタム JavaScript を追加するか、Shopify の環境外でカード データを処理するサードパーティの支払いアプリを使用する場合、範囲は拡大します。

PCI DSS 準拠と PCI DSS 認証の違いは何ですか?

加盟店向けの正式な「PCI DSS 認証」はありません。マーチャントは、自己評価アンケートを通じて、または（レベル 1 マーチャントの場合）QSA が実施するコンプライアンスに関するレポート（RoC）を通じてコン​​プライアンスを証明します。サービスプロバイダーは、Visa のサービスプロバイダーのグローバル登録に登録できます。 「認証済み」と「準拠」という用語は、市場コミュニケーションではしばしば同じ意味で使用されますが、厳密には販売業者は準拠していることを自己証明するか、QSA によって証明された準拠を持っています。

加盟店が違反した場合、どのような罰則が課せられますか?

違約金は PCI SSC から直接支払われるものではなく、カード ブランドから買収銀行を通じて支払われます。加盟店のレベルと違反期間に応じて、月々の罰金は通常 5,000 ドルから 100,000 ドルの範囲です。違反が発生した場合、カード ブランドはカードごとに罰金 (Visa カード 1 枚あたり 50 ～ 90 ドル、Mastercard も同様)、フォレンジック調査費用 (20,000 ドル～200,000 ドル以上)、および必須のカード再発行費用を課す場合があります。深刻な場合には、販売業者はカード支払いを完全に受け入れることができなくなります。違反を繰り返したり、違反の影響が大きかった販売者には、最高の罰則が科せられます。

Magecart 攻撃とは何ですか?PCI DSS v4.0 はこれにどのように対処しますか?

Magecart とは、悪意のある JavaScript が e コマースのチェックアウト ページに挿入され、顧客が入力するカード所有者のデータをリアルタイムで傍受する攻撃を指します。これらの攻撃は、販売者が支払いページに含めるサードパーティのスクリプト (分析、チャット ウィジェット、タグ マネージャー) を悪用します。 PCI DSS v4.0 要件 6.4.3 および 11.6.1 はこれに直接対応しています。加盟店は、支払いページ上のすべてのスクリプトのインベントリを作成して整合性を検証し、支払いページ コードへの不正な変更を検出するための監視を展開する必要があります。

ヘッドレス e コマース アーキテクチャの PCI DSS はどのように処理すればよいですか?

ヘッドレス e コマースは、フロントエンドのプレゼンテーション層をバックエンドのコマース エンジンから分離します。 PCI DSS の目的では、カード所有者のデータがどこに流れるかが重要です。ヘッドレス フロントエンドが Stripe Elements または同様の iFrame ベースのソリューションを使用している場合、カード データはフロントエンド サーバーに触れることなく、ブラウザから決済プロセッサに直接送信されます。これは SAQ A の領域です。ヘッドレス アーキテクチャにカスタムのサーバー側支払い処理が含まれる場合、範囲が大幅に拡大するため、範囲のガイダンスについて QSA を利用する必要があります。

PCI DSS 評価には QSA が必要ですか?

レベル 1 加盟店 (Visa/Mastercard で年間 600 万件以上の取引) のみが、年次コンプライアンス レポート (RoC) のために QSA に参加する必要があります。レベル 2 ～ 4 の販売者は、SAQ を通じて自己証明を行うことができます。ただし、多くの加盟店は、必要でない場合でも、特に範囲が不明な場合やインフラストラクチャが複雑な場合には、自発的に QSA または Qualified Security Assessor Company (QSAC) に指導を求めています。

---

次のステップ

PCI DSS への準拠は、顧客の支払いデータを保護し、責任のリスクを制限し、カードの受け入れを維持するための前提条件です。 Shopify またはカスタム プラットフォームでの e コマース ビジネスの場合、最初のステップは常に範囲の縮小です。ホストされた支払いページを適切に使用して SAQ A に到達することが、最速で最もコスト効率の高い方法です。

ECOSIRE の e コマース実装チームは、CDE の範囲を最小限に抑えるためにゼロから設計された支払いアーキテクチャを使用して、PCI DSS 準拠の Shopify ストアとカスタム コマース プラットフォームを構築した豊富な経験を持っています。

始めましょう: ECOSIRE Shopify サービス

免責事項: このガイドは情報提供のみを目的としており、法的またはコンプライアンスのアドバイスを構成するものではありません。 PCI DSS 要件はカード ブランドやアクワイアラによって変更される場合があります。お客様の環境に固有の最終的なコンプライアンス ガイダンスについては、QSA に依頼してください。