PCI DSSv4.0を読む⑪ 要件8の変更概要

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

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

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

要件8：ユーザの識別とシステムコンポーネントへのアクセスの認証

要件8では主に認証周りが書かれていますが、v3.2.1以前では認証要素や認証クレデンシャルとして色々な用語が使われていた部分が、認証クレデンシャルとして用語統一されています。併せて、用語の意味が分かりにくかった非消費者ユーザが削除され、消費者ユーザも「消費者ユーザ（カード保持者）」に統一されています。

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

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

2つ目の新要件は8.3.6で（v3.2.1では8.2.3）パスワード要件が改訂されました。NISTの推奨に（一部）合わせた形で、パスワード（パスフレーズ）長は、12文字以上が要求されていますが、システムが12文字に対応していない場合は8文字以上でも許容されます。NIST推奨では記号なども含まれる事が推奨されていますが、PCI DSSとしてはより幅広い環境で利用可能な様に（※8文字＋英数でないと問題が発生するカードデータ環境に考慮して）、数字とアルファベットが必須要件となっています。

※NIST SP800-63Bでは8文字～64文字が推奨

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

3つ目の新要件はサービスプロバイダー向けの要件、8.3.10.1です。サービスプロバイダの顧客ユーザに提供するアクセスの定期変更に関する内容なのですが、ここだけ見るのではなく、その前項の8.3.10を先に見る必要があります。

8.3.10では、8.3.10.1が有効になるまで（2025年3月31日まで）の暫定対応が書かれており、顧客ユーザーに対してはパスワード／パスフレーズの定期変更を呼び掛ける（推奨する）事が要求されています。

自組織（被審査組織）向けのパスワードに関しては、8.3.9で従来通り(v3.2.1同様に）90日以内の変更（又は動的分析によるアクセス権のリアルタイム適用）が求められているのに比べて、2025年の未来日付までは同じ事は要求されていません。

これは恐らく”市場の声（関係者からのフィードバック）”を受けての猶予措置になったのではないかと推測します。サービスプロバイダー側、顧客ユーザー側双方に準備期間が必要と判断されたのだろうと思いますが、併せて多要素認証への移行を促している規定と見る事も出来るかも知れません。

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

4つ目の新要件は8.4.2、全てのカードデータ環境（CDE)へのアクセスに多要素認証（MFA）が必須となります。v3.2.1では全ての非コンソールの管理者アクセス（8.3.1）、及びリモートアクセス（8.3.2）に多要素認証が必須でしたが、一部例外はあるものの『全ての』がある為に、この後の8.4.3（リモートアクセス時の多要素認証）と併せて、組織の運用によっては大きな影響が出るかも知れません。

8.4.2＝カードデータ環境（CDE）へのアクセスと、8.4.3＝リモートアクセスの”両方で”多要素認証が必要となるので、例えば外部からリモートアクセスでカードデータ環境にアクセスする際には、2度多要素認証が求められる事になります。

※例外はコンソールからの管理者アクセス、アプリ/システムアカウントによる自動化されたアクセス、及びPOS端末等のユーザアカウント

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

5つ目の新要件は8.5.1、多要素認証（MFA）の実装に関する内容です。以前からPCI SSCのFAQを見ている方であれば違和感はあまり無いと思いますが、一言に多要素認証と言っても、様々な方式があり、実装法によっても多要素認証が回避されてしまう可能性もある為、多要素認証についての（PCI SSCとしての）定義がまとめられています。

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

この中で解釈が間違いやすいと個人的に思う所が2か所あり、１つがGoogle等で実装されている『多段階認証』（同じ認証要素が2回）がPCI SSCでは多要素認証（MFA)としては認められない事、そしてもう1点は、v4.0は思い切ったな、と思える【リプレイ攻撃の影響を受けない】という一文です。

リプレイ攻撃のイメージがつかない方は、”中間者攻撃”と読み替えても良いかと思います。この攻撃の影響を受ける認証要素の代表例は、OTP（ワンタイムパスワード）です。

そうとは明示されていないのでOTPでも回避法があるのかも知れませんが、日本でも多要素認証で多く利用されているSMS-OTP等は、この条件をクリアするのが難しいのではないかと思われます。

多要素認証について、規定のガイダンス部分を見ると多要素認証の補足文書を参照しています。このガイダンスを見ると、SMS（OTP）や音声に関しては、NIST等の（PCI DSSが参照しているベストプラクティス）推奨から外れて可能性が示唆されています。

※この補足文書のリリース後にNIST SP800-63Bが改訂されており、SMS経由の攻撃はソーシャルエンジニアリング（≒リプレイ攻撃）に弱いと書かれている事を考えると、SMS-OTP（OTP）ではこの規定要件を満たせない可能性が高い様に思えます。

6つ目の新要件は8.6.1、システムやアプリケーションアカウントが対話型ログインを使用する場合の制限に関する内容です。こうしたアカウントは元々特権アカウントである事が多く、一般ユーザーと同様に対話型ログインをされた場合に侵害に繋がるリスクを考えての規定となっており、可能であれば対話型ログインを禁止する事、そして対話型ログインを利用する場合はその正当な理由が文書化されており、経営陣が承認している事などが求められています。

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

この規定に引っかかりそうな運用があまり思いつかないのですが、システムやアプリアカウントを使って何かの調査をする、といった際にユーザーに紐づく特権アカウントではなく、システムやアプリケーションアカウント（特権）を使うといったケースがこれに当たるかと思います。

この場合、事前の了承は緊急対応という事で事前に整えられるかと思いますが、普通に管理者がログインした場合に留意すべきなのが、個人への紐づけです。

特権管理ソフトのログなどで対応できる場合は良いかと思いますが、それ以外で実装を考えると面倒に思えます。恐らく個人に紐づく特権アカウントを作ってしまった方が早いとは思いますが、システム数が多いとこの運用は煩雑になりますので、踏み台サーバーを使って最初に個人認証した上でシステム（アプリ）アカウントを利用するといった方法も考えられそうです。

7つ目の新要件は8.6.2、8.6.1でアプリ又はシステムアカウントが対話型ログインする場合に、安易な実装を選んで、パスワードやパスフレーズをソフト等にハードコーディングしてはいけないという要件になります。

Git等からハードコーディングされた認証情報が見つかるケースも年に何回か報じられていますが、注意すべきなのは要件6（開発者系要件）にこれが書かれていない事です。

要件には8.6.2.ｂで『存在しない事を確認する』と書かれていますが、QSA審査でこうした確認を行う事は恐らく”無い”と思います。

※個人的なお勧めは、開発仕様書や、開発時のチェックリストに入れおく事です。

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

最後８つ目の新要件は8.6.3、アプリ及びシステムアカウントのパスワード（パスフレーズ）を悪用されない為に保護する内容です。

パスワード(パスフレーズ）は、十分な複雑性を持たせた（要件8.3.6を満たした）上で、ターゲットリスク分析で定義された頻度で、及び侵害（の恐れ）があった際に変更する事が求められています。

要件7.2.5の所でも書きましたが、アプリケーションやシステムアカウントでは、とても分かりやすいID（アカウント）と、いくつものアプリやシステムで使い回しされたパスワードが利用されている事が多いので、複雑性を満たしていると言っても、アプリケーションおよびシステムアカウントのパスワード（パスフレーズ）が共通である、又は容易に推測が出来る程度の変更しかされていないケースもありますので、可能であれば、パスワード管理ソフト等を使って一意で強固なパスワード運用を検討する事をお勧めします。