Microsoft 365 Double Key Encryption: Complete Setup Guide
15. Jan. 2026
ArtikelDeploy Microsoft 365 Double Key Encryption step-by-step. Control your encryption keys and achieve data sovereignty in M365 with this technical guide.
Artikel lesen
Sechs praktische Kriterien für die Wahl eines Microsoft 365 Double Key Encryption (DKE)-Anbieters: Rotation mit Kontinuität, Graph-Provisioning, Multi-Tenant-B2B, ABAC, Key Custody und Betrieb.
Microsoft 365 Double Key Encryption (DKE) liefert nur dann unabhängige Kontrolle, wenn der Second-Key-Anbieter Schlüssel so betreiben kann, wie ein Security-Team Produktion wirklich führt: rotieren ohne Labels zu brechen, sauber in Azure provisionieren, Partner-Tenants unterstützen und durchsetzen, wer unter welchem Kontext unwrappen darf.
Nutzen Sie diese sechs Kriterien, wenn Sie einen DKE-Key-Anbieter shortlisten. Es sind Capability-Tests, keine Vendor-Rangliste. Bitten Sie jeden Kandidaten, sie in einem Pilot zu demonstrieren.
Fragen Sie: Wenn wir einen DKE-Key rotieren, öffnen Nutzer geschützte Inhalte weiter, ohne ein neues Purview-Label-Rollout oder ein Change-Management-Programm?
Warum das zählt. Rotation, die neue Labels, Reklassifizierung oder ein Wochenende gebrochener Dokumente erzwingt, wird aufgeschoben. Aufgeschobene Rotation ist Residualrisiko.
Was gut aussieht. Ein konfigurierbares Cache-Fenster, damit der vorherige Key während der Rotation weiter Decrypt-Operationen bedient. Kontinuität ist Produktverhalten, keine Runbook-Entschuldigung.
Fragen Sie: Werden Azure App Registration und DKE-Endpoint-Verdrahtung über Microsoft Graph provisioniert, oder ist es eine manuelle Portal-Checkliste?
Warum das zählt. Manueller App-Registration-Drift ist, wie Pilots stecken bleiben und wie Produktion vom Diagramm abweicht.
Was gut aussieht. Automatisiertes Graph-basiertes Provisioning der Application Registration und der erforderlichen Konfiguration, wiederholbar pro Umgebung.
Fragen Sie: Können Partner-Domains und dedizierte Issuers teilnehmen, ohne alle in ein einziges Tenant-Trust-Modell zu flatten?
Warum das zählt. Reale Estates umfassen Tochtergesellschaften, Kanzleien und B2B-Guests. DKE, das nur für einen sauberen Single-Tenant funktioniert, scheitert am ersten External-Collaboration-Test.
Was gut aussieht. Support für Partner-Domains und dedizierte Issuers, damit Cross-Tenant-Collaboration unter expliziter Key-Policy bleibt.
Fragen Sie: Kann Unwrap basierend auf User, IP, Location, Zeit, Azure-Gruppen und MFA-Status verweigert oder erlaubt werden, nicht nur «Mitglied von Gruppe X»?
Warum das zählt. DKE ohne kontextuelle Zugriffskontrolle wird binär: Wer sich am Key Service authentifizieren kann, kann unwrappen. So sollen regulierte Mail und Files nicht funktionieren.
Was gut aussieht. Attribute-basierte Regeln, die bei jedem Key-Zugriff ausgewertet werden: Identität, Netzwerk, Geo, Zeit, Gruppenmitgliedschaft, MFA.
Fragen Sie: Wer kann den kundenkontrollierten Key allein rekonstruieren oder nutzen? Hält eine einzelne Partei (einschließlich DKE-Vendor oder Hyperscaler) ein vollständiges Unwrap-Secret?
Warum das zählt. DKE existiert, damit Microsoft nicht allein unwrappen kann. Der Second Key soll beim Anbieter keinen neuen Single Point of Compromise schaffen.
Was gut aussieht. Kundenkontrollierte Kontrolle mit verteilter Key-Technologie (zum Beispiel MPC), sodass kein einzelner Operator oder keine Appliance den vollständigen Key hält. Siehe MPC vs HSM.
Fragen Sie: Können wir Auditoren zeigen, wer auf Keys zugegriffen hat, wann Rotation stattfand und wie B2B-Issuers skopiert sind, ohne Tribal Knowledge vom Implementierer zu exportieren?
Warum das zählt. Souveränitätsprogramme scheitern an Audits an Evidenz, nicht an Slideware.
Was gut aussieht. Audit Trails, klare Key Ownership, dokumentierte Rotationshistorie und operative Runbooks, die dem entsprechen, was das Produkt tatsächlich tut.
Auf DuoKey for Microsoft 365 DKE sind diese Kriterien Produktfähigkeiten, keine Roadmap-Slogans:
| Kriterium | DuoKey-Verhalten |
|---|---|
| Rotation mit Kontinuität | Konfigurierbares Cache-Fenster; vorheriger Key bedient während der Rotation weiter; kein neues Purview-Label für Kontinuität nötig |
| Graph-Provisioning | Azure Application Registration automatisch via Microsoft Graph provisioniert |
| Multi-Tenant / B2B | Partner-Domains und dedizierte Issuers |
| Kontextuelles ABAC | Zugriffskontrolle nach User, IP, Location, Zeit, Azure-Gruppen und MFA |
| Unabhängige Custody | MPC-verteiltes Key Management; Microsoft hält Ihren Second Key nicht |
| Operabilität | Dediziertes Tenant-/Vault-Modell mit granularen Regeln außerhalb von Microsoft |
Nutzen Sie die sechs Fragen oben gegen jeden Anbieter, einschließlich uns. Die richtige Shortlist ist die, die jeden Punkt mit Ihrem Tenant demonstrieren kann, nicht die mit dem längsten Feature-PDF.
DKE-Anbieter nur nach Markenbekanntheit zu bewerten, verfehlt die operativen Ausfälle, die Programme killen: Rotation, die Labels bricht, manuelle Azure-Verdrahtung, kein B2B-Pfad und Unwrap-Regeln, die Kontext ignorieren. Scoren Sie jeden Kandidaten in einem Pilot auf diesen sechs Kriterien. Halten Sie Microsoft vom Second Key fern, und verhindern Sie, dass Ihr eigener Anbieter der neue Single Point of Failure wird.
Geschrieben von
Nagib Aouini
Verwandte Ressourcen
Sagen Sie uns, wo Kontrolle heute schwierig ist. Wir helfen Ihnen, den nächsten praktischen Schritt zu finden.