はじめに

Microsoft 365 を利用していると、Azure Active Directory のセキュリティ運用を考えることがあるだろう。
今回は、デバイスのためのセキュリティ運用の公開文書から、あずかり知らないデバイスからのサインインを検出する手法を試してみた。エンタープライズ企業をはじめとする組織が Microsoft 365 導入した後で、データ保護の観点から管理されていないデバイスからのアクセスを脅威検出シナリオの一環として検討することが多いと感じたため、本記事を書くことにした。

以降の内容の前提条件は下記である。

Microsoft Sentinel へ Azure Active Directory のサインインログを接続していること（設定方法はこちら）
任意のデバイスから Azure Active Directory ユーザーを利用して Office 365 へアクセスできること
Azure 管理ポータルを管理者権限ユーザーで操作できること

検証準備

上記で紹介したAzure Active Directory のセキュリティ運用文書には、Github のコミュニティで公開されている Sentinel のハンティングクエリのテンプレートが紹介されており、そこから KQL (Kusto Query Language) のクエリを抜粋して利用した。
応用すれば他の SEIM 等ログ分析基盤でも使えるであろう。

SuspiciousSignintoPrivilegedAccount.yaml(33-40)

SigninLogs //Sign-ins by unknown devices
  | where isempty(DeviceDetail.deviceId)
  | where AuthenticationRequirement == "singleFactorAuthentication"
  | where ResultType == "0"
  | where NetworkLocationDetails == "[]"
  | extend AccountName = tolower(split(UserPrincipalName, "@")[0]), WinSecEventDomain = "-"
  | where AccountName in (priv_users)
  | project-rename  ServiceOrSystem = AppDisplayName, ClientIP = IPAddress

このクエリの where AccountName in (priv_users) の部分を割愛すれば、そのままクエリを実行して結果を得ることが出来た。割愛した部分では、Sentinel のウォッチリスト機能を使ってユーザーを絞りこむようにしていた。
このクエリは、以下の観点でサインインログを検索し、得られた結果からユーザー名およびアクセス先などを表示させることができる。
① デバイス ID の値に何も入っていなかった
② MFA (多要素認証) が適用されずに認証が成功した

結果

Azure Active Directory へ登録済みの Windows デバイスと、登録していない (あずかり知らない) Windows デバイスの両方から Office 365 へアクセスを行った時のログ情報を見てみよう。

あずかり知らない Windows デバイスからのサインイン
Azure Active Directory へ登録していない Windows デバイスから、SamplerUser01 という名前のテストユーザーを使って Office 365 へアクセスを行った。その時の認証アクティビティについて、Azure 管理ポータルから Azure Active Directory のサインインログを追うことが出来る。上述した①デバイスIDについては、ログの詳細にあるデバイス情報で確認可能だ。Azure Active Directory へ登録していないデバイスの場合、デバイスIDの値が空になっていることがログからも確認できた。 ② MFA なしの認証の成功については、ログの詳細にある基本情報で確認可能だ。MFA が適用されない場合は、単一要素認証と表示された。
Azure Active Directory へ登録済みデバイスからのサインイン
Azure Active Directory へ登録済みの Windows デバイスから、SamplerUser02 という名前のテストユーザーを使って Office 365 へアクセスを行った。①デバイスIDについては、値が格納されていることを確認できた。URL のリンクになっており、クリックするとデバイスの詳細画面に遷移できた。② MFA なしの認証の成功については、今回は MFA を要求するポリシーを適用していたため、多要素認証と表示された。

Azure Active Directory へ登録済みのデバイスであっても、ブラウザーのインプライベートモードなどを使ってアクセスを行った場合は、デバイス ID が正しく記録されない場合があることに留意しておくと良い。

Azure Active Directory のサインインログを直接確認できたので、Microsoft Sentinel で KQL クエリを実行したところ、想定していたとおりにあずかり知らない Windows デバイスからの SmapleUser01 ユーザーの認証アクティビティのみが得られた。Microsoft Sentinel のログ検索機能をつかって、手動で KQL クエリを実行するだけでなく、得られた結果に応じたアラートの通知設定を行っておくと、セキュリティ運用の自動化に近づくだろう。プレイブックなど Microsoft Sentinel に組み込まれた SOAR (Security Orchestration Automated Response) 機能が活用可能だ。また、一定期間のスナップショットをエクスポートして Power BI で分析することもお勧めできる手法だ。どのようなアプリケーションへあずかり知らないデバイスからアクセスしているかを把握しておくと、アクセス制御に関する追加の対策を打ちやすくなると言っても過言ではないだろう。

まとめ

Azure Active Directory のセキュリティ運用の公開文書から、あずかり知らないデバイスを検出する手法の紹介
Azure Active Directory のサインインログを直接確認し、デバイス ID と MFA の有無に関するログ情報を確認
Microsoft Sentinel のテンプレートを応用した KQL クエリを実行し、想定通りの結果が得られることを確認

最後まで読んでいただきありがとうございました。