Ungeplante Ausfallzeiten können für Unternehmen schwerwiegende Folgen haben, von Reputationsschäden über Kundenverluste bis hin zu Sicherheitsvorfällen. Allen voran sind sie jedoch eines: teuer. So betrugen die durchschnittlichen Kosten für Ausfallzeiten[i] in der Vergangenheit etwa 5.600 US-Dollar pro Minute, größere Unternehmen müssen sogar mit Kosten von einer Million US-Dollar pro Stunde rechnen, der KRITIS-Sektor gar mit bis zu fünf Millionen.

Ein effektiver Weg, unerwünschte Downtime zu reduzieren, liegt im Einsatz Cloud-nativer Architekturen. Cloud Computing bietet eine hoch skalierbare und flexible Infrastruktur für IT- und Security-Vorgänge. Cloud-native Architekturen haben dabei das Potenzial, Disaster-Recovery und Business-Continuity zu verbessern, indem sie kontinuierliche Backups, Failover und Datenwiederherstellung bieten.

Reibungsverluste durch nicht-Cloud-native Komponenten

Das Problem: Können die Kerninfrastrukturkomponenten, die in eine Cloud-Architektur integriert sind, den Bedarf an Skalierbarkeit, Flexibilität und Redundanz nicht erfüllen, sind Unternehmen nicht so widerstandsfähig, wie sie vielleicht denken. Nicht-Cloud-native Komponenten können Reibungsverluste verursachen und die Services ausbremsen, aber auch Schwachstellen aufweisen, die Cyberangriffen Tür und Tor öffnen. Vor allem aber erhöhen sie die Wahrscheinlichkeit und das Ausmaß von Ausfallzeiten und riskieren damit die Beständigkeit wichtiger IT-Systeme und Geschäftsabläufe.

Um ihr Unternehmen vor Unterbrechungen zu schützen, müssen Cloud-Architekten eine robuste und zuverlässige Architektur schaffen, die verschiedensten Herausforderungen standhält und unterschiedliche Geschäftsanforderungen unterstützt. Insbesondere die zentralen Cybersicherheitskomponenten, die die Architektur untermauern – einschließlich Privileged-Access-Management (PAM) – sollten Cloud-nativ sein. Nur so können die Security-Verantwortlichen sicherstellen, dass kritischer Systemzugriff gewährleistet wird und der Schaden eingedämmt werden kann, sollte ihr Unternehmen unter Beschuss geraten.

Was eine Cloud-Architektur resistent und widerstandsfähig macht

Die Voraussetzung einer resistenten, widerstandsfähigen Architektur ist die Implementierung von Mechanismen, die eine Ausfallsicherheit garantieren und zudem eine effiziente Verteilung von Arbeitslasten gewährleistet. Dabei gibt es folgende Faktoren zu berücksichtigen.

·         Verfügbarkeitszonen vs. Regionen

Cloud-Architekturen, die mit Verfügbarkeitszonen (Availibility Zones) arbeiten, sind in der Regel weniger ausfallsicher als solche, die auf Cloud-Regionen setzen. Das gilt insbesondere dann, wenn Dienste zonenübergreifend genutzt werden. Fällt beispielsweise ein solcher gemeinsam genutzter Dienst in einer Zone aus, sind automatisch auch alle anderen Zonen betroffen. Cloud-Regionen sind im Gegensatz dazu stärker von anderen Regionen isoliert und daher widerstandsfähiger gegen kritische Dienstausfälle.

·         Lastmanagement und Aktiv/Aktiv-Cluster

Eine resiliente Cloud-Architektur verfügt über ein angemessenes Lastmanagement, das Anfragen situationsbedingt leitet und so sicherstellt, dass die Arbeitslast effizient verteilt wird. Wenn beispielsweise Region 1 stark ausgelastet ist, Region 2 jedoch weniger stark, kann die Arbeitslast sinnvoll verlagert werden. Und sollte eine Region überhaupt nicht betriebsbereit sein, kann der Verkehr automatisch auf eine andere Region umgeleitet werden. Außerdem sollten die Dienste unabhängig und automatisch skaliert werden können, um eine permanent zufriedenstellende Performance gewährleisten zu können.

Idealerweise verwendet die Cloud-Architektur dabei Aktiv/Aktiv-Cluster, bei denen alle Dienste über mindestens zwei aktive Knoten in jedem Cluster verfügen. Dies bietet mehr Stabilität als der herkömmliche Aktiv-Passiv- bzw. Aktiv-Standby-Ansatz, da es keine Verzögerung beim Failover gibt.

·         Monolithische Architektur vs. Microservices

Grundsätzlich gibt es verschiedene Möglichkeiten, Cloud-Dienste wie PAM zu entwickeln. Eine Vorgehensweise ist dabei der Single-Service-Ansatz, bei dem alles, was mit der Lösung zu tun hat, innerhalb desselben Dienstes geschieht. Das bietet den Entwicklern einige Vorteile, geht aber auch mit Nachteilen einher. So muss etwa bei Änderungen von Details die ganze Architektur bearbeitet werden. Und noch schlimmer: Fällt ein Teil des Dienstes aus, wird der gesamte „Monolith“ beschädigt. Konkret könnte das bedeuten, dass eine PAM-Lösung für die Kunden dann offline geht.

Dem gegenüber steht eine Architektur, die aus verschiedenen Diensten, sogenannten Microservices gebaut ist, die jeweils vollständig isoliert und unabhängig von den anderen Diensten laufen. Dieses Modell beschleunigt nicht nur die Bereitstellung und ermöglicht Upgrades sowie Mikroreleases auf Systemebene ohne Downtime, sondern isoliert auch auftretende Probleme. So wird etwa sichergestellt, dass der Ausfall eines einzelnen Services die anderen Services nicht beeinträchtigt.

Doch auch hier gilt: Wenn einer der kritischen Dienste der PAM-Architektur nicht wirklich Cloud-nativ ist, müssen Ausfallzeiten für Updates und Schwachstellenscans eingeplant werden – Zeiten, in denen die Unternehmen weniger widerstandsfähig sind und Dienste für Kunden eventuell nicht zur Verfügung stehen. Dabei gilt zu bedenken, dass Cyberangreifern letztlich ein Fenster von wenigen Minuten reicht, um zuzuschlagen. Echte Cyberresilienz kennt jedoch keine Pausen und wirkt nur dann, wenn sie wirklich 24/7 vorhanden ist.

Quellen

[i] https://www.pingdom.com/outages/average-cost-of-downtime-per-industry/