3Dセキュア認証中にカードを保存しないようにして、PCI DSSに準拠するには？

Question

私はカード所有者が私たち自身のウェブサイトで彼のカード詳細を入力する支払いソリューションを実装しています。

カード所有者の追加認証には3Dセキュアを使用する必要があります。

私たちの決済ゲートウェイは、次の手順でそれを実装します。

これらのパラメーターを使用してフォームが作成されます：
- 販売者ID
- カードの詳細
- お支払い金額
このフォームを送信すると、ユーザーは3Dセキュア認証ページにリダイレクトされます。その後、彼は通常、SMSを受け取ります。これには、支払いを認証するために入力する必要がある秘密のコードが含まれます。
認証が成功すると、ユーザーはいくつかのパラメーターと共にWebサイトにリダイレクトされます。パラメーターの1つは認証IDです。
次に、次のパラメータを使用して、カードのサーバー間認証を実行します。
- 販売者ID
- カードの詳細
- お支払い金額
- 上記で受け取った3Dセキュア認証ID

すべて良い。しかし問題がある。

PCI DSSに準拠するには、カード番号を保存することはできません。処理してすぐに破棄することができます。

しかし、上記の実装が原因で、どうすればnotができるのかわかりません。

ユーザーが私のウェブサイトでカードの詳細を入力したとします。ステップ1で3Dセキュア用のWebフォームを生成するフォームがサーバーに送信されます。そのため、フォームを生成し、それをユーザーのブラウザーに提示して、自動的にポストし、カードの詳細を破棄します。

これで、ユーザーは認証IDを使用して3Dセキュアページから私のウェブサイトに戻ります。良いことですが、それを保存することができなかったため、承認を行うためのカードの詳細はもうありません。

私は何を取りこぼしたか？

bbozo · Answer

通常、支払いAPIは3つのカテゴリに分類されます。

販売者側でホストされ、販売者に送信された支払いページ
販売者側でホストされている支払いページと支払いプロバイダーに送信されたカードデータのみ（通常はJavaScript SDKを介して）
支払いプロバイダー側でホストされ、支払いプロバイダーに送信された支払いページ、商人は承認が成功すると通知を受け取ります

支払いプロバイダーが何かを大いに台無しにしないと仮定すると、オプション2と3によってPCI DSSのスコープから完全に外れるはずです。

オプション2を使用すると、PCI DSSスコープに属さないため、クレジットカードデータは使用されませんが、永続的または一時的なトークンが割り当てられます支払いプロセッサのJavaScript SDKによるトランザクション（e4baf901-252b-4818-b826-7f89cad884dbなど）。これ以外は、3dsワークフローはオプション1とまったく同じです。APIリクエストにpan属性ではなくpan_tokenがあるだけです。例としてBraintreeのホストフィールドAPIを参照してください https://developers.braintreepayments.com/start/hello-client/javascript/v

オプション3を使用すると、PCI DSSスコープではなく、実際には何もせず、クライアントを支払いプロバイダー、または支払いプロバイダーのページをiframeなどで開きます。この種のAPIの例を次に示します。 https://ipgtest.webteh.hr/en/documentation/form

オプション1

それは別の話です。はい、PCI DSSスコープにいます。はい、有効な証明書が必要です。地域によっては、PENテストを実行し、セキュリティで保護された組織とその他すべての「悪いもの」、パスワードを持っている必要がありますポリシー、接続のためのホストのジャンプ、安全な（そしてできればセグメント化された）ネットワーク、ログに何も表示されていないことの確認、「すべてのネットワーク構成の拒否」、毎年の監査など.

この道を進んだ場合（そして、なぜそうすべきなのかが本当にわからないのですが）、少なくともHSMを回避し、暗号化キーなどについて心配することができます。つまり、PCIを保存しないでくださいDSSハードドライブへのデータ。

通常、これを回避する最も簡単なソリューションは、クレジットカードデータを1時間以内の有効期限ポリシーでmemcacheに保存することです（これまでに行ったすべての実装で15分は機能します）。トリックは、それをディスクに書き込まないことです（そのため、たとえば、ほとんどの実装ではredisではありません）が、memcacheのようなメモリストアは公平なゲームです。アクセスキーが、uuid（つまり、e4baf901-252b-4818-b826-7f89cad884db）のように大きくて安全であることを確認してください。

実際には常にそうであるとは限りません...

歴史的に、決済会社はマーチャントのPCI DSSコンプライアンスについて非常に怠惰でした。「PANでいっぱいのデータベース」と「システムに触れるPANがない」との唯一の実用的な違いは、「自己評価の質問の数」でした。アンケート」（PCI DSS加盟店のSAQ）。

販売店が盗難カードの一般的なPOSであると特定された非常に特殊な場合にのみ、販売店は非常に非常に不本意であり、クレジットカード会社によるPCIを受けることについて多くの「理解」を強いられましたDSS lvl2/lvl1コンプライアンス監査。

ただし、これは一連の違反により変更されており、少なくとも一部の地域（SEEヨーロッパなど）では、決済会社はオプション1から完全なPCIを持っていないすべての加盟店への移行を主張していますDSSコンプライアンス証明書（SAQアンケートの「X」マークだけではありません）。

Richard · Answer

カード番号を保存せずに3D検証を行う方法、または説明したプロセスがPCIに準拠しているかどうかを尋ねていますか？

前者の場合は、支払いゲートウェイプロバイダーに直接問い合わせて、正しく機能していることを確認するか、ドキュメントへのリンクを提供して、技術的な支援を受けられるようにすることをお勧めします。

後者の場合は、状況によって異なります。あなたはどのSAQでどのレベルですか？またはRoCを行っていますか？ SAQ Aを目指している場合、その通りです。PANはまったく触れられません。SAQA-EPに行く場合は、そのまま保持しても問題ありません。ブラウザーは一時的に使用されます。サーバーで発生する場合はSAQ Dです。つまり、使用する範囲によって異なります。

完全なページリダイレクトを行う必要がある場合、技術的にはiframeやajaxを使用してこれを実行できる場合があります。

Jonah Benton · Answer

PCIコンプライアンスの定義と3D Secureが提供する機能との間に矛盾はありません。

商人とその取得銀行との間の契約の条件として、詐欺防止スキームである3Dセキュアの利用が商人に要求されるかもしれない。この契約により、マーチャントはクレジットカードを収集して銀行に提供し、場合によっては支払いプロセッサを介して、マーチャントの銀行口座に入金された資金に対して料金を支払うことができます。

この契約には、PCIコンソーシアムによって作成されたすべてのルール（ガバナンス、アーキテクチャ、開発など）に準拠することを商人に要求する条項も含まれています。これが、PCIコンソーシアムによって作成されたすべてのルールを監査可能な方法で遵守することがPCI準拠であることの意味です。

そのため、3Dセキュアの使用は、PCIコンプライアンスのコンポーネント、一部になり得ます。

現在、PCIルールは「範囲内」システムと呼ばれるシステムに適用されます。カードデータに対して任意の期間にわたって可視性を備えたシステムはPCIルールの対象となり、特定の可視性の定義について、カードの可視性を備えた対象範囲内のシステムに対してネットワーク可視性を備えたシステムも対象範囲となります。

PCIは妊娠のようなもので、途中はありません。システムがカードを見る場合、それらは範囲内にあり、これらのルールの順守が必要です。

PCIもまた、病気のようなもので、広がります。システムがカードを見る場合、それは範囲内にあり、カードを見るシステムを見ることができるすべてのシステムも範囲内にあります。

繰り返しますが、あなたが説明していることには矛盾はありません。ユーザーが制御するシステムで実行されているアプリケーションは、カードを見ることができます。これらのシステムとアプリケーションは対象です。物語の終わり。

Polynomial · Answer

この全体的な状況は間違っているようです。

このような環境でのユーザーの購入またはトランザクションの一般的なフローは次のとおりです。

ベンダーサイトは支払いプロバイダーAPIを呼び出し、トランザクションの詳細を渡します：ベンダーID、製品名と識別子、コストの内訳、顧客名と住所（わかっている場合）、場合によってはリダイレクトターゲットなどのその他の技術情報。
支払いプロバイダーAPIは、このトランザクションの支払いページのURLを返します。
ベンダーは、リダイレクトまたはiframeのいずれかでユーザーに支払いページを表示します。準拠方法の詳細については、 Visaガイドラインを参照してください。このフォームとその内容は決してベンダーサーバーまたはインフラストラクチャに到達しないことに注意してください。それらは、支払いプロバイダーによって直接ホストされます。
フォームにはユーザーが記入し、PCI DSSでのインライン処理を必要とするクレジットカードの詳細が含まれています。
フォームは支払いプロバイダーに投稿されます。このデータがベンダーに直接届くことはありません。これを行うと、インフラストラクチャがPCI DSSの範囲に含まれ、直接準拠する必要があり、サードパーティの支払いプロバイダーの目的全体が無効になるためです。
支払いプロバイダーは詳細を検証し、資金を引き出そうとします。
顧客の銀行が3Dセキュアまたは同様の機能を必要とする場合、追加の検証のために別のリダイレクトが発生します。
3Dセキュア検証が成功した場合、支払いプロバイダーはカードから支払いを取り、ベンダーに送金するための資金を保持します。
支払いプロバイダーは次のいずれかです。
- リダイレクト方式の場合、ユーザーのブラウザをベンダーの完了ページにリダイレクトし、支払いが成功または失敗したことをベンダーに証明する暗号で署名されたステータス（通常はSAML）を返します。
- iframeなどの場合、ベンダーの外部ページは、支払いプロバイダーAPIをクエリするスクリプトをポーリングして、完了ステータスを確認します。支払いが完了すると、署名されたメッセージがベンダーに返され、支払いが成功したか失敗したかを証明します。
ステータスデータには通常一部のカードデータが含まれますが、最も重要なのは、PANをマスクして、PCI DSSガイドライン内で「部分的なPAN」と見なされるようにして、レンダリングすることです。 PCIスコープ外。
これで、ベンダーは「購入いただきありがとうございます」ページを表示し、完了したトランザクションを記録できます。

この手順には差異がありますが、重要な機能は、PANおよびCVV/CV2（およびその他の機密フィールド）がベンダーによって実際に処理または保持されることはありません。支払いプロバイダーは、これらすべてを処理します。「カードを記憶する」などの機能を使用している場合でも、通常の実装では、完全なPANが支払いプロバイダーによって保存され、マスクされたPANがベンダーによって保存され、顧客がベンダーがPANが何であるかを知る必要なく、支払いプロバイダーがカードを自動請求できるように、それらを結び付ける両側に保存されたID。

もう1つの重要な点は、3Dセキュアまたは類似の機能への引き継ぎです。 あなたがそのページに引き継がれている場合、あなたは支払いプロバイダーであり、あなたは完全にPCI DSSスコープ内にいます。あなたは絶対に支払いプロバイダーとベンダーになることができることを覚えておいてください（Amazonを例にとってください）。