ハイパーバイザーの選択

OpenStack におけるハイパーバイザー

Whether OpenStack is deployed within private data centers or as a public cloud service, the underlying virtualization technology provides enterprise-level capabilities in the realms of scalability, resource efficiency, and uptime. While such high-level benefits are generally available across many OpenStack-supported hypervisor technologies, there are significant differences in the security architecture and features for each hypervisor, particularly when considering the security threat vectors which are unique to elastic OpenStack environments. As applications consolidate into single Infrastructure-as-a-Service (IaaS) platforms, instance isolation at the hypervisor level becomes paramount. The requirement for secure isolation holds true across commercial, government, and military communities.

OpenStack のフレームワークの中で、クラウド環境を最適化するために、いくつものハイパーバイザーおよび対応する OpenStack プラグインから選択できます。このガイドの観点では、ハイパーバイザーはセキュリティに必須となる機能セットに関連するため、ハイパーバイザーの選択における考慮事項について注目します。しかしながら、これらの考慮事項は特定のハイパーバイザーの得失について徹底的に調査したことを意味するわけではありません。NIST は Special Publication 800-125, "Guide to Security for Full Virtualization Technologies" でさらなるガイドラインを提供しています。

選択基準

ハイパーバイザーの選択において、セキュリティを保証するために考慮すべき重要な要因がいくつかあります。特に下記の面に注目します。

  • チーム習熟度

  • 製品やプロジェクトの成熟度

  • コモンクライテリア (Common Criteria)

  • 証明書

  • ハードウェア関連

  • ハードウェア対ベアメタル

  • 追加のセキュリティ機能

Additionally, the following security-related criteria are highly encouraged to be evaluated when selecting a hypervisor for OpenStack deployments: * Has the hypervisor undergone Common Criteria certification? If so, to what levels? * Is the underlying cryptography certified by a third-party?

チーム習熟度

多分、ハイパーバイザー選択における一番重要な観点はある特定のハイパーバイザープラットフォームの管理と保守におけるあなたのスタッフのノウハウです。あなたのチームが与えられた製品、その設定、クセに慣れていればいるほど、設定ミスは少なくなります。加えて、あなたのスタッフが与えられたハイパーバイザーについて組織を横断してノウハウを広めていけば、あなたのシステムの可用性は向上し、職務分掌が可能になり、チームメンバーが対応できない場合での問題を軽減します。

製品やプロジェクトの成熟度

ハイパーバイザー製品またはプロジェクトの成熟度もセキュリティ上重要です。製品の成熟度はクラウドを配備してから大きな影響が現れます。

  • ノウハウの入手先

  • 活発な開発者とユーザーのコミュニティ

  • タイムラインとアップデートの入手先

  • インシデントレスポンス

ハイパーバイザーの完成度の最大の指標の１つに、それを取り巻くコミュニティのサイズと活気があります。これはセキュリティに関するので、コミュニティの質はあなたが追加のクラウドオペレーターを必要とする、利用可能なノウハウに影響します。これはまた、ハイパーバイザーがいかに広く開発されているかの印でもあり、同様に、リファレンスアーキテクチャやベストプラクティスの戦闘準備につながるのです。

Further, the quality of community, as it surrounds an open source hypervisor like KVM or Xen, has a direct impact on the timeliness of bug fixes and security updates. When investigating both commercial and open source hypervisors, you must look into their release and support cycles as well as the time delta between the announcement of a bug or security issue and a patch or response. Lastly, the supported capabilities of OpenStack compute vary depending on the hypervisor chosen. See the OpenStack Hypervisor Support Matrix for OpenStack compute feature support by hypervisor.

証明書

ハイパーバイザーを選択する際にもう１つ考慮すべき点は、様々な公式の認証や証明書が利用可能かという事です。あなたの特定の組織の要件ではないかも知れませんが、これらの認証や証明書は、成熟度、商利用可能、特定のハイパーバイザーが目標としてきたテストの徹底さを物語ります。

コモンクライテリア (Common Criteria)

Common Criteria is an internationally standardized software evaluation process, used by governments and commercial companies to validate software technologies perform as advertised. In the government sector, NSTISSP No. 11 mandates that U.S. Government agencies only procure software which has been Common Criteria certified, a policy which has been in place since July 2002.

注釈

OpenStack has not undergone Common Criteria certification, however many of the available hypervisors have.

In addition to validating a technologies capabilities, the Common Criteria process evaluates how technologies are developed.

  • どのようにしてソースコード管理が行われるのか？

  • どのようにしてユーザがビルドシステムへのアクセスを許可されるのか？

  • 技術は配布前に暗号署名されるのか？

The KVM hypervisor has been Common Criteria certified through the U.S. Government and commercial distributions. These have been validated to separate the runtime environment of virtual machines from each other, providing foundational technology to enforce instance isolation. In addition to virtual machine isolation, KVM has been Common Criteria certified to...:

"...provide system-inherent separation mechanisms to the resources of virtual
machines. This separation ensures that large software component used for
virtualizing and simulating devices executing for each virtual machine
cannot interfere with each other. Using the SELinux multi-category
mechanism, the virtualization and simulation software instances are
isolated. The virtual machine management framework configures SELinux
multi-category settings transparently to the administrator."

While many hypervisor vendors, such as Red Hat, Microsoft, and VMware have achieved Common Criteria Certification their underlying certified feature set differs, we recommend evaluating vendor claims to ensure they minimally satisfy the following requirements:

IDと認証

pluggable authentication modules (PAM) を使用した識別と認証はユーザーパスワードに基づいています。使用されるパスワードの質は設定オプションにより強制できます。

監査

The system provides the capability to audit a large number of events, including individual system calls and events generated by trusted processes. Audit data is collected in regular files in ASCII format. The system provides a program for the purpose of searching the audit records. The system administrator can define a rule base to restrict auditing to the events they are interested in. This includes the ability to restrict auditing to specific events, specific users, specific objects or a combination of all of this. Audit records can be transferred to a remote audit daemon.

任意アクセス制御

Discretionary Access Control (DAC) restricts access to file system objects based on ACL that include the standard UNIX permissions for user, groups, and others. Access control mechanisms also protect IPC objects from unauthorized access. The system includes the ext4 file system, which supports POSIX ACLs. This allows defining access rights to files within this type of file system down to the granularity of a single user.

強制アクセス制御

Mandatory Access Control (MAC) restricts access to objects based on labels assigned to subjects and objects. Sensitivity labels are automatically attached to processes and objects. The access control policy enforced using these labels is derived from the Bell-LaPadula model. SELinux categories are attached to virtual machines and its resources. The access control policy enforced using these categories grant virtual machines access to resources if the category of the virtual machine is identical to the category of the accessed resource. The TOE implements non-hierarchical categories to control access to virtual machines.

ロールベースアクセス制御

ロールベースアクセス制御 (RBAC) は、全権を持つシステム管理者の必要性を減らすために、役割を分割できるようにします。

オブジェクト再利用

File system objects, memory, and IPC objects are cleared before they can be reused by a process belonging to a different user.

セキュリティ管理

セキュリティ的に重要なシステムパラメーターの管理が、管理ユーザーにより実行されます。root 権限 (または RBAC 使用時の特定のロール) が必要となる一組のコマンドが、システム管理のために使用されます。セキュリティ関連のパラメーターは特定のファイルに保存されます。これらは、システムのアクセス制御機構により、管理ユーザー以外の権限のないアクセスに対して保護されます。

セキュア通信

システムは SSH を使用する信頼チャネルの定義をサポートします。パスワードによる認証がサポートされます。少しの暗号スイートのみが、評価された設定でそれらのプロトコルのためにサポートされます。

ストレージ暗号化

The system supports encrypted block devices to provide storage confidentiality via dm_crypt.

TSF 保護

While in operation, the kernel software and data are protected by the hardware memory protection mechanisms. The memory and process management components of the kernel ensure a user process cannot access kernel storage or storage belonging to other processes. Non-kernel TSF software and data are protected by DAC and process isolation mechanisms. In the evaluated configuration, the reserved user ID root owns the directories and files that define the TSF configuration. In general, files and directories containing internal TSF data, such as configuration files and batch job queues, are also protected from reading by DAC permissions. The system and the hardware and firmware components are required to be physically protected from unauthorized access. The system kernel mediates all access to the hardware mechanisms themselves, other than program visible CPU instruction functions. In addition, mechanisms for protection against stack overflow attacks are provided.

暗号標準

Several cryptography algorithms are available within OpenStack for identification and authorization, data transfer and protection of data at rest. When selecting a hypervisor, we recommend the following algorithms and implementation standards:

アルゴリズム

鍵の長さ

想定用途

セキュリティ機能

実装標準

AES

128、196、256 ビット

暗号化 / 復号

保護されたデータ転送、保存データの保護

RFC 4253

TDES

168 ビット

暗号化 / 復号

保護されたデータ転送

RFC 4253

RSA

1024、2048、3072 ビット

認証、鍵交換

識別と認証、保護されたデータ転送

U.S. NIST FIPS PUB 186-3

DSA

L=1024、N=160 ビット

認証、鍵交換

識別と認証、保護されたデータ転送

U.S. NIST FIPS PUB 186-3

Serpent

128、196、256 ビット

暗号化 / 復号

保存データの保護

http://www.cl.cam.ac.uk/~rja14/Papers/serpent.pdf

Twofish

128、196、256 ビット

暗号化 / 復号

保存データの保護

https://www.schneier.com/paper-twofish-paper.html

SHA-1

メッセージダイジェスト

保存データの保護、保護されたデータ転送

U.S. NIST FIPS PUB 180-3

SHA-2 (224、256、384、512 ビット)

メッセージダイジェスト

保存データの保護、識別と認証

U.S. NIST FIPS PUB 180-3

FIPS 140-2

In the United States, the National Institute of Science and Technology (NIST) certifies cryptographic algorithms through a process known the Cryptographic Module Validation Program. NIST certifies algorithms for conformance against Federal Information Processing Standard 140-2 (FIPS 140-2), which ensures...:

"... Products validated as conforming to FIPS 140-2 are accepted by the Federal
agencies of both countries [United States and Canada] for the protection of
sensitive information (United States) or Designated Information (Canada).
The goal of the CMVP is to promote the use of validated cryptographic
modules and provide Federal agencies with a security metric to use in
procuring equipment containing validated cryptographic modules."

ハイパーバイザーの基礎技術の評価時、ハイパーバイザーが FIPS 140-2 に認証されているかどうかを考慮します。正式な認証は、指定された暗号アルゴリズムの実装が、アメリカ政府機関のポリシーごとに強制される FIPS 140-2 への適合性だけではなく、モジュール仕様、暗号モジュールのポートとインターフェース、ロール、サービス、認証、有限オートマトン、物理セキュリティ、運用環境、暗号鍵管理、EMI/EMC、自己テスト、設計保証、他の攻撃の緩和に対する適合性をレビューされることを意味します。

ハードウェア関連

When you evaluate a hypervisor platform, consider the supportability of the hardware on which the hypervisor will run. Additionally, consider the additional features available in the hardware and how those features are supported by the hypervisor you chose as part of the OpenStack deployment. To that end, hypervisors each have their own hardware compatibility lists (HCLs). When selecting compatible hardware it is important to know in advance which hardware-based virtualization technologies are important from a security perspective.

記述

技術

説明

I/O MMU

VT-d / AMD-Vi

PCI パススルーの保護に必要です

Intel Trusted Execution Technology

Intel TXT / SEM

動的証明サービスに必要です

PCI-SIG I/O 仮想化

SR-IOV, MR-IOV, ATS

PCI Express デバイスをセキュアに共有するために必要です

ネットワーク仮想化

VT-c

ハイパーバイザーにおけるネットワーク I/O の性能を改善します

Hypervisor versus bare metal

It is important to recognize the difference between using Linux Containers (LXC) or bare metal systems versus using a hypervisor like KVM. Specifically, the focus of this security guide is largely based on having a hypervisor and virtualization platform. However, should your implementation require the use of a baremetal or LXC environment, you must pay attention to the particular differences in regard to deployment of that environment.

Ensure your end users that the node has been properly sanitized of their data prior to re-provisioning. Additionally, prior to reusing a node, you must provide assurances that the hardware has not been tampered or otherwise compromised.

注釈

While OpenStack has a bare metal project, a discussion of the particular security implications of running bare metal is beyond the scope of this book.

Due to the time constraints around a book sprint, the team chose to use KVM as the hypervisor in our example implementations and architectures.

注釈

There is an OpenStack Security Note pertaining to the Use of LXC in Compute.

ハイパーバイザーのメモリ最適化

Many hypervisors use memory optimization techniques to overcommit memory to guest virtual machines. This is a useful feature that allows you to deploy very dense compute clusters. One way to achieve this is through de-duplication or sharing of memory pages. When two virtual machines have identical data in memory, there are advantages to having them reference the same memory.

これは一般的に、Copy-On-Write (COW) 機構により実現されます。これらの機構は、ある仮想マシンが別の仮想マシンの状態に関する何かに影響する可能性がある、サイドチャネル攻撃に脆弱なため、必ずしもすべてのテナントが信頼できず、同じ信頼レベルを共有できないようなマルチテナント環境に適していません。

KVM Kernel Samepage Merging

Linux カーネル 2.6.32 に導入された、Kernel Samepage Merging (KSM) は複数の Linux プロセスの同一メモリページを集約します。KVM ハイパーバイザーにある各ゲスト仮想マシンは、自身のプロセスで動作するので、KSM は仮想マシン間でメモリ使用量を最適化するために使用できます。

XEN transparent page sharing

XenServer 5.6 は、Transparent Page Sharing (TPS) という名前のメモリオーバーコミット機能を持ちます。TPS は4KB 単位でメモリの重複をスキャンします。検出時、Xen Virtual Machine Monitor (VMM) は重複のどちらかを破棄し、2 つ目の参照を記録します。

メモリ最適化に関するセキュリティの課題

Traditionally, memory de-duplication systems are vulnerable to side channel attacks. Both KSM and TPS have demonstrated to be vulnerable to some form of attack. In academic studies, attackers were able to identify software packages and versions running on neighboring virtual machines as well as software downloads and other sensitive information through analyzing memory access times on the attacker VM.

テナントを強く分離する必要があるクラウド環境の場合、つまりパブリッククラウドや特定のプライベートクラウドの場合、導入者は TPS や KSM メモリ最適化を無効化することを検討すべきです。

追加のセキュリティ機能

Another thing to look into when selecting a hypervisor platform is the availability of specific security features. In particular, features. For example, Xen Server's XSM or Xen Security Modules, sVirt, Intel TXT, or AppArmor.

以下の表は一般的なハイパーバイザーにおけるこれらの機能の対応状況を示します。

XSM

sVirt

TXT

AppArmor

cgroups

MAC ポリシー

KVM

X

X

X

X

X

Xen

X

X

ESXi

X

Hyper-V

注釈

Features in this table might not be applicable to all hypervisors or directly mappable between hypervisors.

参考資料