Google baute Jahre an den Zero-Trust-Grundlagen
Für die meisten Grundlagen von Google BeyondCorp, einem Sicherheitsmodell mit Zugriffsentscheidungen nach Nutzer und Gerät, brauchte Google mehrere Jahre. Im Juni 2019 verbesserte das Unternehmen die Umsetzung weiterhin. Anderen Organisationen riet Google zu einem kleinen Einstieg. Die Ausweitung folgt erst nach geprüfter Zuverlässigkeit.
Das Wichtigste in Kürze
- Google benötigte mehrere Jahre für die meisten Grundlagen von BeyondCorp. Im Dezember 2014 lief die Migration noch, im Juni 2019 verbesserte Google die Umsetzung weiterhin.
- Der Rollout wuchs stufenweise aus einem lokalen Pilotprojekt. In den Monaten vor dem Sommer 2017 entfielen 0,3 Prozent aller von Googles technischem Support bearbeiteten Probleme auf BeyondCorp.
- Unzuverlässige Mitarbeiter- und Gerätedaten konnten falsche Zugriffsentscheidungen auslösen. Google bereinigte seine Daten vor folgenreichen Änderungen.
Verwandt: Black October: Viele Angriffe liefen seit Monaten
Ausgangslage bei Google
Vor BeyondCorp schützte Google seine internen Systeme über einen Netzwerkperimeter. Gemeint ist die klassische Abschottung, bei der das Firmennetz als vertrauenswürdige Zone gilt und Beschäftigte von außen per VPN zugreifen, also über einen verschlüsselten Tunnel ins Unternehmensnetz.
Rückblickend begründete Google den Umbau im Juni 2019 mit Produktivitätsproblemen beim VPN-Zugriff, mit der zunehmenden Nutzung der Cloud sowie mit verwundbaren oder kompromittierten Geräten innerhalb des Perimeters. Die Antwort hieß BeyondCorp, Googles Umsetzung von Zero Trust. Der Begriff steht für ein Modell, das dem internen Netz kein Grundvertrauen einräumt.
Im Stand vom Dezember 2014 authentifizierte, autorisierte und verschlüsselte BeyondCorp Unternehmenszugriffe anhand des Gerätezustands und der Zugangsdaten des Nutzers. Der Netzwerkstandort, an dem der Perimeter ansetzt, war für diese Entscheidung unerheblich.
Was ist Zero Trust? Zero Trust bezeichnet ein Sicherheitsmodell, das Zugriffe auf Unternehmenssysteme nicht allein deshalb erlaubt, weil sie aus dem internen Netz kommen. Jede Zugriffsentscheidung stützt sich auf Merkmale wie die Identität des Nutzers und den Zustand seines Geräts. Googles BeyondCorp setzte dieses Prinzip im Stand vom Dezember 2014 mit Prüfungen von Gerätezustand und Nutzerzugangsdaten um.
Zeitachse der Umstellung
Im Dezember 2014 lief die Migration noch. Als verbleibende Herausforderung galten Fat-Client-Anwendungen mit proprietären Protokollen. Das sind lokal installierte Programme, die über herstellereigene Kommunikationswege mit ihren Servern sprechen. Google fasste sie unter einer langen Reihe verbleibender Arbeitsabläufe zusammen.
Im Sommer 2017 beschrieb Google den Rollout als Abfolge von Stufen. Er begann mit einem lokalen Pilotprojekt und reichte bis zu riskanteren Arbeitsabläufen und entfernten Standorten. Geschäftskritische Abläufe migrierte Google erst, nachdem die Vorstufen erfolgreich verlaufen waren.
Im Juni 2019 zog Google Bilanz. Für die meisten Grundlagen hatte das Unternehmen mehrere Jahre gebraucht. Zu diesem Zeitpunkt verbesserte Google die Umsetzung weiterhin.
Entscheidungen und Rückhalt der Führung
Früh im Projekt sicherte sich Google die Unterstützung der eigenen Führung. Diese Zustimmung überprüfte das Unternehmen im weiteren Verlauf fortlaufend neu.
Eine zweite Entscheidung betraf die Datenbasis. Unzuverlässige Mitarbeiter- und Gerätedaten konnten in BeyondCorp falsche Zugriffsentscheidungen auslösen und die Verwundbarkeit erhöhen. Google bereinigte seine Daten, bevor es folgenreiche Änderungen vornahm.
Nach Angaben von InformationWeek vom April 2016 machten Google fehlerhafte Gerätekennungen zu schaffen sowie Inventardaten, die nach Reparaturen veraltet waren. Inventardaten sind die Einträge im Geräteverzeichnis eines Unternehmens. Google reagierte mit verbesserten Arbeitsabläufen, automatisierter Prüfung der Eingaben und doppelter Erfassung nach dem Vorbild der doppelten Buchführung.
Ergebnis und Betriebsfolgen
In den Monaten vor dem Sommer 2017 entfielen 0,3 Prozent aller Probleme, die Googles technischer Support bearbeitete, auf BeyondCorp. Die lange Einführung verband sich bei Google so mit einer schrittweisen Ausweitung und einem begrenzten Anteil migrationsbedingter Supportfälle.
Mit dem Modell wuchs die Bedeutung der zentralen Infrastruktur. Weil jede Anfrage diese Dienste durchlief, mussten Googles zentrale BeyondCorp-Systeme global zuverlässig und ausfallsicher arbeiten. Beeinträchtigungen trafen die Produktivität der Beschäftigten.
Folgerungen für CISOs im DACH-Raum
Aus dem Verlauf bei Google und den Empfehlungen von Google und NIST ergeben sich vier Folgerungen für Sicherheitsverantwortliche in Deutschland, Österreich und der Schweiz.
- Planungshorizont. Google benötigte für die meisten Grundlagen mehrere Jahre. Ein Zero-Trust-Programm gehört daran gemessen als Mehrjahresvorhaben in Budget und Roadmap.
- Rückhalt der Führung. Google holte die Unterstützung der Führung früh ein und prüfte sie fortlaufend neu. Für ein Vorhaben dieser Dauer liegt es nahe, die Zustimmung als wiederkehrenden Prüfpunkt im Programm zu führen.
- Bestand vor Regeln. Nach Empfehlung des US-Standardisierungsinstituts National Institute of Standards and Technology (NIST) vom August 2020 steht vor einer Zero-Trust-Einführung eine Bestandsaufnahme der eigenen Umgebung. Zusammen mit Googles Erfahrung mit unzuverlässigen Mitarbeiter- und Gerätedaten folgt daraus, Inventar und Identitätsdaten zu bereinigen, bevor Zugriffsregeln darauf aufbauen.
- Kleiner Einstieg. Google empfahl, mit wenigen Ressourcen, Anwendungen, Nutzern und Geräten zu beginnen und erst nach bestätigter Zuverlässigkeit auszuweiten. Im eigenen Rollout kamen geschäftskritische Abläufe erst nach erfolgreichen Vorstufen an die Reihe, ein Muster, das sich auf Programme im DACH-Raum übertragen lässt.
Häufige Fragen
Jede Frage ist verschlossen. Ein Tippen entriegelt die Antwort.
Wie ging Google mit Arbeitsabläufen um, die noch nicht zu BeyondCorp passten?
Bis Dezember 2014 hatte Google einen Prozess für befristete Migrationsausnahmen eingerichtet. Nutzer konnten darüber Arbeitsabläufe geltend machen, die noch nicht mit BeyondCorp kompatibel waren. Voraussetzung war eine entsprechende Genehmigung.
Was gehört vor Zero Trust in die Bestandsaufnahme?
Nach Empfehlung von NIST vom August 2020 sollen Organisationen vorab Geräte und andere Ressourcen, Nutzer, Geschäftsprozesse, Verkehrsflüsse und Abhängigkeiten identifizieren und katalogisieren. Diese Erfassung bildet nach NIST eine Grundkompetenz vor der Einführung.
Löst Zero Trust den klassischen Perimeter vollständig ab?
Nach Erwartung von NIST vom August 2020 werden die meisten Unternehmen auf unbestimmte Zeit in einem hybriden Betrieb aus Zero-Trust- und perimeterbasierten Verfahren arbeiten. Die Einführung soll nach NIST schrittweise erfolgen.
Lesetipps der Redaktion
LesetippLinux-Kernel-Lücke: Ubuntu liefert noch keinen PatchLesetippCisco-VPN wird angegriffen: Wer jetzt patchen mussLesetippKI-Agenten brauchen begrenzte Vollmachten
Bildquelle: KI-generiert (November 2026)
Mehr aus dem MBF Media Netzwerk
cloudmagazinCloud-Souveränität könnte 115 Milliarden Euro kosten
MyBusinessFutureKI-Assistenten bringen seltener Zielkunden als die Suche
Digital ChiefsSchwarz setzt auf Cohere: Was Aleph-Alpha-Kunden tun





