もう8ヶ月も前の話になりますが、ラボ環境にCitrix社のデスクトップ配信環境を作り、そこにYubiOn Portalを導入する、という記事を公開しました。別の開発作業などもあって、しばらくこういった仮想デスクトップ環境に対する実験を試せていなかったのですが、今回、AWSのWorkSpacesを触る機会がありましたので、そこにYubiOn Portalを導入してみたいと思います。
■ 構成
構成としては、ごくごく一般的な「Amazon WorkSpaces試してみた」という環境と言えるのではないかと思います。
前回はラボ環境に必要なものをすべて構築したため、記事の内容以上にやる事が多かった印象がありますが、クラウドサービスはこういう時に便利ですね。便利さの反面、うっかりで高額請求が来てしまうのではないか、とドキドキもするのです。今回、極力無料でやろうとしてみましたが、そのあたりのお金の話については最後に余談としてご説明します。
■ WorkSpacesの構築
Amazon WorkSpacesを単純に試してみる、という事であれば、AWSの案内に従って必要な設定をしていけば大体出来るのではないかと思います。
①ディレクトリの構築
まずはWorkSpacesを配置するための「ディレクトリ」を作ります。これはWindowsでいうところのActiveDirectoryにあたる部分です。
試す程度であれば、「Simple AD」タイプで問題無いかと思います。純粋なMicrosoft製のADではなく、「Samba 4 Active Directory Compatible Server」という互換サーバを用いているそうです。
「AWS Managed Microsoft AD」は純粋なMicrosoft WindowsServer2019を用いて稼働しているものですので、Microsoft提供の機能を十全に使いたいのであればこちらを使用する事になると思います。
「AD Connector」はちょっと別物で、既存のイントラ内などのADと連携するための選択肢です。社内ローカルで使っていたものをクラウドに移行する、といった用途で使われるのではないかと思います。
次に、ディレクトリ情報を入力していきます。
お試しなので、サイズはスモールです。組織名やDNS名、NetBIOS名などはあまり深く考えず、通常のAD構築と同様に設定しておきます。管理者パスワードについては忘れるとADとしての管理が出来なくなりますので、厳重に取り扱ってください。
次に、ネットワーク周りの設定をしていきます。
こちらについても、画面の説明に従ってWorkSpacesを使う仮想ネットワークを作成すれば問題ありません。ただし、サブネットをプライベートサブネットとして作る場合、この画面の説明に従ってVPCとサブネット2つを作るだけだと、その空間からインターネットにアクセスできません。この辺りについては後ほど説明しますので、今はVPCとプライベートサブネット2つを作って割り当てておきます。
（後ほどパブリックサブネットを切りますので、VPC内に追加のサブネットが切れる余裕を残しておいてください）
ここまで設定したら、「確認と作成」画面で内容を確認して、ディレクトリを作成します。
AWSではよくある事ですが、作成、とクリックをしてから、バックグラウンドで作成が行われるため、しばらく待つ必要があります。
ステータスが「アクティブ」になれば作成完了です。最後に、このディレクトリをWorkSpacesで使用するために、「登録」をする必要があります。（ディレクトリを選択して、「アクション」→「登録」）
先ほど設定したサブネットをもう一回指定して、登録を行います。
②WorkSpacesの作成
次に、WorkSpacesを作成していきます。「WorkSpaces」という名前ですが、挙動を見る限りでは、1つのWorkSpacesはすなわち一つの仮想マシンと考えて問題無いかと思います。この点に限らずですが、AWSを使う場合、AWSの独自用語が具体的には何を指しているのか、というのは自分なりに理解しておく事が大事だと思います。
一度環境を作成し終わってからスクリーンショットを撮っているので、上図では既にWorkSpacesが存在しますが、上記画面から「WorkSpacesの作成」ボタンでWorkSpacesを作成します。
作成したディレクトリを選択して「次へ」。
ユーザーを新たに作成する場合、「追加ユーザーの作成」を押して追加画面に移動します。既にディレクトリに存在するユーザーを割り当てる場合（一度作ったWorkSpacesを消して同じユーザーで作り直す等）はここでユーザーを作る必要はありません。
ユーザー情報を入力します。5人まで作成可能ですが、ここでは一人だけ設定しておいて、「次へ」をクリックします。
ユーザーの作成が終わったら、自動的に「ユーザーの特定」画面に進みます。この画面は少々わかりづらいのですが、新しく作る1台のWorkSpacesで指定したユーザーがログインできるようになる、ではなく、指定したユーザー数分だけWorkSpacesを作成する、という意味合いになります。今回は1台だけ作成したいので、先ほど作成したユーザーのみ選択して「次へ」をクリックします。
続いて、「バンドルを選択」というステップに進みます。ここで言う「バンドル」はWorkSpacesのベースとなるテンプレートのようなものになります。一番大きな違いはOSですが、その他Officeの有無、クライアントプロトコル（実際にリモート操作する際の通信プロトコル）などの差異があります。
今回は、「Standard with Windows 10 (Server 2019 based)」で、クライアントプロトコルが「WSP」のものを選択します。クライアントプロトコルについては後ほど改めて説明します。
続いて、実行モードなどの設定を行います。画面の説明の通り、常に仮想マシンとして電源が入っている（AlwaysOn）か、使われていなければ自動停止する（AutoStop）か、ですが、実験用であればAutoStopで問題無いかと思います。タグについては必要に応じて設定等行ってください。
続いて、カスタマイズオプションの設定があります。実運用では暗号化等はきっちり行うべきですし、ユーザーボリュームなどは使用用途によって適切なものを選択すべきですが、実験ですのでデフォルトのままとします。
最後に設定内容の確認があります。問題なさそうであれば、そのまま「WorkSpacesの作成」をクリックします。
作成を行うと、例によってバックグラウンドでの作成処理が開始されます。このWorkSpacesの作成には数十分程度時間が掛かりますので、のんびり待ってください。作成が完了すると、「追加ユーザーの作成」の際に指定したメールアドレス宛に、「あなた用のWorkSpacesが出来たよ」というメールが飛んできます。
メール内容に従って、ユーザーパスワードの設定を行い、クライアントアプリのインストールを行って接続してみます。
上記のようにWorkSpacesに接続出来たら、まずは「WorkSpacesを動かしてみる」というところまでは終了かと思います。
■ネットワーク周りの設定
とりあえずWorkSpacesで立てた仮想PCへのアクセスは出来るようになりましたが、そのWorkSpaces上でプリインストールのFirefoxを起動しても、インターネットには接続できません。現在、概要図の左のプライベート部分が出来上がった状態になっていて、自宅LANなどのイメージに置き換えて考えると「家の中でLANを組んでみた」といった状態になっています。ですので、続いて右のパブリック部分、自宅LANのイメージで言うとインターネット接続ルーターにあたる部分を作成していきます。
（一般的な家庭向けインターネット接続ルーターはLAN側のゲートウェイやDHCPサーバーなども入っていますので、厳密にはイメージとは少々違いますが…）
基本的に、全てAWS管理コンソールの「VPC」の画面で作成を行っていきます。
③インターネットゲートウェイの作成・VPCへのアタッチ
まずはインターネットゲートウェイを作成します。ここはあまり難しい事はなく、名前を決めて作成するだけです。
作成が完了したら、既に存在するVPCに紐づけます。アクションメニューから「VPCにアタッチ」を選択して、アタッチを行います。
④パブリックサブネットの作成
インターネット側からアクセスするためのサブネットを作成します。このサブネット内にはNATゲートウェイを配置します。パブリックサブネット自体はプライベートサブネットと作り方は変わりません。VPCの範囲内で、既に存在するプライベートサブネットとは異なるIPv4 CIDRブロックを指定して作成します。
⑤NATゲートウェイの作成
NATゲートウェイの管理画面から、「NATゲートウェイを作成」をクリックして作成画面を表示します。サブネットとして先ほど作成したパブリックサブネットを指定し、接続タイプはパブリック、Elastic IPを割り当てておきます。
⑥パブリック用のルートテーブルを作成
一通りの仮想機器は揃いましたが、このままではインターネットに出るためにどういう経路を取れば良いか、という情報が設定されていません。現在、3つのサブネットで同一のデフォルトで作成されるルートテーブルが使用されているかと思いますが、プライベート側とパブリック側で異なるルート情報を指定する必要がありますので、パブリック用のルートテーブルを一つ作成します。ルートテーブル管理画面から「ルートテーブルを作成」を選択します。
名前は好きに付けて、現在使っているVPCを指定するだけです。
⑦パブリックサブネットのルートテーブル関連付けの設定
サブネット管理画面からパブリックサブネットを選択し、「ルートテーブル」のタブを開きます。
「ルートテーブルの関連付けを編集」をクリックし、ルートテーブルIDの選択で、先ほど作ったパブリック用のルートテーブルを設定して、「保存」をクリックします。
⑧パブリックルートテーブルのルーティング設定
ルートテーブル管理画面から、作成したパブリックルートテーブルを選択して「ルート」タブを開き、「ルートを編集」をクリックします。
デフォルトで、VPCのサブネットの範囲ならlocalに行く、というルーティングが設定されていると思いますが、追加で「0.0.0.0/0」であればインターネットゲートウェイに行く、というルートを追加し、「変更を保存」をクリックします。
⑨プライベートルートテーブルのルーティング設定
前項と同様に、今度はプライベートサブネットに紐づいているデフォルトのルートテーブルのルートを編集します。
こちらは、「0.0.0.0/0」であればNATゲートウェイに行く、というルートを追加します。
ここまでの設定で、WorkSpacesからインターネットへのアクセスが出来るようになるかと思います。もう一度WorkSpacesに接続し、Firefoxでインターネットにアクセスしてみてください。
■ YubiOn Portalの導入・ログオン部での利用
作成したWorkSpacesにYubiOn Portalを導入します。Citrix製品での導入時の要点の使いまわしですが、仮想環境、特にWindowsへの自動ログオンの仕組みのある仮想環境ではほぼ共通で以下の点に気を付ける必要があります。
インストールは、WorkSpacesごとに行う必要があります。
現状では、アカウントとYubiKeyの割り当てもWorkSpacesごとに行う必要があります。
ポリシーにて、強制YubiKeyログオンを有効にする必要があります。
有効にしていない場合、WorkSpaces側の認証の仕組みでWindowsログオン部分がスキップされてしまいます。
キャッシュログオン、YubiKeyを抜いた際のスクリーンロック等は利用できません。
どちらもYubiKeyとUSB通信が必要になるため、直接USBが接続されない環境では利用できません。
複数のWorkSpacesがある場合、それらのマシンは異なるSIDになっている必要があります。
YubiOn Portalでは、SIDを基準に各端末を識別しており、同一SID端末が複数ある状況はサポートしておりません。
セットアップ・設定が終了した後、WorkSpacesのクライアントからアクセスします。
WorkSpacesのログイン情報を入力してサインインを行うと、WorkSpacesの画面上でYubiOn PortalのWindowsログオン画面が表示されます。
こちらで、パスワード+YubiKeyの入力を行う事でログオンする事が出来るようになります。WorkSpaces単体ではWindowsへのログオン部分が省略されていましたが、YubiOn Portalを導入する事によって、デスクトップ表示時の二要素認証を強制する事が出来るようになります。
■ まとめ
Amazon WorkSpacesの環境に対してYubiOn Portalを導入する方法は以上の通りとなります。
前回のCitrix製品への導入の時と同様、大規模に利用したい場合のセットアップなどの面での課題はあるかと思います。現状では作成されたWorkSpacesのSIDなどをリストアップして頂き、キッティング導入オプションなどを利用して導入して頂くやり方になるかと思いますが、イメージとして作成したYubiOn Portal導入済みのWorkSpacesから自動的に登録するような方法を模索しております。
以下、3つほど余談がありますので、合わせて書いておきます。
■ 余談①：WorkSpacesのクライアントプロトコルについて
WorkSpacesでは、クライアントプロトコルとして「PCoIP」と「WSP」があります。どちらもWorkSpaces端末の入出力（映像・音声・マウス操作・キー入力など）の転送を行うプロトコルですが、その出自は大きく異なります。
①PCoIP（PC over IP）
カナダのTeradici社（2021年にHP社が買収）が開発したプロトコルです。Amazon WorkSpacesの他、VMware社のVMware Horizonなどでも採用されています。
②WSP
Amazonが独自に開発したプロトコルです。「WorkSpaces Streaming Protocol」の略称です。
両者の比較はAWSのヘルプが詳しいです。
WorkSpacesが二つのプロトコルをサポートしている理由は推測になりますが、最初はPCoIPを採用していたものの、不安定なネットワーク環境などの対応やカメラサポートなどを行うためにプロトコル自体の見直しをする必要があり、別途WSPを開発した、という流れなのではないかと思います。そういった経緯を想定すると、今後はWorkSpacesにおいてはWSPの方が主流になっていくのではないか、と私は思います。
なお、今回の手順ではWSPを使う形で記述しましたが、PCoIPを用いてもYubiOn Portal自体は正常動作します。ただし、PCoIPを用いた場合、WorkSpacesクライアントで認証情報を入力した後、Windowsのログオン画面が表示されるまで1分程度待たされる、という問題があります。恐らくですが、PCoIP接続の場合、WorkSpacesクライアントから送られた認証情報を使ってWindowsが正式にログオンする(か、タイムアウトする)まで待機する、という仕組みがあるのではないかと思われます。
■ 余談②：WorkSpacesにおけるFIDO Logonの動作について
余談①と関連する話になりますが、PCoIPプロトコルを用いた場合、USBの転送という仕組みが利用可能です。
なお、実際に利用するためには上記ヘルプの内容の他、ADのグループポリシーでのUSB転送許可設定が必要です。(今回はそこは割愛します)
こちらを用いた場合に、FIDO Logonが利用できるかについても実験を行ってみました。結論としては、一応利用可能ではあります。ただ、いくつか問題点があり、今のところ実用的では無さそうだ、と考えています。
余談①で挙げた問題点(接続まで1分程度待たされる)がFIDO Logonでも同様である。
正式にAmazonがサポートしているデバイスがYubiKeyのみであり、FIDO2認証のキー選択の自由度が失われている。
環境依存とは思われるが、私が試した際はデバイスの抜き差し・WorkSpacesへの再接続などを行った後、WorkSpacesクライアントがデバイスを認識できなくなる現象があった。（サポート対象であるYubiKeyも含む）
技術的な話をすれば、通常ミリ秒単位でのやり取りが行われるUSBデバイス通信を、インターネットを介した100ミリ秒単位の回線で転送するのはなかなか難しい話なのかもしれません。また、FIDOの仕組み自体は関連する機器が認証者の手元にある事がセキュリティ的にも必要な要件である、といった考え方もあります。実際、FIDO2がサポートするUSB・NFC・BLEは本来いずれも遠隔地に通信を飛ばすような仕組みではありません。USBデバイスの転送といった手段の是非も含め、DaaSでの認証の在り方というのは今後も業界として考えていくべき事項なのかもしれません。
■ 余談③：AWS料金の請求について
お試しなので出来れば無料で、というのが本音ですが、現時点で請求は以下のようになっています。
「バンドル」の設定で「無料利用枠の対象」の物を選んでいましたので、「Software」の分は無料になっていますが、インスタンスの動作やディレクトリのユーザー登録などは無料では無い、という話なのではないかと思われます。また、上記画像内には記述されていませんが、WorkSpaces以外の部分(VPCなど)についても請求されているのではないかと思います。