Auditor verlangt SecurityAudit-Policy für AWS – wie sicher ist dieser Zugriff?

Die SecurityAudit-Policy erlaubt kein Herunterladen von Storage-Objekten, Kundendaten können sie also nicht einfach ziehen. Aber Lesezugriffe auf Funktionskonfigurationen oder Server-Startdaten sind erlaubt. Wenn ihr Secrets im Klartext in eurem Code oder User Data liegen habt, sieht der Auditor die. Räumt das vorher auf.

Setzt bei der Rolle unbedingt auf das External-ID-Kriterium. Außerdem solltet ihr eine IP-Restriktion in die Vertrauensstellung packen, damit Logins nur über die Büro- oder VPN-IPs der Audit-Firma möglich sind. Nach den zwei Wochen löscht ihr die Rolle mit einem Klick und fertig.

Nutzt der Auditor automatisierte Scanning-Tools oder prüfen die Engineers manuell über die Konsole? Falls externe Cloud-Tools angebunden werden: Habt ihr euch deren AWS-Account-ID und das Handling der External ID vorab schriftlich geben lassen?

Wir haben für ein Compliance-Audit eine ganz ähnliche Rolle eingerichtet. Das Audit hat 12 Tage gedauert. Direkt danach haben wir die IAM-Rolle gelöscht und die Session des Auditors über die Audit-Logs abgefragt; insgesamt kamen sie auf rund 14.200 reine Read-Only-API-Aufrufe. Es gab keinerlei Versuche, Daten herunterzuladen.

bloß keeinen iam user anlegen und access keys rausgeben. also die keys werden am ende eh irgendwo vergessen dann richtet einfach ne rolle ein, tragt ne external id ein und löscht das ding einfach wieder wenn sie fertig sind.

Die Audit-Firmen hätten es natürlich am liebsten fix und fertig serviert, aber man muss ihnen doch nicht direkt eine Rolle auf dem Produktiv-Account geben. Die meisten Firmen ziehen sich die Konfigurationsreports und Security-Outputs per CLI selbst und übergeben das Ganze als Datei. Warum sollte man den kompletten Account live für ein Review öffnen?

In der vorab unterzeichneten Vertraulichkeitsvereinbarung (NDA) muss verbindlich geregelt sein, wie mit den Konfigurationsdaten verfahren wird, nach wie vielen Tagen im Cache der Audit-Tools gespeicherte Logs vernichtet werden und dass keinerlei Weitergabe an Dritte erfolgt.

Um es zusammenzufassen: SecurityAudit greift nur auf Konfigurationen zu, nicht auf eigentliche Daten, daher ist die Anfrage Standard. Trotzdem solltet ihr die Berechtigung per Rolle vergeben, mit External ID, IP-Einschränkung und zeitlicher Befristung versehen und die Rolle am Tag des Abschlusses direkt löschen sowie die System-Logs prüfen.

Da hast du recht. Wenn man versucht, alles gleichzeitig zu ändern, etabliert sich nichts richtig.

Ich hoffe, das hilft dir weiter.

Genau so und das ist zudem kaum bekannt. Die meisten Vorfälle beginnen nicht mit einer Schwachstelle, sondern mit einem geleakten Passwort.

Bei uns ist es genauso.

Da verstehe ich etwas nicht ganz. Je schwerer es ist, eine Entscheidung rückgängig zu machen desto langsamer solltet ihr sie treffen.

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

man sollte der Reihe nach vorgehen. also schrebie bei Entscheidungen auch das Worst-Case-Szenario auf, nicht nur das Beste.

wenn deine Situation anders ist, ändeert sich das natürlich.

Da stimme ich zu. Kein Prozess ohne Dokumentation verbessert sich, weil man nicht weiß, was man verbessern soll.

Das war's, entschuldige, wenn ich zu lang war.

Meine Frage ist geklärt, vielen Dank. Scheut euch nicht zu fragen, wer nicht fragt, zahlt am Ende mehr.

richtig. ehrlich gesagt wenn man Fehlalarme anschreit meldet sich daanach niemand mehr.

an deiner Stelle würed ich so vorgehen.

Ich habe diesen Weg schon hinter mir, ich erzähl mal. Menschen verteidigen nicht den Prozess, sondern die Gewohnheit. Der Widerstand kommt daher.

ich schreibe das, damit ihr denselben Fehler nicht macht. ehrlich gesagt die Zeit die ihr braucht um ein Problem zu erkennen, bestimmt direkt dessen Kosten.

an deiner Stelle würde ich so vorgehen.