Microsoft: Einen solchen Master Key für die Azure-Cloud oder die Microsoft-Infrastruktur gibt es selbstverständlich nicht, daher ist auch die Frage nach dem besonderen Schutz und Schutzbedürfnis irrelevant. Die schiere Anzahl der Sicherheitsmaßnahmen übersteigt an dieser Stelle den Umfang einer kurzen Antwort. Netzwerke sind heute nicht mehr relevant, jede einzelne Maschine ist zu schützen – das Stichwort ist hier "Microsegmentierung". Und weil IT-Verantwortliche grundsätzlich davon ausgehen müssen, dass Maschinen kompromittiert sind, verschiebt der Zero-Trust-Ansatz die Probleme hin zur Verifikation der Identität, also der sicheren Authentifizierung.

In Sachen Policies und Compliance sehen wir IT-Verantwortliche in der Pflicht, regelmäßige Audits durchzuführen. Der Umgang mit Fehlern und die Qualitätssicherung sollten heutzutage auf Zero-Trust-Mechanismen basieren. Sichere und angemessene Verschlüsselung auszuwählen und zu aktivieren liegt in der Verantwortung der Unternehmen.

Diese Frage impliziert, dass es unlösbare, widersprüchliche rechtliche Standards gibt.

Bertram Dorn, AWS: Die Dienste in der AWS-Cloud, hier spezifisch AWS Identity und AWS IAM, kommen ohne Master Keys aus. Wir setzen nicht auf Schlüsselhierarchien, sondern auf One-Time-Keys. Ein dauerhaftes Kompromittieren eines solchen Schlüssels ist quasi unmöglich, weil er nur einmal gültig ist. Es gilt bei uns das Prinzip der geteilten Verantwortung – Amazon sorgt für die Sicherheit der Cloud, der Infrastruktur und der Hardware, für die Gastsysteme sind die Anwender zuständig. Daneben liefern unsere eigenen Security-Reviews korrekte Risikobewertungen und wir arbeiten mit angepassten Schutzmaßnahmen und Prozessen.

Ein Ergebnis derartiger Überlegungen ist unser Nitro-Dienst, den wir bereits 2017 eingeführt haben und der menschliche Fehler und Manipulationen verhindern soll. Die Infrastruktur von AWS ist "Secure by Design" und der Nitro-Hypervisor für Amazon Elastic Compute Cloud wurde so entwickelt, dass wir nicht auf die Workloads der Kunden zugreifen können. Unsere Unternehmenskultur ermutigt die Mitarbeiter, potenzielle Sicherheitsprobleme zu erkennen und zu eskalieren. Eskalation bedeutet hier: sicherstellen, dass die richtigen Personen zur richtigen Zeit über ein Problem informiert werden. Es heißt auch, in die Tiefe zu gehen und wirklich zu verstehen, was vor sich geht. Nur so lassen sich gute Entscheidungen treffen und ein Unternehmen effektiv führen.

Um die Verantwortung für die Sicherheit zu verteilen und zu skalieren, hilft bei AWS das Security-Guardians-Programm. Das macht Programmentwickler zu Sicherheitsbotschaftern. Guardians sind gut informierte, sicherheitsbewusste Produktentwickler, die sich freiwillig als starke Verfechter der Sicherheit in ihren Teams engagieren und mit den Sicherheitsprozessen und -werkzeugen bestens vertraut sind. Sie sind als Ansprechpartner während des gesamten Entwicklungszyklus beteiligt und helfen Teams, fundierte Entscheidungen zu treffen, die zu einer sichereren und pünktlicheren Markteinführung führen. In diesem Modell der verteilten Sicherheitsverantwortung liegt die Verantwortung für die Produktsicherheit bei den Entwicklungsteams, aber die Guardians sind für die erste Bewertung des vom Entwicklungsteam eingereichten Safety-Reviews verantwortlich. Sie bestätigen die Qualität und Vollständigkeit der Ressourcen des neuen Diensts, der Designdokumente, des Bedrohungsmodells, der automatisierten Ergebnisse und der Bereitschaft für Penetrationstests. Die Entwicklungsteams, die von den Guardians unterstützt werden, legen ihre Safety-Reviews den Engineers von AWS Application Security zur abschließenden Überprüfung vor der Markteinführung vor.

Sicherheit muss definitiv von der Unternehmensspitze in die Organisation getragen und von allen Akteuren in der Organisation als Mehrwert gesehen werden. Das machen wir mit AWS exemplarisch, doch auch IT-Verantwortliche in den Unternehmen können mit fünf einfachen Schritten mehr Sicherheit erreichen: Identifizierung und Management von Risiken, der Schutz von Identitäten, Infrastruktur, Anwendungen und Daten, das Reagieren und die Ursache analysieren sowie der Wiederherstellung und Fehlerbehebung mit Vertrauen.

Google: Der Microsoft-Vorfall macht klar, wie fatal eine technische Monokultur und die Abhängigkeit von einem einzelnen Anwender sein kann. Durch einen Multi-Vendor-Ansatz können Behörden und Unternehmen ihre Cybersicherheitslage verbessern, vertrauliche Daten schützen und eine widerstandsfähigere digitale Infrastruktur aufbauen.

Nicht ohne Stolz können wir sagen, dass die letzten Sicherheitsvorfälle bei Google lange zurückliegen und wir viel aus diesen gelernt haben. Die zentrale Erkenntnis dabei ist, dass Zero Trust der Weg zu mehr Security ist – VPN ist einfach nicht mehr State of the Art. Doch auch in den Details der Technik spiegelt sich das wider, so hat beispielsweise Google Workspace anders als Microsoft Exchange nicht eine einzige Schwachstelle aufzuweisen.

Wenn Google von Behörden ein Auskunftsersuchen für Cloud-Kundendaten erhält, sehen unsere Richtlinien vor, dass die Behörde darauf hingewiesen wird, diese Daten direkt beim Kunden anzufragen. Google hat einen strengen Prozess zum Prüfen und Beantworten von behördlichen Ersuchen. Hierzu gehören auch Auskunftsersuchen im Rahmen des US-Gesetzes zum Zugriff von US-Behörden auf Daten, die nicht in den USA gespeichert wurden, wenn das Ersuchen gemäß einer geltenden CLOUD-Act-Vereinbarung eingegangen ist. Wir haben ein Team, das solche Auskunftsersuchen prüft und sich vergewissert, dass sie allen rechtlichen Erfordernissen genügen. Wenn Google zur Herausgabe von Daten gezwungen ist, informiert Google Unternehmenskunden unverzüglich von der Offenlegung von Informationen, sofern eine solche Benachrichtigung nicht gesetzlich verboten ist.