Jenseits der Cloud-Grenzen: Aufbau einer resilienten Infrastruktur in Hybrid- und SaaS-Umgebungen

Executive Summary

Das moderne Unternehmen basiert auf einem Cloud-Fundament. Die rasche Einführung von Plattformen für Software as a Service (SaaS) und Infrastructure as a Service (IaaS) hat die geschäftliche Flexibilität gesteigert, Investitionsausgaben minimiert und eine beispiellose operative Skalierung vorangetrieben. 

Allerdings hat diese absolute Abhängigkeit von Cloud-gehosteten Systemen ein kritisches Paradoxon hervorgebracht: Durch die Verlagerung der Kerninfrastruktur außerhalb ihrer physischen und administrativen Grenzen haben Unternehmen tiefe, systemische Abhängigkeiten von externen Netzwerken und Drittanbietern geschaffen.

Wenn diese Abhängigkeiten ausfallen – aufgrund von durchtrennten physischen Glasfaserkabeln, Routing-Fehlkonfigurationen, Ausfällen des Domain Name System (DNS) oder regionalen Ausfällen bei großen Hyperscalern –, kommen moderne Betriebsabläufe sofort zum Stillstand. Für kritische Branchen wie Gesundheitswesen, Verteidigung, Fertigung, Versorgung, Finanzwesen, Einzelhandel und Transportwesen ist ein Ausfall der Cloud-Konnektivität nicht nur ein IT-Problem; er ist eine Bedrohung für die menschliche Sicherheit, die nationale Sicherheit und die wirtschaftliche Stabilität.

Business Continuity Planning (BCP) in einer Cloud-First-Ära erfordert zusätzliche Planung. Indem wir traditionelle BCP-Methoden untersuchen, uns mit modernen Edge-Computing-Frameworks wie AWS Outposts befassen und die identitätszentrierte Ausfallsicherheit anhand der Offline-Fähigkeiten des Okta Local Authentication Service demonstrieren, zeigen wir, dass lokale Ausfallsicherheit kein Luxus mehr ist. Es ist eine grundlegende Strategie für das moderne Unternehmen.

Wie definiert die Cloud die Business-Continuity-Planung neu?

Jahrzehntelang schrieb das Standard-IT-Paradigma vor, dass Ausfallsicherheit durch die Duplizierung physischer Infrastruktur erreicht wurde – durch den Aufbau sekundärer Rechenzentren, die Provisionierung redundanter Stromversorgung und die Nutzung geografischer Trennung. Der Wechsel in die Cloud verlagerte diese Last auf Cloud-Service-Provider (CSPs). Viele Führungskräfte gingen fälschlicherweise davon aus, dass die Cloud-Einführung gleichbedeutend mit garantierter Verfügbarkeit sei. 

Welche Risiken birgt die ausschließliche Nutzung von Cloud-Infrastruktur?

Während große Cloud- und SaaS-Anbieter Milliarden Dollar in Multi-Region-Failover und hochverfügbare Architekturen investieren, bleiben sie anfällig für Single Points of Ausfall. Eine einzige falsch konfigurierte Border Gateway Protocol (BGP)-Route, ein DNS-Ausfall oder ein kaskadierender API-Fehler in einer primären Hyperscaler-Region kann Tausende von Organisationen sofort von ihren kritischen Systemen trennen.  

Diese Schwachstelle ist nicht rein digital. Schon ein:e einzige:r Baggerfahrer:in, der oder die bei routinemäßigen Straßenbauarbeiten eine unterirdische Glasfaserleitung durchtrennt – oder ein gezielter Akt physischer Sabotage –, kann die Lebensader eines Unternehmens zur Cloud sofort kappen, wodurch ansonsten funktionierende Remote-Ressourcen völlig unerreichbar werden. 

In diesen Momenten ist der Cloud-Anbieter intern möglicherweise voll funktionsfähig, aber da das Unternehmensnetzwerk die Endpunkte des Anbieters nicht erreichen kann, ist der Dienst faktisch ausgefallen.

Welche zentralen Sicherheitsprinzipien gelten für eine resiliente Netzwerkplanung?

Um diesen Risiken zu begegnen, muss die Kontinuitätsplanung die Kernprinzipien der Informationssicherheit und des Disaster Recovery integrieren:

Fokus auf das Wesentliche: Der Realitätscheck

Bevor Sie etwas beheben können, sollten Sie wissen, was Sie eigentlich schützen. Das bedeutet, die absoluten Kernbereiche Ihres Unternehmens zu identifizieren, die nicht ausfallen dürfen, und sie bis zu jedem einzelnen Cloud-Anbieter oder SaaS-Tool zurückzuverfolgen, auf die sie angewiesen sind. Wenn Sie nicht wissen, wo sich Ihre Abhängigkeiten befinden, können Sie diese nicht schützen.

Die Überlebensgleichung: Warum die Rechnung nicht aufgeht

In der Welt der Sicherheit gibt es eine Grundregel für das Überleben von Unternehmen: Ihre Maximum Tolerable Downtime (MTD) – die absolute Grenze dafür, wie lange Ihr Unternehmen finanzielle Verluste überstehen kann – sollte länger sein als die Zeit zur Behebung des technischen Problems, die als Ihre Recovery Time Objective (RTO) bezeichnet wird, zuzüglich der Zeit, die benötigt wird, um Ihre Daten und Mitarbeiter:innen wieder in den normalen Arbeitsablauf zurückzuführen (WRT):

 MTD >= RTO + WRT

Hier ist der Haken an der Cloud: Wenn die Konnektivität komplett ausfällt, verlängert sich Ihre RTO auf unbestimmte Zeit, da die Wiederherstellung der Verbindung völlig außerhalb Ihrer Kontrolle liegen kann. Wenn Sie keine Offline-Alternative haben, geht diese Rechnung komplett nicht mehr auf und dem Unternehmen läuft die Zeit davon.

Graceful Degradation: "Inselmodus" 

Wenn ein Unternehmen die Verbindung zur Außenwelt verliert, sollte es in der Lage sein, kontrolliert auszufallen – und zu einer betriebsfähigen "Insel" zu werden. Das lokale Netzwerk muss für zentrale, lebenserhaltende oder umsatzgenerierende Aufgaben bei reduzierter Kapazität Support leisten, ohne auf externe Cloud-Handshakes angewiesen zu sein.

Wie wirken sich Cloud-Verbindungsabbrüche auf kritische Branchen aus?

Verschiedene Branchen und Unternehmen arbeiten recht unterschiedlich; der Bedarf an Resilienz bei der Nutzung der Cloud betrifft jedoch viele Branchen. Im Folgenden finden Sie eine detaillierte Darstellung der Auswirkungen von Cloud-Verbindungsabbrüchen auf einige kritische Branchen, die verdeutlicht, wo eine lokale Betriebskontinuität zwingend erforderlich ist:

Wie Cloud-Ausfälle die Business Continuity gefährden

Branchenspezifische Schwachstellen

Gesundheitswesen und klinischer Betrieb

In Krankenhäusern ist der sofortige Zugriff auf elektronische Patientenakten (EHRs), Patiententelemetrie in Echtzeit und automatisierte Medikamentenausgabeschränke eine Frage von Leben und Tod. Wenn die Verbindung zu einer in der Cloud gehosteten EHR unterbrochen wird, verlieren Ärzt:innen den Einblick in wichtige Krankengeschichten, Allergien und laufende Behandlungen. Medikamenten-Workflows geraten ins Stocken, was die Patientensicherheit direkt kompromittiert.

Militär und taktische Verteidigung

Streitkräfte operieren routinemäßig in Umgebungen mit verweigerter, beeinträchtigter, unterbrochener oder begrenzter (DDIL) Konnektivität. Kommandozentralen, Kommunikationsanlagen und taktische Logistiksysteme müssen ohne einen ständigen Uplink zu einer zentralen Cloud zuverlässig funktionieren. In Verteidigungsarchitekturen stellt eine starke Abhängigkeit von externen Cloud-Services eine schwerwiegende Schwachstelle für die nationale Sicherheit dar.

Versorgung und kritische Infrastruktur

Stromnetze, Wasseraufbereitungsanlagen und Energieübertragungs-Pipelines sind auf Supervisory Control and Data Acquisition (SCADA)-Systeme angewiesen. Diese industriellen Steuerungssysteme müssen die physische Infrastruktur lokal überwachen und anpassen. Wenn die Cloud-angebundene Überwachungsebene ausfällt, müssen die lokalen Systeme einen sicheren, autonomen Zustand aufrechterhalten, um katastrophale Systemausfälle zu verhindern.

Fertigung und industrielle Automatisierung

Moderne Smart Factories sind auf industrielle Hochgeschwindigkeits-IoT-Netzwerke und automatisierte Montagesysteme angewiesen. Selbst eine kurze Netzwerkunterbrechung kann die Robotik desynchronisieren, Produktionslinien zum Stillstand bringen und zu erheblichem Ausschuss Lead. Ungeplante Ausfallzeiten in der Schwerindustrie kosten Zehntausende von Dollar pro Minute. Daher ist es erforderlich, dass lokale Edge-Controller ohne Remote-Handshakes funktionieren.

Transport- und Versandlogistik

Häfen, Distribution Hubs und globale Reedereien können sich keine Logistikengpässe leisten. Wenn regionale Cloud-Services ausfallen, müssen fahrerlose Transportfahrzeuge (AGVs) weiterhin sicher navigieren, das Scannen von Manifesten muss fortgesetzt werden und Container-Routing-Systeme müssen Transaktionen lokal in die Warteschlange einreihen, um diese asynchron zu synchronisieren, sobald die WAN-Verbindung wiederhergestellt ist.

Warum ist die Identität die primäre Sicherheitskontrollebene?

In modernen Zero Trust -Architekturen ist die Identität die primäre Sicherheitskontrollebene. Eine Organisation kann hochgradig ausfallsichere On-Premise-Anwendungen bereitstellen. Dennoch sind diese Anwendungen bei einem Verbindungsabbruch-Event funktional nutzlos, wenn sie für die Benutzer:in-Authentifizierung auf einen nicht erreichbaren Cloud-Identity-Anbieter (Identity-Anbieter) angewiesen sind.

Wie Standard-Umleitungs-Flows bei Cloud-Ausfällen fehlschlagen

Bei einer typischen cloudbasierten Identitätsbereitstellung beruht Single Sign-On (SSO) mittels Security Assertion Markup Language (SAML) oder OpenID Connect (OIDC) darauf, den Browser der Benutzer:innen zwischen der Anwendung und Okta hin- und herzuleiten. Während eines Internet- oder SaaS-Ausfalls:

• Die Anwendung kann eingehende Identitätszusicherungen nicht validieren.
• Der Browser der Benutzer:in kann die Cloud-Authentifizierungsendpunkte nicht auflösen oder erreichen.
• Back-Channel-Token-Verifizierungsprüfungen schlagen fehl.

Um zu überleben, muss das Unternehmensnetzwerk in den "Inselmodus" zurückkehren – und auf lokale Verzeichnisse und lokale Identitätsserver zurückgreifen, die nativ am Edge gültige Token ausstellen können. Dies ist sowohl für herkömmliche webbasierte Anwendungen als auch für agentenbasierte KI wichtig, bei der sich der Agent möglicherweise On-Premises befindet und Zugriff auf On-Premises-Ressourcen benötigt.

Wie stellt der Okta Local Authentication Service die Verfügbarkeit sicher?

Um den Engpass bei der Ausfallsicherheit von Identitäten zu beheben, hat Okta den Okta Local Authentication Service entwickelt, der in das Okta Access Gateway (OAG) integriert ist. OAG ist eine lokalisierte Gateway-Appliance, die on-premise oder in einer hybriden Cloud bereitgestellt wird. 

In dieser Architektur ist OAG kein einfacher Reverse-Proxy, der den Datenverkehr filtert, authentifiziert und an Anwendungen weiterleitet; stattdessen fungiert es als primärer Identity-Anbieter für lokale Unternehmensanwendungen unter Verwendung von SAML und OIDC.

Wie Okta Access Gateway bei Ausfällen die lokale Authentifizierung aufrechterhält

Die Mechanismen des Offline-Übergangs

1. Kontinuierliche Integritätsüberwachung: OAG überwacht den Verbindungsstatus zum vorgeschalteten Okta Cloud-Tenant kontinuierlich über konfigurierbare Health-Check-Intervalle.
2. Ausfallerkennung: Wenn der Verbindungsfehler den konfigurierten Fallback-Schwellenwert überschreitet, schaltet OAG die Zielanwendungen automatisch in den Disconnected Authentication-Modus um.
3. Lokale Überprüfung der Anmeldedaten: Anstatt die Benutzer:innen zum Okta Cloud-Tenant umzuleiten, präsentiert OAG eine lokalisierte, benutzerdefinierte, getrennte Anmeldeseite. Benutzer:innen geben ihre Anmeldedaten ein, die OAG direkt anhand eines lokalen Directory-Dienstes wie Active Directory (AD) oder Ressourcenschonendes Directory Access Protocol (LDAP) validiert, der über den Okta-AD/LDAP-Agenten mit der Cloud synchronisiert wird.
4. Lokale Richtliniendurchsetzung: OAG wertet lokale, nicht verbundene Authentifizierungsrichtlinien aus, um sicherzustellen, dass nur autorisierten Benutzergruppen während "Break-Glass"-Zeiträumen Zugriff auf kritische Apps gewährt wird.
5. Lokale Token-Generierung: OAG signiert kryptografisch SAML- oder OIDC-Token und stellt diese direkt von der lokalen Appliance für die Anwendung aus, wodurch ein ununterbrochener Session-Zugriff aufrechterhalten wird.
   

Was sind die Einschränkungen hybrider Edge-Architekturen?

Um WAN- und Cloud-Anbieter-Ausfälle abzumildern, ist für echte Operational Resilience eine mehrschichtige Strategie erforderlich. Während Okta sich auf die Absicherung der Identitätskontrollebene konzentriert, muss sich die zugrunde liegende Infrastruktur gleichzeitig anpassen – was Unternehmen dazu veranlasst, zunehmend eine hybride Edge-Topologie einzuführen, die Cloud-Infrastruktur direkt auf lokale, physische Standorte ausweitet. 

Ein primäres Beispiel für dieses Muster ist AWS Outposts, eine vollständig verwaltete Hybridlösungen, die native AWS-Dienste, APIs und Sicherheitstools direkt am on-premise-Standort von Kund:innen bereitstellt.

Ausfallsicherheitsmerkmale von AWS Outposts

Unter normalen Betriebsbedingungen verbindet sich AWS Outposts über eine aktive WAN-Verbindung oder AWS Direct Connect mit einer übergeordneten AWS-Region. Wenn sich lokale Netzwerkverbindungen jedoch verschlechtern, weist Outposts die folgenden architektonischen Verhaltensweisen auf:

Kontinuität der lokalen Ausführung: Anwendungen, die bereits auf dem Outpost-Rack laufen, werden weiterhin lokal ausgeführt. Sie bleiben für lokale Client-Geräte erreichbar.

• Latenz von unter 10 ms: Lokalisierte Systeme interagieren mit der Outpost-Infrastruktur mit einer Latenz im einstelligen Millisekundenbereich und umgehen so die typischen Cloud-Routing-Verzögerungen von 30 bis 100 ms.

Lokale Datenübertragung: Datenverkehr, der für lokale Datenbanken oder on-premise Legacy-Systeme bestimmt ist, wird vollständig über das LGW geleitet, wodurch eine Gefährdung durch WAN-Schwachstellen verhindert wird.

Edge-Einschränkungen 

Obwohl AWS Outposts einen Fortschritt für Hybrid-Cloud-Bereitstellungen darstellt, zeigt es eine grundlegende Einschränkung der Hybrid-Cloud auf: Es ist nicht für einen dauerhaften, isolierten Offline-Betrieb ausgelegt.

• Beeinträchtigte API-Steuerungsebene: Bei unterbrochener Verbindung sind lokale administrative Aktionen stark eingeschränkt. API-Aufrufe zum Ausführen, Starten, Stoppen oder Beenden von Instanzen schlagen fehl, da sich die Control Plane in der übergeordneten AWS-Region befindet.
• Grenzwerte für das Caching von Logs und Kennzahl: CloudWatch-Kennzahl und Systemprotokoll werden bei einem Ausfall lokal auf dem Outpost-Rack zwischengespeichert. Allerdings ist dieser Cache auf sieben Tage begrenzt. Wenn die Verbindung nicht innerhalb dieses Zeitfensters wiederhergestellt wird, gehen kritische Audit-Logs, Sicherheitskennzahlen und Statusindikatoren dauerhaft verloren.

Dies verdeutlicht eine zentrale technische Realität: Um die Business Continuity zu gewährleisten, können sich Unternehmen nicht einfach darauf verlassen, ihre Infrastruktur am Edge zu hosten. Sie benötigen außerdem eine resiliente, Edge-ausfallsichere Identity Control Plane, um Benutzer:in an diesen lokalen Systemen zu authentifizieren und zu autorisieren. 

Okta Access Gateway, das innerhalb einer AWS Outpost-Infrastruktur ausgeführt wird, kann bei einem WAN-Ausfall-Event Offline-Authentifizierung und Identität am Edge für kritische Infrastrukturen bereitstellen.

Wie konfigurieren Sie getrennte Authentifizierungsrichtlinien?

Die Einrichtung eines widerstandsfähigen Identitäts-Perimeters erfordert eine sorgfältige administrative Planung. OAG bietet granulare, lokalisierte Kontrollen, um sicherzustellen, dass Sicherheitsrichtlinien auch bei einer Unterbrechung der Verbindung zur Cloud-Telemetrie intakt bleiben.

Isoliertes Design der Authentifizierungs-Richtlinie

Administrator:innen können spezifische Regeln für Offline-Szenarien festlegen. Beispielsweise möchte eine Organisation den Offline-Zugriff möglicherweise auf hochgradig privilegiertes Notfallpersonal beschränken oder ein Fallback auf alternative Authentifikatoren sicherstellen.

Konfiguration getrennter Authentifizierungsrichtlinien in Okta Access Gateway

Benutzerdefinierte Markenorchestrierung

Bei einem WAN- oder Cloud-Ausfall stellt die Verwirrung der Benutzer:in ein erhebliches Betriebsrisiko dar. OAG ermöglicht es Administrator:innen, die Experience bei getrennter Verbindung zu individualisieren, um Benutzer:innen deutlich auf die geänderte Umgebung hinzuweisen:

• Eigenständiges Branding: Behalten Sie benutzerdefinierte Markenlogos und spezifische operative Farbpaletten bei.
• Kontextabhängige Warnungen: Wir empfehlen, spezielle für Benutzer:in sichtbare Indikatoren anzuzeigen, wie z. B. ein lokalisiertes Banner: "Von der Cloud getrennt: Die Optionen sind möglicherweise eingeschränkt." Diese einfache Ergänzung trägt dazu bei, Panik zu vermeiden, reduziert das Aufkommen an Helpdesk-Tickets und stellt sicher, dass die Mitarbeiter:innen die definierten Offline-Geschäftsprotokolle einhalten.

Automatische Schwellenwerte für Fallback und Wiederherstellung

Um "Flapping" zu verhindern – wobei eine stark instabile Internetverbindung dazu führt, dass OAG schnell zwischen dem Online- und Offline-Modus wechselt –, verwendet OAG eine Zustandserkennung mit zwei Schwellenwerten:

• Organisation-Prüfintervall: Die Häufigkeit, mit der OAG die Verfügbarkeit des Cloud-Tenant prüft (z. B. alle 60 Sekunden).
• Fallback-Schwellenwert: Die Anzahl der aufeinanderfolgenden fehlgeschlagenen Prüfungen, die erforderlich ist, um den getrennten Modus auszulösen (z. B. 2 Prüfungen).
• Wiederherstellungsschwellenwert: Die Anzahl der aufeinanderfolgenden erfolgreichen Prüfungen, die erforderlich ist, um wieder in den Online-Modus zu wechseln (z. B. 4 Prüfungen). Dieser konservative Wiederherstellungsparameter stellt sicher, dass die WAN-Verbindung vollständig stabil ist, bevor Authentifizierungs-Workloads zurück in die Cloud verlagert werden.

Resilienz ist eine Strategie, kein Feature.

Da Unternehmen ihre Cloud-Integrationen vertiefen, steigt das Risiko von Ausfällen bei Drittanbietern exponentiell an. Echte betriebliche Kontinuität lässt sich nicht erreichen, indem man sich ausschließlich auf Service Level Agreement (SLA) verlässt oder davon ausgeht, dass Cloud-Netzwerke unfehlbar bleiben.

Um ein erstklassiges, widerstandsfähiges Unternehmen aufzubauen, sollten Führungskräfte Ausfälle beim Design berücksichtigen. Offline-Zugriff sollte nicht als zweitrangige Option, sondern als essenzielle Architekturstrategie betrachtet werden. Durch die Implementierung von Edge-Plattform-Modellen, die Durchsetzung strenger Grenzen für geschäftliche Auswirkungen und den Einsatz von Technologie wie dem Okta Local Authentication Service kann das moderne Unternehmen Cloud-Grenzen souverän überschreiten – und so sicherstellen, dass sein Geschäft weiterläuft, selbst wenn die Welt offline geht.

Sind Sie bereit, Ihre Hybrid-Cloud-Grenze abzusichern?

Sie sollten nicht auf den nächsten WAN-Ausfall warten, um Ihre Disaster-Recovery-Pläne zu testen. Laden Sie unser Datenblatt zu Okta Access Gateway herunter, um zu erfahren, wie Sie den Zugriff auf Ihre On-Premise-Anwendungen sichern und Ihre Hybrid Cloud schützen können, ohne Ihren vorhandenen Code zu ändern.