DKE-Konfiguration in Cockpit v2
Die Konfigurationsfunktionen von Double Key Encryption (DKE 365), die DuoKey Cockpit v2 bereitstellt.
Diese Seite dokumentiert die DKE-365-Konfigurationsfunktionen, die DuoKey Cockpit v2 bereitstellt. Für den bisherigen Cockpit-v1-Ablauf siehe die Abschnitte Einrichtung und Betrieb dieser Anleitung.
Zwei Endpunktfamilien
DKE 365 stellt zwei Arten von Endpunkten bereit:
- Eine Verwaltungsoberfläche, die Cockpit-Administratoren zum Bereitstellen, Konfigurieren und Verwalten von DKE-Diensten nutzen. Sie ist durch eine Cockpit-Benutzersitzung und die rollenbasierte Zugriffskontrolle der Plattform geschützt.
- Das öffentliche DKE-Protokoll, das Microsoft 365 / Office direkt aufruft:
GetKeyist öffentlich, währendDecryptbei entsprechender Konfiguration ein Azure-AD-Bearer-Token validiert und die gebundene Zugriffsrichtlinie durchsetzt.
Dienst-Lebenszyklus
Provisioned → Running → Disabled → Stopped (+ Failed)
Nur ein Dienst im Zustand Running bedient Decrypt-Anfragen.
Einen Dienst verwalten
Vom Cockpit aus können Sie einen neuen DKE-Dienst bereitstellen, prüfen, ob ein Schlüssel DKE-fähig ist, ihn aktivieren (was die Azure-AD-App automatisch provisioniert), deaktivieren oder stoppen, seinen Schlüssel rotieren (siehe Schlüsselrotation und Schlüsselhistorie) sowie seine Health- und Onboarding-Hinweise (DNS / CNAME) überwachen. Microsoft 365 / Office rufen dann die öffentlichen Protokoll-Endpunkte des Dienstes (version, GetKey und Decrypt) direkt auf.
Felder der Dienstkonfiguration
Ein DKE-Dienst wird konfiguriert mit:
Identität & Routing
name, description, slug (eine GUID zum Aufbau der Dienst-URL), key_id (der gebundene RSA-2048/4096-Schlüssel), key_name (in der veröffentlichten kid-URL angezeigt), status.
Algorithmus
algorithm: RSA-OAEP-256 (Standard) oder RS256.
Schlüsselhistorie
Ein ausrotierter Schlüssel bleibt in der Schlüsselhistorie des Dienstes nur zum Entschlüsseln verfügbar, bis ein Administrator ihn außer Dienst stellt — siehe Schlüsselrotation und Schlüsselhistorie. cache_duration_hours (Standard 24) wird beim Dienst weiterhin akzeptiert.
Azure AD / Entra
azure_tenant_id, azure_client_id, azure_audience, allowed_domains (B2B-Partnerdomänen, jede den gültigen Ausstellern ihres eigenen Mandanten zugeordnet), identity_provider_id (Graph-Anmeldedaten zur automatischen Provisionierung der App).
Optionales mTLS
mtls_enabled, mtls_client_ca_pem, mtls_allowed_subjects, mtls_header_name (Standard X-ARR-ClientCert).
Permissives Decrypt
allow_anonymous (wird nur außerhalb der Produktion berücksichtigt, wenn der Host ebenfalls den permissiven Modus aktiviert; darf niemals in der Produktion verwendet werden).
Zugriffskontrolle
access_policy_id bindet eine Zugriffsrichtlinie, die bei jedem Decrypt ausgewertet wird.
Beispiel einer Dienstkonfiguration
{
"name": "Contoso DKE",
"slug": "89c3b193-af16-4887-8031-43f88d475d9d",
"key_id": "<rsa-key-uuid>",
"key_name": "dke_key",
"azure_tenant_id": "<azure-tenant-guid>",
"azure_client_id": "<app-guid>",
"azure_audience": "https://89c3b193-af16-4887-8031-43f88d475d9d.duokey365.com",
"allowed_domains": ["partner.com"],
"algorithm": "RSA-OAEP-256",
"cache_duration_hours": 24,
"mtls_enabled": false,
"allow_anonymous": false,
"access_policy_id": "<policy-uuid>",
"identity_provider_id": "<idp-uuid>"
}
GetKey- / Decrypt-Ablauf
GetKey
Office ruft das öffentliche JWK des Dienstes über die Label-URL (https://{slug}.{base-domain}/dke/{slug}) ab, um Inhalte mit dem öffentlichen Organisationsschlüssel zu verschlüsseln. Der veröffentlichte Schlüssel ist ein Standard-RSA-JWK, dessen kid die aktuelle Schlüsselversion benennt (https://{slug}.{base-domain}/dke/{slug}/{key_id}).
Decrypt
Office sendet den umhüllten Schlüssel an die im Dokument hinterlegte kid zurück. Cockpit v2 löst den Dienst auf, verlangt den Status Running, wählt den Schlüssel aus, den die kid benennt (den aktuellen Schlüssel oder einen Nur-Entschlüsseln-Schlüssel aus der Historie), führt eine optionale mTLS-Validierung durch, validiert das Azure-AD-JWT, setzt die gebundene Zugriffsrichtlinie durch und entschlüsselt anschließend per RSA-OAEP im Vault. Der private Schlüssel verlässt den Vault nie.
Jedes Decrypt wird pro Client-IP im Krypto-Tarif ratenbegrenzt (1000 Anfragen/Minute).
Der veröffentlichte Schlüssel sowie die Anfrage-/Antwort-Payloads folgen dem DKE-Protokollformat von Microsoft, sodass Office und Purview ohne jede benutzerdefinierte Konfiguration mit dem Dienst zusammenarbeiten.
Schlüsselrotation und Schlüsselhistorie
Seit Cockpit 2.0.8 ändert eine Rotation die URL in der Vertraulichkeitsbezeichnung nicht.
| Element | Verhalten |
|---|---|
| Label-URL | Die URL, die in die Purview-Bezeichnung eingetragen wird, lautet https://{slug}.{base-domain}/dke/{slug}. Sie benennt den Dienst, nicht einen Schlüssel, und wird auf der Detailseite des Dienstes angezeigt. |
| Rotation | Neue Dokumente werden mit dem neuen Schlüssel verschlüsselt. Die kid ändert sich; die Label-URL nicht. |
| Ausrotierte Schlüssel | Werden in der Schlüsselhistorie des Dienstes als Nur-Entschlüsseln-Schlüssel aufbewahrt, sodass damit verschlüsselte Dokumente lesbar bleiben. Ein ausrotierter Schlüssel läuft nicht mehr von selbst ab. |
| Außer Dienst stellen / wiederherstellen | Ein Administrator stellt einen Schlüssel der Historie außer Dienst, wenn kein Dokument ihn mehr benötigt; ein außer Dienst gestellter Schlüssel antwortet mit 404. Ein außer Dienst gestellter Schlüssel kann wiederhergestellt werden. |
| Schlüssel umbenennen | URLs enthalten den Dienst-Slug und die Schlüssel-ID, nie den Schlüsselnamen, sodass das Umbenennen eines Schlüssels für Office nichts ändert. Der Dienst zeigt den neuen Namen an. |
Eine Bezeichnung, deren URL einen Schlüssel benennt (https://{slug}.{base-domain}/dke/{key_id}), funktioniert weiterhin. Seit 2.0.9 folgt sie ebenfalls Rotationen: Sie verschlüsselt neue Dokumente mit dem aktuellen Schlüssel des Dienstes, ohne Änderung an der Bezeichnung.
Azure-AD-Provisionierung („Registrierung" des Dienstes)
Es gibt keinen separaten Registrierungsschritt. Registrierung = Bereitstellen → Aktivieren. Beim enable ruft Cockpit v2, sofern der Dienst über eine identity_provider_id verfügt und noch keine Azure-App existiert, Microsoft Graph auf, um die Azure-AD-App-Registrierung zu erstellen und zu konfigurieren (Identifier-URI / Audience, Redirect-URL), und speichert anschließend die resultierenden Werte azure_client_id, azure_audience und azure_app_object_id. Die Graph-Anmeldedaten stammen entweder vom Identitätsanbieter des Dienstes oder aus dem Host-Fallback DKE_DEFAULT_GRAPH_* (der Application.ReadWrite.All benötigt).
DKE-Einstellungen auf Host-Ebene (Cockpit-v2-Umgebung)
Diese Umgebungsvariablen werden auf dem Cockpit-v2-Server gesetzt:
| Variable | Zweck |
|---|---|
DKE_BASE_DOMAIN | DNS-Basis für Dienst-Verbindungs-URLs — jeder Dienst ist https://{slug}.{DKE_BASE_DOMAIN} (erfordert Wildcard-DNS + TLS) |
DKE_AUDIENCE_DOMAIN | JWT-Audience / Azure-AD-Identifier-URI-Apex (fällt auf DKE_BASE_DOMAIN zurück) |
DKE_DEFAULT_GRAPH_TENANT_ID / DKE_DEFAULT_GRAPH_CLIENT_ID / DKE_DEFAULT_GRAPH_CLIENT_SECRET | Fallback-Microsoft-Graph-App zur automatischen Provisionierung von Azure-AD-Registrierungen |
DKE_ALLOW_PERMISSIVE_MODE | Opt-in für permissives Decrypt, nur für Entwicklung/Test — muss in der Produktion nicht gesetzt sein |
DKE_TENANT_DECRYPT_RPS_MAX | Obergrenze der Decrypt-Rate pro Mandant (Standard 100) |
DKE_JWKS_CACHE_TTL_SECS | Azure-AD-JWKS-Cache-TTL für die Validierung des Decrypt-Tokens |
Microsoft Purview
DKE ist der Purview- / MIP-DKE-Schlüsselspeicher: Vertraulichkeitsbezeichnungen vom Typ Double Key Encryption verweisen auf diese GetKey- / Decrypt-Endpunkte (die Bezeichnungen werden auf Microsoft-Seite konfiguriert — siehe Vertraulichkeitsbezeichnungen und Microsoft Purview). Cockpit v2 bietet zusätzlich einen separaten Purview-DLP-App-Typ für die Integration der Datenverlustprävention.
Fahren Sie fort mit Zugriffsrichtlinien, um zu steuern, wer, von wo und wann einen DKE-Schlüssel verwenden darf.