PCI DSSv4.0を読む⑥ 要件3の変更概要

PCI DSSv4.0が3月31日（日本時間の4月1日）にリリースされました。PCI DSSv3.0がリリースされたのは2013年12月でしたので、実に8年ぶりのメジャー改訂となります。

5/13に日本語版が1ヶ月少し遅れてリリースされました。英語版の360ページに比べて遥かに多い453ページの”大作”となっており、中々細部まで読むのが大変な基準書となっていますが、PCI DSSの専門家を自負している1人として、個人的な感想を交えて何回かに分けてv4.0について記事を書ければと思います。

※①~④までの記事は英語版をベースに機械翻訳をしたものでしたので、日本語表現が正式版とは少し違っているかと思います。記事修正は少しまとまった時間が取れた際に実施予定です。

要件3：保存されたアカウントデータの保護

要件3のタイトルは少しだけ変わっています。v3.2.1では、「保存されるカード会員データを保護する」となっていましたが、保護すべきなのはカード会員データだけでなく、機密認証データまで含めたアカウントデータ全体であるという意図からタイトル変更が行われています。

要件3での新要件は10あり、全体で64の新要件である事を考えるとかなり変更が入っています。また新要件のほとんど(7つ）が2025年3月31日までベストプラクティス、以後要件化という、いわゆる「期限付き」の要件となっており、準拠対応に苦労する可能性がある事を考えると、多くの事業者が影響範囲を早めに把握しておくべきかと思います。

最初の新要件は、前回の要件2と同様に、機能と役割に関する要件です。こちらは対象がアカウントデータに関するものですので、要件2のシステムコンポーネント視点よりは少し対象範囲（影響度）が狭いかと思います。

データを自組織だけでなく、他組織でも取り扱っている様な場合は、責任分界点を明確にする事が必要になる可能性もありますので、アカウントデータの資産管理／棚卸（要件3.2.1）に併せて、管理者を明確化するといった事が有効かと思います。

次の新要件は3.2.1です。v4では機密認証データ（SAD）の保存が限定条件付きで許可される様になったので、その部分が修正されています。実運用に合わせた修正と言えるかも知れません。

限定条件については、要件の前段部分（P8)に説明があり、オーソリ完了後のデータ廃棄は維持されているものの、オーソリ完了前のデータ保管が条件付で認められています。

機密認証データ（SAD）に関する原則ルールが要件3.2.1、そしてオーソリ前に保存する場合には強力な暗号化が必要であるとの新要件が3.3.2に書かれています。

そして機密認証データを保存する正当性についての新要件が、3.3.3にあり、正当化の理由についての（保存が必要とのイシュア判断）の文書化、及びオーソリ後にきちんと削除されているかのテスト確認が要求されています。

要件3.4.1はPANの表示について、ビジネス上の正当性がある担当者だけがマスキングを超えて（16桁の）PANを見る事が出来るとの新要件になっています。この要件もコールセンター業務や保守などの正当性のある運用に対して、必要最低限のPAN表示（利用）が認める内容になっています。

要件3.4.2では、PAN情報の保護という観点で、上記3.4.1といったコールセンターや保守業務などでリモートアクセスによりカード会員データ環境（CDE）からPAN等を閲覧する様な場合、PANが容易にコピーされて持っていかれない様な保護を求めた新規定です。

ファイルの持ち出し（コピーや移動）を禁止する技術としてはシンクライアント端末を使った運用あるいは業務ソフトでファイル持ち出しに制限をかける方法などが考えられますが、新規にこうした取り組みが求められる事業者は、PAN表示が本当に必要かどうかのレビューも含めて、新要件への対応を考える必要がありそうです。

要件3.5.1の新要件は間違い探しの様な軽微な修正です。

v3.2.1では、インデックストークンと『パッド』とあるのですが、ここが削除されています。

要件3.5.1.1はPANを保管する場合の鍵付き暗号ハッシュについての新要件です。ハッシュといっても危殆化したハッシュもありますので、業界標準以上の安全なハッシュ方式をきちんと使用しなければいけないという事が要求されているものとなります。

この要件も2025年3月31日までの期限付きですが、これは既にハッシュ運用をしている事業体が、新しい（安全な）ハッシュ方式に切り替えるのに時間がかかるという事を考慮しての付帯条件だと思います。

要件3.5.1.2も新要件です。リムーバブルメディア（媒体）又は、リーム―バブルでない電子メディア（HDDやSSDでしょうか）を使用する場合に、確実にPANデータが暗号化されている事を要求しています。

ディスクレベルやパーティションレベルで暗号化されている場合は、安全性が担保できないケースもあるので、ベンダー推奨または業界のベストプラクティス（NIST等）に従って、PANを確実に読取り不能にする事が必要です。

最後の新要件は3.6.1.1です。サービスプロバイダーのみの要件ですが、本番環境とテスト環境で同一の暗号化鍵を使用してはいけない、という一見、当たり前に事業者が実装していそうな要求です。

しかし・・期限付きでこれが新要件となっている事を考えると、実運用でテスト鍵を使わずに本番鍵を使っている事業者が『相当多い』事を示唆している気がします。

運用している暗号鍵の数によりますが、特にサービスプロバイダーは相当数の暗号鍵を使用しています。そうした意味でビジネス上、または運用機器における何らかの制約があったりするケースもあるのでしょうが、本番データをテストデータとして使ってはいけないと言われる以上に、本番鍵をテスト鍵として使うのは、漏えいのリスクを考えると非常に危険です。

サービスプロバイダーは2025年3月末までの猶予期間中に、”何らかの制約”について解消する事が求められている様です。