今日はみんなお困り、Intune の同期についてです。
このブログでもIntune の同期についてはこれまでにも何回か取り上げてきました。そんな中、米国マイクロソフトのイベントでIntune 同期に関わるセッションがあったので、まとめ記事を作ってみました。

YouTube

Intune 'fast lane' - Let's talk about all things latency – Micros...

https://www.youtube.com/watch?v=K1RnwR7VVH8

Ever wondered what happens from the time you click the save button on an assignment to when your devices receive the updated changes? Learn about the inner w...

この動画を見ていたら過去に自分がIntune同期の仕組みについて解説したこちらの記事に近いところが色々あったので

Always on the clock

Intuneの同期よ、早く来て！

https://azuread.net/archives/13535

Intuteの同期タイミング について皆さんこんにちは。国井です。Microsoft Intuneと言えば「なんもわからん」という言葉が使われるほど、謎に感じることが多いと思います。どうして謎に思うかと言えば「設定したことがいつ反映されるかわからない」このことに尽きるのではないかと思います。MECM/SCCMをこれまでに使ってきた立場からしてみればボタンを連打してナンボ。システム管理製品なんてこんなもんだよなと思っていたりもします。しかし、お客さんにそんな説明は通用しません。そこで今日はIntuneってどんな時に同期が行われるの...

過去に自分が書いた記事も引用しながら同期の仕組みについて見てみたいと思います。

MSさんの肩を持つわけではありませんが
Intuneとしてはできるだけ早く設定を適用させたいと考えている一方で、
・同じアクションに対して同じ結果が同じ時間だけかかるようにすること
・異なるプラットフォームでも異なるデータセンターでも同じように利用できるようにすること
・小規模から大規模までカバーすること
という非常に多様な状況下で結果が求めるという、かなり困難なミッションを化せられています。
だからこそ、ちょっと変わった同期のアーキテクチャを採用している(採用せざるを得ない)ということはアーキテクチャの話をする前に知っておきたいことです。

同期ロジック

Intune同期プロセスに「チェックイン」という表現が使われますが、そのチェックインプロセスには次の3つがあります。

・シングルデバイス：
管理者やユーザーが特定のデバイスに対して行う操作 (デバイスの同期とかワイプなど)
・メンテナンス：
クライアント側からバックグラウンドで行われるチェックイン操作
・変更ベース：
Intuneで何かの変更があったときにデバイスに通知を行いチェックインする方法

この3つは私が以前の投稿で書いた手動で同期、タスクスケジューラで設定したタイミング、通知を受けたタイミングの3つに当たるものです。
それぞれのチェックイン操作について特徴を見ていきましょう

変更ベースのチェックイン

変更ベースの「変更」とは

・既にあるポリシーやアプリの割り当てに新しいユーザーやデバイスグループを追加する
・特定のポリシーの値を変更する
・グループのメンバー変更
・ストアアプリの新しいバージョンが登場した

などのことを指し、これらが発生するとその情報を対象のデバイスに対してプッシュします。プッシュするということは優先度の高いチェックイン方法だということがわかります。
変更ベースのチェックインでは上記の変更が保留中のデバイスがいる場合にはそのチェックインを常に優先される仕組みになっています。
ただしシャットダウンしていたなどの理由で通知を受け取れなかったデバイスがいる場合、チェックインの処理ができる範囲の中で通知は繰り返し行われることになります。
なお以前の投稿ではプッシュ(通知)にはWindows Notification Serviceが使われ、通知を受けたクライアントはomaclient.exeを呼び出して命令を投げていると話をしました。

メンテナンスチェックイン

メンテナンスチェックインの「メンテナンス」とは

・コンプライアンスポリシーの準拠/非準拠の更新
・クライアント登録証明書の更新
・Intune クライアントアプリの最新状態維持

などのことを指します。また、ポリシーやアプリケーションの更新にもメンテナンスチェックインが使われます。
メンテナンスチェックインにはタスクスケジューラから実行するスケジュールベースのチェックインが含まれますが、このチェックインでコンプライアンスポリシーのチェックを行っています。よくコンプライアンスポリシーの状態がいつまでも変わらないって話を聞きますが、コンプライアンスポリシーをつかさどるメンテナンスチェックインは変更ベースのチェックイン時には処理しないので、次のスケジュールにならない限りコンプライアンスポリシーの状態が変わらないってことが起きるのです。

メンテナンスに当たる作業はすべてを平等に扱うわけではなく、デバイスの変更につながる可能性が高いチェックインに対して優先順位を設けて処理するようにしています。
例えばその日初めてサインインしたというタイミングだったり、コンプライアンスチェックに使われるようなデバイスの変更が生じたい場合など。
また、メンテナンスチェックインは必ずしもスケジュールどおりに実行するとは限らず
直近でチェックインしたばかりであれば、スケジュールどおりに行うチェックインはわざと遅延させて無駄なチェックインが発生しないような工夫をしています。
なお、メンテナンスチェックインにはテナントや時間でチェックイン数の上限が設けられていて、上限値に達すると(変更ベースのチェックインに支障をきたさないようにするために)、チェックイン要求は延期されます。
[同期] ボタンを連打しても同期されない！って話をよく聞きますが、連打するから同期されないってことになるのです。

チェックイントラフィック

チェックインの謎を解き明かす話からはちょっと外れますが、こんな話があったので取り上げさせてください。
Intuneのチェックインのトラフィックは変更ベースが15～20%、残りがメンテナンスチェックインを含むトラフィックになります。「残り」の部分を構成しているのがスケジュールタスクから実行するチェックイン(詳細はこちら) でこれが一番大きな割合になっていて、その他、サインイン時、デバイス登録時、同期ボタンを押したとき、などなどになっています。

新しいチェックインの仕組み：Declarative Device Management

これまでIntuneのチェックインではチェックイン中にポリシーA,B,Cの設定を適用する必要があった場合、チェックインプロセスの中でA,B,Cを順番に受け渡ししていました。
そして、それが途中で失敗すると次のチェックインでまた1からやり直しをしていました。これはすごく効率の悪い仕組みでした。

この課題を解決するためにIntuneでは新しくDeclarative Device Management (DDM) という仕組みを採用するそうです。
(一説によると現在既に従来型とDDM型は平行運用されていて、DDMの設定についてはレジストリのHKLM\Software\Microsoft\Entrallments\GUID\LinkedEnrollment から確認できるそうなのですが、私のデバイスではそのレジストリ項目を確認できませんでした)
DDMではデバイスの構成に関わるメタデータ (A,B,Cの情報がすべて含まれる情報だとおもってください) を一度の通信でまとめて渡してしまいます。そのため少ない通信プロセスでチェックインが完了できるメリットがあります。
この仕組みはPowerShell DSCをイメージしてもらうとわかりやすいと思います。
PowerShell DSCは理想の設定を構成ファイルとして作成しておき、そのファイルをクライアントに配布します。
クライアントは構成ファイルの状態と自分のデバイスの状態を比較し、違う点があれば自動的に修正するというものなのですが、これと同じことをIntuneクライアントでも行うことになります。

Intuneで設定した、すべてのポリシーやアプリの設定はひとつの構成ファイルにまとめられるので、デバイスはこれまでのIntuneのチェックインのように毎回ポリシーの設定を受け取らなくても、ローカルで適用すべきポリシーやアプリを把握できます。また、構成ファイルとの比較結果としてIntune側に送信する必要のあるレポートやコンプライアンスポリシーの状態情報は随時Intuneに送信されます。これによりコンプライアンスポリシーの状態がいつまでたっても変わらない状態は解消されると信じています！

最後にチェックインの結果については新しいレポートが用意される予定で、これを見る限りチェックインプロセスが追跡できるので

チェックインが行われない場合にはどこに問題があるのかがわかりやすくなるようです。

最後に

YouTube動画を中心に自分の過去の投稿なども振り返りながらまとめてみました。変更ベース、メンテナンス、シングルデバイスという3つのチェックイン方法があり、変更ベースが優先されるのでメンテナンスチェックインは時刻どおりに行われるとはかぎらないこと、そしてポリシーのチェックなどはメンテナンスチェックインが行われるたびにIntuneと通信をしていました。しかしDDMの登場により、

・基本的なポリシー設定等は構成ファイルがあればローカルで完結
・メンテナンスチェックインを待たず、継続的にコンプライアンスポリシーの状態をチェックし、結果を報告
・Intuneとの通信回数・トラフィックは減少

というメリットがあります。これらにより、これまで私たちが同期で味わってきた苦い経験を解消できることを願っています。

しばらく開催がなくなってしまうので、自社で導入を予定しているとか、案件対応を予定しているなどの事情がございましたら、個別にリクエストをいただければ御社にお伺いすることもできますので、気軽にお声がけいただければと思います。

Microsoft 365に関しては画面右側のバナーにもあるように、E5/E3を利用したセキュリティ対策のうち、防御面をマスターするコースもございますので、こちらも併せてご検討いただければ幸いです。

WSUSが非推奨になる中、Intuneを利用した更新プログラム管理は注目を浴びています。
そのIntuneを利用した更新プログラム管理方法のひとつにWindows Autopatchというのがあります。更新プログラムの展開に関わる設定をIntune経由で行うときに、その設定を自動的に行ってくれるものです。2022年のこの投稿でその方法を解説しましたが、ホントに全自動な感じでした。

Always on the clock

Windows Autopatchについて説明しよう

https://azuread.net/archives/12345

Windows Autopatchとは何か2025年に新しいバージョンの設定について解説しました。こちらをご覧ください。皆さんこんにちは。国井です。2022年7月12日はWindows Autopatchによって更新プログラムが管理された、はじめての日です。そのせいか、やたらとWindows Autopatchに関する記事が出てきたんだけど、一方でその説明を読んでもよくわからないという意見も目にしました。結局のところ、これなんだけどせっかくなので自分なりの言葉でWindows Autopatchとは？を説明してみたいと思います。更新リングとはWindows Autopatchの話を理解...

ところがこの仕様が変わってしまい、これって自動なの？って感じになっているので、色々な疑問を解き明かすべく一緒に見ていきましょう。

事前設定

最近のIntuneはIntuneのライセンスだけ持っていても利用できない機能が色々あります。
Windows Autopatchもそのひとつです。Windows AutopatchはMicrosoft 365 E3などに含まれるWindows E3ライセンスが必要になるので、そのライセンスを持っている場合は「持ってます」宣言が必要になります。設定はIntune管理センターの以下のメニューからどうぞ。

テナント管理 > コネクタとトークン > Windows データ

それができたらWindows Autopatchそのものの有効化をしましょう。設定はIntune管理センターの以下のメニューからどうぞ。

テナント管理 > Windows Autopatch

自動パッチグループ

Windows Autopatchは更新プログラムを適用する単位をグループ化して運用します。
そのため、デバイス > 更新プログラムの管理 > Windowsの更新プログラム から [自動パッチグループ] をクリックして開始します。

自動パッチグループの作成ウィザードでは更新リングを自分で必要な数だけ作成します。
以前は4つまたは5つと決まっていましたが、今度のAutopatchでは好きなだけ更新リングを作成し、分割して更新プログラムの適用ができるようになっています。

上の画面ではそれぞれの更新リングを利用するグループを指定していますが (HQ-Frist, HQ-Second と書かれている部分) これだと、どのリングにどのメンバーが配属されるかは固定されます。それに対して下の画面では [ダイナミックグループ配布] というのを使ってグループを指定しています。
この方法ではすべてのリングの中からどのリングに配属されるかはAutopatchの設定により自動的に決定されます。下の画面ではRing1に10％、Ring2に90%という振り分けを設定していますので、それに合わせてグループのメンバーが自動的に配属されるようになります。

こっちの設定のほうがいままでのAutopatchっぽい動きですね。ウィザードを進めるとそれぞれのリングで設定される更新プログラム適用の延期期間と

ドライバー更新プログラム適用の手動・自動や延期期間がそれぞれ確認・編集できます。

これでウィザードを最後まで進めれば更新リングとそのメンバーが構成され、その設定に基づくパッチ適用の運用がスタートするようになるのです。

なんでこんな面倒な実装になったの？

ここから先は私の完全な憶測です。
更新リングを複数作って、みんながバラバラなタイミングで更新プログラムを適用したいと思って始めたAutopatchですが、そもそもやりたいことはインターネット回線への負荷を軽減することです。下の図のように事業所ごとにインターネット回線が別々になっているのであれば、それぞれの事業所ごとに更新リングの設計をしなければならないのです。そうしないとRing1に特定の事業所に配置されたデバイスばかりが集中してしまう可能性があるからです。

このような構成に合わせて事業所Aの更新リング群と事業所Bの更新リング群、、のように設計できるようAutopatchではすべてを勝手に作ってしまうのではなく、私たちに更新リング群を作らせるような実装方法に変更したのではないかと思います。

内容に合わせてメールを暗号化

前回はメールの中に重要な内容が含まれていると自分で気が付いたときは自分で暗号化設定できるよ！という話でしたが、では重要な内容が含まれていると気が付いていなかったらどうなるでしょうか？
普通だったらそのまま送信されてしまうのですが、Exchange Onlineのメールフロールールではメールの送受信時に重要な内容が含まれていると判断すれば自動的に暗号化することができます。

この画面はExchange Admin Centerから メールフロー > ルールにアクセスし、ルールを作成した画面です。ここでは

・件名または本文に「Credit」という文字が入っていたら
・Office 365 Message Encryptionのメッセージセキュリティを実装し、Do Not Forward (転送禁止) の暗号化レベルを設定

というルールを定義しています。

このようなルールを作成したら、あとはルールを有効化するだけで、条件に合致するメールは自動的に暗号化されます。なお、Do Not Forwardの設定は日本語だと「転送不可」と表示されるMicrosoft Purview Message Encryptionのテンプレートを流用したものですが、この設定画面では秘密度ラベルを流用することも可能です。

PowerShellからメール暗号化の詳細設定

秘密度ラベルに関する設定はMicrosoft Purview管理センター画面からカスタマイズできますが、Microsoft Purview Message Encryptionの設定はほとんどGUIの設定画面がありません。もしMicrosoft Purview Message Encryptionの設定を行う場合はPowerShellから設定を行います。Microsoft Purview Message Encryptionなのに、なぜか設定はExchange Online PowerShellを使います。

■モジュールのインストール
Install-Module -Name ExchangeOnlineManagement

■Exchange Online PowerShellへの接続
Connect-ExchangeOnline

接続できたら Get-IRMConfiguration コマンドレットを実行するとMicrosoft Purview Message Encryptionの設定を確認できます。

ここに記載のオプションのうち、いくつかを紹介します。

■LicensingLocation 項目
ライセンス発行の場所を示すURLを表します。ライセンス発行とは暗号化されたデータを復号するためのカギをとってくると捉えていただくとわかりやすいと思います。クラウドプロキシでURLアクセスがブロックされていたりするとアクセス許可があるのにメールが開けないみたいなことになります。

■SearchEnabled 項目
暗号化されたコンテンツが検索結果に表示されるかを定義した項目です。もちろんアクセス許可があるユーザーが検索しないと表示されないわけだけど、暗号化しなきゃいけないようなデータが検索結果に出ちゃうっていいの？というのは検討の余地があるでしょう。

■InternalLicensingEnabled / ExternalLicensingEnabled 項目
それぞれ内部受信者、外部受信者にライセンス発行するか？を定義するものです。これを無効にすると暗号化したメールを送信しても相手はカギを受け取れないため、メールを開けなくなります。つまりこの設定を利用することで暗号化の機能が利用できる範囲の設定できるのです。
これらの設定を変えるときは Set-IRMConfiguration コマンドレットを使って変更します。

続いて Get-OMEConfiguration コマンドレットも見てみましょう。

こちらは暗号化が設定されたメールを開くときのオプションが中心に項目が用意されています。

■ExternalMailExpiryInterval 項目
暗号化が設定されたメールを開くことができる日数が入ります。暗号化されたメールを開くカギを一定期間たったら渡さないようにすることでコントロールしています。

■SocialIdSignIn 項目
メールアクセス時のサインインにソーシャルIdPを利用したサインインを利用させるか？OTPEnabled 項目はワンタイムパスワードを利用させるか？を表します。ともに前回登場した、この画面の設定項目を表していますね。

こちらも設定変更するときは Set-OMEConfiguration コマンドレットを利用します。

【FAQ】メールを暗号化したら添付ファイルも暗号化される？

最後にとてもよくいただくご質問を。
秘密度ラベルまたはMicrosoft Purview Message Encryptionでメールを暗号化したら、そこに添付されているファイルも暗号化されるの？です。これはOfficeアプリケーションで作られたファイルが添付されていればメールに設定したラベル(テンプレート)に沿ったアクセス制御が適用されます。こちらは転送不可を設定したメールに添付されていたファイルに適用されたアクセス制御設定です。コピーや印刷などの操作が禁止されていることがわかります。

一方、PDFファイルの場合、Get-IRMConfiguration コマンドレットの設定にもある EnablePdfEncryption 項目の設定がFalseになっているとPDFは暗号化されません。
そこでPDFの添付ファイルも暗号化したいときは

■PDFファイルの暗号化の有効化
Set-IRMConfiguration -EnablePdfEncryption $true

を実行してOfficeアプリケーションと同様に暗号化されるように構成しましょう。
この設定を行った上でPDFファイルを添付すると、ご覧のようなアクセス制御設定が適用されます。こちらもOfficeアプリケーションと同じようにコピーや印刷などの操作が禁止されていることがわかります。

最後はとりとめもない感じになってしまったけど、お役に立てれば幸いです。

突然ですがメールの暗号化をしたいと言ったら、どんな方法をとりますか？
そもそも暗号化しなきゃいけないような大事なデータをメールで送ったりしないよというツッコミもありそうですが、一方で「うちの会社、Teams使ってるけど外部テナントとのコミュニケーションは禁止されてて..」という会社もあるのでメールの暗号化は必須なケースも考えられると思います。そんな時に利用できるのがMicrosoft Purviewで利用できるメールの暗号化です。Purviewというとファイルを暗号化するイメージが強いですが、メールの暗号化も設定できます。ただし、ファイルと違って利用上の注意点があるので、今日はその話をしたいと思います。

メールの暗号化方法

Microsoft 365の中で利用可能なメール暗号化にはS/MIMEなどまで含めればいろんな方法がありますが、Purviewを使った方法で言うと大きく分けて2つの方法があります。
ひとつが秘密度ラベルを利用した方法、もうひとつがMicrosoft Purview Message Encryptionです。

秘密度ラベルを利用したメールの暗号化

秘密度ラベルはラベルの中に暗号化の設定やアクセス許可の設定を埋め込む機能で、暗号化した場合、誰にアクセス許可を与えるかを事前に設定しておきます。ファイルにアクセス許可を割り当てるときはある程度割り当てる対象は決まっていると思うのですが、メールの場合はメールごとにアクセス許可を割り当てる相手が違います。
そのため、
Aさんにメールを送りたければAさんにアクセス許可が割り当てられた秘密度ラベル、
Bさんにメールを送りたければBさんにアクセス許可が割り当てられた秘密度ラベル、、
のような設定が必要になります。
これを無視して適当に秘密度ラベルを割り当てて相手にメールを送ると、こんな感じのメールが届くので[メッセージを読む] をクリックして

[ワンタイムパスコードを使用したサインイン]をクリックして

別メールに届いたワンタイムパスコードを元のメール画面に入力すると

アクセス許可がないから開けません。

アクセス許可がないなら最初から送らなきゃいいのに.. ってことが起きます。
どうしてこういうことが起きるかと言えば、秘密度ラベルであらかじめ決められた相手にアクセス許可を割り当ててしまうからです。

なので秘密度ラベルを作成するときに最初からアクセス許可を割り当てる相手を設定しないようにしておけばよいのです。秘密度ラベルを作成するときにメールだけを対象にして

アクセスの制御設定では [アクセス制御設定の構成] > [ラベルを適用するときにユーザーがアクセス許可を割り当てられるようにする]を選択すれば、メールを送るたびに異なるユーザー (つまり宛先となるユーザー) にアクセス許可が割り当てられます。

ちなみに暗号化のみはアクセス許可をメールの宛先のみに限定、転送不可は暗号化に加えて転送不可、コピペ禁止、印刷禁止などが加わります。

ここまでの話をまとめましょう。
秘密度ラベルがダメであるかのような説明をしましたが、
そもそもラベルを設定するときにファイルとメールの両方を対象にしたラベルを作ってしまうことがいけないのです。ファイルに秘密度ラベルを設定するときは「誰にアクセス許可を割り当てるか？」なんて毎回設定したくないからラベルの中であらかじめ定義してしまう。だけどメールの場合は送る相手が毎回異なるから、ラベルの中にアクセス許可を割り当てるユーザーは事前に設定したくない。この2つの異なる思惑をひとつのラベルにまとめちゃうから問題なのです。

ということでラベルはファイル向け、メール向けは別々にしておくのがよろしいかと思います。

Microsoft Purview Message Encryption

それに対してMicrosoft Purview Message Encryption (旧Office 365 Message Encryption)は一回限りのメール暗号化を目的とした暗号化方法で暗号化設定を選択すると自動的に宛先となるユーザーを対象とした暗号化・アクセス制御が設定され、メールが送信されます。受け取った相手はサインインユーザーのチェックを行い、Microsoft 365ユーザーであれば勝手にアクセス許可に基づくアクセスが行われ、GWSなどのその他のメールシステムを利用しているユーザーであれば秘密度ラベルの時と同じようにワンタイムパスコードを使ったサインインが行われます。そうして開いたメールがこちら。

暗号化されたメールであることがわかる内容が記載されていることがわかります。
ちなみにこのメール、アクセス許可がある本人しか開けないメールなので、画面の中から転送しようとするとSendボタンが押せないことがわかります。

ちなみに開いたメールの中から転送するのではなく、もともとのメーラーから転送しようとすればできるのですが、その場合のワンタイムパスコードはアクセス許可のあるユーザーに届くので、誤って転送することがあったとしても受け取ったユーザーがメールを開けることはありません。

設定はどうやって？

Microsoft Purview Message Encryptionは錠前のアイコンをクリックして設定

秘密度ラベルはペンキ塗りのハケマークをクリックして設定します。

なんか間違えそう！
だけど思い出してください。秘密度ラベルは事前に定義しなければ、ここに表示されることはありません。ファイルとメールの両方を対象としたラベルを作るから、こういうことになるのです。もっと言えば、秘密度ラベルで暗号化のみとか、転送不可とか、設定する画面を前に紹介しましたが、その設定って最初からMicrosoft Purview Message Encryptionのメニューにありませんか？ということで秘密度ラベルを作らなくてもMicrosoft Purview Message Encryptionを最初から使えばよいのです。

今日はここまで。
次回はメール暗号化のオプションなどについて紹介します。

秘密度ラベルを利用してファイルやメールにラベルを設定しましょう、ファイルやメールを暗号化しましょうって話、前回「秘密度ラベルとは？を知ろう」という投稿で紹介をしました。
Microsoft Purviewというブランドの中にデータセキュリティ、ガバナンス、コンプライアンスがあり、秘密度ラベルの暗号化はデータセキュリティのテクノロジーであること、
そして秘密度ラベルとはコンテンツに対するラベリング機能で、ラベル自体に暗号化機能があるわけではなく、ラベルを選択するときのオプションとしてMicrosoft Purview Information Protectionというオプションが選択できるんだ、という話をしました。

そしてこれも前回話したことですが、「暗号化の仕組みなんか世の中いっぱいあるのにどうして必要なの？」と言われれば、

パスワードで暗号化を管理するテクノロジーではなく
Microsoft Entra IDの認証機能を使うから

というのが特徴でした。
今日はそのアーキテクチャというか仕組みについて少し深堀してみたいと思います。

Microsoft Purview Information Protection の暗号化の仕組み

Microsoft Purview Information Protection (MIP) はざっくり言うと、ご覧のような暗号化の仕組みで動作します。これを順番に見ていきましょう。

暗号化とアクセス権限設定

MIPではファイルやメールなどを対象にコンテンツの暗号化を設定する際、OfficeアプリケーションやAdobe Acrobatなどを使います。これらのアプリケーションからコンテンツが暗号化されると、暗号化に使われたカギはMIPのクラウドサービスにアクセス権設定と共に保存されます。

暗号化されたコンテンツへのアクセス

MIPで暗号化されたコンテンツへアクセスする場合、カギが必要になるのでクラウドへ取りに行きます。このとき誰でも取りに行けるのではなく、Microsoft Entra IDで認証を行い、認証を行ったユーザーがアクセス権のあるユーザーであるかを確認します。
参考までに.. ですが、条件付きアクセスを利用してMIPのアクセス制御ができます。
これはEntra IDで認証を済ませた後、MIPにカギを取りに行こうとするタイミングでアクセス制御がかかります。ですので条件付きアクセスを組み合わせれば「誰がコンテンツにアクセスするか？」だけでなく、IPアドレスだったり、アクセスするデバイスだったりを条件にアクセス制御することだってできるのです。
これについてはanbutterさんのブログに詳しく書かれているので参考にしていただけると良いと思います。

Zenn

秘密度ラベルがついたドキュメントに外部ユーザーがアクセスするときの条件付きア...

https://zenn.dev/santafs/articles/1e397e0beac529

暗号化解除のためのカギの送付

アクセス権があることが確認できると暗号化解除のためのカギがMIPクラウドから送られてきます。この時に他の暗号化の仕組みと決定的に異なるのは人によって異なる暗号化解除のカギが送られてくる点です。MIPはアクセス権がある/ないだけを判断する仕組みではなく、閲覧・編集・フルアクセスなどの細かなアクセス制御ができるようになっているので

与えられた権限に応じて与えられるカギも違ってくるのです。ここが暗号化を解除したら、なんでもできちゃう暗号化機能とは異なる最大のポイントなんですね。

■ ■ ■

今日はMicrosoft Purview Information Protectionを利用して暗号化/暗号化解除するときの仕組みについて見てみました。
秘密度ラベルの中でもMIPを利用したときに暗号化の仕組みは作動すること、
アクセス制御にはMIPのクラウドを利用し、その認証にはEntra IDを使っていること
そしてアクセス権であらかじめ定められた範囲でアクセスできるようなカギが与えられることを解説しました。

Microsoft 365 E3 で実現するセキュリティ対策ベストプラクティス

同じMicrosoft 365の中でも防御面にフォーカスしてMicrosoft 365を利用している組織で必要なセキュリティ対策を一緒に考えていきます。Intuneを利用したデバイスセキュリティを中心に、Information Protectionによる簡易的なコンテンツ保護やメールセキュリティについても同時に取り上げる予定です。
※ Microsoft 365 E5にはE3の機能がすべて含まれますが、E5トレーニングではE3の機能をほぼ扱わないので、完全マスターを目指すからはこちらからどうぞ

2025年1月27～28日, 5月15～16日

お申し込みはこちらからどうぞ

Microsoft 365 E5 で実現するセキュリティ対策ベストプラクティス

Microsoft 365 E3 で実現するセキュリティ対策ベストプラクティスコースと同じく防御面にフォーカスしていくMicrosoft 365 E5のトレーニングコースです。MDEの脆弱性の管理やMicrosoft Defender for Cloud Appsによるクラウド管理、Microsoft Purviewによるデータ保護などを含めて２日コースで提供します。

2025年3月17～18日, 6月5～6日

お申し込みはこちらからどうぞ

Microsoft 365 を利用したインシデント対応コース

Microsoft Defender XDR、具体的にはMicrosoft Defender for EndpointとMicrosoft Defender for Office 365(リクエストベースでMDIなども一緒に取り上げていきます)を利用したインシデント対応コースです。ひと目でわかるMicrosoft Defender for Endpoint書籍では取り上げていないような、もっとリアリティのあるサンプルを多数利用して検証を行っていきます。

2025年1月16～17日, 5月8～9日

お申し込みはこちらからどうぞ

Microsoft Sentinel 初級・中級コース

Microsoft SentinelはMicrosoft Defender for Endpointを利用している企業でログを長期保管したいとの要望から使われることがありますが、「しょうがないから使う」から「積極的に使う」に切り替えていく方法を解説します。初級編ではMicrosoft Sentinelの環境構築方法を、そして中級編ではMicrosoft 365から取り込んだログをMicrosoft Sentinelから参照し、ログ分析をしていく方法について解説します。

初級編 2025年2月6日, 5月29日
中級編 2025年2月7日, 5月30日

初級編のお申し込みはこちらから、中級編のお申し込みはこちらからどうぞ

■ ■ ■

価格改定について

2025年4月1日以降に開催されるトレーニングに関しては新しい価格でのご提供を予定しています。ご参加いただく皆さまにご利用いただくMicrosoft 365やMicrosoft Azureなど運営に関わる様々なコスト上昇に伴う措置です。
すべてのコースにおいてトレーニング参加後もTeamsでのQ&Aコーナーの活用、参加後に改訂されたテキストはいつでも最新のものをご覧いただけるサービスなど用意し、これまで以上のサービス向上に努めてまいりますで今後ともどうぞよろしくお願いいたします。

また3～4名以上で参加したい、定期コースのないMicrosoft Entra IDやMicrosoft Intuneトレーニング、MDEやSentinelのCTF形式のトレーニングを開催してほしい、などのご要望についてはあなたの会社に国井が直接伺います。企業規模を問わずお伺いいたしますので、いつでもお問い合わせください。

Always on the clock

あと5年で辞めるの、辞めます宣言

https://azuread.net/archives/13687

皆さんこんにちは。国井です。2024年もどうぞよろしくお願いいたします。いつも年初めの投稿はテクノロジーから離れた話を書かせてもらっているのですが今年は少しだけ自分の話をさせてください。■ ■ ■1997年にマイクロソフト認定トレーナーになってから今年で28年目のシーズンを迎えます。ここに自分の年齢は書きませんが「28年目」という数字を聞けば私がいかに古株であるかがわかると思います。実際、先輩トレーナーの人でも(定年などで)引退する人が増えてきて、自分のまわりに先輩と呼べる人が少なくなってきました。トレーナー職...

Always on the clock

ソフィアネットワークの取締役を退任します

https://azuread.net/archives/11791

皆さんこんにちは。国井です。2022年もどうぞよろしくお願いいたします。今日はお知らせです。2006年に共同創業者として参画した株式会社ソフィアネットワークの取締役を2022年3月末をもって退任することになりました。IT研修の業界では3か月先を見据えてビジネスの話をします。繁忙期である4月以降の商談においてご迷惑をおかけしないよう、少し早い話ですがこのタイミングでお伝えすることになりました。2022年4月からはソフィアネットワークを分社化してできた株式会社エストディアンの代表取締役に就任し、引き続きトレーニングサ...

今年は趣向を変えてテクニカルトレーナーのコミュニティへの関わりについて話してみたいと思います。このテーマは

マイクロソフト認定トレーナーとして受講費用をいただいてお話をしている
立場の人間がコミュニティで無料で話するってどういうこと？

こう考える人もいると思うので、有償と無償は何をもって決まるのか？だったり、トレーナーとしてコミュニティに関わることによるメリットなどを私なりの視点で話してみます。

私がコミュニティに関わるきっかけ

本編に入る前に私のきっかけだけ簡単に話しておきます。
1997年にマイクロソフト認定トレーナーとしての仕事をスタートさせてから、職業としてお金をいただいて技術情報をお話してきました。当時はコミュニティと言えばチャットでのコミュニケーションが主流でかつハンドルネームを使うのが主流だったので、攻撃的なコミュニケーションも多く、私には馴染めない世界でした。だから敬遠するというか全力で逃げるべき存在でした。
一方で自分の中で色々なノウハウが溜まってきたにも関わらず、参加される方のスキルに合わせて話をするため、研修の時間内で伝えたいことの半分も伝えられないという現象が起きていました。おりしもブログだったり、オフラインコミュニティが出始めたり、コミュニティでの表現方法が多様化してきたこともあって、2006年ぐらいから研修の時間内で伝えられなかったTipsをアウトプットとして出していくようになったのがきっかけでした。

研修業界でアフターサービスってあまり聞かないので、自分のアウトプットがアフターサービスの一環として提供できれば.. ぐらいの軽い気持ちで考えていました。もちろんブログなどのオープンな場所に技術情報を書けば、お客さんではない方の目に触れてしまうけれど、それも自分なりの社会貢献だと思って取り組んできました。
(ブログのアクセスログに、あるSIerの名前を付けたプロキシサーバーからのアクセスがいつも大量にあるんだけど、その会社の人がうちの研修を一切受講してくれないんですよねｗ)

有償研修を登壇するトレーナーがコミュニティ活動してたらどう思うか？

まずは受講される方の立場から考えてみたいと思います。
と言いながら私は研修を提供する側の立場の人間なので、受講される方の立場でどう思うか？は正直なところ、よくわかりません。だけど受講費用をいただいてお話をする立場の人間がコミュニティで無料で話をしていたら、一定割合の人が「わざわざ受講に行かなくてもいいじゃん」って思うのでしょう。実際、私も研修とコミュニティで話す内容を変えていたりしません。だけどコミュニティで話す内容はどんなに長くても60分であり、しかもハンズオンで環境を操作できたりするわけではありません。研修は短くて1日、長くて5日というものが多く、それだけの時間を費やして得られるものはおのずと体系的なものになります。

例えばMicrosoft Intuneとは何か？がわからないという人に、Microsoft Intuneの機能のひとつである「Windows Autopilotでハマった話」などというテーマをコミュニティ勉強会で語られても頭の中がクエスチョンマークだらけになると思うのです。だからこそ体系的に学べる研修が必要だと私は考えています。(逆に言えばピンポイントにここだけを知りたい！という方であればコミュニティで知識が得られれば十分なのでしょう)
このような違いがあるので、研修とコミュニティ、どちらか一方があれば私たちの知識習得が完結する世界でもないのです。だからこそ私はコミュニティに関わって20年近くになりますが、いまでも有償の研修を受講してくださる方がいるんだと思うのです。

MS Learnをトレースする研修からの卒業

今度は立場を変えてトレーナーとしてのコミュニティに関わったら？という話をします。
トレーナー職の方でコミュニティに関わる人は私の肌感覚で言えば、だいぶ少ない気がします。実際、コミュニティになんか関わらなくたって自分の仕事は成立するし、Microsoft Learn見とけば私のしゃべりで研修講師ぐらいできるでしょ？正直こういうスタンスで、与えられた仕事をこなすだけって人がいるのは事実です。
現在のマイクロソフトオフィシャルのトレーニングで使われるテキストとLabガイドはどちらもネットで公開されているものを利用します。そのため、お金を出す価値はテクニカルトレーナーの話す内容にかかる比重は大きくなります。それなのにMicrosoft Learnに書かれている内容をトレースしたような説明が繰り返される研修でよいのでしょうか？
かと言って、実際どう使われているのか？どう使うべきなのか？などのベストプラクティスを話したいけど、テクニカルトレーナーという仕事をメインの生業にすれば案件に入ることはほとんどなくなるため、そのあたりの知識がどうしたって薄くなる。この問題を打破するためにコミュニティに関わるのはひとつの考え方としてアリなんじゃないかなと思います。

一例をあげましょう。
Microsoft 365に会社のデバイスを管理するMicrosoft Intuneというサービスがあります。Microsoft Intuneはデバイスに対してネット経由でポリシーを設定したり、アプリをインストールしたりできるサービスですが、テキストをトレースした説明をするなら「Microsoft Intuneではsetup.exeの形式のファイルはintunewin形式のファイルに変換すればネット経由でアプリがインストールできます」って説明になります。確かに説明としては正しいけれど、実際どう使ったらよいか？をもう少し深掘って欲しいと思うのです。例えば

・アプリのインストールって普通、セットアップウィザードが出てくるけど、Intuneを使えば自動的にインストールされるの？
・そうじゃなかったらウィザード画面ってユーザーのデバイス上に表示されるの？
・みんなの会社ではウィザード画面って表示されないように工夫してるの？
・インストールって普通、管理者権限必要だけど、私管理者じゃないけどインストールできるの？
など、挙げればキリがありません。

そうした実際に使おうと思ったら必ず出てくるであろう課題に対して、世間ではどうやって解決しているのか？自分の考えだったり、ソリューションだったりを提示していくことで価値のあるトレーニングを作れるようになるのですが、すべてのパターンを検証する時間もとれないし、もっと言えばMS Learnをトレースしているだけではそもそもこの問いを立てることすらできないかもしれない。
私にとって、そんな時にコミュニティで得た知識はとても役立ちました。

トレーナーのコミュニティ活用

いまやコミュニティはあちこちで山のように開催されています。どれがお勧めなのか？とか考えずに気になるテーマを取り上げている勉強会に参加してみたら良いと思います。時間を見つけて顔を出して色々な人の話を聞けば得られる知見もどんどん増えると思います。

コミュニティは参加するだけでも良いけど、できれば自分からアウトプットしたい。自分がコミュニティに登壇することで、他の人の話も聞く機会が自然と増え、得られる知識も増えていったと思います。また、自分自身が登壇者になることで他の登壇者の方々との強いつながりが得られるようになりますし、自分の思った疑問を他の人に気軽にぶつけたりするようなこともしやすくなったとも思います。
こうした知識はMicrosoft Learnに掲載されていない、生きた知識であり、それを研修に還元することで受講者の方々の満足度にもつなげられたのかな？って思っています。

トレーナーの知名度向上

コミュニティ活動を始めた当初は意識していたことではないけれど、コミュニティへの関わりは結果的に自分の名前を知ってもらう良い機会になりました。ブログを書く、コミュニティで登壇する、このことを何度も繰り返していくことでネットで自分の名前がたくさん登場することになります。それは自分が研修でお客さんを目の前にした時の信頼につながったと思っています。参加者の方が研修初日に、私が自己紹介する前に私のことを既に知っていて「国井さん」と声をけてくれたりすると本当に嬉しいですし、その日の研修も進めやすくなります。
私がまだトレーナーとして駆け出しの頃、よく私のスキルレベルを試すような質問をしてくる人がいました。その質問に的確にこたえていくことで、そのお客さんとの信頼関係を醸成していきましたが、これって本当に無駄な作業なんですよ。限られた時間の中でみんなの知りたい！に応えていく作業をしているのに私のスキルチェックをするようなやり取りはできるだけ省きたい。そんなところでもコミュニティの効用はあったと思います。

そこまでしなきゃいけない職業なのか？

勉強会って勤務時間外に開催されますから、あれこれ参加していたらブラックな職業じゃん！って考える人もいると思います。労働時間の縛りもありますから会社としてはそんなところに参加しろとは強要できません。だからすべてのトレーナー職の方に当てはめて話をしていません。ワークライフバランスを重視するとか、引退間際だからほどほどに働きたいとか、そんな方にとっては理解できない話だろうし、もちろんそういう考え方もあってよいと思います。

だけどコミュニティに積極的に関わっている人の原動力ってテクノロジーが好き、仕事で関わる内容が好き、誰かになにかを伝えたい、というようにブラック or ホワイトという線引きをそもそもしていないと思います。私もこの仕事が好きなので、もっと多くの人の課題解決のお手伝いを自分の仕事のスタイルを通じて (トレーニング/ワークショップという形で) 提供したい。なので明確な線引きをせずに、家族の理解を得ながらコミュニティに積極的に関わってきました。

パワハラと言われてしまうことを避けなければならない時代なので、昔のように上司がギャーギャー騒ぐこともなく、誰も自分に発破をかけて追い込むような人もいなくなり、勤務時間外にできることがあったとしても誰もアドバイスしてくれません。
だけどブラックとかホワイトとかではなく、仕事が好きで頑張りたいというのなら、もっとカラフルな仕事への向き合い方があっても良いと思うのです。ですのでコミュニティに関わって自分で追い込んで努力してみる (誰かがこんな働き方をセルフブラックって言っていましたが面白い表現ですね) ことで、長い期間この職業で成功を収める礎としたり、将来の仕事や立場に対する不安を消し去ったりするよう取り組んでみるって提案をしてみました。

努力とか、追い込むとか、昭和っぽい響きの言葉を聞くと「うわっムリ！」って思うかもしれないけど、一緒に語れるコミュニティの仲間がいれば楽しく様々なことを情報として取り入れられるようになると思います。

今年もどうぞよろしくお願いいたします。

note（ノート）

フリーランスITトレーナーとして生きていくために必要なこと｜国井 傑 | Suguru Ku...

https://note.com/sophiakunii/n/n6550e2ce98f2

私は23年間、ITトレーナーとして仕事をし、そのうち20年をフリーランス(個人事業7年、自分の会社で13年)として活動してきました。最初は2～3年続けられればいいやぐらいの気持ちでスタートしたのですが、順調に売上も伸ばすことができ、自分が作った会社では従業員を雇い入れることができるまでになりました。 一方で、ITトレーナーという括りで見ると人材不足がまったく解消されないことを年々強く憂うようになりました。そして自分があと何年トレーナーとしての仕事ができるのだろうかと考えた時に、他のトレーナーのために自分がで...

しかしその設定はMicrosoft Edgeのみで有効でGoogle Chromeからのアクセスの場合にはMicrosoft Single Sign On拡張機能を別途インストールしなければ条件付きアクセス設定が判定されないケースがありました。
この不便さを解消するためにChrome  Ver. 111からCloudApAuthEnabledを有効にすることで拡張機能を入れなくても条件付きアクセスに対応できるようになったので、今日はGoogle Chromeで条件付きアクセスを適用させるCloudApAuthEnabledについて見てみたいと思います。

CloudApAuthEnabledとは

CloudApAuthEnabledはGoogle Chromeに関わるレジストリの設定で、条件付きアクセスを突破してChrome経由でのシングルサインオンアクセスを実現するための設定です。
Microsoft Learnでは次の設定を行うことでCloudApAuthEnabledを有効化できると書いてあります。

• パス: HKEY_LOCAL_MACHINE\Software\Policies\Google\Chrome
• 名前: CloudAPAuthEnabled
• 値: 0x00000001
• PropertyType: DWORD

これをPowerShellスクリプトにしてIntuneから展開してしまえば出来上がり！なのですが、なんでもPowerShellスクリプトにして展開するのは後の管理者への引継ぎを考えるとあまりやりたくないんですよね..

構成プロファイルからCloudApAuthEnabledを設定する

構成プロファイルの設定にはGoogle Chromeに関わる設定項目が最初から用意されています。しかし、CloudApAuthEnabledに関わる設定がなかったので、Chrome用ADMXファイルをインポートし、そこから設定することにしました。

Chrome用ADMXファイルはGoogleのサイトからダウンロードできるので、これを入手してMicrosoft  Intune管理センターの デバイス > 構成 > ADMXのインポートから
Google.admxとChrome.admxファイル (ja-jpフォルダーにある言語設定ファイルであるGoogle.admlとChrome.admlファイルも一緒に)インポートします。

するとCloudApAuthEnabled設定が利用できるようになります！って言いたかったのですが次のようなエラーが出てしまいました。

エラーメッセージにも書かれているようにChrome.admxファイルをインポートするためには前提条件としてWindows.admxファイルが必要になります。
そこでマイクロソフトのWebサイトから最新のADMXファイルを入手し、ダウンロード・インストールするとインストールフォルダーにWindows.admxファイルとさらにその配下のja-jpフォルダーにあるWindows.admlファイルをインポートします。

ここまでができるとChrome.admxファイルも問題なくインポートできるようになります。

ここまでできたら構成プロファイルからCloudApAuthEnabled設定が呼び出せるようになります。Microsoft  Intune管理センターの デバイス > 構成 > 作成 > 新しいポリシーから、こんな感じでメニューを呼び出すと

管理用テンプレートの画面が出てくるので、コンピューターの構成 > Google > Google Chrome > Microsoft Active Directory 管理設定の順にアクセスすると[Microsoft のクラウドIDプロバイダに自動ログインを許可する]メニューがあるので有効にして
[Microsoft のクラウド認証を有効にする]を選択するとCloudApAuthEnabledを有効にしたことになります。

結果を確認

CloudApAuthEnabledを有効にすれば、Entra登録やEntra参加などを行っているデバイスでChromeからMicrosoft 365のページにアクセスすれば自動的にサインインするようになりますし、また条件付きアクセスの条件も自動的にチェックするようになります。
今回は条件付きアクセスで次のようなアクセス制御設定を行ってみました。

・ユーザー：すべて
・ターゲット：Office 365 Exchange Online
・条件：デバイスフィルターで「Entra登録またはEntra参加デバイスを除外」
・制御：ブロック

ご覧のような設定をすればCloudApAuthEnabledを設定していない限り、「Entra登録またはEntra参加デバイスを除外」を判定できずに先へ進めないはずです。ですが私のコンピューターはCloudApAuthEnabled設定をしてあるので、実際にアクセスしてみると、ご覧のようにアクセスできることが確認できます。

Copilot for Securityから名称が変わりSecurity Copilotとなったサービスのシリーズ、今回はSecurity CopilotとMicrosoft Entra IDの組み合わせでの管理について見ていきます。
※この投稿はなんでもCopilot Advent Calendar 2024 Day9 として投稿しています。

Security Copilotとは

Security CopilotはMicrosoft Defender XDRに対する(Microsoft 365内のインフラ系サービスを対象とした)生成AIのサービスで、自分の会社の構成情報をもとに構成情報の解説をしてくれたり、インシデントであればその状況の解説をしてくれたり、その後に行うべきアクションを指示してくれたりします。これまでにもこのブログではサービス種類ごとに利用感などについて書いてきました。

Always on the clock

Copilot for Securityでの調査：Intune編

https://azuread.net/archives/13929

皆さんこんにちは。国井です。今日は連投です。2024年4月1日から提供開始となったCopilot for Securityについて。Copilot for SecurityはMicrosoft Defender XDRやEntra ID, Intuneなど、いわゆるMicrosoft 365セキュリティ系の様々なサービスに対する生成AIの機能を提供してくれるSaaS型サービスです。ただ、インスタンスを作成するとお金の熔けるスピードが尋常じゃないので、さっさと検証して備忘録を残しておこうと思い、このポストを書いています。インスタンスの作り方とかはこちらで詳しく紹介してくれているので、ここではちょ...

Always on the clock

Copilot for Securityでの調査：Microsoft Defender XDR編

https://azuread.net/archives/14035

皆さんこんにちは。国井です。以前Copilot for Securityを使ったIntuneのトラブルシューティングの話をしてから時間が空いてしまいましたが、今度はCopilot for Securityを使ったインシデント対応をしてみたいと思います。Microsoft Defender XDR単体でインシデント対応する場合とどんな違いがあるか？をつかんでもらえれば嬉しいです。※Copilot for Securityそのものの利用開始方法は他の方が既に解説してくれているので、ここでは省略します。本日の特選素材MDEではおなじみ「Multi-stage incident..」で始まるインシデントが出てい...

Always on the clock

Copilot for Securityでの調査：Microsoft Purview編

https://azuread.net/archives/14275

皆さんこんにちは。国井です。 Copilot for Security でのトラブルがあって検証が止まってしまっていましたが、解決したので再開していきます。今日はCopilot for Securityを利用したMicrosoft Purviewのインシデント対応にチャレンジしてみます。※Copilot for Securityそのものの利用開始方法は他の方が既に解説してくれているので、ここでは省略します。Microsoft PurviewとはMicrosoft 365の中でもデータセキュリティの分野に対するセキュリティ関連のサービスで・主なサービスとしてコンテンツの暗号化を実現する秘密度ラベル・特...

Always on the clock

【まとめ】Microsoft Copilot for Security を安全に使う

https://azuread.net/archives/14470

Microsoft Copilot for Security を安全に使う.. と聞いて「ああ、あの話ね」と察した方もいるかもしれませんが、あの話をします。そうです、Microsoft Copilot for Securityで重課金を防ぐ、つまり安全に使う方法についてです。Microsoft Copilot for SecurityとはCopilot for SecurityはMicrosoft Defender XDRに対する(Microsoft 365内のインフラ系サービスを対象とした)生成AIのサービスで、自分の会社の構成情報をもとに構成情報の解説をしてくれたり、インシデントであればその状況の解説をしてくれたり、その後に行うべきアクシ...

ゼロトラストの世界では「Identity is the new control plane (IDは(これからの時代の)新しい境界になる)」と言われるぐらい、IDはセキュリティ上とても重要な要素です。
そのIDにセキュリティ侵害があったか、なかったか、そして侵害があればその状況を知ることができるのがSecurity CopilotをEntra IDと組み合わせて利用するメリットになります。
早速見ていきましょう！

Security Copilot in Entra のスキル

Security Copilotの中で学習・推論に利用できる分野を「スキル」と表現するのですが、Microsoft Entra IDに関連するスキルとしてはユーザーに関連する情報、特にサインインに関わる情報が利用できるようです。

learn.microsoft.com

Copilot を使用して ID の脅威に対応します。 - Microsoft Entra

https://learn.microsoft.com/ja-jp/entra/fundamentals/copilot-security-entra

Copilot in Microsoft Entra を使用して、ID リスクを調査し、ID タスクのトラブルシューティングをすばやく行います。

ですので
・ユーザーが所属するグループやロールについて
・ユーザーのサインイン失敗やリスクのあるサインインに関して
・監査ログから管理者が行った操作について
などがSecurity Copilotの中でできる操作になります。
エンタープライズアプリケーションのSAML設定に関するトラブルシューティングだったり、ぐちゃぐちゃになっている条件付きアクセス設定とか解説してくれたら本当は嬉しんですけどね..

ビルトインのアイコンから調査する

Security CopilotのSCUを購入するとMicrosoft Entra管理センターにあるCopilotアイコンが利用できるようになります。
一番わかりやすいのは画面右上にある[Copilot]ボタンですが、

画面左側にある 保護 > Identity Protection からリスクのあるユーザーのアラートを要約してくれます。

スタンドアロンから調査する

Microsoft Entra管理センターのメニューにないことを聞きたければスタンドアロンを使います。もちろんMicrosoft Entra管理センターの[Copilot]ボタンを使って質問しても良いんだけど、スタンドアロンの場合はサンプルプロンプト集を使って質問したり

プロンプトブックを使って聞きたいことをまとめて質問してくれたりするので

Copilotを使って調べたいこと、聞きたいことがまとまっている人はMicrosoft Entra管理センターから質問しても良いけど、そもそも何を聞けばよいかわからない.. という人にはスタンドアロン型の設定はお勧めです。
実際に使ってみましょう！
まずはサンプルプロンプトから[User Authentication]というプロンプトを使ってユーザーが利用するサインイン方法を追跡してみましょう。サンプルプロンプトを選択して、ユーザーのUPNを入力すると

こんな感じで結果が返ってきました。
これを見るとWindows Hello for Businessを利用しているデバイス、Microsoft Authenticatorを利用しているデバイスなどが確認できるのと当時にパスワードはどこのデバイスでも使っていないと出ているので、ちゃんとパスワードレス認証を使っているな！ってことがわかります。
デバイス名を塗りつぶしてしまっているのでわかりにくいのですが、Entra IDに登録されたデバイスが認証に使われている場合はデバイス名がちゃんと表示されます。(登録されていない場合はそのデバイスに対して一意に割り当てられたIDが表示されるので、どのデバイスなのか、よくわかりません)

今度はプロンプトブックを使ってみましょう。Entra関連のプロンプトブックに [Microsoft User Analysis] というものがあるので、これを使って特定ユーザーの詳細情報を調べていきましょう。UPNにユーザー名、durationに対象調査期間 (日数) をそれぞれ入れて実行します。

すると1つずつ順番に質問に答えてくれます。
最初の質問：ユーザー情報の詳細教えて
ユーザーの表示名からUPN、ID、作成日などが確認できます。

2番目の質問：ユーザーに関連付けられているデバイスを教えて
Intuneに登録されたデバイスと、そうでないデバイスに分かれて表示してくれます
※そうでないデバイスの一覧は画面が切れちゃって表示されていないです、ごめんなさい

以降は省略しますが、このプロンプトブックでは次のことを質問してくれます。

・上記のユーザーにはどのような認証方法が設定されていますか？
・上記のユーザーは、過去 30 日間にサインインに失敗しましたか? はいの場合、失敗した各サインインの場所とIPアドレスを列挙してください
・上記ユーザーの過去30日間の監査ログを表示してください
・Purviewから上記ユーザーが過去30日間に行った活動をリストアップしてください
・上記ユーザーのMicrosoft  Defender for Identityサマリーを表示してください

こうした情報は自力で頑張ればCopilotを使わなくても確認できます。だけど、どこになんの情報があるかわからない、調べるの面倒、という人は便利だと思います。

便利だけどお高いんでしょ？

それは否定しないです。プロンプトブックにあった8つの質問を投げたら、それだけで5SCUほど消費しました。自分の妻にクレジットカードを渡して自由に買い物をさせるかのような恐ろしさがあります。「エルメスのバーキン買っちゃった！かわいいでしょ？」ってSecurity Copilotが語り掛けてきているようにしか見えませんｗ
あと、従業員雇うのに比べれば安いっていう人がいますが、重課金を経験したことのある私にはそんなこと言えません。

ただ愚痴ばかり言っても始まらないので、効果的な使い方を考えてみましょう。
そもそもプロンプトブックに書いてあること、全部聞く必要あります？
プロンプトブックはブック自体をコピーすればオリジナルのプロンプトブックを作れるので、そこから不要なプロンプトを削除すればスリム化できます。
また、プロンプトブックにある特定のプロンプトだけ実行したければ、そこの文言だけコピペしてプロンプトに打ち込めばよいのです。
例えば先ほどのプロンプトブックにこんなプロンプトがありましたが

From Purview, list the activities performed by above user in the last 30
(Purviewから上記ユーザーが過去30日間に行った活動をリストアップしてください)

これを使いたい場合、プロンプトを次のように書き換えて使うのです。

From Purview, list the activities performed by xxx@xxx.com in the last 30

太字部分にユーザー名を入れて実行すれば、そのユーザーが過去30日で行ったインサイダーリスク管理に引っ掛かった操作があぶりだされます。
下の画面だと5つのファイルを印刷したってことがわかります。

それがわかったら、そこから話を展開していけばよいのです。
例えば「そのユーザーが印刷したファイルを教えてくれ」と聞けば、よろしくないアクティビティの詳細がわかりますよね

このような要領で、わからないから何でも聞いてしまうのではなく、プロンプトのリスクの中から「これよさそう」ってものを選択してピンポイントで質問する
そうすることでコストをある程度抑えながら必要なことを調べられるようになると思います。
Entra関係ない気がしますが参考になれば幸いです。