So vermeiden Sie die 11 häufigsten AWS-Konfigurationsfehler

Wenn Sie eine neue AWS-Cloud-Infrastruktur einrichten oder Einstellungen für Berechtigungen verändern möchten, müssen Sie dabei immer die Folgen für die Sicherheit beachten.

Das AWS-Modell der geteilten Verantwortung besagt, dass Sie für die Sicherheit der Cloud-Inhalte verantwortlich sind, während AWS die Absicherung der Cloud-Infrastruktur übernimmt. Vereinfacht ausgedrückt heißt das, dass Sie für die von Ihnen vorgenommenen Veränderungen haften, die zur Kompromittierung Ihrer Daten führen.

In diesem Artikel erläutern wir die häufigsten Konfigurationsfehler für die meistgenutzten Services und geben Ihnen Empfehlungen, wie Sie bei der Veränderung Ihrer Infrastruktur die Sicherheit gewährleisten und potenzielle Kompromittierungen verhindern können.

Die vier häufigsten S3-Konfigurationsfehler

1. Öffentliche Buckets oder öffentliche Objekte in Buckets

Wenn Sie S3 als Webseitenspeicher oder für statisches Hosting nutzen, müssen Sie entweder einen Teil oder alles davon öffentlich machen. Dies ist ein einfacher Prozess, der jedoch Ihre Daten für potenzielle Kompromittierungen anfällig machen kann, wenn er fehlerhaft ausgeführt wird. Bekanntlich hatten solche Kompromittierungen in den letzten Jahren weitreichende Konsequenzen. Wenn Sie einen neuen Bucket erstellen und diesen öffentlich machen wollen, stehen Ihnen mehrere Optionen zur Auswahl.

Wie im folgenden Screenshot zu erkennen ist, haben Sie die Wahl, ob Sie den öffentlichen Zugriff für Buckets und Objekte entweder über neue ACLs, jegliche ACLs, neue Zugriffspunktrichtlinien oder jegliche Zugriffspunktrichtlinien erlauben wollen:

Wählen Sie sorgfältig die für Ihre Anwendung am besten geeignete Lösung aus. Achten Sie zudem darauf, welche Objekte Sie dem Bucket hinzufügen, da diese solange öffentlich zugänglich bleiben, bis Sie die Einstellung ändern – wodurch vertrauliche Daten kompromittiert werden könnten.

2. Keine Zugriffsprotokollierung

Die S3-Zugriffsprotokollierung lässt sich ganz einfach aktivieren. Sie finden die Einstellung unter der Registerkarte „Eigenschaften“ des Buckets.

Sie ist standardmäßig deaktiviert und kann aktiviert werden, indem Sie auf „Bearbeiten“ klicken und dann einen Ziel-Bucket auswählen, in dem die Protokolle gespeichert werden sollen.

Durch diese Einstellung werden alle Zugriffsanfragen für Ihren Bucket protokolliert. Erfreulicherweise entstehen durch die Nutzung der Protokolle keine zusätzlichen Kosten. In bestimmten Situationen können diese Logs äußerst nützlich sein, zum Beispiel wenn Sie einem Kunden die Kosten für S3 erläutern wollen. Beachten Sie jedoch, dass Ihnen dennoch die Speicherung der Protokolle im Ziel-Bucket gemäß des normalen S3-Preismodells in Rechnung gestellt wird. Da sich die Protokolle schnell anhäufen können, sollten Sie eventuell einen Löschmechanismus einrichten.

Achten Sie außerdem darauf, dass die Zugriffsprotokollierung des Ziel-Buckets deaktiviert ist, da sonst eine Endlosschleife ausgelöst wird, die hohe Kosten verursachen kann.

3. Keine Verwendung von Versionierung und des S3-Lebenszyklus

Durch die Aktivierung der Bucket-Versionierung können Sie mehrere Instanzen eines Objekts im gleichen Bucket aufbewahren. Der größte Vorteil dieser Funktion ist, dass ein Bucket nach einem Anwendungsfehler oder einer unbeabsichtigten Benutzeraktion wiederhergestellt werden kann.

Sie finden die Funktion in der S3-Konsole unter der Registerkarte „Eigenschaften“:

Sie können sie ganz einfach aktivieren. Zudem sollten Sie die Löschfunktion mit Multifaktor-Authentifizierung (MFA) einschalten, um die unbeabsichtigte Löschung älterer Objektinstanzen zu verhindern.

Der Nachteil der Funktion ist, dass für jede Version eines Objekts das gesamte Objekt gespeichert wird, statt nur die Differenz zwischen dem Objekt und den anderen Versionen. Dies lässt sich durch die Verwendung von Konfigurationsregeln für den S3-Lebenszyklus korrigieren. Mit den Regeln können Sie nicht aktuelle Objekte so konfigurieren, dass sie sich nach einer bestimmten Zeit selbst entfernen. Oder Sie können sie auf kostengünstigere Speicherservices wie S3 Glacier Flexible Retrieval überführen und löschen, wenn sie von einer aktuelleren Version ersetzt werden.

4. Keine Verschlüsselung wichtiger Informationen

Wenn Sie vertrauliche Daten in der Cloud aufbewahren, sollten Sie sie immer verschlüsseln. Dies kann entweder serverseitig über S3 oder clientseitig durch Sie selbst erfolgen. Die serverseitige Option ist sehr viel unkomplizierter, da Amazon die Verschlüsselung, Speicherung und Entschlüsselung beim Herunterladen oder Kopieren von Objekten übernimmt. Um sie zu aktivieren, gehen Sie auf die Registerkarte „Eigenschaften“ und klicken unter dem Abschnitt „Standard-Verschlüsselung“ auf die Schaltfläche „Bearbeiten“:

Hier können Sie die Schlüssel für die Verschlüsselung auswählen. SSE-S3-Schlüssel werden von S3 verwaltet, d. h. Sie müssen nichts weiter tun. SSE-KMS-Schlüssel werden über KMS verwaltet und müssen eingerichtet werden.

Wenn Ihre Daten streng vertraulich sind, sollten Sie sie vor der Aufbewahrung möglicherweise selbst verschlüsseln. Das ist durchaus möglich. Dabei besteht allerdings die Gefahr, dass Sie Ihre Objekte beim Verlust der Schlüssel nicht mehr abrufen oder entschlüsseln können. Dieser Prozess erfordert zudem eine umfangreiche Einrichtung. Genauere Informationen finden Sie in der AWS-Dokumentation.

Die drei häufigsten EC2-Konfigurationsfehler

1. Öffentliche Snapshots oder nichtverschlüsselte freigegebene Snapshots

Die von Ihren Instanzen erstellten Snapshots sind standardmäßig auf „privat“ gesetzt, doch es gibt zwei Szenarien, bei denen sich das ändern könnte.

Beim ersten Szenario setzt ein Benutzer mit den entsprechenden Berechtigungen (oder ein Service wie AWS Lambda) die Snapshots auf „öffentlich“, wodurch ein früherer Zustand Ihrer Daten veröffentlicht wird – möglicherweise mit fatalen Folgen. Das zweite Szenario könnte eintreten, wenn Sie einen unverschlüsselten Snapshot freigeben müssen. In diesem Fall könnte der Empfänger des Snapshots daraus Volumes erstellen und damit im Prinzip eine Instanz mit Ihren Daten starten.

Deshalb sollten Sie Ihre Snapshots immer verschlüsseln – entweder indem Sie alle Instanzen bei der Erstellung verschlüsseln, oder indem Sie einen verschlüsselten Snapshot und daraus wiederum ein neues Root-Volume erstellen.

2. Backend-Instanzen in öffentlichen Subnetzen

Wenn Sie Instanzen haben, die keine Internetverbindung benötigen (z. B. Datenbanken oder einfache APIs), sollten Sie diese in einem privaten Subnetz unterbringen. Die Verbindung zum Internet ist eine ständige potenzielle Gefahr, da Sie nie sicher sein können, wer Zugriff auf die IP-Adresse Ihrer Instanz hat.

Um eine Instanz in ein privates Subnetz einzubinden, müssen Sie nur die automatische Zuweisung der IPv4- und IPv6-Adressen entfernen. Gehen Sie dazu auf die Registerkarte „Subnetz“ in der VPC-Konsole, wählen Sie das Subnetz Ihrer Instanz aus und deaktivieren Sie die entsprechende Einstellung:

3. Öffentliche/unverschlüsselte Amazon Machine Images (AMIs)

Wenn Sie ein AMI erstellen möchten, müssen Sie es möglicherweise für ein anderes Konto freigeben. In diesem Fall sollten Sie vorsichtshalber Maßnahmen ergreifen, um potenzielle Sicherheitsverletzungen zu verhindern.

Verschlüsseln Sie zunächst Ihre Volumes, sodass alle AMIs, die ein Volume enthalten, standardmäßig verschlüsselt werden und die Daten darin geschützt sind. Seien Sie außerdem vorsichtig bei der Vergabe von Berechtigungen an EC2, denn dadurch könnte die Verfügbarkeit des AMI auf „öffentlich“ gesetzt werden. Dies kann problematisch werden, wenn sich in Ihrem Unternehmen ein böswilliger Akteur befindet oder wenn Services wie AWS Lambda kompromittiert werden.

Und nicht zuletzt empfiehlt es sich, AMIs immer über die Konsole freizugeben. Damit vermeiden Sie potenzielle Fehler, die dazu führen könnten, dass AMIs öffentlich zugänglich werden:

Die vier häufigsten IAM-Konfigurationsfehler

1. Keine Multifaktor-Authentifizierung/Schlüsselrotation

Multifaktor-Authentifizierung (MFA) ist äußerst wichtig und sollte für alle Entitäten, die in Ihre Identitäts- und Zugriffsverwaltung (IAM) eingetragen werden, aktiviert werden. Dies gilt insbesondere für Benutzer. Durch die Funktion können gestohlene Schlüssel neutralisiert und die Angriffsfläche verkleinert werden. Um sie zu aktivieren, gehen Sie zur Registerkarte „Sicherheitsanmeldeinformationen“ des entsprechenden Benutzers und wählen diese dort aus:

Zudem sollten Sie die kontoweite Rotation von Zugriffsschlüsseln durchsetzen. AWS bietet dafür zwar keine automatische Funktion und empfiehlt, dies manuell durchzuführen, doch es gibt Open-Source-Tools, die diesen Prozess automatisieren und vereinfachen können. Dies gilt nur für IAM-Benutzer und nicht für Rollen, da die Schlüssel für Rollen bereits automatisch nach einer bestimmten Zeit ablaufen.

2. Keine Verwendung von Rollen

Mithilfe von Identity Access Management (IAM) können Sie Benutzern Berechtigungen gewähren, indem Sie Richtlinien direkt an Benutzer anfügen. Dies ist jedoch in großen und kritischen Infrastrukturen nicht empfehlenswert, da unter Umständen die falschen Personen Berechtigungen erhalten könnten. Hinzu kommt: Wenn Sie vergessen, diese Berechtigungen zu entfernen, bleiben sie für immer bestehen.

Durch die Verwendung von Rollen zur Vergabe von Berechtigungen erhalten Schlüssel automatisch ein Ablaufdatum, sodass sich Probleme wie übermäßige Zugriffsrechte oder gestohlene Schlüssel leichter lösen lassen. Wenn Sie viele Benutzer mit den gleichen Berechtigungen haben, können Sie auch Gruppen nutzen. Allerdings sollten Sie die Richtlinien dann möglichst nicht direkt an Benutzer anfügen.

3. Vergabe von übermäßigen Berechtigungen

Bei der Vergabe von Zugriffsrechten sollten Sie immer das Least-Privilege-Prinzip befolgen. Wenn ein Benutzer oder eine Rolle Zugriff auf einen Service benötigt, wählen viele den bequemen Weg und gewähren einfach Zugriff zum gesamten Service. Stattdessen sollten Sie die einzelnen Aktionen erfassen, die für die jeweilige Aufgabe nötig sind, und der IAM-Entität die entsprechenden Zugriffsrechte zuweisen. Wie bereits erwähnt, gibt es viele einfache und dennoch vielseitig einsetzbare Zugriffsrechte, die in den falschen Händen zu verheerenden Folgen führen können.

4. Ungenutzte Anmeldedaten werden nicht gelöscht

Sie sollten immer den Überblick über die Schlüssel sowie die aktiven Benutzer und Rollen in Ihrer Infrastruktur behalten. Wenn Benutzer aus irgendwelchen Gründen inaktiv werden (z. B. durch Urlaub, Entlassung usw.), sollten Sie diese Schlüssel für den jeweiligen Zeitraum deaktivieren und nach einer bestimmten Zeit entfernen.

Dadurch gibt es keine ungenutzten Schlüssel mit Berechtigungen, die für Ihre Umgebung ein Risiko darstellen. Grundsätzlich ist es besser, Benutzer neu erstellen zu müssen und damit vor potenziellen internen Angriffen geschützt zu sein.

See Crowdstrike Falcon In Action

Laden Sie diesen neuen Bericht herunter und erfahren Sie, auf welche Cloud-Sicherheitsbedrohungen Sie im Jahr 2022 achten sollten und wie Sie sich am besten schützen können.

Jetzt herunterladen