GuardDuty in einer Organisation aktivieren

GuardDuty in einem einzelnen Konto zu aktivieren ist einfach, reale Umgebungen umfassen jedoch viele Konten. Die Erkennung in allen Konten manuell zu aktivieren und zu verwalten, ist fehleranfällig und führt zu Lücken. AWS löst dies mit dem Modell des delegierten Administrators, das an AWS Organizations angebunden ist.

AWS Organizations ermöglicht es Ihnen, mehrere Konten unter einem Verwaltungskonto zu gruppieren und in Organizational Units (OUs) zu strukturieren. Es bildet die Grundlage für die Governance mehrerer Konten. Viele Sicherheitsservices, darunter GuardDuty, integrieren sich in Organizations, um zentral über alle Mitgliedskonten hinweg zu arbeiten.

Statt die Sicherheit über das leistungsstarke Verwaltungskonto zu betreiben, bestimmen Sie für GuardDuty ein separates Konto als delegierten Administrator, normalerweise ein eigens dafür eingerichtetes Sicherheitskonto. Dieses Konto konfiguriert und überwacht GuardDuty für die gesamte Organisation. Damit folgen Sie der Best Practice, das Verwaltungskonto nicht für alltägliche Aufgaben zu verwenden.

Das Verwaltungskonto von Organizations ist äußerst sensibel. AWS empfiehlt daher, es ausschließlich für Abrechnung und Kontoverwaltung zu verwenden. Die Delegierung der Sicherheitsadministration an ein separates Konto begrenzt den Wirkungsbereich eines Vorfalls und setzt die Aufgabentrennung um – eine Best Practice des Well-Architected Frameworks, die auch in Prüfungen bevorzugt wird.

Nach der Einrichtung der Delegierung kann der Administrator GuardDuty in jedem vorhandenen Mitgliedskonto aktivieren und dessen Funde in einer einzigen Konsole anzeigen. Wenn der Administrator den Service verwaltet, können Mitglieder ihn nicht deaktivieren. Dadurch bleibt die Abdeckung konsistent und einzelne Teams können den Service nicht versehentlich abschalten.

Eine wichtige Funktion ist auto-enable: Jedes neue Konto, das der Organisation hinzugefügt wird, erhält automatisch eine aktivierte GuardDuty-Instanz. Dadurch wird die häufige Lücke geschlossen, dass ein neu erstelltes Konto zunächst unbeobachtet bleibt. Für die Prüfung ist dies wichtig, weil damit die Erkennungsabdeckung beim Wachstum der Organisation gewährleistet bleibt.

Der delegierte Administrator sieht alle Funde aus sämtlichen Konten in einer zentralen Ansicht. Diese zentrale Übersicht ist für ein organisationsweites Security-Operations-Team unerlässlich, damit es Funde priorisieren und darauf reagieren kann, ohne sich bei Dutzenden Konten anmelden zu müssen. Außerdem speist sie die zentrale Aggregation in Security Hub.

GuardDuty ist regional, daher muss die Aktivierung für die gesamte Organisation pro Region erfolgen. Ein häufiger Fehler besteht darin, GuardDuty in einer Region zu aktivieren und von einer globalen Abdeckung auszugehen. Um alle Aktivitäten abzudecken, aktivieren Sie GuardDuty in jeder von Ihnen verwendeten Region – auch in Regionen, in denen Sie derzeit keine Ressourcen erwarten.

Für die Einrichtung müssen Sie zunächst den vertrauenswürdigen Zugriff für GuardDuty in Organizations aktivieren und anschließend den delegierten Administrator registrieren. Danach verwaltet der Administrator die Mitgliedschaft und Konfiguration zentral. Diese einmalige Einrichtung zahlt sich aus, wenn die Organisation wächst.

Über die zentrale Konsolenansicht hinaus leiten Organisationen häufig die Findings aller Konten über die Aggregation in Security Hub oder durch den Export in einen gemeinsam genutzten S3-Bucket und EventBridge-Bus an ein zentrales Sicherheitskonto weiter. Dadurch erhält das Security-Operations-Team eine dauerhafte, kontenübergreifende Übersicht. Die Konzeption dieses zentralen Datenflusses ist ein wiederkehrendes Thema in Prüfungen zu Umgebungen mit mehreren Konten.

Vor der Integration in Organizations wurden Konten über eine Einladung verknüpft: Ein Administrator lud jedes Mitglied ein, das die Einladung annehmen musste. Dies funktioniert weiterhin, lässt sich aber nicht skalieren und aktiviert neue Konten nicht automatisch. Die Organizations-Methode mit einem delegierten Administrator wird bevorzugt, da sie die Mitgliedschaft zentral verwaltet und neue Konten automatisch aktiviert. In der Prüfung gilt dies als moderne Best Practice.

Wenden Sie die Erkennung organisationsweit an.

Skalieren Sie GuardDuty mit AWS Organizations und einem delegierten Administrator (einem dedizierten Sicherheitskonto, nicht dem Verwaltungskonto). Der Administrator aktiviert GuardDuty in den Mitgliedskonten, verwendet auto-enable für neue Konten und zeigt alle Findings zentral an. Denken Sie daran: GuardDuty ist regional. Aktivieren Sie den Dienst daher pro Region, um eine vollständige Abdeckung zu erreichen.