SEC10-BP05 Vorab bereitgestellter Zugriff

Stellen Sie sicher, dass Notfallteams über den richtigen vorab bereitgestellten Zugriff in AWS verfügen, um die Zeit von der Untersuchung bis zur Wiederherstellung zu verkürzen.

Typische Anti-Muster:

Risikostufe, wenn diese bewährte Methode nicht eingeführt wird: Mittel

Implementierungsleitfaden

AWS empfiehlt, nach Möglichkeit die Abhängigkeit von langlebigen Anmeldeinformationen zu reduzieren oder ganz zu beseitigen und stattdessen Just-In-Time-Berechtigungseskalationsmechanismen zu verwenden. Langlebige Anmeldeinformationen sind ein potenzielles Sicherheitsrisiko und erhöhen den Verwaltungsaufwand. Für die meisten Verwaltungsaufgaben und für die Reaktion auf Vorfälle empfehlen wir die Implementierung eines Identitätsverbunds zusammen mit einer temporären Eskalierung für Administratorzugriff. In diesem Modell beantragt ein Benutzer eine höhere Berechtigungsstufe (etwa für eine Vorfallreaktionsrolle). Anschließend wird, sofern der Benutzer grundsätzlich dafür infrage kommt, eine entsprechende Anforderung an einen Genehmiger gesendet. Wenn die Anforderung genehmigt wurde, erhält der Benutzer temporäre AWS-Anmeldeinformationen für die Durchführung seiner Aufgaben. Nach Ablauf dieser Anmeldeinformationen muss der Benutzer eine neue Erhöhungsanforderung übermitteln.

Wir empfehlen für die meisten Vorfallreaktionsszenarien die Verwendung temporärer Berechtigungseskalierungen. Die korrekte Vorgehensweise ist die Verwendung von AWS Security Token Service und Sitzungsrichtlinien zur Festlegung der Zugriffsbereiche.

Es gibt Szenarien, in denen Verbundidentitäten nicht verfügbar sind. Hier ein paar Beispiele:

Für diese Fälle sollte Notfallzugriff (Break-Glass-Zugriff) konfiguriert werden, um eine Untersuchung und schnelle Behandlung des Vorfalls zu ermöglichen. Wir empfehlen die Verwendung eines Benutzers, einer Gruppe oder einer Rolle mit ausreichenden Berechtigungen für die Durchführung von Aufgaben und den Zugriff auf AWS-Ressourcen. Verwenden Sie den Root-Benutzer nur für Aufgaben, die Root-Benutzeranmeldeinformationen erfordern. Um zu prüfen, ob die Notfallteams über die korrekte Zugriffsstufe für AWS und andere relevante Systeme verfügen, empfehlen wir die Bereitstellung dedizierter Konten. Die Konten benötigen privilegierten Zugriff und müssen streng kontrolliert und überwacht werden. Die Konten müssen mit den geringstmöglichen Berechtigungen versehen sein, die für die erforderlichen Aufgaben benötigt werden, und die Zugriffsstufe muss auf den Playbooks basieren, die im Rahmen des Vorfallmanagementplans erstellt werden.

Verwenden Sie als bewährte Methode zweckgerichtet erstellte und dedizierte Benutzer und Rollen. Die vorübergehende Eskalierung des Zugriffs eines Benutzers oder einer Rolle über IAM-Richtlinien macht unklar, welchen Zugriff Benutzer während eines Vorfalls hatten, und birgt die Gefahr, dass die eskalierten Berechtigungen später nicht widerrufen werden.

Es ist wichtig, möglichst viele Abhängigkeiten zu entfernen, um sicherzustellen, dass in einem möglichst großen Spektrum von Ausfallszenarien zugegriffen werden kann. Erstellen Sie deshalb ein Playbook, um sicherzustellen, dass Vorfallreaktionsbenutzer als Benutzer in einem dedizierten Sicherheitskonto erstellt und nicht durch einen vorhandenen Verbund oder eine Single Sign-On (SSO)-Lösung verwaltet werden. Alle einzelnen Mitglieder von Notfallteams müssen über ein eigenes benanntes Konto verfügen. Die Kontokonfiguration muss eine Richtlinie für sichere Passwörter sowie die Multi-Faktor-Authentifizierung (MFA) erzwingen. Wenn die Playbooks zur Vorfallreaktion nur Zugriff auf die AWS Management Console benötigen, sollten für den Benutzer keine Zugriffsschlüssel konfiguriert werden und er sollte explizit auch keine Zugriffsschlüssel erstellen dürfen. Dies kann mit IAM-Richtlinien oder Service-Kontrollrichtlinien (SCPs) konfiguriert werden, wie in den bewährten AWS-Sicherheitsmethoden für AWS Organizations SCPs erläutert. Mit Ausnahme der Möglichkeit zur Übernahme von Vorfallreaktionsrollen in anderen Konten sollten die Benutzer über keinerlei Berechtigungen verfügen.

Während eines Vorfalls kann es erforderlich sein, anderen internen oder externen Personen Zugriff zu gewähren, um Untersuchungs-, Korrektur- oder Wiederherstellungsaktivitäten zu unterstützen. Verwenden Sie in diesem Fall den vorher erwähnten Playbook-Mechanismus. Darüber hinaus muss ein Prozess vorhanden sein, um sicherzustellen, dass jeglicher zusätzliche Zugriff sofort nach Abschluss des Vorfalls widerrufen wird.

Um sicherzustellen, dass die Verwendung von Vorfallreaktionsrollen ordnungsgemäß überwacht und geprüft werden kann, ist es wichtig, dass die für diesen Zweck erstellten IAM-Konten nicht von mehreren Personen verwendet werden und dass der Root-Benutzer des AWS-Kontos nur verwendet wird, wenn dies für eine bestimmte Aufgabe erforderlich ist. Wenn der Root-Benutzer erforderlich ist (zum Beispiel, wenn kein IAM-Zugriff auf ein bestimmtes Konto verfügbar ist), verwenden Sie einen separaten Prozess mit einem verfügbaren Playbook, um die Verfügbarkeit der Anmeldeinformationen und des MFA-Tokens des Root-Benutzers zu prüfen.

Erwägen Sie zur Konfiguration der IAM-Richtlinien für die Vorfallreaktionsrollen die Verwendung von IAM Access Analyzer, um Richtlinien auf der Grundlage von AWS CloudTrail-Protokollen zu erstellen. Gewähren Sie dazu der Vorfallreaktionsrolle in einem Nicht-Produktionskonto Administratorzugriff und durchlaufen Sie Ihre Playbooks. Anschließend kann eine Richtlinie erstellt werden, die nur die ausgeführten Aktionen zulässt. Diese Richtlinie kann dann auf alle Vorfallreaktionsrollen über alle Konten hinweg angewendet werden. Möglicherweise möchten Sie eine separate IAM-Richtlinie für jedes Playbook erstellen, um Management und Auditing zu vereinfachen. Beispiel-Playbooks können Reaktionspläne für Ransomware-Angriffe, Datenschutzverletzungen, Verlust von produktionsrelevantem Zugriff oder andere Szenarien enthalten.

Verwenden Sie die Vorfallreaktionskonten, um dedizierte IAM-Rollen in anderen AWS-Konten-Konten für die Vorfallreaktion anzunehmen. Diese Rollen müssen so konfiguriert sein, dass sie nur von Benutzern im Sicherheitskonto angenommen werden können, und das Vertrauensverhältnis muss erfordern, dass der aufrufende Prinzipal per MFA authentifiziert wurde. Die Rollen müssen eng gefasste IAM-Richtlinien verwenden, um den Zugriff zu steuern. Stellen Sie sicher, dass alle AssumeRole-Anforderungen für diese Rollen in CloudTrail protokolliert und gemeldet werden und dass alle mit diesen Rollen durchgeführten Aktivitäten protokolliert werden.

Es wird nachdrücklich empfohlen, die IAM–Konten und die IAM-Rollen deutlich zu benennen, damit sie in CloudTrail-Protokollen leicht zu finden sind. Geben Sie also beispielsweise den IAM-Konten den Namen <USER_ID>-BREAK-GLASS und den IAM-Rollen den Namen BREAK-GLASS-ROLE.

CloudTrail wird verwendet, um API-Aktivitäten in Ihren AWS-Konten zu protokollieren, und sollte zum Konfigurieren von Warnungen zur Nutzung der Vorfallreaktionsrollen eingesetzt werden. Weitere Informationen finden Sie im Blog-Beitrag zur Konfiguration von Warnungen bei Verwendung von Root-Schlüsseln. Die Anweisungen können geändert werden, um den Amazon CloudWatch-Metrikfilter so zu konfigurieren, dass nach AssumeRole-Ereignissen gefiltert wird, die mit der IAM-Rolle für die Vorfallreaktion zusammenhängen:

{ $.eventName = "AssumeRole" && $.requestParameters.roleArn = "<INCIDENT_RESPONSE_ROLE_ARN>" && $.userIdentity.invokedBy NOT EXISTS && $.eventType != "AwsServiceEvent" }

Da die Vorfallreaktionsrollen sehr wahrscheinlich eine hohe Zugriffsstufe haben, ist es wichtig, dass diese Warnungen an eine weit gefasste Gruppe gesendet werden und dass umgehend auf sie reagiert wird.

Während eines Vorfalls kann es vorkommen, dass ein Mitglied eines Notfallteams Zugriff auf Systeme benötigt, die nicht direkt durch IAM geschützt sind. Dazu können Amazon-Elastic-Compute-Cloud-Instances, Amazon-Relational-Database-Service-Datenbanken oder Software as a Service (SaaS)-Plattformen gehören. Es wird nachdrücklich empfohlen, anstelle nativer Protokolle wie SSH oder RDP AWS Systems Manager Session Manager für alle administrativen Zugriffe auf Amazon-EC2-Instances zu verwenden. Dieser Zugriff kann mit IAM (sicher und geprüft) gesteuert werden. Gegebenenfalls ist es auch möglich, Teile Ihrer Playbooks mithilfe von Run-Command-Dokumenten von AWS Systems Manager zu automatisieren, um Benutzerfehler zu reduzieren und die Wiederherstellung zu beschleunigen. Für den Zugriff auf Datenbanken und Tools von Drittanbietern empfehlen wir die Speicherung von Anmeldeinformationen in AWS Secrets Manager und die Gewährung des Zugriffs für die Vorfallreaktionsrollen.

Außerdem sollte die Verwaltung der IAM-Konten für die Vorfallreaktion Ihren Joiners-, Movers- und Leavers-Prozessen hinzugefügt sowie regelmäßig geprüft und getestet werden, um sicherzustellen, dass nur die beabsichtigten Zugriffsrechte gewährt werden.

Ressourcen

Zugehörige Dokumente:

Zugehörige Videos:

Zugehörige Beispiele: