Was ist BeyondCorp? Zero Trust für sicheren Zugriff ohne VPN
BeyondCorp ist ein Zero-Trust-Ansatz von Google, der „vertrauenswürdig“ nicht über den Netzwerkstandort definiert, sondern über Identität, Gerätezustand und Richtlinien. Ziel ist sicherer Zugriff auf Anwendungen und Cloud-Ressourcen, ohne dass ein VPN das zentrale Tor sein muss.
- Zugriff wird pro Anfrage entschieden, nicht pauschal „im Netzwerk“.
- Ideal für Remote Work, SaaS und Cloud-Zugriffe ohne Backhaul.
- BeyondCorp Enterprise (BCE) erweitert das Grundprinzip für den Unternehmenseinsatz.
Spannend wird das Thema, wenn VPN-Betrieb teuer ist, Ausnahmen eskalieren oder die Security im Alltag an Standortlogik hängt.
Du sorgst dafür, dass M365 läuft. Wir sorgen dafür, dass niemand unbemerkt eindringt, heimlich mitliest und Schaden anrichtet.
Definition
BeyondCorp ist ein von Google geprägter Zero-Trust-Ansatz, bei dem Zugriff nicht über das Netzwerk-Perimeter, sondern über Identität, Gerätezustand und Kontext autorisiert wird. Es ist kein VPN-Ersatz „mit neuem Namen“, sondern ein Policy-Modell für sicheren Zugriff auf Anwendungen und Ressourcen.
Einleitung
Wenn Teams hybrid arbeiten, werden VPNs schnell zum Engpass: Performance, Sonderfälle, unsaubere Ausnahmen und ein Sicherheitsmodell, das am Standort hängt. BeyondCorp dreht das um: Nicht das Netzwerk entscheidet, sondern wer du bist, wie dein Device aussieht und welche Policy gilt.
Was bedeutet „zero trust“ hier konkret?
„Zero trust“ heißt in diesem Kontext: Explizit prüfen, bevor Zugriff gewährt wird, und Vertrauen nicht dauerhaft „schenken“. Das passt zur Denke aus NIST Zero Trust Architecture: Autorisierung basiert auf Signalen, und diese werden kontinuierlich bewertet, nicht nur beim Login.
Der praktische Nutzen: Weniger pauschale Freigaben im Netzwerk, klarere Regeln pro Anwendung und weniger Risiko, dass ein kompromittierter Zugang automatisch „im internen Netz“ alles sieht.
Wie BeyondCorp grundsätzlich funktioniert
BeyondCorp setzt auf kontextbasierte Entscheidungen. Dafür werden Kontextinfos gesammelt (Identity, Device, Ort, Risiko/Signale), eine Autorisierung getroffen und anschließend laufend wieder überprüft.
Kontext: Benutzeridentität, Gruppen/Rollen, Gerätezustand (z. B. Compliance, Verifikation), Standort- oder Risikosignale.
Policy-Entscheidung: Zugriff wird per Richtlinie pro Application/Resource erlaubt, eingeschränkt oder blockiert.
Kontinuierliche Prüfung: Ändert sich der Kontext (z. B. Device nicht mehr compliant), wird Zugriff neu bewertet.
Statt „gesamten Datenverkehr“ über ein virtuelles Private Network zu ziehen, wird der Zugriff gezielt zu genau den Anwendungen gesteuert, die gebraucht werden. Das senkt Betriebsaufwand (weniger VPN-Troubleshooting) und reduziert die Angriffsfläche.
BeyondCorp vs. BeyondCorp Enterprise (BCE) vs. klassischer Remote Access
BeyondCorp beschreibt das Prinzip. BeyondCorp Enterprise (BCE) ist die Enterprise-Umsetzung für Unternehmen, typischerweise mit mehr Komponenten und Integrationen für Policy, Device-Signale und Access-Controls.
Klassischer Remote Access (meist VPN) baut auf Netzwerkvertrauen: Wer „drin“ ist, kann oft viel erreichen. BeyondCorp zielt auf application-zentrierten Zugriff: Jede Anwendung wird wie „Internet“ behandelt und separat abgesichert.
Typische technische Bausteine in Googles Approach sind BeyondCorp Remote Access sowie Komponenten wie Identity-Aware Proxy (IAP) und Endpoint Verification. In der Praxis hängt der Unterschied weniger am Namen, sondern daran, ob Policies wirklich pro Anwendung und pro Device durchgesetzt werden.
Typische Einsatzszenarien (und was es bringt)
BeyondCorp wird besonders relevant, wenn Zugriff heute über VPN, starre Netzsegmente oder „geht schon irgendwie“-Ausnahmen geregelt wird.
Remote Work ohne VPN: Zugriff auf SaaS und interne Web-Applications, ohne dass alles durchs Unternehmensnetzwerk muss.
Cloud-first-Organisationen: Wenn Anwendungen ohnehin in der Cloud liegen, ist ein Netzwerk-Perimeter als „Sicherheitsgrenze“ oft unlogisch.
Partner- und Drittzugriffe: Externe erhalten minimalen Access auf definierte Ressourcen statt Netzwerkzugang.
Mini-Story: Ein Team nutzt mehrere Cloud-Dienste, aber für eine interne Anwendung muss immer ein VPN aufgebaut werden. Ergebnis: Tickets, Verbindungsabbrüche, Workarounds. Mit BeyondCorp-Logik wird die Anwendung per Policy freigegeben, aber nur für identifizierte Benutzer und verifizierte Devices.
Voraussetzungen und Integrationsaspekte
Die Komplexität steckt selten in „einem Tool“, sondern in den Grundlagen. Ohne saubere Identitäten und Device-Disziplin wird BeyondCorp schnell zu einem Ausnahme-Management.
Identitätsanbieter: Einheitliche Identity, MFA/Conditional Access, saubere Rollen und Lifecycle-Prozesse.
Geräte-Compliance: Device Inventory, Verifikation/Compliance-Signale (bei Apple-Devices oft via MDM wie Jamf Pro/Jamf Cloud als Integration).
Richtlinien-Management: Policies müssen versioniert, getestet und betriebsfähig sein (sonst werden sie umgangen).
Wichtig für ROI: Je besser diese Grundlagen, desto weniger Betriebskosten durch Sonderfälle und desto messbarer wird der Sicherheitsgewinn.
Implementierungsoptionen und Rollout-Modelle
Es gibt grob zwei Wege: klassischer Remote Access „verbessern“ oder konsequent Richtung BCE/BeyondCorp Enterprise gehen. Der zweite Weg lohnt sich besonders, wenn viele Applications cloudbasiert sind und VPN nur noch als historisches Relikt existiert.
Rollout pragmatisch: Starte mit einer kleinen Gruppe und wenigen Anwendungen, die hohe Nutzung und klaren Nutzen haben. Danach Policies erweitern, Device-Signale schärfen und Ausnahmen abbauen. So bleibt der Ressourcenaufwand kontrollierbar und die Akzeptanz steigt.
Wann externe Unterstützung sinnvoll wird
Externe Hilfe ist sinnvoll, wenn Identitäts- und Geräte-Policies zwar existieren, aber niemand sie kontinuierlich betreibt und misst. Typische Trigger sind: zu viele Ausnahmen, fehlende Device-Compliance, unklare Ownership für Richtlinien und keine belastbare Auswertung, ob Zugriff wirklich „sicher“ ist.
Fazit
BeyondCorp verlagert Zugriffskontrolle vom Netzwerk-Perimeter auf Identität, Device und Kontext und folgt damit einem konsequenten Zero-Trust-Modell. Das reduziert VPN-Abhängigkeit, verbessert Nutzererlebnis bei Remote-Arbeit und macht Zugriff auf Cloud- und SaaS-Anwendungen präziser steuerbar.
Für eine realistische Umsetzung sind saubere Identitäten, Geräte-Compliance und ein betreibbares Richtlinienmodell entscheidend. Der ROI kommt nicht aus „mehr Tools“, sondern aus weniger Sonderfällen, weniger Betriebsaufwand und klarer, messbarer Zugriffskontrolle.
Häufige Fragen
Ist BeyondCorp einfach ein VPN-Ersatz?
Nein. VPN ist primär ein Netzwerk-Tunnel (Remote Access), BeyondCorp ist ein Zero-Trust-Ansatz, der Zugriff pro Anwendung und pro Anfrage über Identität, Device und Policy steuert.
Ist BeyondCorp nur für Google Cloud relevant?
Der Ansatz kommt von Google und wird oft mit Google Cloud und BCE diskutiert, aber die Grundidee ist allgemeingültig: Access nicht am Netzwerkstandort festmachen, sondern an Kontextsignalen.
Warum gilt BeyondCorp als „zero trust“?
Weil Vertrauen nicht dauerhaft über „im internen Netzwerk“ entsteht, sondern explizit autorisiert und kontinuierlich überprüft wird, im Sinne der NIST Zero Trust Architecture.
Wie lässt sich ROI oder Erfolg messen?
Typisch sind weniger VPN- und Zugriffs-Tickets, weniger Ausnahmen/Firewall-Freigaben, klarere Nachvollziehbarkeit von Zugriffen und weniger „seitliche Bewegung“ durch zu breite Netzwerkberechtigungen.