So erstellen Sie NGWAF Sites für Ihr Unternehmen

Fastlys fünffach ausgezeichnete</u> NGWAF lässt sich in unterschiedlichsten Umgebungen und Unternehmen implementieren. Einer der Gründe, warum sich sicherheitsbewusste Unternehmen für die Fastly NGWAF entscheiden, ist der branchenführende Angriffsschutz ohne Serviceunterbrechung, den unsere Erkennungsmethode SmartParse</u> bietet. Aber genauso wichtig sind die flexiblen Bereitstellungsmuster, die es Entwicklern ermöglichen, auf einer einheitlichen Plattform zu arbeiten, die an die bestehende Organisationsstruktur ihres Unternehmens angepasst ist.

Die Möglichkeit, die NGWAF so einzusetzen, wie es für unsere Kunden am sinnvollsten ist, ist der Schlüssel zum Schutz unternehmenskritischer Anwendungen. Die NGWAF lässt sich in wenigen Schritten mit Kubernetes</u>, Serverless</u>, der Fastly Edge</u> und vielen weiteren Technologien</u> integrieren. Da bei Fastly für den Schutz Ihrer Anwendung keine spezifische Architektur notwendig ist, halten Sie bei der Entscheidung, welche Architektur für Ihr Unternehmen am besten geeignet ist, die Zügel selbst in der Hand.

In diesem Blogpost möchten wir Kunden einige der Optionen vorstellen, die ihnen bei der Einrichtung von NGWAF Sites</u> für ihr Unternehmen</u> zur Verfügung stehen. Sehen wir uns also drei Setups an, die bei der Verwaltung von Corp und Sites häufig auftauchen. 

Hinweis: Die Fastly NGWAF bietet hervorragenden Schutz für Ihre Anwendungen – auch ohne großen Tuning- und Konfigurationsaufwand. Bevor wir uns den drei Beispielen widmen, möchten wir aber auf eine oft übersehene Funktionsweise der WAF der nächsten Generation von Fastly hinweisen: Die Konfiguration, die unsere NGWAF mit Ihrer Anwendung verknüpft, basiert nicht auf dem HTTP-Host-Header. Sie können also viele verschiedene Anwendungen in einer einzigen Konfiguration für eine NGWAF Site zusammenfassen. Diese Flexibilität ermöglicht es Sicherheitsexperten, die Sicherheitslage ihrer gruppierten Anwendungen zu verwalten, den Aufwand für die Konfigurationsverwaltung zu reduzieren und letztendlich die Kosten für die Implementierung und Wartung Ihrer WAF zu senken. Sie können Ihren Security-Teams das Leben erleichtern, nämlich indem Sie ihnen die individuelle Verwaltung der Einstellungen von Dutzenden (oder sogar Hunderten) von WAF-Instanzen ersparen, wie es bei einer herkömmlichen WAF der Fall sein kann.

Nun aber zu den verschiedenen Bereitstellungsmustern aus der Praxis.

Muster 1 – Eine Site für das gesamte Unternehmen

Dieses Setup wird typischerweise als Einstiegspunkt unter neuen Fastly Kunden gewählt. So können NGWAF Nutzer ihre gesamten NGWAF Einstellungen an einem zentralen Ort verwalten. Zu Testzwecken besteht die Möglichkeit, eine Bedingung wie eine Büro-IP-Adresse oder einen Test-HTTP-Header zu einer NGWAF Request-Regel hinzuzufügen. Bei einer solchen Konfiguration wird die in der NGWAF Request-Regel festgelegte Aktion nur von dem Traffic ausgeführt, der den Testkriterien entspricht.

Mögliche Vorteile:

• Mühelose Massenkonfiguration, die den gesamten Traffic beeinflussen kann

• Transparenz über den gesamten Traffic dank der anpassbaren Site Dashboards

• Einheitliche Einstellungen für die Entwicklungs-, Staging- und Produktivumgebung zur Vermeidung von Versionsabweichungen

• Minimaler Personalaufwand für die Verwaltung

Mögliche Nachteile:

• Begrenzte Gesamtzahl an Rate-Limiting-Regeln auf Site-Ebene</u>

• Für granulare Transparenz müssen Signale zu den Anfragen hinzugefügt werden

Muster 2 – Eine Site pro Anwendung

Wir stellen häufig fest, dass Kunden dazu übergehen, Anwendungen nach Funktionen auf segmentierten NGWAF Sites zu bündeln. Bei diesem Muster wirkt sich eine Konfiguration, die auf eine einzelne Site angewendet wird, auf die gesamte Gruppe von Anwendungen aus, ohne dass NGWAF Sites mit anderen Anwendungsgruppen davon betroffen sind. Ein Vorteil davon ist, dass auf diese Weise für Anwendungen – unabhängig von ihrem Entwicklungsstadium – dieselbe Konfiguration beibehalten werden kann. So können Entwickler Probleme erkennen, bevor sie sich auf die Produktivumgebung auswirken. Kunden können auch eine eigene NGWAF Site für unternehmenskritische Anwendungen erstellen und interne Anwendungen, die allgemeineren WAF-Schutz benötigen, parallel dazu in einer separaten NGWAF Site zusammenfassen. Dabei werden die WAF-Einstellungen für unternehmenskritische Anwendungen nicht von den WAF-Einstellungen für die interne Anwendung beeinflusst und umgekehrt. 

Mögliche Vorteile:

• App-spezifische Konfigurationen, einschließlich einer größeren Gesamtzahl an Rate-Limiting-Regeln

• Geringeres Risiko für Versionsabweichungen zwischen Entwicklungs-, Staging- und Produktivumgebung

• Allgemeine Site-Statistiken über die Corp-Übersicht

• Entwickler können aktiv an der Erkennung von Angriffen in der NGWAF UI teilnehmen

• Kein Risiko für Rollenkonflikte zwischen den verschiedenen Anwendungseignern, da Rollen den einzelnen Sites zugewiesen werden

Mögliche Nachteile:

• Anwendungen mit ähnlichen Funktionen werden unabhängig voneinander verwaltet (außer bei Corp-Regeln)

• Für Transparenz über einzelne Anwendungen ist die Navigation zu den einzelnen Sites erforderlich

Muster 3 – Eine Site pro Stadium des Anwendungs-Lifecycle

Bei der agilen Entwicklung wird erwartet, dass es eine Art Entwicklungs-, Staging- und Produktivumgebung gibt und Bereitstellungen diese Phasen zu durchlaufen haben (vorausgesetzt, es werden keine Probleme festgestellt). Die Fastly NGWAF unterstützt auch diese Form des Setups, wobei den einzelnen Anwendungen in jeder Entwicklungsphase eine eigene NGWAF Site zugewiesen sein muss.

Mögliche Vorteile:

• Teams können Konfigurationen von der Entwicklungs- auf die Staging- und dann die Produktivumgebung übertragen

• Anwendungen mit ähnlichen Funktionen lassen sich gruppieren, damit dieselben Regeln nicht über mehrere Sites hinweg implementiert werden müssen

• Entwickler können aktiv an der Erkennung von Angriffen in der NGWAF UI teilnehmen

Mögliche Nachteile:

• Konfigurationsabweichungen zwischen den einzelnen Sites sind zu erwarten und Teil dieses Designs

• Viele verschiedene Anwendungen führen zu vielen verschiedenen NGWAF Sites, was die Transparenz innerhalb der Nutzeroberfläche erschwert

Beispiele

Einzelnes Entwicklerteam (Muster 1)

Für Kunden, die sich vor Angriffen schützen möchten, ohne viel Zeit in die Sicherheitslösungen zu investieren, ist eine einzige Site eine gute Option. Sicherheitseinstellungen und Transparenz sind auf derselben Site zusammengefasst, sodass Änderungen bei Bedarf nur auf einer einzigen Site vorgenommen werden müssen.

Einzelnes Security-Team. Entwickler kümmern sich nicht um die Anwendungssicherheit (Muster 2)

Wenn ein spezielles Security-Team für die Anwendungssicherheit zuständig ist, lassen sich NGWAF Sites in der Regel nach Funktionen gruppieren. Eine E-Commerce-Plattform, die Onlineshops für ihre Kunden anbietet, tut beispielsweise gut daran, alle Websites ihrer Kunden auf einer einzigen Site zusammenzufassen. Dies macht es besonders leicht, wenn bestimmte Konfigurationen auf die Gruppierung aller Kunden der E-Commerce-Plattform nach Funktionen angewendet werden müssen. Andere Anwendungen der E-Commerce-Plattform könnten auf ähnliche Weise mit anderen NGWAF Sites gruppiert werden. Das Security-Team könnte in diesem Zusammenhang sogar als Anbieter von Managed Security Services mit einer direkteren Schnittstelle zum Kunden fungieren.

Bei internen Anwendungen ist es wichtig, die Zusammenarbeit zwischen den Entwicklern und dem Security-Team im Detail abzustecken. Da die Entwicklungs-, Staging- und Produktivumgebung ja alle auf derselben NGWAF Site zusammengefasst sind, müssen Entwickler wissen, wie sie dem Security-Team Bedenken mitteilen können, sollte eine spezielle Anpassung erforderlich werden.

Großunternehmen mit vielen verschiedenen Anwendungsteams (Muster 3)

Wenn es mehrere Anwendungsteams gibt, die unabhängig voneinander arbeiten und für die Sicherheit ihrer einzelnen Anwendung verantwortlich sind, sollte jedes dieser Teams eine eigene NGWAF Site für jede Anwendung besitzen. So können die Teams, die sich am besten mit der Anwendung auskennen, die entsprechenden Sicherheitskonfigurationen vornehmen. Dieses Modell eignet sich besonders gut für Großunternehmen oder Unternehmen mit mehreren Standorten und Entwicklerteams. Agilere Entwicklerteams wählen höchstwahrscheinlich Option 3, während andere einheitliche Konfigurationen über all ihre Anwendungen hinweg bevorzugen und sich damit möglicherweise für Option 2 entscheiden.

Zusammenfassung

Die in diesem Blogpost beschriebenen Bereitstellungsoptionen sind Beispiele für tatsächliche Deployments aus der Praxis. Oft wird dabei ein hybrider Ansatz verfolgt, bei dem die verschiedenen Optionen so kombiniert werden, dass sie den Anforderungen des Kunden und der Struktur seines Unternehmens optimal gerecht werden. Im Allgemeinen sei darauf hingewiesen, dass es grundsätzlich leichter ist, mit etwas Einfachem zu beginnen und sich dann peu à peu zu steigern, als den umgekehrten Weg zu wählen. 

Fastly Kunden, die noch weniger Aufwand bei der Verwaltung ihrer Sicherheitseinstellungen von der NGWAF bis hin zur Fastly Edge wünschen, sei auch der Managed Security Service von Fastly</u> nahegelegt. 

Wir von Fastly sind immer bemüht, unsere Kunden bei der Bewältigung ihrer Sicherheitsprobleme effektiv zu unterstützen. Sprechen Sie mit uns und lassen Sie uns wissen, was wir tun können, um Ihnen den Alltag zu erleichtern</u>.