皆さんこんにちは。国井です。
私は主にトレーニングという立場からAzure ADに触れ、様々なお客様と触れているのですが、本当にこの数年で浸透してきたなという印象です。
あるサービスが出始めたばかりの頃、アーリーアダプターが騒いでいるレベルの頃は「〇〇ができる」みたいな話で盛り上がるわけですが、Azure ADのように多くの企業で使われるようになってくると「〇〇ができる」の話だけでなく、もっと現実的な部分にフォーカスされていくわけです。Azure ADという観点で言えば、そのうちのひとつに「監査ログ」があるでしょう。
Azure ADには誰がいつアクセスしたかを表すサインインログと、管理者がどういう管理作業を行ったかを表す監査ログがあり、監査ログを参照すれば、適切な管理作業が行われているか？不正アクセスによる設定変更がないか？などを追跡できるわけです。では、その監査ログをどうやって見るか？みたいな話になるとあんまり情報がないんですよね…
ということで、今回はAzure ADの監査ログにフォーカスしてみたいと思います。
監査ログを見る方法
Azure AD管理センターから[監査ログ]をクリックするとご覧になれます。
無償版Azure ADだと過去7日間、有償版Azure ADだと過去30日間のログを参照できます。
上の画面だと過去7日間に絞ってログを出してますが、
画面上部(上ペインと言えばいいのかな)ではログ一覧、その中から特定のログをハイライトすると、画面下部(じゃあ下ペインということで)にその詳細が確認できます。
上ペインでは日時の他、どういう操作を行ったかについての概要(例えば、カテゴリでUserManagement、アクティビティでUpdate userとあれば、ユーザーの更新を行ったんだなということがわかります)が確認できます。
また、アクターとターゲットというのが画面右側にありますが、アクターによってターゲットに対する操作を行ったというみかたをします。ですから、adminユーザーがsuser04ユーザーに対する操作を行ったという意味です。
アクターって誰？
IMEの変換候補に芥川賞が登場するアクターですが、
アクターは誰(何)によってAzure ADに対して変更が加わったかを表すものなので、不正アクセスの可能性を見極めるのであれば重要な要素になると思います。Azure AD管理センター画面から操作を行ったり、Azure AD PowerShellを使ってスクリプト処理で操作を行ったりすれば、その操作は明示的に管理者でサインインしていますから、アクターは必ずユーザーになります。一方、管理者が関係することなく処理が完結するものに関しては、アクターはユーザー以外になります。いくつか例を挙げてみましょう。
■セルフサービスでパスワードをリセットした
この場合、アクターはfim_password_service@support.onmicrosoft.comになります。SSPRという機能がパスワードをリセットするのでそうなります。
ただし、パスワードをリセットしたのは自分なので、fim_..ユーザーがアクターであるログの前に自分自身がアクターのログも一緒に出力されます。
■動的ユーザーグループのメンバーが追加・削除された
Microsoft Approval Managementというアクターが処理を行うそうです。
■Teamsからゲストユーザーを追加した
Microsoft B2B Admin Workerがアクターになります。関連するログも一緒に出るのでゲストユーザーを追加すると複数のログが出力されます。
■Teamsで追加したゲストユーザーが初めてアクセスした
Microsoft Invitation Acceptance Portalがアクターになります。ゲストユーザーを作ったタイミングではメールアドレスしかユーザーのプロパティに入っていませんでしたが、
初めてアクセスし、ゲストユーザーとしてのRedeemの処理を行うと、いつRedeemしたか？などの属性がゲストユーザーのプロパティの中に追加されるようになります。
その一部始終が監査ログでは記録されるのですね。ちなみにゲストユーザー自身がアクターのログも一緒に出力されます。
■Teamsでチームの設定を変更した
Microsoft Teams Servicesがアクターになります。Teamsのチームの実態はOffice 365グループですが、Azure ADから操作すれば管理者ユーザーがアクターになるし、Teamsから操作すればMicrosoft Teams Servicesがアクターになるのです。
■デバイスを登録した
Azure ADへのデバイス登録はDevice Registration Services、Intuneへのデバイス登録はMicrosoft Intuneがアクターになります。なお、登録されたデバイスは定期的にAzure ADやIntuneと通信しますので、OSバージョンが変わったなどのプロパティ変更が生じれば、アクティビティがUpdate deviceのログが出力されます。
ログの詳細を見る
繰り返しになりますが、ログ一覧から特定のログをクリックすると下ペインにその詳細が表示されます。例えば、上の画面でカテゴリーがUserManagement、アクティビティがUpdate userのログをクリックしましたが、このとき下ペインでは次のようなメッセージが出ています。
さらに[変更されたプロパティ]タブをクリックすると具体的に変更した箇所がわかります。
これを見ればAccountEnabled属性がTrueからFalseに切り替わっているので、ユーザーを無効化したことがわかります。
Microsoft Authenticatorを使うと監査ログが増える現象について
多要素認証、特にMicrosoft Authenticatorを利用するように構成している企業ではカテゴリーがUserManagement、アクティビティがUpdate userのログが大量に発生しているのではないかと思います。これは多要素認証を設定しているユーザーがMicrosoft Authenticatorを使ってサインインをするたびにデバイストークンが生成され、その結果が監査ログに出力されるためです。
多要素認証の設定はユーザーのプロパティなので、デバイストークンが変わるたびにユーザーのプロパティが変わる → 監査ログに出力される、というメカニズムなんですね。
Log Analyticsから監査ログを見る
最後に監査ログをLog Analyticsにエクスポートし、その結果を確認してみましょう。
Azure AD管理センター画面から[診断設定]項目をクリックし、AuditlogsをLog Analyticsワークスペースにエクスポートする設定を行います。
※設定の詳細はこちらからもご覧になれます。
設定が完了したら、Azure AD管理センター画面から[ログ]をクリックすると、
Log Analyticsから監査ログに対するクエリが実行できるようになります。例えば、先ほど出てきた多要素認証の実行結果を参照したいということであれば、次のようなクエリを書いて実行すると、
AuditLogs
| where InitiatedBy contains “fim_password_service@support.onmicrosoft.com”
| where TargetResources contains “StrongAuthenticationPhoneAppDetail”
ご覧のような結果を確認できます。
個人情報満載なので、結果画面の詳細まではお見せできないですが、こんな感じで監査ログを利用できますよ。
■ ■ ■
最後になりますが、監査ログにはAzure ADの監査ログとMicrosoft 365の監査ログがあり、
Microsoft 365の監査ログはOffice 365セキュリティ/コンプライアンス管理ポータルからアクセスできます。
https://protection.office.com/unifiedauditlog
こちらはMicrosoft 365のリソースに誰がいつアクセスしたかについて追跡するもので、
Azure ADの監査ログと名前は同じなのに見えるログは全く違うという人騒がせなツールです。これについてはまた別の機会に触れたいと思います。
