問題タブ [pci-dss]

私がやっていることは、金融ソフトウェアを開発し、それを pci 準拠のサードパーティのクレジット カード会社に接続することです。当社はカナダの会社です。私たちは PCI に準拠しておらず、PCI に準拠する予定もありません。ただし、最前線のスタッフが識別できるように、PAN の下 4 桁を保存したいと考えています。

PAN、クライアント名、有効期限、PRN の下 4 桁のみを保存する場合、PCI 準拠である必要がありますか? 必要がある場合、PAN の下 4 桁のみを PRN と共に保存する場合はどうすればよいですか? PCI 準拠である必要はありますか?

PCI DSS のドキュメントを読みました。PANを保存する場合はPCIに準拠する必要があるとだけ言われましたが、最後の4桁だけを保存するかどうかは言われませんでした.

ありがとうございました。

デスクトップ上で排他的に実行される支払い処理クライアントがあります。オペレーターが支払いデータを入力してボタンをクリックすると、私のアプリは安全なチャネルを介してデータを支払いゲートウェイに送信します。私のアプリは、販売者のゲートウェイログイン情報を暗号化して保存しますが、機密性の高い支払いデータを保存することはありません。

私は範囲内ですか？私がそうだとしたら、まったく同じ機能を同じように実行するのに、なぜWebブラウザが範囲外になるのでしょうか。

私が働いている会社は、フォームのスキャン画像を受け取り、そこからデータを収集します (XML ファイルに入れます)。クレジット カード番号はフォームに書き込まれますが、そのデータを収集したり、支払いを処理したりすることはありません。

このようなシナリオでは、PCI 標準は適用されますか? 番号を含む実際のデータ ファイルはありませんが、画像を見れば誰でも簡単にクレジット カード番号を取得できます。カード所有者名が表示されます。セキュリティ コードはありません。有効期限が含まれているかどうかはわかりません。

私たちはサービス プロバイダーの定義に当てはまると思います。私には、SAQ-D が適用される可能性が最も高いように思えました。問題の環境は、SAQ-D のすべての要件を満たしていません。

私が読んだものからの私の意見では、要件は適用されますが、適用されなかったとしても、それらに従おうとしないのはなぜですか? 私より上の人たちは、定期的に画像を削除している限り問題ないと思っています。

このタイプのシナリオで標準に従うことに賛成または反対する、入力、リンク、PCI-DSSドキュメントの関連セクションなどに感謝します。

PCI準拠のクラウドソリューションを使用するには、プライベートクラウド環境が必要であり、GoogleAppEngineを使用できないという記事をいくつか読みました。クレジットカード情報と個人ユーザーデータをGoogleAppEngineアプリケーションに具体的に保存するPCI準拠のウェブサイトを作成することは可能ですか。これが不可能な事実上の非秘教的な理由、またはアプリエンジン開発者が実行する必要があり実行できる高レベルのタスクディレクティブのリストをリストしてください。

PCI-DSSでのソースコードリポジトリ管理にどのような制限がありますか？

私が働いている会社は、私たちのネットワークでホストされているクライアント向けのクレジットカード処理サービスを開発したいと考えています。現在、バージョン管理にSVNを使用しています。チェックアウト/コミットアクセスが必要な開発者だけがアクセスできるように保護されています。その間、私はSVNからHGへの移行を計画していました。ただし、リモートクローンのアクセス制御が不足しているため、セキュリティチームは分散SCMツールの使用について留保を表明しています。具体的には、これはPCI-DSSコンプライアンスに違反すると主張しています。しますか？

クレジットカードの詳細をウェブサイトで取得して、将来請求できるようにしたいクライアントが2人います（1つはコースを実行し、ユーザーはキャンセルしていない場合、コースの4週間前にのみ請求され、もう1つは慈善団体を実行し、各募金活動者は少なくとも 3,000 ドルを集める必要があり、それ未満はクレジット カードから引き落とされます)。彼らが自分のサイトでccデータを取得して保存することができない/保存すべきではないことを心から感謝していますが、これを行うための最善の解決策についてあなたの見解を確認したかったのです. 明らかに、ユーザーがオンラインですぐに支払う場合は問題なく、任意の支払いゲートウェイを使用できますが、すぐに請求する必要はなく、将来の不確定な時間 (通常は数か月後) をカードに請求する必要はありません。支払いの直前にのみ確立できます。

これを行う最善の方法は、ある種の可変定期支払いシステム (例: WorldPay の FuturePay、PayPal の自動請求 、またはAuthorize.net の CIM サービス) を使用することであると考えるのは正しいでしょうか。これら（および他の同様のサービス）は、変動支払いを可能にします（ただし、WorldPay / PayPalは、1回限りではなく定期支払い用に設定されているようです）.

http://www.braintreepayments.com/credit-card-storageのような会社を使用して情報を保存するオプションもあるようです。この状況に一般的にどのように対処しているか、上記のオプションを使用するかどうか、またはより適切な/より適切な代替手段があるかどうかを誰かが確認できれば、非常に感謝しています。

私は、新しいベンチャーのために取り組んでいるプロジェクトで遭遇した「鶏と卵」の問題の解決策を見つけようとしています。

問題のシステムはクレジットカードのデータを扱っているため、カード番号などを暗号化してデータベースに保存する必要があります。PCI 要件に準拠するために、「加盟店」ごとに一意のキー ペアで番号を暗号化しています。そのため、1 つの加盟店が侵害された場合、別の加盟店のカード所有者データにアクセスすることはできません。

人間がパスフレーズを入力して秘密鍵のロックを解除し、データを復号化できるため、システムとの人間の対話に関しては問題ありませんが、データにアクセスする必要がある自動化されたサービス (つまり、トランザクションを処理するため) に関しては、これは問題ありません。サービス/デーモン プロセスに資格情報を提供する最善の方法に問題があります。

システムの背景のビット:

• カード番号は非対称鍵ペアで暗号化されます
• 秘密鍵はパスフレーズで保護されています
• このパスフレーズは、「マスター」鍵ペアで暗号化されます
• マスター秘密鍵のロックを解除するためのパスフレーズは、許可を与えられたオペレーターに知られます (実際には、彼らはパスフレーズしか知らない独自の鍵ペアで暗号化されたそのコピーです)。
• デーモン プロセスは、Linux システム上で独自のユーザーおよびグループとして実行されます。

デーモンがデータを復号化できるようにするために、次のことを検討していました。

• .pgpassの仕組みと同様のパスフレーズ ファイルをセットアップします。
• デーモン ユーザーのホーム ディレクトリにファイルを格納します。
• ファイルのパーミッションを 0600 に設定します
• Tripwire などのファイル整合性監視システムをセットアップして、ファイルまたはアクセス許可に対する変更をセキュリティ グループ (または同様のグループ) に通知します。
• プロセスにのみ使用されるデーモン ユーザーのログインを無効にします。

以上のことから、これで十分かどうかは疑問です。明らかに弱点はシステム管理者にあります - 安全なシステムで信頼されているのは少数 (すなわち 2 人) です - 彼らは権限を昇格させ (つまり root に)、ファイルの所有権または権限を読み取り可能に変更できます。パスフレーズ - ただし、これもまた、ファイルのチェックサムの変更、FIM チェックサムなどを監視することで軽減できる可能性があります。

それで、私はこれを間違った方法で行っていますか、それともこれを処理する方法について他の提案はありますか?

会社の PCI DSS コンプライアンスに取り組んでいます。いくつかの調査の結果、クレジット カードのデータを保存することは、物事がはるかに複雑になるため、まったく良い考えではないことがわかりました。

トークン化ソリューションと組み合わせて安全なデータ保管庫を提供する支払いプロバイダーを見つけました。大規模なソリューションのすべてのサブモジュールを監査したくないので、クレジットカードを送信したいときにすぐに、クレジットカードを置き換える透過的なプロキシサーバーを作成し（正規表現で検索）、それをトークンに置き換えることを考えましたカードを第三者に送信する場合、プロキシ経由で送信すると、プロキシはトークンをクレジット カードに戻します。これにより、他のすべてのコードがトークンにヒットするだけなので、プロキシへのコード監査を含む安全なコーディング要件が軽減されます。

ASP.NET MVC / Webforms と WCF を使用しています。このようなことを成し遂げるための最良の方法は何ですか? 私は、この仕事をするために HttpFilter / ISAPI を書くことについて考えました。

ひょっとしたら、このような製品がすでにあるのではないでしょうか？この考えはまったく理にかなっていますか？

PCI DSS 基準は、電話による小切手のみを扱うプロバイダーに適用されますか?

つまり収集

1) 口座番号 2) ルーティング番号 3) 小切手番号

言い換えれば - クレジットカードなし

ありがとう

私は誰かが私が何かを整理するのを手伝ってくれることを望んでいました。私はWordPress用のショッピングカートプラグインにかなり長い間取り組んできました。私は2008年の終わりにそれをコーディングし始めました（そしてそれは「時間があるときにそれに取り組む」プロジェクトの1つだったので、明らかに進行は非常に遅いです！）そしてそれでかなりうまくいきました。数人のテスターでさえ私を取り上げてフィードバックをくれました。（このプラグインは有料ダウンロードでもあることに注意してください。プレミアムプラグインにするつもりはありません。）

とにかく、2010年にすべてのPCI / DSSが標準になったとき、プラグインはデータベースに特定の情報を保持することを目的としていたため、私はそれを棚上げしました。誰かを危険にさらす可能性があり、おそらく私に戻ってくる可能性のあるものをそこに出したくありません。

過去数週間にわたって、何人かの同僚と私はPCI / DSSコンプライアンスについて話し合っていました、そしてそれはこのプラグインを最終的に完成させることに再び興味を起こさせました。クレジットカード番号とその性質のデータのストレージを削除しますが、このプラグインを使用する可能性のあるサイトでアカウントを自発的に作成したい人の名前と配送先住所を保存するというアイデアは好きです。そのため、再度買い物をしても、そのような情報は保持されます。保存されるデータは公開情報であることに注意してください-電話帳や、郡庁舎の記録室を覗くようなもの。つまり、SS＃、病歴、またはクレジットカード番号を保存するようなものはありません。誰かが過去の購入を見ることができ、将来のチェックアウトプロセスを少し簡単にするためにいくつかの情報を保持できるようなものだけです。

同僚の1人は、サイト所有者が使用することを選択した支払いゲートウェイに名前と配送先住所が渡される可能性があるため、セキュリティを少し強化するためにまだ何かをすることを提案しました。彼らは私が「一方向暗号化」を使用することを提案しました。今、私は巨大なセキュリティフリークではありませんが、これには（とにかく1つの側面で）塩を使ったMD5ハッシュなどが含まれると確信しています。だから、これは私を混乱させます。なぜなら、私のコードでそのようなものを使用する方法をどこで見るべきか、そして/またはそのようなデータをPayPalまたはGoogleCheckoutに渡すときにそれが機能するかどうかについて少しもわからないからです。またはマルの、またはあなたは何を持っていますか。

ですから、これは「コード例が必要」という種類の質問ではなく、「私は一種の劣等生なので、教えてください」という種類の質問だと思います。（これは、私がショッピングカートプラグインLOLを書いているという事実について人々がはるかに気分が良くなると確信しています）