Cloud Services
Classified Cloud
Managed Services
Kubernetes
Öffentliche Verwaltung
Verteidigung & Raumfahrt
Sicherheitsbehörden
Gesundheitswesen
Regulierte Industrien
Kritische Infrastrukturen
Enterprise IT-Modernisierung
SaaS & digitale Plattformen
Cloud Services
Classified Cloud
Managed Services
Kubernetes
Versorgungssicherheit beginnt in der Infrastruktur
Im Versorgungsalltag
Wo ein Ausfall nicht nur ein Ticket ist, sondern eine Störung der Versorgung
Bei kritischer Infrastruktur hat ein IT-Vorfall unmittelbare Folgen außerhalb der IT. Drei Situationen zeigen, wo eine belastbare Cloud-Architektur diesen Unterschied macht.
Systeme zur Angriffserkennung müssen durchgehend laufen und Vorfälle innerhalb der NIS2-Fristen melden können. Die Infrastruktur dahinter darf selbst kein Angriffsziel mit Schwachstellen sein.
Steuerungs- und Leitsysteme für die Versorgung müssen auch bei Störungen weiterlaufen. Ein Ausfall betrifft nicht nur ein System, sondern eine ganze Region.
Fahrgastinformation und Leitsysteme müssen bei Störungen besonders zuverlässig laufen, genau dann, wenn die Last am höchsten ist. Skalierung darf im Ernstfall nicht das Problem sein.
Regulatorischer Kontext
Vorgaben, die für Betreiber kritischer Infrastrukturen gelten
Wer als KRITIS-Betreiber gilt, definiert die BSI-KritisV anhand von Schwellenwerten je Sektor, von Energie über Wasser bis Ernährung und Verkehr. § 8a BSIG verlangt alle zwei Jahre den Nachweis angemessener Schutzmaßnahmen sowie Systeme zur Angriffserkennung. NIS2 verschärft diese Pflichten und setzt enge Meldefristen: eine Frühwarnung innerhalb von 24 Stunden, eine Meldung innerhalb von 72 Stunden. Das geplante KRITIS-Dachgesetz ergänzt die physische Resilienz als eigenständige Anforderung. Branchenspezifisch kommen weitere Vorgaben hinzu, etwa § 11 EnWG für die Energiewirtschaft. BSI C5 bleibt der Prüfkatalog für die eingesetzte Cloud-Infrastruktur selbst.
Souveränität
Resilienz endet nicht an der eigenen Systemgrenze
Wer für die Versorgung verantwortlich ist, muss auch die eigene Cloud-Abhängigkeit als Risiko betrachten. Ein einzelner Anbieter, von dem alles abhängt, ist selbst ein Single Point of Failure.
Prüfbare Basis statt Vertrauensvorschuss
Kubernetes und OpenStack als offene Grundlage. Angriffserkennung und Audits lassen sich auf einer Architektur aufsetzen, die tatsächlich einsehbar ist.
Portabilität als technisches Fundament
Workloads sind nicht an einen Hersteller gebunden. Ein Wechsel des Betreibers ist keine theoretische Vertragsoption, sondern technisch tatsächlich durchführbar.
Keine Abhängigkeit von einem einzigen Anbieter
Redundanz auf Infrastrukturebene reicht nicht, wenn am Ende doch ein Anbieter das gesamte System trägt. Offene Standards machen echte Diversifizierung möglich.
Vor Ort, wenn Anbindung selbst zum Risiko wird
Derselbe Cloud-Stack läuft auch direkt in der eigenen Leitstelle oder im Betriebszentrum, wenn Ausfallsicherheit eine physische Trennung verlangt.
Betrieb in Deutschland
Übernimmt secunet den Betrieb, geschieht das ausschließlich in zertifizierten Rechenzentren im Inland.
Projekte & Referenzen
Betrieb für digitale Landwirtschaftssysteme, die zur Versorgungssicherheit im Ernährungssektor beitragen.
Cloud-Infrastruktur für ein Unternehmen im Bereich der Flugsicherung, mit entsprechenden Anforderungen an Verfügbarkeit.
Zusammenarbeit mit einem der sicherheitskritischsten Unternehmen Deutschlands bei souveränen IT-Infrastrukturen.
Zertifizierungen & Standards
Sprechen wir über Ihre Resilienzanforderungen
Ob § 8a BSIG-Nachweis, Angriffserkennung oder Leitsystem-Betrieb: Wir ordnen den Bedarf gemeinsam ein.
