Immer mehr Firmen in Europa setzen auf Cloud-Dienste von AWS, die in Rechenzentren innerhalb Europas betrieben werden. Das hat einen einfachen Grund: Datenschutz. Gerade mit der DSGVO (Datenschutz-Grundverordnung) in Europa sind Unternehmen sehr vorsichtig, wohin ihre Daten gehen. Wenn die Daten in europäischen AWS-Rechenzentren bleiben, wissen sie, dass die strengen europäischen Datenschutzgesetze eingehalten werden. Das gibt ihnen ein viel besseres Gefühl und hilft, mögliche rechtliche Probleme zu vermeiden. Es geht also darum, die Kontrolle über die Daten zu behalten und sicherzustellen, dass sie nicht ohne Weiteres in andere Rechtsräume gelangen, wo andere Regeln gelten.

Unternehmen in Europa bevorzugen europäische AWS-Rechenzentren (Region EU, z.B. Frankfurt, Irland, London, Paris oder Zürich) vor allem, weil sie dadurch die Kontrolle über den Datenzugriff behalten. Mit der DSGVO ist klar geregelt, wer wann und wo auf Daten zugreifen darf. Wenn Daten in den USA liegen, könnten US-Behörden potenziell Zugriff verlangen – Stichwort CLOUD Act. Das wollen europäische Firmen natürlich vermeiden, um ihren Kunden und Partnern Datensicherheit nach europäischen Standards zu garantieren. Sie möchten sicherstellen, dass die Daten nur unter europäischer Gesetzgebung und nur von autorisierten Personen oder Systemen aus der EU verarbeitet und abgerufen werden können. Das minimiert das Risiko unautorisierter Zugriffe und stellt sicher, dass die Daten immer unter dem Schutz der DSGVO bleiben.

Doch was, wenn ich ihnen sage, dass diese Tatsache in vielen Fällen oft Nonsens ist?

Die AWS-Konsole ist die zentrale Weboberfläche, über die KMU (und auch grössere Unternehmen) ihre AWS-Dienste verwalten, konfigurieren und überwachen können. Sie bietet einen einfachen Zugriff auf alle Cloud-Ressourcen von AWS. Diese Oberfläche, samt der Tools dahinter die essenziell für die Verwaltung der Cloud Umgebungen von AWS sind, werden in den USA, genau genommen in North Virginia gehostet. Das ist eine Region, in der AWS ihre grossen Rechenzentren betreibt.

Sie wird mit der URL https://aws.amazon.com/de/console/ aufgerufen. Nach dem Authentifizierungsvorgang steht dem Benutzer oder Administrator (Root User) eine breite Palette an Tools zur Verfügung um die Cloud-Dienste in jeweilig selektierten Regionen zu verwalten.

Die AWS Management Konsole selbst ist eine globale Anwendung und wird von AWS weltweit bereitgestellt. Ihre Hosting-Region ist für die eigentliche Datenverarbeitung, die in deinen europäischen Regionen stattfindet, im Grunde nicht relevant.

Das ist ein wichtiger Unterschied:

• Die Konsole (GUI): Das ist die Benutzeroberfläche, die du nutzt, um deine Dienste zu verwalten. Sie ist global und wird von AWS betrieben. Hier werden keine Kundendaten gespeichert oder verarbeitet.
• Deine Daten und Ressourcen: Diese werden in den spezifischen Regionen (z.B. Frankfurt oder Irland) gespeichert und verarbeitet, die du beim Einrichten deiner Dienste auswählst. Wenn du eine Instanz in Frankfurt erstellst und Daten dort speicherst, bleiben diese Daten auch in Frankfurt und unterliegen den dortigen Datenschutzbestimmungen.

Es geht also darum, wo die tatsächliche Verarbeitung und Speicherung der Anwendungsdaten stattfindet, und das ist in den europäischen Rechenzentren, dachten wir bislang zumindest.

Um die These durch praktische Beispiele dem Leser (natürlich auch der Leserin) näher zu bringen, habe ich eine EC2 Instanz in der Region Europa im RZ Frankfurt erstellt. Auf diesem EC2 soll eine MariaDB Datenbank (MySQL Fork) eingerichtet werden, die beispielsweise Daten einer HR Applikation der Personalabteilung speichern und verarbeiten soll.

Die Möglichkeit, auf eine EC2 Instanz mithilfe eines SSH Client zuzugreifen ist eine sinnvolle Massnahme für den Zugriff in Europa aus der selben Region.

Geografische Verortung der EC2-Instanz nach dem Start

Nach dem Start einer EC2-Instanz gelangt man typischerweise in die Verwaltungskonsole für diese Instanzen innerhalb der zuvor ausgewählten Region. Eine schnelle Überprüfung der der EC2-Instanz zugewiesenen öffentlichen IP-Adresse bestätigt dann ihre geografische Verortung, in diesem Fall als Host in Deutschland / Frankfurt am Main.

Erste Beobachtungen zur AWS-Datenschutzproblematik

Bislang konnten keine eindeutigen Belege gefunden werden, die die anfänglichen Bedenken hinsichtlich datenschutzrechtlicher Probleme bestätigen.

Es ist bekannt, dass die Management Konsole für die EC2-Verwaltung, auch unter regionalen URLs wie eu-central-1.console.aws.amazon.com, letztendlich über den AWS Global Accelerator läuft. Dieses Routing führt, den Informationen zufolge, auch über AWS-Rechenzentren in den USA. Dieser Umstand sei hier als gegeben angenommen.

Dennoch ist es entscheidend, dass EC2-Instanzen, die im Rechenzentrum in Frankfurt gestartet werden, auch direkt dort verwaltet und administriert werden können. Ein gewisses Mass an Toleranz und Vertrauen ist hier zugunsten der Flexibilität der Cloud-Nutzung erforderlich.

Letztlich sind die Konsolenanwendungen der AWS ebenfalls EC2 Instanzen, die im Verbund angesprochen werden. Ich versuche in meinem AWS-Datenschutz-Experiment meine Instanz mit dem Putty Client über SSH direkt anzusprechen, was auf Anhieb wunderbar klappt. Auch in den Netzwerkverbindungen zeigt mein Windows Client, dass alles soweit im grünen Bereich ist.

Die Verbindung lässt sich auf dem lokalen Windows-System nachvollziehen.

Datenbankeinrichtung für HR-Anwendung auf EC2

Zu Beginn dieses Artikels wurde das Ziel genannt, eine MariaDB-Datenbank auf der EC2-Instanz für Testzwecke einzurichten. Diese Datenbank soll exemplarisch Daten einer HR-Anwendung für die Personalabteilung speichern und verarbeiten.

Nach der Installation von MariaDB auf der EC2-Instanz wird rasch eine neue Tabelle innerhalb einer Datenbank erstellt. Diese Tabelle dient dazu, eine Datenbasis zu illustrieren, die von einer HR-Applikation genutzt werden könnte. Um diese Datenbasis zu füllen, werden einige fiktive Datensätze von einem KI-Sprachmodell generiert und anschliessend in die Datenbank injiziert.

Wunderbar, das hat doch ganz gut geklappt. Nun noch die Einträge in der zuvor geöffneten Konsole (sichere SSH Sitzung) überprüfen.

Alternative Zugriffsmethoden auf EC2-Instanzen und Daten

Es existiert nicht nur ein einziger Weg, um auf eine EC2-Instanz und die darauf befindlichen Daten zuzugreifen. AWS bietet hierfür die AWS Cloud Konsole als vielseitiges Werkzeug an. Somit ist der Aufbau einer externen SSH-Verbindung zur laufenden EC2-Instanz nicht zwingend notwendig.

Stattdessen stehen wahlweise folgende interne Verbindungsoptionen zur Verfügung:

• Interne SSH-Verbindung (via AWS Systems Manager Session Manager): Dies ermöglicht den SSH-Zugriff ohne offene Ports oder die Notwendigkeit von Schlüsselpaaren auf dem Client, da die Verbindung über den AWS-Backbone und den Systems Manager-Dienst läuft.
• Endpunktverbindungen: Hierzu zählen verschiedene AWS-Services, die direkte private Verbindungen zu EC2-Instanzen oder Diensten ermöglichen, ohne den öffentlichen Internetweg zu nutzen.
• Serielle EC2-Konsolenverbindung: Diese Art der Verbindung ist besonders nützlich für das Debugging von Boot-Problemen oder Netzwerkfehlern. Um eine Verbindung über die serielle Schnittstelle einer Instanz via serielle EC2-Konsole herstellen zu können, muss die Instanz jedoch auf dem AWS Nitro System basieren.

Im vorliegenden Beispiel wird allerdings kein AWS Nitro System-basierter EC2-Instanztyp verwendet, wodurch die serielle EC2-Konsolenverbindung nicht zur Verfügung steht. Dies unterstreicht, dass die Wahl des Instanztyps auch die verfügbaren Zugriffsmethoden beeinflusst.

AWS Cloud Console: Globales Steuerpult mit bedingter Datensicherheit

Die AWS Management Konsole ist die zentrale, webbasierte Benutzeroberfläche von AWS. Sie dient dazu, Cloud-Ressourcen einfach zu verwalten, zu konfigurieren und zu überwachen.

Die Konsole selbst ist eine globale Applikation. Das bedeutet, sie wird von AWS weltweit betrieben und ist nicht an ein einzelnes Rechenzentrum in einer bestimmten Region gebunden. Die Anmeldung und Nutzung der Konsole erfolgt über eine AWS-Infrastruktur, die auf weltweite Zugänglichkeit und Performance ausgelegt ist (Das AWS Global Accelerator).

Keine Datenspeicherung von Kundendaten

Entscheidend ist, dass die Konsole selbst keine sensiblen Kundendaten speichert oder verarbeitet. Sie ist lediglich die Schnittstelle, über die Befehle an die tatsächlichen AWS-Dienste in den vom Nutzer gewählten Regionen gesendet werden.

Befehle an die gewählte Region

Wird über die Konsole beispielsweise eine EC2-Instanz in Frankfurt gestartet, ein S3-Bucket in Irland angelegt oder eine Datenbank in Paris konfiguriert, sendet die Konsole die entsprechenden API-Aufrufe an die spezifischen AWS-Rechenzentren in der ausgewählten Region. Die eigentliche Datenverarbeitung und -speicherung findet dann ausschliesslich in dieser Region statt. Doch die Daten werden in der Konsole sichtbar und können von dort auch runtergeladen werden.

Aus irgendeinem Grund hat in meinem Versuch jedoch die Verbindung über „EC2 Instance Connect“ nicht funktioniert.

Doch AWS hat noch das Schweizer Taschenmesser: Die Cloud Shell

Die AWS Cloud Shell ist eine browserbasierte Befehlszeilenumgebung, die direkt in der AWS Management Konsole verfügbar ist.

Man kann sich das so vorstellen:

• Wie ein Terminal im Browser: Statt ein Terminalprogramm auf dem eigenen Computer zu installieren und zu konfigurieren, bekommt man mit der Cloud Shell direkt im Webbrowser eine voll funktionsfähige Kommandozeilenumgebung.
• Vorkonfiguriert und Authentifiziert: Sie ist sofort einsatzbereit, da sie bereits mit den notwendigen AWS-Zugangsdaten (basiert auf der Anmeldung in der Konsole) und vielen gängigen Tools wie der AWS Command Line Interface (CLI), Git, Python, Node.js und mehr ausgestattet ist. Man muss nichts installieren oder einrichten.

Aufbau einer SSH-Verbindung zu EC2 in Frankfurt über die Cloud Shell (aus den USA)

Man kann die AWS Cloud Shell nutzen, um eine SSH-Verbindung zu einer EC2-Instanz in Frankfurt (eu-central-1) aufzubauen, selbst wenn die Cloud Shell-Sitzung in einer anderen Region, beispielsweise US-EAST-1, gestartet wird. Dies zeigt, dass Verbindungen zu AWS-Ressourcen regionenübergreifend möglich sind, unabhängig davon, wo die Cloud Shell-Umgebung selbst gehostet wird.

Um diese Verbindung von einer US-Region aus zu einer EC2-Instanz in Deutschland/Frankfurt aufzubauen, muss die benötigte Key-Pair-Datei (PEM-Datei) zuerst in die Cloud Shell-Umgebung hochgeladen werden.

An diesem Punkt könnte man einwenden, dass dies im Grunde nicht anders ist, als eine SSH-Verbindung von jedem beliebigen Ort der Welt direkt zur EC2-Instanz herzustellen. Der entscheidende Aspekt, der hier vertieft werden soll, ist jedoch, warum dies – aus einer bestimmten Perspektive – dazu führen kann, dass AWS jederzeit in der Lage ist, Daten einzusehen, selbst aus den USA.

Der Prozess beginnt also mit dem Wechsel zur Region US-EAST-1 in der AWS Konsole, dem Start der Cloud Shell und dem Hochladen der Key-Files, bevor ein SSH-Tunnel zur Zielinstanz in Frankfurt geöffnet wird.

AWS Cloud Shell: Datenzugriff über die globale Schnittstelle

Die Einbindung der AWS Cloud Shell als iFrame anstelle einer lokalen Browser-Applikation (wie einer Progressive Web App oder eines Applets) erhärtet den Verdacht, dass mit entsprechendem Fachwissen Daten in europäischen Systemen von AWS theoretisch von jedem Standort aus eingesehen werden können.

Diese Implementierungsweise deutet darauf hin, dass die Cloud Shell nicht primär als isolierte lokale Anwendung im Browser agiert. Stattdessen wird sie als eine Art „Fenster“ zu einer entfernten Umgebung geöffnet. Dies könnte – zumindest im Kontext des Verdachts – bedeuten, dass die Kommunikation und der potenzielle Zugriff auf Daten über diese globale Schnittstelle erfolgen kann, selbst wenn die eigentlichen Ressourcen in Europa liegen.

Nun können wir bei AWS USA, aus der Region US-EAST-1 aus in der Cloud Shell bequem unsere HR Daten abrufen:

Eine SSH Verbindung kann ein Admin doch von überall aus aufbauen – Wo ist das Risiko?

Bedenken bestehen bei der Verwaltung von SSH-Schlüsselpaaren auf AWS EC2

Die Verwaltung von SSH-Schlüsselpaaren für AWS EC2-Instanzen wirft verständliche Sicherheitsfragen auf. Wenn AWS die PEM-Schlüssel für die Authentifizierung am SSH-Server bereitstellt, entsteht die theoretische Möglichkeit, dass der Cloud-Anbieter diese Schlüssel ebenfalls speichern könnte. Ein Grundvertrauen in AWS ist zwar notwendig, um davon auszugehen, dass diese Schlüsselpaare bei ihrer Erzeugung nicht kopiert werden.

Doch die Tatsache, dass diese Schlüssel jederzeit über die AWS Management Konsole getauscht oder hinzugefügt werden können, sorgt für ein gewisses Unbehagen. Besonders wenn EC2-Instanzen in Ruhezeiten keine aktiven SSH-Verbindungen haben, könnten Schlüssel unbemerkt per Skript hinzugefügt oder ausgetauscht werden. Dies würde theoretisch die Möglichkeit eröffnen, Daten temporär auszulesen und eine solche „Hintertür“ anschliessend wieder zu schliessen – und das alles automatisiert.

Da es sich hierbei um Systeme handelt, die nicht in eigenen Rechenzentren betrieben werden, ist eine nachträgliche forensische Untersuchung nur unter der Voraussetzung möglich, dass das System selbst umfassend und lückenlos überwacht wird.

Trotz dieser Bedenken bleibt es eine Tatsache, dass der Zugriff auf europäische Daten auf europäischen AWS-Systemen jederzeit von überall auf der Welt möglich ist, was die globale Natur von Cloud-Diensten unterstreicht.

Handlungsempfehlungen

Verschlüsselung von Daten als Schutz vor Nicht-EU-Zugriffen

Um das Risiko unbefugter Zugriffe aus Nicht-EU-Regionen zu minimieren, ist die Verschlüsselung der Daten eine entscheidende Massnahme. Selbst wenn hier die symmetrische Verschlüsselung zum Einsatz kommt und theoretisch die Gefahr besteht, dass der Verschlüsselungsschlüssel aus dem Arbeitsspeicher ausgelesen werden könnte, ist dies immer noch eine signifikante Verbesserung gegenüber dem Vorhandensein von Klartextdaten.

Massnahme: Implementierung symmetrischer Verschlüsselung

Bei dieser Massnahme werden die sensiblen Daten vor ihrer Speicherung oder Übertragung auf den Servern in den EU-Regionen verschlüsselt. Dies kann auf verschiedenen Ebenen erfolgen:

1. Anwendungsebene: Die Daten werden direkt in der Anwendung verschlüsselt, bevor sie an die Datenbank oder den Speicher gesendet werden. Das bedeutet, die Verschlüsselung geschieht schon, bevor die Daten überhaupt die Kontrolle der eigenen Anwendung verlassen.
2. Dateisystemebene: Das zugrundeliegende Dateisystem oder Speicherdienste wird verschlüsselt. Dies schützt alle Daten, die auf diesem System abgelegt werden. (Auf den EC2-Instanzen wenig effektiv)
3. Datenbankebene: Viele moderne Datenbanken bieten integrierte Verschlüsselungsfunktionen, die es ermöglichen, Spalten, Tabellen oder ganze Datenbanken zu verschlüsseln.

Wichtige Aspekte der Umsetzung:

• Schlüsselverwaltung: Der symmetrische Schlüssel muss sicher generiert, gespeichert und verwaltet werden. Dafür sollte ein Key Management Service (KMS), wie AWS KMS, genutzt werden. Es ist entscheidend, dass der Hauptschlüssel, der die Datentransportschlüssel schützt, in der gewünschten EU-Region (z.B. Frankfurt) erstellt und verwaltet wird. So bleibt die Kontrolle über den Schlüssel und damit über die Daten in der EU.
• Zugriff auf Schlüssel: Die Berechtigungen zum Zugriff auf die Verschlüsselungsschlüssel müssen streng limitiert und ausschliesslich autorisierten Prozessen oder Identitäten in der EU-Region zugewiesen werden.
• Regelmässige Schlüsselrotation: Um das Risiko zu minimieren, falls ein Schlüssel doch kompromittiert wird, sollten Verschlüsselungsschlüssel regelmässig ausgetauscht werden.

Durch diese Massnahme wird sichergestellt, dass selbst im Falle eines unbefugten Zugriffs auf die darunterliegende Infrastruktur aus einer Nicht-EU-Region, die Daten nicht im Klartext vorliegen, sondern nur als unlesbarer, verschlüsselter Text. Dies erhöht die Hürde für Angreifer erheblich und stellt eine wichtige Verteidigungslinie dar.