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 mit einem Überlappungsfenster rotieren 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.
Überlappung bei Schlüsselrotation
cache_duration_hours (Standard 24). Während der Rotation bedient der vorherige Schlüssel GetKey + Decrypt für dieses Fenster weiter (previous_key_id / previous_key_retires_at).
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 ab, um Inhalte mit dem öffentlichen Organisationsschlüssel zu verschlüsseln. Der veröffentlichte Schlüssel ist ein Standard-RSA-JWK, dessen kid die Dienst-URL ist (https://{slug}.{base-domain}/dke/{slug}/{key_name}/{key_id}).
Decrypt
Office sendet den umhüllten Schlüssel zurück. Cockpit v2 löst den Dienst auf, verlangt den Status Running, wählt den effektiven Schlüssel aus (den aktuellen oder während des Rotationsfensters den vorherigen), 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.
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.