後で手動で処理するためのクレジットカード情報の保存
WordpressおよびWooCommerceをフレームワークとして使用してクライアントのeコマースサイトを再構築しています。現在のeコマースサイトはクレジットカード情報を取得し、後で手動で処理するために保存します。送信するデータを「保護」するには、半分クレジットカード番号をメールで送信し、残りを保存します。クライアントは、交渉済みのレートにより、金融サービスソフトウェアを介して手動でクレジットカードに請求できることを望んでいます。これにより、ストライプのような支払いゲートウェイを使用するオプションがなくなります。
彼らの現在のプロセスは、このスレッドのwebengrによる投稿によれば、有効な慣行のようです： https://groups.drupal.org/node/22389 。
「あなたの多くはおそらくzencart/oscommerceがどのようにそれを行うかを知っています。zencardの基本的なオフラインccプロセッサーはクレジットカードの一部を保存してから、他の部分をメールで送信します。 http://tutorials.zen-cart.com/index .php？article = 67 これは「PCIコンプライアンス」を満たすのに十分であるという議論がありました。おそらく、完全なCCで構成されるTrack 1 CCデータを保存していない限り、ビジネスはPCIに準拠しています。番号、名前、有効期限。」
これは本当に正当な慣行ですか？
PCI規格に準拠しながら、後で手動で処理するためにクレジットカードを安全に保存するにはどうすればよいですか？
- トークン化を介してクレジットカードの詳細とトランザクションを保存できるサービスはありますか？次にログインして、トークンでカードの詳細を取得し、金融サービスプロバイダーを通じて手動で請求しますか？
- 他にどのようなセキュリティ対策を提案しますか？ SSLを使用すると、より深い回答が得られます。
PCI DSS v3.1 の関連セクションは次のとおりです。
3.2（暗号化されている場合でも）認証後に機密認証データを保存しないでください。
ただし、これは
- ビジネス上の正当化があり、
- データは安全に保管されます。
また
3.2.1承認後、トラックの内容全体（カードの裏側にある磁気ストライプ、チップに含まれる同等のデータ、またはその他の場所）を保存しないでください。このデータは、フルトラック、トラック、トラック1、トラック2、および磁気ストライプデータとも呼ばれます。
ただし、認証後にCSVを保存することは完全に禁止されています。
3.2.2承認後、カード検証コードまたは値（カードを提示しないトランザクションの検証に使用される支払いカードの前面または背面に印刷された3桁または4桁の番号）を保存しないでください。
カード番号自体の表示に関しては、最初の6桁と最後の4桁を表示しても問題ありません。
3.3マスクPAN表示されると（最初の6桁と最後の4桁が表示される最大桁数）、合法的なビジネスニーズを持つ担当者のみが完全なPANを表示できます）。
要件3の残りの部分（3.4.1から3.7）では、カードデータを保存する方法について説明しています。長い点と短い点は、業界標準で受け入れられている暗号化プロトコルを使用して暗号化して保存する必要があることです。フルディスク暗号化は受け入れられます。次に、キー管理に移ります。これはトリッキーな部分です。 PCIのキーDSSは、これがどのように機能するか、およびこれらがこれらの要件を満たす方法を文書化することです。
後でオフラインで手動で処理するためにクレジットカードデータを保存するためのPCI準拠の方法があります。 （確実に）proper鍵管理による強力な暗号化。
これは本当に正当な慣行ですか？商人がそれを証明し、必要に応じてPCI QSAへの準拠を検証できる場合は、そうです。ネットワークでカードホルダーデータ（CHD）を処理する場合、PCIコンプライアンスを維持するためにそのCHDを保護する責任はすべてお客様にあります。これらの方法は準拠することができますが、継続的な準拠管理には常に付随する労力とコストがあります。四半期ごとのスキャン、オンサイト監査（特定の量で処理する場合）、レポート、定期的な侵入テストなどです。
ただし、あなたとあなたのクライアントの目標が、優先レートとにより取引手数料を節約することであり、PCIスコープ、関連するCHD処理責任、および関連するCHDを処理しないことでコストが発生する場合は、PCI準拠のトークン化およびストレージサービスプロバイダーを検討する必要があります。
トークン化とセキュアストレージサービスプロバイダーAuric または SecureNet のような実装用のCHDのセキュアストレージに特化あなたのシナリオのように。これらのPCI準拠プロバイダーは、機密のCHDデータを安全な「ヴォールト」に保存し、環境から完全に保護するとともに、後の処理のために安全なアクセスを提供することを提供しています。これらは、単純なHTTPS投稿を使用したWebサービスAPIや、ホストされた支払いページに埋め込まれたiframeなどの統合メソッドを提供して、支払いページをサービスにリンクします。
価格は大きく異なりますが、たとえば、Auricボールトサービスはトークンあたり月額0.10ドルかかります。 1か月に1000枚のクレジットカードトークンを保管すると、100.00ドルかかります。
適切に設計されたこのアプローチにより、PCIの範囲とコストを大幅に削減できます。 CHDのホスティングとトークン化に PCI DSS検証済みのサービスプロバイダー を使用すると、PCIコンプライアンスの負担の多くを、すでに検証済みのサードパーティに移すことができます。
PCIのとおりDSS T1データのコンプライアンス直接保存は禁止されています。したがって、データマスキングソリューションを使用してカードデータをマスクし、T1データを一時的に保存できます。このマスクされたデータを使用するシステムもPCIコンプライアンスのT2の範囲で検討する必要があります。カード番号を断片化する代わりに、トークン化の方が優れたソリューションです。リスク管理を最小限に抑え、適切なPKIをこのトークンを安全に格納するために2048ビットのキー長で使用することができます。