Was sind die Best Practices für die NDES-Sicherheit?

Die NDES-Sicherheitsbest Practices sind die Konfigurations- und Betriebskontrollen, die die Rolle des Netzwerkgeräteregistrierungsdienstes (NDES) in Active Directory Certificate Services schützen. Sie umfassen verschlüsselte Kommunikation, Härtung von Dienstkonten, Schutz privater Schlüssel und den Lebenszyklus von Zertifikatvorlagen, sodass ein kompromittierter NDES-Server nicht zum Anfordern beliebiger Zertifikate verwendet werden kann.

Der Netzwerkgeräte-Registrierungsdienst (NDES) ermöglicht es Software auf Netzwerkgeräten wie Routern, Firewalls und Switches, digitale Zertifikate ohne Domänenanmeldeinformationen zu beziehen. NDES ist einer der Rollendienste der Active Directory-Zertifikatdienste (AD CS) und implementiert das Simple Certificate Enrollment Protocol (SCEP) , welches die Kommunikation zwischen der Registrierungsstelle (RA) und Netzwerkgeräten während der Registrierung definiert. Da NDES die Schnittstelle zwischen nicht vertrauenswürdigen Geräten und einer vertrauenswürdigen Zertifizierungsstelle bildet, dienen alle auf dieser Seite beschriebenen Maßnahmen dazu, diese Schnittstelle als Schwachstelle der Public-Key-Infrastruktur (PKI) zu verhindern.

Dieser Leitfaden behandelt die Funktionsweise von NDES, die von Microsoft und EC empfohlenen spezifischen Härtungsmaßnahmen, die Priorisierung der Kontrollen, eine Pro-und-Contra-Analyse der wichtigsten Entscheidungen, einen Entscheidungsbaum und eine Entscheidungsmatrix für Ihre Umgebung sowie die Einbindung der NDES-Härtung in ein umfassenderes Zertifikatslebenszyklusmanagementprogramm.

Wichtige Erkenntnisse

• NDES verbindet nicht vertrauenswürdige Netzwerkgeräte mit einer vertrauenswürdigen Zertifizierungsstelle. Daher dienen alle Sicherheitsvorkehrungen dazu, zu verhindern, dass ein kompromittierter NDES-Server zu einem Einfallstor für die Ausstellung beliebiger Zertifikate wird.
• Der Schutz des privaten Schlüssels hat höchste Priorität: Ein HSM hält NDES-Schlüssel vom Arbeitsspeicher des Betriebssystems und von unverschlüsselten VM-Snapshots oder Backups fern.
• Die Rollentrennung und die Wahl des Dienstkontos (Netzwerkdienst, gMSA oder ein gehärtetes Domänenkonto) bestimmen, wie viel manuelle Passwort- und Berechtigungsverwaltung die NDES-Implementierung langfristig erfordert.
• NDES sollte auf einem eigenen Server laufen, niemals zusammen mit der Zertifizierungsstelle (CA) betrieben werden, außer hinter einer Firewall-Regel mit definiertem Gültigkeitsbereich, und sollte sich hinter einem Reverse-Proxy befinden, wenn es aus dem Internet erreichbar ist.
• Unternehmen, die auf manuelle, nicht dokumentierte PKI-Diensthärtung setzen, meldeten im vergangenen Jahr in 45 % der Fälle zertifikatsbedingte Ausfallzeiten, wobei 37.5 % dieser Ausfälle speziell durch ein abgelaufenes Zertifikat verursacht wurden. Laut der Trust Pulse Survey von DigiCert, veröffentlicht am 2. Juli 2025, fällt ein ungehärteter oder unüberwachter NDES-Server genau in diese Risikokategorie.

Für wen sind die Best Practices für die NDES-Sicherheit relevant?

Die Härtung des NDES betrifft mehr als nur die Person, die die Rolle eingerichtet hat. Hier erfahren Sie, was jedes Team konkret tun sollte.

• PKI-Administratoren Verantwortlich für den NDES-Build, die Dienstkontokonfiguration und den Zertifikatvorlagenlebenszyklus. Maßnahme: Sicherstellen, dass die CEP-Verschlüsselungs- und Exchange-Registrierungsagent-Vorlagen außerhalb der Ersteinrichtungs- und Verlängerungszeiträume nicht von der Zertifizierungsstelle zugewiesen sind.
• Sicherheitsarchitekten Entscheiden Sie, wie die privaten NDES-Schlüssel gespeichert und der Server isoliert werden. Maßnahme: Verpflichten Sie die Verwendung eines HSM-gestützten Schlüsselspeichers für jede NDES-Implementierung, die Zertifikate in großem Umfang ausstellt, nicht nur für die Zertifizierungsstelle selbst.
• Plattform- und Identitätsteams Verwalten Sie den Reverse-Proxy, die Firewall-Regeln und die TLS-Konfiguration vor NDES. Maßnahme: Stellen Sie sicher, dass der Reverse-Proxy und die Durchsetzung von TLS 1.2+ eingerichtet sind, bevor die SCEP-Registrierung für den Internetzugang (z. B. über Intune) aktiviert wird.
• Compliance und GRC Prüfen Sie, ob Nachweise zur NDES-Härtung für Audits vorliegen. Maßnahme: Fügen Sie die Prüfungen des NDES-Dienstkontos, der Vorlagenzuweisung und der Schlüsselspeicherung zur regelmäßigen PKI-Kontrollprüfung hinzu, nicht nur zu den Kontrollen der Zertifizierungsstelle selbst.
• CISOS Sie tragen das Risiko, dass ein kompromittierter NDES-Server einem Angreifer als Weg zur Zertifikatsausstellung dient. Maßnahme: Behandeln Sie NDES aufgrund seiner Vertrauensbeziehung zur Zertifizierungsstelle als ein dem Tier 0 benachbartes Asset und nicht als ein Netzwerkgerät mit niedriger Priorität.

Was sind die Best Practices für die NDES-Sicherheit?

Die Best Practices für die NDES-Sicherheit umfassen die von Microsoft und der Branche empfohlenen Maßnahmen zur Reduzierung der Angriffsfläche des Netzwerkgeräte-Registrierungsdienstes (NDES): Verschlüsselung des administrativen Datenverkehrs, Begrenzung der Dienstlaufzeit, Trennung der Betriebsrollen, Schutz der privaten Schlüssel zum Signieren und Verschlüsseln von Registrierungsanfragen sowie die korrekte Beschränkung der von NDES verwendbaren Zertifikatvorlagen. Keine dieser Maßnahmen ist isoliert wirksam; ein gehärtetes Dienstkonto mit einem ungeschützten privaten Schlüssel stellt weiterhin ein kritisches Sicherheitsrisiko dar, und ein HSM-gestützter Schlüssel ohne Rollentrennung macht den Server weiterhin anfällig für Missbrauch durch jeden mit Zugriff.

Funktionen von NDES

NDES erfüllt drei Funktionen im Zertifikatsregistrierungsprozess, und an jedem dieser Punkte greift eine der folgenden Sicherheitsmaßnahmen:

1. Generiert und stellt Administratoren einmalige Registrierungspasswörter zur Verfügung.
2. Übermittelt Registrierungsanträge an die Zertifizierungsstelle (CA).
3. Ruft registrierte Zertifikate von der Zertifizierungsstelle ab und leitet sie an das anfragende Netzwerkgerät weiter.

Die von Microsoft selbst bereitgestellten Hinweise zu diesen Kontrollmechanismen sind eine nützliche zusätzliche Referenz: siehe den Beitrag „NDES Security Best Practices“ im Microsoft Community Hub.

Sicherheitsbest Practices für NDES

Gehen Sie diese Kontrollmechanismen gemeinsam und nicht isoliert durch. Jeder Mechanismus schließt eine andere Sicherheitslücke, und die meisten Nahtoderfahrungen in der Praxis lassen sich darauf zurückführen, dass zwei oder drei dieser Mechanismen gleichzeitig außer Acht gelassen wurden, nicht nur einer.

Aktivieren Sie SSL/TLS für die NDES-Administrator-Website

Der SSL/TLS-Schutz auf der MSCEP_Admin-Website gewährleistet, dass das Anmelde-Challenge-Passwort vor Inspektionsangriffen geschützt ist, wenn sich ein Administrator oder ein Netzwerkgerät verbindet. Ohne diesen Schutz wäre das von NDES generierte Einmalpasswort im Klartext für jeden einsehbar, der die Verbindung abfangen könnte.

Verwenden Sie gegebenenfalls Zertifikate mit verlängerter Gültigkeitsdauer.

Die standardmäßige IPsec-Zertifikatvorlage (Offline-Anforderung) ist nur ein Jahr gültig. Wenn Sie benutzerdefinierte Zertifikatvorlagen für Signatur, Verschlüsselung oder allgemeine Zwecke für Geräte definieren, sollten Sie eine Vorlage der Version 2 mit zweijähriger Gültigkeit in Betracht ziehen, um den Verwaltungsaufwand für die Anforderung von Gerätezertifikaten zu reduzieren. Beachten Sie dabei den branchenweiten Trend zu kürzeren Zertifikatslaufzeiten für alle internetbasierten Anwendungen. Eine längere Gültigkeitsdauer ist für interne Gerätezertifikate angemessen, nicht jedoch für Anwendungen, die mit dem öffentlichen TLS-Ökosystem in Berührung kommen.

Deaktivieren Sie den NDES-Dienst, wenn er nicht verwendet wird.

Durch das Anhalten des NDES-Dienstes, wenn er nicht aktiv benötigt wird, wird verhindert, dass in diesem Zeitraum unautorisierte Zertifikate ausgestellt werden, und nicht verwendete Registrierungskennwörter werden aus dem Dienstcache entfernt. Diese Maßnahme reduziert das Risiko von Sicherheitslücken und bietet daher einen geringeren Komfort. Sie eignet sich am besten für Umgebungen mit geplanter, stapelweiser Geräteregistrierung anstelle einer kontinuierlichen, bedarfsgesteuerten Registrierung.

Server mit dem Sicherheitskonfigurationsassistenten absichern

Der Windows-Sicherheitskonfigurationsassistent analysiert die auf dem NDES-Server ausgeführten Rollen und Dienste und empfiehlt, IIS und alle zugehörigen installierten Komponenten abzusichern. Führen Sie ihn nach Abschluss der NDES-Konfiguration und nach jeder Änderung an den installierten Rollen erneut aus.

Implementieren Sie eine Rollentrennung

Für die Installation, Konfiguration und den Betrieb von NDES sind mehrere unterschiedliche Benutzerkonten erforderlich, deren Zuständigkeitsbereich sich nicht überschneiden sollte:

• Einrichtungskonto, das nur bei der Erstinstallation und der Vorlagenerneuerung verwendet wird.
• Geräteadministratoren, die die Geräteregistrierung tagtäglich verwalten.
• Das NDES-Dienstkonto selbst, das je nach Umgebung ein Netzwerkdienstkonto, ein gruppenverwaltetes Dienstkonto (gMSA) oder ein gehärtetes Domänenbenutzerkonto ist.

Wählen und härten Sie das NDES-Dienstkonto aus.

Unabhängig vom gewählten Kontotyp sollten Sie diese Kontrollmaßnahmen konsequent anwenden:

• Für gMSA- oder Domänenbenutzerkonten ist eine AES-Verschlüsselung erforderlich.
• Konfigurieren Sie Anmeldebeschränkungen und ein langes, nicht wiederverwendetes Passwort für Domänenbenutzerkonten.
• Ein gMSA- oder Domänenbenutzerkonto darf nicht auf einem anderen Computer oder für einen anderen Zweck wiederverwendet werden.
• Aktivieren Sie das Kontrollkästchen „Konto ist vertraulich und kann nicht delegiert werden“ für Domänenbenutzerkonten.
• Bei Verwendung eines gMSA oder einer benutzerdefinierten Zertifikatvorlage müssen die Berechtigungen für die privaten Schlüssel der NDES-Zertifikate manuell konfiguriert werden, da diese Berechtigungen nicht immer automatisch festgelegt werden.

Das zugrundeliegende System härten

Beschränken Sie die lokale Administratorengruppe auf dem NDES-Server auf PKI-Administratoren. Nur Mitglieder dieser Gruppe sollten über Anmelderechte am Server verfügen (interaktiv, remote-interaktiv, als Batch-Auftrag oder als Dienst). Alle anderen Konten sollten keinerlei Anmelderechte am NDES-Server besitzen.

Sichern Sie die privaten Schlüssel mit einem HSM

Der Schutz des Schlüssels ist die wichtigste Kontrollmaßnahme auf dieser Liste, denn ein kompromittierter NDES-Privatschlüssel ermöglicht es einem Angreifer, ein gültiges Zertifikat anzufordern, um sich als beliebiges Subjekt bei Active Directory anzumelden.

• Verwenden Hardware-Sicherheitsmodul (HSM) Ein HSM dient der Generierung, Speicherung und Verwaltung des Zugriffs auf NDES-Schlüssel. Es stellt sicher, dass NDES-Schlüssel niemals im Arbeitsspeicher des Betriebssystems abgelegt werden, bietet zusätzliche Kontrollmöglichkeiten und beschränkt den Zugriff auf das Schlüsselmaterial selbst.
• Wenn NDES virtualisiert ist, sollte man in jedem Fall ein HSM verwenden, um die privaten Schlüssel zu speichern, da Administratoren des Virtualisierungshosts, die Zugriff auf die VM, die Festplatte oder den Speicher haben, die Schlüssel andernfalls in unverschlüsselter Form wiederherstellen können.
• Wenn kein HSM verwendet wird, sollten Backups verschlüsselt und der Zugriff darauf streng eingeschränkt werden, da Snapshots, Checkpoints und andere Backup-Typen typischerweise die privaten NDES-Schlüssel im Klartext enthalten.

Isolieren Sie NDES innerhalb Ihrer Infrastruktur

• Wenn Sie NDES den Internetzugang gewähren möchten, beispielsweise um Zertifikate auf von Intune verwalteten Mobilgeräten zu registrieren, schützen Sie es mit einem Reverse-Proxy wie Azure AD Application Proxy oder Web Application Proxy (WAP). Setzen Sie NDES niemals direkt dem Internet aus.
• Installieren Sie NDES auf einem anderen Computer als dem, auf dem die Zertifizierungsstelle gehostet wird, und führen Sie keine anderen Dienste auf dem NDES-Server selbst aus.
• Wenn NDES auf einem CA-Computer installiert werden muss, konfigurieren Sie die Firewall-Regel für das Certification Authority Enrollment and Management Protocol (CERTSVC-RPC-TCP-IN) so, dass nur die IP-Adresse von NDES (und OCSP) die CA zur Registrierung erreichen kann.

CA- und Zertifikatvorlagen korrekt verwalten

NDES stützt sich auf eine kleine Anzahl von Zertifikatvorlagen, von denen jede einen eng begrenzten, spezifischen Zweck hat und für die jeweils eine eigene Berechtigungs- und Lebenszyklusdisziplin erforderlich ist.

CEP-Verschlüsselungs- und Exchange-Registrierungsagentenvorlagen

CEP-Verschlüsselung: Während der Dienstkonfiguration wird dem NDES-Computer ein Zertifikat basierend auf dieser Vorlage ausgestellt, das die SCEP-spezifische Verschlüsselung für die Kommunikation mit dem anfragenden Client anwendet. Exchange-Registrierungsagent (Offline-Anforderung): Auch hier wird während der Konfiguration ein Zertifikat basierend auf dieser Vorlage ausgestellt. NDES verwendet dieses Zertifikat, um die vom Gerät oder MDM empfangene Registrierungsanforderung digital neu zu signieren, bevor sie an die ausstellende Zertifizierungsstelle weitergeleitet wird. Beide Vorlagen werden nur bei der Erstinstallation von NDES und bei der Zertifikatserneuerung vor Ablauf benötigt. Im normalen Betrieb sollten sie der Zertifizierungsstelle entzogen werden. Die Berechtigungen für die Kontoregistrierung des Setups dürfen nur für die Dauer der Konfiguration gelten.

IPSec (Offline-Anfrage) / SCEP-Zertifikatvorlage

Diese Vorlage, auch bekannt als „Gerätevorlage“ oder „SCEP-Zertifikatvorlage“, dient der Registrierung von Geräte- oder Benutzerzertifikaten und wird der Zertifizierungsstelle (CA) während der NDES-Konfiguration automatisch zugewiesen. In den meisten Installationen wird sie durch eine benutzerdefinierte Vorlage ersetzt, die besser den jeweiligen Anforderungen entspricht. Erteilen Sie Registrierungsberechtigungen für diese Vorlage ausschließlich der Rolle „Geräteadministrator“ und dem NDES-Dienstkonto.

Datenübertragungsverschlüsselung erzwingen (TLS 1.2+)

TLS muss die gesamte Kommunikation zwischen NDES und dem MDM oder dem Gerät, das das Zertifikat anfordert, verschlüsseln. Dies beinhaltet die Erzwingung von TLS durch vollständiges Deaktivieren des HTTP-Listeners von IIS und die Sicherstellung der TLS-1.2-Konformität im gesamten Stack, nicht nur auf der NDES-Website selbst.

Auswahlkriterien: Welche Praktiken sollten zuerst priorisiert werden?

Nicht in jeder Umgebung lassen sich alle elf Kontrollmechanismen von Anfang an implementieren. Priorisieren Sie in dieser Reihenfolge, wenn Zeit oder Ressourcen begrenzt sind:

1. Zuerst der Schutz des privaten Schlüssels (HSM-gestützter Speicher), da dies die Kontrollmaßnahme mit dem größten Gefahrenradius ist, wenn sie übersprungen wird.
2. Datenverschlüsselung während der Übertragung (TLS 1.2+) ist an zweiter Stelle, da sie mit geringem Aufwand realisiert werden kann und ein passives Abhörrisiko sofort beseitigt.
3. Drittens die Isolation der Infrastruktur (separater Server, Reverse-Proxy bei Internetanbindung), da sie die Reichweite eines Angreifers einschränkt, selbst wenn eine andere Kontrollmaßnahme versagt.
4. An vierter Stelle stehen die Trennung der Rollen und die Härtung der Servicekonten, da falsch konfigurierte Konten die häufigste Art und Weise sind, wie die anderen Kontrollmechanismen umgangen werden.
5. Die Lebenszyklusoptimierung von Zertifikatvorlagen und die Systemhärtung erfolgen zuletzt, da sie das Restrisiko verringern, sobald die wirkungsvolleren Kontrollmaßnahmen bereits implementiert sind.

Vor- und Nachteile wichtiger NDES-Sicherheitskontrollen

Kontrolle	Vorteile	Nachteile
HSM-gestützte Speicherung privater Schlüssel	Schlüssel verlassen niemals eine Hardware-Vertrauensgrenze; ​​erfüllt die meisten Compliance-Anforderungen für den Schlüsselschutz.	Zusätzliche Kosten und erhöhte betriebliche Komplexität; erfordert Expertise in der HSM-Integration
gMSA-Dienstkonto	Keine manuelle Passwortrotation; unterstützt AES; verringert das Risiko von Anmeldeinformationsdiebstahl im Vergleich zu einem Domänenbenutzerkonto	Erfordert AD-Schema- und Versionsunterstützung; benötigt weiterhin einen gMSA-Bereich pro NDES-Server
Reverse-Proxy für internetseitigen NDES	Hält NDES selbst vom öffentlichen Internet fern; zentralisiert Authentifizierung und TLS-Terminierung	Fügt Infrastruktur hinzu, die selbst gepatcht, überwacht und gehärtet werden muss.
NDES zusammen mit CA unterbringen	Weniger Server müssen erstellt, gepatcht und überwacht werden.	Erweitert die Angriffsfläche der Zertifizierungsstelle; von Microsoft nicht empfohlen, außer hinter einer Firewall-Regel mit eingeschränktem Geltungsbereich.
NDES im Leerlauf deaktivieren	Verkleinert das Anzeigefenster; löscht ungenutzte zwischengespeicherte Passwörter	Unterbricht Szenarien mit ständig aktiver Registrierung, wie z. B. die kontinuierliche Ausstellung von Intune SCEPs.

Entscheidungsbaum: Welche NDES-Sicherheitskontrollen sind für Ihre Umgebung relevant?

Nutzen Sie diese Baumstruktur, um herauszufinden, welche Steuerungselemente für Ihre spezifische Bereitstellung unverzichtbar sind:

• Ist NDES über das Internet erreichbar (z. B. für die Intune SCEP-Registrierung)?
  • Ja: Stellen Sie einen Reverse-Proxy (Azure AD Application Proxy oder WAP) vor NDES bereit und stellen Sie sicher, dass TLS 1.2+ durchgängig durchgängig erzwungen wird, bevor Sie den Zugriff aktivieren.
  • Nein: Es muss bestätigt werden, dass NDES weiterhin in einem eigenen internen Segment isoliert ist; intern bedeutet nicht uneingeschränkt.
• Nutzt Ihre Organisation bereits ein HSM für die ausstellende Zertifizierungsstelle?
  • Ja: Das gleiche HSM sollte erweitert werden, um NDES-Privatschlüssel zu schützen, anstatt die NDES-Schlüssel in der Software zu belassen.
  • Nein: Die Einführung von HSM für NDES sollte Vorrang vor der Ausweitung des SCEP-Registrierungsvolumens haben, da das Volumen den Wert der Schlüssel als Ziel erhöht.
• Ist NDES derzeit auf demselben Server wie die Zertifizierungsstelle installiert?
  • Ja: Wenn möglich, migrieren Sie NDES auf einen eigenen Server; falls dies kurzfristig nicht möglich ist, konfigurieren Sie umgehend die Firewall-Regel CERTSVC-RPC-TCP-IN.
  • Nein: Bitte prüfen Sie, ob auf dem NDES-Server selbst keine anderen, nicht damit zusammenhängenden Dienste laufen.
• Erfolgt die Registrierung kontinuierlich (z. B. durch automatisierte, MDM-gesteuerte SCEP-Anfragen) oder in geplanten Chargen?
  • Kontinuierlich: Die Option „Deaktivieren, wenn nicht verwendet“ wird übersprungen. Stattdessen werden die anderen Steuerelemente sowie die aktive Überwachung genutzt.
  • Batch: Deaktivieren Sie den NDES-Dienst zwischen den Registrierungsfenstern, um die Angriffsfläche zu verringern.

Entscheidungsmatrix: Anwendungsfall, Sicherheitsauswirkungen, Betriebsaufwand, Automatisierungseignung und Verantwortlicher

Anhand dieser Matrix kann jede Entscheidung zur Härtung des NDES dem richtigen Verantwortlichen zugewiesen werden, wobei der damit verbundene Aufwand realistisch eingeschätzt werden muss.

Luftüberwachung	Auswirkungen auf die Sicherheit	Operativer Aufwand	Automatisierungsanpassung	Empfohlener Eigentümer
Öffentlich zugängliches/internetbasiertes NDES für die MDM-Registrierung	Hoch	Medium	Hohe Sicherheit, Reverse-Proxy- und TLS-Richtlinien können automatisiert werden	Plattform-/Identitätsteam
NDES befindet sich am selben Standort wie CA	Hoch	Niedrig	Niedrig, meist eine einmalige Firewall-Regel und Migrationsentscheidung	PKI-Administrator
Speicherung des privaten Schlüssels (HSM vs. Software)	Kritische	Medium	Hoch, die HSM-APIs unterstützen skriptbasierte Schlüsseloperationen	Sicherheitsarchitekt
Auswahl des Dienstkontos (gMSA vs. Domänenbenutzer)	Medium	Niedrig	Hoch, gMSA entfernt die manuelle Passwortrotation vollständig	PKI-Administrator
Lebenszyklus der Zertifikatvorlage (Aufhebung der CEP/EEA-Zuordnung)	Medium	Niedrig	Mittelgroß, kann per Skript gesteuert werden, benötigt aber ein Änderungsfenster	PKI-Administrator
Durchsetzung der Datenübertragungsrichtlinien (TLS 1.2+)	Hoch	Niedrig	Hoch, durchsetzbar über IIS und Gruppenrichtlinien-Baseline	Sicherheitsarchitekt

Wie die NDES-Sicherheit mit dem Zertifikatslebenszyklusmanagement zusammenhängt

Jedes von NDES an ein Netzwerkgerät ausgestellte Zertifikat muss weiterhin für die gesamte Lebensdauer ermittelt, verfolgt und erneuert werden. Selbst ein gehärteter NDES-Server, der Zertifikate an eine nicht nachverfolgbare Gruppe ausstellt, birgt weiterhin das gleiche Ausfallrisiko. Die DigiCert Trust Pulse Survey vom 2. Juli 2025 ergab, dass 45 % der Unternehmen im vergangenen Jahr aufgrund von Zertifikaten Ausfallzeiten erlitten, wobei 37.5 % dieser Vorfälle direkt durch abgelaufene Zertifikate verursacht wurden. Gerätezertifikate, die über NDES ausgestellt werden, stellen genau die Art von Zertifikaten dar, die aufgrund ihrer großen Anzahl und der damit verbundenen Schwierigkeit, den Überblick zu verlieren, zu dieser hohen Ausfallrate beitragen.

Zertifikatslebenszyklusmanagement-Plattformen wie CertSecure Manager erweitern die Transparenz auf alle von NDES ausgestellten Zertifikate, nicht nur auf die, die ein Administrator im Blick behält. Dadurch wird die Lücke zwischen „NDES ist gehärtet“ und „jedes ausgestellte Zertifikat ist erfasst“ geschlossen. Wenn Sie Ihre PKI-Abläufe umfassender modernisieren, erfahren Sie, wie PKI-Modernisierung und CLM zusammenwirken und wie eine kombinierte PKI- und CLM-Roadmap die Automatisierung von Gerätezertifikaten berücksichtigt, nicht nur Server- oder Benutzerzertifikate.

NDES-Sicherheit in Cloud-, Hybrid- und Multi-CA-PKI-Umgebungen

Hybridumgebungen, die die Registrierung mobiler Geräte über Intune oder ein anderes Cloud-MDM-System abwickeln, erweitern einen ehemals rein lokalen Dienst um eine Cloud-Schnittstelle. Genau deshalb sind die oben genannten Reverse-Proxy- und TLS-Kontrollen in einer Hybridbereitstellung noch wichtiger. Multi-CA-Umgebungen verschärfen die Problematik der Zertifikatvorlagen: Jede von NDES erreichbare Zertifizierungsstelle benötigt dieselben Richtlinien für Gültigkeitsbereich und Berechtigungen, nicht nur die primäre ausstellende Zertifizierungsstelle.

Für Organisationen, die NDES und die Zertifikatsausstellung in mehreren Umgebungen verwalten, zentralisiert ein PKI-as-a-Service- Modell die Härtungsgrundlagen, den Schlüsselschutz und die Überwachung, die andernfalls auf jeder NDES-Instanz separat repliziert und geprüft werden müssten.

Erfolgsmessung und was regelmäßig überprüft werden sollte

Eine gehärtete NDES-Implementierung ist kein einmaliges Projekt. Überprüfen Sie diese regelmäßig, nicht nur bei der Erstkonfiguration:

• Ob die CEP-Verschlüsselungs- und Exchange-Registrierungsagent-Vorlagen außerhalb von Konfigurations- oder Verlängerungszeiträumen noch nicht von der Zertifizierungsstelle zugewiesen sind
• Ob die Berechtigungen und die Passwortrichtlinie des NDES-Dienstkontos noch der beabsichtigten Härtungsgrundlage entsprechen
• Ob die Erzwingung von TLS 1.2+ und die Deaktivierung des HTTP-Listeners nach einem IIS- oder Windows-Update noch wirksam sind
• Ob die privaten Schlüssel weiterhin als HSM-gesichert bestätigt werden, insbesondere nach einer Servermigration oder Virtualisierungsänderung
• Ob der Reverse-Proxy vor jeder internetseitigen NDES-Instanz aktuell, gepatcht und noch im korrekten Bereich ist

Ein kryptografisches Asset-Inventar wie CBOM Secure erweitert das Maschinenidentitätsinventar und die Zertifikatserkennung auf alle von NDES ausgestellten Zertifikate und liefert so den Prüfpfad, auf dem diese wiederkehrenden Prüfungen beruhen, anstatt sich auf das institutionelle Gedächtnis darüber zu verlassen, was NDES bei der Einführung konfiguriert hatte.

Die Abstimmung des CA/Browser Forums vom 11. April 2025 zur Verkürzung der maximalen Gültigkeitsdauer von TLS-Zertifikaten – zunächst auf 200 Tage, dann auf 100 Tage und schließlich bis 2029 auf 47 Tage – betrifft zwar nicht direkt interne Gerätezertifikate wie öffentliche TLS-Zertifikate, signalisiert aber die branchenweite Entwicklung der Erwartungen an den Zertifikatslebenszyklus, insbesondere für Geräte wie die, für die NDES-Zertifikate ausgestellt werden. Das NIST finalisierte am 13. August 2024 seine ersten drei Post-Quanten-Kryptografiestandards FIPS 203, FIPS 204 und FIPS 205. Organisationen, die eine flexible Kryptografie ihrer PKI planen, sollten neben Server- und Benutzerzertifikaten auch NDES-Gerätezertifikate in ihre Planung einbeziehen. Das PQC Center of Excellence von Encryption Consulting und eine PQC-Readiness-Analyse bieten die ideale Grundlage für die Planung dieses Übergangs.

Einschätzung von Encryption Consulting

Die Härtung von NDES wird oft als Checkliste betrachtet, die einmalig bei der Ersteinrichtung abgearbeitet wird. Die wichtigsten Kontrollmechanismen – Schutz des privaten Schlüssels, ordnungsgemäße Verwaltung der Dienstkonten und Lebenszyklus der Vorlagen – verändern sich jedoch im Laufe der Zeit, da sich das Personal ändert, Server migriert werden und neue Anwendungsfälle für die Registrierung hinzukommen, ohne dass die ursprüngliche Härtungsgrundlage erneut überprüft wird. Betrachten Sie die Entscheidungsmatrix und die oben genannten Auswahlkriterien als regelmäßige Überprüfung und nicht als einmalige Maßnahme vor der Bereitstellung.

Fazit

Die Absicherung von NDES erfordert die gleichzeitige Implementierung aller oben genannten Maßnahmen: TLS-Erzwingung, Härtung von Dienstkonten, Rollentrennung, konsequente Einhaltung des Template-Lebenszyklus und vor allem HSM-gestützter Schutz privater Schlüssel. Denn ein Angreifer, der Zugriff auf einen privaten NDES-Schlüssel hat, kann ein gültiges Zertifikat anfordern, um sich als beliebiges Subjekt bei Active Directory anzumelden. Nutzen Sie die Auswahlkriterien, die Vor- und Nachteile, den Entscheidungsbaum und die Entscheidungsmatrix in diesem Leitfaden, um Prioritäten zu setzen und die Zuständigkeit für eine bestimmte Umgebung festzulegen.

Wenn Sie Hilfe bei der Absicherung Ihrer NDES-Implementierung oder Ihrer gesamten PKI-Umgebung benötigen, senden Sie uns gerne eine E-Mail an [email protected].

Häufig gestellte Fragen

Was ist die wichtigste Erkenntnis aus dem Abschnitt „Was sind die besten Sicherheitspraktiken für NDES?“.

NDES bildet die Schnittstelle zwischen nicht vertrauenswürdigen Netzwerkgeräten und einer vertrauenswürdigen Zertifizierungsstelle. Daher erfordert seine Absicherung den Schutz der privaten Schlüssel, die Verschlüsselung der gesamten Kommunikation, die Trennung der Betriebsrollen und die strikte Begrenzung der Zertifikatvorlagen. Keine einzelne Maßnahme ist allein ausreichend; die höchste Priorität hat der HSM-gestützte Schutz der privaten Schlüssel.

Warum ist das für PKI-Teams in Unternehmen wichtig?

Ein kompromittierter NDES-Server kann dazu verwendet werden, ein gültiges Zertifikat für die Anmeldung bei Active Directory als beliebiges Subjekt anzufordern. Dies macht NDES zu einem wertvollen Ziel, obwohl es oft eher als Netzwerkgerät mit niedriger Priorität denn als Tier-0-nahes Asset behandelt wird.

Welche Risiken erhöhen sich, wenn dieses Thema manuell behandelt wird?

Manuelle, undokumentierte NDES-Härtung führt dazu, dass sich die Berechtigungen der Dienstkonten und die TLS-Einstellungen nach Updates ändern, nicht zugewiesene Zertifikatvorlagen wieder aktiviert und vergessen werden und der Schutz des privaten Schlüssels nach einer Servermigration erst dann überprüft wird, wenn ein Vorfall eine Überprüfung erzwingt.

Welche Teams sollten für diese Änderung verantwortlich sein?

PKI-Administratoren sind für den Aufbau, das Servicekonto und den Lebenszyklus der Vorlagen von NDES verantwortlich. Sicherheitsarchitekten legen die Speicherung privater Schlüssel und die Serverisolation fest. Plattform- und Identitätsteams verwalten den Reverse-Proxy und die TLS-Konfiguration. Compliance- und CISO-Beauftragte überwachen die Härtung von NDES als Teil des umfassenderen PKI-Risikomanagements.

Wie hängt das mit dem Zertifikatslebenszyklusmanagement zusammen?

Jedes von NDES für ein Netzwerkgerät ausgestellte Zertifikat muss während seiner gesamten Lebensdauer weiterhin erkannt, erneuert und sein Ablaufdatum überwacht werden. Tools zur Zertifikatslebenszyklusverwaltung wie CertSecure Manager erweitern diese Überwachung auf von NDES ausgestellte Gerätezertifikate, anstatt sich auf Server- und Benutzerzertifikate zu beschränken.

Wie sollten Organisationen ihren Erfolg messen?

Erfolg bedeutet: Verifizierter HSM-gestützter Schlüsselspeicher, ein Dienstkonto, das weiterhin der beabsichtigten Härtungsgrundlage entspricht, die nach jedem Update bestätigte Durchsetzung von TLS 1.2+, die korrekte Aufhebung der Zertifikatszuweisung außerhalb von Konfigurationsfenstern und ein aktueller Reverse-Proxy für jede mit dem Internet verbundene Instanz.

Was sollte regelmäßig geprüft oder überwacht werden?

Audit-Zertifikatvorlagenzuweisung, Dienstkontoberechtigungen und Passwortrichtlinie, TLS- und HTTP-Listener-Konfiguration, Speicherort des privaten Schlüssels sowie der Patch- und Konfigurationsstatus eines etwaigen Reverse-Proxys vor NDES.

Welche Auswirkungen hat dieses Thema auf Cloud-, Hybrid- oder Multi-CA-PKI?

Hybride Bereitstellungen, die die Registrierung über ein Cloud-MDM-System leiten, schaffen eine Cloud-Schnittstelle, die Reverse-Proxy- und TLS-Kontrollen wichtiger macht, nicht weniger. In Umgebungen mit mehreren Zertifizierungsstellen (CAs) müssen die gleichen Zertifikatvorlagen und Berechtigungen für jede CA gelten, die NDES erreichen kann, nicht nur für die primäre ausstellende CA.

Welche häufigen Fehler sollten Teams vermeiden?

Vermeiden Sie es, die der Zertifizierungsstelle zugewiesenen CEP-Verschlüsselungs- und Exchange-Registrierungsagent-Vorlagen außerhalb der Einrichtung zu belassen, NDES ohne eine entsprechende Firewall-Regel zusammen mit der Zertifizierungsstelle zu platzieren, private Schlüssel in Software zu speichern, wenn ein HSM verfügbar ist, NDES ohne Reverse-Proxy direkt dem Internet auszusetzen und ein Dienstkonto auf anderen Systemen wiederzuverwenden.

Was sollte vierteljährlich aktualisiert werden?

Dieser Leitfaden ist ein stabiles, stets aktuelles Nachschlagewerk, daher erfolgt eine vollständige Inhaltsaktualisierung halbjährlich statt vierteljährlich. Zwischen den Aktualisierungen ist die vierteljährliche Aktualisierung weiterhin der richtige Rhythmus, um die betrieblichen Details zu überprüfen, die sich häufig ändern: Berechtigungen für Dienstkonten, Zuweisung von Zertifikatvorlagen, TLS-Konfiguration und Patch-Status des Reverse-Proxys.