当記事は、M365を管理者の立場で利用している方向けの記事です。管理者としては、社内で利用するシステムのトラブル対応やセキュリティ対策など、システムがクラウドになってもその業務は変わりません。そうした中で、M365 監査ログを集めておき、それを簡単に分析できるようにしておくと、管理者にとって役に立つことが分かっています。
ここでは、特にM365サービスでも重要なサービス、AzureActiveDirectoryの監査ログから実際に何が分かるのか、どうやって簡単に見ることができるのかをご紹介しています。
ここではざっくりとしたご紹介までなので、詳しいやり方などご質問のある方は、お気軽に弊社までご相談ください。なお、本記事は2022年2月時点の情報であり、今後、内容が変わる可能性があります。予めご了承ください。
※M365 監査ログの取得方法について詳しくは以下の記事をご覧ください
・Microsoft 365 監査ログの取得方法
目次
AzureActiveDirectoryのトラブルに早期対応するための M365 監査ログ分析方法
こんにちは。この記事を担当するポトフです。記事をご覧でM365を利用されている方の中には、監査ログをまだ管理・収集していない方や、ログは取っていても分析していない方も多くいらっしゃると思います。M365には、ご承知の通りSharePointやOneDrive・Microsoft Teamsなど多くのサービスがあり、M365 監査ログには各サービスを操作するユーザーのさまざまな操作が記録されます。例えば、M365上でOneDriveやSharePointでファイルを削除する、Microsoft Teamsでファイルをアップロードするなどがあります。
M365サービスの中でも、特にAzureActiveDirectoryサービスは最も利用されるサービスの１つであり、ユーザーの操作ログも多く出力されます。このサービスはM365を利用するユーザーのログイン認証やユーザー管理（作成・変更・削除）・グループ管理（作成・変更・削除）操作などを行うことができ、他のサービスを利用する上でも密接に関係します。
そのため、AzureActiveDirectoryサービスでログインが突然できないトラブルが発生すると管理者に問い合わせがあり、急いでトラブルの原因を調査・対応する必要が出てきます。また、パスワードなどが漏洩してユーザーアカウントが乗っ取られ、セキュリティインシデントが発生していても気がつかない状態が長く続く、管理者の知らない間にユーザーやグループが作られていたケースもあるかもしれません。
ここでは、そのようなことがいつ起こったのか把握するため、監査ログがどのようなもので、どのように分析して役に立つのかに触れます。
監査ログを通してAzureActiveDirectoryにまつわるトラブルの早期対応やセキュリティインシデント発見につなげて、M365管理者の日々の業務負担を軽減する一助になればと考えています。
AzureActiveDirectoryの監査ログとは
下記はAzureActiveDirectoryから実際に出力された監査ログの一例です。AzureActiveDirectoryに限らず全てのM365 監査ログはこのようにJSONと呼ばれる形式で出力されます。全てのログには共通情報としてCreationTime（操作ログの時間）、Workload（ログを出力したサービス名）、UserId（操作したユーザーID）などがあります。
OperationにあるUserLoggedInは、ユーザーがM365にログインした時の操作を指しており、その横にある文字列からWindowsの端末からブラウザ経由でアクセスしていることが分かります。Operationは、他にもユーザーの作成やグループの削除などの操作などが分かるようになっています。ActiveAzureDirectoryのOperationについては後ほど改めてご紹介します。監査ログでは、ResultStatusがSuccessとあるため、ログインは成功したことも分かります。その他の情報としてはUserId（ログインしたユーザーID）、ClientIP（ログインした端末のIPアドレス）、CreationTime（ログインした時間）などがあります。
AzureActiveDirectoryの監査ログを実際に見るには
M365 監査ログは、通常M365の管理画面上から監査ログを有効にすることで、同じ管理画面上で下記の画面から検索できます。
この画面では、全ての監査ログを検索できますが、グラフィカルなログ分析や表示を自由に変更することはできません。収集したログはCSV形式でダウンロードできますが、開くと先ほどのJSON形式になっており、人が見るにはかなり扱いにくいのではと思います。また、ログも90日しか保管が出来ないといった制約があります(E5ユーザーなど上位クラスのコストをかけたサブスクリプションを契約すると監査ログの保存期間は伸ばせます)。
そこで、弊社が開発するLogStare Collectorを使って90日を超える任意の期間ログを圧縮(約10分の1に)して長期間保管する仕組みと、弊社のログ分析基盤サービスを利用することによって、グラフィカルなログ分析や表示を自由に変更することができます。CSV形式でログもダウンロードでき、PDFなどの帳票レポートも出力できます。
※LogStare Collectorについて詳しくは以下のリンクをご覧ください
LogStare Collectorとは
※LogStare Collector でM365監査ログを収集して検索する画面イメージ
※ログ分析基盤サービスを使ってログを分析する画面イメージ
※ログ分析基盤サービスを使って出力したM365 監査ログ分析レポートイメージ
AzureActiveDirectory 監査ログを分析してみた
ここでは、LogStare Collector とログ分析基盤サービス(LogStare Reporter)を通して収集したAzureActiveDirectory 監査ログを分析した詳細手順をご案内しています。大まかな流れは下記の通りです。
今回は過去1週間分のAzureActiveDirectory 監査ログを対象に分析しました。分析にかかった時間はものの数分程度でした(※実際はその時に分析するログ量や対象期間にも依存します。予めご了承ください)。
※LogStare ReporterでM365ログ分析レポートテンプレートを選択する画面イメージ
まず、弊社のログ分析基盤サービスにログインします。次にログイン後、レポート一覧からM365ログレポートテンプレートを選択します。この画面では63個のレポートテンプレートがあることが分かります。レポート閲覧ボタンを押すことで、ログ分析レポートを見ることができます。
数あるログ分析レポートテンプレートの中から、「800.AzureActiveDirectoryサマリ」テンプレートをクリックするとサマリレポートが表示されます。この例では、先週1週間分のAzureActiveDirectory監査ログから1週間にあったAzureActiveDirectoryの操作（グループの作成や削除・ユーザーの作成や削除・パスワード変更・ログインやログイン失敗など）を分析しています。
この中でログイン(UserLoggedIn)が一番多いことが分かります。また、グループの追加(Add Group.)が1件、パスワードの変更(Change user password.)が4件、ユーザーの作成(Add user.)が2件、ユーザーの削除(Delete user.)が3件あります。これらは基本的に管理者による操作であるため、実際に過去1週間以内に操作が行われていれば、それに相当する監査ログも出力されているはずです。身に覚えのない操作があった場合は、詳細を更に調べる必要があります。
次に、パスワードの変更(Change user password. なぜか操作に「.」ドットがついていますが、これはM365監査ログの仕様です。文字列検索時には「.」ドットも含める必要があります)が4件あります。パスワードの変更は以前、定期的に変えることを推奨されていたことが多くありました。しかし最近、パスワード変更は逆にセキュリティ強度を下げる恐れがあるなどで行わないケースもあります。そうしたパスワード変更ルールと運用に沿っているのかどうかをログ分析から見ることができます。
続いてユーザーのログイン失敗(UserLoginFailed なぜかこちらの操作には「.」ドットがありませんが、これもM365監査ログの仕様です)が13件あることが分かります。ログインの失敗は単にユーザーがパスワードを忘れて失敗していること以外にも、不正にログインを試みようとしている、パスワード変更がされたことで前のパスワードでログインし続けようとしている、M365のポリシー(例えば設定した期限を超えると自動的にログインできなくなる)など理由は様々です。
最近は、ブラウザやアプリにパスワードを記憶させておくことで自動的にユーザーがパスワードを入れずともログインできてしまう為、ログイン失敗自体も少ない傾向にあります。13件という数値が適正なのかどうかは、定期的にログ分析をして運用を通してそのシステムでは問題ない数値かどうかを見極めることができます。
社員数にもよりますが、100～300人規模の規模で、毎日1,000回以上のログイン失敗があると1人当たり3回から10回失敗していることになります。明らかにおかしいのでその場合は詳細を追っていく必要があると考えられます。
※UserLoginFailedのログ13件のログを表示する画面イメージ
最後に、ユーザーのログイン失敗13件について詳細を追ってみます。先ほどの「800.AzureActiveDirectoryサマリ」テンプレートのサマリレポートからUserLogginFailedをクリックして、その下にあるログ表示ボタンを押します。上記の通り、13件の生ログが項目に分けられて表示されます。
この中でResultStatusが「Success（失敗に成功した？）」というのは気になりますが、失敗した時間(ログ日時)、失敗したユーザー(UserId)や接続元のIPアドレス(ClientIP)などが分かります。ただ、実際どのような理由で失敗したのかは、LogonErrorという情報にあるテキストメッセージを見ていく必要があります。
※ログイン失敗のログに記載されたSsoArtifactRevokedのメッセージ詳細を検索した結果イメージ
ご参考までに、今回確認した13件のログにあったSsoArtifactRevokedについて調べてみました。
※詳細はMicrosoft社の以下のページよりご覧いただくことができます。
Microsoft｜Azure AD 認証と承認のエラー コード
※UserLogginFailedのログにあるLogonError1の項目を集計対象とするクローズアップ分析の画面イメージ
こちらは、ログ分析レポートテンプレートからクローズアップ分析を通して更に詳細にログイン失敗を分析しています。ここでは、LogonErrorという項目に着目してその理由のサマリを取っています。現在は13件と少ないですが、1,000件など数が多くなると全て見ることは難しいため、LogonErrorをキーに集計することでそれぞれ何件あったのかを再集計するカスタマイズを行っています。この設定はカスタマイズレポートとして保存することもできます。
クローズアップ分析の結果、UserStrongAuthClientAuthNRequiredInterrupt（強力な認証が必要です。ユーザーが MFA チャレンジに合格しませんでした。エラーコード：AADSTS50074）が一番多いことが分かりました。見る限りにおいては特段何かすぐに対応する必要は無いかもしれませんが、必要に応じてログにあったユーザーIDの担当者にその時間何があったのか聞いてみるのも良いかもしれません。ユーザーから連絡がある前に事前に管理者が問題を認識できる可能性もあります。
以上が、「Microsoft365/Office365のセキュリティ対策｜監査ログからAzureActiveDirectoryのログを分析してみた」の記事です。
ログ分析基盤サービスの詳細はこちら
評価版も用意しております。
一通りの設定を終えて
ここまででAzureActiveDirectory 監査ログのご紹介と、LogStare CollectorとLogStare Reporterを通して AzureActiveDirectory 監査ログを分析してみました。製品を使うことで、標準のM365の管理画面よりもグラフィカルで分かりやすく分析できることがご覧いただけたと思います。また見ていく中で管理者が見えていないユーザー操作がどれほどあり、管理者が気づいていない可能性がある操作もあったことが分かりました。
M365に限らずクラウドサービスは世界中どこからでも24時間アクセスできることから、乗っ取られたユーザー操作だと一大事です。管理者は日々忙しい中でシステムのトラブル対応だけでなくセキュリティ対策も行わなければならず、こうした見える化は、今後ますます重要になってくる働き方改革やDX推進に向けても非常に大事になってくる要素と考えます。
この記事では細かい説明は省いていますので、設定や動作など気になることや、このサービスに対応して欲しいといった要望がありましたら是非お問い合わせいただければと思います。
ここまでご覧いただき誠にありがとうございました。 （記：ポトフ）
※関連記事
Microsoft 365 監査ログの取得方法
記載されている会社名、システム名、製品名は一般に各社の登録商標または商標です。
当社製品以外のサードパーティ製品の設定内容につきましては、弊社サポート対象外となります。
