pci-dss-compliance

PCI-DSS コンプライアンス

概要

PCI-DSS（Payment Card Industry Data Security Standard）は、カード決済を受け付けるすべての加盟店に適用されます。コンプライアンス義務の範囲と複雑さは、ほぼ全面的にカードデータがシステム内をどのように流れるかによって決まります。ホスト型の決済フォーム（Shopify Payments、Stripe Checkout、PayPal hosted）を使用する加盟店は、最も簡単な評価（SAQ A、約22項目）の対象となります。カスタムの決済ページを運用する加盟店は、最も複雑な評価（SAQ D、約330項目）の対象となります。PCI に関する最も重要な判断は、対象範囲を最小限に抑える決済方法を選ぶことです。

このスキルを使用する場面

• クレジットカード決済を受け付けており、PCI コンプライアンスの対象範囲を確認する必要がある場合
• SAQ A、SAQ A-EP、SAQ D、またはその他の質問票の種類から選択する場合
• PCI の対象範囲を縮小するためにトークン化を導入する場合
• PCI 監査に備えて、ログ記録、監視、アラートのインフラを整備する場合
• QSA（Qualified Security Assessor）監査の準備をする場合、または SAQ を記入する場合

主な手順

ステップ 1：決済方法に基づいて PCI の対象範囲を特定する

PCI コンプライアンスにおける最も重要な判断は、カードデータが環境内をどのように流れるかです。

連携方法	SAQ の種類	管理項目の概数	対象となる加盟店
完全ホスト型のチェックアウト（Shopify Payments、Stripe Checkout、PayPal hosted）	SAQ A	約22	カードデータがサーバーに一切触れません。顧客は決済処理業者の決済ページにリダイレクトされます
自社ページでの JavaScript トークン化（Stripe Elements、Braintree Drop-in）	SAQ A-EP	約191	カードデータは自社ページ上の iframe に入力されます。サーバーでカード番号の生データを扱うことはありません
サーバーでカードデータを扱う	SAQ D	約330	カードデータがアプリケーションサーバーを経由します

推奨：可能な限り、常に SAQ A を選択してください。 Shopify Payments、Stripe Checkout、または PayPal hosted のチェックアウトを使用してください。SAQ D から SAQ A に移行すると、年間のコンプライアンス対応の負担を約85％削減できます。

ステップ 2：プラットフォーム別の PCI 設定

---

Shopify

Shopify は PCI-DSS レベル1のサービスプロバイダーです。Shopify Payments、または Shopify のチェックアウトを通じて利用できる決済ゲートウェイを使用すると、決済処理環境の PCI コンプライアンスは Shopify が担います。

Shopify 加盟店の PCI 対象範囲：

• Shopify のホスト型チェックアウトと Shopify Payments を使用する場合：SAQ A — すべて Shopify が対応します
• 加盟店側の責任は、Shopify 管理画面へのアクセスを安全に保つこと（強力なパスワード、2FA）、アプリやスプレッドシートにカード会員データを保存しないこと、サードパーティ製アプリのセキュリティを確認することのみです

Shopify で SAQ A を完了する手順：

1. PCI Security Standards Council（pcisecuritystandards.org）から SAQ A をダウンロードします
2. Shopify の加盟店向け PCI コンプライアンス資料は help.shopify.com/en/manual/payments/pci-compliance にあります
3. Shopify はプラットフォームの Attestation of Compliance（AoC）を提供しています。アクワイアラーへの証拠として使用してください

引き続き加盟店が担う主な管理項目：

• 管理者アカウントのセキュリティ：すべての Shopify スタッフアカウントで 2FA を有効にします（Settings → Users → require 2FA）
• Shopify の外部にカード番号を保存しないこと（スプレッドシートやサードパーティ製データベースも不可）
• インストール済みアプリのデータセキュリティ対策を確認すること

---

WooCommerce

WooCommerce 自体は PCI に準拠していません。準拠状況は、ホスティング、決済ゲートウェイ、実装方法によって異なります。

対象範囲を最小限にするには、ホステッド型決済ゲートウェイを使用します。

オプション A — Stripe Checkout（ホステッド型リダイレクト） → SAQ A

// Use WooCommerce Stripe Gateway in "Stripe Checkout" mode
// In WooCommerce → Settings → Payments → Stripe → Stripe Checkout: enable
// Customer is redirected to stripe.com for payment; SAQ A applies

オプション B — WooCommerce で Stripe Elements を使用 → SAQ A-EP

• 公式の WooCommerce Stripe プラグインは、デフォルトで Stripe Elements を使用します
• カードデータは Stripe の iframe 内で取得され、サーバーが受け取るのは決済トークンのみです
• これは SAQ A-EP です（SAQ A より多くの管理策が必要ですが、SAQ D よりは大幅に少なくなります）

SAQ A-EP に準拠するための WooCommerce ホスティング要件： ウェブホスティングは、PCI の最低要件を満たす必要があります。

1. SSL/TLS：ホスティングプロバイダーが TLS 1.2 以降と最新の証明書を使用していることを確認します
2. パッチ適用：WordPress、WooCommerce、プラグイン、PHP を最新の状態に保ちます
3. マネージドホスティング：WP Engine、Nexcess、Kinsta は、関連する管理策を備えた PCI 対応のマネージドホストです
4. Wordfence：マルウェアスキャンと WAF 保護のために Wordfence Security をインストールします（要件 5、6）

WooCommerce の PCI 準拠で確認する項目：

• WooCommerce の注文メモやカスタムフィールドにクレジットカード番号が記録されていないこと
• WooCommerce のデバッグログに決済データが記録されないこと（本番環境ではデバッグログを無効にします）
• すべての管理者アカウントで、強力かつ固有のパスワードと 2FA が使用されていること
• セキュリティパッチが公開されてから 30 日以内に、すべてのプラグインが更新されていること

---

BigCommerce

BigCommerce は PCI-DSS レベル 1 認定プラットフォームです。BigCommerce のホステッド型チェックアウトと、サポート対象の決済ゲートウェイを使用すれば、SAQ A の範囲に収まります。

BigCommerce でコンプライアンスを完了するには：

• BigCommerce は、プラットフォームのインフラストラクチャに関する AoC を提供します
• BigCommerce Payments を利用する加盟店、または BigCommerce のチェックアウトを通じてサポート対象の決済ゲートウェイを利用する加盟店には、SAQ A が適用されます
• カスタム決済連携やカスタムチェックアウトページを使用する場合は、対象範囲が広がります。QSA に相談してください

BigCommerce の主な設定：

1. Store Settings → Security に移動し、すべてのページで HTTPS が強制されていることを確認します
2. Account Settings → Users に移動し、すべての管理者アカウントに固有の ID と強力なパスワードが設定されていることを確認します
3. アカウントのセキュリティ設定で、管理者アカウントの 2FA を有効にします
4. インストール済みアプリを確認し、必要最小限の権限のみを各アプリに付与します

---

カスタム／ヘッドレス

カスタムストアフロントでは、決済処理の連携方法によって PCI の対象範囲が決まります。SAQ A-EP の範囲に収めるには、Stripe Elements または Braintree Drop-in UI を使用します。

Stripe Elements を使用した SAQ A-EP の実装：

// Client-side: Stripe handles card data in an iframe — your code never sees card numbers
const stripe = await loadStripe(process.env.NEXT_PUBLIC_STRIPE_PUBLISHABLE_KEY!);
const elements = stripe.elements({ clientSecret });
const paymentElement = elements.create('payment');
paymentElement.mount('#payment-element');

// On submit — Stripe creates a PaymentMethod on their servers
const { error, paymentIntent } = await stripe.confirmPayment({
  elements,
  confirmParams: { return_url: `${window.location.origin}/order-confirmation` },
});
// Your server never receives a card number — only a paymentMethodId or paymentIntentId

SAQ A-EP の主な管理策（カスタムストアフロント）：

# Requirement 4: TLS 1.2+ only, strong cipher suites
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

決済ページのコンテンツセキュリティポリシー（PCI-DSS v4.0 の要件 6.4.3）：

// Strict CSP on checkout pages — only authorized scripts allowed
const csp = [
  `default-src 'self'`,
  `script-src 'self' 'nonce-${nonce}' https://js.stripe.com`,
  `frame-src https://js.stripe.com https://hooks.stripe.com`,
  `connect-src 'self' https://api.stripe.com`,
  `object-src 'none'`,
].join('; ');
response.headers.set('Content-Security-Policy', csp);

監査ログ（要件 10）：

// Log every authentication event, admin action, and access to payment data
interface AuditEntry {
  timestamp: string;
  userId: string;
  userIp: string;
  action: string;
  resource: string;
  outcome: 'success' | 'failure';
}
// Ship logs to an immutable store: CloudWatch Logs, Datadog, or S3 with Object Lock
// Requirement 10.7: Retain logs for 12 months; 3 months immediately available

PCI-DSS 管理策チェックリスト：

要件	主なエンジニアリングタスク
要件 3：保存データの保護	生のカード番号を保存しない。Stripe／Braintree のトークンのみを使用する
要件 4：通信の暗号化	TLS 1.2 以降、HSTS ヘッダー、混在コンテンツなし
要件 6：安全な開発	CI で依存関係スキャン（npm audit、Snyk）を実施。SAST。決済ページ上のスクリプト一覧を作成
要件 7～8：アクセス制御	ロールベースのアクセス制御、固有の ID、管理者の MFA、パスワードポリシー
要件 10：ログ記録	すべての認証イベント、管理者の操作、CDE へのアクセスを、ユーザー ID、タイムスタンプ、IP アドレスとともに記録
要件 11：脆弱性管理	ASV による四半期ごとの外部スキャン、年次の侵入テスト

ベストプラクティス

• カード会員データ環境（CDE）を最小化する — ホスト型の決済フォームを使用してSAQ Aの要件を満たし、管理項目を約330項目から約22項目に減らします。これはPCIに関する最も効果の大きい判断です
• カード番号をそのまま保存しない — 必ずトークン化を使用します。カードデータを一切扱わなければ、ほとんどのPCI要件はサーバーに適用されません
• ログを改ざん不能なストレージに送信する — 追記専用のログ保存先（Object Lockを有効にしたS3、CloudWatch Logs）を使用し、攻撃者が監査証跡を改ざんできないようにします
• すべての管理者アクセスにMFAを必須にする — PCI-DSS v4.0の要件8.4.2では、CDEへのすべてのアクセスにMFAを義務付けています
• 脆弱性スキャンを自動化する — CI/CDで依存関係の監査を実行し、四半期ごとにASVスキャンを予定します。手動のプロセスは見落とされることが常です
• スクリプトの一覧を文書化する — PCI-DSS v4.0の要件6.4.3では、決済ページ上のすべてのスクリプトについて、業務上の理由を含む文書化された一覧が必要です

よくある落とし穴

問題	解決策
SAQ Aを選択したが、Stripe Elementsを使用している	Stripe Elements（ページ上で実行されるJavaScript）はSAQ AではなくSAQ A-EPに該当します。SAQ Aの要件を満たすのは、完全にホストされたリダイレクト（Stripe Checkout）のみです
本番環境でデバッグログが有効になっており、決済データが記録される	本番環境ではWordPress/WooCommerceのデバッグログを無効にします。WC_DEBUGとWP_DEBUGはfalseにする必要があります
ロードバランサーでTLS 1.0/1.1が有効なままになっている	nmap --script ssl-enum-ciphers -p 443 yourstore.comで確認します。ロードバランサーとCDNでTLS 1.0/1.1を無効にします
チェックアウトページ上のサードパーティ製スクリプトが一覧化されていない	PCI v4.0では文書化された一覧が必要です。ブラウザーの開発者ツールで監査し、決済ページから不要なスクリプトを削除します
インシデント対応計画がない	PCI要件12.10.1では、毎年テストする文書化されたIR計画が必要です。これまでインシデントが発生したことがなくても、基本的な計画を作成します

関連スキル

• @secure-checkout
• @fraud-detection
• @account-security
• @financial-audit-trail