Microsoft 365 監査ログコレクション

監査ログは、顧客テナントと Microsoft 365 内部インフラストラクチャの両方を維持、トラブルシューティング、保護する上で重要な役割を果たします。 Microsoft 365 が動作する規模のため、監査ログの収集と処理は、効率的で効果的な監視を確保するために戦略的に管理する必要があります。 この記事では、キャプチャされるイベントの種類、各ログに含まれる情報、ログ ポリシーの適用方法、ライフサイクルのすべての段階でのログ データの保護方法など、Microsoft 365 の監査ログ記録のプラクティスの概要について説明します。

監査可能なイベントの定義

Microsoft 365 セキュリティ チームは、Microsoft 365 全体で収集する必要があるベースライン ログの定義を担当します。 各システムがキャプチャする必要があるイベントの種類の公式リストと、ログに記録された各イベントに含まれている必要があるデータを保持します。

Microsoft 365 は、次のようなさまざまなソースからログ データをキャプチャします。

  • イベント ログ
  • AppLocker ログ
  • パフォーマンス データ
  • System Center データ
  • 通話の詳細レコード
  • エクスペリエンス データの品質
  • IIS Web Server ログ
  • ログのSQL Server
  • Syslog データ
  • セキュリティ監査ログ

この一覧の各ログには、イベントの種類、ソース、場所、結果、時刻、および関連付けられているエンティティを確立するために、少なくとも次の情報が含まれている必要があります。

  • ソース ユーザー ID
  • ターゲット ユーザー ID – イベントの種類に関連する/適切なユーザー ID
  • イベント タイムスタンプ (日付 & 時刻)
  • イベントの詳細
    • 結果 (成功/失敗)
    • 詳細情報 – イベントの種類ごとに定義されます
  • ソース & ターゲット ホスト名 – イベントの種類に関連する/適切なホスト名
  • ソース & ターゲット ネットワーク アドレスとプロトコル - イベントの種類に関連する/適切な

監査可能なイベントと関連データの一覧は、進行中のリスク評価、Microsoft 365 セキュリティ標準、ビジネス要件、コンプライアンス要件によって通知されます。 Microsoft 365 セキュリティ チームは、監査可能なイベントのリストを見直して更新し、新しい脅威、システムの変更、過去のインシデントから得られた教訓、変化するコンプライアンス要件について考慮します。

サービス チームは、Microsoft 365 セキュリティ チームによって定義された監査可能なイベントの一覧に加えて、サービスの追加のログ記録要件を定義できます。 アプリケーション固有のイベントについては、サービスの見直しや機能マイルストーンの計画フェーズで見直され、更新されます。 また、Microsoft 365 セキュリティ チームは、個々のサービス チームが特定のニーズを満たすように監査機能をガイドするのにも役立ちます。 サービス レベルの監査可能なイベントは、システムに大幅な変更が加えられるたびにレビューおよび更新されます。

Microsoft の規模により、キャプチャされたデータの量と、それを格納および処理する機能とのバランスが取れている必要があります。 可能なすべてのイベントとその中の内容に関する情報を収集することは、リソースと分析の両方の観点から実用的ではありません。 収集されたログ データの種類を選択することで、Microsoft は情報システムの正常性とセキュリティを効率的かつ効果的な方法で維持できます。

集中管理

Microsoft 365 は、Microsoft 365 セキュリティ チームによって設定されたポリシーを通じて、ログ要件を一元的に適用します。 各 Microsoft 365 システムには、システム ベースラインの一部としてインストールされるカスタム ログ エージェント Office Data Loader (ODL) が含まれている必要があります。 ODL は中央ログ ポリシーを適用し、Microsoft 365 Security によって定義されたイベントを収集して、処理とストレージ用の一元化されたサービスに送信するように構成されています。

ODL は、すべてのエンド ユーザー情報を自動的にスクラブし、5 分ごとにバッチでイベントをアップロードするように構成されています。 テナント情報やエンド ユーザーを特定できる情報など、顧客データを含むフィールドはすべて削除され、ハッシュ値に置き換えられます。 監査レコードの内容と時間順序に対する永続的または元に戻せない変更は、前に説明したスクラブとは別に禁止されています。

ログ データは、ほぼリアルタイム (NRT) 分析のために独自のセキュリティ監視ソリューションにアップロードされ、潜在的なセキュリティ イベントとパフォーマンス インジケーターのログを確認します。 ログは、長期ストレージ用の内部ビッグ データ コンピューティング サービス (Azure Data Lake) にもアップロードされます。 すべてのログ データ転送は、FIPS 140-2 で検証された TLS 接続経由で行われ、転送中のデータの機密性が確保されます。

Azure Data Lake に格納されているほとんどの監査ログ データは、セキュリティ インシデントの調査をサポートし、規制の保持要件を満たすために、少なくとも 1 年間保持されます。 サービス チームは、アプリケーションのニーズをサポートするために、特定の種類のログ データに対して 90 日以上の代替保有期間を選択できます。 Microsoft 365 のログの保持とバックアップに関する ポリシーにより、インシデント調査、コンプライアンス報告、およびその他の事業上の要求にいつでも対応できるようにログ データが維持されます。

アクセス制御

Microsoft は、Microsoft 365 内で発生するすべての委任、特権、操作の広範な監視と監査を実行します。 Azure Data Lake に格納されている Microsoft 365 データへのアクセスは、承認された担当者に制限され、セキュリティ イベント分析のためにすべてのアクセス制御要求と承認がキャプチャされます。 Microsoft では、ほぼリアルタイムでアクセス レベルを確認し、ビジネス上の正当な理由を承認し、資格要件を満たしているユーザーのみがシステムにアクセスできることを確認します。 許可されているすべてのアクセスは、一意のユーザーに対してトレース可能です。

Microsoft では、監査ログの管理を、監査機能を担当するセキュリティ チーム メンバーの限定されたサブセットに制限します。 Microsoft の内部アクセス制御 の哲学 は、Just-In-Time (JIT) と Just-Enough-Access (JEA) の原則に基づいています。 そのため、セキュリティ チームは Azure Data Lake への永続的な管理アクセス権を持たず、すべての変更が記録および監査されます。