皆様、こんにちは。
ネットワールド SEの目木です。
Part2～Part3では検証用の環境としてWorkspaceの展開までを行いました。
ここからは展開されたWorkspaceへ実際に接続してみたいと思います。
この接続についてですが、接続方式としては2通りあります。1つはクライアントアプリを利用する方法、もう1つはWebブラウザから利用する方法です。
今回はこの2通りの方法にて、Workpsaceの展開後から接続までの流れを確認していきたいと思います。
クライアントアプリによる接続
Amazon Workspaces のクライアントアプリについては"Amazon Workspaces Client Download"といった文言で検索すれば確認できるかと思います。
こちらのサイトから自身のデバイスのOSにあったモジュールを入手しましょう。
今回のテスト端末はWindows 10 OSですので、Windows 64bit Clientを選択しています。
インストール自体はシンプルなものになりますので、利用者の範囲、インストールパスを指定してサクッとインストールしてしまいます。
インストールが完了した後はアプリケーションを起動してみましょう。
最初に表示された画面では、登録コードを求められます。
この確認コードですが、Workspaceの詳細設定を確認していると見つけることができます。以下はWorkspaceの"ユーザを招待する"アクションを開いた画面です。
手順２の内容として確認コードが記載されていますので、こちらの文字列をクライアントアプリ側で入力すればよいことになります。
さて、こちらの招待メールを見たときに、この内容をAWSからユーザに送ってくれないの？という疑問をもたれた方もおられるかと思います。
これは色々と検証した後に分かったことではあるのですが、招待メールに関してはマネージドのディレクトリサービスを使用していた場合ではWorkspace構成後に自動的に送信されるようです。
よってAD Connectorを使用している今回の環境ではメールの自動送信はできず、管理者が別途メール等で接続に必要な情報を伝える必要があります。
シンプルな方法としては上記のメール文面をコピーして利用者に送信する方法が考えられます。ただし、この方法では大量に新規Workspaceを展開した際の、管理負荷が気になります。
あらためて接続時の手順に立ち返ってみましょう。実際にメールに書かれている情報はクライアントアプリの入手方法と登録コードです。
クライアントアプリについては共通のWebサイトですので、紹介自体は簡単でしょう。
登録コードについてはディレクトリごとに値が決まっていますので、ディレクトリ構成を役割、割り当て部署など、その用途に合わせて設計しておくと、展開時の負荷を減らすことができそうです。
Amazon Workspacesの設計においてはこのディレクトリの構成が非常に重要な要素となるかと思いますので、色々なパターンを検討して導入環境における最適解を探して頂ければと思います。
前置きが少し長くなりましたが、クライアントアプリ起動後に登録コードを入力するとアカウント認証の画面が表示されます。
最終的にこの認証が通った後は、Workspaceへのセッションが開始されます。
この時Workspaceが停止している場合は、自動的にWorkspaceの起動が実行され、サービス起動後に画面転送が実行されます。
以上で接続までの手順については完了ですが、せっかくですので少しWorkspaceの中身についても見ていきましょう。
まず、ストレージディスクについてはエクスプローラ上ではUserProfile（Dドライブ）のみが表示されます。
上のスクリーンショットからもシステムディスクであるCドライブは見えていません。ただし、これは非表示化されているだけですので、追加でCドライブへアプリケーションをインストールすることは可能です。
また、Dドライブには標準でユーザプロファイルが保存されるように定義されており、このあたりも普段使用するPCの構成とは異なっているように思います。
次にネットワーク構成を見てみましょう。
ネットワーク接続を確認すると2つのネットワークにつながっていることが分かります。
1つはAWSマネージドネットワークにつながっており、画面情報の転送に利用されます。もう1つはユーザ管理のVPCにつながっており、デフォルトゲートウェイはこちらを優先するようにメトリックで調整されています。
パート1で画面転送に関する課金が発生しないと記述しましたが、これも画面転送の通信についてはユーザ側のVPCを通ることがないから、と理解して問題ないと思います。
最後にユーザの権限についてみてみましょう。
これはローカルのAdministratorsグループを表示した画面ですが、このグループにWorkspaceへ紐づけたユーザアカウントが所属していることが分かります。これは展開時に設定されたもので、デフォルトで利用ユーザには管理者権限が付与されていることがわかります。
これを制限したい場合は、ディレクトリの設定から管理者権限を付与しないように展開前に設定しておく必要があります。
以上でWorkspaceの細かい仕様についても確認できました。
続けてWebブラウザによる接続手順も見ていきましょう。
WebAccessの手順
Amazon WorkspacesではWebブラウザを使用してWorkspaceに接続することもできます。
Webブラウザで接続するのであればクライアントアプリの導入が必要ないため、導入に際するハードルが低くなります。その一方でクリップボードのリダイレクトがサポートされないなど機能制限も存在するため、WebAccessの利用には一長一短が存在することは理解しておく必要があります。
加えて、Webブラウザのサポートについては以下の通りとなっています。
| プロトコルバンドル | サポートしているWebブラウザ |
| WSP | Microsoft Edge (最新の 3 つのメジャーバージョン) Google Chrome (最新の 3 つのメジャーバージョン) Mozilla Firefox (最新の 3 つのメジャーバージョン) macOS 版 Apple Safari (最新の 3 つのメジャーバージョン) |
| PCoIP | Google Chrome 55 以降 Firefox 52 以降 |
では、実際に操作している画面を見ていきましょう。
まず、Webブラウザによる接続はデフォルトで許可されていませんので、これをディレクトリの設定にて許可する必要があります。
許可するプラットフォームとして"Web Access"を有効として、起動済みのWorkspaceについては再起動して適用します。
この状態で、以下のサイトにアクセスして登録コードをもとに先ほどのディレクトリへアクセスします。
us-west-2.webclient.amazonworkspaces.com
あとはクライアントアプリと同じようにユーザ／パスワードを入力して完了となります。
Workspaceに接続されたあとはアプリで接続した際と同じ要領で使用できます。
なお、今回使用したWorkspaceはWSPプロトコル用のバンドルで展開していましたが、PCoIPプロトコル用のバンドルについてもサポートされています。
今回のまとめ
まずは、今回の内容を振り返っておきましょう。
- Amazon Workspacesの接続方式は"クライアントアプリ"あるいは"Webブラウザ"から選択
- 機能、品質、サポート上の最適解はWSｐプロトコル＋クライアントアプリ接続
- 接続時にはユーザ認証のほかに登録コードが必要
おおまかにはこれらの内容を理解したうえで、どのようなユーザ端末を使って接続するのか想定しつつWorkspaceを展開するとよさそうです。
管理者としてバンドルのカスタムも可能とはいえ、そもそものコンセプトがユーザに管理権限を委任する方向性のようですので、今回のようにデフォルトのまま構成してしまうと思わぬ脆弱性が生まれる可能性が高いように思えました。
そのあたりを管理者側でどこまで制御できるのか、という疑問については今後の調査課題となりそうです。
最後に
Part1より4つの記事にわたってAmazon Workspacesの検証について報告してきた本レポートですが、本パートにて一区切りとなります。
昨今のVDIソリューション（特にDaaS型）はどうしてもユーザ数がある程度の数を超えないとコストメリットが見いだせないという実情があるのですが、Amazon Workspacesのように1台から手軽にかつ最低限の操作で展開できるソリューションにはニーズが存在していると思っています。
その一方で、個人向けVDIとしての特色が色濃く出ていることから管理面での要件にどこまで応えることができるのかは更なる調査が必要でしょう。
弊社としては、最適な設計を目指すために今後も本ソリューションに関する調査を進めてまいりますので、定期的に上がる検証レポートに今後もご期待頂けますと幸いです。
今回も最後まで読んで頂きありがとうございました。
