私が働いている場所には、顧客のクレジットカードを処理するためのイントラネット上のeコマースシステムがあります。現在、Authorize.netを使用して顧客のクレジットカードに請求する際、安全な接続を介してクレジットカード情報をAuthorize.netに送信していません。代わりに、それは通常のhttpに行きます。私はこれがどれほど重大であるか/過失であるかの他の意見を得たいと思います。ありがとう。内部クレジットカード処理のための安全な証明書はどれくらい重要ですか？
EDIT：私は間違っているようです。私はコード内をスヌーピングし、それはhttps://secure.authorize.netでクレジットカードを処理しているようです。ただし、クレジットカードが入力されたWebページは安全ではありません。これは私が最初に説明したのとは異なる状況です。申し訳ありません。
これは非常に間違っているようです。このような振る舞いを可能にするために、クレジットカード情報の漏れが多すぎます。
処理がイントラネット内で処理され、サードパーティに送信されない場合でも、セキュリティで保護された接続を使用することをお勧めします。誰か、内部の権限を持たない従業員までアクセスできるようにすることは望ましくありません。
これは、絶対に受け入れられない災害です。あなたは直ちに（そして私はすぐに）少なくともトランスポートレベルのセキュリティ（SSL/TLS）を使用する必要があり、Authorize.netがメッセージレベルのセキュリティを設定できる場合は、それを設定する必要があります。
私は混乱しています。プレーンなHTTPリクエストをAuthorize.netにどのように送りますか？彼らのトランザクションエンドポイントはHTTPバージョンを持っていません - それを許可するには犯罪的に怠慢です。
これで編集したことが少しわかります。はい、それはです。まだです。イントラネットページをHTTPSではなくHTTPにするセキュリティリスクがありますが、あなたの質問が最初に示したもの（公開インターネットの暗号化されていない転送）よりもはるかに小さいです。
内部的には有料のSSL証明書は必要ありません（コストがHTTPSを避ける理由であれば他の理由は考えられません）。自己署名証明書を使用できるはずです。
これは非常に重要なことであり、何が重大な問題を引き起こす可能性があります。
また、PCI規格に準拠しており、クレジットカード情報を処理するすべての企業はPCI規格に準拠している必要があります。
私はOWASPのガイドを読んで推薦： http://www.owasp.org/index.php/Category:OWASP_Guide_Project以降（無料ダウンロード）
ページ53と..いくつかの素晴らしい情報を手に入れました。
私はあなたがしていることはひどい過失であり、できるだけ早く分類する必要があると言います。
良い質問。私が説明したこのeコマースシステムでは動作しません。私が知る限り、このWebサイトに関連付けられた安全な証明書がありません – SquidScareMe
これは同じことではありません。 –
あなたは正しいです。私の元の投稿への私の編集を見てください。ありがとうございました。 – SquidScareMe