![](\"https:\/\/borncity.com\/blog\/wp-content\/uploads\/2021\/05\/Cloud-Symbol.jpg\" "\\"Cloud\\"")
Irgendwie dumm gelaufen: Ein Software-Entwickler hat vor einigen Wochen ein privates AWS S3 Bucket aufgesetzt, aber leer gelassen. Als er zwei Tage sp\u00e4ter die AWS-Abrechnungsseite \u00fcberpr\u00fcfte, um sicherzustellen, dass das aufgesetzte S3-Bucket kostenlos bleiben w\u00fcrde, sah er sich mit aufgelaufenen Kosten von 1.300 US-Dollar konfrontiert. Dumm gelaufen, die Cloud kann schon echte \"Schmerzen\" bereiten. <\/p>\n
<\/p>\n
In ganz kurz: Vor einigen Wochen begann der Entwickler mit der Arbeit an einem PoC f\u00fcr ein Dokumentenindizierungssystem f\u00fcr seinen Kunden. Dazu erstellte der gute Mann einen einzelnen S3-Bucket in der Region eu-west-1 <\/em>und lud einige Dateien zu Testzwecken dorthin hoch. So weit so normal – wobei ich bei solchen Konstruktionen schon Bauchschmerzen h\u00e4tte. Diese \"Test-Cloud-Konten\" sind sowohl bei Amazons AWS S3-Service als auch bei Microsofts Azure kostenlos. Ich erinnere mich, dass ich bei Microsoft Azure sogar zeitweise Konten mit 150 US-Dollar-Guthaben hatte. Aber Du wei\u00dft nie, ob Du mit dem Traffic im Rahmen dessen bleibst, was kostenlos ist. <\/p>\n Als der Entwickler zwei Tage sp\u00e4ter auf seiner AWS-Abrechnungsseite \u00fcberpr\u00fcfte, ob er noch im Rahmen Free-Tier-Grenzen l\u00e4ge, kam der Schock. Auf dem S3-Bucket waren bereits Kosten von 1.300 $ aufgelaufen. Obiger Tweet zeigt in der Grafik, dass an einem Tag fast 100.000.000 S3 PUT-Anforderungen auf die betreffende Instanz durchgef\u00fchrt worden waren. <\/p>\n Standardm\u00e4\u00dfig protokolliert AWS keine Anforderungen, die f\u00fcr Ihre S3-Buckets ausgef\u00fchrt werden. Solche Protokolle k\u00f6nnen jedoch mit AWS CloudTrail oder S3 Server Access Logging aktiviert werden. Nachdem der Software-Entwickler die CloudTrail-Protokolle aktiviert hatte, stellte er sofort Tausende von Schreibanforderungen fest, die von mehreren Konten oder von au\u00dferhalb von AWS stammten.<\/p>\n Erste Vermutung: Es ist eine Art DDoS-\u00e4hnlichen Angriff gegen das AWS-Konto, was aber keinen Sinn macht. Es stellte sich heraus, dass ein beliebtes Open-Source-Tools standardm\u00e4\u00dfig so konfiguriert war, dass es seine Backups in Amazon Web Services S3 speicherte. Als Platzhalter f\u00fcr einen Bucket-Namen wurde der gleiche Name verwendet, den der Entwickler f\u00fcr seinen S3-Bucket benutzt hatte. Das bedeutete, dass jede Bereitstellung dieses Open-Source-Tools mit Standardkonfigurationswerten versuchte, seine Sicherungen im S3-Bucket des Entwicklers zu speichern!<\/p>\n Der Fall hat gleich einige Implikationen, die einem beim Lesen des Beitrags hier<\/a> so durch den Kopf gehen. So wird sofort der Sicherheitsaspekt auftauchen: Jemand krallt sich das AWS S3-Bucket mit dem Namen, der Default im Open Source-Tool verwendet wurde. Und schon bekommt er Backups von allen Benutzern, die die Standardkonfiguration nicht angepasst haben, auf sein S3-Bucket geliefert. <\/p>\n Der zweite Aspekt ist das Thema Kosten. Hier r\u00e4t ein Nutzer: Erste Regel, die bei Cloud-Lehrg\u00e4ngen vermittelt wird: Namen f\u00fcr alle Ressourcen, deren Namespace global ist, zuf\u00e4llig (randomized) vergeben und Tags verwenden, um sie zu finden\/zu organisieren. In Azure haben die Entwickler Ressourcengruppen festgelegt, um Dinge zu organisieren, schreibt der Betreffende. <\/p>\n Es dauerte nicht lange, bis diese Geschichte auch von Amazon bemerkt wurde, da der Beitrag auf Medium geteilt wurde. AWS-Chefevangelist Jeff Barr schrieb daraufhin in einem Tweet mit, dass das Unternehmen etwas gegen die Situation unternehmen werde:<\/p>\n Vielen Dank an alle, die uns auf diesen Artikel aufmerksam gemacht haben. Wir stimmen zu, dass Kunden nicht f\u00fcr unautorisierte Anfragen zahlen sollten, die sie nicht initiiert haben. Wir werden in K\u00fcrze mehr dar\u00fcber berichten, wie wir diese Geb\u00fchren verhindern werden.<\/p>\n<\/blockquote>\n Was AWS genau unternehmen will, ist mir nicht klar. Aber der Fall zeigt, welche Fallen in der Cloud schlummern, und dass man sehr schnell als Entwickler oder Nutzer die Kontrolle \u00fcber seine Daten verlieren kann. <\/p>\n","protected":false},"excerpt":{"rendered":" Irgendwie dumm gelaufen: Ein Software-Entwickler hat vor einigen Wochen ein privates AWS S3 Bucket aufgesetzt, aber leer gelassen. Als er zwei Tage sp\u00e4ter die AWS-Abrechnungsseite \u00fcberpr\u00fcfte, um sicherzustellen, dass das aufgesetzte S3-Bucket kostenlos bleiben w\u00fcrde, sah er sich mit aufgelaufenen … Weiterlesen Ich bin die Tage auf X \u00fcber einen Tweet<\/a> von Laura Wendel auf den betreffenden Sachverhalt gesto\u00dfen, den der Betroffene auf Medium im Beitrag How an empty S3 bucket can make your AWS bill explode<\/a> geschildert hat. <\/p>\n
![](\"https:\/\/i.postimg.cc\/J0WBZWcD\/image.png\"\/)
<\/a><\/p>\nWoher kamen diese Anforderungen?<\/h2>\n
\n