Cloud im KRITIS-Umfeld: Warum fehlende Leitplanken mehr blockieren als strenge
Ein GKV-IT-Dienstleister wollte mehr Public Cloud nutzen, doch fehlende Leitplanken blockierten jede Entscheidung. Was ein Cloud-Sicherheitsrahmenwerk leisten muss.
Ein IT-Dienstleister im gesetzlichen Gesundheitswesen wollte Public-Cloud-Infrastrukturen stärker nutzen. Der Wille war da, die Anwendungsfälle auch. Was fehlte, war ein systematisches Sicherheitsrahmenwerk, das die Anforderungen im KRITIS-Umfeld abdeckt. Ohne solche Leitplanken kam die Cloud-Nutzung nicht voran, denn niemand konnte verbindlich sagen, unter welchen Bedingungen ein Dienst genutzt werden darf und unter welchen nicht.
In diesem Mandat habe ich als Projektmanager, Architekt und Security Consultant in einem kleinen Team ein solches Rahmenwerk erarbeitet, von den ersten Workshops zu den Anforderungen bis zur Freigabe auf Management-Ebene. Drei Punkte daraus halte ich für übertragbar.
Fehlende Regeln schützen nicht, sie blockieren
Die naheliegende Annahme ist, dass ein Unternehmen ohne Cloud-Regeln eher zu viel Risiko eingeht. Im regulierten Umfeld beobachte ich meist das Gegenteil. Wenn nicht festgelegt ist, was erlaubt ist, wird jede Anfrage zur Einzelfallprüfung, und in einem KRITIS-Umfeld mit Aufsicht und Audit-Druck traut sich verständlicherweise kaum jemand, eine Einzelfallfreigabe zu verantworten. Am Ende passiert dann entweder nichts, oder die Teams suchen sich ihre eigenen Wege, die nicht transparent sind.
Ein Rahmenwerk ist in dieser Lage deshalb weniger eine zusätzliche Hürde als die Voraussetzung dafür, dass überhaupt entschieden werden kann. Es verschiebt die Frage von „Dürfen wir das?” zu „Unter welchen Bedingungen dürfen wir das?“, und auf die zweite Frage gibt es eine Antwort.
Leitplanken, Rollen, Prozesse und Tools gehören zusammen
Ein Sicherheitskonzept allein reicht dafür nicht. Das Rahmenwerk umfasste deshalb neben den Leitplanken für die Cloud-Nutzung auch Sicherheitskonzepte für Public- und Private-Cloud-Szenarien und ein Prozess-Framework für das Onboarding neuer Cloud-Dienste und deren laufende Governance. Für das Management haben wir zusammengefasst, welche Anpassungen bei Rollen, Prozessen und Tools notwendig sind.
Diese Kombination halte ich für den eigentlichen Kern. Leitplanken ohne Onboarding-Prozess bleiben ein Dokument, das bei der ersten konkreten Anfrage niemand anwendet. Ein Prozess ohne klare Rollen läuft ins Leere, weil unklar bleibt, wer eine Freigabe tatsächlich erteilt. Und wenn die Werkzeuge fehlen, mit denen sich die Einhaltung überprüfen lässt, wird aus dem Rahmenwerk schnell eine Selbstauskunft.
Abstufen statt alles gleich streng prüfen
Ein Fehler, den ich bei Sicherheitsprozessen auch in anderen Mandaten erlebt habe, ist die gleiche Prüftiefe für alles. Wenn ein kleines Werkzeug denselben Prozess durchlaufen muss wie eine Plattform, auf der Versichertendaten verarbeitet werden, ist der Prozess für das eine zu schwergewichtig und für das andere womöglich trotzdem nicht gründlich genug. Kleine Tools oder Add-Ons brauchen aus meiner Sicht oft nur eine Kurzprüfung und müssen nicht nach jedem Mini-Update neu bewertet werden. Die Aufmerksamkeit gehört dorthin gelenkt, wo das Risiko tatsächlich liegt.
Im Mandat haben wir die Leitplanken deshalb nach dem Schutzbedarf der Daten abgestuft, die ein Dienst verarbeitet. Für Dienste ohne personenbezogene Daten reichte eine Kurzprüfung. Sobald personenbezogene Daten im Spiel waren, kamen Vorgaben zu Datenstandort und Verschlüsselung hinzu, dazu Nachweise des Anbieters wie ein C5-Testat des BSI. Für Sozialdaten der Versicherten galt die strengste Stufe: Private Cloud oder Public Cloud nur mit eigener Schlüsselverwaltung, und die Prüfung lag bei einem festen Gremium.
Dazu kommt ein zweiter Punkt, der gerne übersprungen wird: Sicherheitsprozesse sollten mit den Menschen abgestimmt werden, die sie später bedienen müssen. Wer Regeln am Schreibtisch (oder besser: im klassischen Elfenbeinturm) entwirft und dann ausrollt, ohne mit den Teams zu sprechen, bekommt meist Umgehungen zurück. Deshalb standen am Anfang des Mandats Workshops zu den Anforderungen, die in den Teams eingeholt wurden, die den Prozess später nutzen.
Ohne Freigabe von oben bleibt es ein Papiertiger
Den wichtigsten Schritt sehe ich am Ende: Das Rahmenwerk wurde auf Management-Ebene präsentiert und dort freigegeben. Das klingt nach Formalie, entscheidet aber darüber, ob die Leitplanken verbindlich sind. Ein Rahmenwerk, das nur in der Sicherheitsabteilung liegt, wird bei der ersten Abwägung zwischen Termin und Vorgabe zur Verhandlungsmasse. Mit der Freigabe von oben ist es die Grundlage, auf die sich Fachbereiche, Betrieb und Sicherheit gleichermaßen berufen können.
Was ich mitnehme
In diesem Mandat lag die Bremse nicht in der Technik, sondern in der fehlenden Antwort auf die Frage, was unter welchen Bedingungen erlaubt ist. Ein Rahmenwerk mit klaren Leitplanken, abgestufter Prüftiefe und einem gelebten Onboarding-Prozess macht die Cloud-Nutzung nicht riskanter, sondern überhaupt erst steuerbar.
Eine Einschränkung würde ich aber machen: Ein Rahmenwerk ersetzt nicht den Überblick darüber, was bereits im Einsatz ist. Absichern lässt sich nur, was man auch kennt. Wer Leitplanken für neue Dienste einführt, sollte deshalb zumindest festhalten, welche Cloud-Dienste heute schon genutzt werden, und dann auch diese schrittweise in den Rahmen holen. Und auch das beste Rahmenwerk muss regelmäßig nachgeschärft werden, weil sich Dienste, Anforderungen und Regulierung weiterentwickeln.
Weiterführend aus dem Blog: KI-Readiness: Erst der Use Case, dann das Tool, Souveränität ausschreiben und IT-Security im öffentlichen Sektor.
Steht bei Ihnen die Cloud-Nutzung im regulierten Umfeld an, und es fehlen die Leitplanken? Genau dafür gibt es unser Cluster Architektur & Transformation im regulierten Umfeld, vom Architektur-Review mit klarem Urteil bis zum Sicherheitsrahmenwerk, das Entscheidungen ermöglicht. Oder direkt: Erstgespräch vereinbaren.