M365 Purview DLPポリシーの実装と運用

Tech

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

M365 Purview DLPポリシーの実装と運用

Microsoft Purview データ損失防止（DLP）は、組織の機密情報が意図せず、または悪意を持って共有されないように保護するソリューションです。クラウド、オンプレミス、エンドポイントにわたるさまざまな場所でデータを監視し、ポリシーに違反する活動を検出して防止します。

アーキテクチャ

M365 Purview DLPのアーキテクチャは、Microsoft 365エコシステム全体に統合されており、データがどこに存在しても保護を適用できるように設計されています。主要なコンポーネントは以下の通りです。

  • データソース: Exchange Online、SharePoint Online、OneDrive for Business、Microsoft Teams、Windowsエンドポイントデバイス、Microsoft Defender for Cloud Apps（MCAS）が統合されたサードパーティクラウドアプリなど、広範なデータ保存場所と転送経路が対象です[1]。

  • 機密情報タイプ（SITs）: クレジットカード番号、社会保障番号、パスポート番号など、事前に定義された100以上のSITs、またはカスタムSITsを使用して、機密データを識別します[1]。

  • 機密度ラベル: Microsoft Information Protection（MIP）の機密度ラベルと連携し、ラベル付けされたコンテンツに対してDLPポリシーを適用できます。これにより、データの分類と保護が統合されます。

  • DLPポリシー: どの機密情報タイプを、どの場所で、どのような条件（例：外部共有、特定のキーワード）で検出した場合に、どのようなアクション（例：ブロック、警告、監査）を実行するかを定義します。

  • ルールとアクション: 各DLPポリシーは複数のルールで構成され、各ルールには特定の条件（例：特定のSITがN個以上含まれる）と、その条件が満たされた場合に実行されるアクション（例：ユーザーへの通知、コンテンツのブロック、インシデントレポートの生成）が含まれます[3]。

  • DLPアラートとインシデント管理: ポリシーに違反するイベントが発生すると、アラートが生成され、Purviewコンプライアンスポータルでインシデントとして管理されます。これにより、セキュリティチームは違反を調査し、対応できます。

以下は、一般的なDLPポリシーの適用フローを示すMermaidフローチャートです。

flowchart TD
    A["ユーザーがコンテンツを作成/編集/共有"] --> |データソース（Exchange/SharePoint/OneDrive/Teams/Endpointなど）| B("DLPポリシーエンジン")
    B --> |コンテンツをスキャンし機密情報を検出| C{"機密情報タイプの検出?"}
    C -- はい --> D{"機密度ラベルの有無?"}
    D -- はい --> E("DLPポリシー条件評価：ラベル有無/共有先など")
    D -- いいえ --> F("DLPポリシー条件評価：SIT/キーワード/ファイル種別など")
    E --> G{"DLPポリシーに違反?"}
    F --> G
    G -- はい --> H("ポリシー違反アクションを実行")
    H --> I["コンテンツブロック/ユーザー通知/監査/暗号化など"]
    H --> J["DLPアラート生成/インシデントレポート作成"]
    J --> K["セキュリティ管理者による監視と対応"]
    G -- いいえ --> L["処理を続行/コンテンツのアクセス許可"]

設定手順

DLPポリシーの設定は、Microsoft Purviewコンプライアンスポータルで行います。以下にPowerShellを利用したポリシー作成の概念的な手順を示します。

  1. 計画: 保護対象のデータ、検出する機密情報タイプ、ポリシーを適用する場所、およびポリシー違反時のアクションを特定します。誤検知を避けるため、慎重な計画が重要です[2]。

  2. 機密情報タイプ（SITs）の定義: 既存のSITsを利用するか、組織固有の情報を識別するためのカスタムSITsを正規表現、キーワード辞書、または関数で作成します。

  3. DLPポリシーの作成:

    • 場所の選択: Exchangeメール、SharePointサイト、OneDriveアカウント、Teamsチャットとチャンネル、Windowsエンドポイントデバイスなど、ポリシーを適用する場所を選択します。

    • ルールの構成:

      • 条件: 「コンテンツに特定の種類の機密情報が含まれる」、「機密度ラベルが適用されている」、「コンテンツが外部ユーザーと共有されている」などの条件を設定します。

      • アクション: 「コンテンツへのアクセスをブロックする」、「ユーザーに通知する」、「監査のみ行う」などのアクションを定義します。

    • ユーザー通知とポリシーヒント: ユーザーがポリシー違反に気づくように、メール通知やアプリケーション内ポリシーヒントを設定します。

    • インシデントレポート: インシデントアラートを生成し、特定のユーザーまたはグループに通知するように設定します。

    • テストモードでの展開: 最初はポリシーを「監査のみ」モードで展開し、誤検知がないか、期待通りの動作をするかを確認します。

PowerShellを使用してDLPポリシーを作成する際の例（概念的なスニペット）。実際には、より複雑な条件やアクションを設定できます。

# Microsoft 365 Security & Compliance Center PowerShellモジュールをインストール


# Install-Module -Name ExchangeOnlineManagement -Force


# Import-Module ExchangeOnlineManagement


# Connect-IPPSSession -UserPrincipalName admin@yourdomain.com

# 機密情報タイプを取得 (例: クレジットカード番号)

$sit = Get-DlpSensitiveInformationType | Where-Object {$_.Name -eq "Credit Card Number"}

# 新しいDLPポリシーを作成


# この例では、Exchange Onlineでクレジットカード番号が検出された場合にメールをブロックし、管理者に通知するポリシーを作成

New-DlpComplianceRule -Name "Block Credit Card Number in Exchange" `
    -Policy "組織全体の機密データポリシー" ` # 既存のポリシー名を指定、またはNew-DlpCompliancePolicyで新規作成
    -Comment "クレジットカード番号を含むメールの外部送信をブロック" `
    -ContentContainsSensitiveInformation @(@{Name=$($sit.Name); mincount=1; maxcount=999}) ` # 少なくとも1つのクレジットカード番号を検出
    -ExceptIfContentContainsSensitiveInformation @(@{Name="Microsoft confidential info"; mincount=1}) ` # オプション: 例外設定
    -SentToScope "NotInOrganization" ` # 組織外への送信を対象
    -BlockAccess ` # コンテンツへのアクセスをブロック
    -BlockAccessExternal ` # 外部ユーザーからのアクセスもブロック
    -GenerateIncidentReport ` # インシデントレポートを生成
    -IncidentReportMailbox "dlp-alert@yourdomain.com" ` # インシデントレポートの送信先
    -NotifyUser "PolicyTip" ` # ユーザーにポリシーヒントを表示
    -NotifyPolicyTip ` # 通知メッセージにポリシーヒントを含める
    -NotifyPolicyTipCustomText "外部にクレジットカード情報を共有することはできません。" ` # カスタム通知メッセージ
    -Mode "Enable" # テストモードの場合は "Audit"

  • 前提条件: Microsoft 365のグローバル管理者またはコンプライアンス管理者ロールを持つアカウントで実行します。Exchange Online Managementモジュール (V2) および Security & Compliance Center PowerShellモジュールがインストールされている必要があります。

  • 入出力: PowerShellコマンドレットを通じてDLPポリシーオブジェクトが作成され、Microsoft Purviewコンプライアンスセンターに反映されます。

  • 計算量: 数百のDLPルールや数万のユーザー規模であっても、通常数秒から数分で処理が完了します。大規模な一括操作の場合、APIレート制限に注意が必要です。

  • メモリ条件: PowerShellセッション自体が消費するメモリは通常数十MB程度ですが、大規模なオブジェクト操作やスクリプト実行ではそれ以上になる場合があります。

運用監視

DLPポリシーの導入後も継続的な運用監視が必要です。

  • DLPアラートとインシデント管理: Purviewコンプライアンスポータルの「DLP」→「アラート」で、ポリシーに違反したイベントを確認します。アラートの詳細をドリルダウンし、関連するインシデントレポートやユーザーアクティビティログを調査します。

  • レポートとメトリック: DLPダッシュボードやDLPレポートを活用して、ポリシーの一致状況、誤検知の傾向、ユーザーの行動パターンなどを分析します。これにより、ポリシーのチューニングやユーザー教育の必要性を特定できます。

  • ポリシーのチューニング: 誤検知（False Positive）が多い場合は、SITsの定義を調整したり、ルールの条件を緩和したりします。検知漏れ（False Negative）がある場合は、SITsやルールの条件を強化します。

  • ユーザーフィードバック: ユーザーからのポリシーヒントや通知に対するフィードバックを収集し、ポリシーの調整に活用します。

  • Microsoft Sentinelとの統合: Purview DLPのアラートをMicrosoft Sentinelに連携させることで、SIEM/SOARソリューションの一部として、他のセキュリティイベントと統合された監視と自動応答を実現できます。

  • 監査ログ: Microsoft 365監査ログを通じて、DLPポリシーに関連する管理者アクティビティやユーザーアクティビティを詳細に追跡できます。

セキュリティと権限管理

DLPの実装と運用におけるセキュリティと権限管理は非常に重要です。

  • Entra IDとの連携: Microsoft Purviewは、Microsoft Entra ID（旧Azure AD）と統合されており、ユーザーとグループのアイデンティティ管理に依存しています。

  • Purview RBAC（ロールベースのアクセス制御）:

    • DLPポリシーの作成・編集・削除には、DLP Compliance Management または Information Protection Admin ロールが必要です。

    • DLPアラートやインシデントの閲覧には、DLP Compliance Viewers ロールが適しています[4]。

    • これらのロールは、Microsoft Purviewコンプライアンスポータルで割り当てられます。

  • 最小特権の原則: DLP管理タスクを実行するために必要な最小限の権限のみをユーザーに付与します。

  • 条件付きアクセス（CA）: DLP管理者がPurviewコンプライアンスポータルにアクセスする際に、多要素認証（MFA）の強制、信頼済みデバイスからのアクセスのみ許可、特定のIP範囲からのアクセス制限など、追加のセキュリティ要件を適用できます。これにより、管理インターフェースへの不正アクセスリスクを低減します。

  • Defender for Cloud Apps（MCAS）との連携: Purview DLPは、MCASと連携して、非Microsoft製クラウドアプリ（Salesforce, Dropboxなど）における機密データの保護も可能にします。MCASのポリシーでDLPルールを参照し、クラウドアプリ内のデータフローを監視・制御できます。

コスト最適化

M365 Purview DLPの主要な機能は、特定のMicrosoft 365ライセンスに含まれています。

  • ライセンス要件: DLP機能の大部分は、Microsoft 365 E5、Microsoft 365 A5、Microsoft 365 G5、またはMicrosoft 365 E5 Compliance アドオンライセンスに含まれています[5]。

    • Microsoft 365 E3 などの下位ライセンスでは、基本的なDLP機能は利用できますが、エンドポイントDLP、Microsoft Teams DLP、MCASとの統合DLP、自動分類、高度なSITsなどの高度な機能にはE5相当のライセンスが必要です。

  • コスト最適化の考え方:

    • DLP機能自体に追加の従量課金はほとんどなく、ライセンス費用が主なコストとなります。

    • 高度なDLP機能が必要な場合は、適切なE5系のライセンスまたはアドオンを選択することが、機能とコストのバランスを取る上で重要です。

    • DLP機能を活用することで、情報漏洩による罰金や企業の信用失墜といった潜在的な巨大なコストを回避できます。これは、DLPライセンス費用を正当化する強力な要因です。

実装と運用の落とし穴

DLPポリシーの実装と運用には、いくつかの一般的な落とし穴があります。

  • 誤検知（False Positive）: 過度に厳格なポリシーや不正確なSITs定義は、正規の業務プロセスを阻害し、ユーザーの生産性を低下させます。これがDLPに対する不満につながり、形骸化を招く可能性があります。

  • 過剰なスコープ: 最初からすべてのデータ、すべての場所、すべてのユーザーに厳格なDLPを適用しようとすると、管理が複雑になり、上記のような誤検知が増加するリスクがあります。段階的な導入が推奨されます。

  • ユーザー教育の不足: ユーザーがDLPポリシーの目的や、なぜ特定の操作がブロックされるのかを理解していないと、不満を抱いたり、回避策を探したりする可能性があります。ポリシーヒントや定期的なトレーニングが不可欠です。

  • テストの不足: ポリシーを本番環境に展開する前に、必ず「監査のみ」モードで十分なテストを行い、影響を評価することが重要です。

  • インシデント対応計画の欠如: ポリシー違反が発生した際の、アラートのトリアージ、調査、是正措置、報告プロセスの明確な計画がないと、迅速な対応ができません。

  • ポリシーの放置: 組織のデータ、規制、脅威環境は常に変化するため、DLPポリシーも定期的に見直し、更新する必要があります。

  • 管理者権限の不適切な管理: DLPポリシーを管理できるユーザーの権限が適切に制御されていない場合、ポリシーの無効化や機密情報の意図的な漏洩のリスクが高まります。

まとめ

M365 Purview DLPは、現代の複雑なデータ環境において不可欠な情報保護ツールです。アーキテクチャを理解し、計画的な設定、継続的な運用監視、厳格なセキュリティ管理、そしてコスト効率の良いライセンス選択を行うことで、組織の機密データを効果的に保護できます。特に、誤検知を最小限に抑え、ユーザーの生産性を維持するための慎重なポリシー設計と、ユーザーへの継続的な教育が成功の鍵となります。段階的な導入と定期的なポリシー見直しを通じて、DLP戦略を成熟させていくことが重要です。

[1] Microsoft. “Learn about data loss prevention.” https://learn.microsoft.com/en-us/microsoft-365/compliance/dlp-learn-about-dlp (参照日: 2024年5月10日) [2] Microsoft. “Get started with Data Loss Prevention.” https://learn.microsoft.com/en-us/microsoft-365/compliance/get-started-dlp (参照日: 2024年5月10日) [3] Microsoft. “Data Loss Prevention policy reference.” https://learn.microsoft.com/en-us/microsoft-365/compliance/dlp-policy-reference (参照日: 2024年5月9日) [4] Microsoft. “Permissions in the Microsoft Purview compliance portal.” https://learn.microsoft.com/en-us/microsoft-365/compliance/permissions-microsoft-365-compliance-center (参照日: 2024年5月1日) [5] Microsoft. “Data Loss Prevention licensing requirements.” https://learn.microsoft.com/en-us/microsoft-365/compliance/dlp-licensing-requirements (参照日: 2024年4月25日)

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

コメント

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