Alles zu AWS migriert – gibt es eine Sicherheits-Checkliste, die wir selbst abarbeiten können?

Drei Dinge, die ihr am besten noch heute erledigt: 1) Billing Alerts einrichten – falls jemand euren Account zum Krypto-Mining kapert, merkt ihr das, bevor eine Rechnung über Tausende Pfund ins Haus flattert. 2) Prüfen, ob CloudTrail-Logs für alle Regionen aktiv sind. 3) Sicherstellen, dass automatisierte Datenbank-Backups laufen.

Da ihr Finanzdaten verarbeitet, liegt die rechtliche Verantwortung nach UK GDPR direkt bei der Geschäftsführung. Selbst wenn ihr euch keinen vollen Pentest holt: Dokumentiert die von euch durchgeführten Sicherheitsprüfungen unbedingt mit Datum und Screenshots.

Wir hatten letztes Jahr nach einer Migration den Fall, dass der externe Dev einen Admin-API-Key auf seinem lokalen Rechner vergessen hatte. Der lag da 4 Monate lang ungeschützt rum. Zum Glück ist nichts passiert, aber seitdem gehen wir jeden ersten Montag im Monat die IAM-Keys durch.

Geht in die IAM-Konsole und ladet den 'Credential Report' runter. Das ist eine einzige CSV-Datei, die euch direkt zeigt, wer kein MFA anhat, wann welcher Access Key zuletzt genutzt wurde und wie alt die Passwörter sind. Damit findet ihr in 10 Minuten die größten Baustellen.

Wenn wir bei S3 Public Access komplett blockieren, betrifft das dann auch die Rechnungs-PDFs unserer Kunden? ehrlich gesagt sie laden ihre Belege über die App herunter, nicht dass die Nutzer dann plötzlich Fehler bekommen.

Grundregel für S3: Dateien sollten niemals direkt öffentlich im Netz liegen. Wenn ein Kunde ein Dokument abruft, generiert eure App im Hintergrund eine temporäre, signierte URL (Presigned URL). Damit bleibt der Bucket nach außen hin komplett dicht, aber der berechtigte Nutzer bekommt einen z.B. für 5 Minuten gültigen Download-Link.

Alle raten immer dazu, sämtliche Monitoring- und Log-Tools anzuschalten, aber keiner redet über die Kosten. Wenn man Logging-Services blind in allen Regionen aktiviert, zahlt man am Monatsende für Logs teils mehr als für die eigentlichen Server. Aktiviert das Zeug nur in der Region, die ihr auch wirklich nutzt.

Schaut als Erstes in den Trusted Advisor. Schon die Free-Version schlägt bei grundlegenden Sicherheitslücken, offenen Ports oder fehlendem Root-MFA sofort Alarm. Wenn ihr dort alle roten Meldungen gelöst habt, ist das Gröbste schon mal erledigt.

Kurzfassung für Neueinsteiger: Wenn man Fehlalarme anschreit, meldet sich danach niemand mehr.

Wenn es jemand anders macht, würde mich das auch interessieren.

Bei uns war es so. Wer bei AWS Sicherheits-Checkliste hetzt stolpert alle an derselben Stelle.

Verlasst euch nicht auf eine einzige Maßnahme; geht schichtweise vor. Wenn ihr das Ergebnis hier postet, hilft es auch anderen.

Entschuldigung, aber das gilt nicht in jedem Fall. Wer bei AWS Sicherheits-Checkliste hetzt stolpert alle an derselben Stelle.

Nur als Notiz, könnte nützlich sein.

Vielen Dank, das hat mir sehr geholfen.

Vor zwei Jahren habe ich genau dasselbe erlebt. Vergessene Testumgebungen sind häufiger das Einfallstor als das Live-System.

Schreibt mir, wenn ihr Fragen habt, ich antworte so gut ich kann.

Ich erkläre mal die technische Seite. Verlasst euch nicht auf eine einzige Maßnahme; geht schichtweise vor.

Gut, dass du diesen Thread eröffnet hast. Bei uns war der größte Zeitfresser die Unklarheit darüber, wer entscheidet.

Überstürzte Entscheidungen sind oft solche, die man sechs Monate später korrigieren muss. Das ist meine Meinung, ich behaupte nicht dass es absolut richtig ist.

Bleibe dran.

Bei mir war es genau umgekehrt deshalb schreibe ich das... ehrlich gesagt lösungen die im kleinen Maßstab funktionieren, brechen bei Wachstum zusammen das habe ich spät gelernt.

Das wars, entschuldige wenn ich zu lang war.

Der am häufigsten übersehene Punkt bei AWS Sicherheits-Checkliste ist dieser: Nur weil alle es tun, heißt es nicht, dass es richtig ist.

Das ist meine Meinung, ich behaupte nicht, dass es absolut richtig ist.