vCloud Director のセキュリティ

VMware Cloud Director 9.5vCloud Director 9.1

最新の技術ドキュメントは、 VMware の Web サイト （https://docs.vmware.com/jp/） でご確認いただけます。 このドキュメ

ントに関するご意見およびご感想は、docfeedback@vmware.com までお送りください。

VMware, Inc.3401 Hillview Ave.Palo Alto, CA 94304www.vmware.com

ヴイエムウェア株式会社105-0013　東京都港区浜松町 1-30-5浜松町スクエア 13Fwww.vmware.com/jp

Copyright © 2010-2020 VMware, Inc. All rights reserved. 著作権および商標情報。

vCloud Director のセキュリティ

VMware, Inc. 2

目次

1 概要 4

2 脅威 5

3 vCloud Director アーキテクチャおよびセキュリティ機能 7仮想マシンのセキュリティと隔離 8

セキュリティおよび vCloud Director の抽象化 8

セキュリティおよび仮想ネットワーク レイヤー 10

4 インフラストラクチャのセキュリティ 12データベースのセキュリティ 14

5 システムのセキュリティ 15ネットワーク セキュリティの要件 15

証明書 17

ファイアウォール 19

ロード バランサと SSL 終端 20

AMQP (RabbitMQ) のセキュリティ保護 21

Cassandra（仮想マシンのメトリック データベース）のセキュリティ保護 22

JMX へのアクセスのセキュリティ保護 23

管理ネットワークの構成 24

監査とログ 25

6 テナントのセキュリティ 28テナント組織のネットワーク セキュリティ 28

リソース割り当てと分離 29

リソースの共有および分離の推奨事項 33

ユーザー アカウントの管理 36

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

ID プロバイダの構成 39

7 チェックリスト 42

VMware, Inc. 3

概要 1VMware vCloud Director は、クラウド コンピューティング サービスを提供するフレキシブルなシステムです。

VMware の中心的な仮想化および管理テクノロジーを活用、拡張し、クラウド環境をサポートします。

本システムは、マルチテナント環境、スケーラビリティ、およびその他のセキュリティ上の懸念事項を考慮して開発

およびテストされているため、展開方法によっては、システム全体のセキュリティに大きな影響が生じることがあり

ます。本書では、システムで想定される脅威のほか、VMware のソフトウェア スタック全体によって提供されるセ

キュリティ機能や、データベースなどのシステムが使用する関連コンポーネントについて説明します。

あらゆるお客様のユース ケースを網羅できるガイドはありません。vCloud Director の展開は、それぞれ独自の IT 環境で行わるため、ネットワーク トポロジ、社内のセキュリティ システムとセキュリティ基準、ユーザーの要求、

ユースケースが異なる可能性があります。本書では、システムの全体的なセキュリティ向上を実現できるよう、一般

的なガイドを提供します。個々のケースに合わせてガイドを利用し、必要に応じて、より具体的な利用シナリオを検

討してください。ただし、本書の個々の推奨事項を採用するかどうかは、最終的に、お客様の独自のデプロイ環境と、

組織でどのような脅威を低減すべきリスクと定めているかによって決まります。

一般に、vCloud Director に対する脅威は、内的脅威と外的脅威の 2 種類に分けることができます。内的脅威は、通

常、マルチテナント環境の問題に関連します。外的脅威は、ホスト クラウド環境のセキュリティを標的にします。た

だし、この区別は厳密なものではありません。たとえば、ホスト環境のセキュリティを脅かす内的脅威もあります。

本書のガイドのほか、http://www.vmware.com/security/advisories.html のセキュリティ アドバイザリを確認して

ください。また、このページのフォームからメール アラートに登録することをお勧めします。このページには、補足

的なセキュリティ ガイダンスと vCloud Director の最新のアドバイザリが掲載されます。

推奨事項の範囲

本書では、vCloud Director に固有のセキュリティ問題の管理に関する推奨事項のみ記載しています。vCloud Director は Linux プラットフォームでホストされる Web アプリケーションであり、この 2 種類の環境にあるセキ

ュリティ脆弱性の影響を受けますが、その脆弱性については、いずれも本書では記載していません。

また、ソフトウェアの安全な展開は、セキュリティ プロセス全体の一部にすぎません。それ以外にも、物理的なセキ

ュリティ、運用手順、パッチ戦略、エスカレーションと対応計画、ディザスタ リカバリなど、多くのトピックがあり

ます。これらの補助的なトピックについては、本書では説明しません。

VMware, Inc. 4

脅威 2vCloud Director に対するセキュリティの脅威は、システムおよびそのテナントの内部に由来する内部の脅威か、シ

ステムの外部に由来する外部の脅威に大まかに分類できます。この後者のカテゴリには、vCloud Director サーバ グループをホストするために作成されるインフラストラクチャに対する脅威と、インストールされている vCloud Director ソフトウェアに対する脅威が含まれます。

マルチテナント環境と内部の脅威

vCloud Director は、テナントに VMware vSphere ® のネットワーク、コンピューティング、ストレージの各リソ

ースへの管理されたアクセスを提供するように設計されています。テナント ユーザーは、vCloud Director にログイ

ンできるほか、一般に、仮想マシンのデプロイや使用、ストレージの使用、アプリケーションの実行、他のユーザー

とのリソースの共有（制限あり）の権限を付与されます。

vCloud Director の主な特徴の 1 つは、非管理者ユーザーはシステム レベルのほとんどのリソース（IP アドレス、

MAC アドレス、CPU のタイプ、ESXi アクセス、物理ストレージの場所などの物理ホスト情報を含む）を直接表示

したりアクセスしたりできないことです。しかし、それでも、クラウド対応アプリケーションが実行されているシス

テム インフラストラクチャに関する情報にユーザーがアクセスしようとする可能性はあります。それらの情報にア

クセスされると、システムのより下位レベルへの攻撃が容易になる可能性があります。

仮想化されたリソースのレベルでも、ユーザーが正当なアクセス権を使用して、資格を付与されていないシステムの

場所（別の組織に属しているリソースなど）に不正にアクセスしようとする可能性があります。具体的には、権限の

エスカレーションによって、管理者用に予約されたアクションに対するアクセス権を取得しようとする可能性があり

ます。また、意図的かどうかにかかわらず、システムの全体的な可用性やパフォーマンスを損なうアクションが試行

される可能性もあります（極端なケースでは他のユーザーの「サービス拒否」に至ります）。

さらに、さまざまな管理者ユーザーが一般に存在します。たとえば、vCloud Director サイトのシステム管理者、テ

ナント組織の管理者、データベースとネットワークの管理者や、ESXi、vCenter、および管理ツールを実行するゲス

ト OS へのアクセス権を持つユーザーなどです。これらのユーザーは、通常のユーザーと比較して高い権限を持ち、

通常は、内部システムに直接ログインできます。ただし、権限が制限されていないわけではありません。これらのユ

ーザーが権限のエスカレーションや有害なアクションを試みる潜在的な脅威もあります。

これから説明するように、これらの脅威に対する vCloud Director のセキュリティは、vCloud Director、vSphere、

および VMware NSX® のアーキテクチャ、設計、実装と、他のセキュリティ システムおよびそれらがデプロイされ

ているインフラストラクチャによってもたらされます。これらのシステムの柔軟性と動的な性質のため、これらすべ

てのコンポーネントについて、該当するセキュリティ構成ガイドのとおり実行することが重要です。

VMware, Inc. 5

セキュアなホスティングと外部の脅威

外部の脅威のソースは、インターネットなど、クラウドの外部から vCloud Director を攻撃するシステムおよびユー

ザーです。攻撃には、API および Web インターフェイス（vCloud Director Web コンソールおよび vCloud Director テナント ポータル）や、vApp 転送サービスおよび仮想マシン リモート コンソールが使用されます。シス

テムへのアクセス権を持っていないリモート ユーザーが、権限を持つユーザーとしてアクセスしようとする可能性が

あります。これらのインターフェイスの認証されたユーザーも、認証されていないユーザーは利用できないシステム

の脆弱性を悪用しようとする可能性があるため、外部の脅威のソースと見なすことができます。

通常、これらのアクターは、システムの実装またはそのデプロイの問題を悪用して、情報を取得したり、サービスに

アクセスしたりしようとします。また、システムの可用性やシステムおよび情報の整合性を損なわせることによって

クラウドの運用を中断させようとする場合もあります。これらの攻撃の中には、その説明からもうかがわれるとおり、

vCloud Director が強制しようとするテナントの境界やハードウェア抽象化レイヤーを侵犯するものもあります。こ

れらの脅威の軽減には、システムのさまざまなレイヤーのデプロイが影響しますが、最も重要となるのは、ファイア

ウォール、ルーター、VPN などの外部向けのインターフェイスです。

vCloud Director のセキュリティ

VMware, Inc. 6

vCloud Director アーキテクチャおよびセキュリティ機能 3vCloud Director は、VMware vSphere ® と VMware NSX® Infrastructure as a Service (IaaS) を提供し、ク

ラウド環境に必要なテナント分離を実現します。

vCloud Director サーバ グループは 1 つ以上の Linux サーバで構成されます。グループの各サーバは vCloud Director セルと呼ばれる一連のサービスを実行します。すべてのセルは、1 つの vCloud Director データベースを共

有し、複数の vCenter Server システム、そのシステムで管理される ESXi ホスト、およびネットワーク サービスを

提供する NSX Manager に接続します。

図 3-1. vCloud Director アーキテクチャ図

vCloud DirectorServer

セル

vCloud Director のインストール

vCenter

VMware vCloud Director

VMware vSphere

ESXi

ESXi

NSX

vCenter データベース

vCloudDirector データベース

図 図 3-1. vCloud Director アーキテクチャ図 は、1 つの vCloud Director サーバ グループ（インストール）を示

しています。このサーバ グループ内に多数の vCloud Director サーバ ホストがあり、それぞれで 1 つのセルが実行

されます。このサーバ グループは vCloud Director データベースと NFS ファイル共有（この図には表示されていま

せん）を共有します。クラウド抽象化は、vCloud Director ソフトウェアと、この図でサーバ グループに接続してい

る vCenter と NSX の両方の機能を使って構築されます。vCloud Director 組織とそのユーザーは、ワークロードの

VMware, Inc. 7

作成と管理に vCenter および NSX を直接使用しません。システム管理者以外のユーザーにとっては、vCenter や

NSX とのすべてのやり取りは、vCloud Director オブジェクトに対する vCloud Director 操作として表されます。

vCloud Director オブジェクトに対するアクセスと操作の権限は、ロールに基づいて割り当てられます。事前定義済

みのロールによって、一般的なタスクへのアクセスのベースラインが設定されます。組織管理者は、権限を詳細に割

り当てたカスタム ロールも作成できます。

以下の各サブセクションでは、仮想コンピューティング レイヤー、クラウド抽象化、および仮想ネットワーク レイ

ヤーのセキュリティについて説明します。

この章には、次のトピックが含まれています。

n 仮想マシンのセキュリティと隔離

n セキュリティおよび vCloud Director の抽象化

n セキュリティおよび仮想ネットワーク レイヤー

仮想マシンのセキュリティと隔離

このドキュメントでセキュリティとネットワークの隔離について検討する際には、ネットワークの分離とトラフィッ

クの隔離の制御が十分でないリスクを評価して、推奨される修正アクションを選択することを目指します。

ネットワークのセグメント化には信頼ゾーンの概念があります。信頼ゾーンは、ネットワーク トラフィックへのアク

セスを制御する予防的なセキュリティ制御です。信頼ゾーンは、その中ではデータが比較的自由に流れるネットワー

ク セグメントとして大まかに定義されます。信頼ゾーンを出入りするデータにはより強力な制限が適用されます。

信頼ゾーンの例を次に示します。

n 境界ネットワーク（非武装地帯 (DMZ) とも呼ばれます）

n Payment-Card Industry (PCI) カード会員データ環境

n サイト固有のゾーン（部門または職務に基づくセグメント化など）

n アプリケーション定義のゾーン（Web アプリケーションの 3 階層など）

セキュリティおよび基盤となる仮想化レイヤー

vCloud Director のセキュリティ（特に、クラウド テナントを内部の脅威から保護するためのセキュリティ）のかな

りの部分は、基盤となる仮想化レイヤーのセキュリティ設計および特定の構成によってもたらされます。これには、

vSphere の設計と構成、vCloud Director の Software-Defined Network によるセキュリティ強化、NSX テクノ

ロジーの活用、および ESXi ホスト自体のセキュリティが含まれます。

セキュリティおよび vCloud Director の抽象化vCloud Director は、vSphere の操作とテナントの日常の運用ニーズを厳密に分離します。

vCloud Director のセキュリティ

VMware, Inc. 8

vCloud Director の抽象化により、サービス プロバイダはテナント組織に（または IT 部門はビジネス部門のチーム

に）vApp の作成、管理、使用を委譲できます。テナント組織の管理者およびユーザーは、vMotion、vSAN などの

vCenter の機能を操作したり管理したりしません。テナントが行うのは、ワークロード (vApp) をリソース プールお

よびストレージ プロファイルにデプロイして、組織が所有する組織仮想データセンター ネットワークに接続するこ

とのみです。組織の管理者およびユーザーが vCenter にログインすることはないため、vCenter の権限の構成ミス

によってユーザーに過剰な権限が付与される可能性はありません。さらに、プロバイダはリソース プールおよびスト

レージ プロファイルの構成を自由に変更できます。組織の側では何も変更する必要はありません。

さらに重要な点は、この抽象化によって組織が互いに分離されることです。たとえ共通のネットワーク、データスト

ア、リソース プールを割り当てられたとしても、互いの vApp を表示したり変更したりすることはできません（同じ

外部ネットワークに接続されている vApp は同じ vSwitch を共有しているため、例外になります）。システムの要件

ではありませんが、各テナント組織に専用のデータストア、ネットワーク、リソース プールを提供すると、組織間の

分離をさらに強化できます。

システム情報へのテナント アクセスの制限vCloud Director は、システム レベルの操作をテナントに表示しないように設計されていますが、悪意のあるテナン

トによって悪用される可能性のある情報を提供するように構成できる機能もあります。

ホストのパフォーマンス データのゲストへの送信の無

効化

vSphere には、VMware Tools がインストールされている Windows オペレーテ

ィング システムの仮想マシン パフォーマンス カウンタが含まれています。デフォ

ルトでは、vSphere はホスト情報をゲスト仮想マシンに公開しません。物理ホスト

に関する情報は、悪意のあるテナントによって悪用される可能性があるため、この

デフォルトの動作が適用されていることを確認する必要があります。詳細について

は、『vSphere のセキュリティ』の「ホストのパフォーマンス データのゲストへの

送信が無効であることを確認する」を参照してください。

仮想マシンのメトリックの

収集の制限

vCloud Director は、仮想マシンのパフォーマンスおよびリソース消費に関する現

在および過去の情報を提供するメトリックを収集できます。これらのメトリックの

一部には、悪意のあるテナントによって悪用される可能性がある物理ホストに関す

る情報が含まれているため、悪意のある使用の対象にならないメトリックのみを収

集するようにメトリック収集サブシステムを構成することを検討してください。詳

細については、『 vCloud Director 管理者ガイド』の「メトリック収集の設定」を参

照してください。

拡張機能に関する注意事項

vCloud Director では、いくつかの機能拡張方法がサポートされています。これらの方法はすべて、拡張機能が、テ

ナント ユーザーに与えられていない権限を取得したり、インストール時に割り当てられた権限をエスカレーションし

たりしないように設計されていますが、拡張機能によって（意図的かどうかにかかわらず）攻撃対象領域が追加され

て、その拡張機能に関する知識を持つ攻撃者によって悪用される可能性があります。サービス プロバイダとテナント

管理者は、拡張機能を提供、レビュー、またはインストールする際に注意してください。また、許可された拡張機能

を慎重に管理し、X-Content-Type-Options: nosniff ヘッダーなどの適切な保護手段を採用することにより、プ

ラグインによって悪意のあるコンテンツがロードされるのを防止できます。

vCloud Director のセキュリティ

VMware, Inc. 9

セキュリティおよび仮想ネットワーク レイヤーvCloud Director ネットワークは、vSphere および NSX の Software-Defined Networking 機能を活用して、テナ

ントに共有ネットワーク リソースへのセキュアなアクセスを提供します。サービス プロバイダの責任は、外部接続

およびそれらの接続をテナントが使用できるようにするために必要なネットワーク インフラストラクチャを提供す

ることと、システム レベルのネットワーク リソースをネットワーク プールに割り当ててテナントが利用できるよう

にすることに限定されます。

この vCloud Director の概要は、プロバイダ レベルおよびテナント レベルのネットワーク要件についてセキュリテ

ィ構成の観点から議論するためのコンテキストを確立することを目的としています。これらの機能の詳細について

は、http://docs.vmware.com で vCloud Director のドキュメントを参照してください。

プロバイダ レベルのネットワーク リソース一般的なケースでは、サービス プロバイダは vCloud Director と外部ネットワーク（インターネット、お客様の企

業ネットワークなど）の間の 1 つ以上の接続の作成を担当します。この種類のネットワークは、基本的にコモディテ

ィ IP ネットワーク接続です。ネットワーク上のパケットが物理レベルで傍受された場合の機密性や、vCloud Director の VLAN ネットワークや VXLAN ネットワークの隔離機能は提供されません。

テナント組織のネットワークを有効にするには、サービス プロバイダが 1 つ以上のネットワーク プールを作成する

必要があります。これにより、ESXi の DVswitches およびポート グループのリソースが、テナント組織が利用で

きる形式で集約されます（外部ネットワークはネットワーク プールのリソースを利用しません）。VXLAN または

VLAN によってバッキングされるネットワーク プールは、vNetwork Distributed Switch で VLAN を使用した隔離

を提供します。vCloud Director の VXLAN ネットワークでは、ESXi カーネルでレイヤー 2 パケットを他のレイヤ

ー 2 パケットにカプセル化する (MAC-in-MAC) ことによって隔離を提供することもできます。パケットは、カプセ

ル化解除されると、この種のプールから作成されたネットワークに接続された正しいゲスト仮想マシンに誘導されま

す。

サービス プロバイダは、テナントが自身のために作成するネットワークとシステム レベルのリソース（ESXi によっ

て提供されるスイッチやポート グループなど）の間にある NSX インフラストラクチャの作成および管理も担当しま

す。これらのリソースからテナント組織は、独自のネットワークを作成できます。

組織仮想データセンター ネットワーク組織仮想データセンター ネットワークでは、組織仮想データセンター内の仮想マシンが相互に通信したり、他のネッ

トワーク（組織仮想データセンター ネットワークと外部ネットワークを含む）にアクセスしたりできます。他のネッ

トワークには、直接アクセスすることも、ファイアウォールと NAT のサービスを提供する Edge Gateway 経由で

アクセスすることもできます。

n 直接組織仮想データセンター ネットワークは、外部ネットワークに直接接続します。システム管理者のみが直接

組織仮想データセンター ネットワークを作成できます。

n 経路指定された組織仮想データセンター ネットワークは、Edge Gateway から外部ネットワークに接続します。

経路指定された組織仮想データセンター ネットワークには、ネットワーク プールを含める親仮想データセンタ

ーも必要です。システム管理者が、Edge Gateway を含む組織仮想データセンターをプロビジョニングして、

ネットワーク プールに関連付けたら、組織管理者またはシステム管理者が、経路指定された組織仮想データセン

ター ネットワークをその仮想データセンターに作成できます。

vCloud Director のセキュリティ

VMware, Inc. 10

n 隔離された組織仮想データセンター ネットワークには、Edge Gateway や外部ネットワークは必要ありません

が、ネットワーク プールに関連付ける親仮想データセンターが必要です。システム管理者が、ネットワーク プールを含む組織仮想データセンターを作成したら、組織管理者またはシステム管理者が、隔離された組織仮想デ

ータセンター ネットワークをその仮想データセンターに作成できます。

表 3-1. 組織 VDC ネットワークのタイプとその要件

組織仮想データセンター ネット

ワークの接続 説明 要件

外部ネットワークへの直接接続 組織仮想データセンターの外部のマシンとネットワークへの直接レ

イヤー 2 接続を提供します。この組織仮想データセンターの外部

のマシンは、組織仮想データセンターの内部のマシンに直接接続で

きます。

クラウドに外部ネットワークを含める必

要があります。

外部ネットワークへの経路指定さ

れた接続

組織仮想データセンターの外部のマシンとネットワークへの Edge Gateway 経由の制御されたアクセスを提供します。システム管理

者および組織管理者は、ゲートウェイにネットワーク アドレス変換

(NAT) およびファイアウォールを設定して、仮想データセンター内

の特定の仮想マシンに対して外部ネットワークからのアクセスを可

能にすることができます。

仮想データセンターに Edge Gateway とネットワーク プールを含める必要があ

ります。

外部ネットワークへの接続なし 組織仮想データセンター内のマシンが接続できる、隔離されたプラ

イベート ネットワークを提供します。このネットワークは、この組

織仮想データセンターの外部にあるマシンへの受信接続および送信

接続は提供しません。

仮想データセンターにネットワーク プー

ルを含める必要があります。

デフォルトでは、組織仮想データセンター ネットワークを使用できるのは、そのネットワークが含まれている組織仮

想データセンター内の仮想マシンのみです。組織仮想データセンター ネットワークを作成するときに、それを共有す

るかどうかを指定できます。共有された組織仮想データセンター ネットワークは、組織内のすべての仮想マシンで使

用できます。

vApp ネットワークすべての vApp に vApp ネットワークが含まれています。vApp ネットワークは論理ネットワークで、vApp 内の仮

想マシンの相互接続の方法と、組織仮想データセンター ネットワークへの接続の方法を制御します。ユーザーは、

vApp ネットワークを作成および更新したり、組織仮想データセンター ネットワークに接続したりできます。直接接

続することも、NAT およびファイアウォール保護を使用することもできます。

vCloud Director のセキュリティ

VMware, Inc. 11

インフラストラクチャのセキュリティ 4本書の大半は、vCloud Director 自体の保護に関係していますが、システム全体のセキュリティを確立するには、

vSphere、NSX、セルの Linux プラットフォーム、および vCloud Director データベースなど、vCloud Director が依存しているインフラストラクチャのセキュリティを確保する必要もあります。

インストール前に、これらの各インフラストラクチャ コンポーネントに最新のセキュリティ パッチを適用すること

が重要です。また、継続的にモニタリングを行い、コンポーネントのパッチ レベルを最新の状態に保つことも欠かせ

ません。

VMware Infrastructure のセキュリティ確保vCloud Director のセキュリティを確保するには、まず vSphere と NSX のセキュリティを確保することが重要で

す。管理者の方は、https://www.vmware.com/security/hardening-guides.html で提供されているチェックリスト

を確認するとともに、次のドキュメントに記載されている詳細なセキュリティ情報を参照してください。

vSphere のセキュリティ vSphere セキュリティ。https://docs.vmware.com/jp/VMware-vSphere/6.0/com.vmware.vsphere.security.doc/GUID-52188148-C579-4F6A-8335-CFBCE0DD2167.html

NSX のセキュリティ VMware NSX for vSphere のセキュリティ確保。https://communities.vmware.com/docs/DOC-27674 および https://communities.vmware.com/docs/DOC-28142。

セル プラットフォームのセキュリティ確保vCloud Director のセルは、Linux ベースのオペレーティング システムを、インストール時に作成される特権のない

ユーザー (vcloud.vcloud) 権限で実行します。サポートされるセル プラットフォームのオペレーティング システ

ムの一覧は、「 vCloud Director リリース ノート」に記載されています。vCloud Director のセキュリティを確保す

るには、セル プラットフォーム（物理的なものか仮想的なものかを問わず）のセキュリティ確保が欠かせません。

不要なネットワーク サービスの無効化、不要なパッケージの削除、リモート root アクセスの制限、強力なパスワー

ド ポリシーの適用など、標準的なセキュリティ強化手順をセル プラットフォームに適用する必要があります。

Kerberos などの中央認証サービスを使用してください。また、モニタリング ツールと侵入検知ツールのインストー

ルを検討してください。

VMware, Inc. 12

追加のアプリケーションをインストールし、セルの OS インスタンスに追加ユーザーをプロビジョニングすることも

可能ですが、そのような設定を行うことは推奨されません。セルの OS へのアクセスを拡大すると、セキュリティが

低下するおそれがあります。

インストール後の機密ファイルの保護

vCloud Director は、インストール時に、セルの Linux ホストのローカル ファイル システム内のファイルに、パス

ワードなどのインストール データを書き込みます。これらのファイル（global.properties および

responses.properties。どちらも $VCLOUD_HOME/etc に格納）には、サーバ グループにサーバを追加すると

きに再利用する必要がある機密情報が含まれています。responses.properties ファイルには、構成スクリプト

を実行するときに管理者から提供された応答が含まれています。このファイルには、vCloud Director データベース

のパスワードおよびシステム キーストアのパスワードの暗号化されたバージョンが含まれています。このファイル

への不正アクセスを許すと、構成スクリプトで指定されたデータベース ユーザーと同じ権限を使用して、攻撃者が

vCloud Director データベースにアクセスするおそれがあります。global.properties ファイルには、暗号化さ

れた認証情報も含まれています。セル管理者以外のユーザーにこの情報へのアクセスを許可すべきではありません。

responses.properties および global.properties ファイルは、作成時に、$VCLOUD_HOME/etc フォルダ

とファイル自体のアクセス制御によって保護されます。ファイルやフォルダの権限を変更しないでください。過剰な

アクセス許可、セキュリティの低下、または過剰なアクセス制限につながり、vCloud Director ソフトウェアが動作

を停止することもあります。アクセス制御が正しく機能するように、vCloud Director サーバへの物理的および論理

的アクセスを厳しく制限し、ログインする必要があるユーザーにのみ、必要最低限のレベルのアクセス権を提供して

ください。アクセス制限には、sudo による root アカウントの使用制限やその他のベスト プラクティスも関係しま

すが、本書ではこれらについては取り上げません。さらに、サーバのバックアップを厳重に保護し、バックアップと

は別に管理されているキーを使用して暗号化する必要があります。

詳細については、『 vCloud Director インストールおよびアップグレード ガイド』の「応答ファイルの保護と再利

用」を参照してください。

管理者の認証情報

セル、vSphere、vCloud Director データベース、外部のファイアウォール、およびその他の機器への管理者権限で

のアクセスで使用する認証情報が、十分なパスワードの複雑さの基準を満たしているか確認してください。可能な場

合は、必ずパスワードの有効期限ポリシーとローテーション ポリシーを検討してください。ただし、データベース、

vSphere、または NSX のパスワードが期限切れになった場合や変更された場合、新しいパスワードで vCloud Director を更新するまで、クラウド インフラストラクチャの一部または全体が機能しなくなります。

「多層防御」の観点から、vCloud Director セル、vCloud Director DB、vSphere サーバ、NSX Manager を含め、

vCloud Director 環境内の各サーバの管理パスワードを、それぞれ別のものにすることが重要です。これは、1 つの

認証情報のセットが（組織に不満を抱いている退職予定の従業員などによって）漏洩した場合に、同じインフラスト

ラクチャのその他のシステムが同時に侵害されるのを防ぐためです。

管理者およびテナントのアカウントと認証情報の管理については、「ユーザー アカウントの管理」を参照してくださ

い。

この章には、次のトピックが含まれています。

n データベースのセキュリティ

vCloud Director のセキュリティ

VMware, Inc. 13

データベースのセキュリティ

基本的にデータベースのセキュリティは、このドキュメントの範囲外です。お客様のクラウド環境で使用されている

他のすべてのシステムと同様に、業界のベスト プラクティスに沿って vCloud Director データベースを適切に保護

する必要があります。

vCloud Director データベースのユーザー アカウントは、『 vCloud Director インストールおよびアップグレード ガイド』の、適切なデータベースの構成に関するガイドに一覧されているシステム権限のみを持つようにします。

vCloud Director データベースのユーザーには、そのサーバ上の別のデータベースに対する権限や、他のシステムの

管理権限を付与しないでください。これは、データベース サーバの最小権限の原則に違反し、ユーザーに必要以上の

権限を与えることになります。

データベースのセキュリティ情報については、次のドキュメントを参照することをお勧めします。

Microsoft SQL Server 『SQL Server Security Best Practices』(http://download.microsoft.com/download/8/f/a/8fabacd7-803e-40fc-adf8-355e7d218f4c/sql_server_2012_security_best_practice_whitepaper_apr2012.docx)。

注： vCloud Director は、Microsoft SQL Server データベースへの SSL 接続を

サポートしていません。

Oracle 『Oracle Database Security Guide』(https://docs.oracle.com/cd/B28359_01/network.111/b28531.pdf)。

注： vCloud Director 9.5 は Oracle データベースをサポートしていません。

vCloud Director 9.1 は Oracle データベースをサポートしますが、Oracle データ

ベースへの HTTPS および SSL 接続はサポートしていません。

PostgreSQL PostgreSQL の接続に SSL を有効にするだけでなく、PostgreSQL のサーバ管理

に関するドキュメントおよび IBM developerWorks の『Total security in a PostgreSQL database』の確認をお勧めします。

vCloud Director のセキュリティ

VMware, Inc. 14

システムのセキュリティ 5サービス プロバイダとシステム管理者は、各 vCloud Director サーバ グループのセキュリティを担当します。

vCloud Director サーバ グループを外部の攻撃者から保護するには、すべての Web ベース サービスに共通の防御手

段（HTTPS エンドポイントを署名付き証明書で保護する、システムとインターネットの間に Web アプリケーショ

ン ファイアウォールを配置するなど）を講じる必要があります。さらに、vCloud Director が依存するサービス

（RabbitMQ AMQP ブローカ、オプションの Apache Cassandra データベースなど）を、これらのシステムのセキ

ュリティが外部から侵害される可能性を最小限に抑えるように構成する必要もあります。

この章には、次のトピックが含まれています。

n ネットワーク セキュリティの要件

n 証明書

n ファイアウォール

n ロード バランサと SSL 終端

n AMQP (RabbitMQ) のセキュリティ保護

n Cassandra（仮想マシンのメトリック データベース）のセキュリティ保護

n JMX へのアクセスのセキュリティ保護

n 管理ネットワークの構成

n 監査とログ

ネットワーク セキュリティの要件vCloud Director を安全に操作するには、安全なネットワーク環境が必要です。このネットワーク環境を、vCloud Director のインストールを開始する前に構成してテストします。

VMware, Inc. 15

すべての vCloud Director サーバーを、セキュリティで保護し監視されているネットワークに接続します。vCloud Director ネットワーク接続には、いくつかの追加要件があります。

n vCloud Director を公開インターネットに直接接続しないでください。vCloud Director ネットワーク接続を、

常時ファイアウォールで保護します。受信接続に対して開くのはポート 443 (HTTPS) のみにする必要があり

ます。必要に応じてポート 22 (SSH) と 80 (HTTP) も受信接続に対して開くことができます。また、cell-

management-tool ではセルのループバック アドレスにアクセスできる必要があります。JMX への要求（ポー

ト 8999）を含む、公開ネットワークから受信した他のすべてのトラフィックは、ファイアウォールで拒否する

必要があります。

表 5-1. vCloud Director ホストからの受信パケットを許容する必要があるポート

ポート プロトコル コメント

111 TCP、UDP 転送サービスで使用される NFS ポートマッパー

920 TCP、UDP 転送サービスで使用される NFS rpc.statd

61611 TCP AMQP

61616 TCP AMQP

n 送信接続に使用されるポートを公開ネットワークに接続しないでください。

表 5-2. vCloud Director ホストからの送信パケットを許容する必要があるポート

ポート プロトコル コメント

25 TCP、UDP SMTP

53 TCP、UDP DNS

111 TCP、UDP 転送サービスで使用される NFS ポートマッパー

123 TCP、UDP NTP

389 TCP、UDP LDAP

443 TCP 標準ポートを使用した vCenter Server、NSX Manager、および ESXi の各接続。これらのサービス用

に異なるポートを選択した場合は、ポート 443 への接続

を無効にし、選択したポートでこれらのサービスで使用で

きるように設定します。

514 UDP オプション。syslog の使用を有効にします。

902 TCP vCenter および ESXi 接続。

903 TCP vCenter および ESXi 接続。

920 TCP、UDP 転送サービスで使用される NFS rpc.statd。

1433 TCP デフォルトの Microsoft SQL Server データベース ポー

ト。

5672 TCP、UDP オプション。タスク拡張用 AMQP メッセージ。

61611 TCP AMQP

61616 TCP AMQP

vCloud Director のセキュリティ

VMware, Inc. 16

n 専用のプライベート ネットワーク上で、vCloud Director サーバと次のサーバ間のトラフィックを経路指定しま

す。

n vCloud Director データベース サーバ

n RabbitMQ

n Cassandra

n 可能な場合は、専用のプライベート ネットワーク上で、vCloud Director サーバ、vSphere、および NSX 間の

トラフィックを経路指定します。

n プロバイダ ネットワークをサポートする仮想スイッチと分散仮想スイッチは、互いに分離する必要があります。

この間で同じレイヤー 2 の物理ネットワーク セグメントを共有することはできません。

n 転送サービス ストレージに NFSv4 を使用します。最も一般的な NFS のバージョンである NFSv3 は、転送時

の暗号化が提供されないため、一部の構成ではデータの転送中に傍受または改ざんを受ける可能性があります。

NFSv3 に固有の脅威については、SANS のホワイト ペーパー NFS Security in Both Trusted and Untrusted Environments に記載されています。vCloud Director の転送サービスの設定とセキュリティ強化についての

詳細は、VMware ナレッジベースの記事 KB2086127 に記載されています。

証明書

vCloud Director は、すべての外部エンドポイントに対するすべてのネットワーク トラフィックに安全性の高い

HTTPS（TLS または SSL）を使用します。HTTPS は、AMQP や LDAP など、多くの内部エンドポイントでもサ

ポートされます。外部エンドポイントには、既知の認証局 (CA) によって署名された証明書を提供することが特に重

要です。内部エンドポイントはそれほど脆弱性が高くないので、多くの場合はエンタープライズ証明書または自己署

名証明書で適切な安全性を確保できます。

すべての証明書には、それがインストールされているサーバの完全修飾ドメイン名 (FQDN) と一致するコモン ネー

ム (CN) フィールドが必要です。通常、これはそのサーバが DNS に登録されており、明確に定義された一意の

FQDN を持つことを意味し、また、IP アドレスではなく FQDN を使用してそのサーバに接続することも意味しま

す。IP アドレスを使用して接続する場合は、ホストの IP アドレスと一致する subjectAltName フィールドを証明書

に含める必要があります。

詳細については、(RFC 6125) と (RFC 5280) を参照してください。また、使用する認証局 (CA) にもお問い合わせ

ください。

パブリック エンドポイント用の証明書エンタープライズ ネットワークまたはインターネットなど他のパブリック ネットワークに公開されるエンドポイン

トは、既知のルート CA によって署名された証明書で保護する必要があります。たとえば、以下のエンドポイントで

す。

n セルの HTTPS アドレスとコンソール プロキシ アドレス。両方のアドレスを設定し、インストール時にその証

明書およびキーストアの詳細を指定する必要があります。

n SSL 終了ロード バランサ。ロード バランサと SSL 終端を参照してください。

vCloud Director のセキュリティ

VMware, Inc. 17

一般に、適切に署名された証明書は、SSL クライアントがルートまでの信頼チェーンを検証できるので、インポート

する必要はありません。低レベルの証明書（エンタープライズ CA または自己署名）はこの方法では検証できず、証

明書を作成したローカル セキュリティ チームによってインポート元が示されます。

プライベート（内部）エンドポイント用の証明書

プライベート ネットワーク上のエンドポイント（パブリック ネットワークに公開されておらず、一般に、データベ

ースや AMQP など vCloud Director コンポーネントによる使用専用に作成されたエンドポイント）には、エンター

プライズ CA によって署名された証明書を使用することも、必要に応じて自己署名証明書を使用することもできま

す。たとえば、以下のエンドポイントです。

n vSphere および NSX への内部接続。

n vCloud Director および RabbitMQ に接続する AMQP エンドポイント。

n PostgreSQL データベース接続（オプション）。

署名付き証明書を使用すると、プライベート ネットワークへのアクセスを入手した悪意のあるアプリケーションが正

規の vCloud Director コンポーネントを偽装する可能性が低くなります。

サポートされているプロトコルと暗号化スイート

vCloud Director は、TLS と SSL を含む複数の HTTPS プロトコルをサポートします。TLS v1.0 は、既知の脆弱

性のため、デフォルトでサポートされていません。インストール後にセル管理ツールを使用して、システムが HTTPS 接続にサポートするプロトコルと暗号化スイートを設定できます。詳細については、『 vCloud Director リリース ノート』を参照してください。

vSphere 証明書の設定vSphere 6.0 以降では、VMware 認証局 (VMCA) が、VMCA で署名された証明書をデフォルトで使用して、各

ESXi ホストと各 vCenter Server サービスをプロビジョニングします。既存の証明書を新しい VMCA 署名付き証

明書に置き換えたり、VMCA を従属 CA にしたり、すべての証明書をカスタム証明書に置き換えたりすることもで

きます。vCenter および ESXi で使用される証明書の作成と置き換えの詳細については、『vSphere セキュリティ』

ガイドの vSphere セキュリティ証明書を参照してください。

vCenter 証明書を検証するための vCloud Director の設定vCenter 証明書を検証するように vCloud Director を設定するには、vCenter 証明書の署名に使用された信頼され

た証明書が含まれる JCEKS 形式の Java キーストアを作成します（個々の vCenter サーバの証明書はこのストア

に含まれません。それらの署名に使用された CA 証明書のみが含まれます）。

以下のコマンドは、PEM でエンコードされた証明書を、/tmp/cacert.pem から myca.ks という名前のキースト

アにインポートします。

$ keytool -import -alias default -keystore myca.ks -file /tmp/cacert.pem -storepass password -

storetype JCEKS

以下のコマンドは、同じキーストアに別の証明書（この例では /tmp/cacert2.pem）を追加します。

$ keytool -importcert-keystore myca.ks -storepass password -file /tmp/cacert2.pem -storetype JCEKS

vCloud Director のセキュリティ

VMware, Inc. 18

キーストアを作成した後、vCloud Director にシステム管理者としてログインします。[管理] タブの [システム設定] セクションで [全般] をクリックし、ページの下部に移動します。

[vCenter Server と vSphere SSO 証明書の検証] と [NSX Manager 証明書の検証] を選択します。[参照] をクリ

ックして Java キーストアを探し、次に [開く] をクリックします。キーストアのパスワードを入力し、[適用] をクリ

ックします。

操作が完了すると、信頼された証明書とその他の情報が vCloud Director データベースにアップロードされます。し

たがって、この操作を 1 回行うだけで、すべてのセルに適用されます。

このオプションを有効にした場合、vCenter と NSX Manager のすべての証明書が検証されるので、すべての

vCenter と NSX Manager には、正しい証明書チェーンとその FQDN に一致する証明書が必要になります。それ

がないと、vCenter と NSX への接続が失敗します。

重要： vCloud Director に vCenter と NSX Manager を追加した後に証明書を変更した場合は、強制的にサーバ

への再接続を行う必要があります。

vCloud Director セル用の証明書とキーの更新各 vCloud Director サーバを使用するには、Java キーストア ファイル内に 2 つの SSL 証明書が必要です。1 つは

HTTP サービス用で、もう 1 つはコンソール プロキシ サービス用です。vCloud Director をインストールするとき

に、これらのキーストアへのパス名を指定する必要があります。署名付き証明書は、最高レベルの信頼を提供します。

セル管理ツールの certificates コマンドにより、新しい証明書で既存の証明書を置き換えるプロセスが自動化され

ます。certificates コマンドを使用して、自己署名証明書を署名付き証明書に、または有効期限が切れる証明書を

新しい証明書に置き換えます。署名付き証明書が格納された JCEKS キーストアを作成する方法については、

『 vCloud Director インストールおよびアップグレード ガイド』の署名付き SSL 証明書の作成とインポートを参照

してください。

エンドポイントのいずれかまたは両方の SSL 証明書を置き換えるには、次の形式でコマンドを使用します。

cell-management-toolcertificatesoptions

詳細については、『 vCloud Director 管理者ガイド』の HTTP およびコンソール プロキシ エンドポイントの証明書

の置き換えを参照してください。

ファイアウォール

vCloud Director のセルは、サービス プロバイダのネットワークの境界外部から通常接続する、テナントとシステム

管理者によってアクセス可能にする必要があります。vCloud Director サービスを外部で利用可能にするための推奨

されるアプローチは、インターネット（またはその他のエンタープライズ ネットワーク）と、各 vCloud Director パブリック エンドポイントの間に、Web アプリケーション ファイアウォールを配置することです。

vCloud Director のセキュリティ

VMware, Inc. 19

ネットワーク ファイアウォールは、物理ネットワークや仮装ネットワークをセグメント化し、特定のポートとプロト

コル上の、事前に定義され限られたトラフィックのみがそれらの間を通ることができるようにするものです。このド

キュメントでは、一般的なファイアウォールの導入の原理を定義したり、ファイアウォールのセットアップを詳しく

解説したりはしません。これらは当ガイドの範囲外です。このガイドでは、vCloud Director 環境のさまざまなコン

ポーネントに関して、ネットワーク ファイアウォールを配置すべき推奨の場所を特定します。

注： ネットワークまたはテナントごとの VPN 内の IP アドレスの制限によって、接続の管理はさらに制限できま

す。このレベルの保護は特定の環境では適切ですが、このドキュメントの範囲外となります。

vCloud Director セルは DMZ 内にあるため、必要なサービスにアクセスするにはネットワークのファイアウォール

を介する必要があります。具体的には、vCloud Director DB、vCenter Server、ESXi ホスト、AMQP や、何らか

のバックアップなどのサービスへのアクセスは、内部ネットワーク（ファイアウォールのパブリック側からはアクセ

ス不可）へのアクセスを制限することが推奨されます。ファイアウォールで開く必要のあるポートのリストについて

は、ネットワーク セキュリティの要件 を参照してください。

悪意のあるトラフィックをブロック

ネットワークの脅威からシステムを保護するためには、さまざまなファイアウォール ルールが推奨されます。

n ルーティングが不可能なアドレスが元になっていると思われるパケットのドロップ（IP スプーフィング）

n 不正な形式の TCP パケットのドロップ

n SYN フラッド攻撃から保護するための、リクエスト（特に SYN リクエスト）のレートの制限（DoS の試行）

n 受信したリクエストが元になっていないファイアウォールからの送信トラフィックを拒否することを検討する

これらのルールやその他のルールは、通常ウェブ アプリケーション ファイアウォールによって適用され、展開する

ネットワーク ファイアウォールによって既定で適用されることもあります。特定の構成手順と既定の機能について

は、ファイアウォールのドキュメントを参照してください。

ロード バランサと SSL 終端vCloud Director 公開エンドポイントは、Web アプリケーション ファイアウォール (WAF) によって保護する必要

があります。ロード バランサと組み合わせて使用する場合は、HTTPS 接続を WAF で終端することで、悪意のある

トラフィックを検査してブロックできるよう WAF を設定します。これによって WAF は、それ自体の証明書を使用

してハンドシェイクを完了し、受け入れ可能なリクエストを X-Forwarded-For ヘッダーによりセルに転送できます。

vCloud Director へのクライアント要求は、HTTPS エンドポイントに対して行う必要があります（セルへの HTTP 接続は、サポートされますが安全ではありません）。リモート クライアントと WAF の間の通信が HTTPS でセキュ

リティ保護される場合でも、WAF からセルへの通信は HTTPS 経由で行う必要があります。

ロード バランサを省略した次の簡単な図に、TLS または SSL 終端を使用する場合の TLS または SSL による 2 つの接続を示します。1 つはユーザー コンピュータと WAF の間、もう 1 つはファイアウォールと vCloud Director セルの間にあります。

vCloud Director のセキュリティ

VMware, Inc. 20

図 5-1. WAF を使用した TLS/SSL 設定

TLS/SSL 終端と証明書TLS または SSL 終端を設定するときは、CA 署名付き証明書を WAF にインストールして vCloud API や Web コンソールなどのクライアント アプリケーションにサーバのアイデンティティを確保するだけでなく、WAF だけが確

認するものであっても、セルでも CA 署名付き証明書を使用することが重要です。自己署名証明書は、WAF が受け

入れた場合でも、展開時に証明書ごとに手動で受け入れられたものに限り有効と見なされます。ただし、これによっ

て各セルを手動で設定（および証明書の更新時には再設定）することが必要になるため、vCloud Director サーバ グループの柔軟性は低下します。

最後に、ロード バランサが WAF から独立したら、同様に CA 署名済み証明書を使用します。ロード バランサのエ

ンドポイントへの証明書チェーン パスを追加する手順は、『 vCloud Director 管理者ガイド』の公開エンドポイント

のカスタマイズに記載されています。

X-Forwarded-For ヘッダーX-Forwarded-For は、広く使用されているヘッダーで、多くのプロキシやファイアウォールでサポートされていま

す。ファイアウォールでは、可能であればこのヘッダーの生成を有効にすることをお勧めします。

セルは記録のためにクライアントの IP アドレスを問い合わせることがありますが、セルの前にファイアウォールが

ある場合、通常は代わりにファイアウォールのアドレスが得られます。ただし、セルが受け取ったリクエスト内に X-Forwarded-For ヘッダーがあると、そのアドレスがクライアントのアドレスとして記録され、ファイアウォールの

アドレスはログ内の proxyAddress という別のフィールドに記録されます。

AMQP (RabbitMQ) のセキュリティ保護AMQP (Advanced Message Queuing Protocol) は、エンタープライズ システムでの柔軟なメッセージングをサ

ポートするメッセージ キューイングのオープン標準です。vCloud Director は RabbitMQ AMQP ブローカを使用

して、拡張サービス、オブジェクト拡張、およびブロック タスク通知に使用されるメッセージ バスを提供します。

RabbitMQ に発行されるメッセージには、機密情報が含まれます。vCloud Director セル間の AMQP トラフィック

を公開することは、システムおよびそのテナントに対するセキュリティ脅威になる可能性があります。AMQP エン

ドポイントは、SSL を使用するように設定する必要があります。AMQP ポートは、システムのファイアウォールで

ブロックする必要があります。AMQP メッセージを使用するサードパーティ製クライアントは、DMZ 内での動作が

許可されている必要があります。vCloud Director メッセージを使用するすべてのコードは、サービス プロバイダの

セキュリティ チームによる監査の対象にする必要があります。

vCloud Director のセキュリティ

VMware, Inc. 21

RabbitMQ の詳細、および RabbitMQ と vCloud Director の連携の詳細については、vCAT-SP ブログのエントリ

(https://blogs.vmware.com/vcat/2015/08/vcloud-director-for-service-providers-vcd-sp-and-rabbitmq-security.html) を参照してください。

SSL による AMQP サービスの保護vCloud Director AMQP サービスで SSL を使用するには、vCloud Director Web コンソールの [拡張性] ページに

ある [AMQP ブローカの設定] セクションで [SSL を使用] を選択し、次のいずれかを指定します。

n SSL 証明書のパス名

n JCEKS トラスト ストアのパス名、ユーザー名、およびパスワード

手順の詳細については、『 vCloud Director 管理者ガイド』の AMQP ブローカの構成を参照してください。

重要： [すべての証明書を承認] オプションを使用できますが、セキュリティに懸念がある場合、これを選択するこ

とはお勧めしません。確認せずにすべての証明書を承認すると、中間者攻撃に対して無防備になります。

システムのファイアウォールにおける AMQP ポートのブロックネットワーク セキュリティの要件で説明されているように、いくつかの AMQP ポートは管理ネットワーク上でアク

セス可能である必要があります。パブリック ネットワークやエンタープライズ ネットワークからアクセス可能な

AMQP エンドポイントが存在することは許されません。

Cassandra（仮想マシンのメトリック データベース）のセキュリティ保護

Cassandra はオープン ソース データベースであり、これを使用してバッキング ストアを提供することで、仮想マ

シンのメトリックのような、時系列データを収集するための拡張性とパフォーマンスに優れたソリューションが可能

になります。Cassandra クラスタに送信されて格納されるデータの一部は、機密性が高く、保護する必要がありま

す。

Cassandra インフラストラクチャは、専用の管理ネットワークに配置することに加え、SSL で保護する必要があり

ます。

Cassandra クライアントとノードの間での暗号化の有効化SSL 証明書をインストールして暗号化を有効にする方法については、Cassandra のクライアントとノードの間での

暗号化に関するページを参照してください。

既知の認証局 (CA) によって署名された証明書を使用することをお勧めします。その場合、vCloud Director で追加

の設定は必要ありません。自己署名証明書を使用する場合は、手動で vCloud Director Director にインポートする必

要があります。『 vCloud Director 管理者ガイド』の外部サービスからの SSL 証明書のインポートで示されているよ

うに、セル管理ツールの import-trusted-certificates コマンドを使用します。

vCloud Director のセキュリティ

VMware, Inc. 22

JMX へのアクセスのセキュリティ保護『 vCloud Director 管理者ガイド』で説明されているとおり、各 vCloud Director セルは、JMX を介していくつか

の MBean を公開することでサーバの運用管理を可能にし、内部統計情報へのアクセスを提供します。このインター

フェイスでは、実行中のシステムに関する機密情報が公開され、その処理が影響を受ける可能性があるため、JMX へのアクセスは厳密に制御することが不可欠です。

JMX 認証JMX インターフェイスは vCloud Director システム管理者だけがアクセスでき、システム管理者は vCloud Director へのアクセスに使用するときと同じ資格情報を使用して JMX に認証される必要があります。この設定は

変更できません。

JMX への接続の制限JMX はシステム管理者のみを対象にした管理インターフェイスなので、vCloud Director の管理ネットワークの外に

公開する理由はありません。システムに管理専用の 3 つ目の IP アドレスが割り当てられている場合は、JMX を直接

その IP アドレスにバインドします。デフォルトでは、vCloud Director JMX コネクタは、システムの設定時に指定

したプライマリ IP アドレスにバインドされます。このデフォルトをオーバーライドするには、次のプロパティ

を /opt/vmware/vcloud-service-director/etc/global.properties に挿入します。

vcloud.cell.ip.management=JMX コネクタがバインドされる管理ネットワークの IP アドレスまたはホスト名

最も安全な設定は、次のように JMX コネクタを localhost アドレスにバインドするものです。

vcloud.cell.ip.management=127.0.0.1

使用されているルーティングとファイアウォールのデバイスに関係なく、この管理ネットワークに割り当てられた IP アドレスと JMX ポート（デフォルトは 8999）は、ネットワーク境界を越えてインターネットまたは組織のユーザ

ーに到達することは許されません。

global.properties でこのように設定することで、JMX はローカルの vCloud Director システムからのみアク

セスできるようになります。ネットワークのルーティング設定に関係なく、JMX ポートへの外部接続は成功しませ

ん。

JMX 通信のセキュリティ保護JMX が localhost アドレス (127.0.0.1) にのみ公開されている場合は、JMX へのすべてのアクセスで SSH をトン

ネル メカニズムとして使用することにより、JMX 通信を保護できます。

管理要件によってこの設定が許可されず、JMX を vCloud Director セルの外部に公開する必要がある場合は、次の

環境変数を設定することによって JMX を HTTPS で保護する必要があります。

# export VCLOUD_JAVA_OPTS="-Dcom.sun.management.jmxremote.ssl=true \

-Djavax.net.keyStore=pathTokeystore \

-Djavax.net.sll.keyStorePassword=password \

-Djavax.net.ssl.keyStoreType=storeType"

その後、vCloud Director を再起動します。

vCloud Director のセキュリティ

VMware, Inc. 23

これで、JMX クライアントは HTTPS で接続することが必要になりますが、CA 証明書へのアクセスが必要です。

たとえば、jconsole の場合は、jconsole を実行するマシンのキーストアに CA 証明書をインポートする必要が

あります。その後、次のコマンド ライン引数を指定して jconsole を起動します。

# jconsole -J-Djavax.net.ssl.trustStoreType=store type \

-J-Djavax.net.ssl.trustStore=pathTokeystore \

-J-Djavax.net.ssl.trustStorePassword=password

自己署名証明書（本番環境の展開では非推奨）を使用すると、JMX クライアントを実行するマシンのキーストアに

すべての自己署名証明書が必要になるため、このプロセスの負荷が増えます。CA 署名証明書の場合は、JMX クライ

アント コンピュータにその CA 証明書だけがあればよいので、サポートが容易です。

管理ネットワークの構成

vCloud Director 管理ネットワークは、クラウド インフラストラクチャを提供するほか、vCloud Director で管理機

能を実行するために使用されるクライアント システムへのアクセスを提供するプライベート ネットワークです。

管理ネットワークに接続するシステムに含まれるのは、vCloud Director データベース サーバ、転送ストレージ用の

NFS サーバ、vCenter サーバ、プロバイダの管理者を認証するための LDAPv3 ディレクトリ（オプション）、組織

のユーザーを認証するためにプロバイダが維持する LDAPv3 ディレクトリ、および NSX マネージャです。このネ

ットワーク上の vCenter サーバには、それぞれ固有の Active Directory サーバへのアクセスも必要です。

仮想インフラストラクチャの管理ネットワークの構成要件

管理ネットワークは、仮想マシンのデータ ネットワークから分離することが重要です。これは、プロバイダとテナン

トが別の組織に属しているクラウド環境ではさらに重要です。プロバイダの管理ネットワークが組織の vApp から

の攻撃に対して無防備な状態は避ける必要があります。同様に、管理ネットワークは、組織管理者にアクセスを許可

する DMZ から分離する必要があります。組織管理者とプロバイダのシステム管理者が同じインターフェイスにア

クセスするとしても、DMZ の概念は、パブリック トラフィックとプライベート トラフィックを分離し、多層防御を

提供するという点で重要です。

物理接続の観点からすると、仮想マシン データ ネットワークは管理ネットワークから分離する必要があります。こ

れは、悪意のある仮想マシンから管理システムを保護するための唯一の方法です。同様に、vCloud Director セルは

物理的に DMZ にあります。物理的な展開の図では、クラウド ポッドに接続する管理ポッド内のサーバは、分離され

た物理ネットワーク経由で接続し、このトラフィックが通過することを特定のファイアウォール ルールによって許可

します。

ネットワーク アーキテクチャの観点からは、vCenter および vCloud Director から vSphere（および他のネットワ

ーク）への接続を仲介する内部ファイアウォールが必要です。これは、単一ホスト上の複数の仮想マシンが DMZ とプライベート ネットワークの両方に接続できるかどうかという問題ではありません。正しくは、その管理ポッド、つ

まりクラウド セル内に仮想マシンがあり、それら自体が両方のネットワークに接続しています。vCloud Director ソフトウェアは VMware 製品のセキュリティ ポリシーに基づき、セキュリティ要件を念頭に設計および実装されてい

ますが、ファイアウォールそのものではないため、DMZ とプライベート管理ネットワークの間のトラフィックを自

ら仲介することはできません。それを行うのはファイアウォールの役目です。

vCloud Director のセキュリティ

VMware, Inc. 24

その他の関連するネットワーク

物理的および論理的な展開の図に示すように、ストレージ ネットワークも物理的に分離されています。これは、

vSphere のベスト プラクティスに基づいており、悪意のある仮想マシンからテナントとプロバイダのストレージを

保護します。バックアップ ネットワークについても同様です。これは、厳密には管理ネットワークからの分岐です。

具体的な要件と設定は、使用中のバックアップ ソフトウェアと設定によって異なります。

vMotion は常に管理ネットワークから分離されたネットワークにあるわけではありませんが、クラウドでは、分離義

務の観点から重要となります。vMotion は一般的に暗号化されないため、管理ネットワークに配置されると、プロバ

イダの管理者や、そのネットワークにアクセスできる他のユーザーは、vMotion トラフィックを「盗聴」できてしま

います。これは、組織のプライバシーに違反します。このため、クラウド ワークロードの vMotion 用に、別の物理

ネットワークを作成する必要があります。

監査とログ

ユーザーのアクティビティを記録したり監視したりできることは、システム セキュリティ全体において重要な部分で

す。多くの組織では、ソフトウェアや関連ハードウェア リソースへのアクセスおよび変更ができるユーザーをルール

で制御しています。重要なアクティビティの監査ログを管理すると、ルール遵守の確認、違反の検出、修正アクティ

ビティの開始を行うことができます。企業によっては、アクセスと権限のルールを継続的に監視および確認すること

を義務付ける外部の法律や規制に従わなければならない場合もあります。

監査ログは、成功したかどうかに関係なく、システムへの不正アクセスや情報の窃取、操作の妨害の試みを検知する

のにも役立ちます。攻撃の試みやその詳細を把握することは、損害を軽減し、それ以降の攻撃を阻止することにつな

がります。

義務付けられているかどうかにかかわらず、定期的にログを調べて不審な活動、異常な活動、不正な活動がないか確

認することは、優れたセキュリティ対策の 1 つです。定期的なログ分析は、システムの構成ミスや障害を特定した

り、SLA の遵守を確認したりするのにも役立ちます。

vCloud Director には次の 2 種類のログがあります。

診断ログ 各セルのログ ディレクトリに保持される診断ログ。このログは、問題の解決に役立

ちますが、重要なシステム操作の監査証跡を保管することを目的とするものではあ

りません。各 vCloud Director セルでは、『 vCloud Director 管理者ガイド』の

vCloud Director ログの表示で説明されている複数の診断ログ ファイルが作成さ

れます。

監査ログ ログインやログアウトなど、重要なアクションを記録する監査ログです。システム

監査ログは、vCloud Director データベースに保管され、Web ユーザー インター

フェイスで監視できます。各組織管理者とシステム管理者は、特別な制御領域を対

象とするログを確認できます。

これらのログおよびその他の vCloud Director ログを保管するには、syslog ユーティリティを使用することをお勧

めします。また、 vRealize Log Insight の使用も検討してください。これは、log4j に基づいていない要求ログの

ような他のログのリモート収集をサポートします。

vCloud Director のセキュリティ

VMware, Inc. 25

vCloud Directorでの Syslog の使用『 vCloud Director インストールおよびアップグレード ガイド』で説明しているように、syslog サーバはインスト

ール時に設定できます。以下の複数の理由により、ログを syslog サーバにエクスポートすることをお勧めします。

n データベース ログの保管期限は 90 日ですが、syslog を介して転送されたログは、必要な間いつまでも保管で

きます。

n すべてのセルの監査ログを、一元化された場所で同時にまとめて確認できます。

n 障害、ディスク容量不足、セキュリティ侵害などによってローカル システムから監査ログが失われるのを防ぎま

す。

n 上記のような問題が発生した場合のフォレンジック調査をサポートします。

n 多くのログ管理システムおよびセキュリティ情報とイベント管理 (SIEM) システムが vCloud Director と連携

する手段になります。これによって以下が可能になります。

n vCloud Director、vSphere、NSX、およびスタックの物理ハードウェアのレイヤー間のイベントとアクテ

ィビティの相関関係。

n 物理、仮想、およびクラウド インフラストラクチャの境界を越えた、クラウド セキュリティ操作とクラウ

ド プロバイダや企業のその他のセキュリティ操作の統合。

n セルが展開されているシステムとは別のリモート システムにログを保管すると、ログの改ざんの防止につながり

ます。セルが侵害されても、監査ログにアクセスしたり、監査ログ情報を書き換えたりできることにはなりませ

ん。

初期インストール時に syslog のログ記録先を設定しなかった場合は、後で各セルに移動し、$VCLOUD_HOME/etc/

global.properties ファイルを編集してからセルを再起動すれば、記録先を設定できます。

vCloud Director ホストから syslog サーバに対して開いたままにする必要のあるポートのリストについては、ネッ

トワーク セキュリティの要件を参照してください。syslog サーバ構成の詳細は、システムごとに異なり、このドキ

ュメントの範囲外です。重要なイベントが必ずログに記録されるように、冗長性を備えた syslog サーバ構成をお勧

めします。

上記では、syslog サーバへの監査ログの転送についてのみ説明しました。セキュリティ運用と IT 運用の組織にと

っては、上記の診断ログを一元的に集約して管理することも有用です。これらのログを収集する方法はいろいろあり

ます。たとえば、ログを一元化された場所に定期的にコピーするジョブをスケジュール設定する方法、

log4j.properties ファイル ($VCLOUD_HOME/etc/log4j.properties) で追加のロガーを中央の Syslog サーバに設定する方法、また、ログ ファイルを監視し、一元化された場所にコピーする vRealize Log Insight などの

ログ収集ユーティリティを使用する方法などです。どの方法を選択するかは、対象の環境で採用するシステムによっ

て異なり、このドキュメントの範囲外です。

重要： TLS 対応の syslog インフラストラクチャを使用することをお勧めします。デフォルト (UDP) の syslog プロトコルでは、転送中の暗号化や伝送制御/確認が提供されません。暗号化を行わないと、ログ データが傍受され

る危険があり（ログ内の情報が別の攻撃に悪用される可能性がある）、伝送制御を行わないと、攻撃者がログ データ

を改ざんする危険があります。詳細については、RFC 5426 のセクション 4 を参照してください。

vCloud Director のセキュリティ

VMware, Inc. 26

診断ログおよびログ ロールオーバJetty 要求ログ ファイル ($VCLOUD_HOME/logs/yyyy_mm_dd.request.log) は、Jetty (HTTP) サーバによっ

てプログラムで制御されますが、サイズの上限が課されていません。このため、ログ ファイルのサイズが無制限に大

きくなるリスクがあります。Jetty の HTTP 要求ごとに 1 つのログ エントリが現在のファイルに追加されます。こ

のため、logrotate や同様の方法を使って、ログのサイズおよび保管する古いログ ファイルの数を制御することを

お勧めします。

それ以外の診断ログ ファイルは合計 400 MB に制限されます。これらのファイルの格納に加え、Jetty 要求ログで使

用されるサイズに対して十分な空きディスク容量があることを確認してください。前述のように一元的なログ管理を

行うと、ログ ファイルの合計が 400 MB に達してファイルのローテーションや削除が発生しても、貴重な診断情報

を失いません。

NTP とログ『 vCloud Director インストールおよびアップグレード ガイド』では、NTP を vCloud Director のすべてのセルの

要件としています。NTP を使用すると、すべてのセルからのログ メッセージのタイムスタンプが同期されるという

副次的効果もあります。確かに、ログ管理ツールと SIEM システムのタイムスタンプが統合されると、複数のツール

やシステムから来るログを揃えるのに役立ちますが、このタイムスタンプはそれぞれのシステムが受け取った時刻で

あり、イベントが実際に記録された時刻ではありません。

その他のログ

vCloud Director に接続したり、使用されたりするその他のシステムが作成する監査ログも、監査プロセスに組み込

む必要があります。たとえば、NSX Manager、vCloud Director データベース、vCenter Server、vSphere ホス

トなどのログがあります。各システムのログ ファイルの詳細と用途はこのドキュメントの範囲外です。それぞれの

製品のドキュメントを参照してください。

vCloud Director のセキュリティ

VMware, Inc. 27

テナントのセキュリティ 6サービス プロバイダ、システム管理者、および組織管理者は、各 vCloud Director テナント組織のセキュリティを

担当します。

vCloud Director テナント組織の外部攻撃からの保護は、外部の攻撃者がテナント リソースにアクセスできないよう

に適切なシステム レベルのセキュリティを提供することが中心になります。サービス プロバイダはそのほかに、テ

ナントが別のテナントを攻撃したり単に干渉したりする可能性についても認識しておく必要があります。テナント間

の潜在的な攻撃ベクトルには、コンピューティング、ストレージ、ネットワークの各リソースのシステム レベルの詳

細のスヌーピングなどが含まれます。干渉は、システム リソースが（互いに不信感を持っている可能性がある）テナ

ント間で共有されている場合に、いずれかのテナントが大量のリソースを利用して、他のテナントのサービス レベル

が維持できなくなると発生します（意図的かどうかは問いません）。この状況は、「ノイジー ネイバー」の問題と呼ば

れます。

「3 章 vCloud Director アーキテクチャおよびセキュリティ機能 」で説明したように、vCloud Director は、多数の

テナント間でシステム リソースを透過的に共有できるように設計されています。一般的には、サービス プロバイダ

は、ダウンタイムの可能性を最小限に抑えながらシステムの効率性を最大化するようにシステム リソースをデプロイ

できます。リソースがテナント組織間で共有される際には常に、さまざまなテナント操作に及ぼす影響や、テナント

間攻撃の可能性について検討してください。

この章には、次のトピックが含まれています。

n テナント組織のネットワーク セキュリティ

n リソース割り当てと分離

n ユーザー アカウントの管理

テナント組織のネットワーク セキュリティvCloud Director 組織は自身のネットワーク セキュリティに責任を負いますが、サービス プロバイダは、ファイア

ウォールによって外部ネットワークを保護する必要があります。

vCloud Director システム内では、VXLAN と VLAN ネットワークにパケット トラフィックの分離が適用され、物

理ネットワークの分離を使用した場合と同じ効果を得ることができます。また、ルーティングとファイアウォールに

関するさまざまなオプションが用意されているため、外部のシステムからのワークロードと組織内のワークロードの

どちらに対するアクセスも細かく調整できます。これらの機能の詳細については、http://docs.vmware.com で

VMware, Inc. 28

vCloud Director のドキュメントを参照してください。ほとんどの場合、システム本体の効果的な保護（Web アプ

リケーション ファイアウォール、SSL 終端ロード バランサ、および適切な署名のあるデジタル証明書を含む）を設

計したサービス プロバイダは、組織仮想データセンター ネットワークのセキュリティを確立、維持するために積極

的に関わる必要はありません。

テナント ワークロードへの外部アクセスインターネットまたは企業ネットワークから組織のワークロード (vApp) へのアクセスを設定するとき、サービス プロバイダは、vCloud Director によって導入および使用される vSphere インフラストラクチャのファイアウォール

要件に注意する必要があります。一部の vApp は、管理のために RDP、SSH などを使用して、またはそのサービス

のエンド ユーザー向けに HTTP などのプロトコルを使用して、インターネットにアクセスできる必要があるか、リ

モートからアクセスされる必要があります。そのため、用途の違いに応じた 2 種類の仮想マシン データ ネットワー

クが推奨されます（リソース割り当てと分離でのアーキテクチャの図を参照）。どちらもネットワークのファイアウォ

ール保護が必要です。

クラウドの外部（インターネットなど）からのアクセスが必要な仮想マシンは、公開ネットワーク、または公開サー

ビス用にポート転送が設定されたプライベートの NAT 経路指定ネットワークに接続されます。これらの組織仮想デ

ータセンター ネットワークが接続される外部ネットワークでは、この DMZ ネットワークへの合意されたトラフィッ

クを許可するファイアウォール保護が必要です。つまり、サービス プロバイダは、外部の DMZ ネットワークへの接

続を開始できるポートとプロトコルを限定する必要があります。同時に、組織の vApp が想定している対象にサービ

スを提供するための十分なトラフィックを確保する必要があります。これには通常、ポート 80/TCP および

443/TCP が含まれますが、それ以外のポートとプロトコルが含まれることもあります。サービス プロバイダは、セ

キュリティの観点からは不要なポートとプロトコルをブロックしなければならないという点を考慮したうえで、この

最適なバランスを決定する必要があります。

一般的に、インターネットとの間で相互にアクセスを必要とする vApp は、必要な種類の受信および送信接続のみを

許可するように設定された、経路指定された組織仮想データセンター ネットワークに接続することをお勧めします。

これにより、組織は NSX ファイアウォールとポート転送ルールを制御できます。このような設定を行っても、組織

仮想データセンター ネットワークで使用される外部ネットワークを分離するネットワーク ファイアウォールが不要

になるわけではありません。これは、パブリックの組織仮想データセンター ネットワークには vCloud Director ファイアウォール保護がまったくないためです。DMZ を作成するためには、個別のファイアウォールが必要です（た

だし、この機能は独立した NSX Edge インスタンスによって実行される可能性があります）。

同様に、仮想マシンにインターネットへのアクセスを許可する仮想マシン データ ネットワークでは、プライベート

の NAT 経路指定された組織仮想データセンター ネットワークが使用されます。前述のとおり、NSX Edge では、

この内部仮想マシン データ ネットワークに NAT とファイアウォールの機能が提供されます。この場合も、この経路

指定されたネットワークの外部ネットワークの部分は DMZ 上に置かれる必要があるため、DMZ は個別のネットワ

ーク ファイアウォールによってインターネット接続自体から分離されます。

リソース割り当てと分離

サービス プロバイダによる vCloud Director の標準的な展開では、複数のテナント組織間での vSphere リソースの

共有を見越しています。これにより、組織は柔軟性を、プロバイダはプロビジョニングしたコンピューティング、ネ

ットワーク、ストレージ リソースの使用率をそれぞれ最大限に高めることができます。論理的および物理的な展開の

例を図に示します。

vCloud Director のセキュリティ

VMware, Inc. 29

このサブセクションの残りの部分では、コンポーネントの概要を説明します。また、その後のサブセクションでは、

リソース プール、データストア、ネットワークなどのコンポーネントの設定に関する具体的な推奨事項を説明しま

す。

共有リソースの展開

図 6-1. 物理的な展開の図 および図 6-2. 論理的な展開の図 は、同じ vCloud Director インストールを 2 つの見方で

示しています。これらの図では、リソース（物理または仮想マシン）のグループを示すために「ポッド」という用語

を使用しています。システム管理用は「管理ポッド」、テナント ワークロード用は「クラウド ポッド」です。

図 6-1. 物理的な展開の図

vCloud Director のセキュリティ

VMware, Inc. 30

図 6-2. 論理的な展開の図 の左側には、ロード バランシングされた DMZ 内に vCloud Director セルが示されていま

す。DMZ には、WAF と、必要に応じてテナントごとの管理 VPN があります。サービス プロバイダは、この VPN を組織ごとに設定することにより、WAF を介して公開されるサービスにアクセスできるユーザーおよび IP アドレス

を細かく制限できます。また、テナントは、オンプレミスのワークロードおよびデータをクラウド内の仮想マシンに

接続するように VPN を設定できます。このような VPN の設定は、本書の範囲外です。

図 6-2. 論理的な展開の図

vCloud Director のセキュリティ

VMware, Inc. 31

セルの背後には、vCenter、NSX、vCloud Director データベースなど、vCloud Director が必要とするプライベー

ト管理要素があります。その接続は、サービスが DMZ 上の他のマシンから、または直接インターネットからアクセ

スできないように、図に示されているファイアウォールによって厳密に制御されています。

図 6-3. 管理ポッドのネットワーク では、管理ポッドのみに注目しています。ここでは、少なくとも 2 つの独立した

物理ネットワークがポッドに接続されている必要があることが示されています。これには、プロバイダ固有の設定が

適用された、ロード バランシングされた DMZ ネットワーク、プライベート管理ネットワーク、およびオプションの

専用ストレージ ネットワークが含まれます。

図 6-3. 管理ポッドのネットワーク

vSphere ホストはさまざまなセキュリティ ドメインにグループ化されており、それぞれに、仮想マシン DMZ デー

タ ネットワークとして公開され、パブリックの組織仮想データセンター ネットワークとして使用される外部ネット

ワークと、プライベートの組織仮想データセンター ネットワーク用で、外部ネットワークに経路指定されることがあ

る仮想マシン データ ネットワークがあります。

図 6-4. クラウド ポッドのネットワーク では、クラウド ポッドに注目しています。ここでは 4 つの物理ネットワー

クが示されていますが、ストレージ ネットワークは特定のハードウェアと一部のストレージ テクノロジーに固有で

す。リソース プールが複数のクラスタにまたがっていない場合は、物理的な仮想マシン データ ネットワークの提供

は必須ではありません。それ以外の場合は（リソース プールが複数のクラスタにまたがっている場合）、vMotion トラフィック用に個別の物理ネットワークを使用することをお勧めします。

図 6-4. クラウド ポッドのネットワーク

vCloud Director のセキュリティ

VMware, Inc. 32

また、ここでは、IDS IPS/、SIEM、構成管理、パッチ管理、脆弱性管理、アンチウイルス、GRC 管理システムな

どの一般的なデータセンター セキュリティ テクノロジーが、vCloud Director とその関連システムおよび vSphere とその関連システムに加え、それらをサポートするネットワークとストレージ インフラストラクチャにも適用される

と想定しています。これらのシステムの詳細も、本書の範囲外です。

リソースの共有および分離の推奨事項

通常、サービス プロバイダはコンピューティング リソース、ストレージ リソース、およびネットワーク リソースを

複数のテナント組織で共有できます。システムは、ハイパーバイザーおよび vCloud Director ソフトウェア スタッ

クにおいて、抽象化による分離およびセキュアなエンジニアリング プラクティスを適用します。

テナント組織は、単一のプロバイダ仮想データセンターを通じて、所有していないリソースに影響を与えずに、ある

いはそのことを認識することもなく、基盤となるリソース プール、データストア、および公開済みの外部ネットワー

クを共有しています。vApp のストレージとランタイム リースの適切な管理、vApp の割り当て容量、リソースを大

量に使用する処理の制限、および組織仮想データセンター割り当てモデルにより、1 つのテナントが他のテナントの

サービスを意図的であるか否かに関わらず、拒否することはありません。たとえば、きわめて堅実な設定では、すべ

ての組織仮想データセンターを予約プール割り当てモデルの管理下に置き、リソースのオーバー コミットを絶対に行

わないように設定します。このドキュメントではオプションについてすべては解説しませんが、いくつかの点につい

て以降のサブセクションで説明します。

セキュリティ ドメインとプロバイダ仮想データセンターソフトウェアで適切な分離と適切な組織構成を行っていても、特定のコンピューティング リソース、ネットワーク リソース、またはストレージ リソースで異なるワークロードを実行したりまたは格納することをテナント組織で避ける

場合があります。これによってシステム全体をセキュリティの高い環境に強化することにはなりませんが、クラウド

を複数のセキュリティ ドメインに分割することが必要になります。このような対応が必要なワークロードの具体的

な例は、次のとおりです。

n 定められた場所での格納および処理が必要な、プライバシー関連法の対象となるデータ。

n 国や組織が所有するデータおよびリソースのうち、クラウドの分離を信頼していても慎重を期すためや多層防御

の問題として、その仮想データセンターでは特定の他のテナント（競合企業など）と共有できないリソース。

これらのようなシナリオでは、プロバイダ仮想データセンターを使用して、リソース プール、ネットワーク、および

データストアを複数の「セキュリティ ドメイン」にセグメント化する必要があります。これによって、同様の問題を

持つ vApp をグループ化（または隔離）できます。たとえば、あるプロバイダ仮想データセンターが特定の国のデー

タを格納、処理するように、明確に識別することが考えられます。

リソース プール単一のプロバイダ仮想データセンターに、基盤となる vSphere インフラストラクチャによって提供される CPU およびメモリ リソースを集約したリソース プールを複数置くことができます。機密保持と整合性を維持するために、

異なるリソース プールにまたがる各組織を分割する必要はありません。しかし、可用性の観点からこれを実行するこ

とが妥当である場合もあります。このリソース管理の問題には、組織仮想データセンターの割り当てモデル、予想ワ

ークロード、これらの組織に適用される割り当て容量と制限、プロバイダが追加のコンピューティング リソースをオ

ンラインにできる速度が関係します。このガイドでは、各種のリソース割り当てモデルの定義や、それが各組織によ

るリソース プールの利用にどのように影響するかについては説明しません。複数の組織によって使用されるプール

vCloud Director のセキュリティ

VMware, Inc. 33

に属するリソースのオーバー コミットメントを許可すると、1 つまたは複数の組織でサービス品質の低下を起こすリ

スクが必ず発生するということを述べるにとどめます。サービス レベルを適切に監視することは、1 つの組織でサー

ビス拒否が発生することを回避するために不可欠ですが、この目標を満たすために具体的に組織の分離を示唆するも

のではありません。

共有リソースの共有使用量の制限

デフォルト設定では、vCloud Director の多くのコンピューティング リソースおよびストレージ リソースがすべて

のテナントによって無制限に使用される可能性があります。システムには、システム管理者がこれらのリソースの使

用を管理および監視するための方法がいくつか用意されています。vCloud Director が提供するサービスのレベルに

影響を与える、「ノイジー ネイバー」の可能性を低くするため、次の事項を慎重に調査することが重要です。

リソースを大量に使用する

処理の制限

『 vCloud Director 管理者ガイド』のシステム制限の構成を参照してください。

実用的な割り当て容量の設

定

『 vCloud Director 管理者ガイド』の組織のリース、割り当て容量、および制限の設

定の構成、および（テナントが作成できる仮想データセンターの数と仮想マシンあ

たりの同時接続数を制限するには、システム制限の構成を参照してください。

ストレージとランタイム リースの管理

リースにより、テナントによるストレージとコンピューティング リソースの使用を

一定のレベルに制御できます。共有リソースを管理する上では、vApp がパワーオ

ン状態を維持できる時間や、パワーオフ状態の vApp がストレージを使用できる時

間を制限することが重要な手順になります。『 vCloud Director 管理者ガイド』のリ

ースについてを参照してください。

外部ネットワーク

サービス プロバイダは、外部ネットワークを作成し、それにテナントがアクセスできるようにします。外部ネットワ

ークは、パブリックなネットワークであるため、複数のパブリック ネットワーク間で安全に共有できます。外部ネッ

トワーク上のトラフィックは傍受されることがあるため、テナントは必要に応じてこれらのネットワークにおいては

気密保持および整合性を確保するためにアプリケーション レベルまたはトランスポート レベルでセキュリティを講

じなければならないことを留意する必要があります。

プライベートの経路指定されたネットワークは、パブリック ネットワークに接続するために使用するという状況で

は、これらの外部ネットワークを共有できます。外部ネットワークは、組織仮想データセンターのネットワークによ

って使用されることがあります。これは、2 台の異なる vApp やそのネットワークを接続したり、vApp ネットワー

クをエンタープライズ データセンターの方向へ接続するために使用されます。これらのケースでは、外部ネットワー

クを組織間で共有すべきではありません。

しかし、組織ごとに個別の物理ネットワークを用意することは現実的ではありません。代わりに、DMZ ネットワー

クであることがはっきりとわかっている 1 つの外部ネットワークに共有物理ネットワークを接続することをお勧め

します。これによって組織は、機密性の保護が提供されないことを意識できます。vApp からエンタープライズ デー

タセンターへの接続やパブリック ネットワークを経由した vApp から vApp へのブリッジなど、外部ネットワーク

を通過しながらも機密性の保護を必要とする通信については、VPN を展開することが考えられます。これは、プラ

イベートの経路指定されたネットワーク上の vApp にアクセスできるようにするには、その外部ネットワークでルー

ティングできる IP アドレスを使用した IP アドレス転送を利用する必要があるためです。その物理ネットワークに

接続する他の vApp はすべて、別の外部ネットワークに接続されている別の組織であっても、その vApp にパケット

vCloud Director のセキュリティ

VMware, Inc. 34

を送信できます。これを防ぐには、サービス プロバイダが NSX 分散ファイアウォールと分散論理ルーティングを使

用して、単一の外部ネットワーク上の複数のテナントからのトラフィックを分離します。『VMware vCloud® for Service Providers Architecture Toolkit™ (vCAT-SP)』の NSX 分散ファイアウォールと論理ルーティングを参照

してください。

複数のテナントによって所有されている組織仮想データセンター ネットワークは、NAT と IP マスカレードによって

内部へのアクセスを許可しない限り、同じ外部ネットワークを（Edge Gateway からのアップリンクとして）共有

できます。

重要： vCloud Director Advanced Networking では、テナントおよびサービス プロバイダが OSPF などの動的

ルーティング プロトコルを使用できます。OSPF 自動検出メカニズムを認証なしで使用すると、異なるテナントに

属する Edge ゲートウェイ間でピアリング関係が確立され、ルートの交換が開始される可能性があります。これを回

避するには、パブリックに共有されているインターフェイスでは OSPF 認証を有効にしない限り OSPF を有効にし

ないことで、認証されていない Edge ゲートウェイとのピアリングを防ぎます。

ネットワーク プール1 つのネットワーク プールを複数のテナントで使用するためには、プール内のすべてのネットワークを適切に分離す

る必要があります。VXLAN にバッキングされるネットワーク プール（デフォルト）は、物理および仮想スイッチが

VXLAN 内の接続、および異なる VXLAN 間の分離を許可するように設定されていることを前提としています。ポー

トグループによってバッキングされるネットワーク プールは、互いに分離されているポートグループを使って設定す

る必要があります。これらのポートグループは、VXLAN によって物理的に分離できます。

3 種類（ポートグループ、VLAN、VXLAN）のネットワーク プールのうち、vCloud Director VXLAN ネットワー

ク プールが最も簡単に共有できます。VXLAN プールは、VLAN やポートグループによってバッキングされるネット

ワーク プールよりも多くのネットワークをサポートしており、また、分離が vSphere カーネル レイヤーで適用され

ます。VXLAN を使用しない場合、物理スイッチではトラフィックが分離されませんが、VXLAN はハードウェア レイヤーでの設定の誤りの影響を受けません。既に説明したように、どのネットワーク プールに属するネットワークで

も、パケットの傍受に対する機密性の保護は（たとえば物理レイヤーで）提供されません。

ストレージ プロファイルvCloud Director のストレージ プロファイルによるデータストアの集約情報を使用すると、サービス プロバイダは

容量、パフォーマンスなどの属性で区分したストレージ機能を提供できます。テナント組織は、個々のデータストア

にはアクセスできません。代わりに、テナントは、サービス プロバイダが提供するストレージ プロファイルのセッ

トから 1 つを選択します。基盤となるデータストアが vSphere 管理ネットワークからのみアクセスできるように設

定されている場合、データストアを共有するリスクは、コンピューティング リソースの場合と同様、可用性に限定さ

れます。ある組織のストレージが予想よりも多くなり、他の組織が使用できるストレージの量が制限される事態も考

えられます。これは特に、組織が従量課金制割り当てモデルとデフォルトの「無制限のストレージ」設定を使用して

いる場合に発生しがちです。このため、データストアを共有する場合は、ストレージの制限を設定し、可能であれば

シン プロビジョニングを有効にして、ストレージ使用量を慎重に監視します。また、共有リソースの共有使用量の制

限で説明しているとおり、ストレージ リースを慎重に管理する必要があります。一方、データストアを共有しない場

合は、各組織が選択したストレージ プロファイルに沿って、適切に専用のストレージを設定します。この場合、必要

としない組織に割り当てることによってストレージを無駄にする可能性があります。

vCloud Director のセキュリティ

VMware, Inc. 35

vSphere データストア オブジェクトは、VMDK が保存される論理ボリュームです。vSphere 管理者は、これらの

データストアの作成元となった物理ストレージ システムを確認できます。これには、vCloud Director 管理者やテナ

ントには提供されない権限が必要です。vApp を作成、アップロードするテナント ユーザーは単純に、使用している

組織仮想データセンター内で使用可能なストレージ プロファイルのいずれかで vApp の VMDK を格納します。

このため、仮想マシンの VMDK によって使用される以外のストレージは、それらのストレージ システムへのネット

ワーク接続がない限り、その仮想マシンでは一切認識されません。そのような接続は設定しないことをお勧めします。

プロバイダがネットワーク サービスとして vApp に外部ストレージへのアクセスを提供する場合もありますが、それ

はクラウドをバッキングする vSphere ホストに割り当てられる LUN とは別にする必要があります。

同様に、テナント組織では、その組織の仮想データセンターで使用可能なストレージ プロファイルしか認識されず、

その表示も vCloud Director 抽象化に限定されます。システムのデータストアを参照することはできません。表示

されるのは、カタログで公開されているもの、または管理する vApp で使用されているものだけです。組織仮想デー

タセンターのストレージ プロファイルでデータストアを共有していない場合、組織が他の組織のストレージに影響を

与えることはありません（ストレージ I/O のネットワーク バンド幅がきわめて大きくなった場合を除く）。影響を与

えたとしても、上記の制限事項と抽象化により、組織間の適切な分離は確保されます。vCloud Director 管理者は、

特定のデータストアで vSphere Storage I/O Control を有効にして、テナントが膨大な量のストレージ I/O バンド

幅を使用できないように制限できます。『 vCloud Director 管理者ガイド』のプロバイダ仮想データセンターでの

Storage I/O Control サポートの構成を参照してください。

ユーザー アカウントの管理ユーザーおよび認証情報の管理は、すべてのシステムのセキュリティにとって重要です。vCloud Director では、シ

ステムに対する認証とシステム内の認証のすべてにユーザー名とパスワードが使用されるため、ユーザーとパスワー

ドの管理のベスト プラクティスを実践することが重要です。

このトピックでは、vCloud Director におけるユーザーとパスワードの管理の機能と制限事項について記載し、それ

ら制約のもとでユーザーとパスワードをセキュアに管理および使用するための推奨事項を紹介します。

ローカル ユーザー アカウントの制限vCloud Director には、vCloud Director データベースで作成および保持されるユーザー アカウントに対する自己完

結型の ID プロバイダが用意されています。これらのアカウントは、本来データベースへのネットワーク アクセスを

制限するよう構成されているシステムでは脆弱ではありませんが（管理ネットワークの構成を参照）、PCI データ セキュリティ基準などの特定の業種で要求されるパスワードの種類を管理する機能は提供されません。ブルート フォ

ース アタックを防ぐために、ローカル アカウントをパスワード再試行の制限およびアカウント ロックアウトのルー

ルの対象にする必要があります。

サービス プロバイダは、システム管理者のローカル アカウントを引き続き使用するメリットとリスクを慎重に評価

する必要があります。ローカル システム管理者アカウントを設定する場合は、組織のクラウド URL で認証されるソ

ース IP アドレスを慎重に制御する必要があります。この ID プロバイダをシステム管理者アカウントに使用しない

ようにするか、少なくとも使用を制限することを強く推奨します。

vCloud Director のセキュリティ

VMware, Inc. 36

vCloud Director の新規インストールでは、ローカル システム管理者アカウントが作成されます。vCloud Director のデフォルトの構成では、少なくとも 1 つのシステム管理者アカウントをローカルにしておく必要があります。シス

テム組織で vSphere SSO サービス (SAML IDP) または LDAP を使用できるようにしているサービス プロバイダ

は、次の手順を実行して、vCloud Director をローカル システム管理者アカウントなしで動作するように構成できま

す。

1 vSphere SSO サービス (SAML IDP) または LDAP でシステム管理者用のアカウントを 1 つ以上作成します。

2 それらのアカウントをシステム組織にインポートします。

3 セル管理ツールの manage-config コマンドを実行してシステムを再構成します。ローカル システム管理者ア

カウントを不要にし、ローカル アカウントを持つシステム管理者はシステムで認証されないようにします。

./cell-management-tool manage-config -n local.sysadmin.disabled -v true

他の組織のローカル アカウントは無効になりません。

注： ローカル システム管理者アカウントがないシステムでは、システム管理者の認証情報を指定する必要があ

るセル管理ツールのコマンドに対して、代わりに -i --pid オプションを使用する必要があります。pid にはセ

ルのプロセス ID を指定します。『 vCloud Director 管理者ガイド』のセル管理ツール リファレンスを参照して

ください。

4 ローカル アカウントを持つシステム管理者のアクセスを再度有効にするには、同様のセル管理ツールのコマンド

ラインを使用してこの変更を元に戻すことができます。

./cell-management-tool manage-config -n local.sysadmin.disabled -v false

パスワード管理

LDAP、OAUTH、SAML の多くの IDP は、ユーザーがパスワードを忘れた場合に、機能を提供するか、システム

と連携します。これらは、このドキュメントの範囲外です。vCloud Director のセル管理ツールには、失われたシス

テム管理者のパスワードを回復するために使用できる recover-password コマンドが含まれています。他のロー

カル ユーザーについてこの状況に対処するためのネイティブ機能は、vCloud Director にはありません。すべてのロ

ーカル アカウントのパスワードを、IT セキュリティ部門によって承認済みの方法で安全に保存することをお勧めし

ます。パスワードをヴォールトに格納する組織もあれば、有償または無償のパスワード ストレージ プログラムを使

用する組織もあります。このドキュメントでは、特定の方法を推奨しません。

パスワード強度

IDP ユーザーのパスワードの強度は、その IDP や、ディレクトリ内のユーザー管理に使用するツールが提供する制

御に依存します。たとえば、vCloud Director を Active Directory に接続する場合は、Microsoft Active Directory に関連付けられている一般的な Active Directory のパスワードの長さ、複雑さ、履歴の制御がディレクトリ自体によ

って適用されます。他の IDP も同様の機能をサポートする傾向にあります。パスワード強度の制御の詳細は、ディレ

クトリに固有であるため、ここでは詳しく説明しません。

vCloud Director では、ローカル ユーザーのパスワードの長さが 6 文字以上である必要があります。この要件は設

定不可で、その他のパスワード要件、履歴の制御はありません。総当たり攻撃からの保護のために、すべてのユーザ

ー（特にシステムや組織の管理者）が細心の注意を払ってパスワードを選択するようにしてください（この後のアカ

ウント ロックアウトの問題を参照してください）。

vCloud Director のセキュリティ

VMware, Inc. 37

ユーザー パスワードの保護IDP によって管理されているユーザーの認証情報は vCloud Director データベースに格納されません。IDP によっ

て選択された方法を使用して送信されます。この情報チャネルのセキュリティ保護の詳細については、「ID プロバイ

ダの構成 」を参照してください。

ローカル ユーザーのパスワードは、vCloud Director データベースに格納される前にソルト付きでハッシュ化されま

す。プレーン テキストのパスワードをデータベースから回復することはできません。ローカル ユーザーの認証で

は、提示されたパスワードのハッシュがデータベースのパスワード フィールドの内容と比較されます。

その他のパスワード

vCloud Director データベースは、ローカル ユーザーの認証情報に加えて、接続されている vCenter Server および

NSX Manager のパスワードを格納します。これらのパスワードの変更は、システムで自動的に更新されません。

vCloud Director 構成スクリプト（vCloud Director データベースのパスワードの場合）か、vCenter および NSX の Web ユーザー インターフェイスを使用して、手動で変更する必要があります。

vCloud Director は、上で説明したように vCloud Director データベース、vCenter Server、および NSX Manager サーバのパスワードを保持するほかに、TLS/SSL 証明書に関連付けられたプライベート キーにアクセスするための

パスワードも保持します。これらのパスワードは、vCloud Director のインストールごとに一意のキーを使用して暗

号化され、$VCLOUD_HOME/etc/global.properties ファイルに保存されます。「インストール後の機密ファイ

ルの保護」で説明したように、そのファイルが含まれているすべてのバックアップを慎重に保護してください。

ロール ベースのアクセス制御vCloud Director は、ロール ベースの承認モデルを実装します。このセクションでは、vCloud Director で使われる

各種の ID ソース、ユーザーのタイプ、認証制御、ロール、および権限について説明します。システムを適切に保護

し、適切な人々に正しいアクセスを提供するためには、この情報を理解することが必要です。

vCloud Director テナント組織には、任意の数のユーザーおよびグループを含めることができます。ユーザーは、組

織管理者がローカルで作成するか、外部のディレクトリ サービス (LDAP) または ID プロバイダ（OAUTH、

SAML）からインポートできます。インポートされたユーザーは、1 つ以上のグループのメンバーになることができ

ます。複数のグループのメンバーであるユーザーには、それらのグループに割り当てられているすべてのロールが割

り当てられます。各組織の作成時には、権限のデフォルトのセットと、それらの権限の組み合わせを含む事前定義済

みのロールのセットが与えられます。システム管理者は追加の権限を組織に付与でき、組織管理者はそれらの権限を

使用して、組織にローカルなカスタム ロールを作成することができます。組織内の権限は、ユーザーおよびグループ

に権限とロールを割り当てることによって管理されます。

認証されていないユーザーは、Web コンソール、テナント ポータル、または vCloud API を介して vCloud Director の機能のいずれにもアクセスできません。各ユーザーは、ユーザー名とパスワードを使用して認証します。パスワー

ドの再試行とアカウントのロックアウトに関するポリシーは、グローバルと組織単位の両方で設定できます。

ロールとは、そのロールが割り当てられたユーザーに機能を提供するために、権限をグループ化したものです。事前

定義済みのロールは次のとおりです。

n システム管理者

n 組織管理者

n カタログ作成者

vCloud Director のセキュリティ

VMware, Inc. 38

n vApp 作成者

n vApp ユーザー

n コンソールのアクセスのみ

『 vCloud Director 管理者ガイド』では、これらの各ロールに割り当てられている権限も説明しています。そのセク

ションの目的は、ユーザーのタイプごとに適切なロールを選択できるようにすることです。たとえば、vApp ユーザ

ー ロールは、仮想マシンをパワーオン、パワーオフする必要がある管理者には適していますが、その管理者が仮想マ

シンに割り当てられるメモリの量を編集することも必要な場合は、vApp 作成者のほうが適切なロールです。これら

のロールが各自のテナント組織に適した権限のセットと完全に一致しない可能性もあるため、組織管理者はカスタム

ロールを作成できます。どのような特定の権限を組み合わせて実用的なカスタム ロールを作成するかについての説

明は、本書の範囲外です。

ID プロバイダの構成vCloud Director テナント組織は、他のアプリケーションや企業と共有する ID プロバイダを定義できます。ユーザ

ーは ID プロバイダに認証し、組織にログインできるトークンを取得します。この方法によって、企業は vCloud Director などの複数の関連性のないサービスへのアクセスを、認証情報の単一のセット（シングル サインオンと呼

ばれる配列）で提供できます。

ID プロバイダについてvCloud Director では、次のような ID プロバイダがサポートされています。

OAuth RFC 6749 で定義された、OAuth 認証に対応する外部の ID プロバイダを定義でき

ます (http://tools.ietf.org/html/rfc6749)。

SAML セキュリティ アサーション マークアップ言語 (SAML) 2.0 標準をサポートする外

部の ID プロバイダを定義できます。

統合 統合 ID プロバイダは、ローカルで作成された、または LDAP からインポートされ

たユーザーを認証する、vCloud Director のサービスです。

OAuthすべての OAuth 実装において、通常のセキュリティの決定は OAuth 認証サーバ レイヤーで行われます。vCloud Director はリソース サーバのロールにあります。これはトークンを使用し、トークンの整合性の検証のみを処理し

ます。

vCloud Director セッションとその基盤となる機密資産を保護するため、OAuth 認証サーバを安全に設定し、最新の

セキュリティ パッチをインストールする必要があります。

クエリ パラメータで指定された任意の URL にユーザーリダイレクトされるように OAuth 認証サーバを設定するこ

とがある場合、攻撃者によってサードパーティ アプリケーションへのリダイレクトが制御されるのを防ぐため、URL を検証するように OAuth 認証サーバを設定する必要があります。正当なアプリケーションのホワイト リストを使

用して検証する必要があります（使用可能な場合）。

LDAPvCloud Director 統合 ID プロバイダは、いくつかの一般的な LDAP サービスをサポートしています。

vCloud Director のセキュリティ

VMware, Inc. 39

サポートされている LDAP サービスのリストについては、『 vCloud Director リリース ノート』を参照してくださ

い。

システム管理者は vCloud Director を使用して、すべてのテナントが使用できるシステム全体の LDAP サービスを

定義できます。テナント ユーザー アカウントは、vCloud Director ロールが割り当てられている vCloud Director データベースにインポートされます。LDAP ユーザーのパスワードは LDAP ディレクトリ内で管理および保持さ

れ、認証は、LDAP 設定画面で指定された設定を使用してそのディレクトリに対して行われます。認証の失敗による

ロックアウト、パスワードの有効期限、履歴、複雑性など、認証とパスワードに関する LDAP ディレクトリのすべ

ての制御は、選択した LDAP サービスごとに保持されます。組織でシステム LDAP を使用するように設定されてい

る場合、その組織のユーザーは、組織の vCloud Director システム LDAP サービス設定で個別に設定されている組

織単位 (OU) に属します。

クラウド プロバイダは、テナントの組織がシステム LDAP 内で組織単位 (OU) を使用すること、または組織固有の

LDAP ディレクトリ サービスをホストすることを許可できます。いずれの場合でも、組織の管理者がユーザーを管

理できるよう、そのディレクトリへの適切な管理アクセスを提供する必要があります。このような制御がないと、シ

ステム管理者に余分な負荷がかかり、組織は簡単、適切に仮想データセンターへのアクセスを制御できなくなります。

このような管理制御がない場合、組織は自身でホストおよび管理するプライベート LDAP ディレクトリのみを使用

する必要があります。

ソフトウェアでユーザーを適切に認証するためには、vCloud Director セルからシステム LDAP サーバおよび組織の

LDAP サーバへの接続を有効にする必要があります。このドキュメントで推奨されているように、システム LDAP サーバは、ファイアウォールによって DMZ から分離されたプライベート管理ネットワーク上に置く必要がありま

す。一部のクラウド プロバイダと大部分の IT 組織は、それぞれ必要な組織 LDAP サーバを実行しますが、これも

DMZ ではなくプライベート ネットワークに置かれます。組織 LDAP サーバのもう 1 つのオプションは、クラウド

プロバイダの環境の外部で、組織の制御下にサーバをホストし、管理することです。その場合は、サーバを vCloud Director セルに公開する必要があります。これは、エンタープライズ データセンター独自の DMZ を介して行うこ

とが考えられます。

これらの状況のどの場合でも、TLS/SSL を使用する LDAP で説明されているとおり、セルと LDAP サーバの間の

経路上にあるさまざまなファイアウォールを通して適切なポートを開く必要があります。また、組織が自らの LDAP サーバをホストする際の懸念は、DMZ を通してサーバを公開することです。通常のユーザーに対してアクセス可能

にしておくべきサービスではないため、vCloud Director セルに対してのみアクセスを制限するよう措置をとる必要

があります。これを行うための 1 つの簡単な方法は、クラウド プロバイダからの報告に基づいて、vCloud Director セルに属する IP アドレスからのアクセスのみを許可するように LDAP サーバや外部のファイアウォールを設定す

ることです。その他の方法としては、2 つのシステムを結ぶ事前構成されたサイト間 VPN などのシステム、強化し

た LDAP プロキシまたは仮想ディレクトリなど、さらにいくつかありますが、いずれも本書の範囲外です。

一方、クラウド プロバイダは、組織がホストする LDAP サーバを問題のある顧客が管理している場合に、他の組織

に対する攻撃で使用される可能性を考慮する必要があります。たとえば、ある組織名のよくあるスペルミスに基づく

組織名を申請して、その紛らわしいログイン URL を使用してフィッシング攻撃に使用することを思いつく人物がい

るかもしれません。この種のテナント間攻撃から保護するためにプロバイダが実行できる手順には、リクエストのソ

ース IP アドレスをできるだけ制限して組織間のログイン試行を避けることや、互いに類似した組織名を割り当てな

いようにすることがあります。

vCloud Director のセキュリティ

VMware, Inc. 40

TLS/SSL を使用する LDAP

ユーザー認証のために LDAPv3 ディレクトリを構成することを強くお勧めします。これらのサーバに対して有効な

パスワードを正しく保護するために、vCloud Director を SSL 経由で LDAP に接続するよう構成する必要がありま

す。詳細については、『 vCloud Director 管理者ガイド』の「LDAP 接続の構成」を参照してください。最も安全な

LDAP 設定は、[SSL を使用] を指定し、LDAP サービスによって提供される SSL 証明書を要求することです。

LDAP サーバの署名付き証明書を入手できない場合は、LDAP サーバ証明書に署名した認証局 (CA) の証明書を、シ

ステムまたは組織の JCE キー ストア (JCEKS) にインポートする必要があります。JCEKS キーストアを指定する

LDAP 設定も安全ですが、信頼する CA 証明書（または個々のサーバ証明書）の数が多くなると設定を誤るおそれが

あります。また、Kerberos 認証をサポートしている LDAP プロバイダを選択することをお勧めします。

LDAP サーバへの接続が必要です。プレーン（非 SSL）LDAP はポート 389/TCP で実行されますが、LDAP over SSL をサポートするサーバは、デフォルトではポート 636/TCP を使用します。ただし、このポートは設定可能で

す。vCloud Director はレガシーの LDAP over SSL (LDAPS) 手法をサポートしており、LDAP 接続で StartTLS コマンドを使用した TLS のネゴシエーションはサポートしていないことに注意してください。

最後に、LDAP 対応のディレクトリ サーバは、SSL 証明書を使って正しく設定する必要があります。その方法は、

本書の範囲外です。

グループのインポート

グループを vCloud Director にインポートする目的は、ロールがすべて同じ個々のユーザーを手動でインポートしな

くて済むようにすることです。LDAP ユーザーがログインすると、そのユーザーが属するグループにマッピングされ

ているロールがセッションに割り当てられます。ユーザーのグループ メンバーシップが組織内での職務の変更に伴

って変更された場合、そのユーザーに割り当てられるロールは、グループとロールのマッピングに基づいて自動的に

変更されます。これによって組織は、クラウドのロールと組織内部のグループ/ロール、およびそれらをプロビジョニ

ングして管理するシステムとを簡単に統合できます。

たとえば、初期状態では LDAP ユーザーに「コンソールのアクセスのみ」ロールを付与してユーザーの権限を制限

することが考えられます。そのためには、この基本ロールが必要なすべてのユーザーを 1 つの LDAP グループに追

加し、そのグループをインポートしてから、組織管理者が「コンソールのアクセスのみ」ロールを割り当てます。そ

の後、追加的な職務を実行する必要があるユーザーは、他の LDAP グループに追加し、同じように vCloud Director にインポートして、追加の権限ロールに割り当てます。たとえば、カタログを作成する必要のあるユーザーは、組織

の LDAP サーバで「組織 A のカタログ作成者」グループに追加することが考えられます。その後、組織 A の組織管

理者は「組織 A のカタログ作成者」グループをインポートし、vCloud Director で事前に設定してある「カタログ作

成者」ロールにマッピングします。これを実行するには、『 vCloud Director ユーザー ガイド』の「グループのイン

ポート」の手順を実行します。

vCloud Director のセキュリティ

VMware, Inc. 41

チェックリスト 7このチェックリストは、このドキュメントで記載されている主なセキュリティ構成のタスクをまとめたものです。

n 本書のガイドのほか、http://www.vmware.com/security/advisories/ セキュリティ アドバイザリを確認してく

ださい。また、このページのフォームからメール アラートにサインアップすることをお勧めします。このページ

には、補足的なセキュリティ ガイダンスと vCloud Director の最新のアドバイザリが掲載されます。

n 管理者は、『vSphere Security』(https://docs.vmware.com/jp/VMware-vSphere/6.0/com.vmware.vsphere.security.doc/GUID-52188148-C579-4F6A-8335-CFBCE0DD2167.html)、

『Securing VMware NSX for vSphere』(https://communities.vmware.com/docs/DOC-27674)、および

『NSX-v 6.3.x Security Configuration Guide 』(https://communities.vmware.com/docs/DOC-28142) で推

奨された手順を適用し、これらの製品が安全にインストールされたことを確認します。

n インストール前に、セルの Linux プラットフォーム、vCloud Director データベース、および仮想インフラスト

ラクチャに最新のセキュリティ パッチを適用します。これらのコンポーネントを継続的に監視し、パッチ レベ

ルが最新の状態に維持されていることも重要です。

n 不要なネットワーク サービスの無効化、不要なパッケージの削除、リモート root アクセスの制限、強力なパス

ワード ポリシーの適用など、標準的なセキュリティ強化手順をセルの Linux プラットフォームに適用する必要

があります。可能であれば、Kerberos などの一元的な認証サービスを使用します。また、モニタリング ツール

と侵入検知ツールのインストールを検討してください。

n 追加のアプリケーションをインストールし、セルの Linux プラットフォームに追加のユーザーをプロビジョニン

グすることも可能ですが、そのような設定を行うことは推奨されません。セルの OS へのアクセスを拡大する

と、セキュリティが低下するおそれがあります。

n responses.properties ファイルは、そのファイルを必要とするユーザーのみが使用できるようにします。

ファイルを使用している（セルをサーバ グループに追加している）場合は、適切なアクセス制御を、すべてのタ

ーゲット ホストがアクセス可能な場所に配置します。作成したバックアップはすべて慎重に管理し、バックアッ

プ ソフトウェアがサポートしている場合は暗号化も行います。サーバのすべてのホストにソフトウェアがイン

ストールされたら、これらがアクセス可能な場所にある responses.properties ファイルのコピーをすべて

削除する必要があります。

n responses.properties および global.properties ファイルは、$VCLOUD_ HOME/etc folder およ

びこのファイルのアクセス制御によって保護されます。ファイルやフォルダの権限を変更しないでください。

n vCloud Director サーバへの物理的アクセスおよび論理的アクセスを厳重に制限し、ログインする必要があるユ

ーザーにのみ、必要最低限のレベルでアクセス権限を付与してください。アクセス制限には、sudo による root アカウントの使用制限やその他のベスト プラクティスも関係します。サーバのバックアップは厳重に保護した

うえで、バックアップとは別に管理されているキーを使用して暗号化する必要があります。

VMware, Inc. 42

n データベースのセキュリティ要件については、使用する vCloud Director データベース ソフトウェアのセキュ

リティ ガイドを参照してください。

n vCloud Director データベースのユーザーには、そのサーバ上の別のデータベースに対する権限や、他のシステ

ムの管理権限を付与しないでください。

n セル、接続済み vCenter Server、vCloud Director データベース、ファイアウォール、およびその他の機器へ

の管理者権限に使用される認証情報が、パスワードの要件を満たしているか確認してください。

n 「多層防御」の観点から、セル、vCloud Director データベース、vCenter Server、NSX を含め、vCloud Director 環境内の各サーバの管理パスワードを、それぞれ別のものにすることが重要です。

n vCenter および ESXi で使用される証明書の作成と置き換えの詳細については、https://docs.vmware.com/jp/VMware-vSphere/6.0/com.vmware.vsphere.security.doc/GUID-779A011D-B2DD-49BE-B0B9-6D73ECF99864.html を参照してください。これは強く推奨されます。

n vCenter Server 証明書には、vCenter Server がインストールされているサーバの完全修飾ドメイン名

(FQDN) と一致するコモン ネーム (CN) フィールドが必要です。

n vCloud Director を設定して vCenter Server 証明書を確認します。

n vCenter 証明書は、認証局 (CA) によって署名されており、セルがインストールされたホストの FQDN に一致

する CN を持っている必要があります。

n vCloud Director サービスを外部で利用可能にするには、DMZ 上で vCloud Director セルからインターネット

を分離しているファイアウォールと共に DMZ 内のセルを配置することをお勧めします。インターネットに接

するファイアウォールで許可する必要のあるポートは 443/TCP のみです。

n vCloud Director セルは DMZ 内にあるため、必要なサービスにアクセスするにはネットワークのファイアウォ

ールを介する必要があります。具体的には、vCloud Director データベース、vCenter Server、vSphere ホス

ト、IDP（LDAP を含む）、およびすべてのバックアップや類似のサービスには、DMZ を内部ネットワークから

分離しているファイアウォールの反対側からアクセスすることが推奨されます。

n インターネットなどのクラウドの外部からアクセスする必要のある仮想マシンは、公開されたサービス用に設定

されたポート転送を使用して、パブリック ネットワークまたはプライベート NAT ネットワークのいずれかに接

続されます。これらの組織仮想データセンター ネットワークが接続される外部ネットワークでは、この DMZ ネットワークへの合意されたトラフィックを許可するファイアウォール保護が必要です。

n 一般的に、インターネットからのアクセシビリティを必要とする vApp は、プライベート ネットワークに配置す

ることが推奨されます。こうすることで、ファイアウォール越しのテナント コントロールおよび NSX により提

供されるポート転送ルールが実現します。上記またはその他のルールは、展開するネットワーク ファイアウォー

ルによって既定で適用されることがあります。特定の構成手順と既定の機能については、ファイアウォールのド

キュメントを参照してください。

n 多層防御原則では、JMX（ポート 8999/TCP）および JMS（ポート 61611/TCP および 61616/TCP）が、セ

ルが接続された DMZ を保護するネットワーク ファイアウォールでブロックされる必要があります。

n WAF またはロード バランサの背後にあるマルチセル クラウド用に、パブリック ウェブ URL、パブリック コンソール プロキシ アドレス、およびパブリック REST API ベース URL を設定します。

n ウェブ アプリケーション ファイアウォール (WAF) は、vCloud Director セルの前に展開する必要があります。

vCloud Director のセキュリティ

VMware, Inc. 43

n このような展開では、WAF を検査し、悪意のあるトラフィックを適切にブロックするように構成することをお

勧めします。これは通常、TLS または SSL の終了で行います。

n TLS または SSL 終了を設定する際は、CA 署名済み証明書をウェブ アプリケーション ファイアウォール

(WAF) でインストールし、vCloud API のクライアント アプリケーションおよび Web コンソールがサーバを

確実に特定できるようにするだけではなく、CA 署名済み証明書を WAF からしか表示できない場合でもセルで

使用することも重要です。

n 最後に、ロード バランサが WAF から独立したら、同様に CA 署名済み証明書を使用します。

n 可能であれば、ファイアウォールで X-Forwarded-For ヘッダーの生成を有効にすることを推奨します。

n vCloud Director サーバに管理専用の 3 つめの IP アドレスが割り当てられている場合は、JMX を直接この IP アドレスにバインドします。デフォルトで、vCloud Director JMX コネクタは構成中に指定したプライマリ IP アドレスにバインドされます。このデフォルト値は、次のプロパティに挿入することで上書きできます。/opt/vmware/vcloud-service-director/etc/global.properties: vcloud.cell.ip.management=IP or hostname for the management network to which the JMX connector should bind.

n 推奨されるよりセキュアな構成では、JMX コネクタをローカルホスト アドレスにバインドします

(vcloud.cell.ip.management=127.0.0.1)。JMX がローカルホストにのみ公開される場合、JMX 通信は

SSH を介して行われます。管理要件で、この種類のローカルホストの構成が許可されておらず、JMX を vCloud Director サーバ外に公開する必要がある場合は、JMX は TLS または SSL でセキュア化する必要があります。

n セルの背後は、vCloud Director が必要とするプライベートの管理要素であり、次が含まれます。データベース

自体、NSX、vCenter Server、システム LDAP サーバ（該当する場合）vCenter が使用する Active Directory サーバ、および vSphere ホストの管理インターフェイス。これらのサービスに DMZ 上の他のマシンや、イン

ターネットから直接アクセスできないように、その接続はファイアウォールによって厳重に制御されています。

n 一般的なデータセンターのセキュリティ技術（IDS/IPS、SIEM、構成管理、パッチ管理、脆弱性管理、アンチ

ウイルス、GRC 管理システムなど）は、vCloud Director とその関連システム、vSphere とその関連システム

に加え、それらをサポートするネットワークおよびストレージ インフラストラクチャの両方に適用されます。

n リース、割り当て容量、制限、割り当てモデルを正しく管理することで、1 つのテナント組織は誤って、または

意図的に他のサービスを拒否することはできません。

n これらのようなシナリオでは、複数のプロバイダ VDC を使用して、リソース プール、ネットワーク、およびデ

ータストアを複数のセキュリティ ドメインにセグメント化すべきです。それによって、同様の問題を持つ vApp をグループ化（または隔離）できます。

n 1 つ以上のテナント組織によって使用されるプール内のリソースのオーバーコミットメントを許可する場合は、

他のテナントでのサービス品質が低下するリスクが発生します。「ノイジー ネイバー」のテナントによるサービ

ス拒否を防ぐため、サービス レベルを適切に管理することが不可欠ですが、これを達成するためにテナントを個

々のリソース プールへと分離することはセキュリティ上は必要ではありません。

n 外部ネットワークは、組織仮想データセンターのネットワークによって使用されることがあります。これは、2 台の異なる vApp やそのネットワークを接続したり、vApp ネットワークをエンタープライズ データセンターの

方向へ接続するために使用されます。これらのような場合、外部ネットワークは複数のテナント組織間で共有す

べきではありません。

vCloud Director のセキュリティ

VMware, Inc. 44

n 外部ネットワークを経由し、機密保護（vApp と 企業データセンター間の接続または vApp 間のブリッジ）を必

要とする通信では、NSX Edge などの VPN 仮想アプライアンスを組織 VDC ネットワークに展開することを推

奨します。

n ネットワーク プールをテナント間で共有する必要がある場合は、VLAN にバッキングされているプールよりも

多くのネットワークをサポートする、VXLAN にバッキングされているプールを共有し、ESXi カーネル レイヤ

ーで分離することが最も安全です。

n ストレージ プロファイルの間でデータストアを共有している場合はストレージ制限を設定し、可能な場合はシン

プロビジョニングを有効にしてストレージ使用量を慎重に監視してください。vApp ストレージのリースも慎重

に管理します。

n 仮想マシンは、VMDK 外のストレージは監視しませんが、それらのストレージ システムにネットワークで接続

されている場合は別です。当ガイドではネットワークで接続しないことを推奨します。プロバイダがネットワー

ク サービスとして vApp 用に外部ストレージへのアクセスを提供する場合もありますが、クラウドの背後の

vSphere ホストへ割り当てられた LUN からは分離すべきです。

n vSphere セキュリティ (https://docs.vmware.com/jp/VMware-vSphere/6.0/com.vmware.vsphere.security.doc/GUID-52188148-C579-4F6A-8335-CFBCE0DD2167.html) で定義さ

れているように、管理ネットワークは仮想マシン データ ネットワークからは分離されていることが重要です。

n 同様に、組織管理者へのアクセスを提供する DMZ からも管理ネットワークは分離されている必要があります。

n ストレージ ネットワークも同様に物理的に分離します。これは vSphere のベスト プラクティスに準拠してお

り、テナント組織およびプロバイダ ストレージを悪意のある仮想マシンから保護します。

n vMotion は常に管理ネットワークから分離されたネットワークにあるわけではありませんが、クラウドでは、分

離義務の観点から重要となります。vMotion は一般的にセキュアに実行されますが、管理ネットワーク上に配置

すると、そのネットワークへのアクセス権を持つプロバイダ管理者などのユーザーが vMotion のトラフィック

を嗅ぎつけ、テナントのプライバシーに違反することができてしまいます。このため、クラウド ワークロードの

vMotion 用に、別の物理ネットワークを作成する必要があります。

n 定期的にログを確認し、疑わしい不審な未承認のアクティビティがないかを調査することはセキュリティ保護に

おいて推奨されます。定期的なログ分析は、システムの構成ミスや障害を特定したり、SLA の遵守を確認したり

するのにも役立ちます。

n Syslog サーバはインストール中に設定できます。TLS を有効にした Syslog インフラストラクチャを使用する

ことをお勧めします。Syslog サーバにログをエクスポートすることを推奨する理由は複数あります。重要なイ

ベントが必ずログに記録されるように、冗長性を備えた syslog サーバ構成をお勧めします。セキュリティ運用

組織と IT 運用組織は、中央集約と診断ログの管理の点でもメリットを享受できます。ログ サイズや保持する古

いログ ファイルの件数を制御するために、logrotate などの方法を使用することを推奨します。

n 診断ログおよび Jetty 要求ログに対応できる十分な空きディスク容量があることを確認します。集約ログは、ロ

グ ファイルの合計サイズである 400MB に達してファイルがローテーションされ削除される際に、重要な診断情

報を失わないようにします。

n vCloud Director に接続したり、使用されたりするその他のシステムが作成する監査ログも、監査プロセスに組

み込む必要があります。これらには、NSX、vCloud Director データベース、vCenter Server、および vSphere ホストからのログが含まれます。

vCloud Director のセキュリティ

VMware, Inc. 45

n 初期のローカル システム管理者のアカウント作成後、すべてのシステム管理者アカウントを LDAP や vSphere SSO サービスなどの ID プロバイダで管理することを強く推奨します。

n 一部のクラウド プロバイダは、組織にシステム LDAP 内で OU を使用することや、組織の LDAP ディレクト

リをホストすることを許可する場合があります。いずれの場合でも、組織の管理者がユーザーを管理できるよう、

そのディレクトリへの適切な管理アクセスを提供する必要があります。適切な管理制御がない場合、テナント組

織は自身がホストおよび管理する専用の LDAP ディレクトリを使用する必要があります。

n 組織が自身の LDAP サーバをホストする際のもう 1 つの懸念点は、サーバが DMZ 外部へ露呈することです。

通常のユーザーに対してアクセス可能にしておくべきサービスではないため、vCloud Director セルに対しての

みアクセスを制限するよう措置をとる必要があります。これを行うための簡単な方法の 1 つとして、LDAP サー

バや外部ファイアウォールを、vCloud Director セルに属する IP アドレスからのアクセスのみを許可するよう

設定することです。

n この種のテナント間攻撃から保護するためにプロバイダが実行できる手順には、リクエストのソース IP アドレ

スをできるだけ制限する、テナントに割り当てた組織名に互いに類似した名前を割り当てないようにするなどの

方法があります。

n これらのサーバに対して有効なパスワードを正しく保護するために、vCloud Director を SSL 経由で LDAP に接続するよう構成する必要があります。SSL 経由の LDAP を構成するときは、すべての証明書は承諾しないで

ください。

n ユーザーとパスワードの管理のベスト プラクティスを理解し、適用することが重要です。

n 総当たり攻撃によるパスワードのクラックの試行を監視するために、ログ管理やセキュリティ情報およびイベン

ト管理 (SIEM) などの監視システムを使用するべきです。

n システム管理者と組織管理者のパスワードは、IT セキュリティ部門により承認された方法で安全に保管すること

を推奨します。

vCloud Director のセキュリティ

VMware, Inc. 46