#5 「仮想デスクトップごとに使えるSaaSを制御する」をやってみた

IIJでは、デジタルワークプレース実現の様々なベストプラクティスを公開しています。中でもご要望の多いパターンを、エンジニアが実際に試してみる本企画。今回はゼロトラストの課題を解決する「仮想デスクトップにデバイス制御の条件を付ける」方法を取り上げます。詳しい解説も聞きました。

目次

1. 仮想デスクトップにも求められるクラウド接続制御
2. 仮想デスクトップの設定配布の仕組み
3. 実験の準備
4. 設定してみる
5. 動作を確認
6. まとめと解説

仮想デスクトップにも求められるクラウド接続制御

今回やってみるのは「仮想デスクトップにデバイス制御の条件を付ける方法」ですね。具体的にはどんなことでしょうか?

今や、業務にクラウドやSaaSを使うのは当たり前になってきました。FAT端末では「デバイスごとにSaaSの接続先を制御したい」というご要望がよくありますが、今回はその仮想デスクトップ版です。「仮想デスクトップごとに利用できるSaaSを制限する」ということをやってみます。

FAT端末と仮想デスクトップでは違いがあるのでしょうか?

今回の制御にはAzure ADの条件付きアクセスを使うのですが、仮想デスクトップで実装するには少しコツがあります。その辺りをじっくり解説したいと思います。

＜今回実現したい構成＞ 仮想デスクトップ単位で利用できるSaaSを制御する

仮想デスクトップの設定配布の仕組み

まず、仮想デスクトップの設定はどのような仕組みで配布されるのでしょうか。

今回の実験には、IIJの仮想デスクトップサービスを利用します。
IIJ仮想デスクトップサービス/Citrix Cloud for Azure Virtual Desktopは、「Azure Virtual Desktop（旧称：Windows Virtual Desktop）」と「Citrix Cloud」を組み合わせたクラウド型のサービスです。

IIJの仮想デスクトップサービスでは、「マスターイメージ」と呼ばれるイメージ展開用のマシンに必要なアプリケーションのインストールや設定を行い、それをもとにリンククローン方式で、ユーザが利用する仮想デスクトップを作ります。これによって、どのユーザがログインしてもマスターイメージと同じ仮想デスクトップ環境を使うことができます。再起動をすると仮想デスクトップ環境はマスターイメージの状態に戻りますので、障害や不具合の復旧にも対応しやすいといったメリットがあります。

また、Active Directory（AD）のグループポリシーや仮想デスクトップ独自のポリシー（Citrixポリシー）を作って、マシンに設定を配布することもできます。利用ユーザによって設定を一部変えたい場合には、こちらを使うケースもあります。

実験の準備

実験環境を準備しましょう。まず、仮想デスクトップというデバイス単位で条件を設定するために、Azure ADへのデバイス登録作業が必要です。仮想デスクトップ環境はマスターイメージから複製されます。仮想デスクトップ環境のコンピューターオブジェクトはマスターイメージとは独立したコンピューターオブジェクトとしてマシン起動のたびに作成されるので、それらをAzure ADへ同期させます。

また、仮想デスクトップはオンプレミスADには参加が必須です。そこで、Hybrid Azure AD Join（以下、HAADJ）によって、仮想デスクトップをオンプレミスADとAzure ADの両方に参加させます。

• お客様環境内にAzure AD Connectを用意する。
• お客様ADドメインコントローラーにある「ユーザアカウント」と、サービス設備ADドメインコントローラーにある「仮想デスクトップサービスのコンピューターアカウント」をAzue AD上に同期させる。
• 条件付きアクセスの設定（後述）は、お客様環境内にあるAzure ADに対して行う（認証はお客様Azure ADで行う）。

仮想デスクトップサービスのコンピューターアカウントがAzure AD上に同期されると、下のように表示されます。

（クリックすると拡大表示します）

HAADJはこれだけでは完了せず、Azure ADに登録されたユーザでログインすることで初めて完了します。以上で、仮想デスクトップ単位で条件付きアクセスを設定する準備が整いました。

設定してみる

いよいよ、Azure ADの管理画面から条件付きアクセスを設定します。今回は以下の設定をしました。

1. 割り当て：「ユーザーとグループ」を対象
   対象のアプリとして「Offce 365」と「Microsoft Teams」を選択
2. 条件：「デバイスフィルター」を選択して、フィルター条件を設定
3. 許可：「アクセスのブロック」を選択

1. 割り当て
（クリックすると拡大表示します）

今回は対象のアプリとして「Office 365（Office 365のポータル画面）」と「Teams」を設定しました。これ以外にも、Azure AD上で選択・登録できるものであれば対象にすることができます。

2. 条件
（クリックすると拡大表示します）

デバイスフィルターでは、コンピューター名に特定の文字列（今回は“vdi02”）を含むものを対象とします。IIJの仮想デスクトップサービスでは「vdi<2桁の管理番号><数字>」というコンピューター名を持ちますので、これをフィルター条件にしました。

3. 許可

最後の許可は、アクセスをブロックするように設定しました。デバイスフィルターで定義した法則のコンピューター名を持つ仮想デスクトップは、アクセスがブロックされるようにしています。

動作を確認

実際に、デバイスフィルターの対象となるコンピューター名を持つ仮想デスクトップ環境（vdi02006）と、対象外となる仮想デスクトップ環境（vdi06001）からSaaSへアクセスしてみます。想定のとおり、フィルター対象の仮想デスクトップからはOffice 365やTeamsに接続できません。フィルター対象外の仮想デスクトップ環境からは、アクセスが許可されるようになりました。どちらの環境も同じユーザで接続しており、Azure ADによって仮想デスクトップ単位で制御されていることが分かります。

【Office 365/Teamsにアクセスできない仮想デスクトップ】
※コンピューター名：vdi02006のため、デバイスフィルター対象となり、アクセスできない
（クリックすると拡大表示します）

【Office 365/Teamsにアクセスできる仮想デスクトップ】
※コンピューター名：vdi06001のため、デバイスフィルター対象外となり、アクセスできる
（クリックすると拡大表示します）

コンピューター名「vdi」の後の2桁の管理番号は、親となるマスターイメージを表します。どのマスターイメージから展開されたかによって利用できるSaaSを変える、といった要件にも対応できることが確認できました。

まとめと解説

仮想デスクトップ環境によって、Office 365へ接続できたり、できなかったりしましたね。他のアプリでも同様に設定できますか？

はい。Azure ADにあらかじめ用意されているMicrosoft系サービス以外にも、エンタープライズアプリという形で、その他のSaaSアプリケーションを独自に登録して選択できます。設定の柔軟性は高いと思います。 また、今回はデバイスフィルター設定を使っていますが、これも必須ではありません。環境に合わせて条件設定を変えていくこともできます。

仮想デスクトップというと、セキュリティの高い環境の中に閉じて使うイメージがありました。SaaSへの接続も制御できると分かって新鮮でした。

働き方が変化していく中で、仮想デスクトップをテレワークに活用する企業も増えていますからね。今後もお客様のニーズは変化していくと思います。今回のように、仮想デスクトップサービスと別のサービスを組み合わせてやりたいことを実現するケースが増えていくかもしれませんね。

仮想デスクトップサービスの選び方
ガイドブックを差し上げます！

最適な仮想デスクトップサービスの選び方
（PDF：17ページ）

Windows 365を徹底調査！

特徴、価格、Windows365とAzure Virtual Desktopを比較

ダウンロード（無料）

この記事を読んだらチェックしたいサービス

Citrix CloudとAVDを組み合わせたDaaSをフルマネージドでご提供

IIJ仮想デスクトップサービス/Citrix Cloud for Azure Virtual Desktop

DL資料あり

ライセンス調達から構築・運用・サポート窓口までワンストップでご提供

企業データを守るリモートアクセス
「ゼロトラストモデル」で安心・快適に

IIJフレックスモビリティサービス/ZTNA

DL資料あり

これからのテレワークに必要なのは “企業データを守る”リモートアクセス