サービスプロバイダー向けのSAQ

実行計画では、加盟店契約会社、カード発行会社、およびPSPなどのサービスプロバイダーには非保持化の選択肢を認めておらず、PCI DSSへの準拠を求めている。これらのサービスプロバイダーがQSA（認定セキュリティ評価機関）によるオンサイトレビュー（外部監査）を行わず、自己問診で準拠を行う場合に使用するのが「SAQ D サービスプロバイダ」（SAQ D-SP）である。加盟店向けのSAQ D-Mとの違いはわずかであるため、そこに焦点を当てて解説する。

●セクション1　評価情報
SAQ D-SPでは、パート2aで「評価範囲の検証」を選択・記述する。評価の対象範囲とする業務として「ホスティングプロバイダ」「管理サービス」「支払い処理」「アカウント管理」「ペイメントゲートウェイ」などの選択肢から該当するものを選ぶ（複数を選んでもよい）。

加えてパート2aでは、他社のサービスを利用しているためにPCI DSSの評価の対象に含めなかった業務の内容も記述する。例えば、銀行系カード会社のフランチャイジーとしてカード発行業務を行うカード発行会社が、業務の全てで銀行系カード会社のシステムを利用しているようなケースだ。この場合、カード発行業務用の専用PCをフランチャイジー側の社内に置いて業務を行っている。発行業務用のシステムは銀行系カード会社で管理しているため、フランチャイジー側のPCI DSS対象範囲には含まれないことになる。複数の銀行系カード会社のフランチャイジーである場合は、パート2aをコピーして1サービスごとに記入する。

パート2gには「テストした要件の概要」を記入する。「未テスト」あるいは「該当無し（適用除外）」となった要件に下位要件がある場合は、どの下位要件が対象なのかを理由とともに記述する。

●セクション2　自己問診
PCI DSSにある「サービスプロバイダのための追加要件」に対応する項目が追加されている。主な追加要件の概要と必要な対応は以下の通りである。

【暗号鍵の管理に関する要件】
「要件3.5.1」では、カード会員データの暗号化に用いる鍵、およびその鍵を保護するための暗号鍵のアーキテクチャー（主に強度）の文書化を求めている。暗号鍵のリストを作成し、鍵の強度や有効期限と用途を文書化する。ハードウエア・セキュリティ・モジュール（HSM）を使用している場合は、そのシリアルナンバーなども文書化する。
「要件3.6」では、サービスプロバイダーがカード会員データの伝送に使用する暗号鍵を顧客（加盟店など）と共有する場合に、その鍵の伝送・保存・変更に関する文書を作成し、顧客に提供することを求めている。例えば、PSPが決済モジュールの中に暗号鍵を入れて加盟店と共有する場合などがこれに該当する。

【非消費者ユーザーのパスワード管理に関する要件】
非消費者ユーザー、すなわち加盟店やホスティングサービス利用者、フランチャイジーのカード会社などに提供しているユーザーIDとパスワードに対して、以下の点を確認する。
・最大6回の無効なアクセス試行でロックアウトされる（要件8.1.6）
・強力な暗号化を適用して送信と保存中に認証情報（パスワードやパスフレーズなど）を全て読み取り不能としている（要件8.2.1）
・パスワードとパスフレーズは7 文字以上、かつ数字と英文字の両方を含む（要件8.2.3）
・ユーザーパスワードの変更が定期的に（少なくとも90日以内に）要求され、かつ変更が必要な時期や状況についてのガイダンスを利用者に周知する（要件8.2.4）
・パスワードやパスフレーズをユーザーが変更する際は、最後に使用した4つと異なるものを要求するシステムになっている（要件8.2.5）

【顧客環境にアクセスするためのログインパスワードに関する要件】
複数の顧客に対してシステムを提供しているサービスプロバイダーが各社の環境にアクセスするためのログインパスワードは、それぞれ別のものを使用する（要件8.5.1）。例えばリモートで運用管理サービスを提供するマネジメント・サービス・プロバイダー（MSP）は、Aという顧客とBという顧客へのログインパスワードを別のものにしなければならない。この要件は、共有ホスティングサービスを提供するサービスプロバイダーに対しては適用されない。なお、別々にする必要があるのはパスワードのみである。

【セキュリティシステムコントロールの障害検知と対応に関する要件】
重要なセキュリティ管理システム（例えばウイルス対策やログの改ざん検知など）に障害が発生した場合に、アラートを発することを求めている（要件10.8）。セキュリティ管理システムの障害は、物理セキュリティの警備システムのダウンと同様に重大なインシデントの兆候である。さらに、障害発生時に迅速に対応するプロセスが導入されていること、発生した障害に対して原因・障害発生期間・復旧の詳細と再発防止策を文書化することを求めている（要件10.8.1）。

【セグメンテーションコントロールに対するテストについての要件】
セグメンテーションを設定している場合、セグメンテーションコントロールに対して少なくとも半年ごとに侵入テストを実施する（要件11.3.4.1）。加盟店は年1回でよいが、サービスプロバイダーはそれよりも高い頻度の実施が求められる。

【責任者の明記に関する要件】
経営層がカード会員データの保護とPCI DSS準拠に責任を持つことを確認する。このほか、PCI DSS準拠ポリシーを作成し、経営者の名前で宣誓されていることを要求している（要件12.4.1）。顧客（加盟店やフランチャイジーのカード会社など）との契約書に、サービスプロバイダー側のカード情報の取り扱いに責任を負っていることを明記する必要がある（要件12.9）。

【内部監査プロセスについて】
四半期ごとに内部監査プロセスが要求されている（要件12.11）。この監査結果を文書化して責任者にレビューすることも求められる（要件12.11.1）。PCI DSSは、担当者の運用負担が重いため、要求される定期運用がスケジュール通りに回っていないことがしばしばある。それらが後手に回ることはサービスプロバイダーにとっては大きなリスクとなる。そのため、定期的な運用状況（四半期ごとのスキャンやログのレビュー状況）を経営層に四半期ごとにレビューすることによって、状況を把握してもらう。必要であれば経営リソース（ヒト・モノ・カネ）の投入を検討してもらう機会とする。

【SSLと初期のTLSについて】
2018 年6 月30日以降、全てのネットワーク接続でTLS 1.2を使用してサービスを提供する必要がある。それまでの間は、文書化されたリスク低減策とそれぞれのシステムごとの移行計画が必要である（要件A2.3）（※1）。

（共著：ｆｊコンサルティング代表取締役CEO　瀬田陽介
PCI Security Standard Council　アソシエイト・ダイレクター　日本　井原亮二）

※出所：書籍『改正割賦販売法でカード決済はこう変わる』（日経BP社、2018年4月発行）から著者および出版社の許諾を得て転載

    ■書籍の詳細はこちら（日経BP社）：改正割賦販売法でカード決済はこう変わる

※1：本稿は執筆時点におけるバージョンのPCI DSS V3.2を元にした記載となっております。現在（2019年4月）の最新バージョンはPCI DSS V3.2.1となります。

 
PCI DSS Ready Cloudでは、PCI DSS v4.0への効率的な移行支援及び準拠を促進するクラウドサービスを提供しています。
是非一度、ご相談ください。
PCI DSS準拠を促進するクラウドサービスならPCI DSS Ready Cloud

■ PCI DSS の構築、維持・運用にかかるコストと工数を削減する
 
■ AWSでの開発事業者や外部ベンダー/事業者との専用線接続がない場合に最適
 
■ 国内トップクラスのPCI DSS専門のコンサルタント集団によるPCI DSS準拠支援サービス