これはPCIに準拠していますか？
質問：クレジットカード情報を共有ホスティングサーバーに保存し、PCIに準拠する方法はありますか？
ここに設定があります：
1）チェックアウトプロセス全体とクライアントのサイトの管理セクションにSSLが実装されています。
2）クレジットカード情報は、サーバー（共有ホスティングプラン）のMYSQLデータベースに保存されます。暗号化されています。
3）クライアントはパスワードで保護された管理パネルにアクセスし、ウェブサイトからクレジットカードを印刷します。
4）次に、クライアントは手動で端末を介してクレジットカード情報を実行し、このクレジットカード情報をサーバーから削除します。
PCIコンプライアンスは少し複雑です。まず、共有ホスティングでは、現在のプロバイダーが関連するすべての要件を満たす必要があります。参照 誰かがAWSでPCIコンプライアンスを達成していますか？
第二に、カードを処理している端末を持っている人は誰でも苦情を担当する責任があります。このような状況では、あなたは処理者ではなく、クレジットカード会社と契約を結んでいないようです。その意味で、あなたは準拠する必要はありません（次の大きな警告）
ただし、端末を持っている人は準拠する必要があり、カードの処理プロセスで使用するすべてのもの（サードパーティとしてのあなたを含む）が必要です。コンプライアンスを達成するため。コンプライアンスには積極的なレビューが必要です。その深さは、処理されるトランザクションの量によって異なります。
最も重要なのは、クレジットカード番号を保存し、実際に処理しないという状況にあることです。
PCIコンプライアンスは、処理されるトランザクションの量に関係しています。小さなお店はあまり心配する必要はありません。大規模な企業は、PCIに準拠しているのは、それらが すべての標準 指定を満たし、PCI評議会承認の監査人によって承認された場合のみです。たとえば、VISAは、年間600万件のトランザクションを処理する人物として指定しています。
https://www.pcisecuritystandards.org/merchants/how_to_be_plied.php に商人のためのガイドがあります
絶対にそうではない
カードの詳細の保存は、これよりもはるかに進んだ特定の設定でのみ承認されます。
説明されているようにこれを行うことは、PCIの苦情だけでなく、さまざまなプライバシーおよび商取引法の下で多くの国で違法になる（多くは、ポリシーおよび規制についてPCI SSCに従う）
さらに、この方法で取得された端末を介して支払いを処理することは、ほぼ間違いなくMSAのサーバー違反です。このような違反は、罰金または法的措置の救済によって管理される場合があります。
それは理想的ではなく、正直に言うと、あなたは違反しているように聞こえます OWASP a9 。チェックアウトプロセスは無意味です。問題は、プレーンテキスト上で認証トークン（THE COOKIE）をこぼすことです。
CC情報を取得し、それをターミナルで実行している場合、それはCVC/CVVを保存していることを意味しますか？ PCI DSSのもとで、いかなる理由であれ、許可を得てから保管することはできません。
複雑ですが、要するに、この設定は準拠していません。まず、提供された限られた情報に基づいて、内部システムではなく、インターネットに面したゾーンにカードデータを保存します。この設定には他にも多くの問題点があります（管理インターフェース、暗号化のための鍵管理など）が、データストレージは目立つものです。
検証する必要がある共有ホスティングプロバイダーの追加要件もあります。 PCIでは、共有ホスティングは、準拠した支払いゲートウェイにリダイレクトするマーチャントページ以外にはあまり適していません。なぜあなたのクライアントはこれをしていませんか？
すべての良い答え。 PCIは、クレジットカードデータを格納する場合、システムをスキャンして脆弱性を検出するために最低でもASVが必要であると述べています。 （トランザクションレベルに基づいて）レベル1または2に到達した場合、それを行うにはQSAが必要です。肝心なのは、クレジットカードのデータを何らかの方法で保存している場合、誰にとってもリスクがあるということです。実行できますが、実行しているボリュームによっては、システムを検証するためのコストが非常に高くなる場合があります。
残念ながら、前述のように、答えは「いいえ」です
完全なPCIコンプライアンスを達成するには、非常に具体的な多くの要件を満たす必要があります。完全なリストはここにあります：
https://www.pcisecuritystandards.org/documents/pci_dss_v2.pdf
これらの要件の一部は、サーバーの管理方法に関するもので、その他は内部の役割の分散などに関するものです...
たとえば、セクション9.1.1は次のように述べています。
"ビデオカメラやアクセス制御メカニズムを使用して、機密領域への個々の物理的アクセスを監視します。収集されたデータを確認し、他のエントリと関連付けます。法律で特に制限されていない限り、少なくとも3か月間保存します。 「[これは明らかにアクセスの提供について話している]
私はこのセクションに焦点を当てて、PCI準拠が「純粋に技術的な」問題ではないことを示すことにします。
とはいえ、テクニカルサイトでは、次のいずれかを要求するセクション6.6に注目する必要があります。
- 手動または自動化されたアプリケーションの脆弱性セキュリティ評価ツールまたは方法を介して、少なくとも年に1回、変更後に公開されているWebアプリケーションをレビューする。
- 公開Webアプリケーションの前にWebアプリケーションファイアウォールをインストールする。
これは、WAFを配置するか、Webアプリケーションにすべての変更を加えた後（これは重要です）に定期的なチェックを実行する必要があるため、おそらく請求書全体で最も厳しいセクションです。
つまり、純粋な悪夢...
このセクションは、多くのSMBウェブサイトの所有者をPCI DDSから遠ざけ、サードパーティの課金プロバイダーの腕に入れます。セットアップとメンテナンスのコストが高すぎるためです（WAFはメンテナンスコストの前でさえ、数千ドル、およびすべての変更後の定期的なチェックはオプションではありません。
最近、この問題に対する手頃なソリューションが、クラウドベースのPCI準拠のWAFを介して利用可能になりました。
ここでの考え方は、「共有利用」と「規模の経済」の考え方です。このシナリオでは、WAF保護はクラウドを介してユーザーのコミュニティ（ウェブサイト）に配布され、各メンバーコミュニティは完全なWAF機能と更新を取得しますが、全額の一部を支払うだけで済みます。
これにより、初期設定/購入コストが大幅に削減され、追加のメンテナンスコストもすべて排除されます（中央のセキュリティチームがすべてのクラウドユーザーのWAFを運用および更新するため）。
また、これは完全な標準化を提供し、非常に高い維持管理品質を約束します（絶え間なく変化するセキュリティ環境では非常に重要ですが、専任のセキュリティ担当者/チームなしでは達成できません）。
（免責事項-私はこのソリューションを提供する会社で働いています）