Das Zero-Trust-Modell

Hölzle: Zero Trust erkennt, dass Applikation A Software B aufrufen darf, aber nur Leserechte erhält. Die entsprechende Firewall-Konfiguration wird im Hintergrund automatisiert erledigt. Darum muss man sich als IT-Verantwortlicher nicht mehr kümmern. 

Hölzle: Wenn man die Applikation in die Cloud migriert, ändert sich an der grundlegenden Sicherheitseinstellung nichts. Dienst A kann immer noch Service B aufrufen und Daten lesen. Dass sich die Netzwerkeinstellungen in der Zwischenzeit verändert haben, ist dann unser Problem, nicht das des Anwenders. Das ist auch nach einer Dekade sofort klar und nachvollziehbar. Diese Vereinfachung der IT-Security macht es wahrscheinlicher, dass man die Sicherheitsfunktionen korrekt einsetzt. 

Hölzle: Die Frage, die sich IT-Verantwortliche heute stellen, lautet: Bin ich als Anwender in der Lage, die Cloud sicher zu nutzen? In jüngster Zeit gab es immer wieder Vorfälle wie Datenbanken, die praktisch ungeschützt öffentlich zugänglich waren. Kürzlich passierte dies sogar Microsoft mit 250 Millionen Datensätzen aus dem Kunden-Support. Die Lücke wurde nach Bekanntwerden sofort geschlossen. Solche Sicherheitsvorfälle sind aber kein typisches Cloud-Security-Problem im Sinne eines technischen Fehlers, sondern Folgen menschlichen Versagens. 

Hölzle: IT-Verantwortliche entwickeln ein Risikodenken. Man weiss, dass die Cloud-Infrastruktur technisch sicher ist, aber man weiss nicht genau, wie man sie korrekt nutzen muss, um Fehler im Umgang mit der Technik zu vermeiden. Das führt zum Trugschluss, dass die IT beim Betrieb in der Cloud unsicherer ist, als wenn man sie im eigenen Data Center betreibt. 

Hölzle: Darauf gibt es keine einfache Antwort. Tatsächlich sprechen wir hier über eines der grössten Hindernisse beim Einsatz von Cloud Computing. 

Hölzle: Natürlich sind wir dafür verantwortlich, dass unsere Technologien funktionieren. Aber die Frage ist, wie wir Kunden helfen können, keine Datenbank versehentlich öffentlich zugänglich zu machen. Eine Möglichkeit wäre, eine Policy für alle Accounts eines Kundenunternehmens zu setzen. So könnte man etwa verhindern, einen Public Bucket auf einer Google-Cloud-Instanz anzulegen. Hier wird die Gemengelage aber komplex. 

Hölzle: Wenn man die Sicherheit der IT komplett an uns abtreten würde, müssten wir Kunden wiederum Rechte an ihrer IT wegnehmen – das ist weder praktikabel noch wünschenswert. Daher versuchen wir, dieser Situation mit der Vereinfachung und Automatisierung von Rechtevergaben zu begegnen. Wir unterstützen hier die Kunden, sodass es am Ende stets das Regelwerk des Anwenderunternehmens bleibt. Speziell im Hinblick auf die Automatisierung von Cloud-Security braucht es daher eine tiefe Zusammen­arbeit zwischen Anbietern und Anwendern. 

Hölzle: Man muss sich zunächst darüber einig sein, welche Workloads überwacht werden müssen und welche Partei wofür verantwortlich zeichnet. Wir setzen heute bereits Tools ein, die melden, wenn ein Kunde nicht gepatchte Betriebssysteme in virtuellen Maschinen (VMs) betreibt. Da die VMs aber vom Kunden stammen, können wir nicht einfach in diese eindringen und Updates durchführen. Wir bieten hierfür Alternativen. Produkte wie unsere Containerlösung Kubernetes Engine oder die Cloud-Management-Plattform Anthos enthalten VMs. Werden diese eingesetzt, verantworten wir deren Aktualität und Betriebssicherheit. Ein anderes Beispiel: Unser Data Warehouse Big Query läuft auf unseren Compute-Ressourcen in der Google Cloud. Hier ist ganz klar, dass die Verantwortung für die Sicherheit bei uns liegt. Je mehr Services wir für Kunden betreiben, desto mehr können wir sie bei der IT-Security in der Cloud unterstützen.