Hybrides Zero Trust: Zugriffe zwischen Datacenter, AWS und OVHcloud absichern
Ihre Umgebungen sind jeweils für sich geschützt. Aber wer schützt die Zugriffe zwischen ihnen?
Ein Unternehmen kann sein Datacenter ordnungsgemäß absichern, seine AWS-Konten strukturieren, seine OVHcloud-Projekte isolieren und die Multi-Faktor-Authentifizierung aktivieren. Dennoch bleibt ein Zugriff gefährlich, wenn die Kontrollen nicht miteinander kommunizieren, wenn eine private Verbindung als Vertrauensbeweis behandelt wird oder wenn ein Dienstleister mehr Ressourcen erreichen kann als nötig. In einem hybriden Informationssystem liegt das Risiko oft weniger innerhalb jeder Umgebung als in der Art, wie sie miteinander verbunden sind.
Es geht nicht mehr nur darum, einen Perimeter zu schützen. Für jeden kritischen Zugriff muss das Unternehmen fünf einfache Fragen beantworten: Wer fordert den Zugriff an, von welchem Gerät oder Dienst aus, auf welche Ressource, nach welcher Richtlinie und mit welcher Widerrufsfähigkeit? Diese Logik gilt für Mitarbeitende und Administratoren, aber auch für Anwendungen, APIs, Pipelines und Workloads, die miteinander kommunizieren.
Dieser Artikel bietet eine operative Lesart von Zero Trust für ein Unternehmen, das ein Datacenter, Altanwendungen, AWS, OVHcloud und SaaS-Dienste kombiniert. Er stellt weder eine universelle Architektur noch einen Produktkatalog vor. Er zeigt, wie man einen kohärenten Rahmen aufbaut, die richtigen Kontrollpunkte auswählt, Verantwortlichkeiten organisiert und schrittweise voranschreitet, ohne den Betrieb zu stören.
Wenn das Risiko zwischen den Umgebungen entsteht
Stellen Sie sich Nova Industrie vor, ein fiktives KMU mit 180 Mitarbeitenden an drei Standorten. Sein Informationssystem stützt sich auf Active Directory, mehrere Vor-Ort-Fachanwendungen, Microsoft 365, zwei AWS-Konten für digitale Dienste und mehrere OVHcloud-Projekte. Remote-Arbeit ist verbreitet, und rund zehn Dienstleister übernehmen Wartung, Support und Entwicklung.
Das Unternehmen hat bereits in Sicherheit investiert: Multi-Faktor-Authentifizierung, Endpunktschutz, aktuelle Firewalls, VPN, Backups und teilweise zentralisierte Protokolle. Auf dem Papier wirkt jeder Baustein solide. Doch ein Dienstleisterkonto wird von einem unbekannten Gerät aus für eine VPN-Sitzung genutzt. Der Netzwerkzugriff bietet Einsicht in mehrere interne Adressen. Der Angreifer erreicht daraufhin einen Sprungserver, entwendet ein Anwendungsgeheimnis und versucht, einen in AWS gehosteten Dienst aufzurufen.
Keine Kontrolle fehlte vollständig. Das Problem lag darin, wie sie zusammenwirkten. Das VPN hatte das Konto authentifiziert, ohne den Nutzer auf die tatsächlich benötigten zwei Anwendungen zu beschränken. Der Zustand des Geräts, dem Schutzsystem bekannt, beeinflusste die Entscheidung nicht. Das Anwendungsgeheimnis war zu lange gültig. Und die Protokolle erlaubten es nicht, schnell die Identität des Dienstleisters, sein Gerät, die VPN-Sitzung, den Sprungserver und den Cloud-Aufruf miteinander zu verknüpfen.
Diese Frage verändert die Diskussion. Sie führt das Unternehmen weg von der Suche nach einem "Zero-Trust-Produkt" hin zu einem überprüfbaren Modell. Eine Lösung deckt möglicherweise den Nutzerzugriff ab, eine andere die Privilegien, eine dritte die Workload-Identitäten. Entscheidend ist die Konsistenz der Garantien und die Fähigkeit zu beweisen, dass eine Ressource keinen Umgehungsweg hat.
Warum ein hybrider IT-Bestand das traditionelle Modell unzureichend macht
In einer klassischen Umgebung stützte sich die Sicherheit lange auf eine einfache Unterscheidung: Das Außen galt als feindlich, das Innen als relativ vertrauenswürdig. Dieses Bild ist zu brüchig geworden. Ein Mitarbeitender kann sich bei einem SaaS-Dienst authentifizieren, bevor er auf eine Vor-Ort-Anwendung zugreift. Ein AWS-Workload kann eine API in OVHcloud aufrufen. Ein Administrator kann von einer privilegierten Arbeitsstation aus über eine Cloud-Konsole handeln, ohne dass der Datenverkehr je über das Datacenter läuft.
Identitäten sind nicht homogen
Ein Active-Directory-Nutzer, eine AWS-Rolle, eine OVHcloud-Dienstidentität, ein technisches Konto und ein Zertifikat folgen weder denselben Mechanismen noch demselben Lebenszyklus. Manche Identitäten sind namentlich zugeordnet, andere versehentlich geteilt, wieder andere in ein Skript eingebettet. Solange das Unternehmen nicht jede Anfrage einer menschlichen oder technischen Identität und einem Verantwortlichen zuordnen kann, bleibt die Zugriffsrichtlinie unvollständig.
Kontrollpunkte sind verteilt
Die Kontrolle kann durch einen ZTNA-Proxy, einen Agenten, ein Bastion-System, eine PAM-Lösung, ein API-Gateway, einen Service-Mesh, eine Firewall oder einen cloud-nativen IAM-Mechanismus durchgesetzt werden. Der Versuch, den gesamten Datenverkehr über einen einzigen Punkt zu leiten, schafft erneut einen Engpass, erhöht die Abhängigkeit und passt schlecht zur Cloud-Nutzung. Die Herausforderung besteht darin, die Regeldurchsetzung zu verteilen, ohne die Steuerung zu verlieren.
Signale stammen aus unterschiedlichen Systemen
Die Identität kommt vom Identitätsanbieter, der Gerätestatus von einem EDR oder MDM, die Kritikalität der Ressource aus einem Anwendungsinventar, das Verhaltensrisiko aus einem Erkennungswerkzeug und der Kontext aus einer Cloud-Engine. Eine Entscheidung ist nur dann wirklich kontextbezogen, wenn diese Signale zuverlässig, hinreichend aktuell und korrelierbar sind. Ein mehrere Tage alter Status kann keinen sensiblen Admin-Zugriff rechtfertigen.
Altanwendungen erzwingen Koexistenz
Nicht jede Anwendung unterstützt SAML, OIDC, kurzlebige Token oder ein modernes Gateway. Manche erfordern einen Thick Client, eine feste IP-Adresse oder ein veraltetes Protokoll. Die Transformation muss daher die Koexistenz organisieren: Föderation, wo möglich, Proxy oder ZTNA für Webanwendungen, VDI für nicht verwaltete Geräte, ein Bastion-System für die Administration und ein begrenztes VPN, wenn die Ausnahme noch notwendig ist.
Zero Trust als Entscheidung erklärt, nicht als Produkt
NIST SP 800-207 beschreibt eine logische Architektur, in der eine Policy Engine die Entscheidung trifft, ein Policy Administrator diese Entscheidung in eine Sitzungsaktion umsetzt und ein Policy Enforcement Point das Ergebnis anwendet. Diese Rollen sind logisch: Ein einzelnes Produkt kann mehrere davon erfüllen, und mehrere Technologien können zusammenwirken, um einen Anwendungsfall abzudecken.
In einem hybriden IT-Bestand ist eine einzige universelle Engine selten realistisch. Der bedingte Zugriff des Identitätsanbieters, PAM, ZTNA, cloud-native IAM-Richtlinien und Anwendungskontrollen übernehmen jeweils einen Teil der Entscheidungen. NIST SP 800-207A erweitert diese Logik auf cloud-native und Multi-Cloud-Umgebungen: Anwendungs- und Dienstidentität, API-Gateways, Proxys und Anwendungsidentitätsinfrastruktur werden ebenso wichtig wie die menschliche Identität.
Das Ziel ist nicht, dass jede Umgebung dieselbe Technologie verwendet. Sie müssen vergleichbare Garantien liefern: eine überprüfbare Identität, minimale Privilegien, einen nahe an der Ressource platzierten Kontrollpunkt, eine gesteuerte Richtlinie, verwertbare Protokollierung, effektive Widerrufbarkeit und ein bekanntes Verhalten im Störungsfall.
Die Prinzipien, die überall gelten müssen
- Das Netzwerk transportiert den Datenverkehr, gewährt aber niemals von sich aus Vertrauen.
- Jede Anfrage muss einer menschlichen oder technischen Identität und einem Verantwortlichen zugeordnet werden können.
- Die Richtlinie schützt eine bestimmte Ressource; der Zugriff auf eine Anwendung sollte kein ganzes Segment öffnen.
- Das Sicherheitsniveau muss der Kritikalität der Aktion und der Daten entsprechen.
- Die verwendeten Signale müssen überprüfbar, aktuell und zum Zeitpunkt der Entscheidung verfügbar sein.
- Der Durchsetzungspunkt muss so nah wie möglich an der Ressource liegen und darf nicht umgangen werden können.
- Die Steuerungsebene — Identität, PAM, Richtlinien, Zertifikate und Konsolen — muss als kritisches Gut behandelt werden.
- Jede kritische Kontrolle muss einen dokumentierten, getesteten und genehmigten Ausfallmodus haben.
Diese Prinzipien lassen sich auf jedes Projekt anwenden. Ein Team kann in AWS und in OVHcloud frei einen anderen Mechanismus wählen, muss aber die verwendete Identität, die angewandte Richtlinie, den Kontrollpunkt, die verfügbare Telemetrie und das erwartete Verhalten bei Ausfall eines der Signale oder Dienste nachweisen können.
Kontrollen entsprechend den tatsächlichen Datenflüssen platzieren
Eine Zero-Trust-Architektur beginnt nicht mit einem Produktdiagramm. Sie beginnt mit kritischen Datenflüssen: Wer greift auf was zu, warum, mit welchem Privilegierungsgrad und über welche Wege? Der richtige Kontrollpunkt hängt von der Ressource und dem Protokoll ab. Ein Anwendungsproxy kann für ein Webportal geeignet sein; er ersetzt weder PAM für die Administration noch die Workload-Identität für eine API.
| Prioritärer Datenfluss | Empfohlener Kontrollpunkt | Mindestsignale | Gewünschtes Ergebnis |
|---|---|---|---|
| Mitarbeitender zu Vor-Ort-Webanwendung | ZTNA oder Anwendungs-Reverse-Proxy | Identität, MFA, Status, Gruppe, Kritikalität | Auf die Anwendung beschränkter Zugriff, keine Segmentexposition |
| Dienstleister zu Admin-Tool | PAM, Bastion oder virtuelle Arbeitsstation | Drittanbieteridentität, Genehmigung, Zeitfenster, Gerät | Temporäre, protokollierte, widerrufbare Sitzung |
| Mitarbeitender zu AWS-Anwendung | Anwendungskontrolle oder nativer Dienst | Föderierte Identität, Status, Kontext | Kurzlebige Rolle und ressourcenabhängiger Zugriff |
| AWS-Workload zu OVHcloud-API | API-Gateway, mTLS oder Workload-Proxy | Dienstidentität, Zielgruppe, Umgebung | Feingranulare Autorisierung und kurzlebiges Geheimnis |
| Administrator zu Cloud-Konsole | IdP, Cloud-IAM und PAM | Getrenntes Admin-Konto, starke MFA, privilegierte Arbeitsstation | Nachverfolgte, genehmigte und schnell widerrufbare Aktion |
Anatomie einer Zugriffsentscheidung
Nehmen wir einen Dienstleister, der Zugriff auf ein Wartungswerkzeug benötigt. Der Kontrollpunkt erfasst seine Identität, den Gerätestatus, die Uhrzeit, das Risikoniveau und die angeforderte Ressource. Die Richtlinie verlangt eine aktive Drittanbieteridentität, phishing-resistente Authentifizierung, einen aktuellen Status und ein genehmigtes Interventionsfenster. Sind alle Bedingungen erfüllt, wird eine auf die Anwendung beschränkte Sitzung für eine kurze Dauer erstellt.
Ist das Gerät nicht verwaltet, sollte die Antwort nicht systematisch binär sein. Das Unternehmen kann eine virtuelle Arbeitsstation verlangen, einen Nur-Lese-Zugriff erlauben oder eine zusätzliche Validierung anfordern. Ein kritischer EDR-Alarm, das Vertragsende oder abnormales Verhalten sollte eine Neubewertung auslösen und gegebenenfalls eine bereits offene Sitzung beenden. Die tatsächliche Zeitspanne zwischen dem Ereignis und dem Widerruf wird dann zu einem Sicherheitsindikator.
Für jede kritische Ressource sollte der Verantwortliche eine einfache Frage beantworten können: Durch welchen Mechanismus werden alle Wege zu dieser Ressource kontrolliert? Eine Anwendung, die durch einen Proxy geschützt ist, aber weiterhin direkt über ihre private Adresse erreichbar ist, hat einen Umgehungsweg. Dies muss technisch überprüft werden, nicht aus einem Diagramm abgeleitet.
Drei mögliche Architekturmodelle
Die Wahl der Architektur hängt von der Reife, den verfügbaren Kompetenzen, der Vielfalt des Bestands und dem akzeptablen Abhängigkeitsgrad ab. Drei Familien kommen wiederholt vor. Keine ist perfekt; die Entscheidung sollte von Anwendungsfällen, Resilienz und Betriebsmodell geleitet werden.
| Kriterium | Integrierte Suite | Zentralisierte Best-of-Breed-Lösung | Föderation nach Anwendungsfall |
|---|---|---|---|
| Anfängliche Geschwindigkeit | Hoch | Niedrig bis mittel | Mittel |
| Heterogene Abdeckung | Mittel | Hoch | Hoch |
| Integrationskomplexität | Niedrig bis mittel | Sehr hoch | Pro Bereich gesteuert |
| Anbieterabhängigkeit | Hoch | Mittel | Niedrig bis mittel |
| Lokale Resilienz | Variabel | Zentralisierungsrisiko | Hoch, wenn Bereiche autonom bleiben |
| Erforderliche Steuerung | Mittel | Sehr hoch | Hoch |
Eine integrierte Hauptsuite
Das Unternehmen wählt einen dominanten Anbieter für Identität, Gerätestatus, Anwendungszugriff und einen Teil der Telemetrie. Dieser Ansatz beschleunigt oft die ersten Einführungen, reduziert die Anzahl der Integrationen und vereinfacht den Support. Er kann jedoch Altanwendungen, Workloads oder eine zweite Cloud unvollständig abdecken. Die vertragliche und technische Abhängigkeit muss von Anfang an geprüft werden.
Eine zentralisierte Best-of-Breed-Zusammenstellung
Jeder Bereich verwendet die als am besten geltende Technologie: IdP, EDR, PAM, ZTNA, Segmentierung, API-Sicherheit und Datenschutz sind getrennt, während eine zentrale Schicht Entscheidungen orchestriert. Die Abdeckung kann umfangreich sein, aber die Integration selbst wird zu einem zu entwerfenden, zu testenden und zu wartenden Produkt. Formate, Kennungen, APIs, Latenzen und Verantwortlichkeiten schaffen eine Komplexität, die manchmal die Betriebskapazität des Unternehmens übersteigt.
Eine nach Anwendungsfall föderierte Architektur
Das Unternehmen setzt eine gemeinsame Grundlage durch — Referenzidentitäten, Kritikalitätsstufen, Mindestanforderungen, Entscheidungsnachweise und Steuerung — und nutzt dann die für jede Umgebung geeignete Engine und den passenden Kontrollpunkt. Lokale Entscheidungen bleiben innerhalb eines gemeinsamen Rahmens autonom. Für eine Organisation, die ein Datacenter, AWS, OVHcloud und Anwendungslegacy kombiniert, ist dieser Ansatz oft der realistischste.
Das Modell in jede Umgebung übersetzen
Datacenter und Altanwendungen
Active Directory bleibt eine wesentliche Quelle für Identitäten und Gruppen, sollte aber nicht zur universellen Engine für jede Entscheidung werden. Kritischer Zugriff muss auch Status, Anwendungssensibilität, Kontext und Dauer berücksichtigen. Kompatible Anwendungen werden föderiert. Andere werden je nach Protokoll und Risikoniveau hinter einem Reverse-Proxy, einem ZTNA-PEP, einer virtuellen Arbeitsstation oder einem Bastion-System platziert.
Das Netzwerk behält eine wichtige Rolle. Es begrenzt die Kommunikation zwischen Zonen, schützt Steuerungsebenen und verhindert die Umgehung von Durchsetzungspunkten. Die Segmentierung sollte dennoch aus beobachteten Datenflüssen abgeleitet werden. Eine zu ehrgeizige Mikrosegmentierung, die vor der Entdeckung von Abhängigkeiten unternommen wird, verursacht Störungen und eine Anhäufung von Ausnahmen, die letztlich das gesamte System schwächen.
AWS
In AWS ermöglicht eine Multi-Konten-Strategie die Trennung von Workloads, Umgebungen, Protokollen und bestimmten Sicherheitsfunktionen. Diese Trennung ist eine nützliche Grenze, ersetzt aber nicht die Autorisierung. Rollen, Bedingungen, Ressourcenrichtlinien und Sitzungsdauer bestimmen, was eine Identität tatsächlich tun kann. Die menschliche Identität sollte vom Identitätsanbieter des Unternehmens föderiert werden, statt kontoweise neu erstellt zu werden.
Für Anwendungen kann AWS Verified Access je nach Anwendungsfall und Dienstverfügbarkeit Anfragen anhand von Identität und Status bewerten, ohne ein traditionelles VPN vorauszusetzen. Andere Architekturen stützen sich auf eine Anwendungskontrolle, einen Load Balancer, ein API-Gateway oder VPC Lattice. Für Workloads sollten Rollen und Dienstidentitäten statischen Schlüsseln vorgezogen werden. Privilegierter Zugriff nutzt temporäre Rollen, und Protokolle werden in einem separaten Bereich zentralisiert.
OVHcloud
In OVHcloud sollten Public-Cloud-Projekte Umgebungen oder Kritikalitätsstufen nachvollziehbar trennen. Menschliche Rechte werden, wo Dienst und Kontext es erlauben, über IAM-Richtlinien begrenzt. Technische Identitäten sollten sich nicht auf geteilte persönliche Anmeldedaten stützen. Jedes Dienstkonto benötigt einen Verantwortlichen, einen Geltungsbereich, eine Dauer und ein Widerrufsverfahren.
vRack bietet eine nützliche private Konnektivität zwischen Ressourcen und Standorten, ist aber kein Autorisierungsnachweis. Datenverkehr, der über ein privates Netzwerk läuft, muss weiterhin authentifiziert, gefiltert und protokolliert werden. Für APIs und Workload-zu-Workload-Kommunikation tragen Dienstidentität, mTLS, kurzlebige Token oder ein Anwendungsgateway dazu bei, das implizite Vertrauen zu reduzieren, das einer IP-Adresse und einem Segment gewährt wird.
Was den drei Umgebungen gemeinsam ist
Die Umsetzung wird nicht identisch sein, und das ist in Ordnung. Die Zugriffskontrolle der Nutzer im Datacenter, eine AWS-IAM-Richtlinie und eine OVHcloud-Dienstidentität verwenden unterschiedliche Mechanismen. Sie müssen dennoch anhand derselben Fragen bewertet werden: Ist die Identität überprüfbar? Ist der Geltungsbereich minimal? Ist die Sitzung begrenzt? Hat die Ressource einen Umgehungsweg? Können Ereignisse korreliert werden? Funktioniert der Widerruf tatsächlich?
Altanwendungen: vorankommen, ohne den Betrieb zu blockieren
Zero Trust erfordert nicht, sofort jede Altanwendung zu ersetzen. Es erfordert, Ausnahmen sichtbar, begrenzt und temporär zu machen. Eine alte Webanwendung kann hinter einem Reverse-Proxy platziert werden. Ein von einem Dienstleister genutzter Thick Client kann über eine virtuelle Arbeitsstation bereitgestellt werden. Eine sensible Konsole kann über ein Bastion-System oder PAM laufen. Eine vollständig inkompatible Anwendung kann ein VPN behalten, sofern es segmentiert und auf das strikte Minimum begrenzt ist.
| Übergangsmodell | Geeignet für | Nutzen | Vorsichtspunkt |
|---|---|---|---|
| Native Föderation | SAML- oder OIDC-Anwendung | Zentralisierte Identität und Lebenszyklus | Anwendungsentwicklung und Tests |
| Reverse-Proxy / ZTNA | Alte Webanwendung | Schneller, anwendungsspezifischer Zugriff | Interne Sichtbarkeit manchmal begrenzt |
| VDI / virtuelle Arbeitsstation | Thick Client oder Drittanbietergerät | Verwaltete Umgebung und eingegrenzte Daten | Kosten, Kapazität und Nutzererfahrung |
| Bastion / PAM | Server- oder Datenbankadministration | Temporäre, nachverfolgbare Sitzung | Kritischer Punkt, der resilient gemacht werden muss |
| Begrenztes VPN | Temporäre inkompatible Ausnahme | Kontinuität während der Migration | Geltungsbereich, Verantwortlicher und Enddatum verpflichtend |
Ein verbleibendes VPN ist nicht automatisch ein Misserfolg. Es wird zu einem, wenn es keinen Geltungsbereich, keinen Verantwortlichen, keine kompensierende Kontrolle und kein Enddatum hat. Jede Ausnahme sollte in einem Register mit der betroffenen Ressource, dem akzeptierten Risiko, temporären Kontrollen, dem Verantwortlichen und dem nächsten Überprüfungsdatum erfasst werden.
Resilienz vor Blockierung gestalten
Entscheidungskomponenten werden betriebskritisch. Eine Architektur, die bei jeder kleinen Störung den gesamten Betrieb blockiert, wird von den Teams umgangen. Umgekehrt hebt eine Architektur, die alles zulässt, sobald ein Signal verschwindet, ihre eigene Sicherheit auf. Das Ausfallverhalten muss pro Ressource und pro Aktion definiert und vor der Ausweitung getestet werden.
Die Nichtverfügbarkeit des Identitätsanbieters kann dazu führen, neue sensible Sitzungen zu verweigern, während bestimmte bereits validierte Sitzungen für eine begrenzte Dauer aktiv bleiben. Das Fehlen eines aktuellen EDR-Signals kann eine virtuelle Arbeitsstation oder einen Nur-Lese-Zugriff erfordern. Die Nichtverfügbarkeit der Policy Engine kann eine restriktive lokale Regel auslösen oder eine zwischengespeicherte Entscheidung für einen häufigen Fall verwenden. Ein Ausfall zwischen Clouds kann wiederholbare Vorgänge in eine Warteschlange stellen und nicht wiederholbare Transaktionen sauber stoppen.
Die Wahl zwischen Fail-Open und Fail-Closed ist nicht nur eine Sicherheitspräferenz. Das Durchsuchen eines Katalogs, das Bearbeiten sensibler Daten und das Ändern der Produktion haben nicht dieselben Auswirkungen. Die Entscheidung muss die geschäftliche Kritikalität, die Fähigkeit zur Missbrauchserkennung, die Dauer des Ausfallmodus und kompensierende Kontrollen berücksichtigen. Notfallkonten müssen, wenn nötig, geschützt, überwacht und getestet werden; ein dem tatsächlichen Prozess unbekanntes "Break-Glass"-Konto ist keine Absicherung.
Ein realistischer Fahrplan in vier Wellen
Die Transformation sollte einen vollständigen Anwendungsfall liefern, bevor eine globale Abdeckung angestrebt wird. Jede Welle hat Eintrittskriterien, ein Pilotprojekt, eine Beobachtungsphase vor der Durchsetzung, ein Rollback und Austrittskriterien. Diese Disziplin reduziert Störungen und ermöglicht es, eine tatsächliche Risikominderung nachzuweisen.
Welle 0 — Abhängigkeiten sichtbar machen
Das Unternehmen inventarisiert Anwendungen, Identitäten, Privilegien, Wege, Workloads und Verantwortliche. Es identifiziert kritische Ressourcen, Umgehungswege und die Komponenten, von denen die Zugriffsentscheidung abhängt. Das erwartete Ergebnis ist keine perfekte CMDB, sondern eine hinreichend zuverlässige Karte, um einen ersten Anwendungsfall zu wählen und zu vermeiden, einen Weg zu schützen, während ein anderer offen bleibt.
Welle 1 — einen vollständigen Ablauf schützen
Ein guter Pilot betrifft oft Dienstleister, da das Risiko leicht erkennbar und der Umfang überschaubar ist. Zwei Anwendungen können mit namentlicher Identität, MFA, Status, ZTNA, Protokollierung, Support und Widerruf migriert werden. Die zugehörige Administration muss in den Piloten einbezogen werden, etwa mit PAM oder einem Bastion-System, damit der Geschäftsanwendungsfall nicht abgesichert wird, während der privilegierte Weg offen bleibt.
Welle 2 — nach Familie industrialisieren
Das Unternehmen definiert reproduzierbare Modelle für fünf Familien: moderne Anwendung, alte Webanwendung, Administration, API und Workload. Jedes Modell legt Identität, Kontrollpunkt, verpflichtende Signale, Protokollierung, Ausfallmodus und Verantwortlichkeiten fest. Ersetzte VPN-Wege werden entfernt; verbleibende Ausnahmen werden datiert und nachverfolgt.
Welle 3 — auf Cloud-Datenflüsse und Daten ausweiten
Dienstidentitäten werden verallgemeinert, die Kommunikation zwischen AWS, OVHcloud und dem Datacenter wird gestärkt, und Richtlinien entwickeln sich anhand der Datenklassifizierung weiter. Das Unternehmen testet Versuche seitlicher Bewegung, abgelaufene Zertifikate, falsche Zielgruppen, Aufrufe von einem anderen Workload und vorübergehende Nichtverfügbarkeit des ausstellenden Mechanismus. Der technische Nachweis stimmt dann mit den Risikoszenarien überein.
Kriterien für den Übergang zwischen den Wellen
- Der geschäftliche und der technische Verantwortliche der Ressource sind identifiziert.
- Alle normalen und alternativen Wege zur Ressource wurden inventarisiert.
- Der Support weiß, wie mit einer falschen Ablehnung, einem Gerätewechsel und einem verlorenen Authentifikator umzugehen ist.
- Ausfallmodus und Rollback wurden mit den beteiligten Teams getestet.
- Protokolle ermöglichen es, Identität, Gerät oder Workload, Sitzung, Entscheidung und Ressource zu verknüpfen.
- Nutzen und Reibung werden während des Piloten gemessen, bevor zur Durchsetzung übergegangen wird.
Richtlinien steuern und Verantwortlichkeiten verteilen
Eine Zero-Trust-Richtlinie ist keine technische Regel, die einem isolierten Administrator überlassen wird. Sie umfasst das Geschäft, die Sicherheitsarchitektur, Identität, Netzwerk, Cloud-Teams, Support und das SOC. Der geschäftliche Verantwortliche definiert die Kritikalität und legitime Nutzungen. Die Sicherheitsarchitektur definiert den Rahmen. IAM-, ZTNA- oder PAM-Plattformen konfigurieren die Mechanismen. Cloud- und Netzwerkteams setzen Kontrollen in ihren Bereichen durch. Das SOC überwacht und fordert bei sich änderndem Risiko einen Widerruf an.
Der Lebenszyklus einer Richtlinie umfasst mindestens Entwurf, Simulation, Genehmigung, Pilot, Bereitstellung, Beobachtung und Überprüfung. Ein Register sollte die beteiligte Engine, die Ressource, die verwendeten Attribute, die Version, den Verantwortlichen, Ausnahmen und Tests festhalten. Ohne dieses Register können mehrere technisch korrekte Regeln widersprüchlich werden oder weiterhin gelten, nachdem der Bedarf verschwunden ist.
In einem KMU kann dieselbe Person mehrere Rollen innehaben. Das ändert nichts an der Notwendigkeit, sie zu unterscheiden. Ein Dienstleister, der eine Regel vorschlägt, sollte nicht der Einzige sein, der das geschäftliche Risiko validiert. Ein Team, das die Plattform administriert, sollte nicht der Einzige sein, der Alarme interpretiert. Ziel ist es, Grauzonen zu vermeiden, nicht schwerfällige Bürokratie zu schaffen.
Indikatoren, die zur Geschäftsleitung sprechen
Die Anzahl der "integrierten" Anwendungen reicht nicht aus. Eine Anwendung kann als geschützt gezählt werden, während sie weiterhin über einen direkten Weg erreichbar ist. Indikatoren müssen die Entscheidungsqualität, die Abdeckung kritischer Ressourcen, die Widerrufsfähigkeit und die für Nutzer entstehende Reibung messen.
- Abdeckung kritischer Ressourcen durch einen Kontrollpunkt ohne Umgehungsweg.
- Anteil sensibler Entscheidungen mit einem hinreichend aktuellen Statussignal.
- Prozentsatz privilegierter Zugriffe mit einer separaten, temporären, nachverfolgten Identität.
- End-to-End-Widerrufszeit, unter realen Bedingungen gemessen.
- Rate falscher Ablehnungen und mediane Lösungszeit durch den Support.
- Anteil der Workloads, die eine kurzlebige Identität statt eines statischen Geheimnisses verwenden.
- Verfügbarkeit der Steuerungsebene und Ergebnisse der Ausfallmodus-Tests.
- Anzahl, Alter und Kritikalität der Ausnahmen, mit Verantwortlichem und Enddatum.
Jeder Indikator benötigt eine Quelle, eine Formel, eine Häufigkeit, ein Ziel und einen Verantwortlichen. Die Geschäftsleitung muss nicht jedes technische Ereignis verfolgen. Sie muss erkennen können, ob der kritische Zugriff nachvollziehbarer wird, ob die potenzielle Ausbreitung abnimmt, ob Privilegien kurzlebiger werden und ob die Transformation für die Teams tragfähig bleibt.
Die Fehler, die das Projekt schwächen
Das private Netzwerk als Vertrauensbeweis behandeln
VPN, Peering, vRack und dedizierte Verbindungen reduzieren die öffentliche Exposition, beweisen aber weder die Identität noch die Autorisierung eines Datenflusses. Die private Konnektivität muss ein Transportmechanismus bleiben. Der Zugriff wird durch eine Identität, eine Richtlinie und eine für die Ressource geeignete Kontrolle gewährt.
Nutzer schützen und Workloads vergessen
Ein statischer Schlüssel, der in einer Pipeline gespeichert ist, kann alle Kontrollen umgehen, die Mitarbeitenden auferlegt werden. Dienste, Skripte und Bereitstellungsketten benötigen eine zuordenbare technische Identität mit minimalem Geltungsbereich und kurzer Dauer. Erneuerung und Widerruf sind Teil der Architektur, nicht nur des Betriebs.
Einen Kontrollpunkt installieren und einen direkten Weg offen lassen
Ein Angreifer wählt den am wenigsten kontrollierten Pfad. Den Schutz der öffentlichen URL einer Anwendung zu gewährleisten reicht nicht aus, wenn der Server weiterhin von einem großen internen Segment aus erreichbar ist. Das Schließen von Umgehungswegen muss Teil der Austrittskriterien des Piloten sein.
Produkte stapeln ohne gemeinsames Vokabular
Lokale Regeln können inkonsistent werden, wenn Kritikalitätsstufen, Kennungen, Verantwortliche und Ausfallverhalten nicht aufeinander abgestimmt sind. Das Unternehmen benötigt einen gemeinsamen Rahmen, bevor eine Orchestrierungsschicht hinzugefügt wird. Andernfalls erhöht jede Integration die betriebliche Verschuldung.
Support und Nutzererfahrung vernachlässigen
Falsche Ablehnungen, Gerätewechsel, verlorene Authentifikatoren und dringende Eingriffe sind vorhersehbar. Ohne Verfahren werden Teams gemeinsame Konten erstellen, dauerhafte Ausnahmen beantragen oder zu weitreichende Zugriffe wieder aktivieren. Der Support ist daher selbst eine Sicherheitskomponente.
Kurze Selbsteinschätzung: Ist Ihre Architektur wirklich konsistent?
Diese Selbsteinschätzung liefert keinen Compliance-Score. Sie hilft festzustellen, ob das Unternehmen über die nötigen Grundlagen verfügt, um einen Piloten zu starten, oder ob es zunächst die Sichtbarkeit verbessern sollte. Antworten Sie mit Ja, Teilweise, Nein oder Weiß nicht.
- Können Sie die Ressourcen benennen, deren Nichtverfügbarkeit oder Kompromittierung die größten Auswirkungen hätte?
- Wissen Sie, welche menschlichen und technischen Identitäten jede dieser Ressourcen erreichen können?
- Ist der Dienstleisterzugriff auf die notwendigen Anwendungen, eine Dauer und ein genehmigtes Zeitfenster begrenzt?
- Beeinflusst der Status des Geräts oder Workloads tatsächlich sensible Entscheidungen?
- Unterliegen private Verbindungen zwischen Standorten und Clouds weiterhin einer Authentifizierung und Autorisierung auf Anwendungsebene?
- Können Sie nachweisen, dass eine geschützte Ressource keinen Umgehungsweg hat?
- Wird die End-to-End-Widerrufszeit eines Zugriffs oder einer Sitzung gemessen?
- Wurden die Ausfallmodi für Identität, Richtlinien und Protokollierung getestet?
Mehrere "Nein"- oder "Weiß nicht"-Antworten bedeuten nicht, dass Sie sofort eine neue Plattform kaufen müssen. Sie weisen in der Regel auf die Priorität hin: Ressourcen, Datenflüsse, Identitäten und Verantwortliche klären, bevor der erste Anwendungsfall gewählt wird. Ein guter Fahrplan beginnt mit Sichtbarkeit und einer gemeinsamen Risikoentscheidung.
Fazit: Konsistenz suchen, nicht Einheitlichkeit
Eine erfolgreiche hybride Zero-Trust-Architektur repliziert nicht dasselbe Werkzeug in jeder Umgebung. Sie organisiert die Konsistenz der Entscheidungen. Das Datacenter, AWS und OVHcloud können unterschiedliche Mechanismen verwenden, solange jeder in der Lage ist, das Subjekt zu identifizieren, die richtigen Signale zu bewerten, die Ressource mit einem Kontrollpunkt zu schützen, Nachweise zu erbringen und auf Widerruf oder Ausfall zu reagieren.
Die Rolle des Architekten besteht darin, diese Konsistenz explizit zu machen: die Prinzipien definieren, die Durchsetzungspunkte wählen, die Zentralisierung abwägen, Altanwendungen behandeln, Ausfallmodi gestalten und Verantwortlichkeiten zuweisen. Für ein KMU liefert eine föderierte, schrittweise Architektur konkrete Ergebnisse, ohne ein unverhältnismäßiges Programm zu starten oder von einer umfassenden Transformation des Informationssystems abhängig zu sein.
Das erwartete Ergebnis ist kein endgültiges Diagramm. Es ist eine operative Fähigkeit: Jeder kritische Zugriff kann erklärt, durchgesetzt, beobachtet, widerrufen und getestet werden, unabhängig davon, welche Umgebung die Ressource beherbergt. Diese Fähigkeit ist es, die das Ausbreitungsrisiko verringert, Drittzugriffe absichert und der Geschäftsleitung einen zuverlässigeren Überblick über ihre Exposition verschafft.
FAQ
Muss man jedes VPN entfernen, um Zero Trust einzuführen?
Nein. Ein VPN kann für bestimmte Protokolle oder Anwendungen weiterhin notwendig sein. Es sollte jedoch begrenzt, segmentiert, an eine starke Identität gebunden und in einen Fahrplan eingebettet sein. Das Problem ist nicht seine Existenz, sondern das zu weitreichende Vertrauen, das es nach der Authentifizierung eröffnen kann.
Reicht eine private AWS-OVHcloud-Verbindung aus?
Nein. Sie reduziert die Exposition gegenüber dem Internet, beweist aber weder die Identität des Dienstes noch die Autorisierung des Aufrufs. Die Architektur muss eine Workload-Identität, eine Autorisierung auf Anwendungsebene, Protokollierung und eine für den Datenfluss geeignete Widerrufsfähigkeit hinzufügen.
Braucht man eine einzige Policy Engine?
Nicht notwendigerweise. In einem hybriden IT-Bestand sind mehrere Engines oft realistischer: Identität, ZTNA, PAM, Cloud-IAM und Anwendungskontrollen. Die Herausforderung besteht darin, sie um konsistente Prinzipien, ein Kritikalitätsvokabular, Verantwortliche und Nachweise herum zu föderieren.
Mit welchem Anwendungsfall sollte man beginnen?
Wählen Sie einen Datenfluss mit hohem Risiko und überschaubarem Umfang: Dienstleisterzugriff auf zwei Anwendungen, Administration eines kritischen Dienstes oder Kommunikation zwischen zwei Workloads. Der Pilot sollte Identität, Richtlinie, den Durchsetzungspunkt, Protokolle, Support, Widerruf und Ausfallmodus abdecken.
Welche Rolle spielt ARCrezo bei einem solchen Projekt?
ARCrezo arbeitet an seinem Kerngebiet: Netzwerkarchitektur, Segmentierung, Firewalls, VPN, Fernzugriff, Datenflüsse zwischen Standorten und hybride Datenflüsse, Dokumentation und Fahrplanvorbereitung. IAM, PAM, EDR, Anwendungssicherheit oder umfassende Compliance-Bereiche können je nach Kontext ergänzende Spezialisten erfordern.
Wichtigste Referenzen
Redaktioneller Hinweis: Cloud-Dienste, ihre Funktionen und ihre Verfügbarkeit ändern sich im Laufe der Zeit. Architekturentscheidungen sollten anhand der offiziellen Dokumentation bestätigt und für die zum Projektzeitpunkt für das Unternehmen geltenden Regionen, Angebote und Einschränkungen validiert werden.
- NIST SP 800-207 — Zero Trust Architecture (2020)
- NIST SP 800-207A — Zero Trust for Cloud-Native and Multicloud Applications (2023)
- NIST SP 1800-35 — Implementing a Zero Trust Architecture, finale Version (2025)
- AWS Security Reference Architecture
- AWS Verified Access
- OVHcloud — Best Practices für Public-Cloud-Sicherheit
- OVHcloud — IAM-Richtlinien
- OVHcloud — Public Cloud vRack