DNS-Governance 2026: prüfungsbereite Registrar-Kontrollen

Um 07:42 Uhr an einem Montagmorgen erhält der CISO eines Fintech-Scale-ups die Nachricht, die niemand sehen möchte. Kunden können nicht auf das Zahlungsportal zugreifen, der Helpdesk ist überlastet, E-Mail funktioniert nicht, und das SOC findet weder Schadsoftware noch einen Firewall-Ausfall noch einen Vorfall beim Cloud-Anbieter.

Die Ursache ist leiser und peinlicher. Auf ein Registrar-Konto wurde mit veralteten administrativen Zugangsdaten zugegriffen, die von mehreren ehemaligen IT-Mitarbeitenden gemeinsam genutzt wurden. Der Angreifer änderte autoritative Nameserver, modifizierte MX-Einträge, deaktivierte DNSSEC und leitete den Datenverkehr lange genug um, um Zugangsdaten abzugreifen und Partner-APIs zu stören. Das Zahlungsportal wurde nicht im klassischen Sinn gehackt. Der Vertrauensanker des Unternehmens, seine Domain, wurde kompromittiert.

Um 09:30 Uhr ist aus der betrieblichen Krise eine Compliance-Krise geworden. Das Leitungsorgan fragt, ob Registry Lock aktiviert war. Die Rechtsabteilung fragt, ob personenbezogene Daten offengelegt wurden. Der DPO fragt, ob es sich um eine Verletzung des Schutzes personenbezogener Daten nach GDPR handelt. Die Aufsichtsbehörde will wissen, ob eine kritische oder wichtige Funktion betroffen war. Ein Kundenauditor verlangt das Änderungsticket, mit dem die DNS-Änderung genehmigt wurde.

Die Antwort besteht in zu vielen Organisationen aus einer Tabellenkalkulation, einem gemeinsamen Postfach und einer Registrar-Konsole, die seit sechs Monaten niemand überprüft hat.

DNS- und Domain-Registrar-Governance ist 2026 kein Nischenthema der Infrastruktur mehr. Sie ist Teil der Resilienz gegen Ransomware, der Verhinderung von Phishing-Missbrauch, der Cloud-Verfügbarkeit, des Lieferantenrisikomanagements, der Vorfallsreaktion, der Aufrechterhaltung des Geschäftsbetriebs und einer nachweisbasierten Compliance. Wenn Ihre Domain übernommen werden kann, kann Ihre SaaS-Plattform verschwinden. Wenn Ihre DNS-Einträge ohne Genehmigung geändert werden können, lassen sich E-Mail-Sicherheit, SSO, TLS-Zertifikate, API-Endpunkte und Kundenvertrauen innerhalb von Minuten untergraben.

Warum DNS- und Registrar-Governance in das ISMS gehört

Ein Domainname ist nicht nur ein Markenwert. Er ist ein logisches Asset, eine Authentifizierungsabhängigkeit, eine Routing-Abhängigkeit und häufig ein von einem Lieferanten verwalteter Dienst. Er verbindet Identitätsanbieter, E-Mail-Authentifizierung, Validierung von TLS-Zertifikaten, Cloud-Endpunkte, Kundenportale, APIs, CDN-Dienste, Monitoring-Probes und Vorfallkommunikation.

Clarysecs Richtlinie zum Asset-Management - KMU Richtlinie zum Asset-Management - KMU macht dies im Geltungsbereich ausdrücklich:

Digitale Zugangsdaten und Dienste: Domainnamen, digitale Zertifikate, API-Schlüssel, E-Mail-Konten, Cloud-Anmeldungen

Aus Abschnitt “Geltungsbereich”, Richtlinienklausel 2.2.4.

Dieselbe Richtlinie verlangt mehr als nur die Auflistung des Domainnamens:

Eigentümerschaft, Zweck, Zugriffsberechtigungen und Verlängerungsfristen müssen dokumentiert werden.

Aus Abschnitt “Anforderungen an die Umsetzung der Richtlinie”, Richtlinienklausel 6.6.2.

Für Unternehmensumgebungen umfasst Clarysecs Richtlinie zum Asset-Management Richtlinie zum Asset-Management ebenfalls logische Assets im Geltungsbereich:

Logische Assets: Domainnamen, Lizenzen, Benutzerkonten, Baseline-Konfigurationen

Aus Abschnitt “Geltungsbereich”, Richtlinienklausel 2.2.5.

Das ist der Ausgangspunkt der Governance. Ein DNS- und Registrar-Inventar sollte Folgendes dokumentieren:

• Domainname, Registry, Registrar, DNS-Hosting-Anbieter und autoritative Nameserver
• Geschäftsverantwortlicher, technischer Verantwortlicher, Sicherheitsverantwortlicher und Notfallgenehmiger
• Zweck, zum Beispiel Produktionsportal, API, E-Mail, SSO, Marketing, Testumgebung oder defensive Registrierung
• Kritikalitätsbewertung und Zuordnung der Abhängigkeiten zu Geschäftsdiensten
• DNSSEC-Status, DS-Eintragsstatus, Schlüsselverantwortung und Prozess zur Schlüsselrotation
• Status von Registry Lock und Registrar Lock
• MFA- und Privileged-Access-Modell für Konten beim Registrar und DNS-Anbieter
• Verlängerungsdatum, Status der automatischen Verlängerung, Zahlungsverantwortlicher und Ablaufwarnungen
• Anforderungen an die Änderungskontrolle für Zonenänderungen und Delegierungsänderungen
• Protokollierung, Alarmierung, Überwachung und Aufbewahrung von Nachweisen

Deshalb sollten Domain-Governance im ISMS-Geltungsbereich und in der Risikobeurteilung nach ISO/IEC 27001:2022 berücksichtigt werden. ISO/IEC 27001:2022 verlangt, dass Organisationen ihren Kontext, Anforderungen interessierter Parteien, gesetzliche und vertragliche Verpflichtungen sowie Schnittstellen und Abhängigkeiten zu externen Organisationen bestimmen. DNS hängt von Registraren, Registries, DNS-Hosting-Anbietern, Cloud-Anbietern, Zertifizierungsstellen, MSPs und mitunter Marketingagenturen ab. Werden diese Schnittstellen aus dem ISMS ausgeschlossen, ist der Prüfpfad unvollständig.

Das DNS-Bedrohungsmodell 2026

Die folgenschwersten DNS-Ausfälle sind häufig einfach:

1. Eine Domain läuft ab, weil die Verantwortung für die Verlängerung unklar war.
2. Eine frühere Agentur hat weiterhin Zugriff auf ein Registrar-Konto.
3. DNSSEC ist aktiviert, aber DS-Einträge sind nach einer Migration des DNS-Anbieters falsch.
4. Ein Wildcard-Eintrag leitet Datenverkehr an einen aufgegebenen Cloud-Dienst.
5. Ein TXT-Eintrag wird geändert, um einen vom Angreifer kontrollierten SaaS-Mandanten oder Zertifikatsantrag zu validieren.
6. MX-Einträge werden während einer Phishing- oder E-Mail-Abfangkampagne geändert.
7. Ein CNAME auf eine Drittplattform wird anfällig für eine Übernahme.
8. Registry Lock besteht für die Hauptdomain, aber nicht für kundenbezogene länderspezifische Domains.
9. Das SOC überwacht Endpunkte, aber niemand überwacht Änderungen an Zonendateien.

Die technischen Schutzmaßnahmen sind gut verstanden. DNSSEC unterstützt den Schutz der DNS-Datenintegrität und der Ursprungsauthentifizierung. Registry Lock sorgt dafür, dass risikobehaftete Änderungen auf Registry-Ebene eine zusätzliche Verifikation außerhalb des normalen Kommunikationskanals erfordern. Registrar Lock reduziert das Risiko nicht autorisierter Transfers. MFA und Berechtigungsüberprüfungen für privilegierte Zugriffe verringern die Wahrscheinlichkeit einer Kontoübernahme. Änderungskontrolle verhindert unbeabsichtigte Störungen. Überwachung erkennt nicht autorisierte oder unerwartete Änderungen.

Die Compliance-Herausforderung ist eine andere: Können Sie nachweisen, dass diese Schutzmaßnahmen existieren, verantwortet werden, überprüft werden und während eines Vorfalls funktionieren?

An dieser Nachweisfrage scheitern viele Organisationen.

Zuordnung der DNS-Governance zu ISO/IEC 27001:2022 und ISO/IEC 27002:2022

ISO/IEC 27001:2022 stellt die Managementsystemstruktur bereit, um DNS-Kontrollen in wiederholbare, auditierbare Prozesse zu überführen. ISO/IEC 27001:2022 Annex A und die Kontrollleitlinien aus ISO/IEC 27002:2022 liefern die Kontrollsprache, die Auditoren erwarten.

Clarysecs Zenith Blueprint: 30-Schritte-Roadmap für Auditoren Zenith Blueprint behandelt Netzwerkdienste als explizite Auditobjekte. In der Phase „Controls in Action“, Schritt 20, weist er Teams an, die Sicherheit von Netzwerkdiensten zu validieren:

Listen Sie alle internen und externen Netzwerkdienste auf (DNS, VPN, SMTP, DHCP, API-Gateways, usw.).

✓ Bestätigen Sie für jeden Dienst, dass sichere Protokolle verwendet werden (z. B. DNSSEC, TLS 1.2+, SSH statt Telnet). ✓ Überprüfen Sie, wie der Zugriff auf jeden Dienst kontrolliert wird (z. B. IP-Positivlisten, Authentifizierung, Zertifikate). ✓ Wenn der Dienst von Dritten verwaltet wird (z. B. DNS, SD-WAN, gehostetes VPN), prüfen Sie die Sicherheitsklauseln im SLA oder Lieferantenvertrag. Aktualisieren Sie Ihr Service-Register und vermerken Sie, wo die Sicherheits- verantwortlichkeiten liegen, intern oder extern.

Aus der Phase „Controls in Action“, Schritt 20: Kontrollen 8.18 bis 8.26.

Das ergibt einen praktikablen Auditpfad: Behandeln Sie DNS als externen Netzwerkdienst, dokumentieren Sie seine Absicherung und erfassen Sie, ob die Verantwortung intern, beim Registrar, beim DNS-Anbieter oder bei einem MSP liegt.

Clarysecs Zenith Controls: Der Cross-Compliance-Leitfaden Zenith Controls ist hilfreich, weil DNS-Governance selten nur einem Rahmenwerk zugeordnet wird. Dieselbe Entscheidung zu DNSSEC oder Registry Lock unterstützt Nachweise für ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0 und COBIT 2019.

Für Lieferantenüberwachung ordnet Zenith Controls ISO/IEC 27002:2022 Control 5.22, Überwachung, Überprüfung und Änderungsmanagement von Lieferantendiensten, als präventive Kontrolle zur Unterstützung von Vertraulichkeit, Integrität und Verfügbarkeit zu. Für DNS bedeutet das: Registrar und DNS-Anbieter sind keine Lieferanten nach dem Prinzip „einrichten und vergessen“. Ihr Risikoprofil der Informationssicherheit, Serviceänderungen, Ausfälle, Unterauftragsverarbeiter und Benachrichtigungspraktiken müssen überprüft werden.

Für DNSSEC und kryptografische Integrität ordnet Zenith Controls ISO/IEC 27002:2022 Control 8.24, Use of Cryptography, als präventive Kontrolle im Zusammenhang mit sicherer Konfiguration zu. DNSSEC ist keine Verschlüsselung des DNS-Datenverkehrs, aber eine kryptografische Zusicherung für DNS-Datenintegrität und Ursprungsauthentifizierung.

Für DNS-Zonenänderungen ordnet Zenith Controls ISO/IEC 27002:2022 Control 8.32, Change Management, als präventive Kontrolle zur Unterstützung von Vertraulichkeit, Integrität und Verfügbarkeit zu. Eine DNS-Änderung ist eine Konfigurationsänderung. Eine Aktualisierung eines DS-Eintrags, Änderung eines MX-Eintrags, CNAME-Migration, SPF- oder DMARC-Aktualisierung, CDN-Umstellung oder Änderung der Nameserver-Delegierung sollte über ein Ticket, eine Risikobeurteilung, eine Genehmigung, ein Testergebnis und einen Rollback-Plan verfügen.

DNSSEC, Registry Lock und Schlüsselmanagement für kritische Domains

Nicht jede Domain hat dasselbe Risiko. Eine defensive Domain, die nur zur Verhinderung von Identitätsnachahmung genutzt wird, benötigt möglicherweise Überwachung und disziplinierte Verlängerungsprozesse. Eine primäre Kundenportal-Domain erfordert die stärksten verfügbaren Kontrollen.

Für kritische Domains empfiehlt Clarysec typischerweise diese Baseline:

• DNSSEC aktiviert und validiert, sofern von Registry, Registrar und DNS-Anbieter unterstützt
• DS-Einträge nach jeder Migration des DNS-Anbieters überprüft
• Dokumentierter KSK- und ZSK-Rollover-Prozess, sofern Schlüssel kundenseitig verwaltet werden
• Registry Lock für primäre Produktions-, Identitäts-, API-, Zahlungs- und E-Mail-Domains aktiviert
• Registrar Lock für alle Domains aktiviert, sofern keine vorübergehende Ausnahme dokumentiert ist
• MFA für alle Benutzer beim Registrar und DNS-Anbieter durchgesetzt
• Privilegierte Benutzer eingeschränkt, personenbezogen, genehmigt und überprüft
• Break-Glass-Zugriff dokumentiert und getestet
• Zonendateiüberwachung mit Warnmeldungen bei Änderungen an NS, DS, DNSKEY, MX, TXT, A, AAAA, CNAME, CAA und Wildcards
• Externe Überwachung über mehrere Resolver und Regionen
• Nachweise im ISMS-Repository aufbewahrt

Clarysecs Richtlinie zu kryptografischen Kontrollen Richtlinie zu kryptografischen Kontrollen für Unternehmensumgebungen liefert den Governance-Anker für DNSSEC-Schlüssel:

Ein zentrales Schlüsselmanagement-Register muss geführt werden, um alle kryptografischen Schlüssel, ihren Lebenszyklusstatus, zugewiesene Verwahrer und Nutzungskontexte zu erfassen.

Aus Abschnitt “Governance-Anforderungen”, Richtlinienklausel 5.2.

Wenn Ihre Organisation DNSSEC-Schlüssel direkt verwaltet oder die DS-Veröffentlichung beim Registrar steuert, sollte das Schlüsselmanagement-Register Verwahrungsverantwortung, Lebenszyklusstatus, Rollover-Daten und Genehmigungsbefugnis dokumentieren. Verwaltet der DNS-Anbieter die DNSSEC-Schlüssel, sollte der Lieferantendatensatz diese Verantwortung erläutern und entsprechende Nachweise enthalten.

Governance des Registrar-Zugriffs: MFA, Least Privilege und Notfallkontrolle

Registrar-Konten werden häufig früh im Lebenszyklus eines Unternehmens erstellt und anschließend vergessen, während das Unternehmen reift. Gründer, Agenturen, Entwickler, Finanznutzer und MSPs können alle historischen Zugriff haben. Das ist eine erhebliche Kontrollschwäche.

Clarysecs Richtlinie zur Verwaltung von Benutzerkonten und Berechtigungen - KMU Richtlinie zur Verwaltung von Benutzerkonten und Berechtigungen - KMU legt fest:

Erhöhte oder administrative Berechtigungen erfordern eine zusätzliche Genehmigung durch den General Manager oder die IT-Leitung und müssen dokumentiert, zeitlich begrenzt und einer regelmäßigen Überprüfung unterzogen werden.

Aus Abschnitt “Anforderungen an die Umsetzung der Richtlinie”, Richtlinienklausel 6.2.2.

Wenden Sie dies unmittelbar auf den Zugriff beim Registrar und DNS-Anbieter an:

• Keine gemeinsam genutzten Registrar-Administratorkonten
• MFA für jeden Benutzer, vorzugsweise phishing-resistent, sofern unterstützt
• Benannte Notfallkontakte mit dokumentierter Befugnis
• Trennung von Abrechnungsbenutzern und technischen Administratoren, soweit möglich
• Unverzügliche Entfernung ehemaliger Mitarbeitender, Agenturen und Lieferanten
• Vierteljährliche Überprüfung privilegierter Zugriffe für kritische Domains
• Ausnahmen mit Ablaufdatum erfasst
• Getestete Verfahren zur Notfallentsperrung und Wiederherstellung, die keine unsicheren Produktionsänderungen erzeugen

Nachweise zu Registry Lock sollten Screenshots oder Registrar-Bescheinigungen enthalten, die aktivierten Status, autorisierte Kontakte, Entsperrprozess und Datum der letzten Überprüfung zeigen.

Änderungskontrolle für Zonen: kleine DNS-Änderungen, große Geschäftsauswirkungen

DNS-Änderungen wirken trügerisch klein. Ein TXT-Eintrag kann die Eigentümerschaft einer SaaS-Plattform validieren. Ein CNAME kann Kunden in eine neue Umgebung umleiten. Ein MX-Eintrag kann E-Mail-Verkehr umleiten. Ein CAA-Eintrag kann die Zertifikatsausstellung beeinflussen. Ein falscher DS-Eintrag kann dazu führen, dass eine signierte Domain bei der Validierung fehlschlägt.

Clarysecs Änderungsmanagement-Richtlinie - KMU Änderungsmanagement-Richtlinie - KMU legt fest:

Alle Änderungen müssen als Änderungsantrag eingereicht werden (E-Mail, Formular oder Helpdesk-Ticket).

Aus Abschnitt “Governance-Anforderungen”, Richtlinienklausel 5.1.1.

Für Unternehmenskunden erhöht Clarysecs Änderungsmanagement-Richtlinie Änderungsmanagement-Richtlinie die Nachweiserwartung:

Alle Änderungsanträge, Überprüfungen, Genehmigungen und unterstützenden Nachweise müssen im zentralen Änderungsmanagementsystem erfasst werden.

Aus Abschnitt “Anforderungen an die Umsetzung der Richtlinie”, Richtlinienklausel 6.1.1.

Der Zenith Blueprint bekräftigt dies in der Phase „Controls in Action“, Schritt 21:

Wählen Sie 2–3 aktuelle System- oder Konfigurationsänderungen aus und prüfen Sie, ob sie über Ihren formalen Änderungsmanagement-Workflow verarbeitet wurden.

✓ Wurden Risiken beurteilt? ✓ Wurden Genehmigungen dokumentiert? ✓ War ein Rollback-Plan enthalten?

Validieren Sie, dass die Änderungen wie geplant umgesetzt wurden und dass alle Vorfälle oder unerwarteten Auswirkungen erfasst wurden. Überprüfen Sie Protokolle, Versionskontroll-Diffs oder Prüfpfade aus Werkzeugen wie ServiceNow, Jira oder Git. Erfassen Sie diesen Prozess in einem Change Record Summary Log als Audit- Referenz.

Aus der Phase „Controls in Action“, Schritt 21: Kontrollen 8.27 bis 8.34.

Ein DNS-spezifisches Änderungsticket sollte die betroffene Domain und Zone, den Eintragstyp, Vorher- und Nachher-Werte, geschäftliche Begründung, Risikobeurteilung, Umsetzungsfenster, Genehmiger, ausführende Person, Prüfer, DNS-Propagationsprüfungen, DNSSEC-Validierung, Rollback-Plan, Überwachung nach der Änderung und exportierte Nachweise enthalten.

Das Auditprinzip ist einfach: DNS-Änderungen müssen vom Antrag über die Genehmigung und Umsetzung bis zur Verifikation nachvollziehbar sein.

Überwachung und Protokollierung: DNS-Änderungen erkennen, bevor Kunden sie bemerken

Ein starkes DNS-Governance-Programm geht davon aus, dass Prävention fehlschlagen kann. Überwachung muss unerwartete Änderungen schnell genug erkennen, um die Vorfallsreaktion zu unterstützen.

Clarysecs Netzwerksicherheitsrichtlinie - KMU Netzwerksicherheitsrichtlinie - KMU ist eindeutig:

DNS-Protokollierung muss aktiviert sein, um Threat Hunting und Incident Response zu unterstützen

Aus Abschnitt “Anforderungen an die Umsetzung der Richtlinie”, Richtlinienklausel 6.6.3.

Die Richtlinie zur Protokollierung und Überwachung Richtlinie zur Protokollierung und Überwachung für Unternehmensumgebungen beginnt mit derselben operativen Erwartung:

Alle erfassten Systeme müssen Protokolle erzeugen, die Folgendes erfassen:

Aus Abschnitt “Anforderungen an die Umsetzung der Richtlinie”, Richtlinienklausel 6.1.1.

Für DNS- und Registrar-Governance sollten die erfassten Systeme Registrar-Portale, DNS-Hosting-Konsolen, API-basiertes DNS-Management, CI/CD-Pipelines für DNS as Code, SIEM-Warnmeldungen und externe Überwachungswerkzeuge umfassen.

Überwachung sollte in die Vorfallsreaktion integriert sein. Eine DNS-Warnmeldung ohne Verantwortlichen, Schweregradbewertung oder Runbook ist nur Rauschen.

NIS2, DORA und GDPR: DNS-Governance als regulatorischer Nachweis

NIS2 Article 21 verlangt geeignete und verhältnismäßige technische, operative und organisatorische Maßnahmen zur Steuerung von Risiken für Netzwerk- und Informationssysteme und zur Minimierung der Auswirkungen von Vorfällen. DNS-Governance lässt sich unmittelbar auf Asset-Management, Zugriffskontrolle, Kryptografie, Sicherheit der Lieferkette, Verfahren zum Umgang mit Informationssicherheitsvorfällen, Aufrechterhaltung des Geschäftsbetriebs und Wirksamkeitsbewertung abbilden.

NIS2 Article 20 macht Cybersicherheit außerdem zur Verantwortung des Leitungsorgans. Leitungsorgane müssen nicht jeden TXT-Eintrag genehmigen, sollten aber verstehen, ob kritische Domains durch DNSSEC, Registry Lock, MFA, Überwachung und getestete Wiederherstellung geschützt sind. Für erhebliche Vorfälle führt NIS2 Article 23 gestufte Meldungen ein, einschließlich Frühwarnung innerhalb von 24 Stunden, Vorfallmeldung innerhalb von 72 Stunden und Abschlussbericht spätestens einen Monat nach der Vorfallmeldung.

Für regulierte Finanzunternehmen gilt DORA seit dem 17. Januar 2025 und wirkt als sektorspezifisches Rahmenwerk für IKT-Resilienz, soweit es sich mit NIS2 überschneidet. DNS unterstützt häufig kritische oder wichtige Funktionen wie Zahlungsanwendungen, Mobile Banking, Handelsportale, Kundenidentität, Betrugserkennungssysteme, API-Gateways und Drittintegrationen. Nachweise nach DORA sollten IKT-Asset-Abhängigkeitskartierung, Vorfallklassifizierung, Resilienztests, Drittparteienrisikomanagement und Wiederherstellungsplanung für DNS- und Registrar-Ausfallszenarien zeigen.

Ein DNS-Vorfall ist nicht automatisch eine Verletzung des Schutzes personenbezogener Daten nach GDPR. Er kann dazu werden, wenn Benutzer auf eine Phishing-Seite umgeleitet werden, Zugangsdaten abgegriffen werden, E-Mails mit personenbezogenen Daten umgeleitet werden, Datenverkehr zu Systemen zur Verarbeitung personenbezogener Daten abgefangen wird oder die Verfügbarkeit personenbezogener Daten wesentlich beeinträchtigt wird. GDPR Article 5 verlangt Integrität, Vertraulichkeit und Rechenschaftspflicht. Article 32 verlangt geeignete Sicherheitsmaßnahmen für die Verarbeitung. DNS-Governance liefert Nachweise, dass Domain-Routing und DNS-abhängige Dienste durch verhältnismäßige technische und organisatorische Maßnahmen geschützt sind.

Ein DNS-Nachweispaket in einer Woche erstellen

Ein praktischer Maßnahmenplan zur DNS-Governance kann schnell umgesetzt werden, wenn er nachweisorientiert ist.

Tag 1: Domain- und DNS-Service-Register erstellen

Beginnen Sie mit der Anforderung aus der Richtlinie zum Asset-Management - KMU, Eigentümerschaft, Zweck, Zugriffsberechtigungen und Verlängerungsfristen zu dokumentieren.

Tag 2: Zugriff und Berechtigungen überprüfen

Exportieren Sie Benutzer beim Registrar und DNS-Anbieter. Entfernen Sie veraltete Konten. Erzwingen Sie MFA. Identifizieren Sie Administratoren. Erfassen Sie Genehmigungsnachweise für privilegierte Benutzer und dokumentieren Sie Notfallzugriff.

Tag 3: DNSSEC und Locks validieren

Überprüfen Sie für jede kritische Domain die DNSSEC-Kettenvalidierung, Richtigkeit der DS-Einträge, Sichtbarkeit von DNSKEY, Registrar Lock und Registry Lock. Wenn DNSSEC durch den Anbieter verwaltet wird, dokumentieren Sie die Verantwortung des Anbieters. Wenn DNSSEC kundenseitig verwaltet wird, ergänzen Sie DNSSEC-Schlüssel und Verwahrer im Schlüsselmanagement-Register.

Tag 4: DNS-Änderungen in formale Änderungsaufzeichnungen überführen

Wählen Sie die letzten drei DNS-Änderungen aus und prüfen Sie sie gegen die Kriterien aus Zenith Blueprint Schritt 21: Risiko beurteilt, Genehmigung dokumentiert, Rollback-Plan enthalten, wie geplant umgesetzt und unerwartete Auswirkungen erfasst. Erstellen Sie ein Change Record Summary Log.

Tag 5: Überwachung mit Vorfallsreaktion verbinden

Bestätigen Sie Protokolle und Warnmeldungen für Registrar-Anmeldungen, Zonenänderungen, DNSSEC-Änderungen, NS-Änderungen, MX-Änderungen, TXT-Änderungen, CAA-Änderungen und Anbieterbenachrichtigungen. Senden Sie Testwarnmeldungen an das SOC oder den IT-Verantwortlichen. Hängen Sie die Nachweise an das ISMS-Repository an.

Tag 6: Lieferantenverpflichtungen überprüfen

Nutzen Sie die Anleitung aus Zenith Blueprint Schritt 23 zu Verfahren für Lieferantenänderungen und Überwachung:

Etablieren Sie ein einfaches, skalierbares Verfahren zur Bewertung von Änderungen an Lieferantendiensten (5.21), wie Migration in die Cloud, neue Unterauftragsverarbeiter oder Neugestaltung der Infrastruktur. Definieren Sie Auslöser, die eine erneute Sicherheitsbewertung erfordern. Implementieren Sie anschließend einen wiederkehrenden Rhythmus für die Lieferantenüberwachung (5.22), weisen Sie kritischen Lieferanten Verantwortliche zu und stellen Sie sicher, dass Leistung, Einhaltung und Risiken mindestens jährlich überprüft werden.

Aus der Phase „Controls in Action“, Schritt 23: Organisatorische Maßnahmen 5.19 bis 5.37.

Clarysecs Richtlinie zur Lieferanten- und Drittparteiensicherheit Richtlinie zur Lieferanten- und Drittparteiensicherheit für Unternehmensumgebungen liefert den vertraglichen Anker:

Verträge mit Lieferanten müssen Folgendes enthalten:

Aus Abschnitt “Governance-Anforderungen”, Richtlinienklausel 5.3.

Tag 7: Tabletop-Übung durchführen

Simulieren Sie eine nicht autorisierte Änderung eines NS-Eintrags. Das Team muss sie erkennen, klassifizieren, eskalieren, den Registrar kontaktieren, bei Bedarf Registry-Lock-Verfahren auslösen, die korrekte Delegierung wiederherstellen, DNSSEC validieren, Interessenträger benachrichtigen, die GDPR-Auswirkungen bewerten und entscheiden, ob Meldeschwellen nach NIS2 oder DORA erreicht sind. Erfassen Sie Lessons Learned und aktualisieren Sie die Verfahren.

Auditfragen, typische Feststellungen und Kennzahlen für das Leitungsorgan

Ein DNS-Governance-Audit wird selten nur aus einer Perspektive durchgeführt.

Die häufigsten Feststellungen sind vorhersehbar.

Leitungsorgane und Managementteams benötigen DNS-Kennzahlen in Resilienzsprache. Sinnvolle Messgrößen sind der Anteil kritischer Domains mit aktiviertem und validiertem DNSSEC, der Anteil mit Registry Lock, die Anzahl der Registrar-Administratoren, der Anteil privilegierter Benutzer, die im letzten Quartal überprüft wurden, die Anzahl der ohne formale Tickets umgesetzten DNS-Änderungen, Mean Time to Detect für nicht autorisierte DNS-Änderungen, Mean Time to Restore der korrekten DNS-Konfiguration, Domains mit Ablauf innerhalb von 90 Tagen, abgeschlossene Lieferantenüberprüfungen und offene DNS-Überwachungswarnmeldungen.

DNS von einem verborgenen Risiko in prüfungsbereite Nachweise überführen

Wenn Ihre Organisation Domain- und DNS-Governance in den letzten sechs Monaten nicht überprüft hat, sollten Sie von Abweichungen ausgehen. Beginnen Sie mit kritischen Produktionsdomains und erweitern Sie anschließend auf regionale Domains, defensive Domains, Testdomains, Akquisitionsdomains sowie Domains, die von Agenturen oder Tochtergesellschaften verwaltet werden.

Clarysec kann Sie dabei unterstützen, verstreute Registrar-Screenshots in ein strukturiertes Nachweispaket zu überführen, mit:

• Zenith Blueprint: 30-Schritte-Roadmap für Auditoren Zenith Blueprint zur schrittweisen Validierung von Netzwerkdiensten, Änderungsmanagement, Protokollierung, Überwachung und Lieferantenkontrollen
• Zenith Controls: Der Cross-Compliance-Leitfaden Zenith Controls zur Zuordnung von DNSSEC, Registry Lock, Lieferantenüberwachung und Governance für Zonenänderungen über ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST und COBIT 2019 hinweg
• Clarysec-Richtlinienvorlagen, einschließlich Richtlinie zum Asset-Management - KMU, Änderungsmanagement-Richtlinie - KMU, Richtlinie zur Verwaltung von Benutzerkonten und Berechtigungen - KMU, Netzwerksicherheitsrichtlinie - KMU, Richtlinie zum Asset-Management, Änderungsmanagement-Richtlinie, Richtlinie zur Protokollierung und Überwachung, Richtlinie zu kryptografischen Kontrollen und Richtlinie zur Lieferanten- und Drittparteiensicherheit

Ihre Domain ist die Eingangstür zu Ihrem digitalen Geschäft. Im Jahr 2026 werden Auditoren, Aufsichtsbehörden, Kunden und Leitungsorgane erwarten, dass Sie nachweisen können, dass diese Eingangstür verschlossen, überwacht, wiederherstellbar und gesteuert ist.

Laden Sie das Clarysec-Toolkit herunter, führen Sie die einwöchige Übung zum DNS-Nachweispaket durch oder buchen Sie eine Clarysec-Bewertung, um DNS- und Registrar-Governance in prüfungsbereite Nachweise zu überführen, bevor Ihre eigene Krise an einem Montagmorgen beginnt.