Kunden-Auditor will eine „AWS-Sicherheits-Audit-Rolle“ in unserem Cloud-Konto – wie viele Rechte sollten wir vergeben?

Der entscheidende Unterschied liegt zwischen ReadOnlyAccess und SecurityAudit. Mit ReadOnlyAccess kann der Auditor Dateien aus euren Objektspeichern herunterladen und tief in Datenbank-Metadaten herumstöbern. Ein Security-Auditor braucht nur die SecurityAudit-Policy und im Einzelfall Zugriff auf ein paar begrenzte Monitoring-Dashboards.

Drei Punkte, die ihr bei einer sicheren Audit-Rolle nicht auslassen solltet: 1) Eine kryptische, nicht erratbare ExternalId in die Trust Policy packen. 2) Die maximale Sitzungsdauer (MaxSessionDuration) auf eine Stunde setzen. 3) Eine IP-Einschränkung in der Policy hinterlegen, damit der Zugriff nur aus dem IP-Bereich des Prüfers klappt.

Es gibt kaum Audit-Standards, die zwingend einen direkten Live-Zugriff auf das AWS-Konto vorschreiben. Meistens reichen Konfigurationsberichte und Exports völlig aus. Habt ihr mal schriftlich nachgefragt, warum Reports allein nicht genügen, bevor ihr jemanden ins System lasst?

Korrektur: Ich hatte die Zahl falsch im Kopf, sie war etwas niedriger.

Bevor Zugänge vergeben werden, muss eine beidseitige Geheimhaltungsvereinbarung (NDA) mit der Prüfungsgesellschaft unterschrieben sein. Darin müssen Audit-Umfang, betroffene Ressourcen und Haftung für Sitzungsprotokolle klar geregelt werden. Ohne saubere Rechtsgrundlage wird gar nichts im Account freigeschaltet.

Wir hatten letztes Jahr zwei ähnliche Prüfungen. Wir haben die Rolle für ein Zeitfenster von genau 72 Stunden aktiviert und die Session-Dauer auf 3 Stunden limitiert. Der Auditor hat insgesamt nur 42 verschiedene API-Abfragen gefahren und war durch. Danach Rolle sofort gelöscht, lief komplett schmerzfrei.

beim ersten Mal macht man sich da völlig verrückt ganz normal aber halt aber keine Panik: Wenn ihr dem Auditor sagt dass eure internen Richtlinien keine direkten Konsolen-User erllauben und ihr stattdessen eine Audit-Rolle mit External ID einrichtet wirkt das direkt extrem professionell.

sobald die rolle steht filtert in cloudtrail ab und zu nach dem rollennamen um zu sehen was der treibt. wenn der grundlos durch dienste klickt direkt nachhaken.

Fackelt nicht lange: Im IAM-Dashboard neue Rolle erstellen, als Typ anderes AWS-Konto wählen, Account-ID des Kunden eintragen, Haken bei External ID setzen, nur die SecurityAudit-Policy anhängen und speichern.

Ich schreibe mal meine Erfahrung auf. Entscheidend ist nicht die Zahl, sondern worauf sie sich bezieht.

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

Betrachtet man den Prozess, ändert sich das Bild. Wenn man versucht, alles gleichzeitig zu ändern, etabliert sich nichts richtig.

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

Es gibt auch noch die Mess-Seite. Ein automatisierter Scan-Report ist kein Penetrationstest.

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

Du hast recht.

Wenn du so vorgehst, kläre das vorher. Nur weil alle es tun, heißt es nicht, dass es richtig ist.

Änderungen an Zahlungsdaten werden niemals über den Kanal bestätigt, über den sie eingehen. Wenn es jemand anders macht, würde mich das auch interessieren.

Du hast recht, ich bin denselben Weg gegangen. Vergessene Testumgebungen sind häufiger das Einfallstor als das Live-System.

Nach diesem Erlebnis hat sich meine Sichtweise geändert. Kein Prozess ohne Dokumentation verbessert sich, weil man nicht weiß was man verbessern soll.

Ein automatisierter Scan-Report ist kein Penetrationstest. Aus Erfahrung weiß ich das.

Das wusste ich nicht.

Das habe ich auch erlebt.

Ich erkläre mal die technische Seite. Der meiste Zeitverlust entsteht durch Arbeiten, die auf Freigaben warten.

Wenn deine Situation anders ist, ändert sich das natürlich.