PCI DSSv4.0を読む➉ 要件7の変更概要

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

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

※前回記事の6月から間が空いてしまいましたが、お盆休み期間に少し記事がかけたので公開します。

要件7：システムコンポーネントおよびカード会員データへのアクセスを、業務上必要な適用範囲（Need to Know）によって制限する

要件7ではアクセス管理対象の明確化（拡大）がされています。従来のv3.2.1で制限が要求されていたのは『カード会員データ』へのアクセスだけでしたが、v4.0では『システムコンポーネント』と『カード会員データ』へのアクセスになっています。

※v3.2.1

※v4.0

要件7における新要件は4つです。

最初は7.1.2です。他の章と同様に「役割と責任」に関する要件が新規追加されています。繰り返しになりますが、文書化要求がありますので留意下さい。

2つ目の新要件は7.2.4で、全てのユーザアカウントと関連するアクセス権限レビューに関するものです。ユーザや特権アカウントの棚卸しはv3.2.1では実施要求がありませんでしたが、新要件では少なくても半年に1回以上の実施が要求されています。

個人的な推測を交えてコメントするならば、特に特権アカウントについては、PCI DSSの要求があろうと無かろうとアカウント権限の棚卸を実施しているのが”普通”な気がしますが、真面目に棚卸を実施してなかった組織が結構あったのかと想像します。

最小権限付与というセキュリティ対策では当たり前の考え方を実現するには人手でのチェックだけでなく特権管理ソフト等の機能を使って実現する（カスタマイズドアプローチで対応する）事も可能かと思います。

注意すべきなのは、その棚卸が適切かどうかをQSA審査で説明できる事ですが、定期人事異動や退職者（もしいれば）で人の出入りがあった際の資料と、定期レビュー結果又は特権管理ソフトのログが”妥当な範囲で”一致している事を確認されるかと思いますので、運用が適切かどうか内部監査のチェックポイントに入れておく事も必要かと思います。

もう1点、例えば監視やメンテナンスで外注会社を利用する場合、そのサードパーティの特権アカウント（ユーザアカウント）も棚卸管理対象ですのでご留意下さい。

※未来日付（2025年3月31日まではベストプラクティス）の規定です

3つ目の新要件は7.2.5で、アクセス権付与に関する新規定です。

7.2.5はアプリケーションのアクセス権に対する管理規定です。ユーザだけでなく、アプリやシステムアカウントも権限があり、こうしたアカウントが侵害される事で大きな被害に結び付く事もある事から、ユーザ権限同様に最小権限付与の管理が必要となります。

システムやアプリ担当に正直ベースで聞くと教えてくれるものと思いますが、個人的経験では多くの場合、アプリケーションやシステムアカウントでは、とても分かりやすいID（アカウント）と、いくつものアプリやシステムで使い回しされたパスワードが利用されている事が多いです。

自分が担当になると分かると思いますが、管理している端末数が多い管理者ほど、この事が悪い事だと頭では理解しつつ、危ない状態でIDとパスワードが運用されています。なかなか現場でお目にかかる事はありませんが、例えばパスワード管理ソフトの導入や、または生体認証ログイン等、多要素認証の導入も、新規定と併せて考えると良いセキュリティ実装になるのではないかと思います。

※未来日付（2025年3月31日まではベストプラクティス）の規定です

最後の新要件は7.2.5.1で、7.2.4同様にアプリケーション及びシステムアカウントに対するアクセス権限レビュー（棚卸）です。

ユーザに関しては半年に1回以上の棚卸実施が必要でしたが、アプリケーション及びシステムアカウントに対する棚卸（アクセス権限レビュー）は、ターゲットリスク分析で実施頻度を決める様です。

特権付与（最小権限付与）の妥当性を機械的に判定するリスク分析になりがちな要件にも見えますが、権限リストの妥当性だけでなく、リスク分析（の判定材料）には、そうとははっきり書かれていませんが、不適切なアクセスが無かったかも含まれる可能性がある事に留意が必要です。

要件に書かれている事を実現する為には、アプリケーション又はシステムアカウントの「不適切なアクセス」を把握できる事が必要ですので、要件10.2.1.2（10.2.1.4）におけるアプリケーション又はシステムアカウントの無効なログオン試行（ログイン失敗）ログや、10.2.1.5で要求される特権昇格や新しい（アプリ又はシステム）アカウント作成のログをリスク分析で判断材料とし、設定ミスや侵害の兆候をレビューする事も含まれていると考えるべきかと思います。

※未来日付（2025年3月31日まではベストプラクティス）の規定です

■PCI DSSv4.0を読むシリーズ

　PCI DSSv4.0を読む① v3.0リリースの頃を振り返る

　PCI DSSv4.0を読む② v4.0の印象とタイムスケジュール

　PCI DSSv4.0を読む③ カスタマイズドアプローチ

　PCI DSSv4.0を読む④ 要件1の変更概要

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

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

　PCI DSSv4.0を読む⑦ 要件4の変更概要

　PCI DSSv4.0を読む⑧ 要件5の変更概要

　PCI DSSv4.0を読む⑨ 要件6の変更概要

　PCI DSSv4.0を読む➉ 要件7の変更概要