Cyber Resilience Act (CRA) und die Software Supply Chain: Warum Nameserver ins Visier rücken

Wenn Unternehmen über IT-Sicherheit nachdenken, stehen meist Firewalls, Verschlüsselung oder der Schutz vor Phishing im Fokus. Der Gesetzgeber blickt mittlerweile jedoch deutlich tiefer in den technologischen Maschinenraum. Mit dem Cyber Resilience Act (CRA) hat die Europäische Union eine Verordnung auf den Weg gebracht, die die gesamte Software-Lieferkette (Software Supply Chain) regulatorisch erfasst. Jedes digitale Produkt - von der Firmware eines IoT-Sensors bis hin zur komplexen Cloud-Plattform, das in der EU auf den Markt gebracht wird, muss strenge Kriterien der Security by Design erfüllen.

Ein Bereich, der bei der Vorbereitung auf den CRA in vielen Architekturen sträflich vernachlässigt wird, ist das Domain Name System (DNS) und die vorgeschaltete Edge-Infrastruktur. Doch Nameserver sind keine passiven Durchlauferhitzer; sie sind das erste logische Glied der digitalen Lieferkette. Wer die Software absichert, aber die Infrastruktur, auf der sie geroutet wird, als Black-Box betreibt, riskiert im Rahmen des CRA empfindliche Sanktionen.

Der CRA und das Prinzip der transparenten Lieferkette

Der Cyber Resilience Act nimmt Hersteller und Betreiber digitaler Produkte in die Pflicht, die Sicherheit über den gesamten Lebenszyklus hinweg lückenlos zu dokumentieren. Ein zentrales Instrument hierfür ist die Software Bill of Materials (SBOM) - eine Art digitaler Beipackzettel, der jede genutzte Open-Source-Bibliothek, jede Abhängigkeit und jede Infrastruktur-Komponente bitgenau auflistet.

Im Kontext des DNS-Betriebs führt dies zu drei fundamentalen neuen Anforderungen für Unternehmen:

1. Das Ende von Black-Box-Infrastrukturen

Viele herkömmliche DNS-Anbieter betreiben geschlossene, proprietäre Systeme. Für den Kunden ist es unmöglich zu prüfen, welche Software-Versionen auf den globalen Routing-Knotenpunkten laufen und ob dort bekannte Sicherheitslücken (CVEs) existieren. Unter dem CRA müssen Infrastrukturen jedoch auditierbar sein. Wer eine kritische Anwendung betreibt, muss auch nachweisen können, dass die vorgelagerte Edge-Ebene frei von bekannten Schwachstellen ist.

2. Nachweisbare Update- und Patch-Prozesse

Der CRA fordert, dass Sicherheitslücken über den gesamten Lifecycle hinweg unverzüglich behoben werden müssen. Nutzt ein Unternehmen ein starres, proprietäres DNS-System, ist es vollkommen von den Update-Zyklen des Herstellers abhängig. Ein proaktives, eigenständiges Schwachstellen-Management an der Netzwerkgrenze ist blockiert.

3. GitOps-basierte Audit-Trails

Änderungen am Netzwerk-Routing oder an DNS-Zonen dürfen nicht mehr unprotokolliert über manuelle Klick-Oberflächen erfolgen. Der CRA verlangt eine lückenlose Nachvollziehbarkeit aller Konfigurationsschritte, um Manipulationen oder unbefugte Eingriffe in die Lieferkette (z. B. DNS-Spoofing oder unberechtigte Subdomain-Weiterleitungen) sofort forensisch aufarbeiten zu können.

Der souveräne Ansatz: Edge-Infrastruktur als auditierbares Software-Asset

Um den Anforderungen des Cyber Resilience Acts gerecht zu werden, muss die Edge-Infrastruktur (Anycast DNS, Loadbalancer, Monitoring) nach denselben strengen Sicherheitsmaßstäben behandelt werden wie die Anwendung selbst. Das gelingt durch den konsequenten Einsatz von Containerisierung, Open-Source-Standards und integrierten Security-Scans.javascript [ Edge-Infrastruktur-Code ] | v (Automatisierter Pipeline-Scan) [ CVE-Scanning & SBOM-Generierung ] | v (Kryptografische Signierung / Harbor) [ Live-Betrieb auf souveränem Anycast-Netzwerk ]

1. Kontinuierliches CVE-Scanning der Edge-Komponenten

Moderne, souveräne Edge-Plattformen werden nicht als starre Black-Box betrieben, sondern basieren auf transparenten, containerisierten Microservices. Das bedeutet: Die Software, die das Anycast-Routing und die DNS-Auflösung steuert, wird in einer privaten Container-Registry (wie Harbor) verwaltet und läuft durch dieselbe Sicherheits-Pipeline wie die eigentliche Fachanwendung. Jedes Update wird vollautomatisch auf bekannte Schwachstellen (CVEs) gescannt, bevor es auf die Nameserver ausgerollt wird.

2. Automatisierte SBOM-Generierung für das Netzwerk

Da die Plattform-Komponenten als Code definiert und paketiert sind, lässt sich für die gesamte Edge-Infrastruktur auf Knopfdruck eine präzise SBOM generieren. Im Rahmen eines offiziellen Audits kann das Unternehmen sofort dokumentieren, welche Linux-Kernel-Versionen, Routing-Protokolle (BGP) und Verschlüsselungs-Bibliotheken im Einsatz sind.

3. Signed Images und GitOps-Sicherheit

Um die Integrität der Lieferkette zu schützen, werden die Container-Images der Edge-Services digital signiert (Content Trust). Das Kubernetes -basierte Zielsystem im Rechenzentrum prüft diese Signatur vor der Ausführung. Ein Angreifer, der versucht, ein kompromittiertes Routing-Image in das System einzuschleusen, scheitert an dieser mathematischen Barriere. Jede Änderung an den DNS-Zonen selbst wird revisionssicher via GitOps im Versionskontrollsystem historisiert.

Fazit: Ohne Edge-Sicherheit keine Compliance

Der Cyber Resilience Act macht unmissverständlich klar: Ein digitales Produkt ist nur so stark wie sein schwächstes Glied in der Kette. Die Auslagerung des Datenverkehrs an intransparente Drittanbieter ohne Kontrollmöglichkeiten ist im modernen Industrie- und Konzernumfeld ein unkalkulierbares Risiko geworden. Wer digitale Souveränität ernst nimmt, muss die Hoheit über seine Edge-Infrastruktur behalten. Die Integration von Anycast DNS und Edge-Services in ein kontrollierbares, scanbares und voll dokumentiertes Software-Supply-Chain-Framework ist daher der einzig sichere Weg zur langfristigen CRA-Compliance.

FAQ: CRA & DNS-Infrastruktur

Ab wann gilt der Cyber Resilience Act verbindlich für Unternehmen?

Der CRA wurde von den EU-Institutionen verabschiedet und trat nach einer gestaffelten Übergangsphase in Kraft. Unternehmen müssen die Anforderungen an das Schwachstellen-Management, die SBOM-Generierung und die Meldepflichten für Sicherheitsvorfälle vollumfänglich erfüllen, um empfindliche Bußgelder - die ähnlich drastisch ausfallen wie bei der DSGVO - zu vermeiden.

Wer gilt im Sinne des CRA als „Hersteller" einer IT-Infrastruktur?

Als Hersteller gilt jedes Unternehmen, das Software-Produkte oder vernetzte digitale Komponenten entwickelt und unter eigenem Namen auf den Markt bringt. Nutzt ein Unternehmen jedoch eine Edge-Plattform, um eigene digitale Services (z. B. ein Kundenportal oder eine IoT-Plattform) zu betreiben, ist es im Rahmen seiner Sorgfaltspflichten dafür verantwortlich, dass die gesamte genutzte IKT-Infrastruktur den CRA-Kriterien entspricht.

Reicht es nicht aus, wenn unser DNS-Provider uns die Sicherheit vertraglich zusichert?

Nein, reine vertragliche Zusicherungen (AGBs) genügen unter den strengen Prüfkriterien des CRA oft nicht mehr, wenn es sich um kritische digitale Produkte handelt. Auditoren fordern technische Evidenzen: Sie wollen die SBOMs sehen, die dokumentierten Patch-Prozesse einsehen und die Audit-Logs der Systemkonfigurationen überprüfen können. Eine transparente Open-Source-Architektur bietet hier die notwendige datenbasierte Nachweisbarkeit.