【コラム】PCI DSS V3.2の主な変更点について、多要素認証についての要求である要件8.3及び要件8.3.1を考察
V3.1までは、要件8.3として、外部ネットワークからのリモートアクセス時には「ニ要素認証」を要求していた。Ver3.2では、まずはこれを2つ以上の認証要素を必要とする「多要素認証」と定義した。2つ以上であれば3つでも4つでもよい。また多要素認証を要求する対象を発展的要求として拡張し、コンソール以外の内部ネットワークからの管理アクセスに対しても求められるようになった。
ただし、この変更は既にPCI DSSに準拠済みの企業にとって負担が重いため2018年1月31日までは、ベストプラクティスとなり、その後は正式な要件となる。なお、要件8.3.1の追加により、Ver3.1での要件8.3は要件8.3.2となった。
8.3: 発展型要件:すべての従業員のコンソールを利用しない管理者アクセスとリモートアクセスには、多要素認証に対応することを8.3のサブの要求事項として拡張した。
8.3.1: 新しい要件:すべての従業員のコンソールを利用しない管理者アクセスには多要素認証に対応すること
※2018年1月31日まではベストプラクティス要件となり、それ以降は要件となる。
8.3.2 新しい要件:すべての従業員のCDEへリモートアクセスには多要素認証を利用すること(旧要件8.3を組み込んだ)
1) PCI DSSにおける多要素認証
PCI DSSでは、多要素認証の手段として以下の3種類を定義している。
-> 記憶情報(Something You Know): パスワード、パスフレーズなどユーザが記憶している情報
-> 所有情報(Something You Have): トークンデバイス、スマートカードなどユーザが所有しているもの
-> 生体情報(Something You Are): 指紋、虹彩、静脈パターンなどユーザ自身の特徴を表すもの
PCI DSSにおける多要素認証とは、上記3種類のうち2つ以上を使用することが条件となる。同じ種類の認証を2つ(例:2つの異なるパスワード)使用しても、多要素認証とは見なさない。
2) 多要素認証が必要とされるタイミングと対象
要件8.3のガイダンスによると、特定のシステムコンポーネントに対して多要素認証する際には、サーバレベルの認証もしくはアプリケーションレベルの認証のいずれかが必要である(両方が必須なわけではない)。また、特定のネットワークへの認証またはシステムコンポーネントへの認証のいずれかの一度でよいとしている。具体的に多要素認証が必要なタイミングは、CDE(カード会員データ環境)と分離するためのセグメンテーションコントロールが導入されているか否かによって定められている。
CDEと他のネットワークがセグメンテーションコントロールされていない場合は、管理者がCDEを含むネットワークヘログインする際、もしくはCDEに設置されたサーバーまたはアプリケーションにログインする場合のいずれかで多要素認証を使用することができる。
セグメンテーションコントロールが導入され、CDEが他のネットワークから分離されている場合は、非CDEネットワークからCDEに接続する際に多要素認証が必要となる。ネットワークレベルもしくはサーバー/アプリケーションレベルのいずれかに実装することができ、両方に実装する必要はないとしている。また、もしネットワークレベルで多要素認証により一度ログインすれば、その後、CDEに設置されるサーバーやアプリケーションに再度多要素認証でログインする必要はない。
なお、多要素認証は、ユーザー(管理者権限を持つ担当者)からのアクセスが対象である。自動機能(ジョブ)実行のためのアプリケーションアカウントやシステムアカウントには適用されないとしている。
3) 認証の独立性
前述の通り、多要素認証の要件として、認証要素として「記憶情報」、「所有情報」、「生体情報」の3種類のうち2つ以上を用いることが要求されている。多要素認証の要件を満たすには、これに加えて、認証機構間の独立性が重要であるとしている。具体的には、1段階目の認証をパスしても自動的に2段階目の認証もパスすることができない、1つの認証が破られても別の認証には影響を与えないといったことが必要である。
例として、デバイス内に証明書をインストールしている場合を考える。証明書をインストールしたデバイスとログインを行うデバイスが同じ場合、デバイスにログインさえできれば、自動的に秘密鍵にアクセスできるため、認証機構間の独立性は不十分である。ただし秘密鍵やトークンを、デバイス内でハードウェアとして独立したセキュリティ機能を提供する「SE(Secure Element)」、デバイスのプロセッサに独立したセキュアな処理環境を用意する「TPM(Trusted Platform Module)」、セキュアで信頼できるアプリケーションの独立した実行環境を提供する「TEE(Trusted Execution Environment)」の配下で使用する場合は、1つのデバイスを所有情報による認証とログインの両方に使用できるとしている。
|