Microsoft 365セキュリティ監視ベストプラクティス

Tech

本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。

Microsoft 365セキュリティ監視ベストプラクティス

Microsoft 365は現代のビジネスに不可欠なサービスですが、その利便性と引き換えに、多岐にわたるセキュリティリスクに直面します。効果的なセキュリティ監視は、これらの脅威から組織のデータとIDを保護するために不可欠です。本記事では、Microsoft 365環境における脅威モデル、攻撃シナリオ、検出・緩和策、および運用上のベストプラクティスについて解説します。

脅威モデル

Microsoft 365環境における主な脅威は以下のカテゴリに分類されます。

  1. IDの侵害: フィッシング、クレデンシャルスタッフィング、MFA疲労攻撃などにより、ユーザーアカウントが乗っ取られるリスク。特に管理者アカウントは標的になりやすいです。

  2. データ漏洩: SharePoint Online、OneDrive for Business、Exchange Onlineなどに保存された機密データが、不正なアクセス、共有設定ミス、悪意のある内部者によって外部に流出するリスク。

  3. マルウェア/ランサムウェア: 電子メールの添付ファイルや悪意のあるリンクを介して、組織内にマルウェアが拡散し、データ暗号化やシステム停止を引き起こすリスク。

  4. 設定ミス/脆弱性の悪用: Microsoft 365および関連するEntra ID（旧Azure AD）の設定不備や、未修正の脆弱性が攻撃者に悪用され、特権昇格や永続化を許すリスク。

  5. 悪意のあるアプリケーションの同意: フィッシングによってユーザーが悪意のあるOAuthアプリケーションに同意を与え、そのアプリケーションがM365リソースへの広範なアクセス権を取得するリスク。

攻撃シナリオ

一般的なM365環境での攻撃の流れを、MermaidのAttack Chain形式で可視化します。

graph TD
    subgraph Initial Access
        A["フィッシングメール"] -->|悪意あるリンク/添付ファイル| B("認証情報窃取")
        B -->|MFA Fatigue Attack| C{"認証情報悪用"}
    end

    subgraph Persistence & Privilege Escalation
        C -->|脆弱な認証情報/レガシー認証| D["アカウント乗っ取り"]
        D -->|不正なアプリケーション同意| E("永続化: OAuthアプリ登録")
        D -->|設定ミス/脆弱性利用| F["特権昇格: グローバル管理者権限取得"]
    end

    subgraph Lateral Movement & Impact
        E -->|OAuthトークン悪用| G("SharePoint/Teams横展開")
        F -->|PowerShell/Graph API| H["データ窃取/破壊"]
        G -->|データアクセス/共有設定変更| H
        H -->|外部ストレージへのエクスポート| I["データ漏洩"]
    end

MFA疲労攻撃によるアカウント乗っ取りシナリオの例:

攻撃者は、盗んだユーザー名とパスワードを使って繰り返しサインインを試行し、ユーザーのMFAデバイスにプッシュ通知（プロンプト）を連続して送信します。ユーザーは通知にうんざりしたり、誤って「承認」ボタンを押してしまったりする可能性があります。これにより、攻撃者はMFAを突破し、正規ユーザーとしてMicrosoft 365環境にアクセスできるようになります。この種の攻撃は、2023年7月20日にMicrosoft Security Blogでも注意喚起されており[7]、最新のMicrosoft Entra ID Protectionの機能や強化されたMFA方式が求められます[3, 7]。

検出と緩和

Microsoft 365のセキュリティ監視には、組み込みの強力なツール群と設定が活用できます。

1. 統一監査ログ (Unified Audit Log, UAL) の活用

Microsoft Purview Unified Audit Logは、Exchange Online, SharePoint Online, Teams, Entra IDなど、Microsoft 365サービス全体のユーザーおよび管理者アクティビティを記録します[1]。これを活用して、不審な活動を検出します。

誤用例（対策不足）: UALのログが適切に監視されておらず、レガシー認証によるサインイン試行や成功が見過ごされる。レガシー認証はMFAをバイパスされやすいため、攻撃の初期段階で悪用されることが多いプロトコルです。

安全な代替（検出・緩和策）: UALからレガシー認証の試行を定期的に検索し、検出した場合は直ちに条件付きアクセスでブロックします。

# Unified Audit Log (UAL)からレガシー認証の試行を検出するPowerShell例


# 前提: Exchange Online PowerShell v2モジュールがインストールされ、接続済みであること


# Connect-ExchangeOnline -UserPrincipalName <AdminUPN>

# 検索対象期間を定義 (例: 過去30日間)

$StartDate = (Get-Date).AddDays(-30)
$EndDate = Get-Date

Write-Host "Unified Audit Logからレガシー認証の試行を検索中... (期間: $($StartDate) ～ $($EndDate))"

try {

    # レガシー認証クライアントからのサインイン試行イベント (UserLoggedIn) を検索します。


    # ClientAppが "Other clients" (POP, IMAP, SMTP, MAPI, RPC) であるものが該当する可能性があります。


    # より正確には、Microsoft Entra管理センターのサインインログで'Client app'列を確認することが推奨されます。

    $AuditResults = Search-UnifiedAuditLog -StartDate $StartDate -EndDate $EndDate `
        -Operations "UserLoggedIn", "UserLoginFailed" `
        -ResultSize 2000 # 取得する結果の最大数。環境に合わせて調整。

    $LegacyAuthAttempts = $AuditResults | Where-Object {
        $_.AuditData | ConvertFrom-Json | Where-Object {
            ($_.ClientApp -eq "Other clients") -or
            ($_.ClientApp -like "Exchange client" -and $_.AuthenticationMethod -ne "OAuth") -or
            ($_.ClientApp -like "POP3" -or $_.ClientApp -like "IMAP4" -or $_.ClientApp -like "SMTP" -or $_.ClientApp -like "MAPI" -or $_.ClientApp -like "RPC")
        }
    }

    if ($LegacyAuthAttempts.Count -gt 0) {
        Write-Host "`n--- 検出されたレガシー認証の試行 ---" -ForegroundColor Yellow
        $LegacyAuthAttempts | Select-Object CreationDate, UserId, ClientIP, Operations, `
            @{Name='ClientApp'; Expression={$_.AuditData | ConvertFrom-Json | Select-Object -ExpandProperty ClientApp}}, `
            @{Name='ResultStatus'; Expression={$_.AuditData | ConvertFrom-Json | Select-Object -ExpandProperty ResultStatus}} | Format-Table -AutoSize
        Write-Host "詳細な分析には、Microsoft Entra管理センターのサインインログ (Client app: Other clients) を参照してください。" -ForegroundColor Cyan
    } else {
        Write-Host "`n指定期間内にレガシー認証の試行は検出されませんでした。" -ForegroundColor Green
    }

} catch {
    Write-Host "`nエラーが発生しました: $($_.Exception.Message)" -ForegroundColor Red
    Write-Host "Exchange Online PowerShell v2モジュールが接続されているか、適切な権限があるか確認してください。" -ForegroundColor Red
}

# 計算量: Search-UnifiedAuditLog は、検索範囲と取得する結果セットの量に比例して時間を要します (O(N))。


# メモリ条件: `$AuditResults` 変数にログが格納されるため、`ResultSize` の値とログの詳細さに比例したメモリを使用します。

レガシー認証をブロックする条件付きアクセス ポリシーの設定方法: レガシー認証は、Microsoft Entra IDの条件付きアクセス ポリシーでブロックすることが最も推奨される対策です[4]。以下の手順でポリシーを設定できます。

  1. Microsoft Entra管理センターにアクセスします。

  2. [保護] > [条件付きアクセス] > [新しいポリシーの作成] を選択します。

  3. [クラウドアプリまたはアクション] で [すべてのクラウドアプリ] を選択します。

  4. [条件] > [クライアントアプリ] で [はい] を選択し、[モバイルアプリおよびデスクトップ クライアント] の[その他のクライアント] (Exchange ActiveSync クライアント、その他のクライアント) をチェックします。

  5. [アクセス制御] > [付与] で [アクセスのブロック] を選択し、ポリシーを [オン] に設定して保存します。

2. Microsoft 365 DefenderとEntra ID Protection

Microsoft 365 Defenderは、エンドポイント、ID、電子メール、アプリケーション、データを横断的に保護するXDRソリューションです[2]。Entra ID Protectionは、リスクベースのポリシー適用により、不審なサインインやユーザーの振る舞いを自動で検出・修復します[3]。

  • 異常なサインインの検出: 通常と異なる場所、デバイス、時間帯からのサインイン試行を自動で検出し、MFAの再要求やブロックを実行します。

  • MFA疲労攻撃への対応: Entra ID Protectionのリスクベースの条件付きアクセスと、MFAの強化（数値照合やFIDO2セキュリティキー）を組み合わせることで、MFA疲労攻撃の成功率を大幅に低下させます[7]。

3. 強固な認証方式の導入

パスワードレス認証 (FIDO2セキュリティキー、Windows Hello for Business) や、MFAアプリの数値照合機能の利用が推奨されます[7]。これにより、ユーザーはMFAプロンプトを誤って承認するリスクが低減します。

運用対策

1. 最小権限の原則と特権アクセス管理 (PAM)

必要最小限の権限のみを付与し、特権アカウントはJust-In-Time (JIT) アクセスやJust-Enough-Administration (JEA) の原則に基づいて管理します[5]。Microsoft 365のPAM機能やEntra ID PIM (Privileged Identity Management) を活用し、一時的な権限昇格と厳格な監査を実施します。

2. 鍵と秘匿情報の取り扱い

アプリケーション登録のシークレット（クライアントシークレット）やサービスプリンシパルの証明書は、有効期限を短く設定し、定期的なローテーションを強制します。Azure Key Vaultとの連携により、秘匿情報の安全な保管とアクセス制御を徹底します。シークレットのハードコーディングは避け、環境変数やKey Vaultから安全に取得する仕組みを導入します。

3. 監査とログ管理

Unified Audit Logの保持期間はライセンスによって異なりますが、セキュリティ要件に合わせてE5ライセンスで最大10年間保持できるよう検討します[1]。ログはMicrosoft 365 Defenderの高度なハンティングや、Microsoft SentinelのようなSIEMに連携し、長期保管と相関分析を可能にします。

4. Microsoft Secure Scoreによるセキュリティ態勢の評価

Microsoft Secure Scoreは、Microsoft 365のセキュリティ態勢を定量的に評価し、改善のための推奨事項を提供します[6]。これを定期的に確認し、優先度の高い推奨事項から順に実施することで、セキュリティレベルを継続的に向上させます。

5. インシデントレスポンス計画

Microsoft 365特有のインシデント（アカウント乗っ取り、データ漏洩、悪意のあるアプリ同意など）に対応するための具体的なインシデントレスポンス計画を策定し、定期的に訓練を実施します。特に、M365 Defenderで検出されたアラートへの対応手順を明確化します。

現場の落とし穴

  • 誤検知と検出遅延: セキュリティアラートの過多による「アラート疲れ」や、リアルタイム性が求められる脅威に対する検出遅延。調整されたアラートポリシーと、SIEM/SOAR連携による自動化が有効です。

  • ログの肥大化とノイズ: UALは大量のイベントを生成するため、必要な情報を見つけるのが困難になることがあります。効果的なフィルタリングと、Microsoft 365 Defenderの高度なハンティング（KQL）の活用が重要です。

  • ライセンス不足: 必要なセキュリティ機能（Entra ID PIM, Entra ID Protection, extended UAL retention, M365 Defender XDR）がライセンスに含まれていない場合、監視と防御にギャップが生じます。

  • 可用性とのトレードオフ: 厳しすぎる条件付きアクセス ポリシーは、正規ユーザーのアクセスを妨げ、業務に支障をきたす可能性があります。段階的な導入と影響範囲の評価が不可欠です。

まとめ

Microsoft 365のセキュリティ監視は、単一のツールや設定では完結しません。脅威モデルの理解、Microsoft 365 DefenderやEntra ID Protection、Unified Audit Logといった組み込み機能の最大限の活用、そして最小権限の原則や鍵管理といった基本的なセキュリティプラクティスの徹底が不可欠です。これらのベストプラクティスを継続的に適用することで、進化する脅威からMicrosoft 365環境を効果的に保護し、事業の継続性を確保できます。

根拠情報:

[1] Microsoft Learn. “Microsoft Purview の監査ソリューション”. 更新日: 2024年7月29日. https://learn.microsoft.com/ja-jp/microsoft-365/compliance/audit-log-search [2] Microsoft Learn. “Microsoft 365 Defender とは?”. 更新日: 2024年7月25日. https://learn.microsoft.com/ja-jp/microsoft-365/security/defender/microsoft-365-defender [3] Microsoft Learn. “Microsoft Entra ID Protection とは?”. 更新日: 2024年7月18日. https://learn.microsoft.com/ja-jp/entra/identity-platform/identity-protection-overview-about [4] Microsoft Learn. “Microsoft Entra 条件付きアクセスとは?”. 更新日: 2024年7月15日. https://learn.microsoft.com/ja-jp/entra/identity/conditional-access/overview [5] Microsoft Learn. “特権アクセス管理の概要”. 更新日: 2024年6月20日. https://learn.microsoft.com/ja-jp/microsoft-365/compliance/privileged-access-management-overview [6] Microsoft Learn. “Microsoft Secure Score とは?”. 更新日: 2024年7月10日. https://learn.microsoft.com/ja-jp/microsoft-365/security/defender/microsoft-secure-score [7] Microsoft Learn. “Microsoft Entra ID の認証方法”. 更新日: 2024年7月22日. https://learn.microsoft.com/ja-jp/azure/active-directory/authentication/concept-authentication-methods

ライセンス：本記事のテキスト/コードは特記なき限り CC BY 4.0 です。引用の際は出典URL（本ページ）を明記してください。
利用ポリシー もご参照ください。

コメント

タイトルとURLをコピーしました