当記事は、主にMicrosoft365/M365(旧Office365/O365)を管理者の立場で利用している方向けの記事です。M365の利用者はどこからでもアクセスができて便利ですが、管理者としてはセキュリティやトラブル対応、重要なデータ管理・利用状況の把握などクラウドになっても課題は日々増え続けます。

そうした中で、M365 監査ログを集めておき、それを簡単に分析できるようにしておくと、管理者にとって役に立つことが分かっています。ここでは、M365 監査ログが必要な背景や、実際に監査ログを出してみたときの問題点、どうやって簡単に見ることができるのかをご紹介しています。ここではざっくりとしたご紹介までなので、詳しいやり方などご質問のある方は、お気軽に弊社までご相談ください。

M365 監査ログを取っておくべき理由

こんにちは。この記事を担当するポトフです。皆さんはM365(旧 O365 以下、M365)をお使いでしょうか。中には個人で契約して使う方もいらっしゃると思います。M365は多くの方が使うクラウドサービスの１つで、学校や職場以外の自宅や外出先からいつでもブラウザを通して利用できる便利なサービスです。

ただ、どこからでもアクセスができる反面、気がついたら誰でも見える場所にファイルが置かれているなど、これまで以上にセキュリティ面に気を遣う必要があります。また、突然データが参照できなくなる、送ったメールが届かないなどのトラブルがあった時は、誰に聞いてどこを見ればよいか分からないことが多いと聞いています。

これは今まで社内システムを管理していた担当者がM365に詳しくない、技術に詳しくない方が本来の業務と兼任するなどで、すぐに対応が出来ないことが理由にあります。

Microsoft社のサポートを受けることも可能ですが、学校や職場のデータはお客様がコントロールすることになっています。こうしたことは使ってみないと分からないことも多いと思いますが、扱うデータが重要になるにつれてログ分析をしてM365の利用状況把握を定期的に行っておくことをお勧めします。

具体的には定期的にデータをバックアップしておくことや、ここでご紹介するM365のログ（監査ログ）を長期間保管して定期的にログ分析することが必要になります。まとめると以下のようなことが言えます。

• クラウドサービス利用ではこれまで以上にセキュリティは重要
• トラブルを早く解決したいことはクラウドになっても変わらない
• 重要なデータがあるほど、監査ログから利用状況の把握をすることが大事

クラウドサービス利用ではこれまで以上にセキュリティが重要

M365はクラウドサービスであるため、そのシステムやデータを自前のデータセンターやサーバーに置くことができません。

インターネットを通じてどこからでも利用できる利便性を考えると、これまでのように学校や職場、自宅からしかアクセスできないようにすることもできず、世界中から誰でもお使いのM365アカウントにログインを試みることができます。

Microsoft社も独自のセキュリティ対策をしていますが、「パスワードが漏れて不正にログインされた」、「担当者が誤ってデータを一般公開した」などは対策してくれません。

導入当初は様々な制限やセキュリティ対策を講じていても、ビジネス要件の変更やユーザーからの要望による制限緩和などを繰り返した結果、気がつかない間にセキュリティが弱くなっていることがよくあります。

M365 監査ログにはそうした一般公開した操作(Operatoin「AnonymousLinkCreated ※リンクを知っていれば世界中誰でもファイルにアクセスできるように公開する操作」)やファイル名(SourceFileName)、操作した人(UserId)などの情報が出力されるので、管理者があとで分かるようにログを使って定期的なチェックできるようにしておくことが有効です。

トラブルを早く解決したいのはクラウドになっても同じ

クラウドサービスに関係なく学校や職場で使うシステムは複数の人がアクセスします。そのようなシステムでは「突然データが消えた」、「送ったメールが届かない」などのトラブルがあります。

単に誰かの操作ミスなのか、システム側に問題があったのかを切り分ける必要がありますが、そもそも誰に聞けばよいのか、システムがブラックボックス、複雑であるほど切り分けが難しいです。

管理者であってもM365のシステムやサービスは複雑で全てを把握することは難しく、素早くトラブルの切り分けをするためには監査ログの長期保管と、いつでもログを簡単に検索できることが有効です。M365監査ログにはそうしたファイルを削除した操作(Operatoin「FileDeleted」)やファイル名(SourceFileName)、操作した人またはシステム(UserId)などの情報が出力されます。

※LogStare Collector でM365 監査ログの中でファイルアクセスログを検索している様子

重要なデータがあるほど、監査ログから利用状況の把握をすることが大事

Microsoft社も独自の対策により重要なデータがあるM365クラウドサービスを安定的に提供するために、大規模な災害時の対応でデータセンターに自家発電設備を配置するなど対策をしています。そのため、有事の際でも基本的に安心して使えるものと思います。ここではそのような頻繁に発生しない災害よりも、重要なデータを見失うことや、消失してしまうことに気をつけておくことを考えます。

実際に使ってみないと何が起こるのか分かりませんが、重要なデータがどのような状態になっているかを常に把握していないと、気がついたらそのデータが誰かの誤操作によって簡単に失われてしまうことがあります。

これは災害よりも良くあるケースで、定期的にバックアップを取ったとしても重要なデータが2週間前に消えていたとき、１週間前のバックアップデータには残っていません。もし2週間前のバックアップも既にない場合は取り返しがつかない状態になります。

普段より監査ログから利用状況の把握、ここでは重要なファイルが日々どのように操作されているかを把握しておかなければ、いざとなった時に管理者としては知らなかったでは済まされない状況に陥る可能性もあります。

忙しい中でも普段からユーザーの利用状況を簡単に把握できる仕組みを持っておき、運用を行っておくことが重要です。そうすることで初めて管理者として「重要なデータが常に問題ない状態であることを把握している」と言えるでしょう。

M365 監査ログでは重要なファイルに対する移動・リネームした操作(Operatoin「FileMoved/FileRenamed」)や元ファイル名(SourceFileName)、変更先ファイル名（DestinationFileName）、操作した人(UserId)などの情報が出力されます。

※M365に特化した弊社ログ分析基盤サービスでM365 監査ログを分析している様子
ファイル削除やフォルダ削除などユーザー操作のサマリレポートがあります。

事前の準備 M365 監査ログの出し方

M365のプランには監査ログの機能が通常含まれており追加費用はかかりませんが、契約した時点では無効状態です。

有効にするには管理者ユーザーでMicrosoft管理センターの「コンプライアンス」からM365コンプライアンスセンターにログインして、「監査」を選択し、「ユーザーと管理者のアクティビティの記録を開始する」をクリックする必要があります。

事前の準備はこれで終わりです。なお、一度有効にすると画面から無効にすることはできません。Microsoft社が提供するコマンドを裏で実行する必要があります。

有効にすると、24時間後ぐらいからログが集め始められて、同じM365コンプライアンスセンター上の監査画面に表示される検索画面からログを検索することができます。

M365　監査ログについての疑問点まとめ

ここで私や周りの人たちから聞いた、M365 監査ログの疑問に思ったことをまとめてみました。恐らく皆さんも同じ疑問や他で見聞きしたことがあるかもしれません。この情報は2022年2月時点の情報であるため、内容が変わっている可能性はあります。予めご了承ください。

M365 監査ログはどのようなログが見えるのか？

基本的に SharePpoint / OneDrive / MicrosoftTeams / Microsoft Exchange / AzureActiveDirectory / その他コンプライアンス系 などのログが見えます。逆に特定の監査ログを出さないように選ぶことはできません。

SharePointは、主にファイルやディレクトリの操作、アップロード、ファイル共有などの操作ログが見えます。

OneDriveは、実は内部的にSharePointをファイルの置き場所として利用している関係で似たようなログが見えます。

McrosoftTeamsは、チームやチャネルの作成、ファイルのアップロード・ダウンロードが見えます。チャットの内容は見えません。

Exchangeは基本的にメールの受信のみで、メールの件名、添付ファイルサイズなど、メールの内容は見えません。E5ユーザーなどの上位のサブスクリプションになるとメールの送信ログが見えます。

AzureActiveDirectoryは、M365へのログインやログイン失敗ログなどが見えますが、最近はブラウザのパスワード補完機能などもあって、正規のユーザーがログインに失敗するケースは少ないようです。

その他コンプライアンス系では、M365のシステム内で受信したメールがスパムと判断された場合の隔離や検疫処理などのログです。

例えば、下記はM365コンプライアンスセンター上の検索画面からダウンロードしたログです。OperationにあるAnonymousLinkUsedは、このURLを知る不特定多数のユーザーがアクセスしていることを表しており、ブラウザ経由でOneDrive上のフォルダ「外部からの受取フォルダ」からアクセスされていることが分かります。リンクの作成などは、OperationにAnonymousLinkCreatedという文字が入ってきます。

M365 監査ログはいつ出てくるのか？

操作がされてすぐにログは検索できません。早くても30分～1時間後、遅いと24時間後になることもあるようです。

M365 監査ログの保存期間はいつまで？

基本的には90日で伸ばす設定は不可です。E5ユーザーのサブスクリプションになると1年以上保存できますが、E5に契約するだけでもそれなりのコストがかかります。

M365 監査ログをダウンロードして手元に持っておくことはできるか？

M365コンプライアンスセンター上の検索画面からエクスポートボタンを毎回手動で押すことで可能です。ダウンロードしたログをファイルはテキスト(CSV形式)で圧縮されていません。

ダウンロードしたM365 監査ログの使い方は？

ダウンロードしたファイルをメモ帳なりで開いて検索することは可能です。画面上では、CSV形式としてダウンロードとなっていますが、中身はJSONという形式で人が読む分には読みづらいです。また、ファイルサイズも非常に大きくなりがちなので、メモ帳では開くのに時間もかかります。頑張ってグラフなどにすることも出来るかもしれませんが、それなりの開発努力とログを解読する技術力が必要です。

ログは固定の長さではなく、サービスの種類によって内容も異なります。それらがまとめてダウンロードされるので仕分けも大変になると思います。なお、ログに出てくるユーザーの操作(ファイル削除やファイル作成など)は100種類以上あると推定されます。

M365 監査ログのタイムスタンプは？

M365監査ログの検索画面上では、ユーザーの言語かロケール設定に合わせて、日本ではJST(日本時間)で見えるようですが、いざログをダウンロードしてJSON形式のログを見ると全てUTC（日本時間のマイナス9時間）で出ます。日本で使っているからJST(日本時間)とはならず、設定も変更できずとても見づらいです。

以上がM365 監査ログを有効にしたあと、私や周りで疑問に思ったことの答えになります。

監査ログを有効にしたものの、次のステップは

1つ前の「事前の準備」でM365 監査ログを有効にして、ログの検索や検索した結果をダウンロードすることができました。ただ、どうも冒頭の「はじめに」にあったイメージから遠く、とても気軽にできない状態です。特にタイムスタンプがUTC、ダウンロードしてもデータ量が多くてJSON形式でサービスによってログの項目もバラバラで、グラフィカルではないなどあります。

M365 監査ログを有効にしたものの、ほとんどのM365管理者はこのような壁に当たっているのではないでしょうか。弊社でもM365を利用しており、社内の情報システム担当者も同じことを申しておりました。

今回、そのような中で弊社LogStare社では、これらの壁に当たっている人が、より簡単にM365 監査ログを収集して見やすくできるようM365 監査ログ収集に対応した製品開発に乗り出しました。この強化により、M365におけるセキュリティ対策向上・トラブルの早期発見・重要なデータに対するグラフィカルな定期監査レポートメールが出せるようになります。
簡単設定 セキュリティ対策 DX推進　勤怠管理｜見えるM365　ログステア M365

M365が登場してから久しいですが、リモートワークや働き方改革（DX推進）が進む中、これらの対策や対応においてこの強化した機能はシステム担当者・管理者の負荷軽減に有効であると考えております。

LogStare CollectorでM365 監査ログを取ってみた

ここからは、2022年2月14日にリリースされたLogStareCollecetorv2.2.0以降に搭載されている新機能「M365 監査ログ収集機能」を使って弊社の検証環境で試した方法をご案内します。なお、M365の設定方法等については、2022年1月時点での内容を元に記載しております。
※監査ログを専門知識不要で収集・分析できるクラウドサービスはこちら

要件

LogStareサーバー(LSC)のM365監査ログ収集の主な要件は下記のとおりです。

• 契約中のM365サービス上でM365監査ログ出力設定をしていること
• 契約中のM365サービス上でLSCがM365へアクセスするための情報(シークレットキー等)を登録していること
• LogStareサーバーとM365クラウド間でHTTPSの疎通ができること（シングルサインオン等を経由の場合、接続可能か要確認）
• 時刻同期がされていること（タイムゾーンは規定値でJST）

うまく取れない状況があり通信経路が問題かを確認する際は一度ネットワーク経路を他に切り替えるなどしてお試しください。
なお、シングルサインオンを経由して試したところうまく通信ができず、M365からログデータの収集が出来ないケースがありました。

手順１．Microsoft Azureポータル画面でアプリを登録します

1. Microsoft Azureポータルへログイン
2. 「アプリの登録」を検索して「新規登録」ボタン
3. 名前を「LSC」、「この組織ディレクトリのみに含まれるアカウント」として登録

以上が手順１です。

手順２．Microsoft Azureポータル画面でアプリのアクセス許可をします

• Microsoft Azureポータルへログイン（手順１の画面のまま）
• メニュー「APIのアクセス許可」を押す
• 「アクセス許可の追加」からOffice365 Management APIsの権限で、ActivityFeed.Read/ActivityFeed.ReadDlpを追加
• 「管理者の同意を与えます」を押して同意が与えられるまで待つ
• API / アクセス許可の名前「Office 365 Management APIs(4)」となっていることを確認する

執筆時点では、2つの任意済みアクセス許可が最初から登録されていますが、もし無いようでしたら画面と同じように4つの項目を登録してください。

以上が手順２です。

手順３．Microsoft Azureポータル画面でシークレットIDを追加します

• Microsoft Azureポータルへログイン（手順２の画面のまま）
• メニュー「証明書とシークレット」を押す

「新しいクライアントシークレット」を押して、「起動」「終了」の期間を入力。
執筆前は「無期限」設定がありましたが、執筆時では最長２年となっています。
M365側のポリシーで推奨期間も変更されることがあります。

期限が切れると再度クライアントシークレットを作り直して、LogStare Collectorに再設定する必要があります。
これを忘れると監査ログが取れなくなります。ここではクライアントシークレットを２年にしています。
設定後、新しいクライアントシークレットが追加され、シークレットキー（「値」の部分）とシークレットIDが登録されます。

 

以上が手順３です。

ここまでMicrosoftのAzureポータル上で行う作業になります。

手順４．LogStare Collector をインストールします

• 無償版は、以下 へアクセスします
  • 【無償版】LogStare Collector
• Webの入力フォームに従ってダウンロードの手続きをします

無償版は有償版と同等のフル機能をインストールしてから30日間使うことが出来ます。また、評価版はこの後で構築したLogStare Collectorと弊社LogStare社のログ分析基盤サービス(LogStare Reporter)と連携させることでグラフィカルにログを分析することができます。
※無償版をインストールしてから30日が経過すると、M365監査ログは収集できますが、ログの保管は10日になる等機能が制限されます。

• 手続き後の案内やライセンスファイルなどを基にインストールを行います。

※今回は以下の記事を参考にWindowsにインストールしています。
LogStare Collectorインストールからアンインストールまで Windows版

• LSCをインストールするとブラウザからアクセスしてログイン画面を表示できます。

規定値のユーザー名とパスワードは、LSCマニュアルをご覧ください。

 

以上が手順４です。

手順５．デバイス登録とメモしたアプリの登録情報をセットします

• LogStare Collectorへログイン（手順４の画面の続き）
• メニュー「デバイス・グループ」を選択、規定値のグループ「MyNetwork」を選択
• 右端「＋」ボタン、デバイス名「M365」、IPアドレス「127.0.0.1」として追加ボタンを押す

ここまでがデバイス登録です。引き続きM365監査ログの収集設定を行います。

• LogStare Collectorへログイン（上記画面の続き）
• メニュー「監視・収集」を選択
• 右端「＋」ボタン、「収集」、「Office365監査ログ」を選択
• 認証情報にMicrosoft社のポータル画面でメモしたアプリの情報を入力

クライアントIDには、アプリケーションID（クライアントID）を入力します。
クライアントシークレットには、シークレットキー（「値」の部分）を入力します。
テナントドメインには、テナントIDに紐づくテナント名またはテナントドメインを入力します。
※テナントドメインは「[テナント名].onmicrosoft.com」という形式
テナントGUIDには、ディレクトリID（テナントID）を入力します。
シークレットキー期間は登録した際の期限を入れます。ここでは最長の２年です。

※執筆時点では既に無期限を入れて作ることができなくなりました
※テストボタンを押すことで、監査ログがLogStareCollectorから収集できるかテストできます。

Microsoft社の管理画面上で監査ログを有効にしても約24時間後にログが出る為、エラーが出た場合はしばらく時間をおいてから再度行っていただくと良いと思います。テストボタンを押した際と設定を保存した際にサブスクリプション開始をしても良いか求められます。OKボタンを押すことで外部からOffice365 Management APIs経由でログの収集ができることに同意したことになります。

• 追加ボタンを押す

以上が手順５です。

Attention!：「コンテンツタイプの有効化が失敗しました – 400 Bad Request」というエラーコードが表示された場合、設定した値に誤りがある可能性があります。このエラーは、M365側と疎通自体は問題なくできていることを表しています。このメッセージはM365側で出力しています。

「コンテンツタイプの有効化」とは、このLSCで利用する設定内容（M365側で登録したアプリ）を使ってM365側のフラグを有効化する設定です。この有効化によりアプリからログの収集が出来るようになります。

M365側に不備があった場合は、恐らく別のエラーコードやメッセージが出てくるものと考えられます。特にシークレットキーの値は、M365側で設定した時の画面に１度しか出てきませんので、値の取得と入力にご注意ください。取得し忘れた場合は再度シークレットキーを作り直すことで対応します。

Attention!：「コンテンツタイプの有効化が失敗しました。 – The permission set () sent in the request does not include the expected permission.」というエラーが表示された場合、必要な権限の設定が不足している可能性があります。

当記事の「手順２．Microsoft Azureポータル画面でアプリのアクセス許可をします」や「事前の準備 M365 監査ログの出し方」を参照し、Microsoft Azureポータル画面よりアプリのアクセス許可とM365 監査ログの状態について再確認してください。

手順６．LogStare Collector で収集したログを表示します

• LogStare Collectorへログイン（手順５の画面の続き）
• メニュー「検索・ダウンロード」を選択、規定値のグループ「MyNetwork→M365→Office365監査ログ-Office365-AuditLog」を選択
• 検索期間、条件に「FileAccessedを含む」として検索ボタンを押す

※ここでは、SharePoint上からファイルにアクセスされたことを示す監査ログを表示しています。

以上が手順６です。

ここまでの作業により、LogStare Collectorが定期的に自動でログを収集して圧縮保管します。収集したいログは選択することも可能です。タイムスタンプは、日本時間になるよう設定もでき、検索の絞り込みは複数指定して日本語を使って文字列指定も可能です。

手順７．ログ分析基盤サービス(LogStare Reporter)上でログ分析レポートを表示します

手順６まではM365 監査ログをMicrosoft社のポータル上で出力する設定、LogStare Collectorをインストールして監査ログを自動で収集して検索するところまでを見てきました。

ここでは、これまでに構築したLogStare Collector と弊社のログ分析基盤サービス(LogStare Reporter)を連携して、ログをグラフィカルに監査して定期的にログ分析レポートを見る流れをご紹介します。実際にお使いになる際の詳しい方法は、お申込みいただいた際のドキュメントや案内をご覧ください。
※M365の監査・分析に特化した製品はこちら

まず、ログ分析基盤サービスを利用するには、LogStare Collectorと弊社のログ分析基盤サービス(LogStare Reporter)を連携するライセンスが必要です。評価版のライセンスがございますので、こちらからお問い合わせください。届いたファイルをLogStare Collector の管理画面にあるメニュー「ライセンス」に登録するだけです。

※インストールしたLogStare Collectorに連携用のライセンスを追加した画面

以上でM365 監査ログのデータが自動でログ分析基盤サービス(LogStare Reporter)に送られて、ログ分析レポートを定期的に作成しますので、後はログ分析基盤サービスのポータル画面にログインすれば、ログ分析レポートを見ることができるようになります。

下記はそのログ分析レポートの一例で、メールで定期的に送信、PDFで取り出してみることも可能です。

※ログ分析のサンプルPDFレポート

※過去1週間分の監査ログからユーザーの操作サマリを見てファイル移動2件の詳細を見る画面

この例では先週1週間分のM365監査ログから1週間にあった操作（ファイル操作・Teamの作成・グループ/ユーザー作成など）を分析しています。

この中でファイル移動(FileMoved)が2件あったことが分かりました。詳しく調べると、顧客管理と請求先一覧のエクセルファイルがuser1@aa.comというユーザーによって一時的な置き場所に移動されたことが分かります。本来はコピーをするところを誤って移動してしまった可能性もあります。

※過去1週間分の監査ログからユーザーがMicrosoftTeamsでチャネルを作ったログ詳細を見る画面

この例では先週1週間分のM365監査ログから1週間にあったMicrosoftTeams上でチャネル作成操作(OperationにChannelAddedとある監査ログ)を分析しています。

この中でテストグループ内にテストチャンネルがuser2@aa.comというユーザーによって作成されたことが分かります。

プライベートチャンネルの場合は、管理者でも見ることができないため、ここで重要な会話や重要なファイルのやり取りがあっても管理者は気が付かないことがあります。

このようにM365監査ログを取って、弊社のログ分析基盤サービスでログ分析をすることで、すぐに気がつかなかったユーザーの操作を簡単に確認することができました。

以上が、「Microsoft 365 監査ログの取得方法｜絶対に取っておくべき理由や保存期間も解説」の記事です。

※LogStare Collectorについて詳しくは以下のリンクをご覧ください
・LogStare Collectorとは

 

一通りの設定を終えて

ここまでで、LogStare Collectorで M365 監査ログの収集と、最後に弊社のログ分析基盤サービスとの連携をしてログ分析レポートを見てみました。アプリの登録やアプリのアクセス許可など、一部Microsoft社の管理画面操作は必要なものの、一度行ってしまえばそれ以降は触らずにM365 監査ログを自動で収集します。

今回の製品強化で基本的に全てのM365 監査ログに対応し、レポートテンプレートも60種類以上を用意しており、全てのレポートにおいてカスタマイズも行うことが可能です。今後もご要望に応じて拡張を検討したいと考えています。

この記事では細かい説明は省いていますので、設定や動作など気になることや、このサービスに対応して欲しいといった要望がありましたら是非お問い合わせいただければと思います。

ここまで閲覧いただき誠にありがとうございました。 （記：ポトフ）

※関連記事
・Microsoft 365/Office365の監査ログからAzureActiveDirectoryのログを分析してみた
・Microsoft Exchange Onlineのスパム対策
・SharePoint/OneDrive/Teamsの監査ログをMicrosoft365（Office365）のログから分析

記載されている会社名、システム名、製品名は一般に各社の登録商標または商標です。

当社製品以外のサードパーティ製品の設定内容につきましては、弊社サポート対象外となります。