vcloud director のぜ㈷㌰尲㔵ぜ㌴㔰尳㔲ぜ㌰㘰尲㐳 - vcloud … · amqp (rabbitmq)...
TRANSCRIPT
vCloud Director のセキュリティ
vCloud Director 9.5vCloud Director 9.1
vCloud Director のセキュリティ
VMware, Inc. 2
VMware Web サイトで最新の技術ドキュメントをご確認いただけます。
https://docs.vmware.com/jp/
VMware の Web サイトでは、最新の製品アップデートを提供しています。
本書に関するご意見、ご要望をお寄せください。フィードバック送信先：
Copyright © 2010–2018 VMware, Inc. All rights reserved. 著作権および商標.
VMware, Inc.3401 Hillview Ave.Palo Alto, CA 94304www.vmware.com
ヴイエムウェア株式会社
105-0013 東京都港区浜松町 1-30-5浜松町スクエア 13Fwww.vmware.com/jp
内容
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
ユーザー アカウントの管理 36
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 は、1 つの vCloud Director サーバ グループ（インストール）を示しています。このサーバ グループ内に多数の vCloud Director サーバ ホストがあり、それぞれで 1 つのセルが実行されます。このサーバ グループはvCloud Director データベースと NFS ファイル共有（この図には表示されていません）を共有します。クラウド抽象化は、vCloud Director ソフトウェアと、この図でサーバ グループに接続している vCenter と NSX の両方の機能を使って構築されます。vCloud Director 組織とそのユーザーは、ワークロードの作成と管理に vCenter および NSXを直接使用しません。システム管理者以外のユーザーにとっては、vCenter や NSX とのすべてのやり取りは、
VMware, Inc. 7
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 接続を提供します。この組織仮想データセンターの外部のマシンは、組織仮想データセンターの内部のマシンに直接接続でき
ます。
クラウドに外部ネットワークを含める必
要があります。
外部ネットワークへの経路指定さ
れた接続
組織仮想データセンターの外部のマシンとネットワークへの EdgeGateway 経由の制御されたアクセスを提供します。システム管理者および組織管理者は、ゲートウェイにネットワーク アドレス変換(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 のセキュリティを確保するには、セル プラットフォーム（物理的なものか仮想的なものかを問わず）のセキュリティ確保が欠かせません。
VMware, Inc. 12
不要なネットワーク サービスの無効化、不要なパッケージの削除、リモート root アクセスの制限、強力なパスワード ポリシーの適用など、標準的なセキュリティ強化手順をセル プラットフォームに適用する必要があります。Kerberosなどの中央認証サービスを使用してください。また、モニタリング ツールと侵入検知ツールのインストールを検討してください。
追加のアプリケーションをインストールし、セルの 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 つの認証情報のセットが（組織に不満を抱いている退職予定の従業員などによって）漏洩した場合に、同じインフラスト
ラクチャのその他のシステムが同時に侵害されるのを防ぐためです。
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 aPostgreSQL 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、NSXManager、および 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 UntrustedEnvironmentsに記載されています。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 終端」を参照してください。
一般に、適切に署名された証明書は、SSL クライアントがルートまでの信頼チェーンを検証できるので、インポートする必要はありません。低レベルの証明書（エンタープライズ CA または自己署名）はこの方法では検証できず、証明書を作成したローカル セキュリティ チームによってインポート元が示されます。
vCloud Director のセキュリティ
VMware, Inc. 17
プライベート（内部）エンドポイント用の証明書
プライベート ネットワーク上のエンドポイント（パブリック ネットワークに公開されておらず、一般に、データベースや 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-tool certificates <options>
詳細については、『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 のセキュリティ
VMware, Inc. 23
その後、vCloud Director を再起動します。
これで、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. クラウド ポッドのネットワーク
また、ここでは、IDS IPS/、SIEM、構成管理、パッチ管理、脆弱性管理、アンチウイルス、GRC 管理システムなどの一般的なデータセンター セキュリティ テクノロジーが、vCloud Director とその関連システムおよび vSphere とその関連システムに加え、それらをサポートするネットワークとストレージ インフラストラクチャにも適用されると想定しています。これらのシステムの詳細も、本書の範囲外です。
vCloud Director のセキュリティ
VMware, Inc. 32
リソースの共有および分離の推奨事項
通常、サービス プロバイダはコンピューティング リソース、ストレージ リソース、およびネットワーク リソースを複数のテナント組織で共有できます。システムは、ハイパーバイザーおよび vCloud Director ソフトウェア スタックにおいて、抽象化による分離およびセキュアなエンジニアリング プラクティスを適用します。
テナント組織は、単一のプロバイダ仮想データセンターを通じて、所有していないリソースに影響を与えずに、ある
いはそのことを認識することもなく、基盤となるリソース プール、データストア、および公開済みの外部ネットワークを共有しています。vApp のストレージとランタイム リースの適切な管理、vApp の割り当て容量、リソースを大量に使用する処理の制限、および組織仮想データセンター割り当てモデルにより、1 つのテナントが他のテナントのサービスを意図的であるか否かに関わらず、拒否することはありません。たとえば、きわめて堅実な設定では、すべ
ての組織仮想データセンターを予約プール割り当てモデルの管理下に置き、リソースのオーバー コミットを絶対に行わないように設定します。このドキュメントではオプションについてすべては解説しませんが、いくつかの点につい
て以降のサブセクションで説明します。
セキュリティ ドメインとプロバイダ仮想データセンター
ソフトウェアで適切な分離と適切な組織構成を行っていても、特定のコンピューティング リソース、ネットワーク リソース、またはストレージ リソースで異なるワークロードを実行したりまたは格納することをテナント組織で避ける場合があります。これによってシステム全体をセキュリティの高い環境に強化することにはなりませんが、クラウド
を複数のセキュリティ ドメインに分割することが必要になります。このような対応が必要なワークロードの具体的な例は、次のとおりです。
n 定められた場所での格納および処理が必要な、プライバシー関連法の対象となるデータ。
n 国や組織が所有するデータおよびリソースのうち、クラウドの分離を信頼していても慎重を期すためや多層防御
の問題として、その仮想データセンターでは特定の他のテナント（競合企業など）と共有できないリソース。
これらのようなシナリオでは、プロバイダ仮想データセンターを使用して、リソース プール、ネットワーク、およびデータストアを複数の「セキュリティ ドメイン」にセグメント化する必要があります。これによって、同様の問題を持つ vApp をグループ化（または隔離）できます。たとえば、あるプロバイダ仮想データセンターが特定の国のデータを格納、処理するように、明確に識別することが考えられます。
リソース プール
単一のプロバイダ仮想データセンターに、基盤となる vSphere インフラストラクチャによって提供される CPU およびメモリ リソースを集約したリソース プールを複数置くことができます。機密保持と整合性を維持するために、異なるリソース プールにまたがる各組織を分割する必要はありません。しかし、可用性の観点からこれを実行することが妥当である場合もあります。このリソース管理の問題には、組織仮想データセンターの割り当てモデル、予想ワー
クロード、これらの組織に適用される割り当て容量と制限、プロバイダが追加のコンピューティング リソースをオンラインにできる速度が関係します。このガイドでは、各種のリソース割り当てモデルの定義や、それが各組織による
リソース プールの利用にどのように影響するかについては説明しません。複数の組織によって使用されるプールに属するリソースのオーバー コミットメントを許可すると、1 つまたは複数の組織でサービス品質の低下を起こすリスクが必ず発生するということを述べるにとどめます。サービス レベルを適切に監視することは、1 つの組織でサービス拒否が発生することを回避するために不可欠ですが、この目標を満たすために具体的に組織の分離を示唆するもので
はありません。
vCloud Director のセキュリティ
VMware, Inc. 33
共有リソースの共有使用量の制限
デフォルト設定では、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 にパケットを送信できます。これを防ぐには、サービス プロバイダが NSX 分散ファイアウォールと分散論理ルーティングを使用して、単一の外部ネットワーク上の複数のテナントからのトラフィックを分離します。『VMware vCloud® for ServiceProviders Architecture Toolkit™ (vCAT-SP)』のNSX 分散ファイアウォールと論理ルーティングを参照してください。
vCloud Director のセキュリティ
VMware, Inc. 34
複数のテナントによって所有されている組織仮想データセンター ネットワークは、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 管理ネットワークからのみアクセスできるように設定されている場合、データストアを共有するリスクは、コンピューティング リソースの場合と同様、可用性に限定されます。ある組織のストレージが予想よりも多くなり、他の組織が使用できるストレージの量が制限される事態も考
えられます。これは特に、組織が従量課金制割り当てモデルとデフォルトの「無制限のストレージ」設定を使用して
いる場合に発生しがちです。このため、データストアを共有する場合は、ストレージの制限を設定し、可能であれば
シン プロビジョニングを有効にして、ストレージ使用量を慎重に監視します。また、「共有リソースの共有使用量の制限」で説明しているとおり、ストレージ リースを慎重に管理する必要があります。一方、データストアを共有しない場合は、各組織が選択したストレージ プロファイルに沿って、適切に専用のストレージを設定します。この場合、必要としない組織に割り当てることによってストレージを無駄にする可能性があります。
vSphere データストア オブジェクトは、VMDK が保存される論理ボリュームです。vSphere 管理者は、これらのデータストアの作成元となった物理ストレージ システムを確認できます。これには、vCloud Director 管理者やテナントには提供されない権限が必要です。vApp を作成、アップロードするテナント ユーザーは単純に、使用している組織仮想データセンター内で使用可能なストレージ プロファイルのいずれかで vApp の VMDK を格納します。
vCloud Director のセキュリティ
VMware, Inc. 35
このため、仮想マシンの VMDK によって使用される以外のストレージは、それらのストレージ システムへのネットワーク接続がない限り、その仮想マシンでは一切認識されません。そのような接続は設定しないことをお勧めします。
プロバイダがネットワーク サービスとして vApp に外部ストレージへのアクセスを提供する場合もありますが、それはクラウドをバッキングする vSphere ホストに割り当てられる LUN とは別にする必要があります。
同様に、テナント組織では、その組織の仮想データセンターで使用可能なストレージ プロファイルしか認識されず、その表示も vCloud Director 抽象化に限定されます。システムのデータストアを参照することはできません。表示されるのは、カタログで公開されているもの、または管理する vApp で使用されているものだけです。組織仮想データセンターのストレージ プロファイルでデータストアを共有していない場合、組織が他の組織のストレージに影響を与えることはありません（ストレージ I/O のネットワーク バンド幅がきわめて大きくなった場合を除く）。影響を与えたとしても、上記の制限事項と抽象化により、組織間の適切な分離は確保されます。vCloud Director 管理者は、特定のデータストアで vSphere Storage I/O Control を有効にして、テナントが膨大な量のストレージ I/O バンド幅を使用できないように制限できます。『vCloud Director管理者ガイド』のプロバイダ仮想データセンターでの StorageI/O Control サポートの構成を参照してください。
ユーザー アカウントの管理ユーザーおよび認証情報の管理は、すべてのシステムのセキュリティにとって重要です。vCloud Director では、システムに対する認証とシステム内の認証のすべてにユーザー名とパスワードが使用されるため、ユーザーとパスワー
ドの管理のベスト プラクティスを実践することが重要です。
このトピックでは、vCloud Director におけるユーザーとパスワードの管理の機能と制限事項について記載し、それら制約のもとでユーザーとパスワードをセキュアに管理および使用するための推奨事項を紹介します。
ローカル ユーザー アカウントの制限
vCloud Director には、vCloud Director データベースで作成および保持されるユーザー アカウントに対する自己完結型の ID プロバイダが用意されています。これらのアカウントは、本来データベースへのネットワーク アクセスを制限するよう構成されているシステムでは脆弱ではありませんが（「管理ネットワークの構成」を参照）、PCI データセキュリティ基準などの特定の業種で要求されるパスワードの種類を管理する機能は提供されません。ブルート フォース アタックを防ぐために、ローカル アカウントをパスワード再試行の制限およびアカウント ロックアウトのルールの対象にする必要があります。
サービス プロバイダは、システム管理者のローカル アカウントを引き続き使用するメリットとリスクを慎重に評価する必要があります。ローカル システム管理者アカウントを設定する場合は、組織のクラウド URL で認証されるソース IP アドレスを慎重に制御する必要があります。この ID プロバイダをシステム管理者アカウントに使用しないようにするか、少なくとも使用を制限することを強く推奨します。
vCloud Director の新規インストールでは、ローカル システム管理者アカウントが作成されます。vCloud Directorのデフォルトの構成では、少なくとも 1 つのシステム管理者アカウントをローカルにしておく必要があります。システム組織で vSphere SSO サービス (SAML IDP) または LDAP を使用できるようにしているサービス プロバイダは、次の手順を実行して、vCloud Director をローカル システム管理者アカウントなしで動作するように構成できます。
1 vSphere SSO サービス (SAML IDP) または LDAP でシステム管理者用のアカウントを 1 つ以上作成します。
2 それらのアカウントをシステム組織にインポートします。
vCloud Director のセキュリティ
VMware, Inc. 36
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 組織管理者
vCloud Director のセキュリティ
VMware, Inc. 38
n カタログ作成者
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 認証サーバを設定する必要があります。正当なアプリケーションのホワイト リストを使用して検証する必要があります（使用可能な場合）。
vCloud Director のセキュリティ
VMware, Inc. 39
LDAP
vCloud Director 統合 ID プロバイダは、いくつかの一般的な LDAP サービスをサポートしています。
サポートされている 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 ConfigurationGuide 』(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 およびこのファイルのアクセス制御によって保護されます。ファイルやフォルダの権限を変更しないで
ください。
VMware, Inc. 42
n vCloud Director サーバへの物理的アクセスおよび論理的アクセスを厳重に制限し、ログインする必要があるユーザーにのみ、必要最低限のレベルでアクセス権限を付与してください。アクセス制限には、sudo による
root アカウントの使用制限やその他のベスト プラクティスも関係します。サーバのバックアップは厳重に保護したうえで、バックアップとは別に管理されているキーを使用して暗号化する必要があります。
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 により提供されるポート転送ルールが実現します。上記またはその他のルールは、展開するネットワーク ファイアウォールによって既定で適用されることがあります。特定の構成手順と既定の機能については、ファイアウォールのド
キュメントを参照してください。
vCloud Director のセキュリティ
VMware, Inc. 43
n 多層防御原則では、JMX（ポート 8999/TCP）および JMS（ポート 61611/TCP および 61616/TCP）が、セルが接続された DMZ を保護するネットワーク ファイアウォールでブロックされる必要があります。
n WAF またはロード バランサの背後にあるマルチセル クラウド用に、パブリック ウェブ URL、パブリック コンソール プロキシ アドレス、およびパブリック REST API ベース URL を設定します。
n ウェブ アプリケーション ファイアウォール (WAF) は、vCloud Director セルの前に展開する必要があります。
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 をグループ化（または隔離）できます。
vCloud Director のセキュリティ
VMware, Inc. 44
n 1 つ以上のテナント組織によって使用されるプール内のリソースのオーバーコミットメントを許可する場合は、他のテナントでのサービス品質が低下するリスクが発生します。「ノイジー ネイバー」のテナントによるサービス拒否を防ぐため、サービス レベルを適切に管理することが不可欠ですが、これを達成するためにテナントを個々のリソース プールへと分離することはセキュリティ上は必要ではありません。
n 外部ネットワークは、組織仮想データセンターのネットワークによって使用されることがあります。これは、2台の異なる vApp やそのネットワークを接続したり、vApp ネットワークをエンタープライズ データセンターの方向へ接続するために使用されます。これらのような場合、外部ネットワークは複数のテナント組織間で共有す
べきではありません。
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 の遵守を確認したりするのにも役立ちます。
vCloud Director のセキュリティ
VMware, Inc. 45
n Syslog サーバはインストール中に設定できます。TLS を有効にした Syslog インフラストラクチャを使用することをお勧めします。Syslog サーバにログをエクスポートすることを推奨する理由は複数あります。重要なイベントが必ずログに記録されるように、冗長性を備えた syslog サーバ構成をお勧めします。セキュリティ運用組
織と IT 運用組織は、中央集約と診断ログの管理の点でもメリットを享受できます。ログ サイズや保持する古いログ ファイルの件数を制御するために、logrotate などの方法を使用することを推奨します。
n 診断ログおよび Jetty 要求ログに対応できる十分な空きディスク容量があることを確認します。集約ログは、ログ ファイルの合計サイズである 400MB に達してファイルがローテーションされ削除される際に、重要な診断情報を失わないようにします。
n vCloud Director に接続したり、使用されたりするその他のシステムが作成する監査ログも、監査プロセスに組み込む必要があります。これらには、NSX、vCloud Director データベース、vCenter Server、および vSphereホストからのログが含まれます。
n 初期のローカル システム管理者のアカウント作成後、すべてのシステム管理者アカウントを LDAP や vSphereSSO サービスなどの 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