PCI コンプライアンスと Ajax

StackOverflow https://stackoverflow.com/questions/4219636

質問

このアイデアはありますが、それが PCI に準拠しているかどうかはわかりません。私は PCI コンプライアンスの分野には初めてですが、このシナリオが PCI に違反するかどうか知りたいと思っています。

それでは、シナリオを設定してみましょう。会社 A は PCI に準拠しており、支払い処理に関する機能の一部を公開する https 上の Web サービスを持っています。会社 B は準拠していませんが、Web サイトは安全です。

ここではシナリオの手順を説明します。

  1. B の Web サイトは、サーバー側コードを介して A の Web サービスに接続します。このサービスは、暗号化された認証トークンを送り返します。
  2. B は、クレジット カード情報を受け入れるためのフォームを含むページにこのトークンを挿入します。
  3. ユーザーは B の Web サイトにクレジット カード情報を入力します。
  4. フォーム情報はトークンとともに、ajax 呼び出しを介して A の Web サービスに送信されます。
  5. A の Web サービスはデータを処理し、ステータス (承認/拒否など) を返します。

問題は、JavaScript がユーザーのマシンから A 社の準拠サーバーに直接送信されるため、PCI に準拠しているかということです。この分野の専門家がどのように考えているかを知りたいと思っています。

役に立ちましたか？

解決

PCI DSSに関するパンフレット すべての PCI規格

PCI DSS (Payment Card Industry Data Security Standard) には「スコーピング」という概念があり、どのシステムが PCI の傘下に入るのかを決定します。

あなたは販売業者ですか、それともソフトウェア ベンダーですか?長いクレジット カード番号である PAN (プライマリ アカウント番号) が Web サイトに送信されない場合、通常、Web サイトは PCI スコープの下にありません。-- あなたが商人だと仮定します。あなたがソフトウェア ベンダーの場合、あなたのソフトウェアはおそらく PA-DSS の範囲内に含まれるでしょう (以下を参照)。

サーバーを通過するPAN以前の考え方では、PAN が (ブラウザーのフォーム送信を通じて) Web サイトに送信され、Web サイトが方向転換して支払いゲートウェイ (Authorize.Net など) に送信されるというものでした。このシナリオでは、PAN はサーバーに保存されませんでしたが、保存されました。 トランジット あなたのサーバー。これは、加盟店システムが PAN を保存したことがないため、PCI DSS の対象外となることを意味していました。しかし、そんな日々はすぐに終わりを告げるか、すでに過ぎ去りました。(これは、アクワイアラ/マーチャント アカウント サプライヤーが PCI に対してどれだけ積極的であるかによって異なります。)

Web ページを制御する Web ページはサーバーに PAN を送信しないため、PCI スコープには含まれません。しかし、誰かが PAN をサーバー (または JSONP 技術を使用して他の場所) に送信するために Web ページを変更していないことをどうやって知ることができるでしょうか?答えは、誰もあなたの支払いフォームページを改ざんしないことを保証する必要があるということです。

これをどのように確信するかはあなた次第です。PCI テクニックまたはその他のテクニックを使用することもできます。これは、内部コンピュータのセキュリティと監査の問題です。

決済アプリケーション データ セキュリティ標準 (PA-DSS) 販売者に SW を販売する場合は、おそらく PA-DSS 標準の範囲内になるでしょう。を参照してください。 標準.

PCI は技術的なものではなく、政治的なものです PCI のスコープはユーザー次第であることに注意してください。十分な規模の販売者であれば、PCI コンプライアンスと範囲計画をレビューして承認してくれる QSA (認定セキュリティ評価者) と協力する必要もあります。

確かに、QSA が、Web ページを管理しているのであれば、Web ページは何者かによって破損される可能性があるため、PCI の下に置く必要があると言う可能性があります。しかし、それは強引な議論でしょう。結局のところ、どの Web ページも破損してユーザーに PAN を要求し、それを使って何か悪いことをする可能性があるため、インターネット販売者のすべての Web ページは PCI の下にある必要があると言えます。一方で、これはまさにVisaがフランチャイザー企業のPCI範囲を拡大するために利用している類の議論である。 記事.

PCI 認定は言い訳にならない また、カード協会は、たとえ PCI に準拠していたとしても、侵入した場合には退場させる権利を留保していることにも注意してください。したがって、自分がブロック内の他の誰よりもはるかに厳しいターゲットであることを確認する必要があります。

追加した： スコーピングの詳細 上記のことからわかるように、重要な問題は、どのシステムが PCI スコープ内にあるか、または外にあるかということです。PCI 評議会には現在、PCI の範囲内と範囲外に関するこの問題全体を調査する特別利益グループ (SIG) が設置されています。そして私の推測では、彼らは封筒が縮小するのではなく拡大することを望んでいるのではないかと思います。

追加した： それはあなたとあなたの弁護士の間の問題です このシナリオでは、顧客のブラウザ上で PAN 処理が開始されます。PAN は一瞬たりともシステムに到達しません。したがって、私の解釈では、あなたはマーチャント PCI DSS の範囲外であるということになります。ただし、あなたと買収者との間の契約である PCI コンプライアンス声明に署名するのはあなたです。したがって、PCI DSS 標準を解釈するのは私ではなく、あなたとあなたの弁護士次第です。

結論 PAN データをシステムに保存しないでください。システムを通過させるべきではありません。Authorize.Net と Braintree の新しいペイメント ゲートウェイ プロトコルにより、ノートランジット技術が可能になります。クレジット カード取引の量に応じて、PCI コンプライアンスは自己管理のチェックリストから大規模なプロジェクトまで異なります。

PCI 戦争のストーリーをさらに詳しく知りたい場合は、 店頭裏話 ブログと彼らの PCI の適用範囲.

他のヒント

ラリー・Kの答えは良いです。これは、主に政治/層のことである。

CORSまたはJSONPで - - やや疑問であるが、それでも、いくつかの大きなプレーヤーのために、少なくとも、許容可能な

アヤックスを使用しながら、 AとBからの投稿のためのiframeを使用して受け入れられた解決策があるようです。

情報補足：PCI DSS Eコマースガイドラインのv2のシームこのソリューション（ダイレクト・ポストと言ってAPI）OKですが、ののはず（PCI DSSは何もコンクリートを規定していないのにあなたがする必要があります）安全コードに世話をすること - セクションの3.4.3.1サードパーティの組み込みのAPIを参照してください

：直接ポストのと読み込み共有・管理Eコマース実装のための関連の3.4.3.4セキュリティについての考慮事項、と
  

の直接ポストAPIアプローチの：ダイレクト・ポストAPIのアプローチでは、   商人はまだに提示されたWebページを担当して   消費者、そして商人ホスト支払いページのフィールド   それは、データのみのカード会員データから直接投稿された受け入れます   サービスプロバイダへの消費者。決済ページがあるので、   商人が主催する、支払いページは、唯一として、安全なようです   商人のウェブサイト、および商人のシステムの妥協ができ   ペイメントカードデータの妥協につながります。   ...   具体的には、上記のシナリオのすべてのために、商人はすべき   システムが変更されたという証拠のために監視し、迅速に対応   不正な変更があるときに、信頼できる状態にシステムを復元します   検出されました。これらの共有・管理を採用商人は外部委託します   該当するPCI DSSの要件を最小限にするモデルが知っておくべき   システムのこれらのタイプに固有の潜在的なリスク   建築。これらのシナリオで、攻撃の可能性を最小限にするために、   商人は、ウェブを確実にするために、余分なデューデリジェンスを適用する必要があります   アプリケーションが確実に開発され、完全な浸透を受けています   テストます。

たとえばストライプ支払いゲートウェイは、2012年の代わりに、彼らが持っているのiframeアプローチので、JSONPするを直接ポストを使用しています前に使用されます。

一方、WePayは、直接ポストAPIを提供していますが、完全に直接ポストAPI「で<全角> [..]あなたはまだだと主張PCI要件[WP]（を取り除くためにはiframeを推奨していますペイメントカード業界データセキュリティ基準（PCI-DSS）およびペイメントアプリケーションデータセキュリティ基準（PA-DSS）に準拠するために必要な時はいつでも適用。の」（指定せずに、まさに 『いつでも適用』手段）。

[WP] WePayリンク：https://www.wepay.com/developer/tutorial/tokenization

私は最近、当社のサーバーのPCIコンプライアンス仕事を通じて行ってきたので、これは右の私の前にあります。短い答えはノーです。

PCIコンプライアンスは、機密情報が通過する経路の各ステップは、それ自体のPCI要件を満たしていることが必要です。あなたが会社B.に関して述べたように、あなたが既に会社Bは、PCIに準拠していないと述べ、まだB社は、独自のウェブサイトを経由してクレジットカード情報を収集し、その後、全体のプロセス、論理的であるされているので何かが、安全ですが準拠していないことができ準拠していない。

かどうかは、PCIコンプライアンスサービスは、実際にこれらのドットを接続し、それらが渡すか、別の問題かもしれ失敗としてそれを証明するだろうか。

「技術的に」PCI 規格を満たしているかどうかに関係なく (または満たしていないか)、私はこのやり方を信頼しません。

フォームが B のホスト名のページにある場合、B はフォーム フィールドの内容に完全にアクセスできます。(B のサーバーは、必要に応じて悪意のある JavaScript をユーザーに送信できます。)

(クレジット カード番号を保護するという観点から) 最も安全な方法は、信頼できないホスト名ではなく、支払い処理サービスのホスト名内にフォームを完全に配置することです。

ここで PCIウェブサイトの

あなたはおそらくカード番号やカードについての識別情報を見ることができた場合は、

は基本的に、あなたは、PCI要件に準拠する必要があります。私は、彼らが必ずしも法的文書であることをわからない「まだ」が、あなたは違反で発見された場合、プロセスへのあなたの能力、またはトランザクション処理の一部で取り消すことができます。また、商人として、あなたはあなたの責任およびクレジットカード会社があなたを細かくすることができ、プロセスのオプトインにについての契約を締結します。クレジットカードを受け入れることの特権のためにすべて。

ここでの楽しみのために

は38ページ（PDF）リンク 'クイック' ガイド。

所属していません StackOverflow
scroll top