およそ8年半ぶりのメジャーバージョンアップとなるPCI DSS v4.0では、全バージョンのPCI DSS v3.2.1から多くの改訂がなされています。ここでは、認証にかかわる要件8を中心に、影響の大きい変更点とv4.0の移行スケジュールについて解説します。

共有アカウントの管理

一般的な情報システムにおいて、ユーザーごとの個人アカウントの付与を原則としつつも複数のユーザーが１つの共有アカウントを使用せざるを得ないケースは、実際に存在します（例：ルーターやスイッチなどのネットワーク機器の管理に使用するアカウント、認証サーバーの障害時に使用する管理者アカウントなど）。しかし、PCI DSS v3.2.1までは、共有アカウントの利用は禁止されていました。

PCI DSS v4.0では、共有アカウントの利用を原則禁止としつつ、「例外的に共有アカウントを使用する場合の条件」を要件として定めました。共有アカウントの管理に関する要件は、要件8.2.2となります。

要件8.2.2
グループアカウント、共有アカウント、汎用アカウント、またはその他の共有された認証情報は、例外的に必要な場合のみ使用し、以下のように管理される。
• 例外的に必要な場合を除き、アカウントの利用を禁止する。
• 使用は例外的な状況に必要な時間に制限される。
• 使用を正当化するビジネス上の理由が文書化されている。
• 使用は、経営陣によって明示的に承認される。
• アカウントへのアクセスが許可される前に、個々のユーザの身元が確認される。
• 実行されたすべてのアクションが、個々のユーザに起因するものである。

共有アカウント管理についての基本的な考え方は以下の３点となります。

1. 共有アカウントの正当な理由による使用と承認を明示的に文書として残す
2. 必要な時間だけ使用する
3. 共有アカウントを使用して行われる操作を誰が行ったかを明確にする

①についてはアカウント使用についてのルールの整備で対処できそうです。しかし、②と③を確実にするためには、ユーザーに個別に発行されるアカウントに紐付けて共有アカウントへのアクセスを制御できる、特権管理システムの導入が必要となると考えられます。

特権管理システムを利用した共有アカウント管理の例

システム管理者が申請に基づき個別ユーザーに対して何月何日の何時から何時まで、と時間を制限してサーバーの共有アカウントの利用を許可します。ユーザーはそれぞれ、許可された時間に特権管理システムに自分のIDとパスワードで認証を行い、特権管理システムを経由し、共有アカウントを使用してサーバーにログインします。

共有IDとパスワードはユーザーには認識できないようにすることで、ユーザーごとに許可された時間帯のみアクセスさせることが可能になります。特権管理システムのログで該当する時間帯に共有アカウントの使用を許可した個別ユーザーを特定することで、共有アカウントを使用して行われたアクションと個々のユーザーを紐づけることができます。またログイン後に自動的にサーバーのパスワードを変更することも可能になります。

図1：特権管理システムによる共有アカウントの管理

この要件のもとになっているのは、例外的とはいえ共有アカウントを使わざるを得ない状況が実際にあるため、安全に使用できるように管理する、という考え方だといえるでしょう。実際に共有アカウントを運用しているPCI DSS準拠企業にとっては、より現実に即した方向での改訂となります。

サービスアカウントの管理

PCI DSS v3.2.1までは、カード会員データ環境におけるシステムコンポーネントにアクセスするユーザーが使用するユーザーアカウント（ユーザーに紐づくログイン可能なアカウント）のみが管理対象となっていました。PCI DSS v4.0では、それに加えてシステムやアプリケーションが使用する「サービスアカウント」も管理対象となります。新たに追加された要件7と8に新設された要件では、サービスアカウントについてもユーザーアカウントと同様に管理することを求められることになりました。

サービスアカウントの種類

サービスアカウントには「対話型ログインが可能なアカウント」と「対話型ログイン不可なアカウント」の２種類があります。

対話型ログインが可能なアカウント

「対話型ログインが可能なアカウント」は、コンソールやアプリケーションから入力することでログインが可能になるようなアカウントです。アプリケーション間連携を目的に、あるアプリケーションが別のアプリケーションに自動ログインするために使用するアプリケーションアカウントや、アプリケーションサーバーがデータベースと連携するために使用するシステムアカウントなどが該当します。

対話型ログイン不可なアカウント

「対話型ログイン不可なアカウント」は、コンソールやリモートでのログインが禁止されているアカウントです。例えばOSがWebサーバーやアプリケーションサーバーを起動する時に使用するようなアカウントなど、ログイン可能にする必要がないものが該当します。

図2は、アカウントの種別について整理した図です。黒い矢印のユーザーアカウントはPCI DSS v3.2.1から管理対象でした。グレーの矢印の消費者アカウントについては、v4.0においてもPCI DSS要件の対象外となります。

図2：アカウントの種別

サービスアカウントに求められる管理

対話型ログインの可否に関わらず、サービスアカウントには以下の要件が求められます。

1. アカウントのアクセス権の定期的な見直し（要件7.2.5.1）
   ユーザーアカウントは半年に１回のアクセス権の見直しが求められていますが、サービスアカウントについては、個々のアカウントごとにリスクに応じた頻度での見直しが求められます。そのため、ターゲットリスク分析（要件12.3.1）によって頻度を決め、全てのサービスアカウントについて見直しをする必要があります。
2. 認証情報の送信・保存時の暗号化（要件8.3.2）
   ユーザーアカウントと同様に、サービスアカウントのパスワードや生体認証などの認証情報の保存・伝送時には暗号化することが求められます。
3. パスワード／パスフレーズのリスク分析に応じた頻度での見直し（要件8.6.3）
   要件8.6.xは新規に追加されたサービスアカウントの管理に関する要件です。サービスアカウントのパスワードもリスク分析に応じた頻度で定期的な見直しを要求されるようになりました。おそらくPCI DSS v4.0に移行する企業の多くに影響する要件だと思われます。パスワードの複雑性や長さなどを元にリスク分析することにより、長期間の変更サイクルも設定が可能であると考えられます。なお、特権管理システムのパスワードの自動変更機能を利用し、自動化させることも可能です。
   
   また、対話型ログイン可能なサービスアカウントには追加で以下が求められます。
   
   
4. 例外的に対話型ログインのアカウントをユーザーが使用する場合の管理（要件8.6.1）
   障害対応など、やむを得ず対話型ログインのサービスアカウントをユーザーが使用する場合、共有アカウントで求められる要件（8.2.2）と同様に「使用と承認を明示的に文書として残す」「必要な時だけ使用する」「操作を行う場合、誰が行なったかを明確にする」ということが求められます。
5. パスワード、パスフレーズのコード、設定ファイルなどへのハードコーディングの禁止（要件8.6.2）
   サービスアカウントのパスワードをプログラムのソースコードにハードコードすることや設定ファイルに平文のまま記述することは禁止されます。アプリケーションによるログインやAPI連携のために、ソースコードや設定ファイルの中にパスワードを平文のまま書き込んでいる場合、システムの改修が必要となります。これらのパスワードはデータベーステーブルに格納して暗号化する、またはシークレット管理などのソリューションやサービスの導入が一般的に考えられます。特権管理システムにサービスアカウントのパスワードなどの認証情報を格納し、APIで呼び出すことも可能です。

サービスアカウントの管理についての要件を満たすためには、まずは管理対象となるサービスアカウントを対話式ログインの可否、パスワードの暗号化状況、パスワードの複雑性などの観点で漏れなく洗い出す必要があります。

多要素認証の強化

PCI DSS v4.0では、v3.2.1に比べて多要素認証が要求される範囲が広がりました。また、多要素認証の実装について定めた要件が追加されました。

多要素認証が求められる範囲

PCI DSS v3.2.1では、カード会員データ環境（CDE）に対する全てのリモートアクセスと、非コンソールの管理者アクセスに対して多要素認証を求めていました。PCI DSS v4.0では、加えてCDEに対する全てのアクセスに対して多要素認証が求められます。

表：多要素認証を求める要件（要件8.4）

8.4.1	全ての非コンソール管理者アクセスに多要素認証（MFA）を要求
8.4.2	カード会員データ環境（CDE）への全てのアクセスにMFAを要求
8.4.3	CDEにアクセスまたは影響を与える可能性のある全てのリモートネットワークアクセスに対して多要素認証を要求

また、リモートアクセスでCDEに接続する場合、リモート接続時の多要素認証（要件8.4.3）と、CDEへの接続時の多要素認証（要件8.4.2）は、それぞれ行う必要があることが要件8.4.2 の「適用上の注記」に以下のとおり明記されました。

要件8.4.2 の「適用上の注記」

ある個人が最初にリモートアクセスによって事業体のネットワークに接続し、その後ネットワーク内からカード会員データ環境（CDE）への接続を開始した場合、この要件に従って、その個人は2回MFAを使用して認証します。1回目は事業体のネットワークにリモートアクセスで接続するとき、そして2回目は事業体のネットワークからカード会員データ環境（CDE）に非コンソール管理アクセスで接続するときです。

具体的な例で説明します。図4は、カード情報を保存するシステムがデータセンターに構築されており、オフィスと専用線で接続されている環境の例です。社内ユーザーは専用線を通じてカード会員データにアクセスするために、Webサーバーを通じてDBサーバーに保存されているカード情報を参照します。緑のエリアがPCI DSS対象範囲、赤い点線で囲まれたエリアがカード会員データ環境（CDE）です。

図3：多要素認証が必要なアクセスの例

例えば、夜間にシステム管理者が自宅からリモートアクセスでデータセンターに接続し、CDE内のWebサーバーに接続してメンテナンスするケースを考えます。まずシステム管理者は自宅にあるPCからインターネット経由でVPNに接続します（①）。この時に１回目の多要素認証が必要になります。

VPNで接続を確立した後、CDEに接続する際（②）も、多要素認証が必要となります。つまり、多要素認証を２回実施する必要があります。ただし、CDE内のWebサーバーやカード情報保存DBそれぞれのサーバーに対して多要素認証を導入する必要はありません。
例えば、特権管理システムに接続する際に多要素認証で接続し、特権管理システムを経由しないとCDE内のサーバーに接続できないという機構を設けることにより、効率的にPCI DSSの多要素認証要件を満たすことが可能であると考えます。

リモートアクセスではない非コンソールの管理者アクセス（③）については、PCI DSS v3.2.1でも多要素認証が求められており、PCI DSS v4.0でも同様です。

v4.0では加えて、一般ユーザーからのCDEへのアクセス（④）についても多要素認証が求められるようになりました。これらのアクセスも全て特権管理システムを経由し、多要素認証を必須とすることにより要件を満たすことができます。

なお、管理者のコンソールアクセス（⑤）については、PCI DSS v3.2.1には要件8.4.1と同内容の要件があったため、多要素認証は不要としていました。しかし、v4.0では「CDEへの全てのアクセスに多要素認証が必要」という要件8.4.2が同時に存在しており、QSAによっては管理者のコンソールアクセスも多要素認証が必要と解釈するケースもあります。どちらの解釈になるかは、実際に審査するQSAに確認して下さい。

悪用されない多要素認証の実装

PCI DSS v4.0では、多要素認証をどのように実装するかについての要件が追加されました。

8.5.1 多要素認証システムは、以下のように実装される。

• 多要素認証システムはリプレイ攻撃の影響を受けない
• 多要素認証システムは、期間を限定して、特別に文書化し、例外的に管理者によって許可されない限り、管理者ユーザを含むいかなるユーザであってもバイパスすることはできない
• 少なくとも異なる 2 種類の認証要素が使用されている
• アクセスが許可される前に、すべての認証要素に成功することが要求される

リプレイ攻撃とは、暗号化された認証情報をネットワーク上でキャプチャした攻撃者が、暗号化されたままの情報を利用し、認証システムに不正アクセスする攻撃手法です。

PCI DSSで要求される多要素認証システムがリプレイ攻撃の影響を受けないためには、ワンタイムパスワードを使用する、あるいはパスワードの動的なハッシュ化を行うなどの対策が必要となります。
また、原則として、多要素認証は管理者であってもバイパスできないように構成し、障害対応など例外的に多要素認証をバイパスする場合は、文書化の上、承認を受けた上で使用しなければなりません。

特権管理システムは、多要素認証のバイパスについてもワークフローで承認の上で許可を発行することが可能です。

PCI DSS v4.0対応の期限

PCI DSS v3.2.1の使用期限は2024年3月末となっております。それまでは、v3.2.1とv4.0のどちらでも準拠が可能です。それ以後はPCI DSS v3.2.1は無効となるため、PCI DSS準拠を維持するためには、2024年3月末までにPCI DSS v4.0の要件を満たせるよう準備を進める必要があります。

ただし、準拠する事業体の負担が重い要件や、移行に時間がかかる要件については、「ベストプラクティス」として、対応が1年猶予されます。例えば本コラムで紹介した要件8.6.x や要件8.4.2、要件8.5.1などはベストプラクティスと区分されているので、2025年3月末までに対応すればよいことになります。

図4：PCI DSS v4.0への移行スケジュール

とはいえ、対応にどの程度期間と工数がかかるのか、現状とのギャップの洗い出し、システム改修計画策定、予算確保と考えていくと、対応期限まで時間はそれほど残されていません。要件7、8については、特権管理システムの活用によって導入や運用の工数が大幅に削減される可能性がありますので、情報収集や導入検討も含め早急に準備に着手する必要があります。