クレジットカードストレージ（PCI-DSS準拠）
私はソフトウェア開発者です。クレジットカード番号を保存するためのカスタムシステムを作成することを検討しています。私たちの意図は、完全に支払いカード業界（PCI）に準拠することです。私は物を借りる中小企業の経営者と協力しており、クレジットカード番号をファイルに保管して、借りた商品の返品を確実にしたいと考えています。顧客が期限内にアイテムを返却しなかった場合、署名されたレンタル契約ごとに請求されます。クレジットカード情報は商品の返品時に消去されます。
一部のクレジットカード処理業者は、レンタル支払いに使用する通常のクレジットカード処理に加えて、クレジットカードの保管サービスも提供していることを認識しています。クレジットカード番号を保存し、そのカードを表すトークンをストレージに提供します。 （例：Paypal、Stripe）このビジネスオーナーは、そのサービスを提供しないクレジットカードプロセッサへの関与をすでに持っています。クレジットカードプロセッサをPaypalまたはStripeに変更することは、オプションのようには見えません。また、クレジットカードストレージの保管サービス（トークンを使用）も調査しましたが、どちらも機能しません。 500枚のカードを1か月あたり$ 1300で保管するのは、この小規模企業にとっては少し高すぎます。
ここでいくつかの重要な投稿を見てきました：
主要な3つのクラウドストレージプロバイダー（Amazon Webサービス、Microsoft Azure、Google Cloud）はすべて、PCI DSSインフラストラクチャとして準拠しています。
これらのサービスの1つをクレジットカード情報のリポジトリとして使用することを真剣に検討しています。明らかに、私たちは完全にPCIになりたいと思っていますDSSに準拠しています。アプリとサーバーの作成方法を知っています。堅牢なログインシステムを追加する方法を知っています。 公開された暗号化ライブラリの使用方法を知っています。 、サーバー側の暗号化用。これらのクラウドサービスの1つでホストされている別のサーバー上にMongoDBを作成する方法を知っています。httpsを介してサーバーと通信する方法を知っています。キーストレージ全体については明確ではありません事。
上記の最初のリンクされたアイテムから：
データの暗号化に使用する暗号化キー（EK）は、それ自体がキー暗号化キー（KEK）で暗号化されている必要があります。暗号化されたEKは保護された場所に保存する必要があります-これはファイル、レジストリキーなど、何でも可能です-重要なことは、それへのアクセスをappserverのユーザーのみに制限することです。
私はその説明に少し混乱しています。私はすべてが公開鍵/秘密鍵のエンコーディング手法になっていると思いました。上記の参照で、上記の暗号化キーは実際には秘密キーであると思いますか？または、ここでアルゴリズムを誤って混合していますか？
私は公開鍵/秘密鍵アルゴリズムを使用していると思いました。サーバーコードに公開キーを含めることを想定しています。私の意図は、秘密キーを別の場所に完全にオフラインで保存することです（そうです、PCI-DSS 3.5.3の要件を満たしています）。私の傾向は、クレジットカードのデコード/取得のために秘密キーのカスタムコピー/貼り付けを要求することです。これは非常にまれなプロセスであり、おそらくビジネスオーナーのみが実行します。
しかし、おそらく私はこれをすべて間違っているのです。個々のクレジットカードエンコーディング用のPCI-DSS「承認済み」アルゴリズムとは何ですか？私が見ることができるものから、 特定の要件 は次のように述べられています：
強力な暗号化の目的（PCI DSSおよびPA-DSS用語集、略語、および頭字語で定義）は、暗号化が業界でテストされ承認されたアルゴリズム（強力な暗号化キーを備えた独自のアルゴリズムまたは「自社開発」アルゴリズム）...
これが私の質問です。
ここでPCI-DSS規格を満たすために、現在推奨されている公開/秘密鍵スタイルエンコーディングのアルゴリズムは何ですか？
公開/秘密鍵エンコーディングでない場合、他の暗号化手法が推奨されますか？
私はこれを正しく行っていますか？
他のコメント、またはここで学んだ教訓はありますか？
どうもありがとう。
PCI DSSは、このトピックでは明確に明確ではありません。安全な鍵の保管と安全な鍵の管理の意味は、QSAの解釈に任されています。1つのQSAがプライベートKEKを検討していることがわかるかもしれません。セキュリティで保護する必要があるすべてであり、EKをトークンとして扱います。または、KEKで暗号化されていても、個々のEKをセキュリティで保護する必要があると見なす別のQSAを見つけることがあります。両方の種類の監査人、そして率直に言って、私は2人の「厳しい」方がより有能であると思いました（私は彼のリスク評価に同意しませんでしたが）。
私が見るより大きな問題は、あなたがこのシステムを所有するコストを考慮していないということです。このような複雑なシステムを構築するには、時間と費用がかかります。審査員はシステムのすべての隅々を非常に注意深く調べる必要がありますが、これには多くの時間と費用がかかります。そして、彼らは毎年試験を繰り返さなければならないでしょう。
現在のルールでは、違反したシステムを構築した場合、レンタル担当者は違反に関連するすべての詐欺の費用の100％を負担することになります。つまり、誰かが億万長者のカードを盗んでその上にフェラーリを請求した場合、彼はその損失の責任を負います。誰かが10億万長者のカードを盗んで、それぞれに1枚のフェラーリを請求した場合、彼は全損失の責任があります。もちろん、彼の弁護士はすぐに向きを変え、安全でないシステムを構築したとしてあなたを訴えます。そして、彼らはあなたの自家製システムが安全ではなかったことを彼らに告げないことで無能のためにQSAを訴えます。したがって、QSAは、システムの監査に費やされた時間を支払うだけでなく、リスクをカバーするための保険も支払う必要があります。
率直に言って、レンタル担当者は、カウンターの従業員が顧客のIDカードのコピーを作成し、そのコピーをカウンターの下のドロップボックスの金庫にドロップする方がよいでしょう。そして彼の防犯カメラを動かし続けます。顧客が返品に失敗した場合、または破損した商品を返品して異議を申し立てた場合は、賃貸人を少額請求裁判所に持ち込む必要があるという証拠が得られます。これは、PCI DSS準拠システムを構築して維持するよりもはるかに安価です（そして、それが実際にPCI DSS-監査人が特定し、リスクを説明する場合、事業主はリスクを慎重に検討し、賢明な選択を行う必要があります。）
「PCI DSS and PA-DSS Glossary of Terms、Abbreviations、and Acronyms」を参照すると、「強力な暗号化」について以下がリストされています。
強力な暗号化：業界でテストされ承認されたアルゴリズムに基づく暗号化と、最小112ビットの有効なキー強度と適切なキー管理方法を提供するキーの長さ。暗号化はデータを保護する方法であり、暗号化（可逆）とハッシュ（「一方向」、つまり可逆ではない）の両方が含まれます。ハッシュを参照してください。
公開時点で、業界でテストおよび承認された標準とアルゴリズムの例には、AES（128ビット以上）、TDES/TDEA（トリプルレングスキー）、RSA（2048ビット以上）、ECC（224ビット以上）が含まれます。 、およびDSA/DH（2048/224ビット以上）。暗号化キーの強度とアルゴリズムの詳細については、NIST Special Publication 800-57 Part 1（ http://csrc.nist.gov/publications/ ）の現在のバージョンを参照してください。
注：上記の例は、カード会員データの永続的な保存に適しています。 PCI PINおよびPTSで定義されている）トランザクションベースの操作の最小暗号化要件は、露出のレベルを下げるために追加の制御が行われているため、より柔軟です。すべての新しい実装では、少なくとも128ビットの有効なキー強度を使用します。
一般的に言えば、対称暗号化アルゴリズムを使用し、それを暗号化してから、使用前に復号化することができます。これはデータベースで実行できます。
「私はこれを正しく行っていますか？」と答えるには私はノーと言うでしょう。彼はトークン化する必要があり、それは彼の人生をより簡単で安価にするでしょう、彼は完全にPCIである必要がありますDSSコンプライアンスと毎年自己評価を行う必要があり、彼はおそらく準拠しません彼は彼のプロセッサが好きなのでトークン化を行うのをためらっています（このプロセッサはこの時代にトークン化をサポートしていませんか？）。確保。