PCI DSS v4.0 要件準拠のポイントを解説！よくある質問にQSAとコンサルタントが答えます（第1回）
2022年3月31日、クレジットカード業界の新しいセキュリティ基準となる「PCI DSS v4.0」がリリースされました。
PCI DSS v4.0では新たな要件の追加や明確化だけでなく、セキュリティの維持や各事業体に合わせたセキュリティ対策の実現に向けて、リスク分析ベースの運用頻度定義やカスタマイズアプローチの新設など検証手法についても大きく改変されています。
これからPCI DSS v4.0による審査が本格的に始まろうとしており、それに向けて新基準へ対応する準備を進める中、カード関係事業者の皆様にはさまざまな疑問が生じていることかと思います。
本記事では、PCI DCSSの準拠支援コンサルティングを行っていく中でお客様からよくいただく質問をピックアップして、TISのコンサルタントが回答していきます。
※回答内容はTISのQSA（PCI DSS準拠性審査の実施を認定されたセキュリティ評価機関）による現時点での解釈です。
審査員の変更による観点や解釈の違いをどう捉えるか
PCI DSS v4.0に関する質問として多いのが、「審査員によって観点や解釈が異なっているのではないか」です。
具体的には「審査員が変わり、これまで問題が無いとされていた要件が指摘されるようになった」「審査員によって解釈が異なると感じる」「解釈は審査員側で揃えられないものなのだろうか」といった内容のご質問です。
バージョンが新しくなった上に、審査員も変わり、今までとは違った観点で指摘を受ける可能性があるとなると、不安を感じることもあるかもしれません。
しかし、審査員によって見解が異なることは決してネガティブな面だけではありません。
PCI DSSにおいては、要件ごとに想定されるリスクへどのように対策を打っているかが問われ、その問いに対して企業は自身の業務やコストに合わせた対応方法を実施しているかと思います。
審査員ごとに観点や解釈が変わるのは、その審査員の経験や知識、洞察などさまざまな観点からのリスクやリスク対策を捉えたことの現れです。
リスクやリスク対策の捉え方が多角的であればあるほど、セキュリティは強固となります。
つまり、審査員によって指摘の観点が異なっていたり解釈が異なったりすることは、新たな観点を得られたりセキュリティが向上したりなど、ポジティブな面が多いです。
特に、セキュリティのトレンドは日々変化していくので、最新の情報を取り込んでいくという意味でも、観点の変化を受け入れたほうがメリットは多くなります。
実際にPCI DSSを策定しているPCI SSC（※国際カードブランド5社のJCB、Visa、Mastercard、American Express、Discoverからなる団体）も、審査員の交代はセキュリティレベル向上に効果があるとしています。
もちろん審査される側としては審査の観点が変わることは不安要素の一つになってしまうかとは思いますが、上記のようなメリットもあることを十分に理解し、前向きに捉えていただければと思います。
PCI DSS v4.0はリリースされてまだ時間が経っていないため解釈にも幅があります。それを「解釈の変化」と感じることもあるかと思います。
加えて、セキュリティインシデントが多数発生した場合、それを受けて解釈を厳格化してセキュリティレベルをより高めていく、というケースもあります。
PCI SSCとしてもFAQを公表したりQSAへ通知を出したりして解釈の統一化に努めていますが、それでも戸惑ってしまう方が多くいらっしゃるかと思います。
こちらについても、セキュリティレベル向上につながるというポジティブな面に注目し、肯定的に捉えていただければと思います。
まとめ
- 審査の形骸化を防ぎ、多角的な観点で対策を確認できるという捉え方をすれば、監査員の変更はむしろ推奨されること
- セキュリティを向上させてアカウントデータの漏えいを防ぐためには観点は多いほうが良い
- PCI DSS v4.0は過渡期なので、解釈が変わっていく可能性はある
アプリケーション/システムアカウントの対象要件と注意点
PCI DSSではv3.2.1からユーザアカウントを管理対象に定めています。
そして、今回のPCI DSS v4.0では、従来のユーザアカウントに加え、新たにアプリケーション/システムアカウントも管理対象に加わりました。
これを受けて、アプリケーション/システムアカウントの対象要件の注意点に関する質問が弊社にも多く寄せられています。
アプリケーション/システムアカウントとは、使用者が存在しない、すなわち人間以外のアプリケーションやシステムのみの利用を前提とするアカウントです。
デフォルト時に存在するアカウントがそれに当たることも多く、どのアカウントがアプリケーション/システムアカウントに該当するかがシステム的に分かりやすいです。
また対象要件についても、アプリケーション/システムアカウントが対象であると明記されているため、比較的容易に絞れます。
しかし、このアカウントを対話型、つまりIDやパスワードを用いて人間もログインできる形式で利用している場合は、そこをどう管理しているかが問われます。
アプリケーション/システムアカウントを対話型に使用しているときは、PCI DSS v4.0の要件8.6.1から8.6.3に従っての管理が求められます。
具体的には、パスワードの桁数管理や、アカウントの申請・変更・削除の承認記録の用意などです。
というのも、たとえアプリケーション/システムアカウントであっても、対話型で使うということはユーザアカウントと同様に使用者がいると捉えられるからです。（もちろん、対話型でないならば、人間は基本的にログインできず、アプリケーションおよびシステムのみがアカウントを使用するので、このケースには当てはまりません）
また、要件8.6.1にもありますが、PCI DSS v4.0では「アプリケーション/システムアカウントは基本的に対応型ログインはさせない」ということが前提とされています。
そのため、前提から外れている状態、つまり対話型ログインができてしまう状態をどのように管理していくかについて、焦点があてられます。
アプリケーション/システムアカウントを対話的に利用している場合、対話的に利用可能だが通常業務では利用していないケースと、ユーザアカウント的に利用しているケースに分けらます。
アプリケーション/システムアカウントの要件だけに対応していれば良いのか、ユーザアカウントの要件にも対応する必要があるのか、迷われる方も多いかと思います。
原則として、アプリケーション/システムアカウント対象要件に準じた管理を行っていれば問題ありません。
しかし、通常運用では利用していないケースと、ユーザアカウント的に利用しているケースとでは、セキュリティ環境が異なる場合も多いと思います。
例えば、通常運用では利用していないアプリケーション/システムアカウントは、そのパスワードを知っている人は少なく、パスワードを共有で使用している場合もほとんどありません。
しかし、ユーザアカウント的に利用している場合は、ユーザアカウントと同様のセキュリティ環境に置かれていると言えます。
従って、ユーザアカウント的に利用しているのであれば、アプリケーション/システムアカウントの要件だけでなく、ユーザアカウントの要件にも対応しておいたほうが、セキュリティの観点からは有効であると言えます。
利用環境によって求められるセキュリティは変わりますので、以上のように状況を整理し、「このような観点で対応している」と審査内で示せるように見解を揃えておくことが重要です。
まとめ
- 対話型で利用していない場合は、要件7.2.5および7.2.5.1に対応すれば問題ない
- 対話型で利用する場合は、要件7.2.5および要件8.6.1～8.6.3にも対応する必要がある
- 対話型で利用し、かつユーザアカウント的に利用している場合は、要件7.2.5と要件8.6.1～8.6.3に加えユーザアカウント対象要件にも対応することを推奨する
TISには、多数の企業へシステムのPCI DSS準拠支援を行ってきた実績と知見があります。
PCI DSS v4.0の対応について、今回紹介した質問以外にもさまざまな疑問が生じることもあるかもしれません。
そのような場合には、ぜひ、私たちコンサルタントにご相談ください。