Apple Configurator 2 から Apple Business Manager へデバイス登録して Microsoft Intune と連携登録する

概要

Microsoft Intune で iPhoneiPad を管理しているとどうしても Apple Business Manager (ABM) との連携が必要となってきます。
中々個人で持ったり、企業でも持てるテナントの制限があったりで検証できない方も多いのではないでしょうか。
今回は macOS 上の Apple Configurator 2 からビジネスストアで購入されていないABM未登録デバイスを登録して管理してみます。

事前準備

事前に以下の準備が必要になります。

Apple Configurator 2 の準備

事前準備が完了したら Apple Configurator 2 の設定をしていきます。

ブループリントの作成

管理対象のデバイスへ投入する設定のテンプレートを作成します。
画面は作成済みのものが表示されていますが、新規の場合は左下の「新規」ボタンをクリックします。
作成済みのものを編集するには対照を右クリックして「準備」をクリックします。

設定ウィンドウが表示されてきたら以下のようにチェックを入れます。

  • Apple School Manager または Apple Business Manager に追加
  • バイスを監視 (デフォルトでチェックが入ります)
  • バイスにほかのコンピュータとのペアリングを許可 (不要であれば外してOK)

チェックを入れ終わったら「次へ」をクリックします。

サーバーは新規作成を選びます。

名称を入力して、URLにはIntune側に登録した Apple Configurator プロファイルのプロファイルからURLをコピーして貼り付けます。

作成済みの Apple Configurator プロファイルを開いてプロファイルのエクスポートからURLを取得します。

証明書の画面はそのまま「次へ」をクリックします。

組織は登録済みの組織を選択します。

iOS設定アシスタントで表示する設定項目を絞ることが出来るので、不要な画面のチェックを外します。

ネットワークプロファイルを配布できます。
Wi-FiやSIMのプロファイルが必要なときは登録しておきます。
「準備」をクリックして設定完了です。

ブループリントの画面に戻るので右下の「完了」をクリックします。
USBケーブルで iPhone を接続すると以下のように画面に表示されるので、右クリックメニューの「適用」から先ほど作成したブループリントの定義を選択します。

ブループリントを適用するか確認が出るので「適用」をクリックします。

使用許諾契約の画面が表示されるので「同意する」をクリックします。

以下のように進捗状況が表示されるので完了まで待ちます。

登録完了するとABM側に以下のように登録されます。
Apple Configurator と記載のあるものが Apple Configurator 2 からデバイス登録したデバイスとなります。

iPhone側でキッティングを始めると以下のような画面が表示されるので、ライセンス割り当て済みのMicrosoft 365 アカウントを使ってサインインします。

以上で Apple Business Manager へ手動登録し、かつ Microsoft Intune へデバイス登録することができました。
色々はまりポイントはありますが検証してみてください。

上記でエラーで失敗したケース

何度か失敗したのでその時の原因を….

バイスのアクティベート中にエラーが出る

ネットワーク通信ができずアクティベート出来ていないようで、タイムアウトになっている模様。
SIMなしや格安SIMを載せている場合は、iOSのセットアップが起動した段階で画面をすすめてWi-Fi設定することで回避できました。

ブループリントでアプリをインストールさせようとするとエラーが出る

こちら原因がわからず…特定のアプリをブループリント時にインストールしようとするとダウンロードエラーが発生する。
対象のアプリをブループリント時ではなく、Intuneから配布する形にして回避しました。

アクティベートの時の画面を撮り忘れましたが、以下はアプリインストールに失敗したときに出たエラー画面です。

環境やiOSのバージョンによっても発生するエラーが異なりますのでご注意くださいませ。

Azure AD のグループ管理について

Azure AD のグループ

Azure AD の中心的な機能といえばアカウントやグループの管理ですよね。
グループは大きく分けて2つあります。

  • セキュリティグループ
  • Microsoft 365 グループ

また、セキュリティグループ、Microsoft 365 グループそれぞれ動的グループというものが作れて条件に合ったユーザー/デバイスを動的にグループに所属させると言う機能も提供されています。

セキュリティグループ

セキュリティグループは以下のように分類されます。

  • セキュリティグループ(メールアドレスなし)
    • オンプレミスADと同期する場合、メールアドレスが設定されていないとこの形式になる
  • メールアドレスが有効なセキュリティグループ
    • クラウドで作成する場合はExchange Onlineの管理画面での操作が必要
    • クラウドで作成した場合、後からメールアドレスを有効にすることが出来ない(オンプレADは可能)

また、グループに割り当てられるものはユーザーとデバイスがあり、メンバーシップは以下のように分類されます。
割り当て済みは手動でユーザーもしくはデバイスを登録できます。 デバイスグループは Azure AD Join / Azure AD Registered デバイスを登録でき、主に Microsoft Intune の利用時に必要となります。

  • 割り当て済み
  • 動的ユーザー
  • 動的デバイス

他のMicrosoft 365 プロダクトで権限など管理する場合、メールアドレスが有効ではないセキュリティグループでは権限が当てられなかったりするので、ユーザーを割り当てる場合はメールアドレスを有効にするか Microsoft 365 グループを選択することをお勧めします。

Microsoft 365 グループ

メンバーに共有メールボックス、カレンダー、ファイル、SharePoint サイトなどへのアクセスを付与できます。
グループ メンバーにはユーザーのみ指定可能です。
Teamsのチームを作成する時にはこのグループが作成されます。
部署毎のチームを作成する場合は、動的グループとして Microsoft 365 グループとして作成して動的に所属部署のユーザーアカウントを入れることも可能です。

Microsoft 365 グループのメンバーシップの種類は以下が選択可能です。

  • 割り当て済み
  • 動的ユーザー

動的ユーザーグループ

条件を指定して動的にユーザーをグループメンバーとして登録できます。
ルールとして指定できるプロパティは以下です。

  • accountEnabled
  • objectId
  • displayName
  • city
  • companyName
  • country
  • department
  • facsimileTelephoneNumber
  • givenName
  • employeeId
  • jobTitle
  • mail
  • mailNickname
  • mobile
  • passwordPolicies
  • physicalDeliveryOfficeName
  • postalCode
  • perferredLanguage
  • sipProxyAddress
  • state
  • streetAddress
  • surname
  • telephoneNumber
  • usageLocation
  • userPrincipalName
  • userType
  • onPremisesSecurityIdentifier
  • otherMails
  • proxyAddresses
  • assignedPlans
  • extensionAttribute1 〜 15

動的デバイスグループ

条件を指定して動的にデバイスをグループメンバーとして登録できます。
ルールとして指定できるプロパティは以下です。

  • accountEnabled
  • objectId
  • displayName
  • isRooted
  • deviceOSType
  • deviceOSVersion
  • deviceCategory
  • deviceManufacturer
  • deviceModel
  • deviceOwnership
  • enrollmentProfileName
  • managementType
  • organizationalUnit
  • deviceId
  • devicePhysicallds
  • systemLabels

例えば、Windowsだけを指定したデバイスグループを作る場合は以下のように指定します。

項目 パラメータ
プロパティ deviceOSType
演算子 Equals
Windows

Windows 11 だけのグループを作りたければ、上記条件に加えて以下をand条件で指定することで作成できます。

項目 パラメータ
プロパティ deviceOSVersion
演算子 Starts With
10.0.22000

AndroidiPhoneといった指定も出来ますので、色々お試しください。

グループへの Azure AD ロールの割り当て

セキュリティ、Microsoft 365 それぞれのグループには Azure AD ロールの割り当てが可能です。
これは例えば情シス部門へ Microsoft Intune の管理権限を割り振りたいという場合に、個人個人のアカウントではなく部署グループにロール割り当てをすることで、部署異動時の管理工数の削減が可能です。
この機能はグループ作成時にのみ有効化できるため、作成時にあらかじめロール割り当てを使うか決めておく必要があります。

f:id:tsukatoh:20220304183829p:plain

グループへのライセンス割り当て

Microsoft 365 / Office 365 ライセンスなどはグループに対して割り当てすることが可能です。
こちらも部署毎にE3だったりE5だったりと別れている場合は、各部署グループにあらかじめライセンス割り当てをしておくことで部署異動時に動的にライセンスをユーザーへ割り当てることができます。

f:id:tsukatoh:20220304183657p:plain

まとめ

Microsoft Azure を使う場合でも、Microsoft 365 を使う場合でも Azure AD のアカウント管理は重要なファクターです。
グループをうまく設計することで、アカウントやデバイスの管理が数倍にも楽になります。
組織にあったグループの設計をして管理工数を減らせる運用を是非目指してみてください。

Azure AD 条件付きアクセスの活用について

Azure AD

前回Azure ADの機能やプランについて書きましたが、Azure ADってMicrosoft 365を使うから必要ってことじゃなく、認証基盤として優秀なので連携できるアプリケーションは連携して使った方がいいってことです。
Micorosft Azure 使うから管理者だけ管理しておけばいいや、ではなくちゃんと権限ロール管理をして管理者自体を管理したりアクセス制御したりIAMでAzureリソースへの権限管理したりと必要になってきますので是非管理手法を学んでいただけるとよりよいクラウドライフが送れると思うんですよね。
というわけで、今回は条件付きアクセスです。
Azureポータルへのアクセスなんかも制御できます。

Azure AD 条件付きアクセス

Azure AD Premium P1 / P2 で利用できる機能で、ユーザーが対象のアプリケーション認証時にアクセス許可/ブロックに対する条件をつけることが可能です。
例えば、以下のようなことができます。

  • 総務部のアカウント(かつ部長は除外)がExchange Online にアクセス
  • Windowsのみアクセス可能
  • 社内ネットワークからのみアクセス可能
  • 多要素認証を強制
  • Intune で管理されている準拠済みデバイス
  • Hybrid Azure AD Join を使用したデバイス
  • アプリの条件付きアクセス制御で重要データが入っている場合拒否

以前、Azure Virtual Desktop で利用する場合の条件付きアクセスも書いているので参考にしてみてください。

tsukatoh.hatenablog.com

条件付きアクセスポリシー

設定できる項目は色々あります。
2022/03/03 時点では以下項目が設定可能です。

  • ユーザー
    • ユーザー
    • ユーザーグループ
    • 権限ロール
  • クラウドアプリ
  • 条件
    • ユーザーのリスク
      • 高 / 中 / 低
    • サインインのリスク
      • 高 / 中 / 低 / リスクなし
    • バイスプラットフォーム
    • 場所
      • MFA 信頼済みIP / 設定済みの場所
    • クライアントアプリ
      • 先進認証クライアント / レガシ認証クライアント
    • バイスのフィルター
      • フィルター処理が書けます(動的グループと同様のフィルター)

上記の条件に対して以下の制御を行うことができます。

  • アクセスのブロック
  • アクセス権の付与
    • 多要素認証を要求する
    • Intune の準拠デバイス
    • Hybrid AAD Join デバイス
    • 承認されたクライアントアプリ
    • アプリの保護ポリシー必須
    • パスワードの変更を必須

アクセス権の付与については「すべて」もしくは「いずれか」で指定が可能です。

これを組み合わせていくことでアプリケーションへのアクセスをセキュアなものにしていきます。

実装例

前提条件として以下があるとします。

  • 社内ユーザーで管理者ロールは対象外
  • Office 365アプリケーション
  • Intune 管理デバイス
  • 場所はどこでも
  • 多要素認証は必須
  • バイス種別はWindowsiOSにしぼる
  • レガシ認証は除外したい

社内ユーザーに絞る理由としてはゲスト参加しているユーザーやコラボレーションした先の外部ユーザーはアクセスさせたくないとかな要件ですね。
Intune管理デバイスに絞る理由は社給のデバイスだったりBYODでも会社として管理・許可しているデバイスを使わせるという理由になります。
場所については最近流行りのゼロトラストですね、どこからでも許可したい場合に色々と縛りをつけることでセキュリティを担保するという考え方です。
正直今回条件付きアクセスの観点で書いていますが、ゼロトラストをやる場合はMicrosoft Defender for Endpoint の導入までやった方がいいです。
Intune のデバイス管理と連携してインシデント管理やデバイス管理が可能になります。

実際の設定画面は以下となります。

f:id:tsukatoh:20220302163935p:plain f:id:tsukatoh:20220302163952p:plain f:id:tsukatoh:20220302164008p:plain f:id:tsukatoh:20220302164024p:plain f:id:tsukatoh:20220302164110p:plain f:id:tsukatoh:20220302164127p:plain f:id:tsukatoh:20220302164142p:plain

認証について

条件付きアクセスを利用する場合、よく言われるのが「条件付きアクセスっていつかかるんですか?」です。
条件付きアクセスはユーザー認証時にかかるものです。
上記の例で言うと、Office 365 アプリに対象のユーザーがアクセス・認証した時に条件に合致したものをアプリへのアクセスを許可またはブロックするといった仕組みになります。
簡単に図で書くと以下のような流れになります。

f:id:tsukatoh:20220302170909p:plain

補足情報ですが、シャドーIT対策で会社のテナントにはアクセスさせるけど、個人所有テナントにはアクセスさせないとかいう場合はProxy製品で対応する形となります。

docs.microsoft.com

まとめ

条件付きアクセスを使ったクラウドアプリケーションへのアクセス制御の一例ですが、複数ポリシーを使ってルールを作っていく形となります。
一つで作ろうとしても無理が出てきますので、アプリケーション単位だったりユーザー単位だったりで工夫して作る必要があるので試行錯誤が必要かなと思います。

次回はIdentity Protectionかグループ管理辺りでもまとめたいと思います。

Azure Active Directory のプラン別機能について

Azure Active Directory (Azure AD)とは

クラウドベースの ID サービス (IDaaS) で、シングルサインオンや条件付きアクセス、多要素認証などの機能を提供しています。
ただ、Active Directoryという名前がついていてもドメインコントローラーの機能は提供されません。
ドメインコントローラーが必要なら Azure AD Domain Services の導入や、オンプレミスADとAzure ADの連携のためのAzure AD Connectの導入を検討ください。
また、Azure AD B2C や Azure AD B2B といった顧客ID・アクセス管理だったりコラボレーションを提供していますがここでは割愛します。

Azure AD の機能とプランによる違い

Azure AD のプランはFree、Office 365 アプリ、Premium P1、Premium P2の4つが提供されています。(2022/03/02現在) Office 365 アプリはO365などのサブスクリプションを購入したテナントに適用されるプランです。
Premiumは有償プランとなり、個別購入もしくはMicrosoft 365 E3以上に同梱される形で提供されます。
以下はプラン別の提供機能の違いになります。

機能 Free O365 P1 P2
ユーザー/グループ/デバイス管理
外部ユーザー連携
オンプレミスAD同期
カスタムドメイン
シングルサインオン
セルフパスワードリセット ×
多要素認証 ×
IP制限 × ×
エンタープライズアプリケーション
レポート
アプリケーションプロキシ × ×
不正アクセスアラート × × ×
条件付きアクセス × ×
リスクベースの条件付きアクセス × × ×
アプリの条件付きアクセス(MCAS統合) × ×
Identity Protection × × ×
Privileged Identity Management × × ×

公式サイト情報はコチラ
docs.microsoft.com

テナントについて

Microsoft社が提供するクラウドサービスにはテナントという考え方があり、テナント内は自社の領域となります。
例えて言うならオフィスビルだったりマンションといったものでしょうか。
認証時の画面はMicrosoft社が用意している共有のものを使用しますが、アカウントを入力した時点でテナントの判別がされます。
アカウントの@以降、ドメインでの判断となります。
これによりサインインするテナントへ割り振りされるのです。

機能について

よく使う機能を抜粋して紹介します。

ユーザー/グループ/デバイス管理

  • ユーザー管理 アカウントの管理、権限ロールの管理ができます
  • グループ管理 セキュリティグループ、Microsoft 365グループの管理ができます

    • セキュリティグループ:一般的なユーザー・デバイスを管理するためのグループでメールアドレスを有効化することも可能(Exchange Online側で作成する必要がありクラウド側のグループでは後から変更が不可)
    • Microsoft 365 グループ:Teamsのチームの管理などにも使われ、M365内のアクセス制御用途で使うことができる

オンプレミスAD同期

オンプレミスADのアカウント/セキュリティグループ/デバイスを Azure AD と同期する機能。
Azure AD Connect サーバーを使って同期する。
既存でADでアカウント管理している場合にはこちらを構成することで、オンプレADとのシングルサインオンが実現できる。
また、AD Joinしているデバイスを連携する Hybrid AD Join を構成することで、オンプレADに参加しているデバイスMicrosoft Intune で管理するために連携したりもできます。

カスタムドメイン

通常 Azure AD テナントを作成した場合、*.onmicrosoft.com というドメインが割り当てられます。
上記とは別に購入したドメインを割り当てることも可能です。

多要素認証

Multi-Factor Authentication が利用できます。

  • 電話
  • SMS
  • Microsoft Authenticator アプリ

追加として Windows Hello for Business なども対象とすることが可能です。

docs.microsoft.com

IP制限

クラウドサービスなので場所を問わずという考え方がゼロトラストですが、アクセス元IPを制限して利用させることも可能です。
この機能はP1以上が必要となります。

エンタープライズアプリケーション

Azure AD 上でクラウドサービス等をアクセス管理することができます。
SAML連携することでシングルサインオンの実装も可能です。

アプリケーションプロキシ

オンプレミスのWebアプリケーションを外部に公開するための機能です。

条件付きアクセス

ユーザー、デバイス、場所などを条件にMFAを強制したり、Intune管理されているデバイスのみアクセス可能にしたりと言った制限がかけられます。
リスクベースの条件付きアクセスを使うことでサインインリスクやユーザーリスクを条件に入れたり、アプリの条件付きアクセスを使うことで Microsoft Defender for Cloud Apps (旧称 Microsoft Cloud App Security [MCAS]) を通じてDLP/AIPを連携させてセッション制御することも可能です。

Identity Protection

サインインリスクやユーザーリスクを検知する機能で以下のようなリスクを特定できます。

  • 匿名 IP アドレスの使用
  • 特殊な移動
  • マルウェアにリンクした IP アドレス
  • 通常とは異なるサインイン プロパティ
  • 漏洩した資格情報
  • パスワード スプレー

Privileged Identity Management

Azure AD の特権ロール管理機能です。
常時特権ロールを割り当てないことにより不要な設定変更やリスクを回避できます。
割り当て可能なユーザー(グループで指定可能)を指定しておき、特権ロールを使用する際に承認を必要とすることでJust-In-Timeによる一定時間内の権限付与を可能にします。

docs.microsoft.com

まとめ

Azure AD は機能レベルによって購入するプランが変わりますので、必要な機能を検討してどのプランを導入するか決定していただければと思います。
セキュリティ観点ではP2まであった方がいいとは思いますが、最低限条件付きアクセス(Premium P1範囲)の導入を検討してみてはいかがでしょうか。

次回は条件付きアクセスをもう少し深く書こうかと思っています。

Azure Virtual Desktop を Azure AD Join 環境で使い、Intuneで管理する

概要

Azure Virtual Desktop (AVD) のVMが Azure AD Join に対応したり Windows 11 MultiSession が公開されたりと昨年色々アップデートがあったのでまとめました。
従来のAVDでは Hybrid AD Join もしくは Azure AD Domain Services へ Join されたVMのみサポートされていましたが、2021/9/22の発表でAzure AD Join がGAされました。
ただ、現状(2021/1/5 現在)は利用用途として以下の制限があります。

  • ローカル ユーザー プロファイルを使用する個人用デスクトップ
  • ジャンプ ボックスとして使用されるプールされたデスクトップ ※ユーザーは VM にデータを保存することはできません
  • ユーザーが VM にデータを保存する必要がない、プールされたデスクトップまたはアプリ

docs.microsoft.com

FSLogix が Azure AD Join VM をサポートしていないのが原因で、マルチセッション環境では移動プロファイルを持てない(現状ローカルプロファイルのみ利用可能)なためですね。
ただ、2021/12/2 にプレビューで発表されていますが、対応中でそのうちGAすると思いますのでこの制限も外れると思います。

azure.microsoft.com

それほど難しくなく構成できるので、Intune 管理まで含めてやってみたいと思います。

AVD ホストプール構築

前提として Azure AD にすでにアカウント・グループがあること、Azure テナントに仮想ネットワークを作成済みであることとします。

Azure Portal から Azure Virtual Desktop を開き、ホストプールを作成します。
※ここではプール型にしています

f:id:tsukatoh:20220105145501p:plain

次に仮想マシンを紐づけます。
「参加するドメイン」の部分を以下のようにします。
参加するディレクトリを選択する:Azure Active Directory Intune に VM を登録する:はい

f:id:tsukatoh:20220105145647p:plain f:id:tsukatoh:20220105145703p:plain

この後の手順は従来と同様です。
ホストプールのデプロイが完了したら割り当てするのを忘れずに。

f:id:tsukatoh:20220105150052p:plain

Intune 側の表示

VMのデプロイが完了すると自動的に Azure AD のデバイスへ登録され、Intuneでも確認ができるようになります。
※画面はWindows 11 Enterprise Multi-session

f:id:tsukatoh:20220105150159p:plain

Multi-session だとプライマリユーザーはなしになります。

f:id:tsukatoh:20220105152613p:plain

コンプライアンスポリシーにしてもデバイス構成プロファイルにしても AVD 用で物理デバイスと分けておかないと非準拠になったりポリシーが当たらなかったりするので注意が必要です。

AVD への接続

Windows Client から接続する場合はAzure ADアカウントで登録されているデバイスからは特にそのままでも問題ありません。
それ以外のデバイスから接続する場合(macLinuxなど)、ホストプールのRDPプロパティへ以下を追加する必要があります。

targetisaadjoined:i:1

f:id:tsukatoh:20220105153030p:plain

これでmacからの接続も確認できました。
FSLogixのAAD Join対応がGAされればプロダクション環境でも使えますね。

Microsoft MVP アワードを再受賞しました

本年も継続してMicrosoft MVPアワードを受賞いたしました。
区切りとなる5年目となり、昨年と同様にAzureカテゴリーです。

AVDやAKSをはじめ、情報の発信を引き続き行なっていきたいと思います。

mvp.microsoft.com

Microsoft 365 E5 で実現する WVD セキュリティ考察

概要

前回「Office 365 E3」および「Windows 10 Enterprise E3」のライセンスの組み合わせにおいての、WVD上でMicrosoft 365 Apps for enterprise (旧称 Office 365 ProPlus) を利用する際のセキュリティ考察について書きました。
今回は Microsoft 365 (M365) ライセンスの最上位である、Microsoft 365 E5 ライセンスを利用する際のセキュリティ考察をしていきたいと思います。

※前回記事ついては以下参照ください。

tsukatoh.hatenablog.com

今回の構成については以下も含めて検討していき、ゼロトラストセキュリティを目指します。

  • Endpoint Detection and Response (EDR)
  • Cloud Access Security Broker (CASB)
  • Mobile Device Management (MDM)
  • Mobile Application Management (MAM)
  • Secure Web Gateway (SWG)

アカウント認証

M365 E5 には Azure AD Premium P2 のライセンスが包含されています。
前回の構成ではできなかった、条件付きアクセスが利用できます。
ゼロトラストセキュリティ前提で構成する場合は、場所(IPアドレス)の指定は外すか事業所が存在してる国のみに絞るといった事を検討する必要があると思います。
もちろん許可されたデバイスかどうかの判定は必須と思います。
条件付きアクセスで検討する項目は以下。

・許可されたデバイスかどうか
 →MDMで認可としているデバイスを対象にする。
 →もしくはプレビュー機能 (Filters for devices) ですがデバイスのフィルターも可能です。
 ( モデルやOSといった条件でフィルターが可能)
・許可されたアプリケーションか
 →SSO対象にしているクラウドアプリ等を対象にできます

・許可されたロケーションか
 →アクセス許可するIPアドレスレンジ
・多要素認証 (MFA) の強制

条件付きアクセスの設定等については以下記事を参照ください。

tsukatoh.hatenablog.com

WVDホストからの通信

前回の書いた3つと追加で Microsoft Cloud App Security (MCAS) を追加できます。

上3つについては前回記載しましたので、今回は M365 の CASB サービスである MCASを検討していきます。

[Microsoft Cloud App Security (MCAS)]
MCAS を導入する理由としては以下のようなものがあります。

  • シャドウITの検出・制御
  • 機密情報の保護
  • 攻撃の脅威や異常に対する保護
  • コンプライアンス

以下のようなことが対応可能になるため、是非とも導入したいですね。
・Office365 へのアクセスは許可するが、個人テナントにはアクセスさせない。
・Azure Information Protection (AIP) や Data Loss Prevention (DLP) と組み合わせた機密情報保護。
・ユーザーアクティビティによる制御や Microsoft Defender for Endpoint との連携による振る舞い検知。 ・ダッシュボードによるデータ流出の監視やアクセス制御。

Web コンテンツ フィルタリングについては Microsoft Defender for Endpoint の1機能として現在プレビュー公開されています。
こちらを使うことでWVDだけではなくIntuneに登録されているデバイスと同等の構成を組むことができます。

WVD ホストのウイルス対策

Windows Defenderを利用するのは変わりませんが、脅威検知・保護の観点で Microsoft Defender for Endpointを構成します。
ウイルス検知だけではなく、攻撃に対する監視・検知・自動対応や振る舞い検知といったことが可能になります。

Windows 10 Enterprise Multi-Session で利用する場合は以下のような対応が必要になります。

docs.microsoft.com

Device制御 (MDM / MAM)

Microsoft Intune でデバイスを管理して企業のポリシーにあった構成を組みます。
前述の条件付きアクセスへ Intune で管理されており、かつポリシーにそった構成であることを条件とすることができます。
上記により許可されていない端末やデバイス構成をとっているデバイスについては企業データへのアクセスを禁止することができます。
また、インストールするアプリケーションの制御や企業データの個人領域へのコピー&ペーストの禁止等の制御も可能です。
※この辺りの細かい記事はIntune関連の記事を参照ください。

ただ2021年6月5日現在、Windows 10 Enterprise マルチセッションには対応していないので WVD でどうしてもIntune管理下に置きたい場合はマルチセッション以外のイメージをお使いください。

docs.microsoft.com

ログ関連

Microsoft 365 関連ログ及びAzure AD ログはAzure Sentinelへ接続します。
Azure Sentinel (SIEM) を使うことでAIによるセキュリティ分析が可能になります。
Power BI と連携することで可視化することも可能です。

docs.microsoft.com

最終的な構成

f:id:tsukatoh:20210605210744p:plain

Microsoft 365 E5 では Windows 10 ライセンスや Intune、MCASなど様々なライセンスが含まれるため個別に購入することもなくゼロトラストセキュリティを実現することが可能です。
また、Azure のセキュリティサービスやSIEMを組み合わせることで分析・監視の強化も行えます。
WVD、クラウド、デバイスのトータルセキュリティとしてこのような構成を考えてみました。
一部プレビュー機能が含まれますが、Microsoft 社製品だけでトータルセキュリティが構成できると思います。
サービス間の親和性も高いのでご検討のヒントになれば幸いです。