6

クレジット カード処理を統合した WPF アプリケーションがあります。現在、PCI コンプライアンスを満たすために、クレジット情報を WPF Web ブラウザーの Web ページにスワイプ/入力しています。Web ブラウザー コンポーネントは PCI に準拠しており、コードはクレジット カード情報を処理しないため、これで問題ないようです。

私はこの設計が大嫌いで、Web ブラウザー コンポーネントの代わりにプラグインできる、スタンドアロンの PCI 準拠の WPF コントロール/アセンブリを作成したいと考えています。アプリのコードが PCI 認定を受けていなくてもブラウザを使用できる場合、それ自体が PCI 認定を受けていなくても、独自の PCI 認定アセンブリを使用できますか? それが行うすべての新しい制御/アセンブリは、カード情報を収集し、WCF サービスを介してリモートの安全なサーバーに安全に送信することです。クレジットカードを保存したり、ローカルで処理したりすることはありません。これを行うには 9 か月のレビュー プロセスが必要であると言われたので、ブラウザー アプローチを採用しました。

誰かがこれを行うには何が必要かについての一般的な考えを教えてもらえますか?

  • C#/WPFで書ける？
  • コードには特別なセキュリティ対策 (CAS など) を実装する必要がありますか?
  • アセンブリを難読化する必要がありますか?
  • そして、それが書かれたら、あなたは何をしなければなりませんか？
4

1 に答える 1

3

PCI-DSS と多くの重複がありますが、探している正式な名前は PA-DSS (Payment Application Data Security Standards) です。

問題に対処する最善の方法の 1 つの戦略は、カード エントリ/カード処理部分を完全に別のソリューションに分離することです。この個別のソリューションは、最終的には PA-DSS 認定を受ける「アプリ」になります。認定されると、それをより大きなプロジェクトに組み込むことができます (これにより、より大きなプロジェクトの PCI コンプライアンスが変更されることはありません)。

分離する利点は、PA-DSS を調べると明らかになります。基準の 1 つは、アプリの再コンパイルが必要な変更では、アプリを再認定する必要があるということです。それはあなたが頻繁にやりたいことではありません！

プロセスを容易にするもう 1 つの戦略は、「社内」アプリケーション (クライアントに配布されない) は PA-DSS 認定を受ける必要がないことを考慮することです (ただし、明らかにカード データを処理する場合は、それでも PCI-DSS に該当します)。 . したがって、ドメイン内で Web サービスを使用すると、作業が簡単になる可能性があります。たとえば、「支払いエントリの詳細」Web ページをホストし、メイン アプリで標準の Web ブラウザを使用して、支払いエントリ ページを指定することができます。これにより、PA-DSS 認定をバイパスできる可能性があります (ただし、現在ホストしている Web ページには引き続き PCI 認定が必要です)。

どのような決定を下すにせよ、最善のアドバイスは、意図した設計を合理的に把握したらすぐに QSA を関与させることです。QSA は、コンプライアンスの問題を引き起こす可能性のある領域についてアドバイスを提供し、最終的には QSA がコンプライアンスを承認します。

于 2012-02-07T12:10:54.637 に答える