AWS-WAF-Governance im großen Maßstab

Große Unternehmen mit mehreren Teams, die eigene Webanwendungen oder APIs entwickeln und betreiben, setzen Tools und Prozesse ein, um die Sicherheitskontrollen in allen Teams konsistent zu halten und exponierte Endpunkte mit schwachem oder keinem Schutz zu vermeiden. AWS Firewall Manager ist ein Tool, mit dem Unternehmen AWS-WAF- und Shield Advanced-Bereitstellungen im großen Maßstab verwalten können.

Mit Firewall Manager können Sie AWS-WAF- oder Shield Advanced-Richtlinien definieren, die automatisch auf Ihre öffentlich zugänglichen Ressourcen wie CloudFront-Distributionen, ALBs oder API-Gateways angewendet werden. Eine Richtlinie besteht aus:

• Dem Geltungsbereich, der festlegt, welche Art von Ressourcen (CloudFront, ALB usw.), ob nur Ressourcen mit bestimmten Tags bzw. welche Konten oder Organisationseinheiten einbezogen oder ausgeschlossen werden.
• Regeln, die definieren, welche WAF-Regelgruppen angewendet werden, ob die Protokollierung zentral erfolgt, und ob Shield Advanced-Schutzmaßnahmen hinzugefügt werden.
• Eine Aktion, die definiert, was geschehen soll, wenn eine Ressource im Geltungsbereich einer Richtlinie gefunden wird. Sie können beispielsweise automatisch Richtlinienregeln durchsetzen oder sie einfach melden. Bei einer ersten Bereitstellung von Firewall Manager wird empfohlen, die automatische Fehlerbehebung zuerst deaktiviert zu lassen, um die Ressourcen zu identifizieren, die manuell bearbeitet werden müssen, ohne dass sich Auswirkungen auf bestehende Anwendungen ergeben. Wenn ein höheres Maß an Vertrauen erreicht ist, können Sie Firewall Manager wieder auf Automatik umstellen.

Um Firewall Manager verwenden zu können, müssen bestimmte Voraussetzungen erfüllt sein. AWS Config ist eine der Voraussetzungen für Firewall Manager. Wenn Sie AWS Config nur in Verbindung mit Firewall Manager verwenden, können Sie die Kosten dafür optimieren, indem Sie die Aufzuzeichnenden Ressourcentypen auf die für Ihr Szenario relevanten Ressourcen beschränken (z. B. WAF, CloudFront Distribution, Load Balancer usw.). Richtlinien sind regionale Konstrukte (z. B. benötigen Sie eine globale Richtlinie für CloudFront und eine regionale Richtlinie in jeder Region, in der Sie über regionale Ressourcen wie ALBs und API-Gateways verfügen). Es gibt auch eine AWS-Lösung, die Ihnen die Bereitstellung von Firewall Manager-Richtlinien in allen AWS Organizations erleichtert

Wenn Sie eine WAF-Richtlinie erstellen, stellt Firewall Manager eine WAF-WebACL mit den Richtlinien-WAF-Regeln in den AWS-Konten innerhalb des Geltungsbereichs der Richtlinie bereit. In einer WAF-Richtlinie können Sie zwei Arten von Regelgruppen definieren, die von Firewall Manager zur bereitgestellten WebACL hinzugefügt werden:

• Eine erste Regelgruppe, die vor jeder anderen Regel ausgewertet wird.
• Eine letzte Regelgruppe, die am Ende ausgewertet wird.

Ein zentral agierendes Sicherheitsteam hat damit die Möglichkeit, gemeinsame Regelgruppen im Unternehmen durchzusetzen. Gleichzeitig können Anwendungsteams benutzerdefinierte Regeln, die für ihre Anwendung relevant sind, zwischen der ersten und der letzten gemeinsamen Regelgruppe hinzuzufügen. Da Regeln in AWS WAF der Reihe nach ausgewertet werden, wird die erste gemeinsame Regelgruppe vor jeder anderen Regel evaluiert. Danach die Regeln, die von den Anwendungsteams definiert wurden, und schließlich die letzte gemeinsame Regelgruppe.

Sie können eine CI/CD-Pipeline erstellen, um allgemeine WAF-Regelgruppen in der AWS-WAF-Richtlinie des AWS-Administratorkontos zu aktualisieren, die dann innerhalb weniger Minuten von Firewall Manager in der gesamten Organisation bereitgestellt wird. In diesem Blog erfahren Sie, wie OLX mithilfe einer CI/CD-Pipeline eine zentrale WAF-Richtlinie mit einem zentralen Protokollierungssystem bereitgestellt hat.

Firewall Manager ist ein flexibles Tool, mit dem Sie entsprechend den Anforderungen Ihres Unternehmens verschiedene Sicherheitsmanagementstrategien festlegen können. Bei jedem zentralisierten Sicherheitsmanagement müssen Sie einen Kompromiss zwischen dem Grad der zentralen Durchsetzung von Regeln zur Erhöhung der Sicherheit und dem Umgang mit Fehlalarmen, die durch zentral bereitgestellte allgemeine Regeln verursacht werden, eingehen.

Wenn Sie über hochgradig autonome Anwendungsteams verfügen und den Umgang mit Fehlalarmen vermeiden möchten, sollten Sie eine einzige zentrale WAF-Richtlinie für kritische Bedrohungen erstellen. Sie können beispielsweise WAF-Regeln definieren, die auf Ratenlimits mit hohen Schwellenwerten, kombiniert mit Reputationslisten für nachweislich bösartige IPs und Geoblocking-Regeln für Länder, denen ein Embargo auferlegt wurde, basieren. Sie können auch Shield Advanced aktivieren und die automatische DDoS-Abwehr auf Anwendungsebene aktivieren. Diese Regeln führen in der Regel nur zu sehr wenigen Fehlalarmen, schützen aber wirksam vor HTTP-Floods. Wenn kritische und schwerwiegende Zero-Day-Schwachstellen bekannt werden, können Sie mithilfe der bereitgestellten gemeinsamen WAF-Regelgruppe zudem zentral Abhilfemaßnahmen durchsetzen.

Am besten geben Sie Anwendungsteams ein internes Wiki an die Hand, das Anleitungen für das Hinzufügen benutzerdefinierter WAF-Regeln zur WebACL enthält, die für ihre Anwendung relevant ist. Das Wiki könnte auch Informationen zu Schutzmaßnahmen gegen SQLi- und XSS-Angriffe enthalten, wenn die jeweilige Anwendung für solche Angriffe anfällig ist.

Wenn Sie mit Ihren zentralen Sicherheitsmaßnahmen ein breiteres Spektrum von Bedrohungen abdecken möchten, sollten Sie Ihre zentralen allgemeinen Regelgruppen härten, den Anwendungsteams aber die Möglichkeit geben, Fehlalarme selbstständig zu verwalten. Um dieses WAF-Governance-Modell zu implementieren, platzieren Sie im Zählmodus Ihre allgemeinen Regeln in der ersten Regelgruppe der WAF-Richtlinie. Diese Regeln geben nur Labels aus, die Sie in der letzten Regelgruppe der WAF-Richtlinie verwenden können, um Anfragen zu blockieren, die diesen Labels entsprechen.

Wenn Ihre Anwendungsteams auf Fehlalarme stoßen, können sie anhand der von Ihren Regeln ausgegebenen Labels Ausschlussregeln erstellen. Um dies anhand eines Beispiels zu veranschaulichen, stellen Sie sich ein Szenario vor, in dem Amazon Managed Rules (AMR) zum Schutz vor SQLi im Zählmodus zur ersten Regelgruppe hinzugefügt wird. In der letzten Regelgruppe blockiert eine Regel Anfragen mit dem Label label_matched=”SQLi_BODY”, das vom oben genannten AMR gesendet wird. Wenn AMR für eine Anwendung mit einer bestimmten URL (url=”/form1”) einen Fehlalarm ausgibt, kann das Anwendungsteam eine Ausschlussregel in der WebACL erstellen, die diesen Fehlalarm unterbindet (z. B. IF url=”/form1” AND label_matched=”SQLi_BODY” then ALLOW). Die Aktion „Regel zulassen“ wirkt terminierend, was bedeutet, dass AWS WAF die Auswertung nachfolgender Blockierregeln einstellt.

Um Änderungen an dieser Richtlinie auszurollen, ohne bestehende Anwendungen zu beeinträchtigen, sollten Sie erwägen, ein Replikat dieser Richtlinie zu erstellen, das von Anwendungsteams in Staging-Umgebungen verwendet werden kann. Beide Richtlinien müssen einen sich gegenseitig ausschließenden Geltungsbereich haben. Beispielsweise gilt die Produktionsrichtlinie für alle CloudFront-Distributionen außer denen mit staging-Tag, und die Staging-Richtlinie für alle CloudFront-Distributionen mit dem staging-Tag. Die meisten Updates können Sie zunächst in der Staging-Richtlinie ausrollen und dann alle Anwendungsteams mithilfe eines SNS-Themas benachrichtigen. Sobald die Anwendungsteams über eine Änderung informiert wurden, testen sie die neue Richtlinienversion in ihrer Staging-Umgebung und behandeln bei Bedarf Fehlalarme. Das kann auch automatisiert werden. Nach einer vereinbarten Wartezeit gibt das zentrale Team die Änderung an die Produktionsrichtlinie weiter. Wichtige Updates, die keine Woche warten können, wie z. B. der Schutz vor Log4j CVE, können sofort angewendet werden. Die Anwendungsteams können etwaige Fehlalarme auch im Nachhinein mit Ausnahmen behandeln.

Wenn Sie die Anwendung einer konsistenten Sicherheitsgrundlinie erzwingen und gleichzeitig einige Anpassungen durch Kontoadministratoren zulassen möchten. In diesem Artikel werden Schritte zum Entwerfen und Implementieren einer zentral verwalteten Sicherheitsgrundrichtlinie beschrieben. Außerdem werden bewährte Methoden zum Testen und Bereitstellen der Richtlinie detailliert beschrieben.

Wenn Sie die gleichen Anforderungen wie zuvor haben, aber die kognitive Belastung der Anwendungsteams durch die Härtung der Anwendungssicherheit verringern möchten, sollten Sie einen Richtlinienkatalog für die verschiedenen in Ihrem Unternehmen vorhandenen Anwendungstypen erstellen. Sie können beispielsweise einen Katalog mit zwei Richtlinien anlegen:

• Erste Richtlinie: Zum Schutz von Wordpress-basierten Anwendungen empfohlen.
• Zweite Richtlinie: Zum Schutz von PHP-Anwendungen mit einer SQL-Datenbank empfohlen. Sie können zwei Versionen dieser Richtlinie mit unterschiedlichen Blockierungsempfindlichkeitsstufen erstellen. Auf diese Weise können Anwendungsteams diejenige Richtlinie auswählen, die ihren Sicherheitsanforderungen (Paranoia-Level) und ihrer Bereitschaft, mit Fehlalarmen umzugehen, entspricht.
  
  

Der Richtlinienumfang wird durch ein Tag definiert (z. B. wordpress für die erste Richtlinie und LAMP_HIGH/LAMP_LOW für die zweite Richtlinie). Anwendungsteams konsultieren den Richtlinienkatalog und wenden das Tag der gewünschten Richtlinie auf ihre Ressourcen an. Firewall Manager ordnet WAF WebACLs automatisch ihren Ressourcen zu.

Mit diesem Ansatz können Sie wie im vorherigen Abschnitt beschrieben auch Fehlalarme und Phasenänderungen behandeln.

Auf Anwendungsebene können Sie eigene Signale verwenden, um abnormales Verhalten der Anwendung zu definieren und zu erkennen. Sie können beispielsweise vorgeben, dass Benutzer in einer bestimmten Reihenfolge durch die Anwendung navigieren müssen, oder dass es aufgrund der registrierten Adresse unwahrscheinlich ist, dass ein Benutzer bestimmte Waren aus/nach bestimmten Ländern bestellt. Mit solchen Signalen und AWS WAF können Sie Ihr Antwortverhalten automatisieren, indem Sie beispielsweise Anfragen von IPs mit verdächtigem Verhalten auf Anwendungsebene blockieren oder mittels CAPTCHA absichern. Schauen Sie sich die Beispiele in dieser AWS-Lösung an, um sich mit dem Konzept der WAF-Automatisierung auf der Grundlage von Anwendungssignalen vertraut zu machen.

Einige komplexere Automatisierungen:

• Verarbeiten von Hochrisikoereignissen, die von Cognito während des Anmelde-/Anmeldevorgangs ausgelöst wurden.
• Verarbeiten von Hochrisikoereignissen, die von Fraud Detector identifiziert wurden. Fraud Detector nutzt Machine Learning (ML) und 20 Jahre Erfahrung von Amazon Web Services (AWS) und Amazon.com bei der Betrugserkennung, um potenzielle betrügerische Verhaltensmuster von Menschen und Bots in Echtzeit zu identifizieren. Fraud Detector ermöglicht die Erkennung von Betrug durch die Analyse des Benutzerverhaltens auf Anwendungsebene. Dabei werden Ihre eigenen historischen Betrugsdaten verwendet, um benutzerdefinierte ML-Modelle zur Betrugserkennung zu trainieren, zu testen und bereitzustellen, die auf Ihren Anwendungsfall zugeschnitten sind.

Wenn Sie es vorziehen, das WAF-Management vollständig von den Anwendungsteams an Ihr zentrales Sicherheitsteam auszulagern, erstellen Sie für jedes Anwendungsteam eine eigene Richtlinie, deren Geltungsbereich nur für deren AWS-Konten gilt. In diesem Fall müssen Sie Prozesse für die Ersteinrichtung und Kommunikationskanäle zwischen den Anwendungsteams und Ihrem zentralen Sicherheitsteam für Abläufe wie die Behandlung von Fehlalarmen definieren.

• Whitepaper: Governance-Beispiele aus dem Whitepaper über Richtlinien für die Implementierung von AWS WAF
• Vortrag von AWS re:Inforce 2024: Wie Twilio AWS-WAF-Richtlinien im großen Maßstab verwaltet
• AWS-WAF-Bereitstellungspartner suchen
• Blog: Betriebsmodelle für das Sicherheitsmanagement von Web-Apps in AWS