2016年8月27日土曜日

NSX for vShield Endpointの各社サポート状況がKBに掲載されています

NSX for vSphere 6.2.4により、NSX for vShield Endpointなるライセンスが発表されたことを記載しました。
この新しい形のエージェントレスのウイルス対策には、当然ながらアンチウイルスソフトベンダーの協力なしに、なし得ない機能でもあります。

さて、ではアンチウイルスベンダーの対応状況はというと、KB2110078で公開されています。

ここには、実に興味深い内容が掲載されています。


NSX 6.2.4 vShield Endpoint Certification Planner
PARTNERPRODUCTNSX 6.2.4 CERTIFICATION TARGET
BitDefenderGravityZone SVE version 6.1September, 2016
Trend MicroDeep Security 9.6 (Version 7314 or higher)September, 2016
Intel Security (McAfee)MOVE 4.0October, 2016
ESETESET Virtualization Security for VMware NSX v1.5November, 2016
KasperskyKaspersky Security for Virtualization 4.0Q4 - 2016
SymantecDCS 6.7Q1 - 2017
SophosSophos Anti-Virus for VMware vShieldContact Vendor

(参考)
https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2110078

これを見ると、DeepSecurity9.6も、今すぐにはNSX for vShield Endpointには対応していないようですね。
興味深いのは、ESETの掲載があることです。ESETもついにエージェントレス版を提供するようですね...。






NSX for vSphere 6.2.4の登場とfor vShield Endpointエディションが無償で登場

NSX6.2.3がリリースされましたが、一部不具合があり、一度撤回されましたが、昨日ついに、NSX for vSphere(NSX-v) 6.2.4がリリースされました。
これは、NSX-v 6.2.3の改修版となり機能としては、6.2.4と変わりがありません。

しかし、6.2.3のリリースノートには、かなり大きな変更がたくさん加わっています。

その1つは、「VXLAN」の通信ポートです。
NSX-vは、VXLANのRFCに正式に認定される前に利用してた8472/UDPを利用していましたが、NSX-v 6.2.4から、4712/UDPに変更となります。
これは、大変大きな変更です。これには、Hardware VTEPが正式にサポートされることによる仕様に変更だと思われます。

さらに驚くべきことは、「vShield Endpoint」のサポート終了とNSX for vShield Endpointのリリースです。

vShield Endpointは、vCloud Network and Security(vCSN)の1機能として提供され、ESXi上にいる仮想マシンに対して、エージェントレスなウイルス対策機能を提供する製品でした。

vSphere5.1のリリースとともに、vShield Endpointに関しては、vSphereの1機能として提供されるようになり、vSphere Essentiauls Plus以上を保有していれば、無償で利用できるライセンスとなりました。

ここrで、vShield Endpointは、vCNSファミリーではなく、vSphereファミリーとなったのですが、vShield Endpointを利用するためには、vShield Managerが必要であることから、vShieldのファミリーであると認識をされていました。
ただ、vCNSが、2016年9月でサポートが終了されることから、vShield Endpointはどうなるのかという話が出ており、VMwareは、KB2128156で、
「VMware vShield Endpoint as part of vSphere 6.0 will follow its lifecycle with current end of general support occurring on March 12, 2020. For more information, see the VMware Lifecycle Product Matrix.」と記載しており、vShield Endpointは、vSphere6のサポート期限に紐づくものであると記載をしていました。(このKBはすでに削除されています)

当時のKB


(参考)VMware vCloud Networking and Security Manager support of vShield Endpoint (2128156)
http://web.archive.org/web/20150909045150/http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2128156 

しかし、最近出たKBを見ると状況が変わっており、vShield Endpointは、vShieldファミリーと同じく、2016年9月にサポートを終了すると発表がなされております。

(参考)Implementation of VMware vShield Endpoint beyond vCloud Networking and Security End of Availability (EOA) (2110078)
https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2110078

これにより、新しく登場したのが、「NSX for vShield Endpoint」になります。
vSphere Essentials Plus以上のライセンスを保有しているユーザーは、みなNSX Managerをダウンロードする権利を有し、「NSX-v for vShield Endpoint」ライセンスが自動的に付与されることとなります。

(参考)vSphere Essentiauls Plusライセンス保有ユーザーでもMyVMwareからNSX関連のバイナリがダウンロード可能


このNSX for vShield Endpoint ライセンスでは、カーネルモジュールで動作するVXLANや分散ファイアーウォール機能などは利用できず(モジュールインストールをしようとするおとライセンスが不足している旨のメッセージが表示される)、Guest Introspectionが展開できるだけという機能制限がかかっています。(もちろん、NSX for Standard以上のライセンスを適用すればそのロックは解除されます)

今まで、vShield Endpointを利用していたユーザーさんは、2016/9/19までに、NSX for vShield Endpointに乗り換える必要があります。

NSX Managerは、メモリーが16GB必要であることも注意点ですので、既存のvShield Endpointユーザーさんは、リソースの空き具合を含めて今一度確認をして以降に備えましょう。(といっても時間があまりありませんが)







2016年8月21日日曜日

vSphere6から誕生したPSCとSSOについておさらい

vSphere6が出て1年半が経とうとしています。
もう、この時期から新規構築でvSphere5.xを選択するケースは少なくなってきたかと思います。


vSphere6では、様々なところでアーキテクチャーの変更が加えられておりますが、構築の時点で一番に気が付くのは、vCenter Server Applianceのデプロイ方法だと思います。
昔は、OVFをぽいっとするだけで終わっていたのですが、今では少々面倒はWebのウィザードを経由してデプロイをする必要があります。

一方で、Windows版のvCenter Serverは、Embeded DBのアーキテクチャーが、PostgreSQLに変わったぐらいで、あまり変化がないように思いますが、プラットフォームに関係なく大きくアーキテクチャーが変わっているところがあります。

それが、「PSC」の存在です。
PSCは、Platform Service Controllerという名前で、vSphere5.5まであった、SSOの後継となります。

その昔、vSphere5.0までは、ADが必須という条件がありましたが、vSphere側にSSO機能を持つことで、AD必須という条件が取れたことは、非常に大きなアップデートだっだように思います。
(もともとV4.xやV5.0のvCenter Serverでも非サポートながら、Workgroupでのイストールで動作していた実績がありますが)

PSCは、従来のSSOと違い、
  • Single Sign-On (SSO)
  • ライセンス
  • 認証局
  • 証明書ストア
  • サービス(製品)登録
の機能を保有しています。

さらに、このPSCと今までのvCenter Serverは、独立した仮想アプライアンス(仮想マシン)として展開することも可能です。

ここで重要になるのは、vCenter ServerとPSCは、サーバーをまたいで通信をする構成になっているということです。
ということは、PSCとvCenter Serverで、きちんと名前引きができるDNSを構築しておかなければならないという事情があります。

PSCとvCenter Serverを同一の構成で作成すれば、同じホスト名だから問題ないよねと思うケースもあるかもしれませんが、NSX ManagerやvShield Managerなど、PSCを経由して、vCenter Serverと接続する連携製品は、それら連携製品がPSCとvCenter Serverの両方のホスト名を名前引きできないと、ただしく接続できません。

ここで、ポイントです。
vCenter Serverをインストールする際に、PSCを共にインストールをしますが、PSCをインストールする際に定義されたホスト名が、そのままPSCで構築されるSSOのURLの一部として利用されます。

Windows Serverにインストールする際、あらかじめホスト名にドメインサフィックスを入れてないと、そのホスト名だけがSSOのURLとして利用されるため、NSX ManagerのようなほかのアプライアンスからSSOにアクセスする際、FQDNになっていないため、SSOサーバーにたどり着けず、認証に失敗するケースがあります。(検索ドメインを定義おり、DNS名で名前引きができれば通信は可能です)


上記から、vSphere Web Clientにアクセスするとまず、PSCにSAML認証されていることがわかります。

vCenter Serverをインストールする際は、
  • DNSサーバーを構築し、vCenter Server、PSC(別立てする時)の正引き、逆引きをかならず設定する
  • Windows版の場合、vCenter Serverのインストール前に、DNSドメインサフィックスを設定し、ホスト名をFQDNの形式で設定をする
の2つを忘れないことが、とりあえずvCenter Server入ったけど、外部製品との連携ができないとか、vSphere Web Clientが正しく開けないといったトラブルを防ぐことができます。



2016年8月12日金曜日

NSX fro vSphere 6.2.3のリリース中止

NSX for vSphere 6.2.3(NSX-v)がリリースされましたが、現在、バイナリのダウンロードは中止されています。

NSX-v 6.2.3では、VXLANのポート番号がRFCに準じた「4789/UDP」(以前まではドラフト時代の8472/UDPで動作)に変更になるなど、マイナーバージョンアップのバージョンナンバーですが、かなり大きな変更が入っていました。(これはHW-VTEPの絡みでしょうね)

さて、このNSX-v 6.2.3ですが、上記のとおり現在はバイナリがダウンロードできません。その理由は、リリースノートにも記載されていますが「KB:2146227」が要因のようです。

要は、分散ファイアーウォールでSecurity Groupで定義した仮想マシンが分散ファイアーウォール処理されたときに、その仮想マシンがvMotionしてしまうと、通信が一切できなくなるという問題です。

分散ファイアーウォールとvMotionとは、NSXとvSphereのそれぞれのいいところを使うと発生する問題であり、実業務に影響が出る問題と思われます。
そのため、この問題が解決するまで6.2.3のバイナリは提供中止になったようです。

NSX-v 6.2.2は提供されていますので、現況では6.2.2を利用するしかなさそうですね。

KBは、日本語版も新たにリリースされましたので併せて紹介しておきます。

(参考)
NSX 6.2.3 をインストールまたはこれにアップグレードした後に SG を使用する DFW ルールが仮想マシンに正しく適用されない (KB:2146401)
http://kb.vmware.com/kb/2146401





ゼロクライアントからHorizon Viewに接続できなくなった

Horizon View 6.2.2から採用された「TLS1.0」のデフォルト無効化。
これが、Tera1チップを搭載したゼロクライアントでは、どうやら問題になるようで、私の利用する環境では、以下のような画面が出てゼロクライアントからVDIの環境にログインできなくなりました。

「セッションネゴシエーションに失敗しました。ゼロクライアントはホストのセッションネゴシエーションの暗号設定と互換性がない可能性があります。」とのこと。

TLS1.2等で接続をしてくれればよいのですが、どうやらTLS1.0で接続をしているようでそれが仇になっているようです。

さて、この場合の対策ですが、Connection Serverにレジストリで「TLS1.0」を許可することで対応可能です。(TLS1.0を許可することが事態はセキュリティを低くすることになるので、お勧めではありません)LANなど閉じられた環境下で引き続きTera1のゼロクラを利用したい場合はこの手法を使うことで回避できます。

キーの場所:HKLM\Software\Teradici\SecurityGateway
キー名称: SSLProtocol
型: REG_SZ
値: tls1.2:tls1.1:tls1.0

値に、「tls1.0」が入っているのがポイントです。

これで、tera1チップを積んだゼロクライアントでも、接続可能になります。

(参考)Configuring security protocols on components to connect the View Client with desktops (2130798)
https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2130798