1. Einleitung
2. Kritische Infrastrukturen
2.1. Interaktionen in Systemen
2.2. Kopplung
2.3. Resilienz
2.4. Vier-Ebenen-Modell nach Perrow
3. Cloud-Computing
3.1. Vulnerabilität
3.2. Cloud-Computing von kritischen Infrastrukturen
3.3. Cloud-Computing als kritische Infrastruktur
4. Analyse
5. Fazit
6. Literatur
„Das Ausmaß der Erhebung und des Austauschs personenbezogener Daten hat eindrucksvoll zugenommen. Die Technik macht es möglich, dass private Unternehmen und Behörden im Rahmen ihrer Tätigkeiten in einem noch nie dagewesenen Umfang auf personenbezogene Daten zurückgreifen“, so lautet es in Abs. 2 der Begründung der europäischen Datenschutzrichtlinie DSGVO (DSGVO 2022, S. 3). Doch das Verwalten und Sammeln personen- und geschäftsbezogener Daten auf Cloud-Speichern birgt Risiken, wie Datenverlust sowie deren Raub oder Spionage durch Dritte. Besonders Cloud-Dienste, die Einrichtungen kritischer Infrastrukturen (KRITIS) zu ihrem Kundenstamm zählen, stellen ein beliebtes Ziel von Cyberangriffen dar (vgl. Adelmeyer et al. 2018, S. 7). Dass diese Attacken auf kritische Infrastrukturen fatale Folgen haben können, zeigten die beiden Hackerangriffe durch die Softwares „NotPetya“ und „WannaCry“ Mitte des Jahres 2017. So sorgte die WannaCry-Attacke in mehreren britischen Krankenhäusern für Systemausfälle, wodurch Patienten nicht mehr aufgenommen oder nicht behandelt werden konnten und somit Leben in Gefahr standen (vgl. Hofstetter 2019, S. 65). Die darauffolgende Attacke durch NotPetya führte bei der Reederei Maersk zum Ausfall von 50.000 Rechnern, wodurch ein wirtschaftlicher Schaden im neunstelligen Bereich für das Unternehmen entstand; insgesamt lagen die globalen Verluste durch den Angriff schätzungsweise in Milliardenhöhe (vgl. Hofstetter 2019, S. 65).
Die vorliegende Hausarbeit geht daher der Forschungsfrage nach, unter welchen Voraussetzungen Cloud-Dienstleister von KRITIS-Betreibern als kritische Infrastrukturen im sozio-technischen Sinne wahrzunehmen sind, bzw. ob die Einordnung von Cloudanbietern als KRITIS grundsätzlich gelten muss. Hierzu werden zunächst die zur Risikobestimmung maßgeblichen Merkmale kritischer Infrastrukturen ausgearbeitet und erläutert. Daran anschließend wird an den Forschungsgegenstand des Cloud-Computings herangeführt. Hierbei wird bewusst darauf verzichtet, eine tiefe Auseinandersetzung mit der technischen Perspektive der IT-Sicherheit vorzunehmen, da deren Verbesserung nicht Gegenstand dieser Arbeit ist und deshalb ein Grundwissen über IT-Sicherheit ausreicht. Ferner werden die rechtlichen Grundlagen zur Identifikation von Cloud-Diensten als KRITIS-Dienstleister sowie als Kritische Infrastruktur selbst beschrieben. In der Analyse findet die Untersuchung von Cloudsystemen auf Anwendbarkeit der KRITIS-Eigenschaften am Fallbeispiel des Cloud-Computings für das Gesundheitssystem statt. Aus den hieraus gewonnenen Erkenntnissen erfolgt eine Schlussfolgerung im Hinblick auf die Forschungsfrage.
Gemäß § 2 Abs. 10 BSIG werden als kritische Infrastrukturen jene Einrichtungen, Anlagen sowie deren Teile bezeichnet, „ die den Sektoren Energie, IT und Telekommunikation, Transport und Verkehr, Gesundheit, Wasser, Ernährung sowie Finanzen und Versicherungen“ zugeordnet werden und deren Ausfall eine Gefahr für die öffentliche Sicherheit oder Einbußen in der Versorgung bedeuten würde (Adelmeyer et al. 2018, S. 7). Aus sozio-technischer Sicht lassen sich kritische Infrastrukturen durch die in den folgenden Unterkapiteln beschriebenen Eigenschaften nach dem amerikanischen Soziologen Charles B. Perrow beschreiben.
Um festzustellen welche Systeme besonders hohe Vulnerabilität für Ausfälle vorweisen ist es notwendig, sich der Begriffe Interaktion und Kopplung im sozio-technischen Kontext bewusst zu werden (vgl. Perrow 1992, S. 107 ff). In der modernen Gesellschaft sind signifikantes Wachstum von Systemgröße und Multifunktionalität von Systemen längst als Status quo zu betrachten. Damit verringert sich die Vorhersehbarkeit von Interaktionen von Systemen maßgeblich verringert (vgl. Perrow 1992, S. 107). Hierbei ist die Interaktion per se nicht das Problem, vielmehr muss eine Unterscheidung zwischen linearen und komplexen Interaktionen getroffen werden, bei denen sich verschiedene Vor- und Nachteile abzeichnen (vgl. Perrow 1992, S. 107 f).
Man spricht von linearer Interaktion, wenn Interaktionen zwischen aufeinanderfolgenden Systemkomponenten auftreten, wie beispielsweise ein Produktionsablauf in bestimmten aufeinanderfolgenden Einzelschritten (vgl. Perrow 1992, S. 114 f). Die Folgen einer Störung lassen sich aufgrund der Reihenfolge der Abläufe offensichtlich erkennen. Unmittelbare Reaktionen auf auftretende Störfälle können erfolgen, selbst wenn die Interaktion unvorhergesehen auftritt (vgl. Perrow 1992, S. 107; 115).
Bedient eine Einheit oder ein Subsystem (siehe Unterkapitel 3.5) nun allerdings mehrere Systemkomponenten, ist die Rede von komplexer Interaktion, bei welcher ein Defekt der ersten Komponente den Ausfall sämtlicher bedienten Systemkomponenten nach sich zieht (vgl. Perrow 1992, S. 108). Man spricht in diesem Fall von abhängigen Fehlern, wobei die Unfallursache in der Komplexität der Interaktion vorzufinden ist (vgl. Perrow 1992, S. 108). Neben abhängigen Fehlern, auch „Common-Mode-Fehler“ genannt, lassen sich komplexe Interaktionen ferner auf physisch eng benachbarte Aggregate sowie indirekte Informationsquellen zurückführen (vgl. Perrow 1992, S. 109). Hierunter ist zu verstehen, dass nahe beieinanderliegende Aggregate, beispielsweise eine Motoreinheit, welche durch Defekt zu Funken beginnt und eine undichte Ölpumpe, deren ausgetretenes Öl sich zum Teil zu Gas entwickelt, ungewollt miteinander agieren (vgl. Perrow 1992, S. 109 f). Es kommt zu einer nicht vorhersehbaren Interaktion, der zum Feuer führenden Explosion. Die indirekte Informationsquelle ist dann die irreführende Wahrnehmung der Folge und die falsche Ursacheneinschätzung einhergehend mit der falsch gewählten Konsequenz, den Ölbrand im Maschinenraum mit Wasser zu löschen und somit das Feuer zu vergrößern (vgl. Perrow 1992, S. 110). Der abhängige Fehler beschreibt hier, dass weder der Funkenflug im Maschinenraum noch die Havarie der Ölpumpe allein zum Feuer geführt hätten, sondern der Eintritt des Unfalls von dem Zusammenspiel beider Störungen abhängt.
Zu unterscheiden gilt es zwischen enger und loser Kopplung. Wenn zwei Komponenten miteinander so in Verbindung stehen, dass sich ihre Vorgänge unmittelbar aufeinander auswirken, also kein Spielraum oder Elastizität in der Verbindung der Komponenten vorherrscht, dann ist die Rede von enger Kopplung (vgl. Perrow 1992, 131). Lose gekoppelte Systeme kennzeichnen sich analog durch mehr Spielraum hinsichtlich der eigenständigen Funktionalität ab, welcher sie bei Störungen, Erschütterungen oder forcierte Veränderungen vor Stabilitätsverlust schützt, eng gekoppelte Systeme hingegen werden von diesen Ereignissen stärker tangiert und sind deshalb mitunter schweren Defekten ausgesetzt (vgl. Perrow 1992, S. 131). Lose Kopplung ist insbesondere dann unabdingbar, wenn bestimmte Prozessabläufe unabhängig von anderen erfolgen müssen, wie beispielsweise eine externe Qualitätskontrolle von Produkten, wodurch allerdings Sonderinteressen sowie verbotene Handlungen von Systemteilen begünstigt werden (vgl. Perrow 1992, S. 132). Ein denkbares Beispiel hierfür wäre die Bestechung zu falschen Qualitätsgutachten, oder zur Herausgabe geheimer Produktinformationen durch den Prüfer. Eng gekoppelte Systeme verfügen über mehr zeitgebundene Abläufe, da der Produktionslauf keine Stillstände erlaubt, wie etwa in einem Labor, in dem bestimmte Substanzen spezielle Haltbarkeiten aufweisen (vgl. Perrow 1992, S. 132 f). Ferner sind die Abläufe in Systemen mit enger Kopplung genauer festgelegt, da zur Produktfertigung eine vorgegebene Produktionsreihenfolge eingehalten werden muss und sich nur wenige Teilschritte unter hohem Kostenaufwand verschieben lassen (vgl. Perrow 1992, S. 133). Daraus resultiert der ebenfalls vorgegebene Gesamtprozess der Produktion. Die Produktpalette und das Produktionsvolumen von Dauerbetriebsanlagen kann begrenzt verändert werden, grundlegende Veränderungen des Herstellungsprozesses sind jedoch nicht umsetzbar (vgl. Perrow 1992, S. 133). Im Gegensatz dazu ist dies bei lose gekoppelten Fertigungsanlagen möglich, weshalb man lose gekoppelte Systeme als „äquifinal“ und eng gekoppelte Systeme als „unifinal“ klassifizieren kann (vgl. Perrow 1992, S. 133).
Die Regenerationsfähigkeit eines von Störungen oder Ausfällen betroffenen Systems steht in unmittelbarer Abhängigkeit zu seiner Form der Kopplung (vgl. Perrow 1992, S. 134). Während es der festen Integration von Puffern, Redundanzen und Substitutionsmöglichkeiten bei eng gekoppelten Systemen aufgrund ihrer unifinalen Natur bedarf, können diese Elemente in Systemen loser Kopplung im Falle einer auftretenden Störung nachträglich improvisiert werden und dennoch ihren Zweck wahrnehmen (vgl Perrow 1992, S. 134). Somit bauen eng gekoppelte Systeme auf fest eingebaute Sicherheitsvorrichtungen, um die Entwicklung eines Störfalls zu einem Unfall abzuwehren. In lose gekoppelten Systemen können neben eingebauten Schutzmechanismen ebenfalls unerwartete Maßnahmen erfolgen (vgl. Perrow 1992, S. 135). Dies kann zur Folge haben, dass bei loser Kopplung ein ausreichendes Aufkommen an integrierten Sicherheitsvorkehrungen außer Acht gelassen wird, da man sich zu sehr auf die Möglichkeit von zufälligem konstruktivem Handlungsspielraum im Störungsfall verlässt (vgl. Perrow 1992, S. 135).
Aus den im vorangegangenen Kapitel genannten Gründen einer gegebenen Vulnerabilität durch die Digitalisierung ist es notwendig, der Erarbeitung von resilienten Systemen noch mehr Relevanz zuteil werden zu lassen. Resilienz meint hierbei, ein System bei Auftreten eines Störfalls in seiner Funktionsfähigkeit zu erhalten und diese bei Verlust so schnell wie möglich wiederherzustellen (vgl. Krebs und Hagenweiler 2021, S. 43). Voraussetzung hierfür ist neben der Kalkulation möglicher unerwarteter Ereignisse, wie des bereits genannten menschlichen Versagens, ebenfalls retrospektives Lernen aus bereits eingetretenen Schadensfällen, wodurch Vorsorgemaßnahmen erarbeitet und bekannte Risiken identifiziert werden können (vgl. Krebs und Hagenweiler 2021, S. 43).
Charles Perrow unterscheidet anhand eines Modells auf vier Ebenen zwischen Störungen und Unfällen. Hierbei legt er die Ebenen Teile, Einheiten, Subsysteme und Gesamtsystem fest, wobei er bei Defekten auf erster und zweiter Ebene von Störfällen, auf dritter und vierter Ebene von Unfällen spricht (vgl. Perrow 1992, S. 99). Das Merkmal, durch welches eine Störung zu einem Unfall wird, ist die nicht mehr fortwährende Funktionsfähigkeit des Gesamtsystems, welche bei einer Störung langfristig betrachtet weitestgehend unbeeinträchtigt bleibt (vgl. Perrow 1992, S. 98). Teile sind hierbei als die kleinste Systemkomponente zu verstehen und verbinden sich zusammen mit anderen Teilen, die in funktionaler Beziehung miteinander agieren, zu einer Einheit (vgl. Perrow 1992, S. 99). Zusammenwirkende Einheiten werden als Subsysteme verstanden, deren Zusammenspiel schließlich das Gesamtsystem bildet (vgl. Perrow 1992, S. 99). Perrow weist jedoch darauf hin, dass eine strikte Unterscheidung in Teil, Einheit und Subsystem nicht klar getroffen werden kann und dahingehend, in welche der drei Ebenen sich ein Systembestandteil einordnen lässt, stets Interpretationsspielraum besteht (vgl. Perrow 1992, S. 99).
Das Cloud-Computing lässt sich im Wesentlichen als ein digitales Outsourcing beschreiben. Die Verarbeitung privater sowie geschäftlicher Daten wird nicht mehr vom Nutzer selbst durchgeführt, sondern per Auftrag durch den Nutzer an den Dienstleister an eine zentrale Recheninfrastruktur übertragen (vgl. Jäger et al. 2020, S. 3). Die Datenverarbeitung kann gänzlich in der Cloud vorgenommen werden, oder aber auch zum Teil auf dem Gerät des Nutzers durch diesen (vgl. Jäger et al. 2020, S. 4). Hierbei gilt der Nutzer als der für die Daten Verantwortliche und der Cloud-Betreiber als den Auftrag Verarbeitender (vgl. Jäger et al. 2020, S. 5). Um dem Nutzer eines Cloud-Anbieters ein Urteil über dessen wirksame technische Voraussetzungen zu erleichtern, werden die Dienste des Anbieters durch unabhängige Prüfer von Akkreditierungsstellen zertifiziert (vgl. Jäger et al. 2020, S. 10). Dieses Vorgehen wird meist durch den Cloud-Anbieter selbst bei der jeweiligen Stelle beauftragt, welche daraufhin den Zertifizierungsauftrag an einen unabhängigen Prüfer erteilt und dieser sodann einen Prüfbericht erstellt (vgl. Jäger et al. 2022, S. 10). Aufgrund des vorgelegten Berichts entscheidet die Zertifizierungsstelle über die Zertifikatsausstellung, zum Beispiel eines Datenschutz-Zertifikats nach Art. 42 DSGVO, wonach der Nutzer von der Sicherheit über die Datenschutzkonformität des Dienstes ausgehen kann (vgl. Jäger et al. 2020, S. 10). Um die Vertrauenswürdigkeit der Zertifizierungsstellen zu gewährleisten, wird ihre Eignung nach dem Katalog ISO/IEC 17065 akkreditiert (vgl. Jäger et al. 2020, S. 12).
In einer durch Digitalisierungsprozesse immer tiefgreifender vernetzten Infrastruktur erhöht sich die Anfälligkeit für schwerwiegende Ausfälle sowie die Tragweite der dadurch entstehenden Schäden maßgeblich. (vgl. Krebs und Hagenweiler 2021, S. 43). Dies liegt zum einen daran, dass in immer komplexer vernetzten Informations- und Kommunikationssystemen selbst scheinbar kleine Störfälle eine Kettenreaktion innerhalb eines Systems hervorrufen können (vgl. Krebs und Hagenweiler 2021, S. 43). Zum anderen können viele Staaten die Geschwindigkeit von ausgereiften Schutzmaßnahmen für Informationstechnik nicht an die der Digitalisierung anpassen, weshalb ein gravierender Zuwachs von nicht hinreichend gesicherten digitalen Geräten zu beobachten ist (vgl. Krebs und Hagenweiler 2021, S. 82). Da sich die Sicherheit eines Systems durch die Einkalkulierung und Berücksichtigung menschlichen Versagens sowie der Vermeidung von daraus resultierenden Schadensereignissen beschreiben lässt, erscheint es in der heutigen Zeit zunehmend unmöglich, diese Sicherheit gewährleisten zu können (vgl. Krebs und Hagenweiler 2021, S. 32). In einer Gesellschaft, in der fast jeder Mensch im Besitz von mindestens einem dieser Geräte ist und damit Zugang zur digitalen Infrastruktur erlangt, ist menschliches Versagen im Sinne von Social-Engineering sowie die Täuschung durch Ransomware (erpresserische Sofware) nicht auszuschließen.
Ist ein Cloud-Anbieter Dienstleister für einen KRITIS-Betreiber, so ist der Dienstleister nur mittelbar durch das IT-Sicherheitsgesetz (IT-SiG) betroffen, da beim IT-Outsourcing die Erkennung und Überwachung von durch das IT-SiG regulierten potenziellen Risiken in der Verantwortung des Betreibers der kritischen Infrastruktur liegt (vgl. Adelmeyer et al. 2018, S. 13). Der KRITIS-Betreiber muss jedoch nach den §§ 8a und 8b BSIG beispielsweise durch Audits und Zertifizierungen sicherstellen, dass der Cloud-Dienst der Erfüllung der im IT-SiG gestellten Anforderungen nachgekommen ist, wodurch der Cloud-Anbieter dennoch durch dieses tangiert wird (vgl. Adelmeyer et al. 2018, S. 13).
[...]
