Die S3-Sicherheit ist konstruktionsbedingt fehlerhaft

Amazon S3, eine der führenden Cloud-Speicherlösungen, wird von Unternehmen auf der ganzen Welt für eine Vielzahl von Anwendungsfällen eingesetzt, um ihren IT-Betrieb zu unterstützen. Im Laufe von vier Jahren hat UpGuard Tausende von S3-bezogenen Datenschutzverletzungen entdeckt, die durch die Fehlkonfiguration der S3-Sicherheitseinstellungen verursacht wurden. Jeff Barr, Chief Evangelist für Amazon Web Services, kündigte kürzlich öffentliche Zugriffseinstellungen für S3-Buckets an, eine neue Funktion, die AWS-Kunden dabei helfen soll, die Epidemie von Datenschutzverletzungen zu stoppen, die durch falsche S3-Sicherheitseinstellungen verursacht werden.

AWS-Kontoinhaber können jetzt zwischen vier neuen Optionen wählen, um eine Standardzugriffseinstellung für die S3-Buckets ihres Kontos festzulegen. Die Einstellungen sind global, d. h. sie überschreiben alle neuen oder vorhandenen ACLs (Zugriffskontrolllisten) und Richtlinien auf Bucket-Ebene. Die neuen Einstellungen können nachträglich angewendet werden, um bestehende S3-Buckets abzusichern.

Das anhaltende Cloud-Sicherheitsproblem für diesen einfachen Speicherdienst hat zu Dutzenden von Millionen von kompromittierten Datensätzen geführt. Das sind also willkommene Neuigkeiten und ein Schritt in die richtige Richtung für AWS-Services, aber wir glauben nicht, dass das ausreicht.

Schlechte S3-Sicherheit ist ein häufiges Ziel für Unternehmensspione.

Das S3-Sicherheitsproblem

Sicherheitsforscher, darunter auch UpGuard, entdecken ständig offene, ungeschützte S3-Buckets mit sensiblen Daten. Zum Vergleich: Die Forscher von UpGuard haben die folgenden Datenschutzverletzungen offengelegt, die direkt auf undichte S3-Buckets zurückzuführen sind:

• Eine Datenoffenlegung mit 540 Millionen Datensätzen von mehreren von Drittanbietern entwickelten Facebook-Apps.
• Leak von GoDaddys Geschäftsgeheimnissen und detaillierten Infrastrukturinformationen.
• Pocket Inet, das über 73 GB an Daten offenlegte, darunter Klartext-Passwörter und geheime AWS-Schlüssel für Pocket iNet-Mitarbeiter.
• Ein Verstoß durch Localblox, eine private Intelligence-Plattform, die 48 Millionen Datensätze mit detaillierten persönlichen Informationen von Dutzenden Millionen von Personen offenlegte, die aus mehreren Quellen gesammelt und gescrapt wurden.
• Die Offenlegung von 14 Millionen Kundendatensätzen durch den Telekommunikationsanbieter Verizon ist ein Beispiel dafür, wie das Risiko von Drittanbietern zu diesem Problem beiträgt.
• Viacom, das einen Schatz an Systemanmeldeinformationen und kritischen Anwendungsdaten in einem offenen S3-Bucket offengelegt hat.
• Der Einbruch in eine Wählerdatenbank in Chicago, bei der rund um die Parlamentswahlen 2016 1,8 Millionen persönliche Daten durchgesickert sind.
• Der Tea Party Patriots Citizens Fund, der die persönlichen Daten von 527.000 Personen in einem falsch konfigurierten S3-Eimer durchsickern ließ.

Wir decken seit über vier Jahren S3-Sicherheitsverletzungen auf, und das Problem scheint nicht zu verschwinden.

Wer ist für das S3-Sicherheitsproblem verantwortlich?

Es ist verlockend, Ihnen, den Benutzern, die Schuld dafür zu geben, dass Sie zu faul oder dumm sind, S3 richtig zu verwenden. Wir alle haben von "Lösungen" für das S3-Sicherheitsproblem gelesen, einschließlich (aber nicht beschränkt auf):

• Überwachen Sie Ihre S3-Buckets mit Produkten wie AWS Config
• Erstellen Ihrer eigenen S3-Überwachungslösung mit AWS Cloudtrail und Lambda
• Testen über die Befehlszeile mit Tools wie S3 Inspector
• Verwenden von AWS Identity and Access Management (IAM)-Benutzerrichtlinien, die die Benutzer angeben, die auf bestimmte Buckets und Objekte zugreifen können

Diese Lösungen funktionieren, und wir empfehlen, sie zur Überwachung Ihrer S3-Sicherheitslage zu verwenden. Um ehrlich zu sein, fühlt es sich ein bisschen unfair an. Warum sollten S3-Benutzer gezwungen sein, mehr Geld für alternative Lösungen auszugeben, um ein grundlegendes Problem zu lösen? IAM-Richtlinien sind selbst für erfahrene Benutzer kompliziert.

Wir sind der Meinung, dass das Sicherheitsproblem bei S3 im Produktdesign liegt.

Ja, AWS stellt sicher, dass S3-Server standardmäßig privat sind. Dennoch sehen wir weiterhin Tausende von offenen Eimern und regelmäßige Sicherheitsverletzungen.

Wir sind der Meinung, dass AWS es S3-Benutzern viel zu einfach gemacht hat, Buckets falsch zu konfigurieren, um sie vollständig öffentlich über das Internet zugänglich zu machen. Es liegt an AWS, standardmäßig bessere Sicherheitslösungen zu entwickeln. Es gibt zwei wichtige Produktmerkmale, die wir im Folgenden hervorgehoben haben und über die Sie leicht stolpern können, wenn Sie nicht aufpassen.

1. Alle authentifizierten Benutzer

Das Konzept "alle authentifizierten AWS-Benutzer" ist eine schlecht verstandene Funktion von S3 und eine äußerst häufige Fehlkonfiguration in der Cloud. Diese Sicherheitsstufe ermöglicht es jedem mit einem AWS-Konto, in Ihre Buckets zu blicken.

Nicht irgendjemand in Ihrem Unternehmen. Jeder auf der Welt mit einem AWS-Konto, dessen Einrichtung 5 Minuten dauert.

Es ist, als ob Ihre Internet-Banking-Zugangsdaten funktionieren würden, um sich bei dem Bankkonto einer anderen Person anzumelden. Dieses ungewöhnliche Sicherheitsmodell verursacht nach wie vor eine beträchtliche Anzahl von Sicherheitsverletzungen und ist unserer Meinung nach ein entscheidendes Problem mit dem S3-Sicherheitsmodell.

2. Inkonsistente ACLs und Bucket-Richtlinien

Ein weiteres leicht falsch konfiguriertes Merkmal des Sicherheitsmodells von S3 ist das Zusammenspiel zwischen ACLs und Richtlinien, die Buckets und die darin enthaltenen Objekte steuern.

Einige der katastrophalsten Sicherheitsverletzungen, die wir gefunden haben, wurden durch Personen verursacht, die nicht verstehen, wie diese Einstellungen zusammenwirken. Sie können ACLs für einen Amazon S3-Bucket sperren, aber wenn die Bucket-Richtlinie falsch konfiguriert ist, können Sie Ihre Daten weiterhin für das Internet offen lassen. Es ist nicht hilfreich, dass Bucket-Richtlinien relativ versteckt sind und mit einer ziemlich obskuren JSON-Syntax geschrieben werden.

Aber sie zu verstehen ist super wichtig.

Andernfalls könnten Sie sich Ihre ACL ansehen, die besagt "Dieser Bucket ist nicht lesbar", aber die darin enthaltenen Objekte könnten aufgrund verschiedener Bucket-Richtlinien immer noch zugänglich und lesbar sein.

Was hat AWS getan, um S3 zu sichern?

Wenn Sie also der Meinung sind, dass Funktionen des S3-Sicherheitsmodells zumindest teilweise für undichte Buckets verantwortlich sind, was hat AWS getan, um das Problem zu lösen?

Im Laufe des Jahres 2017 kündigte AWS mehrere Änderungen an, die zu helfen versprachen:

• Bereitstellung eines "öffentlichen" Flags für offene Buckets und einer E-Mail-Outreach-Kampagne für Besitzer dieser Buckets.
• Die Einführung von Amazon Macie, einem "Sicherheitsservice, der maschinelles Lernen verwendet, um sensible Daten in AWS automatisch zu erkennen, zu klassifizieren und zu schützen".

Nach der Einführung dieser Funktionen haben wir gesehen, dass viele freiliegende Buckets verschwunden sind. Wir haben aber auch gesehen, dass viel mehr Buckets mit sensiblen Informationen bestehen bleiben und seitdem neue Buckets mit sensiblen, öffentlich zugänglichen Daten erstellt wurden.

Warum sehen wir keine entscheidenderen Veränderungen?

S3 gibt es seit 2006. Es ist eines der ersten drei AWS-Produkte. Als Opfer seines eigenen Erfolgs kann Amazon nur schrittweise Änderungen an S3 vornehmen, ohne bestehende Anwendungen für Zehntausende von Kunden zu beschädigen. Eine zu schnelle Umstellung auf ein "standardmäßig privates" Sicherheitsmodell für S3 würde AWS und seinen bestehenden Kunden schaden.

Nichtsdestotrotz glauben wir, dass AWS S3 im Laufe der Zeit in zwei unterschiedliche Produkte aufteilen sollte:

1. Amazon Web Hosting - Diese Speicherlösung wurde für das Hosten öffentlicher Websites entwickelt und ist immer öffentlich.
2. Amazon Private Storage - Dieser Speicher wurde entwickelt, um alle Daten zu speichern, die Sie nicht im Internet veröffentlichen möchten, dieser Speicher ist immer privat und kann nicht direkt über das Internet aufgerufen werden.

Die Trennung der Produkte würde die Unterschiede zwischen öffentlichem und privatem Speicher deutlich machen und Ihnen helfen, den einfachen Fehler zu vermeiden, Ihre Daten über S3 preiszugeben.

Wenn Sie wirklich Daten aus dem privaten Speicher offenlegen müssten, würden Sie dies über eine API tun, die mit sinnvollen Sicherheitskontrollen ausgestattet ist.

Und was ist mit den neuen S3-Sicherheitsfunktionen?

Die neuen S3-Sicherheitsfunktionen von Amazon werden wahrscheinlich den gleichen Effekt haben wie ihre vorherigen Bemühungen: Sie werden mehr Buckets sichern, aber nicht alle. Nach der Einführung des "public"-Flags für offene Buckets und der E-Mail-Kampagne an die Besitzer dieser Buckets im November 2017 haben wir beispielsweise gesehen, dass viele Buckets verschwunden sind. Wir haben aber auch gesehen, dass viel mehr Buckets mit sensiblen Informationen bestehen bleiben und seitdem neue Buckets mit sensiblen, öffentlich zugänglichen Daten erstellt wurden.

Warum? Denn solange es möglich ist, ein System falsch zu konfigurieren, werden die Menschen dies tun. Das Hinzufügen neuer Funktionen, die es einfach machen, S3-Speicher als privat zu konfigurieren, ist nicht dasselbe wie das Entfernen der Möglichkeit, ihn als öffentlich zu konfigurieren.

Solange S3-Buckets für den öffentlichen Zugriff konfiguriert werden können, gibt es Datenoffenlegungen über S3-Buckets. Die Bewältigung erfordert grundlegende Veränderungen, die wir noch nicht sehen werden. Bis dahin werden wir weiterhin S3-Datenschutzverletzungen sehen.