AWS Security Serie: Teil 2 – Location and Physical Access

Nachdem wir uns im ersten Teil der Blogserie das sogenannte Shared Responsibility Model, das Zuständigkeiten innerhalb von AWS regelt, angesehen haben, gehen wir in diesem Artikel einen Schritt weiter und sprechen über die geographischen sowie physikalischen Grundlagen der AWS Datacenter. Auch hier handelt es sich um Grundlagen, die wir für die nächsten, deutlich spezifischeren, Themen benötigen.

Das Geokonzept von AWS

Amazon Webservices steuert das Delivery der Services über das eigene Geokonzept, bestehend aus Regions, Availability Zone und Edge Locations.

Regions

Eine Region ist eine Sammlung von Rechenzentren, die sich in einem bestimmten geografischen Gebiet befinden. Unterschiedliche Regionen sind, vereinfacht ausgedrückt, mindestens eine Flugreise voneinander entfernt. Die Regionen sind voneinander isoliert, so dass, wenn eine geotechnisch von der Karte gestrichen wird, die anderen weiter funktionieren können.

Eine Region in AWS ist beispielsweise Region EU in Frankfurt, eine weitere ist Region US East in Virginia. Dies sind zwei verschiedene geografische Regionen, die jeweils mehrere Rechenzentren enthalten.

Da zwei Regionen geografisch getrennt und in getrennten Netzwerken liegen, ist die Replikation von Daten von einer Region zur anderen teurer als diese Daten innerhalb einer Region zu transferieren. Darüber hinaus ist nicht immer jeder Dienst in jeder AWS Region verfügbar. 

Availability Zones (AZ)

Eine Availability Zone (AZ) stellt ein oder mehrere Rechenzentren innerhalb einer Region dar. Jedes AZ ist über eine spezielle Glasfaser mit den anderen AZs verbunden.

Die Region us-west-2 verfügt über drei verschiedene Verfügbarkeitszonen, die zumindest eine Autofahrt voneinander entfernt sind. Wenn eines der Rechenzentren an Strom verliert, gibt es ein weiteres in der gleichen Region, das weiterhin online sein sollte. Regionen und Verfügbarkeitszonen sind die Kernpunkte sowohl fehlertoleranter als auch hochverfügbarer Services innerhalb von AWS. 

In der folgenden Grafik ist eine Übersicht über die derzeitigen (Stand März 2019) AWS Regionen, wobei die Zahlen die jeweilige Anzahl an Availability Zones innerhalb der Region darstellt. Grüne Regionen stehen für zukünftige Regionen.

Edge Locations

Eine Edge Location ist ein Ort, an dem Endbenutzer auf Workloads zugreifen, die sich in AWS befinden. Sie befinden sich in den meisten Großstädten der Welt und werden speziell von CloudFront (CDN) verwendet, um Inhalte an den Endverbraucher zu verteilen und die Latency zu reduzieren. Es ist wie das Frontend für den Service, auf den wir zugreifen und der sich in der AWS-Cloud befindet. 

Eine aktuelle Liste der Edge Locations findet ihr unter diesem Link.

Wo liegen meine Daten?

Grundsätzlich ist erst einmal der Kunde dafür zuständig zu bestimmen, wo die Daten liegen bzw. ein Service läuft. Möchte ein deutscher Kunde seine Daten in Deutschland halten, so wählt er die Region EU (Frankfurt). Natürlich kann man Daten zwischen verschiedenen AWS Regionen replizieren und sichern, doch dies geschieht nur durch Konfiguration des Kunden. Daten einzelner Dienste werden von AWS zwar automatisch zwischen verschiedenen Availability Zones hochverfügbar gehalten, allerdings nicht auf Ebene verschiedener Regions repliziert oder transferiert.

Und das heißt genau?

Immer wieder kommt auch in Gesprächen mit unseren Kunden die Frage nach der genauen Lokation der AWS Datacenter auf. Selbst die Bitte um Besichtigung für das gute Gewissen wurde bereits gestellt.

AWS stellt die genauen Adressen der Rechenzentren nicht bereit und auch Besuche in diesen sind nicht möglich. Die Ansicht, dass AWS hier extreme Geheimniskrämerei betreibt, kann ich persönlich nicht wirklich teilen, da man die ein oder andere Adresse eigentlich relativ einfach herausbekommt. Der Fakt, dass AWS hier nichts offensiv oder auch auf Anfrage preisgibt hat allerdings schon Wiki-Leaks dazu bewogen Adressen der Datacenter zu veröffentlichen.

Hier ein relativ persönlicher Kommentar zu dieser Thematik: Ich kann im Grundsatz verstehen, dass Kunden gerne wüssten, wo genau die Daten liegen und dass es dem ein oder anderen auch ein gutes Gefühl vermittelt eine Begehung des Datacenters zu tätigen. Andererseits halte ich es für deutlich wichtiger überhaupt die Region meiner Daten bestimmen und mir schwarz auf weiß die gegebenen Zertifizierungen der Datacenter oder Services anzeigen lassen zu können. Seine Daten physikalisch innerhalb eines Software defined Datacenters zu besichtigen wird vermutlich eh relativ schwierig.

Governance

Ich höre schon wieder meinen inneren Kritiker sagen: „Fängt der auch endlich mal mit Security an?“ Ja, versprochen. Doch auch ich habe in den letzten Jahren lernen müssen, dass wir erst gar nicht über Services reden müssen, wenn wir nicht zuvor Governance abgehakt haben. Also, auf ein letztes Mal:

Darf ich meine Daten denn überhaupt zu AWS transferieren? Wie steht es um die Zertifizierungen der Datacenter? Wie schaut es mit der Datenverarbeitung innerhalb der verschiedenen Dienste aus?

Diese und viele andere Fragen erklärt AWS, meiner Meinung nach, sehr seriös und transparent im AWS Compliance Program.

Hier wird unter anderem dargestellt, welcher AWS Service mit welcher Zertifizierung compliant ist. Als Beispiel hier ein Ausschnitt der Eignung der Services für TISAX, ein von der Automobilindustrie definierter Standard für Informationssicherheit:

Das heißt im ersten Schritt natürlich nur, dass der Dienst compliant ist. WIE ich mit dem Dienst umgehe und WIE ich die Daten innerhalb des Dienstes verarbeite, steht auf einem ganz anderen Blatt Papier. Auch hier kommt wieder das Shared Responsibility Model zum Tragen.

Fazit

AWS bietet ein, für mich, schlüssiges Geokonzept und viele wertvolle Informationen für die Governance Abteilungen der Kunden. Ich und auch Proact werden nie einen Datenschutzbeauftragten ersetzen. Trotzdem wollte ich in diesem Artikel die Grundlagen bereitstellen, die für die nächsten Artikel notwendig sein werden. Im nächsten Artikel werde ich dann (endlich) spezifischer: Wir werden uns mit der Account Verwaltung, dem Access Management und interessanten Themen wie Blast Radius beschäftigen.

Series Navigation