問題タブ [pci-compliance]

私が働いている会社は、フォームのスキャン画像を受け取り、そこからデータを収集します (XML ファイルに入れます)。クレジット カード番号はフォームに書き込まれますが、そのデータを収集したり、支払いを処理したりすることはありません。

このようなシナリオでは、PCI 標準は適用されますか? 番号を含む実際のデータ ファイルはありませんが、画像を見れば誰でも簡単にクレジット カード番号を取得できます。カード所有者名が表示されます。セキュリティ コードはありません。有効期限が含まれているかどうかはわかりません。

私たちはサービス プロバイダーの定義に当てはまると思います。私には、SAQ-D が適用される可能性が最も高いように思えました。問題の環境は、SAQ-D のすべての要件を満たしていません。

私が読んだものからの私の意見では、要件は適用されますが、適用されなかったとしても、それらに従おうとしないのはなぜですか? 私より上の人たちは、定期的に画像を削除している限り問題ないと思っています。

このタイプのシナリオで標準に従うことに賛成または反対する、入力、リンク、PCI-DSSドキュメントの関連セクションなどに感謝します。

PCI準拠のクラウドソリューションを使用するには、プライベートクラウド環境が必要であり、GoogleAppEngineを使用できないという記事をいくつか読みました。クレジットカード情報と個人ユーザーデータをGoogleAppEngineアプリケーションに具体的に保存するPCI準拠のウェブサイトを作成することは可能ですか。これが不可能な事実上の非秘教的な理由、またはアプリエンジン開発者が実行する必要があり実行できる高レベルのタスクディレクティブのリストをリストしてください。

Railsアプリで検証を開発する方法を考えています。この検証では、すべてのクレジットカードを使用してアイテムを購入できるように、ユーザーが特定のトランザクションに使用するクレジットカードがシステム内で一意であることを基本的に確認します。すべてのユーザーのアプリケーション全体で、いつでも1回だけ。

この制限の背後にある考え方は、このアプリが時間に敏感なプロモーション取引を実行することがあるということです。私たちはこれらの取引に対して「クレジットカードごとに1回の購入」システムを確立するために最善を尽くしたいと考えています。

クレジットカード番号をハッシュしてそのハッシュをデータベースに保存し、新しい購入のたびに相互参照することを考えていました（したがって、支払いゲートウェイは実際の番号を保持し、ハッシュはDBに保持します） 、しかし、さらなる調査では、これは悪い考えのようです。

それで、私は製図板に戻って、新しいアイデアを探しています。私ができる限りPCIに準拠しながら、この問題への優れたアプローチを知っている人はいますか？

私はRails3で開発しており、ActiveMerchantを使用して、支払いゲートウェイであるAuthorize.netと統合しています。

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

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

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

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

市販の ASP.net メンバーシップ プロバイダーとテーブルは、PCI に準拠していないようです。ASP.net 用の PCI 準拠のメンバーシップ プロバイダーを既に実装している人はいますか? 特に、セクション 8.5 の要件を検討しています。

• 8.5.2: 非対面の方法で行われたユーザー要求のパスワードのリセットを実行する前に、ユーザーの身元が確認されていますか?

  このために、X 時間以内に有効なリセット トークンを含む電子メールを考えています。デフォルトのプロバイダーは、ランダムな値を生成してメールで送信するだけです (ただし、この要件を満たすためにセキュリティの質問/回答を有効にすることもできます)。

• 8.5.5: 90 日以上経過した非アクティブなユーザー アカウントは削除または無効化されますか?

  デフォルト プロバイダはこのアクションをサポートしていません。ログイン試行の続行を許可する前に、OnLoggingIn に結び付けていくつかのチェックを行うことができます。

• 8.5.9: 使用パスワードは少なくとも 90 日ごとに変更されていますか?

  この OnLoggedIn を確認できるはずです。最後のパスワードの日付が 90 日を超えている場合は、目的のコンテンツではなく、パスワード変更フォームにリダイレクトします。

• 8.5.12: 個人は、過去に使用した 4 つのパスワードのいずれとも異なる新しいパスワードを送信する必要がありますか?

  デフォルト プロバイダーのメンバーシップ テーブルがこれをサポートしているとは思えません。パスワード履歴テーブルを追加して、誰かが新しいパスワードを作成するたびにエントリを貼り付けることができます。これらは、ChangePassword コントロールの OnChangingPassword イベントで確認できます。

私はこれを自分で十分に行うことができますが、すでに何かがある場合は利用したいと思います.

私は、新しいベンチャーのために取り組んでいるプロジェクトで遭遇した「鶏と卵」の問題の解決策を見つけようとしています。

問題のシステムはクレジットカードのデータを扱っているため、カード番号などを暗号化してデータベースに保存する必要があります。PCI 要件に準拠するために、「加盟店」ごとに一意のキー ペアで番号を暗号化しています。そのため、1 つの加盟店が侵害された場合、別の加盟店のカード所有者データにアクセスすることはできません。

人間がパスフレーズを入力して秘密鍵のロックを解除し、データを復号化できるため、システムとの人間の対話に関しては問題ありませんが、データにアクセスする必要がある自動化されたサービス (つまり、トランザクションを処理するため) に関しては、これは問題ありません。サービス/デーモン プロセスに資格情報を提供する最善の方法に問題があります。

システムの背景のビット:

• カード番号は非対称鍵ペアで暗号化されます
• 秘密鍵はパスフレーズで保護されています
• このパスフレーズは、「マスター」鍵ペアで暗号化されます
• マスター秘密鍵のロックを解除するためのパスフレーズは、許可を与えられたオペレーターに知られます (実際には、彼らはパスフレーズしか知らない独自の鍵ペアで暗号化されたそのコピーです)。
• デーモン プロセスは、Linux システム上で独自のユーザーおよびグループとして実行されます。

デーモンがデータを復号化できるようにするために、次のことを検討していました。

• .pgpassの仕組みと同様のパスフレーズ ファイルをセットアップします。
• デーモン ユーザーのホーム ディレクトリにファイルを格納します。
• ファイルのパーミッションを 0600 に設定します
• Tripwire などのファイル整合性監視システムをセットアップして、ファイルまたはアクセス許可に対する変更をセキュリティ グループ (または同様のグループ) に通知します。
• プロセスにのみ使用されるデーモン ユーザーのログインを無効にします。

以上のことから、これで十分かどうかは疑問です。明らかに弱点はシステム管理者にあります - 安全なシステムで信頼されているのは少数 (すなわち 2 人) です - 彼らは権限を昇格させ (つまり root に)、ファイルの所有権または権限を読み取り可能に変更できます。パスフレーズ - ただし、これもまた、ファイルのチェックサムの変更、FIM チェックサムなどを監視することで軽減できる可能性があります。

それで、私はこれを間違った方法で行っていますか、それともこれを処理する方法について他の提案はありますか?

AWSの負荷分散されたEC2インスタンスでPCI準拠を試みています。解決しなければならない問題の1つは、ロードバランサーが弱い暗号を受け入れることです。ただし、ELBは暗号スイートをサポートしていないため、各暗号を1つずつ手動で設定する必要があります。問題は、強力な暗号として適格なもののリストが見つからないことです。たとえば、この設定はどの暗号に変換されますか。

SSLCipherSuite ALL：！aNULL：！ADH：！eNULL：！LOW：！EXP：RC4 + RSA：+ HIGH：+ MEDIUM

この情報を見つけるのは驚くほど難しく、AmazonにはデフォルトのPCI準拠の設定がありません（これは非常にばかげているようです。2つのデフォルトのポリシーがあります。3つ目は「強力なPCI」などと呼ばれます）。

Paypal を iPhone アプリケーションに統合する際にどのアプローチを取るべきかを考えています。現在、アプリで Paypal ライブラリを使用していません。代わりに、UIWebview を使用して Paypal の Web サイトへの URL を開き、顧客がそこからチェックアウトできるようにしています。Mobile Express Checkout Library または Mobile Payment Libraries を使用することが PCI 準拠であるかどうか疑問に思っています。また、Paypal のサイトまたは開発者サイトで、このことを説明しているドキュメントはどこにありますか。

制御を支払いゲートウェイに転送する支払いゲートウェイ統合を介して支払いを受け入れている e コマース サイトがあります。業界では、クレジット カード情報を受け入れ、サイト自体でトランザクションを処理することでコンバージョン率が向上する (ドロップオフが減少する) ことは認められていますが、これは、PCI に準拠する必要があることを意味します。ストライプ支払いゲートウェイと、PCI コンプライアンスの負担を回避する (stripe.js 経由で) 提供される統合について読みました。他の支払いゲートウェイについて同様のものを読んだことがないため、ここで見逃している潜在的な問題はありますか? または、そのような統合を提供する他の/新しい支払いゲートウェイがありますか.

Apache Tomcat（最新バージョン）がPCIに準拠しているかどうかを誰かが知っていますか？もしそうなら（またはそうでなければ）、肯定/否定をサポートするためのリンクをいくつか教えてください。

前もって感謝します