PCI DSSv4.0を読む⑤ 要件2の変更概要

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

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

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

要件2：すべてのシステムコンポーネントにセキュアな設定を適用する

v4ではまず要件タイトルが変わっています。v3では「システムパスワードおよび他のセキュリティパラメータにベンダ提供のデフォルト値を使用しない」という要件タイトルでしたが、パスワードやパラメータに対するデフォルト値（ベンダー設定の初期値）だけを気にするのだけでなく、『全般的に安全な設定にする』事が重要であると、明確化する為に変更されています。

要件2ではそれほど内容に新しい部分は無く、新規規定は要件2.1.2の1つだけです。

役割と責任（Role and Responsibility）についての明確化という、いわばセキュリティの基本的な考え方が”新規規定なのか？”と思われる方も多いのも知れません。

v3.2.1では、要件1.1.5（v4では要件1.1.2）に記載があり、ここで十分に気もしなくはないのですが、一方で”体制図”だけ作ってしまって役割と責任を与える文章を作ってしまえば良いとも読み取れるので、「セキュアな設定を適用する」という目的が達成できていない組織が多いと判断されたのかと思います。

要件2.1.2では、最初の部分に「要件2 の活動を行うための役割と責任が文書
化され、割り当てられ、理解されている。」と限定的な表現になっています。

規定全部に対して役割と責任と書かずに、要件2に新たに追加されたのは、カード会員データ環境（CDE）に影響を与えるシステムコンポーネントが、以前に比べて広範になった事が背景にあると考えられます。

例えばクラウド上でシステムが実装されているケースが分かりやすいかと思いますが、IaaSといったシステム基盤部分と、SaaSといったサービス実装部分とで社内でも”担当”が分かれる場合や、AWS/Azureといった他社のサービスの上で自社のサービスを実現しているケースも多いかと思います。

こうした複数の担当（企業）が存在する場合に、問題となるのは”責任分界点”です。PCI DSS以外のサービスも同居する環境だったりする場合、例えばPCI DSSを意識していないシステム基盤担当者が初期設定や間違った設定のままで運用しているという事も考えられ、こうした設定不備がカード情報漏洩に繋がる不正アクセスの原因となってしまう様な事もあり得るのです。

余談となりますが、過去に個人的に見たケースでは、設置されている内部機器の設定を誰も知らないという事が審査で判明した事があります。

その審査対象（CDE）のネットワークを管理しているのはA部門だったのですが、機器を設置したのが本社部門のB部門だったという事で、A部門はB部門の資産という事で”思考停止”になり、一方でB部門もA部門から要求が無いので設定書コピーもA部門に渡しておらず、機器の資産移転も行って無かった事で、管理状態不明な機器として審査で引っかかりました。

要件2.1.2では、管理者を明確にすると共に、設定レビューの実施をし、こうした”曖昧さ”を解消するための資産管理（見える化）を行う事が求められていると言えます。

PCI SSCがクラウド実装なども含めて、こうした多岐に渡る（管理者が分かれる）システムコンポーネントに対し、セキュアな設定が重要であると考えている事が分かるのが、要件2.2.3のガイダンス部分です。