Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
SEC10-BP05 Zugriff vor der Bereitstellung
Stellen Sie sicher, dass den Incident-Respondern vorab der richtige Zugriff zugewiesen wurde, um den Zeitaufwand für die Untersuchung AWS bis zur Wiederherstellung zu reduzieren.
Typische Anti-Muster:
-
Verwendung des Root-Kontos für die Reaktion auf Vorfälle
-
Veränderung bestehender Benutzerkonten
-
Direktes Manipulieren von IAM Berechtigungen bei der Gewährung von Rechteerweiterungen just-in-time
Risikostufe bei fehlender Befolgung dieser bewährten Methode: Mittel
Implementierungsleitfaden
AWS empfiehlt, die Abhängigkeit von langlebigen Anmeldeinformationen, wo immer möglich, zu reduzieren oder ganz zu vermeiden und stattdessen temporäre Anmeldeinformationen und Mechanismen zur just-in-timeRechteerweiterung 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
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:
-
Ausfall im Zusammenhang mit einem kompromittierten Identitätsanbieter (IdP)
-
Durch fehlerhafte Konfiguration oder menschlichen Fehler beeinträchtigtes Managementsystem für den Verbundzugriff
-
Böswillige Aktivitäten wie ein Distributed-Denial-of-Service (DDoS) -Ereignis oder die Nichtverfügbarkeit des Systems.
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, dass Sie einen Benutzer, eine Gruppe oder eine Rolle mit den entsprechenden Berechtigungen verwenden, um Aufgaben auszuführen und auf Ressourcen zuzugreifen AWS . Verwenden Sie den Root-Benutzer nur für Aufgaben, die Root-Benutzeranmeldeinformationen erfordern. Um sicherzustellen, dass Incident Responder die richtigen Zugriffsrechte auf AWS und andere relevante Systeme haben, empfehlen wir die Vorabbereitstellung von dedizierten 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. Durch die vorübergehende Ausweitung des Benutzer- oder Rollenzugriffs durch das Hinzufügen von IAM Richtlinien ist nicht klar, welchen Zugriff die Benutzer während des Vorfalls hatten, und es besteht auch die Gefahr, dass die eskalierten Rechte nicht entzogen 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. Um dies zu unterstützen, sollten Sie ein Playbook erstellen, das sicherstellt, dass Incident-Response-Benutzer als Benutzer mit einem eigenen Sicherheitskonto erstellt werden und nicht über eine bestehende Federation- oder Single Sign-On () -Lösung verwaltet werden. SSO Alle einzelnen Mitglieder von Notfallteams müssen über ein eigenes benanntes Konto verfügen. Bei der Kontokonfiguration müssen strenge Kennwortrichtlinien und eine mehrstufige Authentifizierung () durchgesetzt werden. MFA Wenn für die Playbooks zur Reaktion auf Incident Response nur Zugriff auf die erforderlich ist AWS Management Console, sollten für den Benutzer keine Zugriffsschlüssel konfiguriert sein und es sollte ihm ausdrücklich untersagt werden, Zugriffsschlüssel zu erstellen. Dies kann mit IAM Richtlinien oder Dienststeuerungsrichtlinien (SCPs) konfiguriert werden, wie unter Bewährte AWS Sicherheitsmethoden für beschrieben. AWS Organizations SCPs 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 der Einsatz von Incident-Response-Rollen ordnungsgemäß überwacht und geprüft werden kann, ist es wichtig, dass die zu diesem Zweck erstellten IAM Konten nicht von Einzelpersonen gemeinsam genutzt werden und dass sie nur verwendet werden, wenn sie für eine bestimmte Aufgabe erforderlich sind. Root-Benutzer des AWS-Kontos Wenn der Root-Benutzer erforderlich ist (z. B. wenn der IAM Zugriff auf ein bestimmtes Konto nicht verfügbar ist), überprüfen Sie anhand eines separaten Verfahrens die Verfügbarkeit der Anmeldedaten und des Tokens des Root-Benutzers. MFA
Um die IAM Richtlinien für die Rollen zur Reaktion auf Vorfälle zu konfigurieren, sollten Sie in Erwägung ziehen, IAMAccess Analyzer zu verwenden, um Richtlinien auf AWS CloudTrail der Grundlage von Protokollen zu generieren. 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 für jedes Playbook eine separate IAM Richtlinie erstellen, um die Verwaltung und Prüfung zu vereinfachen. Beispiel-Playbooks können Reaktionspläne für Ransomware-Angriffe, Datenschutzverletzungen, Verlust von produktionsrelevantem Zugriff oder andere Szenarien enthalten.
Verwenden Sie die Incident-Response-Konten, um spezielle IAMAufgaben im Bereich Incident Response in anderen AWS-Konten Bereichen zu übernehmen. Diese Rollen müssen so konfiguriert werden, dass sie nur von Benutzern im Sicherheitskonto übernommen werden können, und die Vertrauensstellung muss voraussetzen, dass sich der aufrufende Prinzipal über authentifiziert hat. MFA Für die Rollen müssen eng begrenzte Richtlinien zur Zugriffskontrolle verwendet IAM werden. Stellen Sie sicher, dass alle AssumeRole Anfragen für diese Rollen angemeldet sind und dass Benachrichtigungen angezeigt werden CloudTrail und dass alle Aktionen, die mit diesen Rollen ausgeführt werden, protokolliert werden.
Es wird dringend empfohlen, dass sowohl die IAM Konten als auch die IAM Rollen eindeutig benannt sind, damit sie in den CloudTrail Protokollen leicht auffindbar sind. Ein Beispiel hierfür wäre die Benennung der IAM Konten <USER_ID>-BREAK-GLASSBREAK-GLASS-ROLE.
CloudTrailwird verwendet, um API Aktivitäten in Ihren AWS Konten zu protokollieren und sollte verwendet werden, um Benachrichtigungen zur Nutzung der Incident-Response-Rollen zu konfigurierenAssumeRole Ereignisse filter-to-filter im Zusammenhang mit der IAM Rolle „Incident Response“ zu konfigurieren:
{ $.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 ist es möglich, dass ein Responder Zugriff auf Systeme benötigt, die nicht direkt durch IAM gesichert sind. Dazu könnten Amazon Elastic Compute Cloud-Instances, Amazon Relational Database Service Service-Datenbanken oder software-as-a-service (SaaS) -Plattformen gehören. Es wird dringend empfohlen, für den gesamten administrativen Zugriff auf EC2 Amazon-Instances anstelle von systemeigenen Protokollen wie SSH oder RDP zu verwenden. AWS Systems Manager Session Manager Dieser Zugriff kann über IAM eine sichere und geprüfte Methode 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 Zugangsdaten in den Rollen der Incident-Responder zu speichern AWS Secrets Manager und ihnen Zugriff zu gewähren.
Schließlich sollte die Verwaltung der IAM Incident-Response-Konten zu Ihren Joiners-, Movers- und Leavers-Prozessen hinzugefügt und regelmäßig überprüft und getestet werden, um sicherzustellen, dass nur der vorgesehene Zugriff erlaubt ist.
Ressourcen
Zugehörige Dokumente:
Zugehörige Videos:
Zugehörige Beispiele:
