Microsoft 365 DLPポリシーの実装

Microsoft 365・Azureカテゴリを表すパンダのイラスト Microsoft 365・Azure
2026.01.16

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

Microsoft 365 DLPポリシーの実装

データ損失防止 (DLP) は、組織が機密データを誤って共有したり、意図せず漏洩させたりすることを防ぐ上で不可欠なセキュリティ対策です。Microsoft 365におけるDLPは、Microsoft Purviewコンプライアンスポータルを中心に、Microsoft 365の幅広いサービスで機密情報の検出と保護を可能にします。このガイドでは、クラウドアーキテクトの視点から、Microsoft 365 DLPポリシーの包括的な実装について解説します。

アーキテクチャ

Microsoft 365 DLPは、Microsoft Purviewの機能群の一部として提供され、組織内の様々なデータが存在する場所（Exchange Online、SharePoint Online、OneDrive for Business、Microsoft Teams、およびWindowsエンドポイント）で動作します。この統合されたアプローチにより、データがどこに移動しても一貫した保護が可能です。

DLPポリシーは、以下の主要な要素で構成されます。

  • 場所: ポリシーを適用するサービス（例: Exchangeメール、SharePointサイト、OneDriveアカウント、Teamsチャット、デバイス）。

  • 機密情報の種類: クレジットカード番号、マイナンバー、健康保険証番号などの組み込みの機密情報タイプ、またはカスタム定義した機密情報タイプ。

  • 条件: 機密情報の種類が検出された場合や、特定のキーワードが含まれる場合など、ポリシーがトリガーされる条件。

  • アクション: 条件が満たされた場合に実行される処理（例: アクセスブロック、ユーザーへの通知、管理アラートの生成）。

  • ユーザー通知とオーバーライド: ユーザーにポリシー違反を警告し、正当な理由がある場合にポリシーをオーバーライドできるオプション。

DLPポリシーの検出フロー

DLPポリシーが機密情報を検出・処理する基本的なフローは以下の通りです。

flowchart TD
    SUBGRAPH A["データソース"]
        EX["Exchange Online"]
        SP["SharePoint Online"]
        OD["OneDrive for Business"]
        TE["Microsoft Teams"]
        EP["Windows エンドポイント"]
    END

    A --|機密情報を含むコンテンツ| B["Microsoft Purview"]

    B --|DLPポリシーの評価| C{"ポリシー違反を検出？"}

    C --|はい| D["アクションの実行"]
    D --|ブロックまたは制限| D1["アクセスブロック/共有制限"]
    D --|ユーザーへ警告| D2["ポリシーヒント/メール通知"]
    D --|管理者に通知| D3["アラート生成"]
    D --|監査ログに記録| D4["DLPイベントログ"]

    C --|いいえ| E["コンテンツを許可"]

    D4 --|監視・レポート| F["DLPアラート/レポート"]

  • A[データソース]: 機密情報が保存または転送される場所。

  • B[Microsoft Purview]: DLPポリシーが定義・管理され、データソースから流れるコンテンツを検査する中核サービス。

  • C{ポリシー違反を検出？}: 定義された機密情報タイプと条件に基づいてコンテンツを評価します。

  • D[アクションの実行]: ポリシー違反が検出された場合、定義されたアクションが実行されます。

  • D1[アクセスブロック/共有制限]: 違反コンテンツへのアクセスをブロックしたり、外部共有を制限したりします。

  • D2[ポリシーヒント/メール通知]: ユーザーにポリシー違反の可能性があることを通知し、場合によってはオーバーライドを許可します。

  • D3[アラート生成]: 管理者向けにアラートが生成され、監視システムに通知されます。

  • D4[DLPイベントログ]: 全てのDLPイベントが監査ログに記録されます。

  • E[コンテンツを許可]: ポリシー違反がない場合、コンテンツの処理は通常通り続行されます。

  • F[DLPアラート/レポート]: 生成されたアラートとログは、Microsoft Purviewコンプライアンスポータルで集約・可視化され、運用監視に利用されます。

設定手順

DLPポリシーの設定は、Microsoft Purviewコンプライアンスポータル（compliance.microsoft.com）からGUIで行うのが一般的ですが、大規模な展開やIaC (Infrastructure as Code) を実現するためにはPowerShellまたはMicrosoft Graph APIを利用することも可能です。

1. 必要なロールの割り当て

DLPポリシーを作成・管理するためには、適切な権限が必要です。Microsoft Entra ID (旧 Azure AD) のユーザーに、Microsoft PurviewコンプライアンスポータルでDLPポリシーを管理する役割グループを割り当てます。 必要な役割グループの例:

  • コンプライアンス管理者: DLPを含むほぼ全てのコンプライアンス機能の管理権限。

  • DLPコンプライアンス管理: DLPポリシー、DLPアラート、DLPレポートの管理に特化した権限。

  • 情報保護アナリスト: DLPレポートの表示、DLPアラートの管理。

# PowerShellで役割グループにユーザーを追加する例


# 最初にConnect-IPPSSessionでSecurity & Compliance Center PowerShellに接続します。


# 接続手順: https://learn.microsoft.com/ja-jp/powershell/exchange/connect-to-scc-powershell?view=exchange-ps

# 現在のJST: 2024年6月1日

# 役割グループ 'DLP Compliance Management' にユーザー 'user@contoso.com' を追加


# この操作は、Connect-IPPSSessionで接続後に実行します。

Add-RoleGroupMember -Identity "DLP Compliance Management" -Member "user@contoso.com"
Write-Host "ユーザー user@contoso.com を 'DLP Compliance Management' 役割グループに追加しました。"

このPowerShellコマンドレットは、Security & Compliance PowerShell モジュールが接続されている環境で実行する必要があります[5]。

2. 機密情報の種類の定義

組み込みの機密情報タイプを利用するか、ビジネス要件に合わせてカスタムの機密情報タイプを定義します。カスタムタイプは、キーワード辞書、正規表現、関数（検出されるインスタンス数など）の組み合わせで作成できます。

3. DLPポリシーの作成（PowerShell例）

Microsoft Purview コンプライアンスポータルでウィザードに従ってポリシーを作成することもできますが、ここではPowerShellを使って基本的なDLPポリシーを作成する例を示します。

このポリシーは、”テストサイト”という名前のSharePointサイトで日本のマイナンバー（個人番号）が検出された場合にアクセスをブロックし、管理者に通知するものです。

# 現在のJST: 2024年6月1日

# ① 機密情報タイプを取得（またはカスタムタイプを作成）


# 日本のマイナンバー（個人番号）の組み込みIDを取得

$SensitiveInfoType = Get-DlpComplianceRuleTemplate | Where-Object {$_.DisplayName -like "*Japan National ID Number*"} | Select-Object -ExpandProperty Name
if (-not $SensitiveInfoType) {
    Write-Error "日本のマイナンバーの機密情報タイプが見つかりません。組み込みタイプ名を確認してください。"
    exit
}

# ② DLPポリシーを作成


# ポリシー名: MyNumber Protection Policy


# 場所: SharePointサイト (特定のURLを指定)


# 条件: 上記の機密情報タイプが検出された場合


# アクション: ユーザーへのアクセスをブロック、管理者に通知

New-DlpCompliancePolicy -Name "MyNumber Protection Policy" `
    -ExchangeLocation "All" ` # Exchange Onlineにも適用（必要に応じて変更）
    -SharePointLocation "All" ` # SharePoint Online全体に適用
    -OneDriveLocation "All" ` # OneDrive for Business全体に適用
    -TargetLocations @("SharePointSites","ExchangeMailboxes","OneDriveAccounts") ` # 適用対象
    -Comment "日本のマイナンバーを保護するためのポリシー" `
    -Mode "Test" # 最初はテストモードで作成し、影響を確認する

Write-Host "DLPポリシー 'MyNumber Protection Policy' をテストモードで作成しました。"

# ③ DLPコンプライアンスルールを作成


# このルールは、先ほど作成したDLPポリシーに関連付けられます。

New-DlpComplianceRule -Name "Block MyNumber on SharePoint" `
    -Policy "MyNumber Protection Policy" `
    -ContentContainsSensitiveInformation @(@{Name=$SensitiveInfoType; MinCount=1}) `
    -Locations @("SharePointSites") ` # 特定のSharePointサイトに限定する場合はここにURLを記述する例
    #-SharePointLocation "https://contoso.sharepoint.com/sites/TestSite" ` # 特定サイトへの適用例

    -BlockAccess $true ` # アクセスをブロック
    -BlockAccessExempt $null ` # 例外なし
    -GenerateIncidentReport @{Alert=1; Severity='High'; NotifyEmail='admin@contoso.com'} ` # 管理者へアラートメール
    -Disabled $false `
    -Comments "SharePointサイトでのマイナンバーの共有をブロックし、管理者に通知"

Write-Host "DLPコンプライアンスルール 'Block MyNumber on SharePoint' を作成しました。"
Write-Host "ポリシーは現在テストモードです。運用前に効果を監視してください。"

# ポリシーを有効にするには、Modeを "Enforce" に変更します。


# Set-DlpCompliancePolicy -Identity "MyNumber Protection Policy" -Mode "Enforce"

上記のコードは、Microsoft Security & Compliance PowerShellモジュールに接続されていることを前提としています。New-DlpCompliancePolicy および New-DlpComplianceRule コマンドレットは、DLPポリシーとルールを定義するために使用されます[3]。最初はTestモードでポリシーを作成し、効果を確認することが強く推奨されます。

運用監視

DLPポリシーの運用には、検出されたイベントの監視と、レポートによる分析が不可欠です。

  • DLPアラート: Microsoft Purviewコンプライアンスポータルの「アラート」セクションで、DLPポリシーによってトリガーされたインシデントを確認できます。

  • DLPレポート: 「レポート」セクションでは、DLPポリシーの一致、アクション、およびユーザーオーバーライドに関する集計データがグラフと表で表示されます。これにより、組織全体のDLPの状態を把握し、ポリシーの有効性を評価できます[6]。

  • Microsoft 365監査ログ: すべてのDLPイベント（ポリシーの一致、ユーザーのオーバーライド、管理者のアクションなど）は、統合監査ログに記録されます。Microsoft Purviewコンプライアンスポータルから監査ログを検索し、詳細な情報を取得できます[6]。

  • SIEM連携: Microsoft SentinelなどのSIEM (Security Information and Event Management) ソリューションと連携することで、DLPアラートを他のセキュリティイベントと統合し、より高度な脅威検出とインシデント対応を実現できます。

  • SLA/バックアップ/DR: Microsoft 365 DLP機能自体に個別のSLAは提供されていませんが、基盤となるMicrosoft 365サービス全体のSLA (通常は99.9%の稼働率) に準拠します。DLPポリシー設定自体はMicrosoft 365の管理データとして冗長化されており、バックアップやディザスタリカバリ (DR) を意識する必要はありません。

セキュリティ

DLPの実装において、アイデンティティと権限境界、および他のセキュリティサービスとの連携は極めて重要です。

  • Microsoft Entra ID (旧 Azure AD): すべてのDLP関連のアクセスはEntra IDを通じて認証・認可されます。前述の通り、DLP管理者はEntra IDのユーザー/グループに適切なMicrosoft Purviewの役割を割り当てることで制御されます。

  • 条件付きアクセス (CA): Microsoft Purviewコンプライアンスポータルへのアクセスに条件付きアクセスポリシーを適用することで、多要素認証の強制、信頼できるデバイスからのアクセス制限、特定IP範囲からのアクセス制限など、DLP管理機能へのセキュリティを強化できます。

  • Microsoft Defender for Cloud Apps (MDCA): Microsoft Defender for Cloud Apps (旧 Microsoft Cloud App Security) は、Microsoft 365以外のSaaSアプリケーション（例: Dropbox, Google Drive, Salesforce）へのDLPを拡張します。シャドウITの検出や、これらのクラウドアプリにおける機密情報の共有を監視・制御できます[7]。

  • Microsoft Defender for Endpoint (MDE): エンドポイントDLPは、Windowsデバイス上の機密情報が、USBデバイス、ネットワーク共有、プリンター、またはクラウド同期サービス（OneDrive同期クライアントなど）を通じて共有されるのを防ぎます。MDEと連携することで、エンドポイントレベルでのDLPを統合的に管理できます。

コスト

Microsoft 365 DLP機能の利用コストは、主にMicrosoft 365のライセンスプランに含まれています。DLPの基本的な機能は多くのEnterpriseライセンス（E3以上）で利用可能ですが、より高度なDLP機能（エンドポイントDLP、Microsoft Defender for Cloud Appsとの統合によるサードパーティアプリDLP、高度な機密情報タイプなど）を利用するには、上位のライセンスまたはアドオンが必要になります[4]。

主なライセンス要件

  • Microsoft 365 E5 Compliance: 全てのDLP機能を含む最も包括的なライセンス。

  • Microsoft 365 E5: 一般的なDLP機能とMicrosoft Defender for Cloud Appsの一部機能を含む。

  • Office 365 E3 または Microsoft 365 E3 + Microsoft 365 E5 Compliance add-on: E3ライセンスでは基本的なDLPが利用できますが、エンドポイントDLPや高度なMDCA連携にはE5 Complianceアドオンが必要です。

コスト最適化

  • 適切なライセンスの選択: 組織が必要とするDLP機能の範囲を正確に評価し、過剰なライセンスを購入しないようにします。例えば、エンドポイントDLPが不要であれば、E5 Complianceアドオンを必ずしも必要としない場合があります。

  • ポリシーの最適化: 不要なDLPポリシーや、検出範囲が広すぎるポリシーは、パフォーマンスへの影響やFalse Positiveの増加につながる可能性があります。真に保護すべきデータと範囲に焦点を当て、ポリシーを最適化します。

  • 段階的な導入: まずは最小限のポリシーで開始し、監視を通じて効果と影響を評価しながら徐々に適用範囲を拡大することで、運用コスト（管理工数）を抑えられます。

落とし穴

DLPポリシーの実装にはいくつかの一般的な落とし穴があり、注意が必要です。

  • 過剰なポリシーまたは不適切なポリシー設定:

    • False Positive (誤検知): 過度に厳格な、または不正確な機密情報タイプ定義は、正規の業務プロセスを阻害し、ユーザーの生産性を低下させる可能性があります。

    • 広すぎるスコープ: すべてのユーザー、すべてのデータに一律にポリシーを適用すると、管理が複雑になり、業務への影響が大きくなります。

  • ユーザー教育の不足:

    • DLPポリシーの目的と、それがユーザーの業務に与える影響について、適切な教育が行われていないと、ユーザーはポリシーを回避しようとしたり、システムへの不満を抱いたりする可能性があります。

    • ポリシーヒントやユーザーオーバーライドの活用方法を周知することが重要です。

  • シャドードキュメント・シャドーITへの対応不足:

    • Microsoft 365外のクラウドストレージや承認されていないアプリケーションに機密情報が保存される「シャドードキュメント」や「シャドーIT」は、Microsoft 365 DLPの直接的な監視範囲外となるため、MDCAなどの連携ソリューションによる対策が必要です。

  • テストと段階的導入の欠如:

    • ポリシーを本番環境に直接適用すると、予期せぬ業務停止を引き起こす可能性があります。必ずテストモードで開始し、影響を評価した上で、段階的に適用範囲を広げるべきです[2]。

  • 監視体制の不備:

    • ポリシーを導入しても、DLPアラートやレポートを定期的に監視し、必要に応じてポリシーを調整する運用体制がなければ、実効性は得られません。

まとめ

Microsoft 365 DLPポリシーの実装は、組織の機密データを保護するための重要なステップです。Microsoft Purviewを中心とした包括的なアーキテクチャにより、メール、ドキュメント、チャット、エンドポイントといった多岐にわたる場所でデータ損失を防止できます。

効果的なDLP実装のためには、Microsoft Entra IDによる適切な権限管理、条件付きアクセスによる管理アクセス強化、そしてMicrosoft Defender for Cloud AppsやDefender for Endpointとの連携による多層防御が不可欠です。また、ライセンス要件を理解し、コストを最適化しつつ、False Positiveを避けるための慎重なポリシー設計と、ユーザーへの十分な教育が成功の鍵となります。導入の際は、必ずテストモードから開始し、段階的に適用範囲を拡大していくアプローチを推奨します。これらの要素を組み合わせることで、強固なデータ保護体制を確立できるでしょう。

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

コメント

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