メニュー

PCI DSS テストデータ入門: 開発環境も対象になる理由

PCI DSS はテスト環境を例外扱いしません。保存できるデータと禁止されるデータの違い、マスキングとトークン化、合成データで環境を保つ方法を整理します。

公開日

  • コンプライアンス
  • テストデータ

PCI DSS テストデータという言い方には、少し意外な響きがあります。カード業界のデータ保護基準である PCI DSS は、本番環境だけでなく開発やテストの環境にも適用されるからです。テスト用だからといって本物のカード情報を置いてよい理由にはなりません。この記事では、基準が何を求めているのか、テスト環境でなぜ合成データを使うのか、そして現場でどう運用するのかを説明します。

データ保護基準はテスト環境も対象にする?

PCI DSS は、カード会員データを扱うすべての環境に対して、その扱いの水準を定めています。適用範囲はシステムの役割ではなく、データが存在する場所で決まります。したがって、本番と同じ構造のデータを複製した検証用のデータベースも、そこに本物のカード情報があれば対象になります。

「テスト環境だから」という理由づけが通用しないのは、複製の過程で保護の水準が落ちるからでもあります。本番では厳しく管理されていた情報が、複製された瞬間に別の場所へ移り、別の権限の下に置かれます。漏えいが起きたときの影響は、本番と変わらないか、むしろ大きくなります。

保存してよいデータと禁止されるデータ?

基準の理解で最初につまずくのが、データの種類による扱いの違いです。カード番号や有効期限は、条件を満たせば保存できます。一方、セキュリティコードや磁気ストライプの完全なデータは、認証が完了した時点で保存できません。例外はありません。

データの種類 承認後の保存
カード番号 条件を満たせば可
有効期限 条件を満たせば可
カード名義 条件を満たせば可
セキュリティコード 不可
磁気ストライプの完全なデータ 不可
PIN の関連データ 不可

この区別を踏まえると、テスト環境に複製してよい情報の範囲も自然に決まります。そもそも保存が禁じられている種類のデータは、テスト目的であっても複製してはなりません。

保存する場合に求められる保護

保存が許されるカード番号であっても、そのまま置いてよいわけではありません。基準は、保存時の保護と、表示時の取り扱いの両方を求めます。保存するなら暗号化などの手段で読めない状態にし、画面に表示するときは中央部分を伏せ、先頭 6 桁と末尾 4 桁だけを見せるのが一般的な方法です。

この表示の規則は、テスト環境の画面にも当てはまります。管理画面やデバッグ用の一覧で番号が丸見えになっていると、そこが保護の穴になります。伏せ字の処理を表示側に任せると、新しい画面が追加されたときに漏れます。表示の直前に一元的に処理する仕組みを用意しておくほうが安全です。

トークン化という選択肢

もうひとつの有力な方法が、カード番号をそのまま持たずに、決済事業者が発行する参照用の値に置き換えて保持する方法です。この参照値は単独では使えず、元の番号は事業者側の管理下に留まります。自社の環境に存在する機密情報そのものを減らせるため、適用範囲を狭める効果が大きい手法です。

トークンを使う場合も、対応表の管理は必要です。参照値と元の番号のひも付けを自社で持ってしまうと、元の番号を持つのと同じことになります。参照値だけを保存し、必要なら事業者の仕組みを通じて処理する、という原則を崩さないでください。

テスト環境には合成データを使う

基準がもっとも明確に求めているのは、開発とテストの環境で本物のカード会員データを使わないことです。代わりに合成データ、またはトークン化されたデータを使います。合成データとは、実在の口座に対応しない、計算で作られた値のことです。

合成データには副次的な利点もあります。件数を自由に作れるので、境界値や大量データの検証がしやすくなります。また、特定の番号をテストの期待値として固定できるため、失敗の原因をデータの揺れに求めずに済みます。生成した番号は構造としては妥当ですが、いずれも実際には発行されていない値であり、実在のカードとして扱ってはなりません。

開発者向け: 環境分離と確認項目

運用に落とすときは、まず本番データがテスト環境へ流れ込む経路を列挙します。よくある経路は、本番からの定期的な複製、障害調査のための一時的な取り込み、問い合わせ対応の際の手作業による転記です。このうち手作業の経路が、もっとも制御しにくい部分です。

次に確認したい項目を挙げます。テスト環境の接続情報が本番と明確に区別されているか。テスト用の鍵と本番の鍵が同じ場所に置かれていないか。ログにカード番号やセキュリティコードが出ていないか。開発者に与える権限が必要最小限に絞られているか。不要になったテストデータが定期的に削除されているか。

これらは特別な作業ではなく、ふだんの開発の進め方の延長で確認できます。とくに、テストデータの出所を記録しておく習慣は有効です。出所がたどれないデータは、本物かどうかを後から判断できません。合成データの作り方と使い分けは テストカード番号の基礎 にまとめています。番号そのものを用意するときは テスト用クレジットカード番号生成 を利用してください。

次のステップ

まず、テスト環境に存在するカード関連のデータを棚卸しし、それぞれが合成データかトークンか、あるいは本物かを分類してください。本物が見つかった場合は、それが入り込んだ経路を特定し、塞ぐところから始めます。次に、セキュリティコードが保存され得る場所がないかを、ログと一時ファイルまで含めて確認しましょう。保存が禁じられている種類のデータの扱いは セキュリティコードの役割 で詳しく説明しています。

続けて読む

テスト用クレジットカード番号生成の関連記事