PCI DSS Ver3.2の変更点（２）要件8.3　管理者アクセスに対する多要素認証の要求

前の記事：PCI DSS V3.2における変更点解説（１） 要件10.8セキュリティ制御システムの監視と障害への対応
次の記事：PCI DSS V3.2における変更点解説（3） 要件12.11/12.11.1　サービスプロバイダに対する四半期レビューの要求

PCI DSS Ver3.2の主な変更点について、今回は多要素認証についての要求である要件8.3および要件8.3.1をとりあげる。

Ver3.1までは、要件8.3として、外部ネットワークからのリモートアクセス時には「ニ要素認証」を要求していた。Ver3.2では、まずはこれを2つ以上の認証要素を必要とする「多要素認証」と定義した。2つ以上であれば3つでも4つでもよい。また多要素認証を要求する対象を発展的要件として拡張し、コンソール以外の内部ネットワークからの管理アクセスに対しても求められるようになった。

ただし、この変更は既にPCI DSSに準拠済みの企業にとって負担が重いため2018年1月31日までは、ベストプラクティスとなり、その後は正式な要件となる。なお、要件8.3.1の追加により、Ver3.1での要件8.3は要件8.3.2となった。

PCI DSSにおける多要素認証

PCI DSSでは、多要素認証の手段として以下の3種類を定義している。
PCI DSSにおける多要素認証とは、上記3種類のうち2つ以上を使用することが条件となる。同じ種類の認証を2つ（例：2つの異なるパスワード）使用しても、多要素認証とは見なさない。

多要素認証の必要とされるタイミングと対象

要件8.3のガイダンスによると、特定のシステムコンポーネントに対して多要素認証する際には、サーバーレベルの認証もしくはアプリケーションレベルの認証のいずれかが必要である（両方が必須なわけではない）。また、特定のネットワークへの認証またはシステムコンポーネントへの認証のいずれかの一度でよいとしている。具体的に多要素認証が必要なタイミングは、CDE（カード会員データ環境）と分離するためのセグメンテーションコントロールが導入されているか否かによって定められている。

CDEと他のネットワークがセグメンテーションコントロールされていない場合は、管理者がCDEを含むネットワークヘログインする際、もしくはCDEに設置されたサーバーまたはアプリケーションにログインする場合のいずれかで多要素認証を使用することができる。

セグメンテーションコントロールが導入され、CDEが他のネットワークから分離されている場合は、非CDEネットワークからCDEに接続する際に多要素認証が必要となる。ネットワークレベルもしくはサーバー／アプリケーションレベルのいずれかに実装することができ、両方に実装する必要はないとしている。また、もしネットワークレベルで多要素認証により一度ログインすれば、その後、CDEに設置されるサーバーやアプリケーションに再度多要素認証でログインする必要はない。

なお、多要素認証は、ユーザー（管理者権限を持つ担当者）からのアクセスが対象である。自動機能（ジョブ）実行のためのアプリケーションアカウントやシステムアカウントには適用されないとしている。

関連記事：多要素認証とは？メリット・デメリットや具体例を詳しく解説

認証の独立性

前述の通り多要素認証については要件8.3に記述されているが、より詳細な説明として2017年2月に、Information Supplement ”Multi-factor Authentication” （多要素認証に関する参考文献）が公開されている。こちらの文献から、PCI DSSの多要素認証の理解に必要な部分を抜粋して紹介する。

前述の通り、多要素認証の要件として、認証要素として「記憶情報」、「所有情報」、「生体情報」の3種類のうち2つ以上を用いることが要求されている。多要素認証の要件を満たすには、これに加えて、認証機構間の独立性が重要であるとしている。具体的には、1段階目の認証をパスしても自動的に2段階目の認証もパスすることができない、1つの認証が破られても別の認証には影響を与えないといったことが必要である。

例として、デバイス内に証明書をインストールしている場合を考える。証明書をインストールしたデバイスとログインを行うデバイスが同じ場合、デバイスにログインさえできれば、自動的に秘密鍵にアクセスできるため、認証機構間の独立性は不十分である。ただし秘密鍵やトークンを、デバイス内でハードウェアとして独立したセキュリティ機能を提供する「SE（Secure Element）」、デバイスのプロセッサに独立したセキュアな処理環境を用意する「TPM（Trusted Platform Module）」、セキュアで信頼できるアプリケーションの独立した実行環境を提供する「TEE（Trusted Execution Environment）」の配下で使用する場合は、1つのデバイスを所有情報による認証とログインの両方に使用できるとしている。

SMS（ショートメッセージサービス）を用いたOTP送信は今後非推奨になる可能性

また、多要素認証として多く利用されているものの一つとして、携帯電話やスマートフォンを利用した帯域外認証（Out of band :OOB）がある。具体的にはスマートフォンなどのSMSや通話を利用してワンタイムパスワードを送信する方法である。

Information Supplement ”Multi-factor Authentication” は、SMSなどを受信するデバイスの独立性についても言及している。OTPを受信したデバイスにそのOTPを入力して認証（例：メールでOTPを受信して、WebブラウザでそのOTPを入力する）する場合は、二要素認証としての有効性はなくなるとしている。要はスマートフォン自体に不正アクセスされてしまうことにより二つの認証要素がいずれも乗っ取られてしまうというリスクを想定してのことであろう。
一方で、SMSや通話を多要素認証に使用する場合、それを受信できる携帯電話やスマートフォンを所持していることそのものが認証プロセスに求められる「所有情報」の正当性を保証しているとみなされてきた。しかし実際にはSMSは、携帯電話だけでなくPCなど他のデバイスでも受信できることが広く知られ始めている。また、SIMカードが抜きとられて不正なデバイスに装着された場合、SMSだけでなく音声通話も別のデバイスで受けることができてしまう。

そのため、NIST（米国立標準技術研究所）が2016年7月に発表した”Digital Authentication Guideline”の草案では、「SMSまたは音声を使用した帯域外認証を推奨しない」としている。PCI DSSはNISTなど業界標準とも整合させる必要があるので、将来のリリースではSMSまたは音声を使用した帯域外認証は推奨されなくなるか、削除される可能性があるため注意が必要である。

多要素認証と多段階認証の違い

Information Supplement ”Multi-factor Authentication” によると、PCI DSSにおける多要素認証では、すべての認証要素を同時に検証した上で認証する必要があるとしている。すべての要素によるログインの成否が提示されるまでは、個別の認証要素の成功、もしくは失敗の事前知識が個人に提供されてはならない。具体的には、個別のパスワードの認証に失敗したときは再度やり直し、成功した時に、続けて指紋認証の要求を提示するようなシステムは「多要素」ではなく「多段階」認証と区分されるという。
＜多要素認証と多段階認証＞

 

一般的な4つの認証シナリオに対する考察

Information Supplement ”Multi-factor Authentication” では、一般的な認証のシナリオを4つ挙げ、多要素認証における注意事項を説明している。なお、ここで「パスワード」と書いているのは、「記憶情報」による認証を指している。
＜シナリオ１＞

１．パスワードAを使用して、ソフトウェアトークンがインストールされているコンピューターなどのデバイスにログイン
２．ソフトウェアトークンが生成したOTP（ワンタイムパスワード）と、パスワードBを使用してCDEネットワークにアクセス

この方式では、CDEネットワークにアクセスするための認証は、

記憶情報による認証：パスワードB
所有情報による認証：ソフトウェアトークン

となるとしているため、PCI DSSの多要素認証の要件を満たしている。ただし認証要素の独立性を担保するためには、ソフトウェアトークンが他のユーザーやデバイスにコピーできないことを確実にしなければならない。また、コンピューターなどのデバイスに対しては、物理的なセキュリティによって、正しい所有者が持つようコントロールされなくてはいけない。正規の担当者以外によるソフトウェアトークンへのアクセスが制限されない場合、単にパスワードAとパスワードBという「記憶情報による2段階認証」となってしまい、多要素認証の要件を満たさなくなるとしている。

＜シナリオ２＞

１．パスワードA（もしくは生体認証）を使用して、ソフトウェアトークンをインストールしたデバイスにログインする。
２．パスワードAはデバイス上のソフトウェアトークンにアクセスし、OTPを生成する。
３．同じデバイスでブラウザを開き、ブラウザもしくはパスワードマネージャー等に保存されているパスワードBとOTPを一緒に使用してCDEネットワークにアクセスする。

このシナリオ2では、最初の1．で使用する認証要素が判明すれば、そのままCDEネットワークへのログインに必要な2つの認証情報にアクセスできてしまう。すなわち、認証機構間の独立性が担保されていないとみなされる。

＜シナリオ３＞

１．パスワードAを使用してコンピューターにログインする。
２．所有するモバイルデバイスでOTPを生成する。
３．取得したOTPとパスワードAを使用してCDEにログインする。

このシナリオでは、シナリオ1と同様にCDEネットワークへのログインは「記憶情報」と「所有情報」の2要素による認証となる。OTPを取得するためのトークンがスマートフォン上にありコンピューターへのログイン認証とは独立しているとみなせるためである。そのため、CDEネットワークにアクセスするためのパスワードはコンピューターと同じもの（パスワードA）を使用しても多要素認証とみなすことができる。

ただし、そのモバイルデバイス自体でCDEネットワークにアクセスする場合は、認証機構の独立性を担保するため、モバイルデバイスなどに追加のセキュリティ制御が必要になる。

＜シナリオ４＞

１．2要素による認証（例：パスワードと生体認証）でスマートフォンもしくはコンピューターにログインする。
２．何らかの単一の認証（例：コンピューターへの認証とは異なるパスワード、電子証明書、署名付きチャレンジアンドレスポンスなど）でCDEネットワークにアクセスする。

このシナリオでは、CDEネットワークへの接続の都度、ローカルコンピューターへのログイン時に多要素認証が適切に実行されることが保証されれば、コンピューターからCDEネットワークへの接続時の認証は1要素でも問題ないとしている。その条件には、ユーザーが多要素認証を無効にしたり回避したりするといったセキュリティ設定変更をできないようにすることと、認証機構間の独立性が維持されることが含まれている。

さらに、権限のないユーザーによる、このコンピューターからCDEネットワークへ接続を防ぐためのコントロールが必要となる可能性がある。例えば権限のないユーザーが、CDEネットワークに接続するためのアプリケーションを実行できなくするための措置などである。

BYOD環境など、デバイスの管理がユーザーに任される場合、それらのデバイスの認証プロセスがユーザーによって変更されたりバイパスされたりしないよう、前述の「SE」、「TPM」、「TEE」などの堅牢で独立した実行環境により管理する必要があるとしている。

「代替コントロール」使用に大きな影響

繰り返しになるが、要件8.3の拡張により、すべての担当者におけるCDEに対する外部からのリモートアクセスに加えて、コンソール以外の内部ネットワークからの管理アクセスに対しても多要素認証が求められるようになる。この変更の影響を大きく受けるのが、今までPCI DSSの他要件を満たすための「代替コントロール」として多要素認証を使用していた企業だ。

PCI DSSでは、何らかの正当な理由で要件を満たすことができない場合、十分にリスクを評価した上で他のコントロールの実装をもって「代替コントロール」とみなすことができる。そのため、例えば、アプリケーション仕様の制約により管理者パスワードが要件8.2.1（送信と保存中の暗号化）および8.2.3の要件（7文字以上／数字と英文字の両方を含む）を満たしていないなどの場合に、多要素認証を追加で導入することで代替コントロールとすることがしばしば行われている。

代替コントロールについて詳細を定めている付録Bでは、「既存のPCI DSS要件に対して要求されている場合、それらを代替コントロールとみなすことはできない」としている。すなわち、要件8.3で内部ネットワークからの管理者アクセスに対しても多要素認証が要求されるようになったことにより、「パスワード要件を満たさない管理者パスワード」の代替コントロールとして多要素認証を使用することが認められなくなる。したがって、別の代替コントロールを策定し、実装する必要がある。

次の記事：PCI DSS V3.2における変更点解説（3） 要件12.11/12.11.1　サービスプロバイダに対する四半期レビューの要求

PCI DSS Ready Cloudでは、PCI DSS v4.0への効率的な移行支援及び準拠を促進するクラウドサービスを提供しています。
是非一度、ご相談ください。
PCI DSS準拠を促進するクラウドサービスならPCI DSS Ready Cloud

■ PCI DSS の構築、維持・運用にかかるコストと工数を削減する
 
■ AWSでの開発事業者や外部ベンダー/事業者との専用線接続がない場合に最適
 
■ 国内トップクラスのPCI DSS専門のコンサルタント集団によるPCI DSS準拠支援サービス