では、少々実践に基づいた仕様を考えてみましょう。
Q.仮想マシンを配信するIISと管理サーバーのIISを分けることは可能か？
A.ドキュメントを読む限り記載はありませんが、tarファイルのダウンロード先は、完全に手動入力であることと、IISからダウンロード状況等を取得することは困難ですので、およそ可能だと思います。ただし、VMware Playerがダウンロードできる仮想マシン等の情報をもらうときは、FLEXサーバーから情報をもらいますので。FLEXサーバーと通信できておく必要があると思います。
Q.VMPlayerを稼働させるPCの日付と時刻を送らせれば、仮想マシンの期限に関係なく利用できるのでは？
A.仮想マシンを稼働させるホストOSの時間及びゲストOSの時間は、期限の対象としてみていません。FLEXサーバーと通信をして、FLEXサーバー経由で日付と時刻を取得しているようです。 そのため、クライアント側で日付をいじっても仮想マシンの有効期限には影響しません。
（期限ギリギリの日から、オフラインで運用をすれば、オフラインで許可された日数まで継続利用可能となる仕様ですので、設計時に注意が必要です）
ちなみに、FLEXサーバーの日付を未来にして仮想マシンの有効期限切れにさせた後、FLEXサーバーの日付を元に戻して、ゲストの仮想マシンを起動しても、仮想マシンへのアクセスが無効とメッセージが出て起動しませんでした。一度何らかのトリガーでロックされるとそれはロック状態で、管理者オペレーションが無い限りロック状態が続くようです。
Q.仮想マシンのVMX（仮想マシン構成ファイル）をメモ帳で変更したら何でもできてしまうのでは？
A.マスター仮想マシンを作成した後に、暗号化という作業をしますが、この際VMXファイルも暗号化され、読めなくなってしまいます。
↓暗号化されたVMX
Q.VMware Playerで新しい仮想マシンを作成して、VMDKファイルをマウントしたらUSBやクリップノードの制限を外した仮想マシンで動作できてしまうのでは？
A.ここもちゃんと考えられておりまして、ディスクが暗号化されている場合暗号化されたVMXファイルとセットでないと動作しません。
↓違う仮想マシンでマウントしようとするとこんなメッセージが表示されます
Q.展開した仮想マシンを、ロック後、再度Reactivedしても、仮想マシンが起動しない。
A.これ、私自身はまりました。どうやら、一度仮想マシンをロックし、そのロックをReactiveする際は、有効期限を前のポリシーで設定された有効期限より未来でないと起動しません。
期限切れと共生ロックの時はメッセージこそ違うものの、内部アーキテクチャーは同じようで設定されていたポリシーの日付で有効期限が切れたと認識をしているようです。
Q.仮想マシンを展開した後に、有効期限変更するため、Policiesで、該当するポリシーを変更したが、反映されない。
A.一度展開した仮想マシンのポリシーについては、Virtual Machinesのメニューから該当する仮想マシンを選択で、Editボタンから個別にポリシーを変更します。
強制ロックは、 複数選択で一括ロックができるようですが、日付変更は、1台ずつ仮想マシンを選択しないと駄目なようです。
言い換えると、Policiesでの設定はテンプレートで有り、仮想マシンに展開後はテンプレートとは紐付いておらず、仮想マシン個別で設定情報が保有されます。
残念ながら、現行プールやグルーピングする機能が無いため、大量展開をしている場合は、作業に結構手間がかかると思います。
↓複数選択は、ロックしかできない。期限を変更するよりも一度対象台数を全台ロックにして、 Reactivedでポリシーを再設定した方が早いかもしれません。
運用上の注意は見えてきました。
しかし、実は結構（かなり）考慮が必要なポイントを見つけてしまいました。
それは、ネットワークの設定です。FLEXから配信された仮想マシンの設定で、セキュリティに影響が出る項目はロックがかかっており、仮想マシンのマスターを作成した際にセットしたパスワードがないと設定変更ができないのですが、ネットワークアダプタの動作については、稼働させる端末の状況によって自由に変更できます。
BYODだから、稼働させる本体PCの所有者はユーザーですので、ユーザー側のネットワーク環境に合わせられるようにしてるんだといわれればばそれまでの話しなのですが...。
そもそも、VMware PlayerやFusionは、ホストOSのネットワークを経由してゲストOSが通信します。
勘のいい方はわかってきたかと思うのですが、ゲストOSに何も通信的な制限等を入れていなければ、ゲストOSからCIFSやNFSでホストOSに入れてしまいます。ホストOSの権限はユーザーにあるわけですから、ホストOS上で、共有フォルダを用意しておけば、いくらクリップボードやドラッグ＆ドロップによるファイルのコピーを阻止してもネットワーク経由でごそっとファイルがコピーできてしまいます。
ゲストOSから、Windowsネットワーククライアントのサービスを外してしまったとしても、ftpやwebdavなど何かしのプロトコルで、ホストOSとゲストOS間で通信ができてしまうので、パーソナルファイアーウォールによっぽど細かなポリシーを書かない限り、厳しいと思います。
（そもそもWindowsのファイルサーバーとアクセスできなくなってしまうので、これは非現実的でしょう）
仮に、Windows Firewallで、会社のファイルサーバーIP以外をアクセスできないようにしても、ホストOSを一時的にそのファイルサーバーのIPと同じIPを付与すれば、アクセス可能になってしまいます。
ここの部分は運用を考えておかないと、盲点になってしまうような気がします。
ちなみに、このFLEXの機能は、完全にmirageと分離しております。わざわざmirageとセットでFLEXとして販売しているのは、FLEXの機能だけだと仮想マシンの配信機能だけですが、実際の運用の場合、オフラインで仮想マシンを個人PCで動作させるため、バックアップ等のポリシーが適用しにくくなりますので、こういった環境の場合、mirageの定期的なファイルバックアップは非常に有益だと思います。
ということで、FLEXな回は取り急ぎこれで終わりです。
また、希望（or 追加質問用件）があれば調べてみます。
0 件のコメント:
コメントを投稿