皆さんこんにちは。国井です。
Microsoft Teamsでチームやチャネルを使ってコミュニケーションを取る際、
チームやチャネルを利用するメンバーを追加して利用すると思います。
しかし、使い続けていると誰がメンバーなのか、
そして追加したメンバーは果たして必要なメンバーなのか
ということがわからなくなるケースもきっとあるでしょう。

そうしたときにAzure AD Premium P2で用意されているアクセスレビューを利用する方法があります。(いきなりライセンス上のハードルが上がった！)
ちょこちょこお客さんにご質問でいただくことがあるので、まとめておきます。

アクセスレビューとは

Azure ADのMicrosoft 365グループ、セキュリティグループやAzure ADに関連付けられたアプリに対するアクセス許可を参照し、不要なメンバーがいないかを確認する、
いわゆる棚卸のためのサービスです。
Microsoft 365グループって、Microsoft Teamsにおけるチームの実体です。
ですので、Microsoft 365グループのメンバーの棚卸をするってことは
言い方を換えればTeamsチームのメンバーの棚卸をするってことでもあります。

アクセスレビューのサービスはAzure AD Privileged Identity Managementのサービスの一部として提供されるものであり、それゆえにAzure AD Premium P2のライセンスが必要になります。

レビューの開始

では早速レビュー(棚卸)を始めましょう。
レビューの設定はAzure AD管理センターのIdentity Governance > アクセスレビューから行います。最初にレビュー対象となるグループを選択し、

続いてレビュー担当者(レビュアー)を設定します。
ここでポイントなのは今見ているウィザードを実行している人(レビュー作成者)と
レビューを実行する人(レビュアー)は異なるユーザーだということです。
もちろん同じユーザーでもいいのですが、特定のチームのメンバーが必要・不要なんて
業務のことがわかっていなかったら判断できないので、
レビュー作成者ではなく、実際にチームを使っている人をレビュアーに指定します。

最後にレビューの詳細設定を行います。
[リソースへの結果の自動適用]ではレビュアーが「この人要らない」と
判断した時にチームのメンバーから自動削除するか？という設定、
[30日間サインインなし]ではサインインのなかったユーザーを
「この人、もう要らないんじゃない？」というアドバイスをしたりします。

以上の設定が完了したら、レビューの名前を設定してできあがり。

レビュアーの作業

レビューを開始するとレビュアーに1通のメールが届きます。
(Teams上で処理できるといいんだけどね)
[レビューを開始する]をクリックしてスタートします。

すると[マイアクセス]のページに飛んで、レビュー画面が表示されます。
ここでチームのメンバー一覧とそれぞれのユーザーが最後にアクセスした日時、
そしてメンバーとして残す、残さない、の推奨事項が表示されます。
これらをもとにレビュアーはメンバーとして残すことを承認or拒否を判断します。

設定はこれだけです。

レビュー作成者側での確認

レビュアーの作業が完了すると、レビュー作成者は
[Identity Governance]画面で、レビュアーの作業結果が確認できます。

以上のような感じで棚卸作業をサービスとして提供してくれるのがアクセスレビューです。
実際に使ってて思うことは「レビュアーの協力は大事」ってことです。

まず協力してくれるような仕掛けを社内に作っていくことも必要ですし、
必要・不要を判断するための「ある程度の基準」を設けておくことも必要だと思います。
なんでもそうですけどツールだけ使えばOKとか、そんなことはないですよね。

皆さんこんにちは。国井です。
OneDrive for Businessは基本的に自分専用のストレージですが、
共有を設定することで他の人と特定のファイル・フォルダーだけ共有でき、
PPAPの代わりとしても重宝されていたりすると思います。

一方、安易に共有を設定することで、設定した本人も把握していない共有ができてしまい、
共有が放置されるというセキュリティ的によろしくないことが起きるわけです。
定期的に棚卸をしましょうというのは簡単なことですが、
実際にそれを各人にお任せしていたら間違いなく棚卸は一生行われないでしょう。

そこで今日トライしてみたいのは
Microsoft Cloud App Security(MCAS)のファイルポリシーです。

MCASについて

MCASはクラウドサービスの監視を行うCASBのサービスで、
クラウドサービスへのアクセス監視だけでなく、クラウドサービスそのものの監視を行うことも可能です。
どんな監視を行うのか？そしてどんなアラートを出力するのか？についてはMCASのポリシーで定義します。

MCASでポリシーを作成する

MCASで作成可能なポリシーには色々なものがあるのですが、
ここではその中からファイルポリシーについて解説したいと思います。
ファイルポリシーはMCASに連携されたクラウドサービスの中で扱うファイル・フォルダーの監視を行うポリシーで、ファイル・フォルダーが特定の条件を満たすときにアラートを出力する、アクセスをブロックするなどのアクセス制御ができるようになっており、これを利用することで、OneDrive for Businessで使われていない共有を見つけることができます。
実際に設定してみましょう。

MCASのポータルサイトから[ポリシー]-[ポリシーの作成]-[アクセスポリシー]の順にアクセスし、ポリシーを新規作成します。アクセスポリシーにはテンプレートが用意されており、この中から[外部共有ファイルの失効]を選択すると一定期間、ファイルへの変更がない共有フォルダーを見つけてくれます。

デフォルト設定では180日間、ファイルへの変更がない共有フォルダーという設定をしていますが、日数は変更可能です。また、[アクセスレベルが次と等しい]の欄もご覧のように共有レベルに合わせた監査が可能です。

そのほか、条件設定にはアプリ(Office 365、BOX、Dropboxなど)を選択することもできますし、

Office 365内の特定のアプリ(Teams, SharePointなど)を指定することやファイルの拡張子などで指定することも可能です。
マイクロソフトの認定試験に出てきそうな話としてはファイルの属性は作成日と最終変更日時で設定できるので、作成日にしておくことで共有を開始してから〇〇日経ったら強制的に共有解除という機械的な運用もできるわけです。

一方、アラート設定はこんな感じです。

アラートを出力する設定とは別に[ガバナンスアクション]メニューで共有を解除([非公開にする]を選択)したり、ゲストユーザーによるアクセスを制限([外部ユーザーの削除]を選択)したりできます。

アラートを参照

以上のポリシーを作成しておいてみましょう。
しばらくするとアラートが出力されます。

内容を見てみましょう。
WPというフォルダーの中にSurface3Deploymentという、いかにも前から放置されていたようなコンテンツが共有されていたことが確認できます。
(しかも作成日2015年、更新日2016年って..)

アラートは参照するだけでなく、アクションを選択すればアラートが出力されるような事象を放置せずに対処できます。例えば、[非公開にする]を選択すれば共有設定を解除することができますし、ファイル単位であればファイルを削除したり、AIPの分類ラベルを設定したり、することができます。

今回は上記のメニューから[外部ユーザーの削除]を選択してみました。
すると、アラート内の[レポート]でアクションの履歴を参照できます。
今回は2人のユーザーに共有されていたので、ログが2つ出ていることが確認できます。

以上のようにMCASを使って定期的に監視するように構成すれば、ユーザーによって野放図に行われる共有の取り締まりができるので、

OneDrive for Businessの共有 = なんとなく危険そうだから禁止

ではなく、適切ではない使い方を見つけられる仕組みを活用しながら、新しいテクノロジーに入り込んでいくってことを検討したいですね。

皆さんこんにちは。国井です。
前回、MCASのファイルポリシーを使ってOneDrive for Business共有を発見する方法を解説しましたが、ファイルポリシーはOffice 365のためだけのものではなく、AWS, box, dropboxなどのクラウドサービスも監視対象にすることができます。
ですのでboxやdropboxで共有されたコンテンツも古くから共有されたものを見つけてブロックするような運用が可能です。

(このメニューの中から共有をブロックするのであれば[直接共有リンクの削除]などを利用するケースが多いと思います。間違ってたら誰かご指摘を！)

またAWSの場合であれば、S3バケットがパブリックアクセスできるようになっていないか？など気になるわけです。ここでは前回に引き続きMCASを使ってOffice 365以外のアクティビティを監視していく方法を紹介します。

アプリコネクタの登録

MCASではAPI経由で直接クラウドサービスの監視を行う場合、
アプリコネクタという設定でMCASとクラウドサービスの連携設定を行います。
連携可能なクラウドサービスの種類とどんな監視が可能かについては
MSサイトで紹介しているので、そちらをご覧ください。

アプリコネクタの登録方法は上記サイトにも説明があるのですが、AWSの登録方法が少し厄介だったのでここでは備忘録も兼ねて記載しておきます。
登録するときはMCASのポータルサイトから以下の要領で登録します。

このとき、AWS側のパラメーターを登録しなければなりません。
そこで、MCAS側の設定の前に、AWSにアクセスして必要なパラメーターを取ってきます。
ちなみに必要なパラメーターとはアクセスキーと秘密鍵の2つです。

AWSでアクセスキーと秘密鍵を取得

AWSコンソールにログインし、セキュリティ、ID、およびコンプライアンス > IAM をクリックしてユーザーを作成します。作成するユーザーの名前はなんでもよいのですが、重要なポイントは[プログラムによるアクセス]を選択しておくことです。
(※つまりAPIアクセスを認めるってことですね)

ユーザー作成のウィザードを進め、ユーザーに割り当てるロール(AWSではポリシーと呼ぶのかな？)を定義します。
ポリシーは[ポリシーの作成]から新規作成し、

以下の文字列をJSONタブに貼り付けます。

{
“Version” : “2012-10-17”,
“Statement” : [{
“Action” : [
“cloudtrail:DescribeTrails”,
“cloudtrail:LookupEvents”,
“cloudtrail:GetTrailStatus”,
“cloudwatch:Describe*”,
“cloudwatch:Get*”,
“cloudwatch:List*”,
“iam:List*”,
“iam:Get*”,
“s3:ListAllMyBuckets”,
“s3:PutBucketAcl”,
“s3:GetBucketAcl”,
“s3:GetBucketLocation”
],
“Effect” : “Allow”,
“Resource” : “*”
}
]
}

続くウィザード画面では作成したポリシーの名前を設定することになりますので、
名前も登録しておきます。ここまでできたら、ユーザーの作成は完了です。
すると、アクセスキーIDとシークレットアクセスキーが表示されるので
(※OAuth2.0のクライアントIDとシークレットのことですね)
文字列を控えておきます。

CloudTrailで証跡を作成

AWSコンソールにログインし、管理とガバナンス > CloudTrail をクリックしてAWSのアクティビティを収集できるようにします。(もうお気づきだと思いますが、MCASはCloudTrailに格納されたデータにAPI経由でアクセスし、監視を行っています)
CloudTrail画面から 証跡 > 証跡の作成 をクリックし、

証跡を保存するS3バケットを作成し、

証跡を残すイベントを選択します。ここで選択した内容がMCASから参照できる内容になります。

設定が完了したら保存して終了しましょう。

MCAS側の設定

MCASに戻って、AWSでユーザーを作成した時に生成されたアクセスキーIDとシークレットアクセスキーをそれぞれアクセスキーと秘密鍵に入力します。
これで[接続]ボタンをクリックすれば、できあがり。

しばらくすると、MCASの 調査 > アクティビティログをクリックすると、
AWSのアクティビティがすべて表示されます。

ご覧のような画面が表示されるので、
いつログインをしたか？とか、
root userが使われたか？とか、
MFAが有効になっていないとか、
そういったことが確認できると同時に
ログイン後の操作(上の画面だと「Account Summaryの表示」)も表示されます。

少し話は外れますが、アクティビティログではログに対するフィルターも設定することができ、下記のようなフィルターを設定すれば絞り込みができますし、
[検索に基づく新しいポリシー]をクリックして、ポリシーを作成し、
アラートを出力したり、アクセスをブロックしたりすることができます。

ポリシーの作成

アクティビティログに表示された内容からも確認できるように、アプリコネクタを使ってクラウドをMCASと連携させることによってクラウドサービスのリアルタイム監視ができるようになります。そして、その中からどのような条件の時にアクセスをブロックするか？などの条件をポリシーで作るわけです。例えば、前にも登場したS3バケットのパブリックアクセスを発見してブロックしたいということであれば、
MCASポータルからポリシー > ポリシーの作成 > ファイルポリシー を選択し、
ファイルポリシーに最初からテンプレートで[パブリックにアクセス可能なS3バケット]というのがあるので、これを選択するだけで監視を始められます。

テンプレートのデフォルト設定ではアラートを出力するだけになっているので、
[ガバナンスアクション]メニューから[非公開にする]にチェックをつけておけばブロックの設定ができます。

こんな感じでアプリコネクタにクラウドサービスを追加すれば、監視対象は広げることができるのでお勧めなんですが、この機能の最大の欠点は接続可能なクラウドサービスが少ない！ってことです。MCAS自体はずいぶんと前からあるクラウドサービスですが、この数年で接続可能なクラウドサービスが追加されたことはないので、この先もあまり期待はできなさそうです。。

今回は紹介しませんでしたが、MCASのポリシーにはファイルポリシー以外にも、ログインを監視するアクティビティポリシーやコピペ等の特定操作の監視をするセッションポリシーなどいろいろなポリシーがあるので、機会があればまた紹介できればと思います。

皆さんこんにちは。国井です。
日経BPさんの書籍「ひと目でわかるIntune」を執筆するにあたり、Intuneのプロファイルを操作していたのですが、その中で書籍に書ききれなかったものにeSIMプロファイルの展開というのがあります。

SIMといえば、これまでは携帯キャリアと契約してSIMカードと呼ばれるものをもらい
それをスロットに差し込んでデータ通信をしていました。

しかし時代は令和。

イマドキはeSIMと呼ばれるものを利用することで、パラメーターをセットするだけで
物理的なカードを挿さなくてもデータ通信が始められるのです。
話には聞いたことがあるけど、自社で実装しても大丈夫かしら？と思っている
IT管理者の方の参考になれば幸いです。

eSIMの契約

携帯キャリアと通信契約を結ぶ場合、SIMカードによる契約とeSIM契約は
契約自体が別々になっていることが多いので、最初からeSIMの契約を結んでください。
eSIMの設定をIntune経由で配る場合、以下のパラメーターが必要になりますので
これらを用意できるキャリアであることを確認してください(←ここ大事！)。

・ICCID (SIMに対して割り当てられる識別子)
・Subscription Manager Data Preparation サーバーのURL
・Matching ID

通常、eSIM契約を結ぶとQRコードが発行され、そのQRコードを対象となる携帯電話で読み取ってアクティベートします。ちなみにQRコードにはSubscription Manager Data Preparation サーバーのURLとMatching IDが含まれているので、Intune経由で展開する場合であれば、QRコードに書かれた文字列を解読し、この2つの情報を取り出しておいてください(解読するって簡単に言ってるけど、QRコードに書かれた内容を解析するツールって世の中にいっぱいあると思いますので、そうしたものを使って文字列を取り出してくださいって意味です)。
また、ICCIDはQRコード内に情報がないため、別に情報として事前に入手しておく必要があります。(ちなみに事前検証する場合、自分でQRコードの解読とICCIDの入手をしなければならず、結構苦労しました。こっちから言わなくてもQRコードに書かれている情報を文字列で別に送ってきてくれたIIJ mioさん、ありがとう！)

Intuneの設定

Microsoft Endpoint Manager admin center画面で、デバイス > eSIM 携帯ネットワーク プロファイル よりeSIMプロファイルを展開する設定ができます。
設定は[追加]ボタンからCSVファイルを登録するだけ。
ちなみにCSVファイルは

1行目にSubscription Manager Data Preparation サーバーのURL
2行目以降にICCIDとMatching IDをカンマで区切って記述したものを用意しておきます。

なので、Subscription Manager Data Preparation サーバーのURLがadfs.jp
ICCIDが12345
Matching IDがaaa-bbb-cccだとしたら、

adfs.jp
12345,aaa-bbb-ccc

という感じで書きます。
複数のICCIDとMatching IDを登録するのであれば、3行目以降に続けて書いていってください。正しく登録が完了すれば、[アクティブ化コード]欄の数字がゼロではなくなります。

Windows 10側の設定

Intuneからプロファイルを受信すれば勝手にeSIMの設定が完了するので、何もすることはありません。[eSIMプロファイルの管理]画面にアクセスすると、eSIMプロファイルが登録されていることが確認できます。ここで[使用]ボタンをクリックすれば、使用開始できます。

あとは、必要に応じて接続・切断を繰り返すだけ。

展開結果はポータルサイトからもデバイス名とICCIDがマッピングされた形で確認できます。

■ ■ ■

IntuneからeSIMプロファイルを展開する上で一番大変なのはCSVファイルを作るための情報集めであり、それさえできてしまえば、とても簡単に展開できます。
iOS/Androidだけでなく、WindowsでもeSIMを搭載したデバイスが登場してきているので、これから使う機会が増えそうですね。

皆さんこんにちは。国井です。
2021年6月10日に日経BPさんから書籍「ひと目でわかるIntune」が発売されますが、色々な事情で書籍の中に入れなかったトピックがあるので、今日はそれを紹介したいと思います。

Microsoft Intuneに登録されたデバイスからイベントビューア等のログを収集する方法についてです。

Windowsデバイスのトラブルシューティングを行うときって、イベントログを見たり
関連するログを見たりすると思うのですが、それってクライアントコンピューター上で操作しなければなりません。そこでIntuneではデバイスのイベントログを含む、様々なログ情報をまとめて収集できる方法を新しく提供しました。

Intuneでのログ収集設定

設定は簡単で、Microsoft Endpoint Manager管理センター画面から
デバイス > すべてのデバイスより特定のデバイスを選んで、[診断の収集]をクリックするだけ。

あとはしばらくするとデバイス画面の[ログ収集]メニューより収集したファイルをダウンロードできます。(上の画面と下の画面で、デバイス名が異なりますが気にしないでください)

収集したファイルの中身

ダウンロードしたファイルはZIPファイルで展開すると、1から50までの数字が書かれたフォルダーがいっぱいできあがります。そのフォルダーとは別にresults.xmlというファイルがあり、このファイルを開くとそれぞれのフォルダーの中に入っているコンテンツが確認できます。

results.xmlファイルを開き、タグの項目に上から番号を振ると、その番号の項目がフォルダー内に入っている内容になります。

例えばXMLファイルの一番上のタグにはHKLM\Software\Microsoft\IntuneManagementExtensionと書いてあります。
この項目は一番上の項目になりますので、番号は1となります。
それがわかったら、ZIPファイル内の1フォルダーを開きます。
すると、export.regというファイルが入っていることがわかります。
つまり、このファイルの内容はレジストリHKLM\Software\Microsoft\IntuneManagementExtensionの設定内容が入っていることになります。

こんな感じで50個のフォルダーにはXMLファイルに書かれた、様々な内容が保存されています。いくつか代表的なログとその使い方について見てみましょう。

フォルダー1 IntuneManagementExtension

IntuneでWindowsデバイスの管理を行う際、Intune Management Extensionエージェント経由での管理を行うケースがあります。このエージェントが正しく動作していなければPowerShellスクリプトを展開するなどの操作ができなくなるため、フォルダー1に保存されている.regファイルを参照し、Intune Management Extension関連のレジストリ設定が正しく構成されているか確認します。
ただし、現実にはレジストリのなかみを見て正しいか判断することは難しいので、正しく動作しているデバイスからもログを収集し、2つのレジストリ設定を比較することで問題となっている個所を突き止めていきます。

フォルダー4  LogonUI

Windowsデバイスに最後にサインインしたユーザーの情報が参照できます。イベントログから参照することも可能ですが、サインインユーザーの情報だけ参照したいということであれば、こちらのほうが便利でしょう。

フォルダー10 Uninstall

コントロールパネルに表示されるアンインストールするアプリの一覧情報が参照できます。
つまりデバイスにインストールされたアプリの一覧ってことです。
Intuneではソフトウェアインベントリの情報を収集してくれる機能がありますが、
すべての情報を集められるわけではないので、Uninstall情報を使って参照するとよいでしょう。

フォルダー13,14 certutil.exe

クライアントデバイス上でcertutil.exeコマンドを実行し、デバイス・ユーザーにインストールされた証明書の情報を参照できます。Intuneから配った証明書であれば、構成プロファイルのログから参照できますが、それ以外はこの方法を採らなければなりません。

フォルダー23 WLAN

デバイスが過去に接続したWi-Fi一覧を参照します。
これはWindowsデバイス上でnetsh.exe wlan show profilesコマンドを実行して得られた結果をもとにしています。

フォルダー39 IntuneManagementExtension\logs

前にも言ったようにIntune Management ExtensionエージェントはIntune経由でPowerShellスクリプトの実行を担当します。
エージェント経由で実行されたスクリプトがある場合、フォルダー39の中にあるIntuneManagementExtension.logファイルを参照すると確認できます。

フォルダー42 Battery

デバイスのバッテリー情報を参照できます。
バッテリーの充電がxx%という話だけでなく、フル充電でどのくらい充電されるか(Full Charge Capacity)を見ることでリチウムイオン電池の消耗具合を見たり、時間ごとのバッテリーのxx%という履歴情報を参照したりできます。

フォルダー46,47

MECMと共同管理を行っている場合、IntuneからMECMクライアントのログを収集できます。
遠隔からクライアントのログを収集すること自体はMECMの機能でも実現できますが、
Intuneからでも収集できますよ、というものです。

■ ■ ■

疲れてきたのでそろそろこの辺にしますが
ご覧のように色々な情報が収集できることがお分かりいただけると思います。
インベントリとして使うには使い勝手が悪いけど、トラブルシューティングにはとても有効な情報が得られますよね。

皆さんこんにちは。国井です。
先日、お客さんに「BreakGlassアカウントって普段使わないから、もしサインインがあったらわかるようにしたいです」とご意見をいただきました。
そりゃそうだよなと思い、BreakGlassアカウントでAzure ADにサインインしたらアラートのメールが送信されるような仕組みを作ってみることにしました。

BreakGlassアカウントとは
マイクロソフトの公式ドキュメントで「緊急アクセス用管理者アカウント」と紹介されているアカウントで、普段使っている管理者アカウントが使えなくなった時のために予備で用意しておくアカウントのことです。
このアカウントには多要素認証や条件付きアクセスをいっさい設定しないという実装をするため、めちゃ長いパスワードを設定しましょう！というベストプラクティスがあるのですが、それでも不正アクセスは怖いですよね。
だからサインインがあったらメールで通知するように設定したいのです。

実装のアイデア

BreakGlassアカウントでサインインがあったらサインインログに記録されるので、
ログを監視して該当のサインインがあったら管理者にメールを送信という設定をすればよい、というのは誰でも思い浮かぶところだと思います。
しかし、サインインログをMicrosoft Graphで収集し、そこにクエリを実行をして.. というのを定期的に実行するにはハードルが高いのです。
そこで私はLog Analytics(Azure Monitorって言うのが正解？いまだに2つの違いがよくわからない..)を利用することにしました。

ライセンス

サインインログをLog Analyticsで収集する場合、
サインインログをLog Analyticsに転送するためのライセンスとしてAzure AD Premium P1
Log Analyticsにログを保存できるようにするためのライセンスとしてMicrosoft Azure
がそれぞれ必要になります。
うちの会社の場合、小さな会社過ぎて参考にならないかもですが、10名程度のユーザーがサインインする会社で90日ログを保存して50MB程度の保存量でした。

サインインログをLog Analyticsに転送

過去にLog Analyticsにサインインログを転送する方法については解説していますので、こちらを参考にしてください。

BreakGlassアカウントでサインインしたら.. というクエリを作成

AzureポータルからLog Analyticsにアクセスし、[ログ]という項目をクリックすると、
クエリの実行画面に移動できます。Log AnalyticsのクエリはKusto (KQL) と呼ばれるクエリ言語を採用していて、BreakGlassアカウントのサインインをクエリで引っ張ってくる場合、こんな感じに書きます。

SigninLogs
| where Identity contains “breakglass”

ちなみにbreakglassって書いてある部分がユーザー名です。ユーザー名はUPNではなく表示名で書いてください。さらに、このクエリから結果の表示を絞り、サインイン日時、ユーザー名、結果、サインインアプリの4種類だけが表示されるようにカスタマイズしました。

SigninLogs
| where Identity contains “breakglass”
| project TimeGenerated, Identity, ResultType, AppDisplayName

これを実行した結果がこちら。

過去のサインインが表示されていることがわかりますね。

アラートの作成

最後にBreakGlassアカウントでサインインがあったら管理者にメールを送信というアラートを作ります。アラートは上の画面にある[新しいアラートルール]と書かれているところをクリックすると作れます。
作成画面を見てみましょう。
まずは[条件]項目。ダミーの条件が入れてあるのでリンクをクリックして..

シグナルロジックというのを作成します。
ここでは、アラートロジックに結果の数が1以上だったらという条件を入れます。
次に評価基準では期間1分、頻度1分と設定し、1分ごとに過去1分ぶんのクエリを実行するという基準を定義しました。設定できたら完了をクリックして元の画面に戻りましょう。

次に[アクショングループ]項目をクリックして、設定します。

ここではアクショングループというのを作るのですが、具体的には送信先となるメールアドレスを定義します。アクショングループの作成をクリックして、以下の画面ショットを参考にメールアドレスを登録しましょう。

設定が完了したら、再びアラートルールの作成画面に戻ってきて、あとはメールの件名とアラートルールそのものの名前を適当につけておきます。

これで完成です。
では実際にBreakGlassアカウントでサインインしてみましょう。
サインインを行うと、およそ1分ぐらいの後にメールが届くことが確認できます。

View 4 resultsって書いてありますけど、この下の画面(画面からは切れて見えないですが)に
クエリの実行結果がそのまま参照できます。

Azure Sentinelでも同じことできますよね？

って思った方は流石です！
ただLog Analyticsに比べるとログそのものが出力されるまでのタイムラグが大きく、即時性という点ではLog Analyticsに軍配が上がるように感じました。やっぱりSentinelだと経由するポイントが多くなる分だけタイムラグが大きくなってしまうのでしょうね。

皆さんこんにちは。国井です。

今日は2021年6月10日に発売開始した「ひと目でわかるIntune」からページ数の関係で載せられなかったトピックについてです。

Microsoft Intune では構成プロファイルをはじめ
様々な項目を通じて様々な設定を管理対象デバイスに施すことができます。
一方、「様々な設定ができる」と言われても具体的に何をすればよいかわからないという方もいることでしょう。セキュリティ設定であればCIS Benchmarksのようなベストプラクティスを提示してくれるのもいいけど、できればうちの会社に足りないものを指摘して必要なものだけを適用したい。

そんなときはMicrosoft Defender for Endpoint(MDE)で参照可能な脆弱性管理設定を
Microsoft Intune 側で使えるようにする方法があります。
(いきなりMicrosoft 365 E5が必要なパターン！)

MDEの脆弱性管理ってなに？

MDEはもともとEDR製品であり、インシデントが発生した時に役立つなにかを提供してくれます。しかし、最近はオンボーディングされたデバイスの脆弱性を見つけて報告・対処方法をアドバイスしてくれるようになっています。
MDEの管理もできるMicrosoft 365 Defender (https://security.microsoft.com) 画面の 脆弱性の管理 > 推奨事項 では組織全体で修復すべき脆弱性が一覧で表示されています。

Intune連携して脆弱性管理

MDEで脆弱性一覧を知ることができれば便利だけど、「そういう脆弱性があるんですね」だけでは具体的なアクションに落とし込んでいくことができません。
そこでIntuneを利用して各種設定を行い、脆弱性をつぶしていくのです。
Microsoft 365 Defenderの設定画面にアクセスするとIntune接続という項目があるので、これを使ってまずは連携を行うように定義しておきます。

脆弱性管理をはじめよう

再びMicrosoft 365 Defenderの画面に戻ります。

上の画面ではPythonの更新が画面一番上に出ているので、クリックすると下のような画面が出てきて詳細が確認できます。ここから[露出されたデバイス]をクリックすれば、どのデバイスでその脆弱性があるのかを確認できます。
このメニューの中で[修復の要求]というのがありますが、これをクリックすると、、

修復作業のためのチケット管理ができるようになります。
この時に[Microsoftエンドポイントマネージャーでチケットを開く]にチェックをつけておくと、修復作業の情報がIntuneに転送されます。

Intuneに転送されたタスクがこちら。Microsoft Endpoint Manager admin centerのエンドポイントセキュリティ > セキュリティタスクに入ってきます。

個別のタスクをクリックすると、具体的にどのような作業を行うべきか案内をしてくれます。
[許可]をクリックするとタスクが始まり、

[完了]をクリックするとタスクが完了します。

Intuneのセキュリティタスクはただのタスク管理

許可ボタンをクリックしてから、完了ボタンをクリックするまで、何も動きはありません。
そう、Intuneのセキュリティタスクのメニューはただのタスク管理をするだけのメニューであって、脆弱性を修復するための設定を自動的に行ってくれるものではありません。
ですから、前の画面でいえばPythonの更新ってありましたけど
Pythonの新しいバージョンをIntune管理者がアプリから自分で展開設定してくれ
とお願いしているに過ぎないのです。

改めてチケット管理という観点から見てみる

今度はチケット管理だと割り切ってみてみましょう。
会社の中でセキュリティ管理者とIT管理者が分かれて日常の運用を行っている場合、

見つかった脆弱性のうち対策が必要なものを選択する業務
→ セキュリティ管理者

具体的な脆弱性対策のソリューションを実装する業務
→ IT管理者

のように分かれることが通常だと思うのですが、MDEとIntuneの関係もそれに沿った形になっています。それを踏まえ、Microsoft 365では…

セキュリティ管理者
→ Microsoft 365 Defender画面で対策が必要な脆弱性をピックアップしてIT管理者へ転送

IT管理者
→ セキュリティ管理者から送られてきたタスクをIntuneで実装

という流れでのタスク管理を用意しています。
じゃあ、もう一度流れを見てみましょう。

1．セキュリティ管理者がMicrosoft 365 Defender画面で、脆弱性を選んで修復要求を設定
このときに修復方法、期日、優先度とともにメモを入れておくことでIT管理者への申し送りができます。

2．IT管理者がIntuneのセキュリティタスクで設定すべき内容と手順を確認。
作業を開始する段になったら、[許可]をクリック。
(このときメモ欄が登場するのでメモ書きができる。docsによればMDEに送られるとあるが、どこへ行くかは不明)

3．IT管理者による修復作業(この場合は新しいOfficeアプリケーションのインストール)が完了したら、セキュリティタスクで[完了]をクリック。

4．Intuneのセキュリティタスクで完了したことはMicrosoft 365 Defenderの脆弱性の管理 > 修復から確認できる(画面の[チケットのステータス]欄のところ)。
ところが[デバイスの修復状態]は進行中のままであることがわかる。
つまり、IT管理者からは管理者の判断によって「終わりましたぜ！」と連絡をもらうのだが、
MDEは自身の脆弱性管理の仕組みにより脆弱性が取り除かれたかをチェックしているため、修復状態に変化がなければIT管理者がちゃんと仕事していないことがわかる。

5．もしセキュリティ管理者から見て脆弱性が取り除かれたと判断できる材料
(例えば[デバイスの修復状態]の項目が[完了]になったとか)がそろったならば、
最後にMicrosoft365 Defenderの修復項目を開き、[完了としてマーク]をクリックすれば脆弱性管理が完了したことになる。

脆弱性管理で「設定」を管理

今度は修復すべき脆弱性がソフトウェア更新ではなく、
レジストリを変更するなどの設定の場合についてみてみましょう。
設定を変更することによって脆弱性を修復するケースでは[ユーザーへの影響]という項目が出てきます。ここでは、もし理想の設定を行った場合、影響が起こりえるか？ということを案内してくれます。(これ、憶測でモノをいっているのではなく、ちゃんと過去45日間のアクティビティを見て判断してくれてます)

これもソフトウェアの更新の時と同じく[修復の要求]をクリックすると、Intuneにタスクが転送されます。Intune側ではご覧のような案内が表示されるのですが、「ソフトウェアの更新をしろ！」という雑な案内ではなく、構成プロファイルのどこを設定すれば脆弱性を潰せるかをちゃんと案内してくれていることがわかります。

■ ■ ■

最後は取り留めもない話になってしまいました..
IT管理者とセキュリティ管理者で連携が必要なケースってあると思います。
そのときにチケット管理専門のツールをいれるのもいいですが、Microsoft 365 E5の範疇でできることもありますよ、というのを今回は見てもらいました。
誰かの参考になれば幸いです。

皆さんこんにちは。国井です。
今日も「ひと目でわかるIntune」書籍の出版記念で
Azure ADの設定をMicrosoft Intuneから実装という話をします。
具体的にはタイトルにもあるようにAzure AD参加デバイスのローカル管理者の設定をMicrosoft Intuneから設定する方法です。

以前、ブログでAzure AD参加デバイスのローカル管理者について言及し、その時はDevice  AdministratorsロールまたはAzure AD 参加済みデバイスのローカル管理者ロールが割り当てられたAzure ADユーザーはすべてのAzure AD参加デバイスのローカル管理者になるという話をしました。

一方、このやり方ではテナントのすべてのデバイス一律でローカル管理者が設定されてしまうため、標的型攻撃のラテラルムーブメントが心配だという話もしました。
そこで、今回はデバイスによってローカル管理者となるユーザーは異なるように設定したいと思います。この野望を実現するのに登場するのがMicrosoft Intuneの
構成プロファイル > カスタムから設定できるOMA-URIです。
(※OMA-URIそのものの説明はIntune本で解説しましたから、そちらでどうぞ)

ローカル管理者を定義する設定では以下のOMA-URIを用意し、デバイスごとに異なるローカル管理者となるユーザーを指定できました。

./Device/Vendor/MSFT/Policy/Config/RestrictedGroups/ConfigureGroupMembership

しかしこのOMA-URIには既存の設定を上書きしてしまうという欠点がありました。
そこでWindows 10 20H2から代替となるOMA-URIが登場しました。

./Device/Vendor/MSFT/Policy/Config/LocalUsersAndGroups/Configure

今日はこれを使ってAzure ADユーザーをローカル管理者となるような設定をしてみたいと思います。

ローカル管理者を追加するための準備

今回のOMA-URIを使ってローカル管理者となるAzure ADユーザーを追加する場合、ユーザーのSIDを追加しなければなりません。Azure ADユーザーのSIDなんて知らんがな！と思っていたら、なんとAzure ADユーザーのオブジェクトIDから一定のルールでSIDって生成されるのですね。しかもGithubにオブジェクトIDからSIDを変換してくれるスクリプトまで公開されてる！ありがとう!, Thank you!, Danke!

これを使って変換してみましょう。
今回、Azure AD参加デバイスのローカル管理者になる人はこの人です。
Azure AD管理センターからユーザーのプロファイルを開き、オブジェクトIDを確認しておきます。

続いてGithubからスクリプトをコピペして実行し、、

その後、$objectIDという変数を作って、さっき調べたオブジェクトIDを入れましょう。

ここまでできたらConvert-AzureAdObjectIdToSid関数で-objectidスイッチを伴って実行します。すると、S-1-12-で始まるSIDが生成されました！

OMA-URIでローカル管理者となるユーザーを指定

続いてマイクロソフトdocsの説明を参考に管理者の指定をしましょう。

Intuneの管理センター画面から
デバイス > 構成プロファイル > カスタム
の順にアクセスし、OMA-URIのプロファイルを作成します。パラメーターは以下の通り。

■名前：なんでもよい
■OMA-URI：
./Device/Vendor/MSFT/Policy/Config/LocalUsersAndGroups/Configure
■データ型：文字列
■値：XML形式で記述

値の部分はこんな書式で記述します。

<GroupConfiguration>
<accessgroup desc = “Administrators”>
<group action = “U” />
<add member = “AzureAD\bob@contoso.com”/>
<add member = “S-1-12-1-1111111-222222222-33333333-44444444″/>
</accessgroup>
</GroupConfiguration>

順番に説明すると、
<accessgroup desc = “Administrators”>部分がAdministratorsグループ、
<group action = “U” /> 部分が追記しますよという指定、
<add member = “AzureAD\bob@contoso.com”/> 部分が管理者となるユーザー名
(AzureAD\aaa@bbb.comのように記述します)
<add member = “S-1-12-1-1111111-222222222-33333333-44444444″/> 部分がSID
となります。

こんな感じで指定できたら保存して、あとは該当となるユーザーまたはデバイスに割り当てればできあがり！同期を行って結果を見てましょう。
同期前がこちら

そして同期後がこちら

ローカルAdministratorsグループにAzure ADユーザーが追加されたことが確認できました！
ちょっと設定は面倒かもしれないですが、こうやってIT管理者にとっての不安要素を取り除いていけば理想のAzure AD管理に近づけると思います。

皆さんこんにちは。国井です。
2009年6月30日にブログをスタートさせてから今日で12年経つのですが
12年目となった、この1年間でどのようなページへのアクセスがあったかランキング形式で紹介します。

第1位 ADFSとは？フェデレーションとは？を知る方法 26,641PV

今見るとかなり恥ずかしい文章だなと昔の自分を恥じていたりするのですが、
いまだによく見られているページです。
文章に登場するアンドリューさん(通称 アンディ)はその後、うちの猫の名前にもなりました。

そういえばパスワードを忘れたときの質問「はじめて飼ったペットの名前は？」を
ゲットしたぜと思ったひと、甘いな。私がそんなの設定するわけないでしょｗ

第2位 【101シリーズ】パフォーマンスモニタ徹底攻略 ～ パフォーマンスの確認編 25,433PV

オンプレミスのお話、いまだに根強い人気があるんですよね..
上の猫の写真に写っている赤い雑誌の連載で書いた内容なのですが、出版社も、版権も、どっか行ってしまったので
ブログで転載をさせていただいた内容です(版権の確認をするも誰にもわからないというグダグダっぷりでした)。

第3位 Azure ADユーザーの属性情報一覧 11,937PV

Azure ADユーザーの属性にどんな属性があるのか？を紹介する投稿というよりは
GUIで用意されている属性がMS Graphにおける正式名がなにになるのか？を解説した内容なんですけど、やっぱり皆困っていたのね。
Azure ADの話としては一番多くみられた投稿でした。

第4位 Microsoft Authenticatorアプリを複数デバイスで利用 8,201PV

多要素認証の話って、Azure ADをよく知る人からしてみれば当たり前すぎる話なんだけど、
実際の導入率って10%程度しかないそうなんです。
ですので、これからの人に刺さった話なのかなと勝手に推測しています。
多要素認証・パスワードレス認証は今後もコンテンツを増やして啓蒙できればいいなと思っています。

第5位 ADFSとAzure ADの違いを比較してみよう 7,938PV

ADFSを導入してシングルサインオンの環境を使っているけど、
Azure ADなどのクラウドIdPも良いみたい、どうしようかな？
という方に読まれている投稿です。
ADFSからAzure ADに切り替えたいと思っても、
上司やステークホルダーたちを納得させ、予算を引っ張ってこなければならないので、
そうしたときに役立つ情報になればと思って書いてみました。

■ ■ ■

年間で450,000PV程度あるサイトの中で、どんなページがよく見られているかについて紹介しました。
昔は毎年、年初に紹介していたのですが、何年たっても同じランキングだったので書くこと自体やめていたのですが、最近やっと変化が現れるようになったので、紹介させていただきました。
なにが流行りなのかなど、参考になればうれしいです。

皆さんこんにちは。国井です。
Microsoft Defender for Endpoint (MDE) ってセキュリティ対策を行う上で何が便利なの？という話を聞きます。

EDRとしての適切なインシデント対応だったり、インシデント対応自体が簡単にできますよ、という話だったりはあちこちで聞く話だと思いますので、今日はそこから視点をずらして、タイムラインという機能を利用することによる便利さを紹介します。

タイムラインというのはMDEの管理対象となるデバイスで、どのようなファイルアクセスやネットワークアクセスなどがあったかを追跡できる機能で、これを利用することによって、不正アクセスの履歴を追跡できたり、またはトラブルシューティングの目的で使ったりできるのです。
トラブルシューティング？って思うかもしれないですが、案外便利なんですよ。
私たちが普段ネットワークがらみのトラブルシューティングをしましょうと言ったらWireSharkを使う方法やFiddlerを使う方法などを思い浮かべると思います。しかし、どちらのツールもローカルにインストールしなければならないという欠点があります。そこでもしMDEが皆さんの会社で使われているのであれば、これを使って履歴を追跡していけば、なぜアプリが動かないのか？とかなぜネットワークアクセスに失敗するのか？とか、そうした情報をクライアント上での操作を行うことなくトラブルシューティングできるというメリットがあるのです。
本当にトラブルシューティングで使うかどうかは別として、
今回はPowerShellからMicrosoft Graphを使ってMDEのログを収集するというスクリプトを実行した場合、
どのようなファイルアクセスがあるか？
どのようなネットワークアクセスがあるか？
を追跡しながら、MDEのタイムラインの見かたをチェックしてみたいと思います。

前提条件

ここではPowerShellからMicrosoft Graphを利用してMDEのアラートログを参照するスクリプトを実行し、その実行の様子をMDEから参照してみます。

前提条件～MDEの契約とオンボーディング

MDEはMicrosoft 365 E5または単体ライセンスで購入できます。無料試用版もありますので、お持ちでない方は無料試用版でスタートしましょう。

無料試用版をゲットしたらオンボーディングスクリプトをダウンロードし、管理対象となるデバイスにインストールしましょう。登録が完了すると、Microsoft 365 セキュリティ管理センター画面にデバイスが表示されます。

前提条件～アプリの登録

また、APIアクセスにはAzure ADで[アプリの登録]を利用してアプリを登録しておく必要がありますので、Azure AD管理センター画面で [Azure Active Directory]-[アプリの登録]から次のパラメーターでアプリを作成しました。

■作成時の設定
・名前：MDATP
・アカウントの種類：この組織ディレクトリのみに含まれるアカウント
・リダイレクトURI：なし

■作成後のアプリの登録の設定
・クライアントシークレットを作成し、値を保存
・APIのアクセス許可：APIの種類として[所属する組織で使用しているAPI]を選択し、アプリケーションの許可としてAlert.Read.Allを追加

APIのアクセス許可は設定が完了したら、管理者の同意を設定することもお忘れなく。

前提条件～スクリプトの準備

MS GraphでAPIアクセスする場合、アクセストークンを取得するまでのプロセスとアクセストークンを提示してAPI経由でデータを取得するプロセスに大きく分かれるので、この2つがわかりやすいようにスクリプトを分けてみました。
(‘テナントID’、’クライアントID(アプリケーションID)’、’クライアントシークレット’に記載されている情報は前の手順で作成したアプリの登録の中に情報があるので、それをコピーして使ってください)

■アクセストークンを取得するスクリプト (Get-Token.ps1)

$tenantId = ‘テナントID’
$appId = ‘クライアントID(アプリケーションID)’
$appSecret = ‘クライアントシークレット’

$resourceAppIdUri = ‘https://api.securitycenter.windows.com’
$oAuthUri = “https://login.windows.net/$TenantId/oauth2/token”
$authBody = [Ordered] @{
resource = “$resourceAppIdUri”
client_id = “$appId”
client_secret = “$appSecret”
grant_type = ‘client_credentials’
}
$authResponse = Invoke-RestMethod -Method Post -Uri $oAuthUri -Body $authBody `
-ErrorAction Stop
$token = $authResponse.access_token
Out-File -FilePath “./Latest-token.txt” -InputObject $token
return $token

■アクセストークンをもとにAPIアクセスするスクリプト (Get-Alerts.ps1)

$dateTime = (Get-Date).ToUniversalTime().AddHours(-24).ToString(“o”)
$url = “https://api.securitycenter.windows.com/api/alerts?`
$filter=alertCreationTime ge $dateTime”
$headers = @{
‘Content-Type’ = ‘application/json’
Accept = ‘application/json’
Authorization = “Bearer $token”
}
$response = Invoke-WebRequest -Method Get -Uri $url -Headers $headers ‘
-ErrorAction Stop
($response | ConvertFrom-Json).value | ConvertTo-Json

なお、この2つのスクリプトは必ず同じWindows PowerShellコンソール画面の中で実行してください。なぜなら最初のスクリプトを実行した結果、$token変数にアクセストークンが入っており、それを使って2つめのスクリプトを実行するからです。

準備ができたら、それぞれのスクリプトを実行してみましょう。

MDEで結果を確認～概要編

MDEのタイムラインを参照するときはMicrosoft 365 Defender画面またはMicrosoft Defender Security Center 画面を使います。
ただ、Microsoft 365 Defenderは画面が見にくいので、ここではMicrosoft Defender Security Center 画面(https://securitycenter.windows.com)を使います。

Microsoft Defender Security Center 画面から[Device inventory] をクリックして該当のデバイスを開くとTimelineタブをクリックして履歴を参照できます。

この中からPowerShellの実行結果を追跡するのであれば、まず検索窓にpowershell_ise.exeと入れてみましょう。
するとPowerShellに関連する実行結果だけが表示されます。

MDEで結果を確認～ファイルイベント編

タイムラインの検索結果から[Filters]をクリックして、さらにフィルターを設定しましょう。いろいろありますけど、まずはFile Eventsを選択してみます。

こちらでは変更したpowershell_ise.exeによって作成したファイルや変更したファイルなど、ファイル単位でのイベントが表示されます。
今回はスクリプトを実行して作成するファイルはありませんので、テンポラリのファイルだけが作られていることがわかります。

MDEで結果を確認～プロセスイベント編

続いてフィルターでProcess eventsを選択してみましょう。
こちらはWindows上で実行したプログラム(プロセス)が一覧で出ていることがわかります。
PowerShellでアクセストークンを取得した様子やpowershell_ise.exeが実行された様子などがわかります。

powershell_ise.exeをクリックすると、その詳細が確認でき、
Get-Token.ps1が実行されたことがわかります。

MDEで結果を確認～ネットワークイベント編

今度は[Filters]をクリックして、Network eventsだけを選択して、powershell_ise.exeによるネットワークイベントだけを表示します。

同じログが2回ずつ出ているけど、PowerShellからAPIアクセスすると次の2つのアクセスがあることがわかります。

https://login.windows.net
https://api.securitycenter.windows.com

それぞれのタイムラインをクリックしてみます。
まずhttps://login.windows.netにアクセスしたログ。
こちらはGet-Token.ps1ファイルからアクセスしたと表示されていることがわかります。

続いてhttps://api.securitycenter.windows.comにアクセスしたログ。
こちらもGet-Token.ps1ファイルからアクセスしたと表示されていることがわかります。

えっ？？https://api.securitycenter.windows.com ってMDEのAPIアクセス時のエンドポイントなんじゃないの？
なんでGet-Token.ps1のアクセス時にこのエンドポイントにアクセスしているの？と思った方、そうですよね！
そこで今度はGet-Alerts.ps1というキーワードで検索してログを出してみました。
この中からpowershell_ise.exe created file Get-Alerts.ps1ファイルを開いてみます。

すると、ご覧のようにGet-Alerts.ps1ファイルはGet-Token.ps1ファイルを実行したpowershell_ise.exeの配下に表示されていることがわかります。
つまり、Get-Alerts.ps1によるネットワークアクセスはGet-Token.ps1を実行したpowershell_ise.exeの配下からのアクセスなので、
画面上はGet-Token.ps1からネットワークアクセスがあったと見えてしまうのです。

どうしてこういうことが起きるかというと、こういう風にひとつの画面の中で2つのタブを開いてスクリプトを実行しているからです。

つまりMDEでネットワークアクセスの追跡を行うときは先に実行したプロセスの子プロセスとしてどんなプロセスが動いていたか？を確認したうえで追跡を行わないと間違った判断を下す可能性があるので注意してください。

MDEで結果を確認～そのほかのイベント編

最後にフィルターでOther eventsを選択してみます。
すると実行したPowerShellコマンドレットのひとつひとつが表示されていることがわかります。これを使えば、単純にPowerShellスクリプトを実行した！というだけでなく、どんなコマンドレットが実行されたかまでが確認できます。

まとめ

今回はPowerShellスクリプトでMicrosoft Graph経由でMDEのログを取得する、という操作を例に出力されたタイムラインを参照してみました。タイムラインはただ単純に眺めているだけではログの羅列にしか見えませんが、Filterを駆使することによって様々な情報をあぶりだすことができます。
そのほかのケースでもタイムラインを使った調査をやってみたいという方、いらしたらMicrosoft 365インシデント対応コースというトレーニングコースを開催していますので、そちらも参加してみていただければと思います。

皆さんこんにちは。国井です。
知られているようで意外と知られていないMCASのポリシーから、Teamsへのゲストユーザーの登録状況を把握する方法について確認します。
(把握する、というよりはゲストユーザーが登録されたらアラートを出力するという言い方が正確な表現になります)

設定はとても簡単でMCASでポリシーを作成するだけ。
もしかしたら一番大変なのはMCASのポリシーを作ることよりも、
MCASのライセンスを買うための稟議を会社で通すことかもしれませんｗ
それは各自で頑張っていただくこととして早速見ていきましょう。

まず、MCASのポータルサイトにアクセスし、調査 > 接続アプリ からアプリコネクタを使ってMCASによる監視対象としたいクラウドサービスを登録します。
ちなみにOffice 365の場合は自動的に登録されるので、登録設定は不要です。
ここへの登録が完了すれば、MCASでの監視がスタートします。

次にポリシーを作成します。
制御 > ポリシー から[アクティビティポリシー]を新規作成します。
ポリシーの新規作成画面では、どのようなアクティビティがあったらアラートを出力するのか？という条件を設定します。
ただ、よく使われる設定が最初から盛り込まれたテンプレートが用意されているので、これを使うとポリシー設定を半自動化できます。

上の画面はポリシーの新規作成画面ですが、ここでテンプレートとして[外部ユーザーが追加されました]を選択すると、、

ご覧のように条件が自動的に追加されたことがわかります。
[フィルター]部分を拡大してみると、TeamsにExternal users(ゲストユーザー)がメンバーとして追加されたら.. という条件が入っていることがわかります。

[フィルター]部分の画面右上に[結果の編集とプレビュー]をクリックすると、条件に当てはまる事象を実際に検索してきてくれます。

Teamsにゲストユーザーが追加されたら.. の条件をもうちょっと工夫して「特定のチームに追加されたら..」という条件にしてみましょう。
フィルター設定にアクティビティIDというのがあるので、これを使うのですが、特定のチームのアクティビティIDってなに？ですよね。その場合にはプレビューで表示された結果から条件を作りましょう。特定のプレビュー結果をクリックし、表示された詳細情報からどこでもいいのでリンクをクリックすると、

ついにアクティビティIDが確認できました！
これを登録するのですが、[フィルターに追加]をクリックすれば自動登録もできます。

登録が完了した様子がこちら。

ここまででポリシーができあがり。
アラートはMCASのポータルサイトで確認できるだけでなく管理者にメールでお知らせしたり
ゲストアクセスに対してそのユーザーを使わせないようにするとか、サインインを改めて行わせるように設定したりすることができます。
すべての設定が完了できたら[作成]ボタンを押せば完了です。

アラート画面はこんな感じで表示されます。
画面上部のアクティビティログ部分が追加されたゲストユーザー、
画面下部のユーザー部分がTeamsでアクセス許可を与えたユーザーがそれぞれ表示されています。

Teamsを使う会社でAzure ADに勝手に作られるゲストユーザーの扱いに困っている会社は多いと思います。
ゲストユーザーの作成は管理者の承認が必要という運用もいいけど、スピーディーな業務の遂行だったり、管理者の手間だったりを考えるとなんでもかんでも管理者の承認が.. っていうのはやりたくない。
そういう時にTeamsへのゲストユーザーの追加は認めるけど、
誰が追加されたかは監視させてね☆という運用にするのも
ひとつの方法としてアリだと思います。

皆さんこんにちは。国井です。
前回MCASを使ってTeamsにゲストユーザーが登録されたことを確認する方法について紹介しました。ゲストユーザーが登録されるとアラートが出力されるので、それで確認できますよという話をしましたが、アラート設定の画面を見ていて気になった方もいるのではないかと思います。

そう、Power Automateのフローが呼び出せるのです！
ということで、今回はMCASでアラートが出力されたらPower Automateを使って
Teamsにメッセージを自動で書き込むという設定を行ってみたいと思います。
(そういえば画面キャプチャを設定するのを忘れてしまったのですが、これから紹介するPower Automateの設定が完了したら、上の画面で[Power Automateにアラートを送信する]にチェックをつけ、作成したフローを選択しておいてください。)

MCASとPower Automateの連携設定

Power AutomateでMCASのアラートをトリガーにする場合、
MCASのAPIトークンを取ってきて、Power Automateで使えるようにする必要があります。
MCASのAPIトークンはMCAS画面の右上にある歯車マークから[セキュリティ拡張機能]をクリックし、[APIトークン]タブから新しくトークンを作成します。

生成されたトークンを控えておきます。

Power Automateのフローを作る

続いてPower Automate画面に移動します。
左側の[コネクタ]をクリックし、コネクタ一覧からCloud App Securityを見つけたら、[アラートが生成される時]をクリックすると、フローを作り始められます。

表示されるフローから接続名とAPIキーをそれぞれ入力します。
接続名は単なるラベルなので適当な名前を、そしてAPIキーには先ほど取得したトークンを入力します。

次に[新しいステップ]をクリックして、Teamsのステップを登録しましょう。
この中から[メッセージを投稿する]を選択すれば、チームにメッセージを書き込むことができます。

メッセージにはAlertDisplayNameとDescriptionを追加しました。

ここまでを踏まえて、実際にTeamsに外部ユーザーを追加してみると..

違う、違う、そうじゃない！
Descriptionを指定することで表示される内容は説明欄にある内容なのですが、
実際に見たいのはそっちじゃなくて、下段にある[アクティビティ]の部分なんですよ。
だって、[アクティビティ]欄には追加された外部ユーザーの名前が書いてありますから。

Teamsに書き込むメッセージの内容はDescription以外にもいろいろあるのですが、どれを指定しても[アクティビティ]欄の内容は出力されず..
なにか良い出力方法ないもんですかね。

【参考URL】チュートリアル:エンドポイントの修復までガバナンスを拡張する
https://docs.microsoft.com/ja-jp/cloud-app-security/tutorial-flow

皆さんこんにちは。国井です。
今日は普段のトレーニングで時間の都合や優先順位の関係上、省略してしまうことの多いAzure ADの基本機能を紹介してみたいと思います。
今回はOpenID Connect (OIDC) でSaaSアプリと連携する方法についてです。

SaaSアプリとAzure ADで連携する場合、SAMLプロトコルを使うことが多いですが、
SAMLプロトコルはIdPとSPでそれぞれ連携のための設定を行う必要があります。
フェデレーションメタデータを使うなどすれば、多少の設定は簡単になりますけど、
それでもそれなりの設定は必要です。

一方、SaaSアプリがOIDCに対応している場合、これから見てもらうように
連携するボタンを一発クリックするだけで設定完了というお手軽実装になっています。

前提条件

今回はサンプルとしてeHourというSaaSアプリを使ってみます。
サイトにアクセスして評価テナントを取得しておきましょう。

登録設定

SaaSアプリの登録は
Azure AD管理センターのエンタープライズアプリケーション > 新しいアプリケーション から行います。検索窓からehourと入力すると、候補が出てきます。

エンタープライズアプリケーションから登録可能なSaaSアプリにはSAMLで連携できるもの、OIDCで連携できるもの、パスワードをデータセンターにキャッシュさせて連携できるものがあります。
OIDCで連携可能なアプリ一覧は新しいアプリケーションを登録する画面で
シングルサインオン＝OpenID Connectとなるようにフィルター設定すれば確認できます。

話を元に戻します。
前の画面からeHourが出てきますがOIDCの場合、エンタープライズアプリケーションを登録する必要はなく、eHourサイトからAzure ADと連携するように指定するだけで完了します。

ということで、eHourのサイトに移動します。
eHourの評価版を取得したユーザーでログインし、
歯車マーク > Single Sign On > Connect with Microsoft Azure の順にクリックします。

Connect with Microsoft Azureをクリックすると、OIDCではおなじみの同意画面が登場します。[承諾]をクリックして同意してください。これで連携設定は完了です。

設定ができたら、一度ログアウトし、もう一度ログインしなおします。

このとき、[Log in with Microsoft]というボタンをクリックすると、
OIDCでのシングルサインオンが行われ、eHourのページにアクセスできるようになります。

設定結果の確認

Azure ADのエンタープライズアプリケーション側では何も設定しませんでしたが、ここまでの連携設定を行うと、eHourが追加されていることがわかります。

eHourをクリックして、[シングルサインオン]をクリックすると、
ほかのアプリと違って、SAMLやパスワード連携などを設定する項目がありません。

続いて[ユーザーとグループ]をクリックします。
すると、こちらでは同意を行ったユーザーが追加されていることがわかります。
eHourのライセンスを持つ他のユーザーでも同意を行えば、自動的にこの項目にユーザーが追加されます。

[アクセス許可]項目をクリックします。こちらでは同意の状況を確認できます。
[ユーザーの同意]タブをクリックすれば、同意したユーザーの一覧表示、
[管理者の同意]タブをクリックすれば、ディレクトリを代表した同意を行うことができます。

ここで[管理者の同意を与えます]ボタンをクリックすると、以下の画面が登場しますので、[承諾]を押して管理者の同意を行います。

この後、別ユーザーでサインインしたとしても管理者の同意を行っているため、
ユーザー個別には同意画面が表示されることなく、eHourにログインできるようになります。

■ ■ ■

ここまでのところでOIDCでSaaSアプリとAzure ADを連携させる方法についてみてきましたが、OIDCはSAMLに比べて簡単実装。また、事前に管理者が同意しておけばユーザーが初めてログインするタイミングで同意画面が出ることもありません。
とても便利なSSO設定なのですが、現状の課題は対応アプリが少ないこと！
今後のSaaSベンダーさんの対応に注目したいところです。

皆さんこんにちは。国井です。

今日は完全な備忘録です。
かつてMicrosoft Defender for Endpointで利用可能だったアクティビティのクエリ機能であるAdvanced Hunting。このAdvanced Huntingは現在、Microsoft 365 Defender全体で利用できるように機能拡張され、様々なアクティビティに対してクエリを実行できるようになりました。
そのクエリのスキーマに IdentityLogonEvents というスキーマが使えるようになったので、
今日はこのスキーマを使ってAzure ADのサインインを追跡してみたいと思います。

IdentityLogonEvents スキーマの元ネタ

IdentityLogonEvents スキーマはMicrosoft Defender for Identity経由で収集したActive DirectoryのサインインログとMCAS経由で収集したAzure ADのサインインログをミックスさせたデータが元ネタになっていて、その内容に対してクエリを実行するので、Azure ADのサインインログそのものに対してAzure Monitorからクエリを実行する場合とは異なる情報を返してくる特徴があります。

IdentityLogonEvents スキーマのカラム

では、Azure MonitorからAzure ADのログに対するクエリを実行する場合とAdvanced HuntingからAzure ADのログに対するクエリを実行する場合でどのようなカラムの違いがあるか見てみましょう。

こっちがAzure MonitorからアクセスするAzure AD SigninLogsスキーマのカラム

それに対して、こっちがIdentityLogonEvents スキーマのカラム

こうしてみるとSigninLogsスキーマのほうが圧倒的に多くのカラムを出力してくれます。
ですので、普通に考えたらSigninLogsスキーマを使いましょう、、となるのですが、
Azure MonitorはMicrosoft 365に含まれるサービスではないので別にコストが発生してしまうことがネックだったりします。(と、書いてて気が付いたのですが、Microsoft 365 E5を買えるお客さんならAzure Monitorのコストなど大したことない？？)

あと、IdentityLogonEvents スキーマで面白いなと思ったのはISPフィールドがあることです。外部ユーザーの方が弊社のTeamsにアクセスしてくると、うちの会社では契約していないISPからのアクセスがログに残ります。大きな会社の場合、企業の名前がそのままISP名に入ってくるので、その人がどこの会社にお勤めか？ということがすぐにわかったりします。

じゃあ最後にSigninLogsとIdentityLogonEvents でそれぞれクエリを実行してみたいと思います。ここでは外部ユーザーでTeams以外のアプリにアクセスしたユーザーがいないかクエリで調べてみます。
まずはSigninLogs。こちらはLog Analyticsワークスペースから[ログ]にアクセスし、次のようなクエリを書いて実行します。

続いてIdentityLogonEvents。
こちらはhttps://security.microsoft.com から追及 > 高度な追及にアクセスし、次のようなクエリを書いて実行します。

あれこれ書いたけど、やっぱりSigninLogsスキーマが便利だと思いましたｗ

皆さんこんにちは。国井です。
今日は普段のトレーニングで時間の都合や優先順位の関係上、省略してしまうことの多いAzure ADの基本機能を紹介する101シリーズ。
今回はかつてアクセスパネルと呼ばれていた、マイアプリポータルについてです。

マイアプリポータルはAzure ADに関連付けられたクラウドサービスにシングルサインオンアクセスする際に利用するユーザーのための機能です。
URLはhttps://myapplications.microsoft.com/で、アクセスするとクラウドサービスの一覧が表示されます。

この画面からアクセスしたいクラウドサービスのアイコンをクリックすると、シングルサインオンアクセスできるのですが、Office 365を契約するだけで、ものすごいアイコンがいっぱい並んで邪魔なんですよね…

よく使うアイコンだけを並べる(ユーザー定義)

マイアプリポータルはタブを新しく作って、自分がよく使うものだけを並べることができます。マイアプリの画面から[作成]をクリックして、タブの名前とタブ内に表示させるアプリを選択します。

すると、ご覧のようによく使うものだけがすっきりと表示されることがわかります。

よく使うアイコンだけを並べる(管理者定義)

前の手順ではマイアプリポータルのタブをユーザー自身が作っていましたが、タブとその中にいれるアプリの一覧は管理者が作って、ユーザーに使わせるようにすることもできます。

ただ、設定した内容をユーザーが後からカスタマイズしたり、削除したりすることはできません。

不要なエンタープライズアプリケーションは非表示にする

マイアプリポータルに表示するクラウドサービスはAzure AD管理センターのエンタープライズアプリケーションに登録されていることが前提条件です。
しかし、エンタープライズアプリケーションに登録されてしまったがゆえにマイアプリポータルに(表示してほしくないのに)表示されてしまうケースもあります。
例えば、Microsoft Graphを使った操作を行うPowerShellスクリプトを作る際、[アプリの登録]からAPIアクセス許可設定を行いますが、その設定を行うとエンタープライズアプリケーションが勝手に作られてしまい、勝手にアイコンが表示されてしまいます。
PowerShellスクリプトからAzure ADを使うのに、マイアプリポータルにアイコンが表示されている必要ってなくないですか？

このような場合、アイコンを非表示にする設定がありますので、これを使います。
設定はAzure AD管理センターからエンタープライズアプリケーション > 特定のアプリ > プロパティから[ユーザーに表示しますか？]欄の[いいえ]を設定すればOKです。

そもそもマイアプリポータル要らない？

マイアプリポータルに表示されたクラウドサービスのうち、パスワード連携によって登録されたアプリを利用する場合、事前にブラウザーの拡張機能を入れておく必要があります。
拡張機能を入れると、パスワード連携を行うクラウドサービスにアクセスするためにアイコンをクリックすると、

クラウドサービスにアクセスし、ID/パスワードを自動入力して、自動ログインが完了します。これって拡張機能が実現していることなんです。

この拡張機能はブラウザーに常駐し、アクセスしたサイトがあらかじめマイアプリポータルに登録されたサイト(クラウドサービス)であれば、「ちょっとお兄さん、そこID/パスワード入れなくてもOKですよ」とお知らせしてくれます。そこで、拡張機能のアイコンをクリックすると、自動的にシングルサインオンアクセスが始まるのです。

つまり、マイアプリポータルにアクセスしなくても該当のサイトにアクセスすれば結局シングルサインオンアクセスできるのです。
あれ？マイアプリポータルにアクセスしなくても良いのでは？と思ったかもしれません。
ただ、マイアプリポータルにアクセスすれば、アイコンをクリックするだけでOKなので、該当のサイトにアクセスする手間を省いてくれるっていうメリットがあります。

皆さんこんにちは。国井です。
前回、マイアプリポータルについてお話ししました。
Azure ADをユーザーが利用するときのポータルサイトの存在について紹介しましたが、
ポータルサイトはいくつのメニュー(Webページ)に分かれています。
そのうちのひとつにmystaffというのがあり、これを使うとAzure ADの部門管理者による簡易的な管理作業を行うことができます。

部門管理者っていう耳慣れない言葉が出てきましたが、Azure ADではActive Directoryで言うところのOU(Azure ADではAUって言います)を作って部門管理者を擁立することができます。
AUについては以前のブログで紹介しているので、そちらを参照ください。

ということで今日はmystaffアプリ(https://aka.ms/mystaff)を紹介したいと思います。

事前準備

mystaffアプリはAUの管理を行うためのポータルサイトなので、まずはAUを作っておきましょう。作り方は上記のブログに書いてあるので参考にしてください。
AUを作ったら、AUの管理者ロールに自分を割り当ててください。
ここでは認証管理者のロールを割り当てた前提で話を進めていきます。

ファースト インプレッション

mystaffアプリにアクセスします。すると、自分にロールが割り当てられているAUの一覧が表示されます。

AU(ここでEmployeesという名前のAUです)をクリックすると、メンバーの一覧が表示されます。

さらに特定のユーザーをクリックするとご覧の表示になり、そのユーザーに対するパスワードをリセットしたり、多要素認証用の電話番号を追加したり、または電話番号の設定を変更したりすることができます。

管理者としてAzure ADの設定を行うと言ったらAzure AD管理センターを使うのが定石ですが、mystaffという手軽に管理ができるポータルがあるんですね。特に多要素認証を使い始めるときって、アプリの設定だったり、電話番号の設定だったりを行わなくてはならず、それをなかなか設定してくれない人っていますよね。そんな時に管理者が業を煮やして「代わりに私が設定してあげる」というときに使えると思います。

また、mystaffアプリ(https://aka.ms/mystaff)は条件付きアクセスでアクセス制御可能なので、特定の条件下でのみ管理操作が可能になるようなアクセス制御も可能です。

お試しあれ。

皆さんこんにちは。国井です。
コロナ禍でリモートワークを導入する機会もだいぶ増えたと思いますが、
一方で使い機会が物理的に少なくなったと思われるのがプリンターではないでしょうか？
リモートワークでオフィスのプリンターに印刷要求をしたとしても
受け取るのに出社しなければならないので、だったら印刷しなくてもいいや。
そう考える機会もぼちぼち出てくると思います。
一方、リモートワークを導入することで、自宅のプリンターやコンビニのプリンターなど
好き勝手にプリンターに接続し、印刷をするような人も出てくる可能性があります。

その制御ってどうすればいいんだろと調べていたら、会社で定めたプリンター以外を使わせないようにしたいというときはIntuneまたはGPOを使ってアクセス制御ができますよ、という記事がマイクロソフトのdocsに掲載されていました。

これを見ていて思ったのですが、
プリンターのアクセスをブロックするのではなく、プリンターのアクセスを追跡したい場合ってどうするんだろうか？と。
前置きが長くなりましたが、今日はMicrosoft Defender for Endpointを使ってプリンターへのアクセスがあった場合、これを見つける方法を探ってみたいと思います。
(外付けハードディスクの利用を見つける方法もあるよ)

Microsoft Defender for Endpointでアクティビティの追跡

Microsoft Defender for EndpointはWindows 10デバイスに対してオンボーディングと呼ばれる設定を事前に行っておくことによって、Windows 10デバイス上のアクティビティがMicrosoft Defender for Endpointの画面上で確認できるようになります。
ここで言うアクティビティとは、ファイルアクセス、レジストリアクセス、ネットワークアクセスなどのことで、Microsoft 365 Defenderポータルサイトにアクセスすると確認できます。
ただアクティビティを一覧で見せられても膨大なログなので、現実的に利用する場合はクエリを書いて見たいものだけを取り出します。クエリはMicrosoft 365 Defenderポータルサイトの追及 > 高度な追及からクエリ文を書いて確認します。

クエリを書くときは1行目にスキーマを定義して、見たいログのジャンルを指定します。
例えば、前述のdocsでも紹介されているDeviceEventsスキーマはデバイスで行われたイベントを出力するスキーマで実行するとログが大量に出てきます。

このログを見てもらうとActionTypeという列があり、これがデバイス上でどのような操作を行ったかを大まかに表すものになっていることがわかります。実際、前述のdocsでもIntuneで制限がかけられたプリンターへのアクセスがあった場合にはActionTypeにPrintJobBlockedと記録されるよと書いてあります。ここまでのところでActionTypeを使えば、どんな操作があるのかがわかるということが理解できました。

ActionTypeで出力される情報を一覧表示

続いてActionType列にはどのような文字列がログに出てくるのか見てみましょう。
過去に行われたアクティビティはActionTypeを見ればわかるということだったので、
ActionTypeに出力された文字列一覧を実行回数の多い順に並べるクエリを書いてみました。

DeviceEvents
| summarize count() by ActionType
| order by count_ desc

その結果がこちら。

画面が切れてしまって一覧に表示されていないのですが、USB接続の外付けハードディスクを利用した場合、ActionTypeにUsbDriveMountedと記録されます。
ですので、今度は次のようなクエリを書いて外付けハードディスクの利用だけを表示させてみました。

DeviceEvents
| where ActionType == “UsbDriveMounted”

あらま。よく使われていることがわかります。
さらに詳細情報を見たいときは必要な列だけ絞り込んで表示させてみましょう。
今度はこんな感じのクエリを書いてみました。

DeviceEvents
| where ActionType == “UsbDriveMounted”
| project Timestamp,DeviceName,ActionType,AdditionalFields

すると、見たい内容だけが絞り込まれて表示されていることがわかります。
さらに特定のログをクリックすると、その詳細が右側の画面に表示されます。
これで、いつディスクを接続したか、どのデバイスが接続したか、どのユーザーが接続したか、どのドライブ文字を利用したか、などがわかります。

ちなみにUSBの外付けディスクを禁止する会社は多いと思いますが、
それについてもIntuneまたはGPOから設定可能です。

プリンターのアクセス履歴を追跡

続いてプリンターアクセスを追跡します。
ところが、ActionTypeにプリンターのジョブはありません。
プリンターはドライバーをロードした情報はActionTypeから確認できるのですが、
印刷要求そのものはどうやらDeviceEventsスキーマから追跡できないようなのです。
(どなたか、こうやったら見えるよ！などの情報があれば連絡ください)

そこで私はネットワークプリンターにアクセスするのであれば、ネットワークアクセスを追跡すればよいのではないかと考え、DeviceNetworkEventsスキーマを使ってプリンターが持つIPアドレスへのアクセスを追跡することにしました。

DeviceNetworkEvents
| where RemoteIP == “プリンターのIPアドレス”

すると、ご覧のように結果が確認できました。
spoolsv.exeからプリンターへのアクセスが行われているとログに書かれているので、
DeviceProcessEventsスキーマから追跡しても見えそうな気がするのですが、
DeviceProcessEventsスキーマからプリンターアクセスを確認することはできませんでした。

【おまけ】ユーザーがアクセスしたWebサイトを追跡

DeviceNetworkEventsスキーマはネットワークアクセスを追跡するので、例えばブラウザーからWebアクセスがあれば、それもログに残ります。アクセスしたURLはRemoteURL列に記録されるので、Dropboxへのアクセスがあったことを追跡したければ、こんな感じでクエリを書きます。

DeviceNetworkEvents
| where RemoteUrl contains “dropbox”

使い勝手の問題は多少あるかもしれないけど、操作ログを追跡する使い方もできるんだなってことがわかりました。今回、クエリの書き方については端折って解説しましたが、Microsoft 365インシデント対応コースでは実機でクエリを体験できますので、ご興味のある方は参加してみてください。

皆さんこんにちは。国井です。
今日は普段のトレーニングで時間の都合や優先順位の関係上、省略してしまうことの多いAzure ADの基本機能について紹介します。今回はAzure AD Connectの代替として期待されているAzure AD Connectクラウド同期についてです。

Azure ADクラウド同期とはオンプレミスActive Directoryのユーザーやグループの情報をAzure ADに同期するサービスで、まさにAzure AD Connectの代わりとなるサービスです。
ADの情報を同期すると言ったら今まではAzure AD Connectを使っていましたが、Azure AD Connectを利用しようと思ったらアプリケーションをインストールしなければならず、さらに(必要に応じて)アプリケーションの設定をAzure AD Connect側で行う必要がありました。
それに対してAzure AD Connectクラウド同期の場合、Azure AD Connectをインストールしたときに利用可能なSynchronization ServicesやSynchronization Rules Editorなどのツールに相当する機能をクラウド側で持つため、Azure AD Connectのサービスや設定のバックアップを考える必要がないというメリットがあります。(本当はMSがデータセンターに保存しているデータを消してしまうようなトラブルがあった時のためのバックアップは必要なんでしょうけどね)
では、Azure AD Connectクラウド同期を利用しながら、
Azure AD Connectとの違いを見ていきましょう。

インストール

インストールって、、さっきAzure AD Connect入れなくていいって言ったじゃない！と思うかもしれませんが、クラウド同期を行うためのエージェントはインストールする必要があります。
Azure AD管理センター画面からAzure AD Connect > Azure AD クラウド同期を管理する をクリックして、エージェントをダウンロードし、ドメインコントローラーにインストールします。
Azure AD Connectではプロビジョニングエンジンそのものをインストールするため、一元的な同期が実現できるよう、アクティブーパッシブの構成をとるとき以外は複数のサーバーにAzure AD Connectをインストールしてはならないというルールがありました。
しかし、クラウド同期の場合は複数のドメインコントローラーにエージェントをインストールして冗長構成にすることができます。

Azure AD Connect cloud syncの構成

Synchronization ServicesやSynchronization Rules Editorを通じて設定するはずの構成は
Azure AD管理センター画面からAzure AD Connect > Azure AD クラウド同期 のメニューから[新しい構成]をクリックして設定します。
設定画面はこちら。
①から順番に設定していきます。

①ではエージェントをインストールすることによって同期元のADドメインは既に認識しているので、ドメインの中のどのグループ/OUを同期対象にするかをスコープフィルターで設定します。対象となるグループやOUはDNで指定します。DNってOU=xxxx,DC=contoso,DC=comみたいに書く設定のことです。
ちなみにAzure AD Connectだと10GB(オブジェクト数で言うとおよそ10万)を超える場合、SQL Serverが必要になりますが、クラウド同期に10GBの上限はないので大規模環境だとコスト的なメリットがあったりします。

②ではSynchronization Rules Editorで設定していた属性マッピングの設定です。
以前、このブログでADユーザーの国/地域の属性をAzure ADユーザーの利用場所属性にマッピングさせる設定というのを紹介しましたが、こうした設定を含むマッピング設定がクラウド側で定義できます。
(ちなみにマッピング設定はユーザー、グループ、連絡先と別々のタブで用意されています)

利用場所属性のマッピング

Azure ADの利用場所属性はusagelocationなので、usagelocation属性のソース属性側(右側)で属性に入れる値を定義します。

デフォルトではmsExchUsageLocation属性を引っ張ってくる設定になっていますが、
ADの国/地域属性を利用するように設定するなら

IIF(IsNullOrEmpty([c]),”JP”, [c])

と入れてあげれば国/地域属性がセットされ、ADの属性値が空ならJPの値が自動的に入るようになります。

代替ログインIDの設定

代替ログインIDをAzure AD Connectで利用するときにはウィザードの中で属性を定義していましたが、クラウド同期で同じことをする場合は②の中で定義します。例えば、ADユーザーのmail属性をAzure ADユーザーのUPN属性として使いたい場合はこんな感じで設定します。

って紹介しようと思ったら画面が切れちゃって見えないので、こちらで紹介します。

IIF(IsPresent([mail]), [mail], IIF(IsPresent([userPrincipalName]), [userPrincipalName], Error(“AccountName is not present”)))

mail属性が値が入っていればmail属性をそのままUPN属性へマップ、そうでなければADのUPN属性をマップするように設定してみました。

ただしProxyAddresses属性にメールアドレスが入っている場合はマップさせる方法がないんですよね。。ProxyAddresses属性に入るメールアドレスって、SMTP:に続く文字列だけをマップさせなければならないのですが

Mid(Item([proxyAddresses],Contains([proxyAddresses], “SMTP:”)),6)

のような書き方ができないんですよ(Contains関数が使えない)。
色々書き方を工夫してみたのですが、タイムアップで挫折してしまいました。
※クラウド同期ではAzure AD Connectで利用可能だった関数すべてをサポートしているわけではなく、このことが互換性の上で課題になるケースがありそうです。

Azure AD Connect cloud syncの構成に話を戻します

属性マッピングの話が長くなりましたが、クラウド同期構成に話を戻します。
②の部分でマッピング設定ができたら、同時にパスワードハッシュ同期を行うか選択します。
この時に注意したいのはパスワードハッシュを同期しなかったらパススルー認証になるのか？と言ったらパススルー認証しない(というかできない)点です。(じゃあ何のためにあるんだ？とつっこみたくなりますが、恐らくADFSのためにあるのでしょう)
また、Azure AD Connectでは一部のユーザーだけパスワードハッシュ同期するように構成できますが、クラウド同期ではその選択肢はありません。

以上の設定ができたら、続いて③を利用して同期の検証を行います。
③の[ユーザーのプロビジョニング]ボタンを押して、同期させたいADユーザーのDNを指定すると、そのユーザーだけがAzure ADに同期されます。(※Azure AD Connectに用意されているInvoke-ADSyncSingleObjectSyncコマンドレットとおなじものとお考え下さい)
そしてその結果をみて問題がなければ、最後に⑤の部分で[有効にする]を選択すれば同期が始まります。

なお、docsの説明には以下の内容が書かれています。

エージェントは再起動時 (およびその後 10 分ごと) にブートストラップ サービスを呼び出して、構成に更新がないか確認します。

このことから同期は10分間隔で行われることになります。Azure AD Connectだとパスワードの同期はPCNSコンポーネントを利用することによりリアルタイムに近い形で行われますが、クラウド同期だとPCNSを利用している様子はなく、他の属性と同じようにパスワードを同期していました。(ウラが取れないので確かなことは言えないのですが..)

Azure AD Connectはもう要らないのか？

ここまでの設定でクラウド同期が始まり、Azure AD Connectなしでの同期が実現します。
すると次にAzure AD Connectはもう要らないのか？という疑問が出てきます。
将来的にはAzure AD Connectをインストールしなくても良い世界を目指していることはなんとなくわかりますが、現時点では足りていない機能がたくさんあります。
代表的なのがコンピューターアカウントの同期です。コンピューターアカウントの同期はハイブリッドAzure AD参加という機能に必要なもので、これが利用できないと条件付きアクセスの一部機能が利用できなくなるので困る人は多いと思います。そのほか、オンプレミスAD以外のディレクトリに接続して利用できないことや、パスワード等のライトバックがりようできないなど、本稿執筆時点では一部の人が困る機能制限が色々あるのです。詳しくはMicrosoft docsで確認してもらえればと思いますが、すべての会社にお勧めできる状況でないことがわかります。

今すぐ同期を実行したい

ここからは思いつくままに書いていきます。
Azure AD管理センター画面からAzure AD Connect > Azure AD クラウド同期 のメニューからクラウド同期構成の編集画面を開き、[同期の再開]をクリックすれば今すぐ同期が始められます。
エージェントをインストールしたコンピューターから同期を始めたければMicrosoft Azure AD Connect Provisioning Agentサービスを再起動すればOKです。

同期の結果を確認する

Azure AD管理センター画面からAzure AD Connect > Azure AD クラウド同期 のメニューから[状態]欄の[正常]と書かれたところをクリックすれば

結果が確認できます。

またオブジェクト単位での結果(ログ)を参照したければ、上の画面から[ログ]をクリックすればCSVまたはJSON形式でダウンロードできます。
ただしSynchronization Serviceで見てきたログとはフォーマットが違う点に注意です。

複数のADドメインと同期

エージェントをインストールするときに複数のドメインを指定できます。

既存のAzure AD Connectから移行は可能？

可能です。移行方法に関するドキュメントがdocsに記載されていました。

docs内の説明でcloudNoFlow属性のくだりなどイマイチ理解できないところがあるのですが、自分自身が検証した限りではAzure AD Connect側の同期設定を停止し、クラウド同期のエージェントをインストールすれば、そのまま切り替えることができました。
ちなみにAzure AD Connectをインストールしたサーバーとクラウド同期のエージェントをインストールするサーバーは同一のサーバーでも動作していました。

一意のユーザー識別の設定変更は可能？

Azure AD Connect cloud syncの構成画面からソースアンカーの設定変更はできません。

また、Azure AD Connectから移行を行う際のdocsドキュメントに次のようなことが書かれています。

Azure AD Connect 同期のソース アンカーが objectGuid または ms-ds-consistencyGUID であること

チュートリアル – 既存の同期済み AD フォレストに対して Azure AD Connect クラウド同期のパイロットを実施する | Microsoft Docs

以上のことからソースアンカーを変更したクラウド同期の運用は不可能なものと考えています。

所属OUの情報を同期させられるか？

ADにあって、Azure ADにない概念にOUがあります。似たような概念でAUっていうのがあるんだけど、Azure ADでOUを使いたいと言っている人の多くはOUの中にいるユーザーだけが管理画面に表示されるようにフィルターをかけたいんだと思うんです。
そこで私はOUの情報を含むDNをAzure ADの会社名属性にマップしてあげました。

CStr([distinguishedName])と書けば、DN属性が文字列として会社名属性に入ってくるので、こうすれば会社名でOUの名前による検索がかけられます。

ところが、Azure AD管理センターのフィルター設定って前方一致しかできないんですよ！

というわけで、ADからとってくるDN属性のうちOU=で始まる部分だけを切り出してマップしなければならないのですが、うまく切り出せないんですよね。。
何かいい方法があったら誰か教えてください！

■ ■ ■

ここまでのところでクラウド同期について見てきました。
繰り返しになりますが、クラウド同期には利用できない機能があるので、
自社での要件と照らし合わせて利用可否については決定するようにするとよいでしょう。

皆さんこんにちは。国井です。
以前にMicrosoft Defender for Endpointを利用して印刷や外付けディスクの利用を追跡していく方法を紹介しましたが、Microsoft 365 E5を利用しているのであれば、もうひとつ追跡する方法があります。
それがエンドポイントDLPを使った方法です。

■ ■ ■

DLP(Data Loss Prevention)とはコンテンツの中に機密情報が含まれているかをチェックし、機密情報があればデータの送信をブロックするなどの措置を行ってくれるソリューションです。DLP自体は古くからOffice 365のサービスとして用意されていたのですが、Microsoft 365 E5になるとWindows 10デバイスでのアクティビティを監視し、機密情報の存在を見つけてきてくれるエンドポイントDLPなるものが利用できるようになります。

DLPは条件をもとに機密情報を見つけてくれるソリューションですが、その過程でエンドポイントデバイスでのアクティビティそのものを監視してくれて、アクティビティエクスプローラーと呼ばれるMicrosoft 365コンプライアンス管理センターのユーザーインターフェイスから参照することができます。これこそが今回のブログでやりたいこと、見たいことになります。

実装方法は簡単なので、簡単に見てみましょう。

セットアップ

マイクロソフトのdocsにアクセスすれば全部書いてあるのですが、

簡単にまとめておくと以下の前提条件が必要になります。

・Microsoft 365 E5 / E5 Compliance / E5 Information protection and governanceのいずれかのライセンスを保有していること
・Windows 10 1809以降であること
・Microsoft Defenderウイルス対策のバージョンが4.18.2009.7以上であること
・Windows Updateにより次の更新プログラムがインストールされていること
-Windows 10 1809 の場合 – KB4559003、KB4577069、KB4580390
-Windows 10 1903 または 1909 の場合 – KB4559004、KB4577062、KB4580386
-Windows 10 2004 の場合 – KB4568831、KB4577063
-Office 2016 を実行しているデバイスの場合 (他の Office バージョンではない) – KB4577063
・デバイスがAzure AD登録 / Azure AD参加 / ハイブリッドAzure AD参加 のいずれかの登録が行われていること
・新しいEdgeがインストールされていること

そのほか、プロキシを利用している場合には他の設定が必要になります。

ここまでの設定が完了したらMicrosoft 365コンプライアンス管理センターにアクセスして
設定 > デバイスのオンボード からオンボーディングスクリプトをダウンロードしてデバイスで実行します。(※このオンボーディングスクリプトってMDEのスクリプトと同じような気がしますが、何が違うんでしょうね？？)

それから監査対象となるコンテンツはMicrosoft 365コンプライアンス管理センターのデータ損失防止 > エンドポイントのDLP設定からカスタマイズすることも可能です。

Here we go

Microsoft 365コンプライアンス管理センターのデータ損失防止 > アクティビティエクスプローラーから結果を参照します。アクティビティエクスプローラーではフィルター設定ができるのですが、アクティビティの種類でフィルターしようとすると、こんな感じのフィルター項目があることがわかります。

フィルター項目だけ拡大してみるとこんな感じです。

フィルター項目を見れば[File printed]とあるので、印刷されたデータがすぐにわかります。
実際にフィルターをかけると該当の項目が表示されるので、クリックして詳細を見ると印刷したファイルの名前が確認できます。

外付けディスク利用を追跡

外付けディスクの利用があればフィルターから[FileCopiedToRemovableMedia]という項目で追跡できます。

上の画面では1件だけ該当の項目がありました。
詳細は日時やユーザー名などと一緒に以下のような情報を参照できます。

クラウドへのコピー

コピーをしましたよという追跡はローカル、ネットワーク共有、クラウド、RDPセッションと別々にフィルター項目が用意されています。例えばクラウドへのコピーを追跡してみましょう。クラウドへのファイルコピーはターゲットドメイン名が表示されるので、ドメイン名を見れば「あ、DeepLで翻訳したんだｗ」とか分かるわけです。

ここに画面は載せていませんが、RDPセッションの場合はコピー先がmstsc.exeとだけ表示されて、どこの仮想マシンにコピーされたかは全く分からなかったりします。

まとめ

Microsoft 365 E5のDLPを使えばMDEを使った印刷や外付けディスク利用の追跡をするよりも簡単に追跡できることが分かったと思います。
一方でキーワードで検索・追跡するなどのフィルター設定が充実していないのでCSVにエクスポートしてExcelから検索しなければならないなど、ちょっと使い勝手が悪いところもあったりします。
あとはこの情報をもとにしたアラートが設定できるといいですね。
このあたりはもう少し調べて別途お伝えできたらと思います。

皆さんこんにちは。国井です。

今日はMicrosoft Defender for Endpoint (MDE) の話です。
MDEって脅威インテリジェンスを利用して不正アクセスを検出し
プレイブックに基づくインシデント対応を自動化するっていうけど

本当にスキルゼロでできるものなのか？
そうでなければ、どの程度の前提スキルが必要なものなのか？

そのあたりをなんとなくでも把握してもらえるよう、Windows 10デバイスをランサムウェアに感染させ、そのうえで調査や対応を実際にやってみました。

MDEを使うためにはライセンスを買う、初期設定する、Windows 10デバイスをオンボーディングする、などが必要になりますが、その辺は評価ガイドが出ているので、そちらを参考にしてもらえればと思います。

そのうえでWindows 10デバイスでランサムウェアを検出したらどうなるのか見てみます。

ランサムウェアが見つかった

まず、Microsoft Defender for Endpointの管理は Microsoft 365 Defender管理センターから行います。

管理センター画面の左側から[インシデント]をクリックすると、インシデントの発生状況が確認できます。ランサムウェアが見つかった場合もインシデントのメニューでその内容を確認します(下の画面みたいに)。ここの画面には書いていないですけど、ランサムウェアが見つかればRansomware was detected.. みたいな感じで表示されます。
利用する上での前提スキルという点からいえば、これを見たときに「ああ、〇〇が起きたのね」とわかる、もしくは自分で関連情報を調べられるスキルが必要になると思います。

インシデントをクリックすると、その詳細が確認できます。
なかでも[証拠と対応]と書かれたところをクリックすると、インシデントと判定されるに至った基準(証拠)について情報が書かれていることがわかります。今回の場合にはランサムウェアと判定されるファイルやプロセスがあったことが書かれています。ちなみにRemediatedと書かれた項目がありますが、これは検疫などの修復対応済みであることを表します。
これを見れば自動で対処してくれたのね！ってことがわかりますね。

さらに[証拠と対応]タブでは[Persistence Methods]欄からASEPと呼ばれるWindows起動とともに実行するプロセスが不適切に追加されたことが書かれています。ここでPersistence Methodsというキーワードが出てきましたが、これも典型的な攻撃のプロセスってどういうもの？ということを理解していることが前提になっているように思います。

項目をクリックすると、ご覧のようにレジストリのどの項目に書き込みを行い、ASEPの設定をしたのかがわかります。もちろんRemediatedと表示されているので修復済みです。

アラートから見てみる

MDEではインシデントが発生するとそれに対応するアラートが一緒に出力されます。
アラートの詳細を開くと[アラートのストーリー]と呼ばれるアラートを出力するに至ったプロセスの情報がプロセスツリーで表示されます。これにより、どのプロセスからどのプロセスが呼び出されたかがわかります。今回の場合で言えば、プロセスID4384のプロセスからプロセスID7424のプロセスが呼び出され、そこからcsrss.exeを通じてASEPの登録を行ったということがわかります。
(その他にも赤い字で数々の悪行が書かれていますが、ここでは省略します)

タイムラインから見てみる

アラートに出力された悪行からタイムラインに移動することができます。
そこでタイムラインを参照すると、アラートを出力することになったプロセスの前後にどのようなことが行われたかを確認できます。今回のケースだと、マルウェアはMicrosoft Edgeでダウンロードしていることがわかるので、自発的にダウンロードしたのかな？だとか仮説を立てたりできるわけです。その他、マルウェアはChromeでダウンロードしたから自分のデバイスで実行することになったとか、メーラーでメールと一緒に添付ファイルのダウンロードを行ったから自分のデバイスで実行することになったとか、タイムラインを見れば前後関係が把握でき、アラートのストーリーと組み合わせて参照することで攻撃の実態をより立体的に把握することができます..
というのはセールストークなどでよく聞く話で、じゃあ実際に誰でも立体的に把握できるかといわれれば、典型的な立体がなにか？がわかっていなければならないわけで、それは前提条件スキルにあたる部分なのかなと思うのです。

ファイルの単位で見てみる

前の画面で表示させたインシデントメニューに戻り、[証拠と対応]タブから特定のファイルの詳細を開きます。するとファイルのハッシュ情報であったり、マルウェアと判定されたそのファイルが組織内で何台のデバイスで見つかったか？などが確認できます。この辺りを参照すれば組織内での影響範囲なども把握できると思います。

また、[詳細分析]タブをクリックすると、マルウェアの検体を送信し、さらに詳細な分析を依頼することができます。

でもって結果が返ってくるとこんな感じの情報が表示されます。

細かく見ていきます。
まず、動作 > Communicationsではそのexeファイルがどこと通信しているかを確認できます。通信先をencrypted channelとexternal IP addressに分けているんだけど、encrypted channelって単純にHTTPSのことかな？？

監視可能なもの > 接続されたIPでは前の画面で表示された通信先となるIPアドレスがありましたがそれぞれのIPアドレスがリンクになっていて、クリックするとIPアドレスそのものの危険度が確認できたりします。こうした調査って、マルウェアの動的解析や静的解析など、解析調査を通じて知りうるものだと思いますが、MDEだとそれをボタン一つでMSに依頼して解析してもらうことができるっていう嬉しさはあると思います。
一方で結果を見せられて、その情報をどのように扱うべきかということについては
わかる人がいなければならないことは事実だと思います。

インジケーターを使う

前の画面ではファイル単位での分析を見てきましたが、この中のメニューに[インジケーターの追加]というのがあります。これを利用すると同じファイルが他のオンボーディングされたデバイスで見つかった場合、ファイルをブロックしてくれます。
1台のデバイスでマルウェアを発見した時、その影響範囲を広げたくない時などに有効です。

インジケーターを追加するウィザードで指定可能なパラメーターはこんな感じ。

インジケーターを設定した後にオンボーディングされたデバイスでマルウェアを検出すると、ご覧のようにブロックしてくれます。ただし、インジケーターの設定に基づくブロックができるのはオンボーディングされたデバイスでMicrosoft Defenderウイルス対策を使っていることが前提条件です。ESETなどのウイルス対策との組み合わせでもMDEは動作しますが、アクティブモードと呼ばれるインジケーターに基づくアクションを実行することができない点が注意点です。

■ ■ ■

ここまでMDEでインシデント対応をしながらMDEの特徴や扱う人に求められるスキルを簡単に見てきました。簡単に言えば不正アクセスの特徴そのものをある程度理解していることが必要だと言うことが理解してもらえたと思います。もうちょっと具体的に言えば、MDEでインシデント/アラートが出力されると「本物のインシデントか？それとも誤検知か？」からスタートしますが、内容を見てそれを判断できるチカラがまず必要になると思います。そして自分のデバイスの中での影響範囲や組織内のデバイスにおける影響範囲を見極めるチカラが必要になります。こうしたことを判断できるようになるには色々なスキルが必要になるんだと思いますが、まずはMDEに触れて、様々な事例に触れていくことが重要ではないかと思っています。