PCI DSS データフロー図：カード会員データを可視化してスコープを縮小する

PCI DSS の評価は、たいてい同じ依頼から始まります。カードデータがどこへ流れるかを示してほしい、というものです。wiki にある図にはサービスと矢印は描かれていますが、どの矢印がカード番号を運び、どれがトークンだけを運ぶのか、そして分析用ウェアハウスがなぜスコープ外なのかは分かりません。それが分からないと、すべてのシステムがスコープをめぐる議論になります。

この記事では、PCI DSS v4.0.1 の要求事項、スコープのカテゴリ、ホスト型決済フィールドを使ったチェックアウトの実例、トークン、セグメンテーション、SAQ の種類、図の保守を扱います。法務やコンプライアンスの助言ではありません。何が適用されるかはアクワイアラーまたは評価者が決め、公式文書は PCI SSC Document Library にあります。

PCI DSS v4.0.1 の要求事項

2024 年 6 月に公開された PCI DSS v4.0.1 は、執筆時点（2026 年 11 月）の最新版です。将来日付の要件は 2025 年 3 月 31 日に必須になりました。図に関わる要件は次の 3 つです。

アカウントデータには、カード会員データ（PAN、カード会員名、有効期限、サービスコード）と機密認証データ（全トラックデータ、カード検証コード、PIN と PIN ブロック）が含まれます。決め手になるのは PAN です。PAN を保存、処理、伝送するなら、カード会員データ環境（CDE）があることになります。

SAQ A には要件 1 も 12.5.2 も含まれず、SAQ A-EP には 1.2.3 と 1.2.4 が含まれ、SAQ D と完全な評価には 3 つすべてが含まれます。SAQ A でも、図は適格性を示す最も明確な証拠です。

3 種類のシステム

セクション 4 は、CDE と、「カード会員データまたは機密認証データのセキュリティに影響しうる」あらゆるものに要件を適用します。この表現は v4.0.1 で「CDE のセキュリティ」に代えて導入されました。標準自身の例は「決済フォームまたはページの生成を制御する Web サーバー」です。PCI SSC のスコープ設定ガイダンスは、システムを上から順に確認する 3 つのカテゴリに分けています。

システムは、当てはまる最上位のカテゴリに属します。セグメンテーションは任意ですが、行わなければ「フラットなネットワーク」全体がスコープに入り、暗号化だけでは通常カードデータはスコープから外れません。

例：ホスト型決済フィールドを使ったチェックアウト

ストアフロントの Web アプリがチェックアウトページを配信し、そのカードフィールドは決済プロバイダーの iframe で、ホスト型フィールド（hosted fields）と呼ばれることもよくあります。注文サービスが決済を請求し、Postgres が注文を保存し、夜間ジョブがウェアハウスにデータを流し、CI/CD がストアフロントをデプロイします。

1. ブラウザーがチェックアウトページを読み込み、プロバイダーのスクリプトが独自の iframe にカードフィールドを描画します。
2. 顧客が PAN、有効期限、CVC を入力すると、ブラウザーはそれらを TLS でプロバイダーに直接送ります。同一オリジンポリシーにより、加盟店ページのスクリプトは iframe に入れません。
3. プロバイダーは PAN を自社の vault に保存し、トークンを返します。
4. ページは注文とトークンを注文サービスに送ります。
5. 注文サービスはシークレットキーを使ってプロバイダーの API 経由でトークンに請求し、プロバイダーはカードネットワーク経由でオーソリを要求します。
6. Webhook が結果を確認します。注文サービスはトークン ID、カードブランド、下 4 桁を保存します。

加盟店のどのシステムも PAN を保存、処理、伝送しないため、加盟店に CDE はありません。独自の評価を受けているプロバイダーは、要件 12.8 に基づいて管理します。決済ゲートウェイ連携図では、同じチェックアウトをシーケンスとして示しています。EC プラットフォームの構成図では、それをカタログ、カート、注文の各サービスの中に位置づけています。

Web アプリはスコープに残ります。Web アプリや、それが読み込むスクリプトを改ざんした攻撃者は、iframe を偽のフォームに差し替えられるからです。この攻撃、つまりイースキミングが、v4.0 で 6.4.3（決済ページのスクリプトの承認、整合性確認、インベントリ化）と 11.6.1（決済ページの変更検知）が追加された理由です。標準はデプロイツールもシステムコンポーネントに数えるため、CI/CD もスコープ内です。

トークンとスコープに残るもの

PCI SSC のトークナイゼーションガイドラインは、デトークナイズと PAN の保存を含むトークナイゼーションシステムを CDE に含めます。トークンだけを保持するシステムは、トークンから PAN を復元できず、デトークナイズを要求したり vault に到達したりできず、CDE からセグメント化されていれば、スコープ外になりえます。

vault はプロバイダーが所有するため、注文サービスとデータベースは条件を満たせますが、注意点があります。再利用可能なトークンとシークレット API キーがあれば、請求を作成できてしまいます。ガイダンスは、取引を開始できるトークンは「PCI DSS のスコープに入る可能性がある」とし、加盟店にアクワイアラーへの確認を勧めています。キーは他の本番シークレットと同様に守ってください。

セグメンテーションとそのテスト方法

セグメンテーションは通常、ファイアウォールルール、セキュリティグループ、または別々のクラウドアカウントを指します。それが CDE を分離している場合、要件 11.4.5 は、資格のある独立したテスターによる、これらの統制のペネトレーションテストを、少なくとも 12 か月ごとと変更後（サービスプロバイダーは 6 か月ごと）に求めます。1.2.3 のネットワーク図には、論理ネットワークトポロジーと同じように、各セグメントとその間の統制を描きます。

ここでは加盟店に CDE がないため、重要な境界はチェックアウトページを変更できるものすべてを囲みます。注文サービス、ウェアハウス、およびそれらの認証情報が、ストアフロントにデプロイできてはいけません。

アーキテクチャの選択と SAQ の種類

チェックアウトの設計が自己評価質問票（SAQ）をほぼ決めます。確認するのはアクワイアラーです。

2025 年 1 月の SAQ A 改訂では、質問票から 6.4.3 と 11.6.1 が削除され、適格性基準が追加されました。加盟店は「自社サイトが、加盟店の e コマースシステムに影響しうるスクリプトによる攻撃を受けにくい」ことを確認します。FAQ 1588 は 2 つの方法を認めています。6.4.3 や 11.6.1 のような手法でページを保護するか、指示どおりに実装した場合にプロバイダーのソリューションがそれを満たしているというプロバイダーの確認を得るかです。この基準は埋め込み iframe に適用され、リダイレクトには適用されません。どちらも Approved Scanning Vendor による四半期ごとのスキャンが必要です（FAQ 1604）。自社ページが描画するカードフィールドが 1 つでもあれば、SAQ A は使えません。

図を最新に保つ

標準は「アカウントデータの流れまたは保存方法の変更」をすべて重大な変更になりうるものとみなします。決済手段、プロバイダー、チャネル、チェックアウトのスクリプト、あるいは決済データに触れるエクスポート、ログパイプライン、サポートツールを追加するたびに、図を更新してください。

サポートチケットやチャットに含まれるカード番号にも注意してください。そのような意図しないチャネルについて、v4.0.1 は、CDE に組み込むか、データを安全に削除してそのチャネルが使われないようにするよう定めています。図には日付、作成者、承認者を記載してください。生きたドキュメントのワークフローで、オーナーと更新のトリガーを扱っています。

カード会員データフロー図

図の読み方は次のとおりです。

• 3 つのゾーン。 赤はプロバイダーの CDE、琥珀色はチェックアウトページを変更できる加盟店システム、青緑はトークンだけを扱うシステムです。
• 色はデータに従います。カードデータは赤、トークンは青緑、どちらでもなければ灰色で、破線は非同期を表します。
• 番号は 1 回の購入に沿っています。 赤い経路は加盟店のフレームには入りません。
• 2 つのノートが残るリスク、つまりページのスクリプトと再利用可能なトークンを示しています。
• 凡例がデータの分類とスコープをまとめています。

PCI DSS データフロー図を分かりやすく描く

すべてのフローとストアにラベルを付けます。

• スコープはフレームで描き、1.2.3 のガイダンスにあるとおり、スコープ外の領域には網掛けをします。
• チャネルごとに 1 枚の図を描きます。e コマース、電話、端末は異なるためです。
• 目立たない経路も含めます。返金、チャージバック、バックアップ、ログ、サポートツールです。
• ネットワーク図と一致させます。データフロー図はネットワーク図を補うものです。
• 省くものは、アカウントデータもトークンも含まない呼び出しです。

よくある間違いは、トークンしか扱わないシステムを PAN の線が通ることです。これにより、書類上はそれらがスコープに入ってしまいます。表記法はデータフロー図の例、信頼境界は脅威モデリングの解説、似た棚卸しは GDPR データマップを参照してください。

Archboard で作る

1. Google または GitHub でサインインし、ダイアグラムを作成します。
2. 顧客のブラウザー用に、C4 モデルパックから人物を追加します。
3. プロバイダー（赤）、スコープ内の加盟店（琥珀色）、スコープ外の加盟店（青緑）用に、基本パックからフレームノードを 3 つ追加します。
4. プロバイダーのフレーム内に、ホスト型フィールドと決済 API 用の外部システムノードを C4 モデルパックから 2 つ、セキュリティパックからボールトを 1 つ追加します。カードネットワーク用の外部システムはフレームの下に置きます。
5. 琥珀色のフレーム内に、Web アプリ用のコンテナを C4 モデルパックから、パイプラインを DevOps パックから追加します。
6. 青緑のフレーム内に、注文サービス用のコンテナと、データパックの Postgres ノードとデータウェアハウスノードを追加します。
7. ラベル付きのエッジを描きます。カードデータは赤、トークンは青緑、それ以外は灰色で、Webhook とエクスポートは破線にします。
8. 基本パックから Markdown の凡例を、基本のテキストノートを 2 つ追加します。

1.2.3 のネットワーク図には、Terraform コンバーターが .tf ファイルから最初のたたき台を作ります。決済フロー図のページではシーケンス図を紹介しています。

この例で使うダイアグラムノードは 14 個で、Free プランの範囲に収まります。

よくある質問

PCI DSS ではデータフロー図が必須ですか？ はい。v4.0.1 の要件 1.2.4 は、すべてのアカウントデータフローを示す正確なデータフロー図を、最新の状態に保つことを求めています。SAQ A には含まれず、SAQ A-EP、SAQ D、完全な評価には含まれます。

PCI のネットワーク図とデータフロー図の違いは何ですか？ ネットワーク図（1.2.3）は CDE と他のネットワークとの接続を示します。データフロー図（1.2.4）は、アカウントデータがどこを通り、どこに保存されるかを示します。両者は一致している必要があります。

iframe やホスト型決済ページを使えば、自社サイトは PCI のスコープから外れますか？ いいえ。カードデータは自社システムに入りませんが、iframe を埋め込むページは攻撃を受けうるため、SAQ A では四半期ごとの ASV スキャンと、iframe の場合はスクリプト攻撃への対策が求められます。

トークンだけを保存するシステムは PCI DSS のスコープ外ですか？ トークンから PAN を復元できず、システムがトークナイゼーションシステムからセグメント化されていれば、スコープ外になりえます。取引を開始できるトークンは、依然としてスコープに入る可能性があります。

PCI のスコープと図はどのくらいの頻度で見直すべきですか？ アカウントデータフローが変わるたびにデータフロー図を更新し、スコープは少なくとも 12 か月ごと、および重大な変更後（12.5.2）に確認します。サービスプロバイダーは 6 か月ごとです。

無料で始める — 1 シート、クレジットカード不要。