PCI DSS v3.0対応をされている日本全国のみなさん、こんにちはー！
自己問診のSAQを含め、PCI DSS v3.0の日本語リソースは足りていないとお考えではありませんか？
SAQに新しくeコマース向けのカテゴリができるみたいなんでちょっと訳してみました。
これからのセキュリティポリシー策定などに、お役に立てると幸いです。

免責事項: 以下の内容は個人の翻訳によるもので、翻訳前の元資料との整合性を保証するものではありません。あくまで参考程度に御覧ください。
注意事項: SAQ A-EPは適用開始されるのは2015年1月ごろと言われており、
SAQ A-EPの要件も最終的な決定ではないので、トーンダウンされる可能性や大きく変更されることがあるそうです。

元資料:
https://www.pcisecuritystandards.org/documents/Understanding_SAQs_PCI_DSS_v3.pdf

視点	SAQ A	SAQ A-EP
概要	カード会員データ機能がすべてアウトソースされている	eコマースの決済手段が一部アウトソースされている
適用対象	非対面取引(CNP)を行っている加盟店(eコマースまたはメール/電話による注文)	eコマースを行っている加盟店
アウトソースしてる機能	支払いの受け入れ、処理がPCI DSSに準拠しているサードパーティサービスプロバイダに完全にアウトソースされている	カード会員データの処理がPCI DSSに準拠しているサードパーティ決済事業者にアウトソースされている
カード会員データのコントロール	加盟店のeコマースウェブサイトはカード会員データを受け取らず、カード会員データの読み込み、処理、伝送または保存に関する直接的コントロールがない	加盟店のeコマースウェブサイトはカード会員データを受け取らない。しかし、顧客やカード会員データのコントロールはPCI DSSに準拠しているサードパーティ決済処理業者にリダイレクトされている
決済ページ	すべての決済ページは PCI DSSに準拠しているサードパーティのサービスプロバイダから直接顧客のブラウザに提供されている	決済ページのすべての要素は、加盟店もしくはPCI DSSに準拠しているサービスプロバイダから提供されている
サードパーティの準拠状況について	加盟店はすべてのサードパーティがカード会員データの受け入れ、保存、処理または伝送についてPCI DSSに基づいてハンドリングしていることを確認している	加盟店はすべてのサードパーティがカード会員データの保存、処理または伝送についてPCI DSSに基づいてハンドリングしていることを確認している

どのようなタイプのeコマース実装が、SAQ A-EPとSAQ Aに適格なのか

SAQ Aを受ける資格があるのは、SAQ Aに詳述されている基準をすべて満たすeコマース加盟店である必要があります。これには、加盟店のウェブサイト上に決済情報を(読み取る、記録する？)プログラムやアプリケーションコードがないこと、を含みます。
以下に、SAQ Aに含まれるeコマース実装例を示します。

加盟店は自身のウェブサイトにアクセスしない。そして、ウェブサイトはPCI DSSに準拠しているサードパーティ決済事業者によってホスト、管理されている
加盟店のウェブサイトは、PCI DSSに準拠している決済事業者が提供する(支払いプロセスを促進する)iFrameを利用している
加盟店のウェブサイトは、自身のウェブサイトからユーザーをリダイレクトするURLリンク(PCI DSSに準拠している決済事業者が提供する)が含まれている。

もし、顧客のブラウザに支払いページの任意の要素が加盟店webサイトから提供された場合、SAQ Aは適用されません。SAQ A-EPが必要になる可能性があります。

以下に、SAQ A-EPに含まれるeコマース実装例を示します。

加盟店のウェブサイトが決済フォームを作成し、決済データは直接決済事業者に提供される(いわゆる、Direct Postと呼ばれるもの)
加盟店のウェブサイトが、決済ページの作成または決済事業者へのデータ伝送機能を提供またはサポートするために、顧客のブラウザで動作するスクリプト(例えば、JavaScript)を読み込む、もしくは提供する

加盟店に課される負担

https://www.pcicomplianceguide.org/new-more-a-first-look-at-the-pci-dss-3-0-saqs/
上記から引用したが、公式情報ではないため注意が必要

SAQのタイプ	準拠が必要な要件の数	ASVスキャンが必要か	ペネトレーションテストが必要か
A	14	不要	不要
A-EP	139	必要	必要

FAQより

なぜSAQ A-EPはDirect Postを採用し、SAQ AはiFrameやリダイレクトを採用しているのか

決済の受け入れの観点では、DirectPostとiFrame/redirectの間には大きな差がある。この差がSAQの違いとなっている。DirectPostの実装では、加盟店のウェブサイトは、決済データを受け入れるために使用するウェブページを生成し、その後、サードパーティの決済プロセッサに直接渡します。この実装では、顧客(カード所有者)は、加盟店のウェブサイトから離れることはありません。

反対に、リダイレクトやiFrameでは、サードパーティの決済プロセッサが決済データを受け入れるウェブページを生成します。加盟店のウェブサイトは、決済データの受け入れに直接参加しません。サードパーティの決済プロセッサが直接決済データを受け入れます。リダイレクトやiFrameの実装では、顧客は加盟店のウェブサイトを離れ、決済の受け入れと処理のために決済プロセッサに向かいます。

このデータフローは、SAQ AとSAQ A-EPの間のキーとなる違いであり、「受け入れ」という言葉がSAQ Aの適用性基準に含まれ、A-EPには含まれていないかを以下のように説明しています。

SAQ A: すべての決済の受け入れと処理は完全にPCI DSS準拠のサービスプロバイダにアウトソースされている。
SAQ A-EP: すべてのカード会員データの処理は、PCI DSS準拠のサービスプロバイダにアウトソースされている。

どうしてDirectPostと、iFrameやURLリダイレクトは実装上別のアプローチになっているのか。eコマースのセキュリティに与えるインパクトの違いは何なのか。

eコマースでカード会員データを盗む方法は、加盟店のウェブサイトがカード会員データを受け付けるかどうかにかかっている。トランザクションをより保護するには、どのように犯罪者がカード会員データの供給を受けるかについても知る必要がある。

PCI DSSは、犯罪者が加盟店のeコマースからカード会員データを盗む可能性を下げるためにある。この3年で攻撃手法は、直接カード会員データを処理しないが、決済サービスプロバイダと連携するパターンで2つの攻撃手法を見ている。

概ね、これらの加盟店はSAQ Aを完了し決済の処理は全てアウトソースされていると信じていた。なぜなら、攻撃の性質上カードブランドやPCI SSCは加盟店が合法的に処理をアウトソースできる条件を明確にしたからである。

PCI DSS v3のSAQ Aに適格であるには、eコマースの環境が全てアウトソースされている必要がある: 全ての決済ページはPCI DSSに準拠したサードパーティのサービスプロバイダから直接顧客に提供される必要がある。
加盟店のウェブサイトは、顧客をサードパーティの決済ページにリダイレクトすることも、サードパーティの決済ページをiFrameで埋め込むことも出来る。
これらの方法に対する主な攻撃手法は、加盟店のウェブサイトのコードを書き換え、悪意のあるページにリダイレクトすることです。これは、中間者攻撃として知られています。
犯罪者としての欠点は、この攻撃は通常すぐに検出されることと、危険にさらされるカード会員データが最小限に留まってしまうことです。
付け加えると、いくつかの決済サービスプロバイダは中間者攻撃を検出し、加盟店に通知するソリューションを開発しています。

また、加盟店のウェブサイトは顧客のブラウザから直接カード会員データをPOSTする前に、カード会員データを受け入れるための決済ページを生成する方法がいくつかあります。
この決済を受け入れるページのフォーム要素は、加盟店のウェブサイトから読み込んだHTMLか、顧客のブラウザがサードパーティから読み込んだJavaScriptで生成されることだろう。
加盟店からの観点では、これは魅力的なソリューションである。というのも、加盟店は、決済ページの見た目や決済フローを、リダイレクトやiFrameを使う場合に比べて自由にコントロールできるからだ。
これに対抗する攻撃のシナリオは、入力されたカード会員データをコピーして犯罪者のサーバに送信するだけの単純なJavaScriptを含めることにより、決済ページを危険にさらすことである。しかも、実際の決済フローは影響を受けないし、この攻撃手法は発見するのが難しい。カード会員データを犯罪者に継続的に供給することになりかねない。
この種の環境を適切に保護する保証レベルを提供するために作られたのがSAQ A-EPである。

PCI SSCは、加盟店がeコマースをする様々な方法が継続的に発達していることを理解しています。
加盟店やQSA(PCI DSSの監査員のこと)は、困惑するようなアドバイスをベンダーから受ける可能性がある。とりわけ、iFrameを使うのか決済フォームを埋め込むdivタグを最小限にするのかといった内容で。

ただし、セキュリティの差は相当なものである。完全なhosted payment pageと、iFrameで読み込まれた決済ページは、カード会員データの明らかな盗難に対して耐性がある。(ここの訳に自信がない)
直接のPOSTや、JavaScriptのフォームといった技術ではない。

PCI SSCは、リダイレクトやiFrameに対して中間者攻撃が可能であることを認識しているが、ペイメントブランドの認識では、これらはカード会員データのかなりのボリュームが失われる前に検出できているとのことである。

PCI SSCは、耐タンパ性と改ざん検知を促進し、中間者攻撃の実行可能性を減少させるために決済サービスプロバイダと協力しています。

加盟店やQSAが、SAQ AかSAQ A-EPのどちらを完了すればよいか自信がないときは、まず顧客のブラウザに配信されるすべての決済ページの全体が、PCI DSSに準拠したサービスプロバイダから直接配信されているかどうか判断することをおすすめしています。
もし、決済ページの要素が加盟店もしくは、PCI DSSに準拠していないサービスプロバイダから配信されたら、この実装はSAQ Aに適格ではありません。
もし、この条件が満たされたかどうか不明な場合は、アクワイアラーやペイメントブランドに連絡することをおすすめします。