Citrixの新セキュリティソリューション deviceTrust 検証レポート

皆様、こんにちは。

ネットワールド SEの目木です。

今回はCitrix DaaSの新機能であるdeviceTrust機能について検証していきたいと思います。

deviceTrustは2025年に入ってから追加された機能で、Hybrid-Multi Cloud（HMC）ライセンス以上のエディションにて使用することができます。

まずは、その機能の概要から見ていきましょう。

機能概要

deviceTrustは、継続的なコンテキストアクセスにより、コンプライアンスに準拠したデバイスとアプリケーションのみを企業データにアクセスさせることができるセキュリティソリューションになります。今までもCitrixではNetScalerあるいはSAML連携によるIDP側の定義によって認証時のセキュリティを強化することはできましたが、deviceTrustによってセッション形成後のセキュリティを強化することが可能になります。

動作としてはログイン時の検査、およびログイン後のステータス変更を検査し、その動作をもとに定義されたアクションを実行する、というシンプルなものになります。

この機能を利用するにあたっては、以下のコンポーネントが必要となります。

deviceTrust Agent：
VDI/SBCなどユーザが利用する環境にインストール
VDI/SBCの検査を行うほか、自動アクションによって不正な利用を防止する
deviceTrust Client Extension：
接続元となる端末にインストール
上記Agent上における自動アクションのトリガーとして利用するクライアント端末の情報収集を行う
deviecTrust Console：
検査項目およびアクションの定義作成を行うためのコンソール
ここで定義したルールをGPOあるいはテキストファイルとしてAgentに展開する

以下の機能紹介ページから引用した画像が、製品の導入イメージとして分かりやすいかと思います。

www.citrix.com

この絵の構造は、以下のとおりです。

図の左側にあるユーザ端末にはWorkspace AppとdeviceTrust Client Extensionをインストール
真ん中にあるVDI/SBCにはVirtual Delivery Agent（VDA）とdeviceTrust Agentをインストール
deviceTrust Consoleは何かしらのサーバにインストール
deviceTrust ConsoleからGPOやファイルにアクションポリシーを落とし込んでVDI/SBCへと展開
ユーザ端末のコンテキスト情報は画面転送プロトコルの中でやり取り

おおよそ上記の内容のみで構成されるシンプルな機能です。

インストール要件

各コンポーネントのOSサポート状況は以下のサイトから確認できます。

docs.devicetrust.com

上記サイトの情報を一覧化すると以下の通りになります。

現状、Agentの対応がWindows OSのみサポート、Client ExtensionについてはWindows OS、iOS、macOS、Ubuntuなどがサポートされています。

CitrixとしてはLinux VDAやWorkspace App for Android / ChromeOSなどにも対応している関係から、Citrix Virtual Apps and Desktopsとして構成できていてもdeviceTrustが動作しないパターンが存在しますので、その点は注意が必要かと思います。

また、deviceTrust Agent / Client Extension / Consoleのいずれにおいても、Citrixへの統合後のEOLはCitrix側のライフサイクルに準拠するとのことですので、AgentおよびConsoleはコアコンポーネント（VDA／DDCなど）と同等、Client ExtensionはWorkspace Appと同等ということになります。

インストール手順

まず、インストールモジュールについてですが、最新のバージョン(25.3)についてはCitrix Virtual Apps and Desktopsのインストールモジュールに統合されていますのでそこから取得していきます。

現状では、CRバージョンであるCitrix Virtual Apps and Desktops 2503にのみ統合されている状況でしたので、最新バージョンで導入する場合はこちらのモジュールをダウンロードします。
それ以前のバージョンについては、deviceTrustのサイトからダウンロードが可能です。

Download - deviceTRUST Documentation

まず、deviceTrust Agent / ConsoleのインストーラはCitrix Virtual Apps / DesktopsのISOファイルを展開して取得します。

次に、deviceTrust Client Extensionのインストーラについては、現状統合が不完全のようでしたので、deviceTrustのWebサイトから1つ前のバージョン(23.1)を取得しました。

Download Windows Client - deviceTRUST

これ以降のバージョンについては今後リリースされるWorkspace Appに同梱されるため単独でのインストールは不要になるもようです。

それぞれのインストールについてですが、特に選択する項目もないのでウィザードに従って進めることで完了します。

※Client Extensionのみ下位バージョンではありますが、サポート上問題ないことは確認しております。

なお、deviceTrust AgentについてはすでにVDAのインストールウィザードに統合されていましたので、そちらのインストールオプションから選択してインストールを実施することも可能です。

Citrix Policyの調整

deviceTrustではdeviceTrsut AgentとdeviceTrust Client Extension 間で通信を行う必要があります。Citrixと連携する際はICA内でこの通信を通すため、Citrix Policyにて事前に仮想チャネルを許可しておきます。

ポリシー：仮想チャネルの許可リスト

値：DEVTRST,C:\Program Files\Citrix\Agent\Bin\dtagent.exe

今回はこちらのポリシーをデリバリーグループを対象として適用しました。

deviceTrust Consoleによるアクションポリシーの作成

deviceTrustの動作ポリシーはGPO、ローカルポリシー、テキストファイルのいずれかにて作成して配布します。少し触ってみた感じですとローカルポリシーによる作成の場合は複数のポリシーを構成することが難しそうなので、GPOかテキストファイルで作成して管理するのがよいかと思います。
今回の検証ではVDIがドメイン管理化にあることもあり、GPOベースで動作ポリシーを構成していきます。

まず、deviceTrust Consoleを起動して、[New Policy]を選択します。

今回作成する動作ポリシーをGPO上に保存します。
画面右上の[Save]ボタンをクリックして[Sace as...]を選択します。

[Save Group Policy]を選択します。

グループポリシーのオブジェクト一覧が表示されますので、新規にポリシーを作成するか、あるいは事前に準備しておいたポリシーを選択します。

これで以降、手順内で保存した情報がGPOのポリシーに書き込まれていきます。

続けて新規のポリシーに対して、ライセンス情報を入力します。

右上の[Licensed by Citrix]をクリックして、ライセンスの設定画面を開き、ライセンスファイル内の文字列を入力して[OK]をクリックします。

Home画面に戻った際に右上の文字が[Licensed]へと変更されていればライセンスの適用は完了となります。

ここで適用したライセンスは、その適用対象となるユーザアカウントを指定することもできます。
[Settings]→[Licensing]と展開して[Users]タブを選択します。

Managed Usersは割り当て対象アカウント、Unmanaged Usersは割り当てを行わないアカウントを指しています。特にVDI/SBCの管理者、ヘルプデスクなど制限をかけると運用業務に支障が出るユーザアカウントを対象に、Unmanaged Usersの設定を利用するとよいでしょう。

なお、最後に[Do not manage local administrators]と書かれた項目もありますので、こちらを有効としてローカル管理者アカウントを一括で除外対象とすることもできます。

ライセンスの設定が追加されてポリシー情報が変更されましたので、画面上部の[Save <ポリシー名>]をクリックして情報を保存しておきます。

以降、特に記載はしませんが、設定を追加するたびに情報は保存しています。

ライセンスもインポートできましたので、ここからは動作ポリシーを構成していくわけですが、一から構成するのはハードルも高いため最初はテンプレートをもとにポリシーの構造を確認していきます。

テンプレートのインポートは画面右上の[Shared]ボタンから進めます。

[Import Template]を選択します。

テンプレートカテゴリが表示されます。

今回は試しに[Compliance Check]の[Operating System]をインポートしています。

インポートが完了すると、作成されたコンテンツのリストが表示されます。

これにてテンプレートのインポートが完了しました。
続けて、コンテキストの中身を見ていくために[Operating System]をクリックして設定値を展開します。

フロー形式にて詳細が表示されました。
このコンテキストでは各段の検査を通して、最終的に返す値（Value）が定義されています。検査内容としては以下のとおりです。

2段目：VDI内のdeviceTrust Agentがユーザ端末のdeviceTrust Client Extensionを認識できているか
3段目：ユーザ端末のOSが指定したOSであるか
4段目：ユーザ端末のOSバージョンが指定したバージョンよりも新しいものか

ちなみに、コンテキストのタイトルに「Local」とある場合はdeviceTrust Agentから、「Remote」とある場合はdeviceTrust Client Extensionが検査対象となります。

項目が多いためすべては開きませんが、3段目左端のWindows OSの検出であれば、以下のような条件で設定がされています。

上図の検査フローを通して最終的にこのコンテキストの値が返されます。

具体的には、ユーザ端末内にdeviceTrust Client Extensionがインストールされていなければデフォルト値である[Unavailable]、その下のユーザ端末のOSの種類およびバージョンについての検査をクリアできれば[Supported OS]、クリアできなければ[Unsupported OS]（すいません、こちらは右端の項目が見切れています）というように、このコンテキストでは3パターンの値が返される可能性があるわけです。

これが、このテンプレートで行う検査の詳細となります。

次にアクション設定についても見ていきましょう。

作成されたアクションは2種類あり[-Enforcement: Very High]、[-Notification: High]としてアクション名と優先度が設定されています。
より優先度が高いEnforcementから見てみます。

こちらも順番に内容を展開していくとわかるのですが、1段目の緑の欄がトリガー、2段目の青紫の欄がコンテキストの検査、3段目の白の欄が実行アクションを定義していました。

まず、1段目のトリガーについては2段目の検査を実行するタイミングを表します。
下図のようにチェックボックス方式で選択するのですが、今回のアクションでは左列はログインおよび再接続時に実行、右列はログイン、再接続およびコンテキストが変化した際に実行されるものとなっています。

次に2段目のコンテキストについては、先ほど確認した[Operating System]と値が設定されています。左列は[Equals Unavailable]、右列は[Equals Unsupported OS]ということでそれぞれ返された値と合致した場合に、その下のアクションを実行します。

3段目のアクションについては[Deny Access]とある通り、どちらのパターンでもセッションを拒否する内容となっています。

そのうえで、アクセスを拒否した際にどのようなメッセージを表示するのか、サインアウトやセッションの切断までの待ち時間といったアクション実行時の動作について定義されています。

なお、このメッセージについては別途メッセージ一覧で定義されたものから引用するようになっており、今回のフローではコンテキストで[Unavailable]の場合と、[Unsupported]の場合で異なるメッセージが設定されていました。適切なエラーメッセージを表示するためにフローを分けたと考えてもよさそうです。