Um besonders schützenswerte Daten zusätzlich zu verschlüsseln, habe ich in unserer Organisation den Double Key Encryption (DKE)-Service in Microsoft 365 eingeführt. Dies stellt sicher, dass sensible Informationen selbst innerhalb von Microsoft 365 von nicht befugten Personen weder gelesen noch über Funktionen wie die Content Search ausgelesen werden können. In vielen Branchen steigen die Anforderungen an Datenschutz und Datensicherheit – gerade hochregulierte Sektoren wie Finanzen oder Gesundheitswesen legen verstärkt Fokus auf den Schutz sensibler Informationen
Double Key Encryption (DKE) ist eine von Microsoft bereitgestellte Technologie, die genau hierfür entwickelt wurde. Sie erlaubt es Organisationen, hochgeheime Daten zusätzlich abzusichern, indem zwei unabhängige Schlüssel zum Einsatz kommen. Double Key Encryption bedeutet, dass Inhalte mit zwei verschiedenen Schlüsseln verschlüsselt werden. Einen Schlüssel hält das Unternehmen selbst (on-premises oder in eigenem Cloud-Tenant), der zweite wird in Microsoft Azure gespeichert. Nur wenn beide Schlüssel präsent sind, kann der geschützte Inhalt entschlüsselt und angezeigt werden Dadurch behält die Organisation die volle Kontrolle über den Zugriff auf ihre Daten: Da Microsoft nur einen der beiden Schlüssel besitzt, bleibt der Inhalt für Microsoft (oder Dritte) unlesbar, solange der kundeneigene Schlüssel nicht bereitgestellt wird
In einem zukünftigen Beitrag werde ich detailliert erläutern, wie ich DKE implementiert habe. Bleiben Sie also gespannt!
Die Herausforderung
Die Nutzung von DKE bringt allerdings eine besondere Herausforderung mit sich: Automatisches Labeling in SharePoint funktioniert nicht mit DKE-geschützten Labels. Das bedeutet, dass Dateien vor der Migration manuell oder alternativ über andere Methoden gelabelt werden müssen, um sicherzustellen, dass keine Informationen aus den Dateien von Microsoft 365 gelesen werden können.
Mögliche Lösungsansätze
Es gibt mehrere Optionen, um Dateien mit den erforderlichen Labels zu versehen:
- Manuelles Labeln über den Purview Label Client
- Verwendung des Azure Information Protection (AIP) Scanners
- Labeln von Dateien mittels PowerShell
Ich habe mich intensiv mit diesen Methoden auseinandergesetzt und möchte meine Erfahrungen teilen.
1. Manuelles Labeln
Das manuelle Labeln beinhaltet das Auswählen einzelner Dateien oder Ordner im Datei-Explorer, um sie mit dem entsprechenden Label zu versehen.
- Problematik: Bei auftretenden Fehlern gibt es nur eingeschränkte Protokollierungsmöglichkeiten. Die Dateien müssen einzeln überprüft und bearbeitet werden, was bei größeren Datenmengen sehr zeitaufwendig und für Migrationsprojekte ungeeignet ist.
2. AIP Scanner
Der Azure Information Protection Scanner ist ein Tool, das in der lokalen Infrastruktur installiert wird. Es kann mithilfe von Richtlinien automatisch Dateien auf File Shares oder SharePoint On-Premises labeln.
- Vorteile: Ideal für größere Umgebungen oder wenn man die Label-Funktionalität von Purview auch in der On-Premises-Umgebung nutzen möchte.
- Nachteil: In meinem Fall, mit nur einem kleinen lokalen Laufwerk für die Migration, wäre der Implementierungsaufwand zu hoch.
3. Labeln von Dateien mit PowerShell
Aus diesem Grund habe ich mich für das Labeln von Dateien mittels PowerShell entschieden.
Voraussetzungen:
- Ein Client mit PowerShell und installiertem Purview Label Client.
- Eine App-Registrierung in Entra ID (ehemals Azure Active Directory).
Limitierungen:
- MSG-Dateien (Outlook-Nachrichten) können nicht über PowerShell gelabelt werden.
- PDF-Dateien, die passwortgeschützt sind oder mit einem Zertifikat signiert wurden, können nicht gelabelt werden (Limitation des Labels, nicht von PowerShell).
Die Herausforderung mit Standard-PowerShell-Befehlen
Beim Versuch, die PowerShell-Befehle gemäß der Microsoft-Dokumentation auszuführen, stellte ich fest, dass sich PowerShell aufhängt und der Prozess endlos läuft. Der verwendete Befehl war:
Get-FileStatus -Path \\Finance\Projects\ | Where-Object {$_.IsLabeled -eq $False} | Set-FileLabel -LabelId d9f23ae3-4321-4321-4321-f515f824c57b
Microsoft empfiehlt in der Dokumentation, bei Schleifen zusätzlich die folgenden Zeilen einzufügen:
[GC]::Collect()
[GC]::WaitForPendingFinalizers()
Quelle: Microsoft Purview Information Protection PowerShell Module
Leider löste diese Anpassung mein Problem nicht.
Meine Lösung mit PowerShell
Nach einigen Experimenten entwickelte ich ein Skript, das das Labeln der Dateien zuverlässig durchführt. Hier ist mein Ansatz:
Get-ChildItem -Path \\Finance\Projects\ -Recurse -File | ForEach-Object {
try {
# Versuch, das Label mit einem Retry-Mechanismus zu setzen
$maxRetries = 3
$retryCount = 0
$setSuccess = $false
while (-not $setSuccess -and $retryCount -lt $maxRetries) {
$retryCount++
$jobsetlabel = Start-Job -ScriptBlock {
param ($fileName, $DKELabelId)
Set-FileLabel -FileName $fileName -LabelId $DKELabelId
[GC]::Collect()
[GC]::WaitForPendingFinalizers()
return $true
} -ArgumentList $_.FullName, "d9f23ae3-4321-4321-4321-f515f824c57b"
$finishedsetlabel = $jobsetlabel | Wait-Job -Timeout 10 | Receive-Job
if ($finishedsetlabel) {
$setSuccess = $true
if ($finishedsetlabel.Status -eq "Skipped") {
Write-Host "Datei $($_.FullName) wurde übersprungen: $($finishedsetlabel.Comment)" -ForegroundColor Red
}
else {
Write-Host "Label erfolgreich gesetzt für $($_.FullName) beim Versuch $retryCount." -ForegroundColor Green
}
}
}
}
catch {
Write-Host "Label konnte nach $maxRetries Versuchen nicht gesetzt werden für $($_.FullName)." -ForegroundColor Red
}
}
Erläuterung des Skripts:
- Retry-Mechanismus: Das Skript versucht bis zu drei Mal, das Label auf eine Datei anzuwenden, falls Fehler auftreten.
- Verwendung von
Start-Job
: Jeder Labeling-Vorgang wird in einem separaten PowerShell-Job ausgeführt, um Ressourcenprobleme zu vermeiden. - Speicherbereinigung: Durch
[GC]::Collect()
und[GC]::WaitForPendingFinalizers()
wird der Arbeitsspeicher nach jedem Job bereinigt. - Timeout: Mit
Wait-Job -Timeout 10
wird sichergestellt, dass ein Job nicht unendlich lange läuft.
Mit diesem Skript konnte ich erfolgreich alle relevanten Dateien labeln, ohne dass PowerShell einfriert oder unendlich lange läuft. Der Retry-Mechanismus stellte sicher, dass temporäre Probleme überwunden wurden, und die Verwendung von Jobs verhinderte Ressourcenengpässe.
Weiter habe ich für die Migration ein zusätzliches Scripts geschrieben, welche das Label auf den Files ausgelesen hat und in einem CSV Dokumentiert. Mit diesem konnten vor der Migration alle Files geprüft werden und bei Bedarf manuell angepasst.
Fazit
Das Labeln von Dateien mit DKE-geschützten Labels ist ein kritischer Schritt, um die Sicherheit sensibler Daten in Microsoft 365 zu gewährleisten. Die Verwendung von PowerShell in Kombination mit dem oben genannten Skript hat sich in meiner Umgebung als effiziente und zuverlässige Methode erwiesen.
Quellen:
Double Key Encryption (DKE) | Microsoft Learn
Set up Double Key Encryption (DKE) | Microsoft Learn
Your Azure Information Protection tenant key | Microsoft Learn
Microsoft Purview Information Protection PowerShell Module