9

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

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

シナリオの手順は次のとおりです。

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

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

4

5 に答える 5

13

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

PCI DSS(Payment Card Industry Data Security Standard)には、「スコープ」の概念があります。これは、どのシステムがPCIの傘下に入るのかを決定するものです。

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

サーバーを通過する PAN古い考え方では、PANは(ブラウザーフォームの送信を介して)Webサイトに送信され、次にWebサイトが向きを変えて支払いゲートウェイ(Authorize.Netなど)に送信されます。このシナリオでは、PANはサーバーに保存されませんでしたが、サーバーを通過しました。これは、PANを保存したことがないため、マーチャントシステムがPCIDSSスコープに含まれないことを意味していました。しかし、それらの日はすぐに終わるか、すでになくなっています。(これは、アクワイアラー/マーチャントアカウントのサプライヤーがPCIに対してどれほど積極的であるかによって異なります。)

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

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

ペイメントアプリケーションデータセキュリティ標準(PA-DSS)ソフトウェアを販売者に販売する場合、おそらくPA-DSS標準の範囲内になります。標準を参照してください。

PCIは政治的であり、技術的ではありませんPCIスコープはあなた次第であることを忘れないでください。あなたが十分な規模の商人である場合は、PCIコンプライアンスとスコーピング計画を確認して承認するQSA(Qualified Security Assessor)とも協力する必要があります。

QSAは、Webページを制御しているため、誰かによって破損している可能性があるため、PCIの下にある必要があると言う可能性があります。しかし、それは強引な議論になるでしょう。結局のところ、どのWebページも破損して人々にPANを要求し、それに対して何か悪いことをする可能性があるため、インターネット商人のすべてのWebページはPCIの下にある必要があると言えます。一方、これはまさに、Visaが企業フランチャイザーのPCIスコープを拡大するために使用している種類の議論です。記事

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

追加:スコープの詳細上記からわかるように、重要な問題は、どのシステムがPCIスコープ内またはPCIスコープ外にあるかです。PCI評議会には現在、PCIの範囲内にあるものと範囲外にあるもののこの問題全体を調査する分科会(SIG)があります。そして、私の推測では、彼らはエンベロープを縮小するのではなく、拡大することを望んでいるでしょう。

追加:それはあなたとあなたの弁護士の間ですあなたのシナリオでは、顧客のブラウザでPAN処理が開始されます。PANがシステムに到達することは、一瞬でもありません。したがって、私の解釈では、あなたはMerchantPCIDSSの範囲外です。しかし、あなたはあなたとあなたの取得者との間の契約であるPCIコンプライアンスステートメントに署名する人です。したがって、PCI DSS標準を解釈するのは私ではなく、あなたとあなたの弁護士の責任です。

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

その他のPCIウォーストーリーについては、StorefrontBacktalkブログとそのPCIカバレッジを確認してください。

于 2010-11-19T06:05:03.963 に答える
6

ラリーKの答えは良いです。それは主に政治的/層的なものです。

BからAへの投稿にiframeを使用することは受け入れられている解決策のようですが、Ajax(CORSまたはJSONPを使用)を使用することはやや疑わしいですが、少なくとも一部の大手プレーヤーにとっては受け入れられます。

情報の補足:PCI DSS Eコマースガイドラインv2は、このソリューション(ダイレクトポストAPI)は問題ないが、安全にコーディングするように注意する必要があると述べています(ただし、PCI DSSは必要な具体的なことを何も規定していません)-セクション3.4.3.1ダイレクトポストを使用したサードパーティの組み込みAPIおよび関連する3.4.3.4共有管理Eコマース実装のセキュリティに関する考慮事項を参照してください。

ダイレクトポストAPIアプローチ:ダイレクトポストAPIアプローチでは、マーチャントは引き続き消費者に提示されるWebページに責任を負い、マーチャントはデータを受け入れる支払いページのフィールドをホストします。カード会員データのみが消費者から直接投稿されます。サービスプロバイダーに。支払いページはマーチャントによってホストされているため、支払いページはマーチャントのWebサイトと同じくらい安全であり、マーチャントのシステムの侵害は支払いカードデータの侵害につながる可能性があります。...具体的には、上記のすべてのシナリオで、マーチャントはシステムが変更されたという証拠を監視し、不正な変更が検出された場合にシステムを信頼できる状態に復元するために迅速に対応する必要があります。適用可能なPCIDSS要件を最小限に抑えるためにこれらの共有管理アウトソーシングモデルを採用する加盟店は、これらのタイプのシステムアーキテクチャに固有の潜在的なリスクに注意する必要があります。これらのシナリオでの攻撃の可能性を最小限に抑えるために、マーチャントは、Webアプリケーションが安全に開発され、徹底的な侵入テストを受けることを保証するために、追加のデューデリジェンスを適用する必要があります。

たとえば、 Stripe支払いゲートウェイは、以前使用していたiframeアプローチではなく、2012年以降JSONPを介したダイレクトポストを使用しています。

一方、WePayはダイレクトポストAPIも提供しますが、PCI要件を完全に取り除くためにiframeを推奨します[WP](ダイレクトポストAPI " [..]を使用する場合でも、ペイメントカード業界のデータセキュリティ標準(PCI-DSS)およびペイメントアプリケーションデータセキュリティ標準(PA-DSS)は、該当する場合は常に「」(「該当する場合」の意味を正確に指定せずに)。

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

于 2014-03-04T13:16:54.257 に答える
3

最近、サーバーのPCIコンプライアンス作業をいくつか行ったので、これは目の前にあります。簡単な答えはノーです。

PCIコンプライアンスでは、機密情報が通過するパスの各ステップが、それ自体でPCI要件を満たしている必要があります。B社について述べたように、何かは安全ですが準拠していない可能性があります。B社はPCIに準拠していないと既に述べたので、B社は独自のWebサイトを介してクレジットカード情報を収集しているため、プロセス全体は論理的には準拠していません。

PCIコンプライアンスサービスが実際にこれらのドットを接続するかどうか、およびそれらが合格または不合格としてそれをどのように認定するかは別の問題である可能性があります。

于 2011-11-18T21:00:36.037 に答える
1

それが「技術的に」PCI標準を満たしているかどうかに関係なく、私はこの方法で物事を行うことに信頼を置きません。

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

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

于 2010-11-19T03:52:43.330 に答える
0

こちらがPCIのウェブサイトです

基本的に、カード番号またはカードに関する識別情報が表示される可能性がある場合は、pci要件に準拠する必要があります。それらが必ずしも「まだ」法的文書であるかどうかはわかりませんが、違反が見つかった場合は、処理する能力、またはトランザクションプロセスの一部である能力を取り消すことができます。さらに、商人として、あなたはあなたの責任についての合意に署名し、クレジットカード会社があなたに罰金を科すことができるプロセスにオプトインします。すべてクレジットカードを受け入れる特権のために。

楽しみのためにここに38ページの「クイック」ガイドへの(pdf)リンクがあります。

于 2010-11-18T21:21:30.593 に答える