Der Schutz der Infrastruktur beginnt beim physischen Schutz der Rechenzentren und geht bis zum technischen Schutz der Rechner, auf denen Services sowie Workloads der Kunden betrieben (Compute) und Daten gespeichert werden (Storage).

Auf der Applikationsebene geht es um den Schutz der Business Applikationen selbst. Hier muss sichergestellt werden, dass nur berechtigte Benutzer Zugriff haben, aber auch, dass einzelne Applikationen nur auf die Daten sowie auf die anderen Applikationen zugreifen, die sie wirklich benötigen. Als verbindendes Element nimmt das Netzwerk eine zentrale Rolle ein und muss entsprechend geschützt werden. Dies gilt sowohl innerhalb der Cloud bei Verbindungen zwischen Services, wie auch bei Verbindungen zu on-premise Systemen oder dem Internet. Konkret verfolgt Google Cloud folgende Massnahmen, um ihre eigenen Kunden und deren Daten zu schützen.

1. Das Zero Trust Security Modell

Bekannt geworden unter dem Namen BeyondCorp propagiert Google das Zero Trust Security Model. Zero Trust bedeutet, dass sich die Zugriffskontrollen vom Perimeter in die Tiefe zu den einzelnen Benutzern und Services verschieben. Statt also auf eine einzelne Firewall und ein privilegiertes Intranet zu setzen, verhält sich jeder Service so, als wäre er potentiell ins Internet exponiert. Konkret bedeutet dies, dass jeder Service über Verschlüsselung und starke Mechanismen zur Authentisierung und Autorisierung abgesichert ist.

2. Verschlüsselung «in transit» und «at rest»

Verschlüsselung bietet einen effektiven Schutz, um unberechtigte Zugriffe auf Daten zu verhindern. Es wird unterschieden ob die Daten «at rest» sind, also persistiert in einem Data Store liegen, oder ob sie «in transit» sind, d.h. zwischen Data Store und Applikation bewegt werden. In beiden Zuständen ist eine Verschlüsselung möglich. In der Google Cloud ist das auch der Standard bzw. es ist gar nicht möglich, dass Daten «at rest» unverschlüsselt sind. Im einfachsten Fall werden dabei Schlüssel verwendet, die durch Google automatisch erzeugt werden. Das ist aber nur eine von mehreren Möglichkeiten.

3. «Bring your own Encryption Key»

Google Cloud verschlüsselt Daten automatisch. Im einfachsten Fall werden die Schlüssel von Google erzeugt und verwaltet. Falls mehr Kontrolle über die verwendeten Schlüssel gewünscht ist, gibt es zwei Varianten: Customer-managed Encryption Keys (CMEK) und Customer-supplied Encryption Keys (CSEK). Bei CMEK ist der Kunde für die Erzeugung der Schlüssel verantwortlich. Sie werden aber in der Cloud gespeichert (z.B. im Cloud KMS Service) und können von Cloud Services direkt verwendet werden. Bei CSEK ist der Kunde auch für die Verwaltung der Schlüssel verantwortlich. Dies geschieht on-premise und die Schlüssel werden nur bei Bedarf in die Cloud geladen und werden dort auch nur im Hauptspeicher abgelegt. Bei der Wahl einer Lösung ist zwischen Einfachheit und Kontrolle bzw. Schutzbedarf abzuwägen.

4. Abgesicherte Hardware mit Titan Security Keys und Chips

Zwei-Faktor-Authentisierung (2FA) findet immer breitere Anwendung. Dabei geht es darum, den ersten Faktor zur Authentisierung (Passwort; «etwas wissen») um einen zweiten Faktor (Token, Key oder Mobiltelefon; «etwas besitzen») zu ergänzen. Google bietet mit dem Titan Security Key einen einfach zu verwendenden zweiten Faktor an. Im Inneren des Keys arbeitet ein von Google selbst entwickelter Sicherheits-Chip, der die Integrität des Keys sicherstellt. Derselbe Sicherheits-Chip wird auch in den Server der Google Cloud Infrastruktur eingesetzt um Kompromittierungen auf tiefster Ebene zu verhindern und die Integrität sicherzustellen.

5. Applikationssicherheit erhöhen mit Cloud Security Scanner, Container Registry Vulnerability Scanning und Binary Authorization

Die bisherigen Massnahmen bezogen sich alle auf Infrastruktur und Netzwerk. Auf Applikationsebene bietet Google Cloud eine Reihe von Services zum Schutz von Inhalten.

Mit dem Cloud Security Scanner können Web-Applikationen automatisch auf verbreitete Schwachstellen (z.B. cross-site scripting, veraltete oder unsichere JavaScript Libraries) geprüft werden.

Für Applikationen die als Docker Container gebaut und in der Google Container Registry (GCR) abgelegt sind, existiert ebenfalls ein automatisches Vulnerability Scanning. Dabei werden die Container auf Schwachstellen gemäss CVE Datenbank geprüft. Zusätzlich kann mit dem Feature Binary Authorization des Google Kubernetes Engine (GKE) Service sichergestellt werden, dass nur bestimmte signierte Docker Container deployed werden können. So wird gewährleistet, dass nur entsprechend getestete und freigegebene Versionen einer Applikation in Produktion laufen. Dieser Prozess ist in Abbildung 2 grafisch dargestellt.

Hast du auch einen spannenden Use Case? Let's talk!

Matthias Hert