Die Rolle des DNS bei der Absicherung kritischer Infrastrukturen (NIS-2 & Compliance)

Die europäische Cybersicherheits-Richtlinie NIS-2 (Network and Information Security) hat den Kreis der regulierten Unternehmen drastisch erweitert. Betrafen die alten KRITIS-Regelungen fast ausschließlich Großkonzerne aus den Bereichen Energie und Wasserversorgung, fallen unter NIS-2 nun zehntausende mittelständische Betriebe und Zulieferer ab 50 Mitarbeitern in die Pflicht. Wer die strengen Vorgaben ignoriert, haftet im Ernstfall als Geschäftsführer persönlich und riskiert empfindliche Bußgelder im siebenstelligen Bereich.

Bei der Umsetzung der geforderten Risikomanagement-Maßnahmen (Artikel 21 NIS-2) konzentrieren sich IT-Abteilungen meist auf offensichtliche Schutzmaßnahmen wie Patch-Management, Firewalls und Multi-Faktor-Authentifizierung (MFA). Eine elementare Komponente wird bei Audits jedoch regelmäßig als gravierende Schwachstelle identifiziert: das Domain Name System (DNS). Als Bindeglied zu allen digitalen Diensten gilt das DNS unter NIS-2 als „wesentlicher Dienst für das Funktionieren der Wirtschaft und Gesellschaft". Wer seine Nameserver-Infrastruktur nicht resilient aufbaut, gefährdet die Compliance der gesamten nachgelagerten IT-Landschaft.

Warum das DNS im NIS-2-Audit im Rampenlicht steht

NIS-2 fordert von betroffenen Einrichtungen ein proaktives Risikomanagement zur Bewältigung von Cybersicherheitsrisiken sowie die Gewährleistung der Betriebskontinuität (Business Continuity Management / BCM). Das DNS ist hierbei die Achillesferse der digitalen Infrastruktur.

Aus Sicht eines IT-Auditors ergeben sich bei klassischen, gewachsenen DNS-Strukturen drei fundamentale Compliance-Risiken:

1. Verletzung der Pflicht zur Ausfallsicherheit und Redundanz

Wer seine DNS-Zonen bei einem Standard-Hoster ohne Anycast-Routing betreibt, verstößt strukturell gegen das NIS-2-Gebot der Resilienz. Fällt der Nameserver durch eine lokale Störung aus, bricht die Erreichbarkeit kritischer Systeme (wie VPN-Zugänge, E-Mail-Kommunikation oder IoT-Leitstände) sofort zusammen. Ein „Best Effort"-Betrieb reicht für wichtige Einrichtungen nicht mehr aus; Redundanz muss auf Netzwerkebene mathematisch nachweisbar sein.

2. Fehlende Transparenz in der Supply Chain (Lieferkettensicherheit)

NIS-2 nimmt die Sicherheit der Lieferketten explizit ins Visier. Unternehmen müssen nachweisen können, welche Drittanbieter und welche Softwarekomponenten an geschäftskritischen Prozessen beteiligt sind. Wer das DNS und das globale Traffic-Routing an intransparente Black-Box-Systeme ausländischer Drittstaaten auslagert, kann die Integrität seiner Lieferkette gegenüber den Behörden (wie dem BSI) oft nicht lückenlos belegen.

3. Unzureichende Fähigkeiten zur Incident Response und Protokollierung

Ein Kernpfeiler von NIS-2 ist die Pflicht zur Meldung von erheblichen Sicherheitsvorfällen innerhalb von 24 Stunden. Wenn Angreifer versuchen, die Namensauflösung durch DNS-Spoofing oder DDoS-Attacken zu manipulieren, muss das Unternehmen den Vorfall sofort erkennen und forensisch aufarbeiten können. Klassische DNS-Interfaces ohne granulare Echtzeit-Metriken und GitOps-Audit-Trails machen diese geforderte lückenlose Nachweisbarkeit unmöglich.

Die Lösung: Das NIS-2-konforme Nameserver-Design

Um die Nameserver-Infrastruktur prüfungssicher und hochverfügbar zu gestalten, müssen Unternehmen die DNS-Ebene als integralen Bestandteil ihres Informationssicherheits-Managementsystems (ISMS) betrachten. Ein NIS-2-ready Design stützt sich auf drei technologische Säulen:

[ NIS-2 Richtlinie / ISMS ]
                                  |
         +------------------------+------------------------+
         |                        |                        |
         v                        v                        v
[ Anycast-Infrastruktur ]   [ Multi-Provider-Sync ]   [ Revisionssicheres IaC ]
 (Geo-Resilienz & DDoS)      (Keine Provider-Monopole)  (Lückenloser Audit-Trail)

1. Geografische Resilienz via Anycast

Durch den Einsatz eines europäischen Anycast-Netzwerks wird die Verfügbarkeit der Namensauflösung auf das geforderte Maximum gehoben. Da DNS-Anfragen automatisch zum netzwerktechnisch nächsten Point of Presence (PoP) geleitet werden, fängt die Architektur den Ausfall einzelner Standorte oder massive DDoS-Angriffe lokal ab. Das Gesamtsystem heilt sich selbst und garantiert die geforderte Betriebskontinuität.

2. Multi-Provider-DNS zur Eliminierung von Konzentrationsrisiken

Um die von NIS-2 geforderte Unabhängigkeit in der Lieferkette zu wahren, empfiehlt sich eine automatisierte Multi-Provider-Strategie. Die DNS-Zonen werden zentral auf einer souveränen, internen Plattform verwaltet und vollautomatisch mit mehreren, voneinander unabhängigen externen Nameserver-Betreibern synchronisiert. Selbst der theoretische Totalausfall eines globalen Providers beeinträchtigt die Erreichbarkeit der kritischen Systeme zu keinem Zeitpunkt.

3. Infrastructure as Code (IaC) für lückenlose Audits

Änderungen an DNS-Zonen und Routing-Regeln werden nicht mehr unprotokolliert per Hand vorgenommen, sondern konsequent als Code (z. B. via Terraform) im Git-Repository definiert. Jeder Commit erzeugt einen manipulationssicheren, zeitgestempelten Audit-Trail. Interne Prüfer und externe Auditoren können auf Knopfdruck nachweisen, wer wann welche Netzwerkkonfiguration vorgenommen hat.

Fazit: Resilienz beginnt an der Netzwerkwurzel

Der Cyber Resilience Act, DORA und insbesondere NIS-2 machen unmissverständlich klar: Cybersicherheit ist eine ganzheitliche Aufgabe, die nicht erst auf Anwendungsebene beginnt. Das DNS ist das logische Fundament jeder digitalen Interaktion im Unternehmen. Wer hier auf veraltete Unicast-Topologien oder intransparente Drittstaaten-Lösungen setzt, baut seine Sicherheitsarchitektur auf sandigem Boden. Die Migration zu einer souveränen, Anycast-basierten und via GitOps automatisierten DNS-Infrastruktur ist daher kein rein technisches Upgrade, sondern eine fundamentale regulatorische Notwendigkeit, um die Zukunftsfähigkeit und Compliance kritischer Geschäftsprozesse nachhaltig abzusichern.

FAQ: NIS-2 & DNS-Praxis

Ab wann müssen Unternehmen die NIS-2-Vorgaben zwingend umsetzen?

Die NIS-2-Richtlinie wurde von den EU-Mitgliedstaaten in nationales Recht umgesetzt (in Deutschland durch das NIS-2-Umsetzungs- und Cybersicherheitsstärkungsgesetz - NIS2UmsuCG). Betroffene Unternehmen, die als „wesentliche" oder „wichtige" Einrichtungen klassifiziert sind, müssen die strengen Sicherheitsanforderungen und Meldepflichten vollumfänglich erfüllen. Bei Verstößen drohen bereits empfindliche Sanktionen.

Welche Rolle spielt DNSSEC im Kontext von NIS-2?

DNSSEC (Domain Name System Security Extensions) ist ein unverzichtbarer Baustein zur Erfüllung der NIS-2-Anforderungen an die Integrität von Datennetzwerken. Durch die kryptografische Signierung der DNS-Einträge wird sichergestellt, dass die Antwort des Nameservers auf dem Weg zum Client nicht manipuliert werden kann (DNS-Spoofing oder Man-in-the-Middle-Angriffe). Eine NIS-2-konforme Edge-Plattform sollte DNSSEC daher nativ und ohne komplexen manuellen Schlüssel-Overhead im Hintergrund verwalten.

Können wir für das DNS weiterhin die Standard-Nameserver unseres Domain-Registrars nutzen?

Rein rechtlich verbietet NIS-2 die Nutzung von Standard-Nameservern nicht pauschal. Allerdings fordert die Richtlinie eine angemessene Risikoanalyse. Wenn ein einfacher Ausfall des Nameservers Ihres Registrars dazu führt, dass Ihre Produktion stillsteht, Ihre Logistikketten abreißen oder kritische Kundenportale offline gehen, wird diese unzureichende Redundanz in jedem professionellen Audit bemängelt. Die Migration zu einer dedizierten, hochverfügbaren Anycast- und Multi-Provider-Architektur ist der einzig sichere Weg, um dieses Risiko regulatorisch sauber zu schließen.