Microsoft AZ-801: Verschlüsselung, Zertifikate und PKI — Lernleitfaden

By Laurynas Brazys · 7 August 2026 · #microsoft #az-801 #certification #exam-prep #study-guide

Teil des Microsoft Windows Server Hybrid Administrator Associate AZ-801 — Lernleitfaden. Üben Sie mit verifizierten Antworten im Microsoft-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

Überblick

Verschlüsselung und Public-Key-Infrastruktur bilden die Vertrauensgrundlage einer auf Windows Server zentrierten hybriden Umgebung. Administratoren müssen in der Lage sein, Daten im Ruhezustand (at rest) mit BitLocker und EFS zu härten, eine Unternehmens-PKI mit AD CS und einem Online Responder einzurichten und zu betreiben, den Lebenszyklus von Zertifikaten durch Vorlagen und automatische Registrierung (Autoenrollment) zu automatisieren und eine cloud-native Zertifikatsverwaltung über Azure Key Vault zu integrieren. Die folgenden Abschnitte beschreiben die Architektur, die Voraussetzungen, die Bereitstellungsmuster und die operativen Kontrollen, die in realen hybriden Windows-Server-Umgebungen regelmäßig anzutreffen sind.

BitLocker und EFS auf Windows Server

Die BitLocker-Laufwerkverschlüsselung schützt Volumes durch eine Kombination aus dem TPM und Schlüsselschutzmechanismen. TPM 2.0 ist die aktuell empfohlene Basis; TPM 1.2 wird weiterhin unterstützt, aber TPM 2.0 mit UEFI und Secure Boot bietet eine stärkere Bindung der Startkette an die TPM Platform Configuration Registers (PCRs). Für Server sollte TPM+PIN für Betriebssystem-Volumes vorgeschrieben werden, um einen Online-Faktor hinzuzufügen, was Kaltstart- und Offline-Angriffe abschwächt. Konfigurieren Sie dies über eine Gruppenrichtlinie unter BitLocker Drive Encryption (Require additional authentication at startup; Allow enhanced PINs for startup). Wo kein TPM vorhanden ist, ist ein USB-Startschlüssel möglich, aber operativ unterlegen und weniger sicher.

Eine Governance für Wiederherstellungsschlüssel ist zwingend erforderlich. In AD DS-Umgebungen hinterlegen Sie Wiederherstellungsinformationen in Computerobjekten (msFVE-RecoveryInformation) über Gruppenrichtlinien (Choose how BitLocker-protected operating system drives can be recovered; Back up recovery passwords and key packages to AD DS). In Szenarien mit Azure AD-Join werden Wiederherstellungsschlüssel im Azure AD-Geräteobjekt hinterlegt und sind für autorisierte Administratoren im „Devices“-Blade auffindbar; Intune-Richtlinien können die Hinterlegung in Azure AD vorschreiben. Überprüfen Sie die Hinterlegung, bevor Sie die Verschlüsselung in großem Umfang aktivieren.

Network Unlock macht die manuelle PIN-Eingabe für in die Domäne eingebundene Server in sicheren Rechenzentrums-Subnetzen bei unbeaufsichtigten Neustarts überflüssig. Zu den Voraussetzungen gehören TPM-geschützte Betriebssystem-Volumes, UEFI-Firmware, eine kabelgebundene Verbindung ohne 802.1X-Sperre vor dem Start (Pre-Boot), die Erreichbarkeit von DHCP-Broadcasts und ein Windows Deployment Services-Server mit dem Network Unlock-Feature und einem Server-Authentifizierungszertifikat, das von einer Unternehmens-CA unter Verwendung der Network Unlock-Vorlage ausgestellt wurde. Konfigurieren Sie die BitLocker-GPOs, um Network Unlock zu aktivieren, und stellen Sie sicher, dass OCSP/CRL der CA vom WDS-Server aus erreichbar sind. Network Unlock ist nicht auf mobile oder drahtlose Hosts anwendbar.

Pre-Provisioning beschleunigt groß angelegte Bereitstellungen, indem der belegte Speicherplatz bereits während des Imagings in Windows PE verschlüsselt wird. Verwenden Sie in MDT/Configuration Manager-Tasksequenzen den Schritt „Pre-provision BitLocker“ (manage-bde -on C: -used -skiphardwaretest), um die Verschlüsselung vor der Bereitstellung des vollständigen Betriebssystems zu beginnen; wechseln Sie nach dem Domänenbeitritt und der Anwendung der Richtlinien zum vollständigen Schutz.

Verwalten Sie BitLocker zentral mit Microsoft Endpoint Manager. Intune (MDM) erzwingt eine stille Verschlüsselung (silent encryption) mit reinen TPM-Schutzmechanismen für in Azure AD eingebundene Geräte und hinterlegt die Schlüssel in Azure AD; die Anforderung einer Start-PIN schließt die stille Verschlüsselung aus und erfordert eine Benutzerinteraktion. Für in die Domäne eingebundene Server und gemischte Umgebungen verwenden Sie Configuration Manager BitLocker Management (der Nachfolger von MBAM) für Compliance-Berichte, Hinterlegung, Portale und Schlüsselrotation. Planen Sie immer eine überprüfbare Hinterlegung und Besitzerzuordnung ein.

EFS ist eine dateibasierte Verschlüsselung, die an EFS-Zertifikate von Benutzern gebunden ist. Pro Datei wird ein Dateiverschlüsselungsschlüssel (File Encryption Key, FEK) generiert und mit dem öffentlichen EFS-Schlüssel des Benutzers verschlüsselt. Ohne eine Unternehmens-CA stellt Windows ein selbstsigniertes EFS-Zertifikat aus, was die Wiederherstellung und die zentrale Kontrolle behindert. In Unternehmensbereitstellungen stellen Sie EFS-Zertifikate von AD CS unter Verwendung der Vorlage „Basic EFS“ aus und benennen Data Recovery Agents (DRAs) über GPO (Public Key Policies, Encrypting File System), um die Wiederherstellbarkeit von benutzerverschlüsselten Dateien sicherzustellen. Das Kommandozeilen-Tool cipher bleibt unerlässlich: cipher /e und /d verschlüsseln bzw. entschlüsseln; cipher /r generiert DRA-Schlüsselpaare; cipher /u aktualisiert verschlüsselte Dateien, damit sie das aktuelle EFS-Zertifikat verwenden. Verwenden Sie BitLocker für den Schutz auf Volume-Ebene und EFS nur dann, wenn eine Trennung pro Benutzer oder pro Datei erforderlich ist, wobei zu beachten ist, dass EFS eine Benutzeranmeldung und die Verfügbarkeit von Zertifikaten erfordert.

AD CS-Hierarchie und Online Responder

Eine resiliente Unternehmens-PKI verwendet eine mehrstufige CA-Hierarchie. Die Offline-Stammzertifizierungsstelle (Root CA) ist der Vertrauensanker und muss physisch und logisch isoliert sein. Sie wird nur eingeschaltet, um Anforderungen untergeordneter CAs zu signieren und CRLs zu veröffentlichen. Verwenden Sie lange Gültigkeitsdauern (z. B. 10–20 Jahre), große RSA-Schlüssellängen (mindestens 4096, wo möglich) und veröffentlichen Sie CDP/AIA unter hochverfügbaren, pfadkonsistenten URLs. Stellen Sie niemals End-Entitäts-Zertifikate von der Stammzertifizierungsstelle aus.

Untergeordnete (ausstellende) CAs sind in die Domäne eingebunden, online und haben eine kurze Lebensdauer (z. B. 3–5 Jahre) mit eingeschränkter Schlüsselverwendung und EKUs. Sie stellen Computer-, Benutzer- und Dienstzertifikate aus und veröffentlichen häufig CRLs mit Überlappung, um Ausfälle bei Veröffentlichungsverzögerungen zu vermeiden. Bevorzugen Sie HSM-gestützte private Schlüssel auf ausstellenden CAs, um das Risiko der Exfiltration von Schlüsseln zu verringern. Konfigurieren Sie registrierungs- oder richtlinienbasierte Einschränkungen für Vorlagen und die Ausstellung, um das Prinzip der geringsten Rechte (Least Privilege) durchzusetzen.

Die Sperrprüfung muss schnell und zuverlässig sein. Ein Online Responder (OCSP) reduziert die Latenz für Clients, indem er Statusabfragen pro Zertifikat beantwortet, anstatt vollständige CRLs herunterzuladen. Installieren Sie den Rollendienst „Online Responder“, registrieren Sie Responder für ein OCSP Response Signing-Zertifikat über eine dedizierte v3-Vorlage und konfigurieren Sie eine Revocation Configuration, die auf die ausstellende CA und deren CRLs verweist, indem Sie den Microsoft CRL-based Revocation Provider verwenden. Stellen Sie sicher, dass die CA eine OCSP-URL in die Authority Information Access-Erweiterung aufnimmt, damit Clients wissen, wo sie Anfragen stellen müssen.

Für Skalierbarkeit und Resilienz stellen Sie ein OCSP-Array bereit. Bestimmen Sie einen Array-Controller, um Sperrkonfigurationen auf die Mitglieds-Responder zu replizieren. Verteilen Sie die Last des Arrays mithilfe von Windows NLB oder einem externen Load Balancer mit einem Health Probe, der die Reaktionsfähigkeit von OCSP und die Aktualität der Signaturzertifikate bestätigt. Legen Sie kurze Lebensdauern für OCSP-Signaturzertifikate fest und nutzen Sie die automatische Registrierung für die Erneuerung, um die Risikoexposition zu minimieren. Überwachen Sie die Aktualität der CRL und die Cache-Lebensdauer des OCSP, um veraltete Antworten zu verhindern.

Vorlagen, automatische Registrierung, Schlüsselarchivierung und Credential Roaming

Zertifikatvorlagen steuern die Einschränkungen für Anforderungen, den Antragstellernamen, die Schlüsselverwendungen und die Ausstellungsanforderungen. Vorlagen der Version 2 (eingeführt mit Windows Server 2003 Enterprise) ermöglichen Anpassungen und unterstützen die automatische Registrierung mit CSP-basierten Schlüsseln. Vorlagen der Version 3 (Windows Server 2008 und neuer) fügen CNG-Unterstützung, ECC und Suite-B-Algorithmen hinzu. Wählen Sie v3, wenn Sie CNG/ECC benötigen; wählen Sie v2 für maximale Kompatibilität mit älteren Systemen. Binden Sie Vorlagen an eine einzelne Gruppe ausstellender CAs, um den „Blast Radius“ (Schadensradius) zu begrenzen.

Die automatische Registrierung (Autoenrollment) macht den Zertifikatslebenszyklus zu einem richtliniengesteuerten, automatisierten Prozess. Konfigurieren Sie die Gruppenrichtlinie unter Computerkonfiguration oder Benutzerkonfiguration, Windows-Einstellungen, Sicherheitseinstellungen, Richtlinien für öffentliche Schlüssel, Zertifikatdienste-Client – Automatische Zertifikatregistrierung. Aktivieren Sie sie mit den Optionen „Abgelaufene Zertifikate erneuern“, „Zertifikate, die Zertifikatvorlagen verwenden, aktualisieren“ und „Gesperrte/abgelaufene Zertifikate entfernen“. Die automatische Registrierung erfordert Vorlagenberechtigungen: Prinzipale müssen die Berechtigungen „Lesen“ und „Automatisch registrieren“ haben; „Registrieren“ reicht nur für die manuelle Registrierung aus. Beschränken Sie den Geltungsbereich über Sicherheitsgruppen, um unerwartete Zertifikatausstellungen zu vermeiden und das Volumen zu kontrollieren.

Die Schlüsselarchivierung schützt Daten bei Verlust eines privaten Schlüssels. Aktivieren Sie in der Vorlage die Option „Privaten Verschlüsselungsschlüssel des Antragstellers archivieren“ für reine Verschlüsselungszertifikate (z. B. EFS, S/MIME). Bestimmen Sie Schlüsselwiederherstellungs-Agents (KRAs), indem Sie ihnen KRA-Zertifikate aus der Vorlage „Schlüsselwiederherstellungs-Agent“ ausstellen und die CA für die Archivierung von Schlüsseln konfigurieren. Die Wiederherstellung ist auf archivierbare Schlüsseltypen beschränkt; traditionell wird RSA Key Exchange (Legacy-CSP) unterstützt, während die Archivierung privater CNG/ECC-Schlüssel von der AD CS-Schlüsselarchivierung nicht unterstützt wird. Aktivieren Sie die Archivierung nicht für reine Signaturvorlagen.

Credential Roaming synchronisiert Benutzerzertifikate, private Schlüssel und DPAPI-Hauptschlüssel über in die Domäne eingebundene Geräte, indem es sie in AD speichert. Aktivieren Sie es über die Gruppenrichtlinie unter Benutzerkonfiguration, Administrative Vorlagen, System, Credential Roaming, und beschränken Sie den Geltungsbereich auf vertrauenswürdige Benutzer. Dies verbessert die Benutzererfahrung für EFS-, S/MIME- und Client-Authentifizierungszertifikate auf mehreren Rechnern ohne servergespeicherte Profile (Roaming Profiles). Überprüfen Sie die Unterstützung des Verzeichnisschemas und planen Sie die Interaktion mit Windows Hello for Business und Anmeldeinformations-Managern von Drittanbietern, um Konflikte oder Duplizierungen zu vermeiden.

Lebenszyklus von TLS/SSL und Integration von Azure Key Vault

Modernes TLS hängt von der korrekten Semantik der Zertifikate ab. Fügen Sie immer die Serverauthentifizierungs-EKU hinzu und bevorzugen Sie SHA-256 oder stärkere Signaturen mit mindestens 2048-Bit-RSA oder entsprechenden ECC-Kurven. Der Alternative Antragstellername (SAN) muss jeden Hostnamen auflisten, den Clients verwenden; der veraltete Antragsteller-CN allein ist für moderne Clients unzureichend. Wildcard-Zertifikate (*.contoso.com) vereinfachen Bereitstellungen für mehrere Hosts in einer DNS-Zone, passen aber nicht auf mehrstufige Namen (app.dev.contoso.com) oder andere Zonen; bewerten Sie die Risikokonzentration sorgfältig, wenn private Wildcard-Schlüssel breit verteilt werden. Für Anforderungen über mehrere Zonen hinweg sollten Sie SAN-Zertifikate oder mehrere gezielte Zertifikate bevorzugen.

Standardisieren Sie CSRs mit certreq oder IIS, pflegen Sie Richtlinien zur Schlüsselverwahrung und automatisieren Sie die Erneuerung rechtzeitig vor dem NotAfter-Datum, um gestaffelte Rollouts und die Weitergabe über OCSP/CRL zu ermöglichen. Auf in die Domäne eingebundenen Webservern kann die automatische Registrierung (Autoenrollment) mit einer Webserver-v3-Vorlage die Ausstellung und Erneuerung automatisieren; verwenden Sie die Angabe des Antragstellernamens in der Anforderung mit entsprechenden Genehmigungen. Wenden Sie reine TLS 1.2/1.3-Serverkonfigurationen an, aktivieren Sie ECDHE-Cipher-Suiten für Forward Secrecy und entfernen Sie veraltete SHA-1- und Export-Grade-Chiffren.

Azure Key Vault erweitert den Lebenszyklus von Zertifikaten in die Cloud. Sie können vorhandene PFX/PEM-Zertifikate importieren, neue mit einer in Key Vault integrierten Zertifizierungsstelle (z. B. DigiCert) unter Verwendung einer Zertifikatsrichtlinie generieren und die automatische Rotation einstellen, sodass Key Vault die Erneuerung anfordert und die neueste Version vorhält. Das Zertifikatsobjekt umschließt einen Key Vault-Schlüssel und ein Secret und ermöglicht je nach Richtlinie exportierbare PFX-Workflows oder HSM-gestützte, nicht exportierbare Schlüssel. Anwendungen und Dienste rufen aktuelle Versionen über RBAC oder Zugriffsrichtlinien und verwaltete Identitäten ab. Key Vault-Referenzen ermöglichen es Diensten wie Azure App Service und Azure Functions, Zertifikate und Secrets per Referenz abzurufen, ohne sie in der Konfiguration einzubetten. Für Windows Server-Workloads in Azure oder hybriden Umgebungen verwenden Sie die Azure Key Vault VM-Erweiterung oder eine benutzerdefinierte Automatisierung mit verwalteten Identitäten, um aktualisierte Zertifikate abzurufen, im Windows-Zertifikatspeicher zu installieren und Dienstneustarts auszulösen, was Zero-Touch-Erneuerungen über Webserver, Reverse-Proxys und Application Gateways hinweg sicherstellt.

Praktisches Problemszenario

Adobe Inc. muss die Verschlüsselung und PKI über zwei lokale Rechenzentren und in Azure gehostete Windows Server-Workloads hinweg standardisieren. Sie benötigen unbeaufsichtigte Serverneustarts in den Rechenzentren, automatisierte Erneuerungen von Webzertifikaten, die Wiederherstellung der Verschlüsselung auf Dateiebene und minimale Beeinträchtigungen für die Benutzer.

Aufbau einer zweistufigen PKI mit einer Offline-Stamm-CA und zwei online ausstellenden CAs

Warum: Eine Offline-Stamm-CA schafft einen hochsicheren Vertrauensanker, während kurzlebige ausstellende CAs das Risiko begrenzen und Hochverfügbarkeit unterstützen. Die Hierarchie ermöglicht eine Trennung der Zuständigkeiten, eine skalierbare Geltungsbereichsdefinition für Vorlagen und eine sichere Veröffentlichung von CRL/AIA.

Bereitstellung eines OCSP-Online-Responder-Arrays hinter einem Load Balancer

Warum: OCSP liefert Sperrinformationen mit geringer Latenz für Web- und Anwendungsserver im großen Maßstab. Ein Array mit lastverteiltem Verbund und Integritätsprüfungen verhindert Single Points of Failure und stellt sicher, dass Clients aktuelle Statusinformationen erhalten, ohne große CRLs herunterladen zu müssen.

Erstellen von v3-Zertifikatvorlagen für Webserver, OCSP-Antwortsignierung und Computerauthentifizierung; v2-Vorlagen für EFS und S/MIME mit Schlüsselarchivierung

Warum: v3 ermöglicht CNG/ECC für modernes TLS und die Signierung durch Responder; v2 maximiert die Client-Kompatibilität für EFS/S/MIME und unterstützt die Schlüsselarchivierung für Verschlüsselungsschlüssel. Die Geltungsbereichsdefinition der Vorlagen erzwingt die Ausstellung nach dem Prinzip der geringsten Rechte.

Aktivieren der automatischen Registrierung (Autoenrollment) über Gruppenrichtlinien und Zuweisen der Berechtigungen Lesen/Automatisch registrieren auf Vorlagen an eingegrenzte Sicherheitsgruppen

Warum: Die automatische Registrierung eliminiert manuelle Schritte, kümmert sich um Erneuerungen vor dem Ablaufdatum und bereinigt widerrufene/abgelaufene Zertifikate. Die Eingrenzung über Sicherheitsgruppen vermeidet eine übermäßige Ausstellung und folgt dem Prinzip der geringsten Rechte.

Implementieren von BitLocker auf allen Servern mit TPM+PIN für Betriebssystem-Volumes; Hinterlegen der Wiederherstellungsschlüssel in AD DS

Warum: TPM+PIN erhöht die Widerstandsfähigkeit gegen Offline-Angriffe; die Hinterlegung in AD DS garantiert die Wiederherstellbarkeit. Die Server erfüllen die Uptime-Ziele und gewährleisten gleichzeitig eine Compliance-konforme Überprüfbarkeit der Schlüsselverwahrung.

Konfigurieren der Netzwerkentsperrung mit WDS und der Funktion „Netzwerkentsperrung“ in den Subnetzen des Rechenzentrums

Warum: Unbeaufsichtigte Neustarts nach dem Patchen ohne lokalen Konsolenzugriff werden ermöglicht, während die TPM+PIN-Sicherheitskontrollen außerhalb des Rechenzentrums beibehalten werden. UEFI+TPM und kabelgebundenes DHCP erfüllen die technischen Voraussetzungen

← Azure Arc und hybrides Servermanagement · Alle Domänen · Windows Server Update- und Patch-Management →

Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →