仮想環境下のPCI DSS対策第1回「仮想技術に関連するリスクの評価」

前回「クラウド時代のPCI DSS」では、PCI SSCによって公開されたガイドライン“Information Supplement: PCI DSS Virtualization Guidelines”の前半を読み解きました。

前半では、まず使用される言葉や概念の定義を行っており、PCI DSSにあまり依存しない形で、仮想環境特有のリスクを考察していると考えられます。本稿では、前回挙げられたリスクに対して、どのような対策を行うべきであるのかを、比較的細かく説明しています。

付録文書、Appendix－Virtualization Considerations for PCI DSSでは、要件毎に何をすべきかが記載されています。PCI DSSへの準拠が求められる環境や、同等のセキュリティレベルが求められる環境において仮想技術の導入を検討する場合は、この付録文書を参考にしてリスク洗い出しと適切な対策の検討を行っていただくことをお勧めします。

前回の連載では、仮想環境に特有のリスクを洗い出し、対応していく際の観点が上げられましたが、本稿は、それを踏まえてどのような対策を行うべきかを説明しています。なお、ここではまだ解説は概念的で、具体的に何をすべきかが記載されているわけではありません。対策を行う際のひとつの観点であると考えるのが良いでしょう。

4.1 一般的な推奨事項

4.1.1 仮想技術に関連するリスクの評価
あらゆるリスク領域を識別し、適切に対策を行うため、注意深くかつ徹底的に、仮想システムに関連するリスクを評価する。仮想環境および仮想システムコンポーネントは、年次のリスク評価プロセスに含め、文書化し、詳細なビジネス上および技術上の評価を伴うべきである。

4.1.2 カード会員データ環境のスコープに対する仮想化の影響度合いの理解
仮想化により環境を少数の物理ハードウェアプラットフォームに集約する場合、仮想システムの設定は複雑になり、カード会員データ環境の境界およびスコープの識別が難しくなる。仮想環境は、PCI DSSの”Scope of Assessment for Compliance with PCI DSS Requirements”ガイダンスをもとに評価する。

ハイパーバイザー上にひとつでもスコープ内のホストがある場合、同ハイパーバイザー上における、たとえば仮想マシン、仮想アプライアンス、ハイパーバイザープラグイン等を含むすべてのシステムコンポーネントを対象とすることを推奨する。

仮想コンポーネントの設計時に、スコープ外と考えられるようなシステムも含めてPCI DSS要件を適用することは、仮想環境のセキュリティベースラインができるだけでなく、複数のセキュリティプロファイルを管理する際の複雑性、リスクを軽減し、スコープ内のコンポーネントの準拠確認におけるオーバーヘッドや労力の低減にもなる。

4.1.3 物理アクセスの制限
単一の物理システムで複数のコンポーネントを稼働させることは、攻撃者が物理アクセスを得た際の影響範囲を広げる結果となる。物理的な対策を評価する際は、単一の物理ホストが提供する全てのVM、ネットワーク、セキュリティデバイスアプリケーション、ハイパーバイザーに同時にアクセスできる、未承認もしくは悪意のある個人による潜在的な侵害を考慮すべきである。また、未使用の物理インタフェースは使用できないようにし、物理的、もしくはコンソールレベルのアクセスは確実に制限と監視を行う。

4.1.4 多層防御の実装
多層防御は様々な観点で必要とされることであり、物理環境における予防・検知・復旧、論理的なセキュリティ対策においてはネットワーク、ホスト、アプリケーション、データレイヤーの保護、認証されていない物理アクセスからの媒体、システム、設備の保護、迅速かつ効率的な潜在的侵害の監視および対応、重要資産の取り扱いや脅威の識別、侵害発生時の対応などに対するトレーニングと教育などを含む。

また、ポリシー、プロセス、手順書が文書化され、あらゆる関係者がそれを理解し、実行していることも重要である。

仮想環境を保護するための多層防御も全く同様で、例えば物理デバイス、ハイパーバイザー、ホストプラットフォーム、ゲストOS、VM、境界、ホスト内部のネットワーク、アプリケーション、データなどのそれぞれのレイヤーの保護や、物理対策、ポリシーと手順書の文書化、関係者の教育、などを含める必要がある。

4.1.5 セキュリティ機能の分離
物理環境でもいえることだが、仮想環境についてはさらに重要な点となる。

VMが提供するセキュリティ機能は、物理環境で要求されるのと同様、プロセス分離のもと実装すべきである。例えば、ファイアウォールのような予防的制御の機能を果たすものは、カード会員データをもつホストと結びつけてはならない。同様に、ネットワーク分離の制御機能自体と、ネットワークセグメンテーションの制御の改変を検知するためのログ集約機能は混在すべきではない。

同一のハイパーバイザー上でこのようなセキュリティ機能を実装するのであれば、別のマシンにインストールされていると考えられうるレベルの分離を施すべきである。

4.1.6 最小権限と責務の分離の徹底
ハイパーバイザーへの管理アクセスに使用するアカウントと認証情報は注意深く管理し、リスクレベルによってはより制限の強いハイパーバイザーアクセスを使用する。二要素認証や管理パスワードの二重／分割管理などの実装も検討し、ハイパーバイザーへのローカルおよびリモートアクセスを含める。個々の仮想コンポーネントについては適切な役割ベースのアクセス制御を実装し、リソースへの不必要なアクセス防止と責務の分離を徹底する必要がある。

一管理者がファイアウォールと監視サーバ両方へのアクセスが可能というような状況にならないよう、管理権限は適切に分離する。ベストプラクティスとしては、特定のVM機能、仮想ネットワーク、ハイパーバイザー、ハードウェア、アプリケーション、データストアに応じて管理アクセスを制限する。

4.1.7 ハイパーバイザー技術の評価
すべてのハイパーバイザーが適切なセキュリティ機能を持っているわけではないので、適切なパッチ管理、および脅威や脆弱性の利用に対応できる機能について、導入前にハイパーバイザーのセキュリティをテストする。

4.1.8 ハイパーバイザーの強化
ハイパーバイザーは単一障害点となるため、以下の追加の対策を推奨する。

・管理機能の利用は、あらかじめ決められたネットワークおよびデバイスからのみに制限する。

・全ての管理機能に対しての多要素認証を要求する

・全ての変更に対する適切な変更管理。通常の変更管理プロセスで要求される内容に追加で管理対策を検討する。

・ハイパーバイザー管理者がハイパーバイザーの監査ログの変更、消去、無効化ができないよう管理機能を分離する。

・ハイパーバイザーのログは、物理的に分離された安全なストレージに、可能な限りリアルタイムで送信する。

・ワークロード間のセグメンテーション、セキュリティコントロール、コミュニケーションチャネルの整合性を脅かすことを示す動作や行動を識別するため、監査ログを監視する。

・ハイパーバイザーの認証情報でアプリケーション、データ、個々の仮想コンポーネントへのアクセスができないよう、管理機能において責務を分離する。

・仮想化ソリューションを実装する前に、当該ソリューションがどのようなセキュリティ管理をサポートし、ハイパーバイザーの侵害のリスクを低減できるか確認する。

（NTTデータ先端技術株式会社　CISSP　川島祐樹）

略歴：NTTデータ・セキュリティ入社後、セキュリティ対策の研究開発から、セキュリティ製品の評価、サービス開発、導入、運用支援を実施。その後、PCIDSS公開当初から訪問調査を実施し、セミナーや書籍、記事の執筆など、PCIDSS普及促進も実施している。