PCI DSS SAQ-A から SAQ-D へ移行する業務システムで確認すべき 7 項目

1. カード情報の取り扱い境界を再確認する

SAQ-A の前提は 「カード情報はサーバー側に一切渡らず、決済代行のホスト型ページに完全に外出しされている」 です。

ところが、要望や仕様変更でフォーム入力の一部をサーバー側で中継する、エラー画面でカード番号の一部を表示する、決済代行の API レスポンスのうち PAN を含むものをログに残す、といった小さな改修で SAQ-A の前提が崩れます。

対応として、サーバー側で受け取る決済関連データを「トークンと表示用末尾 4 桁、ブランド名のみ」 に絞る境界を明文化し、テストでも境界外のデータがサーバーに渡らないことを確認します。境界を超える場合は、SAQ-A-EP / SAQ-D を前提とした設計に切り替えるか、業務要件側を切り直すべきです。

2. トークン化と非保持の徹底

決済代行が提供するトークン (Stripe であれば cus_xxx / pm_xxx、Square であれば cnon:xxx) のみを保管し、PAN・有効期限・CVV はサーバー側の DB・ログ・キャッシュ・APM・エラートラッキング (Sentry 等) に一切残らない状態を作ります。

具体的にはアプリのログ出力を見直し、HTTP ボディや決済代行 SDK の dump がそのままログに出ていないか、Sentry の breadcrumbs に決済 form の入力値が記録されていないか、CDN や WAF のログに POST body が記録されていないかを確認します。

3. アクセスログ・操作ログの 90 日以上保管

PCI DSS の要件として、認証・特権操作・カード情報関連の操作ログを 90 日以上オンラインで参照可能にし、1 年以上の長期保管が求められます。

業務システムでは、管理画面ログイン・権限変更・決済情報参照・払い戻し・委託先設定変更などの操作を、操作者・対象・日時・前後値で記録します。改ざん防止のために、書き込み専用の保管先 (S3 + Object Lock、CloudWatch Logs の retention 設定等) に転送し、削除権限を本番権限と分離します。

4. ロール権限の最小化と職務分掌

管理画面で 「全部できる管理者」 のロールを使い回していると、SAQ-D の段階で職務分掌違反として落ちます。決済情報参照・払い戻し・権限付与・設定変更・運用ユーザー管理を別ロールに分け、最小権限で割り当てる設計に直します。

運用側で 「全権限ロールを 1 人だけが持ち、必要時に他メンバーに付与する」 ような棚卸し手順を持つだけでも、監査時の説明はかなり通りやすくなります。

5. テスト環境と本番環境のデータ分離

テスト環境に本番のカード情報・PAN を持ち込まないことが原則ですが、 「再現テストのために本番の取引データの一部をテストに持ってきた」 ような運用が残っていると、SAQ-D 移行のタイミングで指摘されます。

テスト用には決済代行のテストカード番号・テスト用トークンのみを使い、本番データのコピーが必要な場合はマスクと匿名化を必ず通します。データベース・ログ・ファイルストレージ・バックアップまで含めた分離を設計に入れます。

6. 外部委託先 (決済代行・SaaS) の評価記録

決済代行・メール配信・SMS・分析ツール・エラートラッキング・CDN など、決済処理周辺で利用している外部委託先について、PCI DSS 上のスコープ・委託範囲・契約条件・AOC (Attestation of Compliance) 取得状況を一覧化し、年次で更新する仕組みを業務システム側で持ちます。

SaaS 単位で 「これは決済代行」 「これは marketing 用、決済情報触らない」 が明確になっていないと、監査時の説明が二度手間になります。

7. 監査前の自社内ギャップ分析

SAQ-D 移行の正式な評価前に、自社内で項目別のギャップ分析を 1 回回します。設計図・データフロー図・操作ログサンプル・権限一覧・委託先一覧・運用手順書を一度棚卸ししておくと、評価者からのヒアリングがスムーズになり、指摘事項も初動で潰せます。

ギャップ分析は、業務システムの構成を把握している外部レビュアーを 1 回入れることで、社内では気付けない盲点が見つかりやすくなります。