Einen sicheren Amazon-S3-Bucket erstellen (AWS)

In der Presse und in Fachpublikationen wurde bereits viel über die Sicherheit von Amazon S3 auf Amazon Web Services (AWS) geschrieben. Vieles davon ist jedoch stark vereinfacht und bietet in der Praxis nur begrenzten Nutzen. Amazon S3 ist ein unglaublich einfach zu nutzender Cloud-Service. Ihre S3-Ressourcen angemessen abzusichern, ist jedoch alles andere als einfach – wie schon zu viele Unternehmen feststellen mussten.

In diesem Beitrag (und in unseren beiden Cloud Security Masterclass-Sessions zu Amazon S3) stelle ich einen pragmatischen Ansatz vor, um die Sicherheit von S3 zu verstehen. Sie erfahren, wie Sie die Absicherung Ihrer konkreten S3-Anwendungsfälle beurteilen und einen sicheren S3-Bucket erstellen, der Ihren Anforderungen entspricht.

Wenn Sie sich allein auf das verlassen, was Sie in der Presse lesen, könnten Sie fälschlicherweise annehmen, dass Sie für die Sicherheit Ihres S3-Buckets nur „Block Public Access“ aktivieren müssen. Diese Einstellung richtig zu konfigurieren, ist zwar wichtig (und AWS hat die erforderlichen Schritte unternommen, um Sie bei einer falschen Konfiguration zu warnen), doch wenn Sie sich darauf beschränken, kann ein trügerisches Sicherheitsgefühl entstehen.

Die verschiedenen Ebenen der Amazon-S3-Sicherheit

Die Sicherheit von Amazon S3 umfasst mehrere Ebenen, von denen einige wichtiger sind als andere.

• Zugriffskontrollpunkte (ACLs)

• Identity and Access Management (IAM)-Richtlinien

• Bucket-Richtlinien

• Block Public Access

• Zugriffspunkte

• Verschlüsselung

Zunächst sind IAM-Richtlinien, Verschlüsselung und Bucket-Richtlinien am wichtigsten. Bevor wir uns mit den Details dieser Richtlinientypen befassen, brauchen wir jedoch ein grundlegendes Verständnis davon, was Richtlinien sind und wie sie sich auf Aktionen und Ressourcen in AWS beziehen. ACLs lassen wir außen vor, da sie ein Relikt aus der Vergangenheit sind, von deren Verwendung AWS in den meisten Fällen abrät.

IAM-Richtlinien

In AWS gibt es Principals, Actions und Resources. Natürlich gibt es in AWS auch andere Arten von Entitäten. Für die Entwicklung sicherer S3-Buckets müssen Sie jedoch diese drei verstehen.

• Principals sind Akteure – sowohl Menschen als auch Maschinen. Es sind Entitäten, die mithilfe entsprechender Anmeldedaten Actions für Resources ausführen.

• Actions sind die API-Endpunkte, mit denen wir Aktionen in der Cloud ausführen. Jeder AWS-Service umfasst eine Reihe von Actions, zum Beispiel ListBuckets oder GetObject in S3.

• Resources sind die konkreten Instanzen und Objekte in einem AWS-Service, etwa ein S3-Bucket oder -Objekt oder eine EC2-Instanz.

Damit ein Principal eine Action für eine Resource ausführen kann (zum Beispiel den Inhalt eines S3-Buckets auflisten), müssen Richtlinien die erforderlichen Berechtigungen durchgängig gewähren. Eine Verweigerung an irgendeiner Stelle verhindert die Ausführung der Action für die Resource. AWS wendet standardmäßig auf alle Actions und Resources für alle Principals die Richtlinie Deny an.

Sehen wir uns das an einem Beispiel an.

Sehen Sie die vertikale Linie zwischen Principals und Actions sowie die weitere Linie zwischen Actions und Resources? Nennen wir sie unsere „Verweigerungsbarrieren“. Beim Erstellen eines sicheren S3-Buckets müssen wir diese Linien nur für die Actions durchlässig machen, die der Principal benötigt, und nur für die passenden Resources.

Für AWS-Principals wie AWS-Benutzer und -Ressourcen (z. B. eine EC2-Instanz mit zugeordneter IAM-Rolle) können wir IAM verwenden, um den Zugriff auf Actions und Resources zu erlauben. Hier sehen Sie ein Beispiel für eine IAM-Richtlinie, die eine Gruppe von Actions für alle S3-Buckets im Konto zulässt:

1{
2    "Version": "2012-10-17",
3    "Statement": [
4        {
5            "Sid": "VisualEditor0",
6            "Effect": "Allow",
7            "Action": [
8                "s3:GetObjectAcl",
9                "s3:GetObject",
10                "s3:GetObjectTagging"
11            ],
12            "Resource": "*"
13        }
14    ]
15}

Beachten Sie, dass die Richtlinie wie in unserer Abbildung Abschnitte für Actions und Resources enthält. Die Verweigerungsbarriere zwischen Principals und Actions ist für die drei in der Richtlinie definierten Get-Aktionen durchlässig. Diese gelten für alle S3-Buckets unter Resources.

In diesem und vielen anderen Fällen lautet der Eintrag im Abschnitt Resources „*“ und umfasst damit alle Resources hinter dieser Action. Das ist oft sinnvoll, da wir mithilfe von Bucket-Richtlinien und anderen Maßnahmen bei der Auswertung aller Richtlinien festlegen können, welche Resources zulässig sind.

Wenn Sie entscheiden, wo konkrete Angaben wie Ressourcennamen festgelegt werden sollen, sollten Sie bedenken, dass Sie eine übermäßige Anzahl an IAM-Richtlinien vermeiden möchten: Deren Verwaltung wird sonst zu einer Kosten- und Risikoquelle. Daher ist es generell nicht empfehlenswert, konkrete Resource-Kennungen in einer IAM-Richtlinie zu hinterlegen, da dies zu zahlreichen Kopien der Richtlinie führt. Als Nächstes verwenden wir S3-Bucket-Richtlinien, um den Ressourcenzugriff auf Bucket-Ebene einzuschränken. So gewährt diese Richtlinie bei der Bereitstellung für einen Benutzer oder Prozess keinen Zugriff auf alle S3-Buckets.

Wir empfehlen, nach Möglichkeit von AWS verwaltete Richtlinien zu verwenden. In Ihrem Konto sind bereits mehr als 700 davon verfügbar, und AWS verwaltet sie für Sie. Selbst wenn keine Richtlinie genau zu Ihrem Zweck passt, eignen sie sich als Beispiele für die Erstellung gut gestalteter IAM-Richtlinien.

Bucket-Richtlinien

Wir haben nun eine IAM-Richtlinie, die mehrere Get-Aktionen für alle S3-Buckets im Konto zulässt. Wahrscheinlich möchten wir den Zugriff jedoch auf die S3-Buckets beschränken, die unsere Anwendung benötigt. Dafür gibt es verschiedene Möglichkeiten. Wir empfehlen, für alle Ihre S3-Buckets eine Bucket-Richtlinie als letzte Schutzmaßnahme einzurichten.

Bucket-Richtlinien sind AWS-Richtlinien, die für einzelne Buckets gelten. Sie eignen sich hervorragend, um Anfragen abzulehnen, die IAM-Richtlinien möglicherweise zulassen. In diesem Beispiel soll der Bucket „foo“ nur Actions akzeptieren, die von zwei bestimmten VPC-Netzwerken ausgehen. Sehen wir uns dazu eine Richtlinie aus dem AWS-Supportportal an.

1{
2  "Version": "2012-10-17",
3  "Id": "VPCe and SourceIP",
4  "Statement": [{
5    "Sid": "VPCe and SourceIP",
6    "Effect": "Deny",
7    "Principal": "*",
8    "Action": "s3:*",
9    "Resource": [
10      "arn:aws:s3:::awsexamplebucket",
11      "arn:aws:s3:::awsexamplebucket/*"
12    ],
13    "Condition": {
14      "StringNotEquals": {
15        "aws:sourceVpce": [
16          "vpce-1111111",
17          "vpce-2222222"
18        ]
19      },
20      "NotIpAddress": {
21        "aws:SourceIp": [
22          "11.11.11.11/32",
23          "22.22.22.22/32"
24        ]
25      }
26    }
27  }]
28}

Am Anfang der Anweisung legen wir für alle Principals und alle S3-Actions Deny fest. Anschließend schränkt eine Condition die Verweigerung auf VPC-Endpunkte ein, die nicht mit zwei VpcE-Kennungen und zwei CIDR-Blöcken übereinstimmen. Anders gesagt: Nur Principals, die über diese VPC-Endpunkte und innerhalb dieser CIDR-Blöcke zugreifen, dürfen überhaupt S3-Actions ausführen.

Wenn wir diese Richtlinien in der Abbildung zusammenführen, diese Richtlinie auf den Bucket „foo“ anwenden und für andere Buckets jeweils andere Richtlinien mit abweichenden VPC-Endpunkten und CIDR-Blöcken festlegen, ergibt sich Folgendes:

Hier greift der blaue Benutzer über eine VPC mit dem Endpunkt vpce-1111111 zu, während der rote Benutzer den Endpunkt vpce-3333333 verwendet. Die Bucket-Richtlinie für foo verweigert dem roten Benutzer den Zugriff, obwohl er dieselbe IAM-Richtlinie wie der blaue Benutzer nutzt, da er über einen nicht zugelassenen VPC-Endpunkt zugreift.

Sie können sich all diese Richtlinien als Teil einer einzigen Auswertung vorstellen, bei der jedes Deny zur Ablehnung der Anfrage führt. Deshalb können Sie Allow- und Deny-Anweisungen je nach Anwendungsfall und Architektur an den passenden Stellen festlegen.

Block Public Access

Wir hören oft, dass Menschen glauben, sie seien vor S3-Sicherheitsverletzungen geschützt, wenn sie in AWS die Funktion Block Public Access aktivieren. Das ist eine großartige Funktion. Sie sollten sie dort einsetzen, wo es sinnvoll ist. Was den Zugriffsschutz betrifft, leistet sie jedoch längst nicht so viel, wie Sie vielleicht denken. Sie können nicht davon ausgehen, dass Sie allein durch ihre Aktivierung sicher sind.

In der AWS-Dokumentation heißt es:

„Damit ein Bucket als nicht öffentlich gilt, darf eine Bucket-Richtlinie den Zugriff nur für feste Werte (Werte ohne Platzhalter) aus einer oder mehreren der folgenden Kategorien gewähren:

• Eine Gruppe von Classless Inter-Domain Routings (CIDRs) unter Verwendung von aws:SourceIp. …“

Das Dokument enthält noch viele weitere Informationen (die Sie lesen sollten). Schon diese Aussage zeigt jedoch, dass eine Liste von CIDR-Blöcken mit öffentlichem Zugriff aus Sicht dieser Funktion nicht als „öffentlich“ gilt. CIDR-Blöcke können große Teile des Internets abdecken. Sie könnten also einen „nicht öffentlichen“ Bucket haben, der für Millionen von IP-Adressen erreichbar ist, und trotzdem glauben, Sie seien geschützt. Für jeden S3-Bucket sollten Sie die Bucket-Richtlinie möglichst eng fassen.

Ein Hinweis zur Verschlüsselung

Wenn Sie einen S3-Bucket verschlüsseln, sollten Sie dafür KMS-Schlüssel oder benutzerverwaltete Schlüssel verwenden. Bei diesen Verfahren muss ein Angreifer zusätzlich auf andere Services oder Daten zugreifen, um entschlüsselte Informationen aus Ihrem S3-Bucket auszulesen. Wenn Sie lediglich die einfachste Form der serverseitigen Verschlüsselung aktivieren, werden die Daten nur innerhalb des S3-Service im Ruhezustand verschlüsselt. Jeder Principal mit GetObject-Berechtigung erhält die Objekte dann in entschlüsselter Form.

Wenn gesetzliche oder regulatorische Vorgaben verlangen, dass alle ruhenden Daten verschlüsselt sind, erfüllen Sie damit diese Anforderung. In der Praxis hat diese Maßnahme jedoch kaum oder gar keinen Einfluss auf Ihre Sicherheitslage.

Es gibt noch mehr …

AWS bietet weitere Funktionen und Sicherheitsebenen für S3, die wir in diesem Beitrag nicht behandelt haben. Einige davon beleuchten wir in unserer Cloud Security Masterclass-Reihe zur S3-Sicherheit. Wenn Sie aus diesem Beitrag einen Gedanken mitnehmen, dann hoffentlich diesen: Sie müssen AWS-Richtlinien wirklich verstehen, um die Sicherheit von S3 zu verstehen. Vorgefertigte Beispiele allein reichen nicht aus, um sich mit dem Thema vertraut zu machen.

ERGÄNZUNG: Ich habe vergessen zu erwähnen, dass Sie für Ihre S3-Buckets Zugriffsprotokollierung, Protokollierung auf Objektebene und Versionierung aktivieren sollten. Mithilfe der Zugriffsprotokollierung und der Protokollierung auf Objektebene sehen Sie, was in Ihrem Bucket passiert ist. Dank der Versionierung können Sie frühere Versionen Ihrer Objekte wiederherstellen, falls sich jemand Zugriff verschafft und benötigte Objekte ändert oder löscht.

Wenn es weitere Themen zur S3-Sicherheit gibt, die wir behandeln sollen, melden Sie sich bei uns – wir gehen der Sache gern auf den Grund!