Facebook ConnectまたはTwitter OAuth PCIに準拠していますか？
クレジットカードを安全に保管するシステムがあります。ユーザーがFacebook ConnectまたはTwitterを使用してサインアップできるようにしたいと思っています。
古いOAuthまたはOpenIDプロバイダーのみを信頼している場合、これは安全ではありませんが、FacebookおよびTwitterの場合は特に、PCI準拠のサインアップ/ログインプロセスを実装することは可能ですか？クレジットカードをファイルに保存したままですか？
PCI DSS v2 、要件7：「強力なアクセス制御手段の実装」が適切なセクションです。このセクションでは、カード所有者にアクセスする非消費者向けのアクセス制御について主に説明しますビジネス目的のデータ。ただし、消費者と非消費者に適用できるように見えるいくつかの要件があります。
8.1システムコンポーネントまたはカード会員データへのアクセスを許可する前に、すべてのユーザーに一意のIDを割り当てる
8.2一意のIDの割り当てに加えて、次の方法の少なくとも1つを使用してすべてのユーザーを認証します。
パスワードまたはパスフレーズ
トークンデバイスまたはスマートカード
バイオメトリック8.3従業員、管理者、および第三者によるネットワークへのリモートアクセス（ネットワークの外部から発生するネットワークレベルのアクセス）に2要素認証を組み込みます。 （たとえば、トークンを使用したリモート認証およびダイヤルインサービス（RADIUS）、トークンを使用した端末アクセスコントローラアクセス制御システム（TACACS）、または2要素認証を容易にするその他のテクノロジ。
8.4強力な暗号化を使用して、すべてのパスワードを送信中およびすべてのシステムコンポーネントでの保存中に読み取り不可能にする
上記を念頭に置くと、Facebook Connect/oAuthがカード所有者システムに接続するサードパーティのサービスと見なされる可能性があるため、システムへの2要素による認証が必要になる場合があります。 （要件8.3から）
また、実際にはシステムに接続するサードパーティのサービスではないというケースも考えられますが、これは単にシステムに対するコンシューマーの認証を容易にするものです。
あなたのQSAはそれを要求しなければならないでしょう。
過去10年間に多くのIT監査を実施してきたことから、私の最大の懸念は、このサードパーティの認証メカニズムが正常に機能することを確認することだと思います。 FacebookやTwitterで何かが起こった場合（ユーザーベースが大規模なため、人気のターゲットである）、何かに問題が発生すると、これは非常に厄介な立場にあり、一般的には認証メカニズムを監査する...
現実的には起こりません
そのため、例外が発生し、企業はそれを承認する必要があります。彼らは彼らがサインオフしているものを完全に理解しますか？あなたにとってこれが彼らにとってどれほど大きな取引であるかを説明する場合にのみ。
Joshが指摘したように、このケースに当てはまる可能性のあるPCI内の表現がありますが、結局のところ、このレベルのリスクが必要かどうかは、監査人と事業主にかかっています。
認証にTwitter/Facebookを使用することを検討している場合に考慮すべきことの1つは、認証後、HTTPではなくhttpを介してアクセスされるため、どちらも暗号化されていない接続を介してセッションIDを送信できることです。
そのため、PCI要件に適合しているとは考えられません。
元の質問では、Facebook、Twitterなどの認証方式がPCIに準拠しているかどうかを尋ねます。
ペイメントカード業界（PCI）データセキュリティ基準（DSS）仕様では、認証に関して2つの別個の異なる点を引用しており、要件を区別するのは使用のコンテキストです。
セクション8では、コンピューターにアクセスできる各ユーザーに一意のIDを割り当てる必要があると述べています。ユーザー名「プリンシパル」（どのサービスからのものでも）はその要件を満たしています（一意です）。
このセクションでは、パスワードコンポーネントが準拠する、承認されたユーザーの確認について説明します。したがって、これはカード所有者の検証のための基本的な「認証」（これが私たちがそうであると考える人）をカバーしています。
ただし、付与されるアクセス権によって異なります。保管されている支払い手段の場合、カード所有者がそれに対して購入を行うには、これで十分です（支払い手段の構造のストレージがPCI要件を満たしている場合など）。
ただし、支払いシステムへの「リモートアクセス」の場合（通常）-2番目の要素の認証（たとえば、音声/ SMSワンタイムパスワードによる帯域外）が必要です。この場合、たとえば、電話番号のコールバックオプションが支払いシステムへのリモートアクセスの第2要素認証の手段として実装されていれば、Googleは準拠しています。電話番号が利用できない場合、またはFacebookが支払いシステムへのリモートアクセス用の第2要素認証を実装していない場合は、準拠していません。