22.04.2020
Mit dem Schritt in die Public Cloud zeigen sich diverse Security-Herausforderungen. Google Cloud ergreift mitunter folgende 5 Massnahmen.
Der Schritt in die Public Cloud stellt Unternehmen vor neue Herausforderungen im Bereich Security. Einige dieser Herausforderungen werden bereits von den Public Cloud Providern adressiert. In diesem Beitrag stellen wir 5 Massnahmen vor, die Google Cloud ergreift, um Kunden und ihre Daten zu schützen.
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.
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.
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.
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.
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.
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.
Zusätzlich zu den hier beschriebenen Massnahmen sind auch die Themen Transparenz und Vertrauen zentral. Wie kann ich als Kunde sicher sein, dass nicht der Cloud Provider selbst auf meine Inhalte zugreift? Google Cloud bietet unter dem Stichwort «Access Transparency» eine Lösung für dieses Problem. In einem ersten Schritt müssen Google Cloud Mitarbeiter, z.B. vom Support, explizit eine Anfrage für den Zugriff stellen. Der Kunde kann diesen erlauben oder ablehnen. Wurde der Zugriff erteilt, wird jede Aktion feingranular in ein Audit Log geschrieben. Dabei werden detaillierte Informationen über den Zugriff aufgezeichnet und damit die Nachvollziehbarkeit gesichert.
Die hier beschriebenen Massnahmen sind alle technischer Natur. Natürlich beinhalten die Verträge und Bestimmungen zwischen Google Cloud und ihren Kunden auch rechtliche Aspekte zum Schutz der Inhalte. Darüber hinaus ist Google bestrebt, ihre Bemühung durch Audits und Zertifizierungen von Dritten verifizieren zu lassen. Konkret sei hier der für Schweizer Kunden wichtige ISAE 3000 Type 2 Report sowie das Swiss-U.S. Privacy Shield Framework genannt.
In diesem Beitrag konnte nur ein Auszug aller Massnahmen thematisiert werden. Es sollte damit aber klar geworden sein, dass Google effektive Mechanismen bereit stellt, damit Unternehmen den Schritt in die Public Cloud guten Gewissens wagen können.
Weitere Links und Quellen:
BeyondCorp | Cloud KMS | Titan Security Key | Cloud Security Scanner | CVE Datenbank | Binary Authorization
