問題タブ [pci-dss]

そのため、合理的に有能な Web 開発ショップと同様に、クレジット カードに触れるときは綿の手袋を着用し、Braintree SecureVault を使用してクレジット カードを保存し、PCI コンプライアンスの問題を回避しています。

ただし、現在、サービスの無料トライアルを提供したいと考えています。これは、無料トライアルで特定のクレジットカードが1回だけ使用されることを保証できることにほとんど依存しています. 理想的には、一意性を保証するためにクレジット カード番号自体をハッシュできるようにすることです。問題は、有効なクレジット カード番号のセットが少ないことです。そのため、クレジット カード番号をブルート フォース攻撃するのは簡単です。私が見る限り、ソルティング戦術は無用です。誰かがハッシュのデータベースにアクセスできる場合、おそらくコードもソルティング アルゴリズムも持っているからです。

これまでのところ、最良の 2 つのアイデアは次のとおりです。

A) 請求情報とは関係なく、ハッシュを分離してセットに保持する。したがって、ハッシュがブルート フォースである場合、ある時点で使用されたクレジット カード番号のリストだけが残り、個人情報や、それがまだ有効であるかどうかさえわかりません。ここでの主な弱点は、ある程度一致させるために使用できる可能性のあるベスト 4 の記録があることです。

B) 完全な数値なしでハッシュし、偽陽性と偽陰性に対処します。name、last-4、および有効期限のハッシュは、かなり一意である必要があります。偽陽性は宝くじに当たるようなもので、カスタマー サポートで対処できます。名前の変更によって偽陰性が誘発される可能性があります。名前の一致の精度についてどのような保証があるかは明確ではありません (ゲートウェイとマーチャント アカウントの両方によって影響を受ける可能性があると私は理解しています)。

考え？提案？試練に満ちた知恵？

私はソフトウェア エンジニアであり、現在 PCI PA-DSS に準拠する必要がある別の支払いアプリケーション (私の 3 つ目) に取り組んでいます。PA-DSS のドキュメントを再検討していますが、TLS とユーザー/パスを使用できたのに、過去にアプリケーションのセキュリティについて過労したのではないかと考えています。そこで、PA-DSS セキュア アプリケーションを実装する場合の私の質問は次のとおりです。

1. 認証と通信のセキュリティには、TLS + ユーザー/パスがあれば十分ですか?

2. PA-DSS 標準のどの部分が、Web メソッド呼び出し間のメッセージ ハッシュとローリング ハッシュの実装の必要性を正当化しますか? TLS は信頼できるメッセージを実装しますが、メッセージ間のローリング ハッシュと永続的な呼び出し元は実装しません。ローリング ハッシュを実装すると、(PA-DSS の観点から) 違いが生じますか?

3. 支払い処理アプリケーションが PII 情報を保存し、異なる会社にサービスを提供する場合 (会社 A と会社 B がそのようなアプリケーションでアカウントを持つことができることを意味します)、PII 情報を同じ DB に保存できないという特定の要件はありませんが、過去には、PA-QSA はこれが問題であると主張してきました。問題は、これが本当に必要かということです。何千ものクライアントとプロセッサを持つ会社である Authorize.NET が、クライアント企業ごとに処理されたクレジット カードを格納するための異なるデータベースを持っているとは思えません。

前もって感謝します！

更新 #1:

• DMZ とセキュア ゾーンの両方にあるすべてのページと Web サービスが、すべての通信チャネル、ページ、およびサービスに対して HTTPS を持つと仮定します。

• #3 の問題は、機密情報の保管場所やセキュリティに関するものではありません。この質問は、同じデータベース内のさまざまなソース (たとえば、AT&T や Verizon などのクライアント) からの機密情報を共有する能力に疑問を投げかけるものです。

SQLクエリを保護するための効果的で安全な方法は何ですか？

要するに、プログラマーがクエリを実行するためにアプリケーションによって使用されるパスワードを見ないことを保証したいと思います。RSAやPGPのようなものが思い浮かびますが、アプリケーションのどこかにエンコードせずにパスワードの変更を実装する方法がわかりません。

私たちの環境は典型的なLinux/MySQLです。

注意:ベンダー サポートが付属していないMagento のProfessional Editionを使用しています。

以前の質問に目を通し、サイト上の複数の支払いゲートウェイに関する質問と回答を見つけることができますが、Magento の Payment Bridge に関する具体的な情報は見つかりません. Payment Bridge は、Magento が Enterprise および Professional ライセンスで提供する PA-DSS 認定アプリケーションです。これは、PCI 準拠の環境に必要です。

私たちの問題は、クライアントが 2 つの Auth.net アカウントを持っていることです。これは和解のためのものであり、説明が長くなる可能性があるため、これは必要なシナリオであると信じてください.

Payment Bridge をセットアップする際に Merchant Configuration ツールを使用して加盟店を作成すると、1 つのログイン、つまり 1 つのアカウントしか提供できず、どのカードが受け入れられるかを尋ねられます。サイトはすべてのカードを受け入れますが、1 つのアカウントは Visa、Mastercard、および Discover を処理し、もう 1 つのアカウントはすべての Amex 支払いを処理します.

両方のアカウントを持つことができるようにするために、Payment Bridge のセットアップ中にマーチャントをセットアップするにはどうすればよいですか?

PCI DSS 準拠を必要としない英国の支払いゲートウェイ用の Drupal6/ubercart2 支払いモジュールを探しています。私のウェブサイトは比較的トランザクションの少ないショッピング カートであり、コンプライアンスを取得するのは予算を超えています。

たとえば、コンプライアンスが必要な「Sage pay go direct」のモジュールがあります。Sagepay は、「Sage Pay Go with Form」と呼ばれる別のソリューションも提供しています。このソリューションでは、顧客がサイトにリダイレクトされてカードの詳細を保存し、支払いを行いますが、私の知る限り、利用できるモジュールはありません。

Worldpay にはモジュールがありますが、コンプライアンスが必要です。

ユーザーがアカウントを作成する必要があるため、最後のオプションとして残すpaypalモジュールがありますが、これは少し面倒です。

誰もが推奨できる他のゲートウェイモジュールまたは安価な PCI-DSS 準拠のホスティングプロバイダーはありますか?

Apache 2.2.17 を実行している Fedora 14 サーバーを取得して、McAfee ScanAlert による PCI-DSS コンプライアンス スキャンに合格させようとしています。ssl.conf に設定されているデフォルトの SSLCipherSuite および SSLProtocol ディレクティブを使用した最初の試み...

弱い暗号が有効になっていることを理由に失敗しました。ssllabs および serverniff ツールを使用したスキャンにより、40 ビットおよび 56 ビットのキーが実際に利用可能であることが明らかになりました。

私はその後...に変更しました

さまざまなサイトで報告されている次の文字列をすべて試して、さまざまなベンダーからの PCI スキャンに合格しました...

更新後に apache を再起動すると、apachectl configtest で構文が問題ないと表示されます。後続の ScanAlert スキャンはすべて失敗し、他のスキャン ツールは利用可能な 40 ビットおよび 56 ビットの暗号を引き続き表示します。SSLProtocol と SSLCipherSuite を httpd.conf の VirtualHost に直接追加しようとしましたが、効果がありませんでした。

実際には、どこかでこれらの設定が上書きされているように感じますが、ssl.conf 以外にこれらの値を設定する場所は見つかりません。

誰かが最近の PCI スキャンに合格した既知の優れた SSLCipherSuite を提供できれば、私の問題を追跡するのに大いに役立ちます。

ありがとう。

定期的な請求のために暗号化されたクレジット カード番号を保存している場合、PCI 認定レベルはどうなるのだろうと思っていました。

年間 20,000 件未満の取引を計画していますが、保存されているクレジット カード番号が不明です。

ですから、クレジット カード情報の保存に関する投稿が数多くあることは知っています。私たちはモバイル アプリケーションを作成しており、ユーザーがカード情報を購入のたびに入力するのではなく、一度入力できるようにしたいと考えています。

Authorize.net CIMを調べたところ、これは理想的なソリューションのようです (クレジット カード番号を返すプロファイル ID またはトークンを保存するだけです)。 （必然的に）authorize.netによって処理されませんが、支払いを送信しているマーチャントアカウントによっても処理されます。つまり、ウォレットのようにクレジットカード情報を保存したいのです...必ずしもAuthorize.netで毎回処理する必要はありません。

CIM XML ドキュメント(p.94) を読むと、getCustomerPaymentProfileResponse がクレジット カードの戻りデータをマスクしているように見えます。

実装には他にもいくつかのオプションがありますが、私は、顧客が支払いアカウントを管理するための Web ベースの方法があることを本当に望んでいました. オンデマンドで呼び出して任意の加盟店のプロセッサに渡すことができるクレジット カード データを保存する方法を知っている人はいますか?

EDIT 4.28.2011 - 私はこれで壁にぶつかっています。クレジット カード情報をまったく保存せず、顧客に入力してから渡すようにしたらどうなるでしょうか。保存せず、HTTPS を渡し、転送中にカード データを暗号化しますか?

監査会社は、PCIに準拠していないと述べましたが、問題を解決する方法について役に立たない指示を提供しました。彼らは明らかに、私たちが彼らのコンサルティングユニットに従事することを望んでいます。

PCIコンプライアンス監査アラートを受信した後、ギャップを埋めるためにどのリソース/サービスを使用しましたか？

PCIコンプライアンスの問題を解決するのに役立つリソースを提供するWebサイトはありますか？

たとえば、フラグが立てられた不可解な失敗メッセージの1つを次に示します。

「説明：URLXのカテゴリパラメータにクロスサイトスクリプティングの脆弱性があります」

しかし、この脆弱性を閉じる方法についての明確なガイダンスはありません。

ありがとう。

PHPで支払いゲートウェイを開発する方法とベストプラクティス（SSLやPCI DSSなど）を学びたいと思っています。誰かがこれを手伝ってくれる本/ブログを推薦できますか？私が見つけたものはすべて支払いゲートウェイ固有のものであり、私が理解するのに役立ちませんでした。