B3S Housing, Hosting und CDN: der Nachweisweg für Rechenzentren, Serverfarmen und Content Delivery Netzwerke

Problem in der Praxis

Anbieter in diesem Sektor arbeiten in Ketten. Ein CDN nutzt Serverfarmen, die in fremden Rechenzentren stehen, deren Stromversorgung wieder von Dritten kommt. Die naheliegende Reaktion, sich auf den Vertrag mit dem Vorlieferanten zu berufen, greift zu kurz: Der Standard verlangt, dass die Verantwortung für den Stand der Technik auch bei Auslagerung beim Betreiber der kritischen Infrastruktur bleibt und dass Prüfmöglichkeiten nach der Bedeutung der jeweiligen Dienstleistung vorgesehen werden.

Die zweite Schwierigkeit ist die Trennung der Verantwortungsbereiche zum Kunden hin. Im Housing gehört die Kundenhardware dem Kunden, im Hosting die Kundenumgebung. Der Standard verlangt an beiden Stellen eine klare technische und organisatorische Trennung und, im Housing, ein Monitoring der Gebäudeleittechnik, deren Systeme von den Kundensystemen vollständig getrennt sein müssen.

Die dritte betrifft den Umfang. Das Dokument ist mit 107 Seiten das längste der sechs B3S, die für diesen Aufsatz beschafft und im Bezugs- und Bestandsregister erfasst sind, und sein Anhang zur Angriffserkennung trägt auf den Seiten 85 bis 99 allein 71 einzeln nummerierte Anforderungen. Wer den Aufwand am Umfang der Kapitel 2 bis 4 schätzt, unterschätzt ihn.

CISO-Einordnung

Der Standard erklärt seine Modalverben selbst, in Großbuchstaben und mit eigener Definition. "MUSS" heißt unbedingt zu erfüllen, wobei eine gleichwertige Alternative zulässig ist, sofern ihre Gleichwertigkeit belegt und die Begründung nachvollziehbar festgehalten wird. "SOLL" und "SOLLTE" heißen, dass die Anforderung normalerweise zu erfüllen ist; wer abweicht, muss das Risiko abwägen, die Abweichung und ihre Akzeptanz nachvollziehbar dokumentieren und, soweit möglich, Ersatzmaßnahmen umsetzen. Die Ersatzmaßnahme ist dabei keine Alternative zur Dokumentation, sondern kommt hinzu. Eine Empfehlung im landläufigen Sinn ist das nicht. Auf RFC 2119 beruft sich das Dokument nicht, und die Großschreibung allein trägt die Einordnung nicht: Im Anhang zur Angriffserkennung steht die Stufe in einer eigenen Rangspalte, und es gibt Zeilen, deren Fließtext ein klein geschriebenes Modalverb führt, während die Rangspalte SOLLTE ausweist. Wer den Pflichtenbestand bestimmen will, liest deshalb die Rangspalte und nicht die Schreibweise.

Inhaltlich zerfällt das Dokument in vier Teile. Kapitel 2 trägt die anlagenübergreifenden Anforderungen: ISMS, Asset Management, Kontinuitätsmanagement, technische Informationssicherheit, personelle und bauliche Sicherheit, Vorfallerkennung, Überprüfung im laufenden Betrieb, Lieferkette, Meldewesen und Angriffserkennung. Kapitel 3 vertieft Housing, Kapitel 4 Hosting und CDN. Der Anhang bringt Themenlisten, die elementaren Gefährdungen und die Anforderungen zur Angriffserkennung.

Beim ISMS ist eine Formulierung wichtig, die oft überlesen wird: Ein bestehendes Unternehmens-ISMS genügt ausdrücklich, wenn sein Geltungsbereich die für die kritische Dienstleistung relevanten Prozesse und Systeme umfasst. Der Standard verlangt kein zweites ISMS neben dem vorhandenen.

Die dreizehn Mapping-Tabellen in Kapitel 2.4 sind eine echte Erleichterung. Sie nennen je Thema die einschlägigen Stellen anderer Werke, meist Kapitel der ISO/IEC 27002 und Kriterien des BSI C5, bei manchen Themen zusätzlich BSI-Standards; eine durchgängige Dreifachzuordnung ist es nicht. Wer bereits nach C5 testiert oder nach ISO zertifiziert ist, sieht daran unmittelbar, welche Arbeit wiederverwendbar ist. Die Tabellen ordnen allerdings Themen zu, nicht einzelne Pflichten; sie ersetzen die Prüfung der B3S-Anforderung nicht.

Eine dritte Bezugsquelle übersieht man dabei leicht, obwohl die Tabellen sie mitführen: die Durchführungsverordnung (EU) 2024/2690, dort mit den einschlägigen Kapiteln ihres Anhangs. Dasselbe Kapitel verlangt ihre Umsetzung bei der Ausgestaltung der Themen aus Artikel 21 Absatz 2 der NIS-2-Richtlinie. Wer vorhandene ISO- oder C5-Arbeit wiederverwendet, gleicht sie also gegen drei Bezugswerke ab, nicht gegen zwei.

Umsetzungsperspektive

Der erste Schritt ist die Bestimmung der eigenen Rolle in der Kaskade. Wer nur Housing anbietet, arbeitet mit Kapitel 2 und 3. Wer hostet, kommt um die für ihn relevanten Housing-Anforderungen nicht herum, auch wenn er kein eigenes Rechenzentrum betreibt. Diese Feststellung gehört an den Anfang, weil sie den Umfang bestimmt.

Der zweite Schritt ist der Geltungsbereich mit Netzstrukturplan. Der Standard verlangt für Housing ausdrücklich, die Versorgung mit Strom, IT-Netz und Internet, die Kühlung im Zusammenspiel von Kühl- und Steuerungssystemen sowie die Betriebssicherheit einschließlich Brandvermeidung, Löschanlagen, unterbrechungsfreier Stromversorgung und Meldesystemen textlich und grafisch darzustellen. Für Hosting und CDN verweist er dafür auf die Grundsätzlichen Anforderungen im Nachweisverfahren des BSI.

Der dritte Schritt ist die Angriffserkennung. Ihre 71 Anforderungen gliedern sich in vier Gruppen: allgemeine Rahmenbedingungen, Protokollierung, Detektion und Reaktion. Die Reihenfolge ist auch die sinnvolle Umsetzungsreihenfolge. Von den 71 Zeilen weist die Rangspalte 43 als MUSS und 28 als SOLLTE aus; die SOLLTE-Zeilen sind zusätzlich an der Endung ihrer Kennung erkennbar. SOLLTE heißt hier nicht freigestellt: Die Anforderung ist normalerweise zu erfüllen, eine Abweichung kostet Risikoabwägung und Dokumentation, und wo Ersatzmaßnahmen möglich sind, müssen sie umgesetzt werden. Einzelne SOLLTE-Zeilen tragen im Text sogar eine eigene MUSS-Bedingung: Bei der automatischen Reaktion auf erkannte Angriffe etwa muss gewährleistet sein, dass automatisiert ergriffene Maßnahmen die kritische Dienstleistung nicht relevant beeinträchtigen können.

Typische Fehler

1. Ein Hosting- oder CDN-Anbieter beschränkt sich auf sein eigenes Kapitel und übergeht die für ihn einschlägigen Anforderungen der vorgelagerten Bereiche.
2. Die Auslagerung an einen Vorlieferanten wird als Übergang der Verantwortung behandelt, obwohl der Standard sie beim Betreiber belässt.
3. Ein zweites ISMS wird aufgebaut, obwohl ein bestehendes mit passendem Geltungsbereich ausdrücklich genügt.
4. Der Anhang zur Angriffserkennung wird als Referenzmaterial gelesen statt als Anforderungskatalog mit 71 Einträgen.
5. Die Mapping-Tabellen werden als Nachweis verwendet, obwohl sie Themen und keine einzelnen Pflichten zuordnen.

Risiken und Trade-offs

Die Kaskade über drei Bereiche erzeugt Mehrarbeit, aber sie bildet die Wirklichkeit ab: Ein Ausfall der Kühlung trifft den Hoster genauso wie den Rechenzentrumsbetreiber. Der Trade-off besteht darin, dass ein Anbieter Anforderungen nachweisen muss, deren Umsetzung bei einem Dritten liegt. Dafür braucht er Einblick in die Leistung des Dritten. Das Dokument verlangt Prüfmöglichkeiten nach der Bedeutung der bezogenen Leistung und nennt die Vereinbarung von Auditrechten als SOLLTE-Anforderung neben anderen Überprüfungswegen, etwa Berichten und Zertifikaten. Welche Form trägt, entscheidet der Betreiber; dass sie vor dem Nachweis geklärt sein sollte, ist die Empfehlung dieses Aufsatzes.

Der zweite Trade-off liegt in der Mandantentrennung. Je stärker geteilte Infrastruktur genutzt wird, desto günstiger der Betrieb und desto aufwendiger der Nachweis der Trennung. Der Standard nennt organisatorische und technische Mechanismen nebeneinander; welche angemessen sind, hängt von der Art der Dienstleistung ab und ist zu begründen.

Entscheidungspunkte

• Welche der drei Rollen nimmt der eigene Betrieb ein, und welche vorgelagerten Anforderungen folgen daraus?
• Deckt der Geltungsbereich eines vorhandenen ISMS die kDL-relevanten Prozesse und Systeme ab, oder muss er erweitert werden?
• Welche Prüfrechte gegenüber Vorlieferanten bestehen, und reichen sie für den eigenen Nachweis?
• Wie wird die Trennung der Kundenumgebungen belegt, organisatorisch, technisch oder beides?

Praktische Empfehlungen

Zeichnen Sie den Netzstrukturplan so, dass die vier Versorgungsstränge Strom, Netz, Internet und Kühlung sichtbar sind und die Gebäudeleittechnik als eigener Bereich erscheint. Das ist eine Empfehlung dieses Aufsatzes, keine Vorgabe des Standards: Der B3S verlangt eine anlagenspezifische Darstellung und zählt dafür auf, was sie zeigen muss, darunter Kundenmanagement, Mandantentrennung, Zugangssicherheit und Schnittstellen; für Hosting und CDN gilt ein eigener Katalog solcher Inhalte, und die Grafik im Dokument ist ausdrücklich unverbindlich. Die vorgeschlagene Zeichnung beantwortet aber einen Großteil der Fragen zur baulichen Sicherheit.

Nutzen Sie die Mapping-Tabellen für die Bestandsaufnahme, nicht für den Nachweis. Sie zeigen zuverlässig, wo vorhandene C5- oder ISO-Arbeit anschlussfähig ist, und sparen damit die teuerste Phase, die Suche nach dem Vorhandenen.

Planen Sie die Angriffserkennung als eigenes Vorhaben mit vier Meilensteinen entlang der Gruppen des Anhangs. Die Protokollierung ist der Engpass: Ohne vollständige Datenquellen sind Detektion und Reaktion nicht belegbar.

Relevante Normreferenzen

• Branchenspezifischer Sicherheitsstandard für Housing, Hosting und CDN, Version 3.0 vom 24.7.2025, erarbeitet im UP KRITIS, Branchenarbeitskreis Datacenter und Hosting. BSI-Eignungsfeststellung nach dem früheren § 8a Absatz 2 BSIG. Das Dokument nennt die Frist selbst: Feststellungsbescheid vom 2.10.2025, Gültigkeit bis zum 1.10.2028. Die BSI-Detailseite zu diesem B3S weist denselben Ablauf aus (https://www.bsi.bund.de/SharedDocs/Textbausteine/DE/KRITIS/B3S/IT_TK/b3s-it-tk.html, abgerufen am 17.9.2026).
• BSI-Gesetz in der Fassung des NIS2-Umsetzungs- und Cybersicherheitsstärkungsgesetzes: Betreiberpflichten, Nachweispflicht und die gesetzliche Pflicht zu Systemen zur Angriffserkennung.
• Verordnung zur Bestimmung Kritischer Infrastrukturen (BSI-KritisV): Anlagenkategorien Rechenzentrum, Serverfarm und Content Delivery Netzwerk.
• Durchführungsverordnung (EU) 2024/2690: technische und methodische Anforderungen zu den Themen des Artikels 21 Absatz 2 NIS-2-Richtlinie; das Dokument verlangt ihre Umsetzung bei der Ausgestaltung dieser Themen.
• ISO/IEC 27002, BSI-Standards 200-1 bis 200-3 und BSI C5: in den Mapping-Tabellen des Dokuments zugeordnet (reine Konzeptreferenz, kein Volltext).
• Orientierungshilfe des BSI zum Einsatz von Systemen zur Angriffserkennung: fachliche Richtschnur für den Anhang.