Déployer Microsoft Purview de bout en bout (Loi 25)

Le probleme qu’on resout

Une organisation qui traite des renseignements personnels (dossiers citoyens, RH, finances, santé) doit prouver qu’elle protège ces données et qu’elle respecte la Loi 25 : responsable désigné, rétention limitée aux fins, registre des incidents et notification à l’autorité dans les 72 heures. En pratique, le constat récurrent est le même : le journal d’audit existe, le MFA est actif, des étiquettes de sensibilité sont publiées — mais aucune politique DLP n’est en place, aucune rétention n’est configurée, et les étiquettes ne sont pas adoptées.

La méthode « évidente » — acheter une licence haut de gamme pour tout le monde et activer toutes les protections d’un coup — échoue pour deux raisons. D’abord, le coût : licencier l’ensemble du parc est disproportionné quand quelques dizaines d’utilisateurs manipulent réellement les données les plus sensibles. Ensuite, le choc opérationnel : activer un blocage DLP sans calibrage génère une avalanche de faux positifs, les utilisateurs contournent la mesure et la confiance dans l’outil s’effondre. Il faut une montée en charge maîtrisée.

Comment ca marche

L’architecture repose sur trois vagues qui augmentent progressivement la couverture et le coût :

• Crawl (0-3 mois) : fondations sans nouvelle licence. On active Compliance Manager pour obtenir un score, on déploie le DLP en mode notification, les politiques de rétention de base, les alertes, et on force l’adoption des étiquettes existantes. On désigne officiellement le responsable de la protection des renseignements personnels.
• Walk (3-6 mois) : licences ciblées sur un périmètre restreint (administrateurs TI, RH, finances, services sensibles, direction). On passe le DLP en mode application, on ajoute l’étiquetage automatique côté serveur, la gestion des risques internes et la conformité des communications.
• Run (6-12 mois) : excellence et audit-ready. Protection adaptative, Endpoint DLP sur les postes, classificateurs entraînables, eDiscovery avancé.

Deux principes structurent chaque déploiement. Premièrement, la séquence test → calibrage → pilote → généralisation : on n’active jamais un blocage directement en production. Deuxièmement, le DRY-RUN systématique dans les scripts : par défaut un script ne modifie rien et affiche ce qu’il ferait ; il faut explicitement le paramètre -Execute pour appliquer. Enfin, l’étiquetage automatique côté serveur, configuré par un administrateur licencié haut de gamme, s’applique aux fichiers de tous les utilisateurs même sous licence standard — un levier économique majeur.

Prerequis

• Rôle Microsoft Entra Compliance Administrator (configuration des politiques) ou Compliance Data Administrator (plus l’accès au contenu pour investigations).
• Rôle Exchange Administrator pour activer la journalisation unifiée et les règles de transport.
• Rôle Security Reader ou Global Reader pour l’audit en lecture seule.
• Modules PowerShell : ExchangeOnlineManagement (cmdlets Connect-IPPSSession) et Microsoft.Graph pour l’inventaire.
• Une application Entra avec authentification par certificat (PFX) et les rôles applicatifs minimaux ; à défaut, authentification interactive d’un compte administrateur.
• Documents internes : calendrier de conservation documentaire approuvé, organigramme à jour, désignation du responsable de la protection, liste des sous-traitants.
• Vérifications techniques préalables : MFA généralisé, accès conditionnel actif, groupes Entra par direction synchronisés, Defender pour Endpoint et Intune fonctionnels (pour l’Endpoint DLP en vague Run).

Procedure

1. Activer la journalisation unifiée. Portail de conformité → Audit → bouton « Start recording user and admin activity ». C’est le socle de traçabilité ; les événements ne sont jamais consignés rétroactivement. Pour les comptes licenciés haut de gamme, créez une politique de rétention d’audit (jusqu’à 10 ans pour les administrateurs et le responsable de la protection).
2. Activer Compliance Manager. Ajoutez les modèles pertinents (référentiel de protection des données par défaut, cadre national de cybersécurité, normes applicables à votre juridiction) pour obtenir un score de départ et une liste d’actions d’amélioration que vous assignerez à des responsables TI.
3. Déployer le DLP en mode notification. Activez les modèles détectant les identifiants sensibles de votre juridiction (données financières, identifiants personnels, information de santé) sur Exchange, SharePoint, OneDrive et Teams. Action = notification utilisateur + rapport d’incident à l’administrateur, sans blocage.
4. Configurer les politiques de rétention de base. Éléments supprimés conservés 30 jours, courriels standards selon la durée légale, documents légaux permanents, boîtes d’utilisateurs partis supprimées après 90 jours (principe de limitation).
5. Activer les alertes de sécurité : création de règle de boîte de réception, suppression massive de fichiers, élévation de privilèges, téléchargement massif. Notifier administrateurs et responsable de la protection.
6. Forcer l’adoption des étiquettes : publication à tous les utilisateurs licenciés, étiquette par défaut « Interne », justification obligatoire si non étiqueté, formation des groupes clés.
7. Après 3 mois en notification, passer le DLP en application (mode Enable) sur un périmètre pilote, avec substitution justifiée pour les cas critiques.
8. Déployer l’étiquetage automatique et la gestion des risques internes sur le périmètre licencié ciblé.

Le script

Ce script applique l’étape fondatrice : il vérifie et active la journalisation unifiée, puis sort une liste de politiques DLP critiques du mode test pour les passer en mode application, en s’assurant que la notification utilisateur et le rapport d’incident sont activés. Par défaut il tourne en DRY-RUN et ne modifie rien ; ajoutez -Execute pour appliquer. Toutes les valeurs sont génériques.

# Phase fondations — Journal d'audit + bascule DLP en mode application
# Par defaut : DRY-RUN. Ajouter -Execute pour appliquer reellement.
# Role requis : Compliance Administrator ou Exchange Administrator.

[CmdletBinding()]
param(
    [string]$PfxPath = '.\cert-purview.pfx',         # certificat d'authentification applicative
    [string]$Org     = 'exemple.onmicrosoft.com',    # tenant generique
    [switch]$Execute,
    [string[]]$DlpToEnable = @(
        'PII-Locale',
        'Information-Sante',
        'Carte-de-credit',
        'Politique-RH-Confidentialite',
        'Politique-Info-Sante-Defaut'
    )
)
$ErrorActionPreference = 'Continue'
$ProgressPreference    = 'SilentlyContinue'

$mode = if ($Execute) { 'EXECUTE' } else { 'DRY-RUN' }
Write-Host "=== Fondations Purview — Audit + DLP ($mode) ===" -ForegroundColor Cyan

# --- Connexion (certificat + App ID via variables d'environnement) ---
# Le mot de passe du PFX est lu depuis une variable d'env, jamais en clair dans le script.
$pfxPwd = ($env:PFX_PASSWORD | ConvertTo-SecureString -AsPlainText -Force)
$cert   = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2(
              $PfxPath, $pfxPwd, 'EphemeralKeySet')
Connect-IPPSSession -AppId $env:M365_CLIENT_ID -Certificate $cert `
    -Organization $Org -ShowBanner:$false | Out-Null

# --- Etape 1 : Journal d'audit unifie ---
Write-Host "`n[1/2] Verification du journal d'audit unifie..." -ForegroundColor Cyan
$audit = Get-AdminAuditLogConfig -ErrorAction SilentlyContinue
Write-Host ("  UnifiedAuditLogIngestionEnabled actuel : " + $audit.UnifiedAuditLogIngestionEnabled)

if ($audit.UnifiedAuditLogIngestionEnabled) {
    Write-Host "  Deja active - OK" -ForegroundColor Green
}
elseif (-not $Execute) {
    Write-Host "  [DRY-RUN] Set-AdminAuditLogConfig -UnifiedAuditLogIngestionEnabled `$true" -ForegroundColor Yellow
}
else {
    try {
        Set-AdminAuditLogConfig -UnifiedAuditLogIngestionEnabled $true
        Write-Host "  Active OK" -ForegroundColor Green
    } catch {
        Write-Host ("  ECHEC : " + $_.Exception.Message) -ForegroundColor Red
    }
}

# --- Etape 2 : DLP mode TEST -> mode ENABLE ---
Write-Host "`n[2/2] Bascule des politiques DLP critiques en mode application..." -ForegroundColor Cyan
$dlps = Get-DlpCompliancePolicy -ErrorAction SilentlyContinue

foreach ($name in $DlpToEnable) {
    $d = $dlps | Where-Object { $_.Name -eq $name }
    if (-not $d) { Write-Host "  - $name : INTROUVABLE" -ForegroundColor Red; continue }

    Write-Host "`n  - $name (mode actuel : $($d.Mode))" -ForegroundColor Yellow
    if ($d.Mode -eq 'Enable') { Write-Host "    Deja en application - skip" -ForegroundColor DarkGray; continue }

    # S'assurer que chaque regle notifie l'utilisateur et genere un rapport d'incident
    $rules = Get-DlpComplianceRule -Policy $d.Name -ErrorAction SilentlyContinue
    foreach ($r in $rules) {
        $changes = @()
        if (-not $r.NotifyUser)             { $changes += 'NotifyUser=ON' }
        if (-not $r.GenerateIncidentReport) { $changes += 'IncidentReport=ON' }
        if ($changes.Count -gt 0) {
            Write-Host ("    Regle '$($r.Name)' : " + ($changes -join ', '))
            if ($Execute) {
                try {
                    Set-DlpComplianceRule -Identity $r.Identity `
                        -NotifyUser SiteAdmin,LastModifier,Owner `
                        -GenerateIncidentReport SiteAdmin,LastModifier,Owner `
                        -IncidentReportContent All -ErrorAction Stop
                    Write-Host "    Regle mise a jour" -ForegroundColor Green
                } catch { Write-Host ("    ECHEC regle : " + $_.Exception.Message) -ForegroundColor Red }
            }
        }
    }

    if (-not $Execute) {
        Write-Host "    [DRY-RUN] Set-DlpCompliancePolicy -Identity '$($d.Identity)' -Mode Enable" -ForegroundColor Yellow
    } else {
        try {
            Set-DlpCompliancePolicy -Identity $d.Identity -Mode Enable -ErrorAction Stop
            Write-Host "    Politique passee en mode application" -ForegroundColor Green
        } catch { Write-Host ("    ECHEC politique : " + $_.Exception.Message) -ForegroundColor Red }
    }
}

if (-not $Execute) { Write-Host "`n[DRY-RUN] Aucune modification. Ajouter -Execute pour appliquer." -ForegroundColor Yellow }
Disconnect-ExchangeOnline -Confirm:$false -ErrorAction SilentlyContinue | Out-Null

Pour un audit en lecture seule de l’existant via Graph (quelles capacités sont déjà configurées, quelles permissions manquent), ce complément ne modifie rien :

# Audit lecture seule des capacites Purview accessibles via Graph (beta)
$ProgressPreference = 'SilentlyContinue'
$secure = ($env:GRAPH_SECRET | ConvertTo-SecureString -AsPlainText -Force)
Connect-MgGraph -TenantId $env:M365_TENANT_ID `
    -ClientSecretCredential (New-Object PSCredential($env:M365_CLIENT_ID,$secure)) -NoWelcome | Out-Null

function Probe {
    param([string]$Label,[string]$Uri)
    try {
        $r = Invoke-MgGraphRequest -Method GET -Uri $Uri -ErrorAction Stop
        $n = if ($r.value) { $r.value.Count } else { 1 }
        [pscustomobject]@{ Domaine=$Label; Statut='OK'; Nombre=$n }
    } catch {
        $st = if ($_.Exception.Message -match '403|Forbidden') { 'PERM MANQUANTE' } else { 'ERREUR' }
        [pscustomobject]@{ Domaine=$Label; Statut=$st; Nombre=0 }
    }
}

@(
  Probe 'Etiquettes de sensibilite' 'https://graph.microsoft.com/beta/security/sensitivityLabels'
  Probe 'Etiquettes de retention'   'https://graph.microsoft.com/beta/security/labels/retentionLabels'
  Probe 'Cas eDiscovery'            'https://graph.microsoft.com/beta/security/cases/ediscoveryCases'
) | Format-Table -AutoSize
Disconnect-MgGraph | Out-Null

Validation

• Journal d’audit : Get-AdminAuditLogConfig | Select UnifiedAuditLogIngestionEnabled doit renvoyer True. Dans le portail, lancez une recherche d’audit sur une action récente (ex. suppression d’un élément de boîte) ; les résultats apparaissent sous ~30 minutes.
• DLP : Get-DlpCompliancePolicy | Select Name,Mode doit afficher Enable pour les politiques ciblées. Effectuez un test contrôlé (envoyer un courriel contenant un identifiant fictif mais au bon format) et vérifiez qu’une notification et un rapport d’incident sont générés.
• Compliance Manager : le score de base est affiché et des actions d’amélioration sont assignées.
• Rétention : Get-RetentionCompliancePolicy liste les politiques créées et leur état Enabled.

Plan de retour (rollback)

Chaque changement est réversible. Repassez une politique DLP du mode application au mode test (notification seule) :

# Revenir du mode application au mode test (aucun blocage)
Set-DlpCompliancePolicy -Identity 'PII-Locale' -Mode TestWithNotifications
# ou desactiver completement une politique :
Set-DlpCompliancePolicy -Identity 'PII-Locale' -Mode Disable

Pour la journalisation, la désactivation est possible mais fortement déconseillée (perte de traçabilité, non-conformité) : Set-AdminAuditLogConfig -UnifiedAuditLogIngestionEnabled $false. Les politiques de rétention ne suppriment rien tant qu’elles sont en test ; conservez une sauvegarde de la configuration (export CSV des politiques via Get-DlpCompliancePolicy | Export-Csv) avant toute modification de masse.

Depannage

Securite, changement et bonnes pratiques

• Secrets : jamais de mot de passe PFX ni de secret client en clair dans un script. Utilisez des variables d’environnement ou un coffre-fort ; stockez le PFX hors du dépôt de code.
• Moindre privilège : séparez les rôles lecture (audit, vérificateurs) et écriture (configuration des politiques). Réservez Compliance Data Administrator au responsable de la protection.
• DRY-RUN d’abord : exécutez toujours sans -Execute, relisez le plan affiché, puis appliquez.
• Cadrage ITIL : l’activation du journal d’audit et le DLP en mode notification relèvent du changement standard (faible risque, réversible). La bascule DLP en mode application est un changement normal : documentez-le, passez-le en revue au CAB, planifiez-le dans une fenêtre de maintenance hors pointe et communiquez aux utilisateurs pilotes. Les incidents détectés alimentent la gestion des incidents, et les récurrences la gestion des problèmes.
• Traçabilité : conservez la sortie des scripts (journal d’exécution) comme preuve de conformité et pour le registre des incidents exigé par la Loi 25.

A retenir

Le déploiement de Microsoft Purview réussit quand il est progressif, mesuré et réversible. On commence par le socle gratuit — journal d’audit, Compliance Manager, DLP en notification, rétention, adoption des étiquettes — puis on cible les licences avancées sur les utilisateurs qui manipulent réellement les données sensibles. Le DRY-RUN systématique et le rattachement explicite aux obligations de la Loi 25 transforment un projet technique en démarche de conformité défendable devant un auditeur. Commencez dès maintenant par activer la journalisation unifiée et mesurer votre score de départ : c’est l’action à coût nul qui conditionne tout le reste.