FortiWeb WAF ist die Web Application Firewall von Fortinet, die öffentlich erreichbare Webanwendungen und APIs gegen OWASP Top 10, Botnetze und Angriffe auf Anwendungsebene schützt. Über die klassische Prüfschicht aus Angriffssignaturen, IP-Reputation und Protokollvalidierung legt sie eine zweite, Machine-Learning-basierte Erkennungsschicht; sie läuft als Hardware, virtuelle Maschine, Container, in der Cloud und als SaaS und hilft dabei, die clientseitigen Anforderungen von PCI DSS 4.0 zu erfüllen.
Warum diese Schicht ein eigener Investitionsposten ist, zeigen aktuelle Breach-Daten. Laut dem Data Breach Investigations Report 2025 von Verizon erreichte die Ausnutzung von Schwachstellen als initialer Zugriffsvektor bei Sicherheitsverletzungen einen Anteil von 20 % und stieg gegenüber dem Vorbericht um 34 %; Edge-Geräte und VPNs machten dabei 22 % der Ziele von Exploit-Aktivitäten aus — ein Jahr zuvor lag dieser Anteil bei 3 % (Verizon DBIR, 2025). Auf europäischer Seite untersuchte der Bericht Threat Landscape 2025 der ENISA 4.875 Vorfälle und zeigte, dass die Ausnutzung von Schwachstellen 21,3 % der initialen Zugriffe ausmachte (ENISA, 2025). Wenn die Geschwindigkeit, mit der ein Angreifer eine neue Lücke scharf schaltet, regelmäßig die Geschwindigkeit übertrifft, mit der das Entwicklungsteam Patches liefert, wird die Prüfschicht vor der Anwendung zum einzig realistischen Puffer.
Welche Angriffe wehrt FortiWeb ab?
FortiWeb stoppt Anfragen, die unmittelbar auf die Anwendungslogik zielen: OWASP-Top-10-Kategorien, Cross-Site Scripting (XSS), SQL-Injection, Cross-Site Request Forgery (CSRF) und Session Hijacking stehen dabei an erster Stelle (Fortinet FortiWeb Datenblatt, 2025). Innerhalb derselben Policy-Engine finden sich Protokollvalidierung, HTTP-RFC-Konformität, Brute-Force-Schutz, Cookie-Signierung und -Verschlüsselung, syntaxbasierte SQLi-/XSS-Erkennung, HTTP-Header-Sicherheit, Threat Scoring und Gewichtung, Verhinderung von Datenabfluss, Schutz vor Website-Defacement sowie Schutz vor Man-in-the-Browser-Angriffen.
Das ersetzt den Schutz auf Netzwerkebene nicht, sondern ergänzt ihn. Während die FortiGate Next-Generation-Firewall die Sitzung auf Netzwerk- und Anwendungserkennungsebene bewertet, untersucht FortiWeb den Body, die Query-Parameter, die Cookies und die Header einer HTTP-/HTTPS-Anfrage im Kontext des eigenen Verhaltensmodells der geschützten Anwendung. Die Application Control einer NGFW sagt: „Dieser Verkehr geht an eine Webanwendung"; eine WAF kann sagen: „Diese Anfrage hat für dieses Feld dieser Anwendung nicht die erwartete Form." In Organisationen, die öffentlich erreichbare Zahlungs-, Antrags- oder Kundenportale betreiben, werden beide Schichten gemeinsam positioniert.
Was leistet virtuelles Patching bei nicht patchbaren Anwendungen?
Virtuelles Patching bedeutet, die Anfrage, die eine Lücke ausnutzt, auf der WAF zu blockieren, bis die Lücke im Code geschlossen ist. Warum das kritisch ist, erklären erneut die DBIR-Daten: Obwohl Organisationen erheblichen Aufwand betrieben, um Schwachstellen in Edge-Geräten zu schließen, konnten sie im Jahresverlauf nur rund 54 % davon vollständig beheben — mit einer Mediandauer von 32 Tagen (Verizon DBIR, 2025). Bei intern entwickelten oder vom Hersteller nicht mehr unterstützten Anwendungen dauert dies meist noch länger.
FortiWeb arbeitet mit führenden Schwachstellenscannern wie Acunetix, HP WebInspect, IBM AppScan, Qualys, ImmuniWeb und WhiteHat zusammen; die vom Scanner gefundenen Schwachstellen werden automatisch in Sicherheitsregeln überführt, und die Anwendung bleibt geschützt, bis das Entwicklungsteam den Code korrigiert (Fortinet FortiWeb Datenblatt, 2025). Wenn die Anwendung selbst überarbeitet werden muss, führen wir den Patching-Plan gemeinsam mit unserem Team für individuelle Web- und Backend-Entwicklung im selben Zeitplan.
Was verändert eine Machine-Learning-Schicht in einer WAF?
Die kurze Antwort: Sie erkennt Abweichungen, für die es keine Signatur gibt, und senkt die Last durch False Positives. Die erste Verteidigungsschicht von FortiWeb bilden die klassischen WAF-Engines. Verkehr, der diese Schicht passiert, wird mit dem laufend aktualisierten Verhaltensmodell der Anwendung verglichen; eine Support Vector Machine (SVM), die Vektormuster von FortiGuard Labs nutzt, teilt Anomalien in „harmlose Abweichung" und „Angriff" ein (Fortinet FortiWeb Datenblatt, 2025).
Die praktische Bedeutung dieser Unterscheidung: Sowohl der Anwender, der versehentlich zusätzliche Zeichen in ein Formularfeld eingibt, als auch der Angreifer, der eine Datenbankabfrage in dasselbe Feld schreibt, sind für das Modell eine „Anomalie"; blockiert wird jedoch nur der zweite Fall. Ansätze des automatischen Lernens, die jede Anomalie als Bedrohung werten, erzeugen eine große Zahl fehlerhafter Blockierungen. Das Ergebnis im Feld ist bekannt: Die Administration lockert die Regeln, die WAF wird faktisch zu einem Monitoring-Werkzeug, und die Fähigkeit zu blockieren bleibt Theorie.
An dieser Stelle ist ein ehrlicher Hinweis nötig. Die im Fortinet-Datenblatt genannte Formulierung „nahezu 100 % Genauigkeit" ist keine unabhängige Labormessung, sondern eine qualitative Herstelleraussage; sie sollte nicht wie eine Statistik behandelt werden. Der richtige Weg ist, die FortiWeb WAF zunächst im Lern- und Beobachtungsmodus mit Ihrem eigenen Produktivverkehr zu betreiben, das erzeugte Modell und die ausgelösten Regeln zu prüfen und anschließend schrittweise in den Blockiermodus zu wechseln. Als Sora Yazılım halten wir in Einführungsprojekten diese Reihenfolge ein und wechseln erst mit Freigabe des Teams, dem die Anwendung gehört, in den Blockiermodus.
Wie erkennt und schützt FortiWeb APIs?
Die API-Discovery von FortiWeb läuft automatisch per Machine Learning: Der Anwendungsverkehr wird fortlaufend ausgewertet, daraus entsteht ein Inventar der aktiven Endpunkte, und auf dieser Basis wird ein positives Sicherheitsmodell aufgebaut. Lädt die Organisation ihre eigene Schemadefinition hoch — unterstützte Schemaformate sind OpenAPI, XML und generisches JSON —, werden Aufrufe abgelehnt, die dem Schema nicht entsprechen; und wird die Schemavalidierung in die CI/CD-Pipeline eingebunden, aktualisiert sich die Richtlinie bei jeder API-Änderung von selbst (Fortinet FortiWeb Datenblatt, 2025).
Zusammen beantworten diese beiden Fähigkeiten die zwei schwierigsten Probleme der API-Sicherheit im Unternehmen. Das erste sind Shadow-APIs: nicht dokumentierte Endpunkte, die im Inventar nicht auftauchen, aber im Internet erreichbar sind. Die verkehrsbasierte Discovery macht sie sichtbar. Das zweite ist, dass die Sicherheitsrichtlinie mit dem Entwicklungstempo nicht Schritt hält; die Anbindung der Schemavalidierung an die Build-Pipeline macht die Richtlinie zu einem Teil des Release-Zyklus. FortiWeb bietet außerdem eine Konformitätsprüfung für XML- und JSON-Protokolle, Web-Service-Signaturen und eine API-Gateway-Funktion; auch die Backend-Dienste mobiler Anwendungen werden im selben Richtliniensatz geschützt.
Bei containerbasierten Microservice-Architekturen ist die Frage, wo der Schutzpunkt gesetzt wird, eine eigene Designentscheidung. Ob ein einzelner Prüfpunkt vor dem Ingress oder eine eigene Richtlinie je Servicegruppe nötig ist, bestimmen wir im Rahmen unserer DevOps- und Infrastrukturdienstleistung anhand Ihrer bestehenden Deployment-Pipeline.
Wie wird Bot-Verkehr getrennt und gesteuert?
FortiWeb kombiniert Machine Learning mit schwellwertbasierter Erkennung, Bot Deception und biometrischer Verhaltensanalyse und unterscheidet so menschliche Nutzer, gute Bots und schlechte Bots; bei Bedarf werden CAPTCHA und Real Browser Enforcement eingesetzt. Zu den adressierten Angriffsarten gehören automatisierter Bot-Verkehr, Web Scraping, Crawler-Bots, Data Harvesting und Credential Stuffing (Fortinet FortiWeb Datenblatt, 2025).
Die Erkennung guter Bots ist im E-Commerce und im Publishing wichtiger, als oft angenommen wird: Eine Regel, die Suchmaschinen-Crawler versehentlich blockiert, kann einen weit größeren Sichtbarkeitsverlust verursachen als der Sicherheitsgewinn wert ist. FortiWeb unterscheidet mit fortgeschrittenen Tracking-Techniken menschliche Anfragen, automatisierte Anfragen und wiederkehrende Angreifer im Zeitverlauf; über das FortiView-Bot-Dashboard und die OWASP-Top-10-Angriffsklassifizierung kann das Team berichten, welcher Verkehr aus welchem Grund blockiert wurde. Auf der Seite des Credential Stuffing gleicht das Abonnement FortiGuard Credential Stuffing Defense Anmeldeversuche mit der FortiGuard-Liste kompromittierter Zugangsdaten ab; dabei lassen sich unterschiedliche Aktionen von der Warnung bis zur Blockierung definieren.
Auch die Grenze des Leistungsumfangs muss klar gezogen werden. FortiWeb bietet DoS-Schutz auf Anwendungsebene und eine zustandsbehaftete Layer-4-Netzwerk-Firewall-Funktion; für volumetrische DDoS-Angriffe, die die Leitung füllen, ist jedoch upstream ein Carrier- oder Scrubbing-Dienst erforderlich. Im ENISA-Bericht 2025 traten DDoS-Angriffe als häufigster Bedrohungstyp EU-weit hervor und betrafen mit einem Anteil von 81,4 % mehrere Sektoren gleichzeitig (ENISA, 2025); deshalb sind Schutz auf Anwendungsebene und volumetrischer Schutz getrennt zu planen.
Welche Anforderungen der PCI DSS 4.0 erfüllt FortiWeb?
Unmittelbar drei Anforderungen: 6.4.2, 6.4.3 und 11.6.1. PCI DSS v4.0 schreibt in 6.4.2 vor, vor öffentlich erreichbaren Webanwendungen eine automatisierte technische Lösung vorzuhalten, die webbasierte Angriffe fortlaufend erkennt und blockiert, und definiert diese Anforderung bis zum 31. März 2025 als „Best Practice" und danach als verpflichtend (PCI SSC, PCI DSS v4.0, 2022). Dasselbe Datum gilt auch für 6.4.3. Die folgende Tabelle fasst zusammen, was den Anforderungen auf FortiWeb-Seite entspricht.
| Anforderung PCI DSS v4.0 | Kern der Anforderung | Entsprechung auf FortiWeb-Seite |
|---|
| 6.4.2 | Automatisierte technische Lösung vor öffentlich erreichbaren Webanwendungen, die webbasierte Angriffe fortlaufend erkennt und blockiert, aktuell betrieben wird, Audit-Logs erzeugt und den Angriff blockiert oder eine unverzüglich geprüfte Warnung auslöst | Als Reverse Proxy oder inline positionierte WAF-Richtlinie; FortiGuard-Signatur- und Modellaktualisierungen; Audit-Logs über FortiView und Syslog-Übertragung; Aktionen Blockieren oder Warnen |
| 6.4.3 | Autorisierung, Integritätssicherung und begründete Inventarisierung sämtlicher Skripte der Zahlungsseite, die im Browser des Verbrauchers geladen und ausgeführt werden | Inventarisierung, Autorisierung und Echtzeit-Integritätsprüfung von Erst- und Drittanbieterskripten mit Client-Side Protection |
| 11.6.1 | Erkennung unbefugter Änderungen/Manipulationen an Inhalten der Zahlungsseite und an HTTP-Headern sowie Alarmierung des Personals | Änderungs- und Manipulationswarnungen der Client-Side Protection, Überwachung der Skriptaktivität und Compliance-Reporting |
| Protokollierung und Reporting | Regelmäßige, aufbewahrbare Protokoll- und Berichtserstellung für die Compliance-Prüfung | Zentrale Protokollsammlung und vorgefertigte PCI-DSS-Berichtsvorlagen auf FortiAnalyzer |
FortiWeb Client-Side Protection erkennt und blockiert fortlaufend schädliches und nicht autorisiertes JavaScript, das im Browser des Anwenders ausgeführt wird; damit schützt es die Zahlungsseite gegen Angriffe wie Formjacking, Magecart und Online-Kartenskimming. Fortinet positioniert diese Funktion ausdrücklich passend zu den Anforderungen 6.4.3 und 11.6.1 der PCI DSS 4.0 (Fortinet FortiWeb Datenblatt, 2025). Es sei ergänzt, dass Compliance nicht mit einem einzelnen Produkt abgeschlossen ist: Die FortiWeb WAF erfüllt die technische Kontrolle, nach der ein Auditor fragt; Scoping, Richtliniendokumentation und Penetrationstests sind eigene Posten.
Welches FortiWeb-Modell und welche Bereitstellungsform sind zu wählen?
Die Auswahl wird von zwei Variablen bestimmt: dem Volumen des zu prüfenden HTTPS-Verkehrs und der bevorzugten Bereitstellung. Die FortiWeb-WAF-Hardwarefamilie skaliert von 100 Mbps bis 70 Gbps, und bei allen Modellen liegt die Latenz unter 5 Millisekunden; ab Modell 600F erfolgt die SSL/TLS-Verarbeitung in Hardware (Fortinet FortiWeb Datenblatt, 2025). In Szenarien, in denen verschlüsselter Verkehr terminiert wird, ist diese Unterscheidung das entscheidendste technische Kriterium der Auswahl.
| Modell | Durchsatz (max.) | Schnittstellen | SSL/TLS-Verarbeitung | Formfaktor | ADOM |
|---|
| FortiWeb 100F | 100 Mbps | 4x GE RJ45 | Software | Desktop, lüfterlos | — |
| FortiWeb 400F | 500 Mbps | 4x GE RJ45, 4x SFP GE | Software | 1U | 32 |
| FortiWeb 600F | 1 Gbps | 4x GE RJ45 (2 Bypass), 4x SFP GE | Hardware | 1U | 32 |
| FortiWeb 1000F | 2,5 Gbps | 8x GE RJ45 Bypass, 4x SFP GE, 2x 10GE SFP+ | Hardware | 2U | 64 |
| FortiWeb 2000F | 5 Gbps | 4x GE RJ45 (4 Bypass), 4x SFP GE, 4x 10GE SFP+ | Hardware | 2U | 64 |
| FortiWeb 3000F | 10 Gbps | 8x GE RJ45 Bypass, 10x 10GE SFP+ (2 Bypass) | Hardware | 2U | 64 |
| FortiWeb 4000F | 70 Gbps | 2x 40GE QSFP Bypass, 10x 10GE SFP+ (2 Bypass), 8x GE RJ45 Bypass | Hardware | 2U | 64 |
Alle Werte in der Tabelle sind von Fortinet unter idealen Laborbedingungen gemessene „Maximalwerte" und variieren je nach Systemkonfiguration; die tatsächliche Kapazität hängt von den aktivierten Sicherheitsprofilen und der Last der SSL-Terminierung ab. Bei allen Hardwaremodellen ist die Anwendungslizenz unbegrenzt, Active/Passive- und Active/Active-Clustering werden unterstützt und ein Trusted Platform Module (TPM) ist vorhanden. Ein Punkt sei unterstrichen: Fortinet veröffentlicht für FortiWeb keine aufgeschlüsselten Metriken wie in den FortiGate-Datenblättern (etwa IPS-Durchsatz oder Durchsatz der SSL-Prüfung); in der Tabelle steht nur eine einzige Zeile für den Gesamtdurchsatz. Der Vergleich zwischen den Modellen erfolgt daher über einen einzigen Wert, und die Kapazitätsplanung stützt sich auf eine erwartete, nicht auf eine gemessene Obergrenze. In der Praxis ist folgendes Vorgehen richtig: Ermitteln Sie aus den Logs Ihres bestehenden Load Balancers oder Webservers die tatsächlichen Requests/Sekunde und die Zahl gleichzeitiger Verbindungen, entscheiden Sie, ob die SSL-Terminierung auf FortiWeb oder auf den dahinterliegenden Servern erfolgt, und wählen Sie das Modell anhand dieser beiden Eingangsgrößen. Von zwei Installationen derselben Durchsatzklasse kann eine allein wegen der Last des TLS-Schlüsselaustauschs und der gewählten Cipher Suites deutlich mehr Ressourcen verbrauchen als die andere; dieser Unterschied ist in der Datenblatt-Tabelle nicht sichtbar.
Was bieten die Optionen als virtuelle Maschine, Container und SaaS?
Die FortiWeb-VM-Versionen tragen denselben Funktionsumfang wie die Hardwaremodelle und werden in fünf Stufen von 1 vCPU bis 16 vCPU lizenziert; die HTTP-Durchsatzwerte betragen 25 Mbps, 100 Mbps, 500 Mbps, 3 Gbps und 6 Gbps. Der empfohlene Arbeitsspeicher reicht von 8 GB bis 64 GB, die Zahl der Verwaltungsdomänen liegt je nach zugewiesenem Speicher zwischen 4 und 64. Unterstützte Hypervisoren sind VMware, Microsoft Hyper-V, Citrix XenServer, Open-Source-Xen, VirtualBox, KVM und Docker; in der Public Cloud ist die Nutzung auf AWS, Azure, Google Cloud und Oracle Cloud als virtuelle Maschine oder als WAF-as-a-Service möglich (Fortinet FortiWeb Datenblatt, 2025).
Die Container-Versionen (FWB-VMC01–VMC08) laufen mit dem Docker-Container-Manager; die kleinste Stufe beginnt bei 25 Mbps HTTP-Durchsatz. Hier gibt es eine Inkonsistenz innerhalb des Datenblatts, und es ist redlicher, sie zu benennen als zu verschweigen: Für die oberste Stufe VMC08 nennt die Leistungstabelle 3 Gbps, der Abschnitt mit den Bestellinformationen dagegen 2 Gbps. In einem Design, in dem die Obergrenze ausschlaggebend ist, lassen wir diesen Wert vor der Bestellung schriftlich über Fortinet bestätigen. Für die Container-Versionen werden mindestens 4 GB, empfohlen 8 GB Arbeitsspeicher sowie zwischen 30 GB und 500 GB Speicher aufgeführt; eine Unterstützung für Hochverfügbarkeit ist dagegen nicht gelistet, weshalb die Verfügbarkeitsarchitektur auf der Orchestrierungsebene geplant werden muss. Für die zentrale Verwaltung mehrerer FortiWeb-Geräte wird die Lizenz FortiWeb Central Manager mit den Optionen für 10 Geräte oder unbegrenzt viele Geräte angeboten.
Wie wird FortiWeb im Netzwerk positioniert?
Es gibt fünf Positionierungsoptionen: Reverse Proxy, Inline Transparent, True Transparent Proxy, Offline Sniffing und WCCP (Fortinet FortiWeb Datenblatt, 2025). Reverse Proxy ist der häufigste Modus; da FortiWeb die Verbindung terminiert, lassen sich in diesem Modus Application-Delivery-Funktionen wie URL-Rewriting, Content Routing, Layer-7-Server-Load-Balancing, HTTPS-/SSL-Offloading, HTTP-Komprimierung und Caching nutzen. Die Modi Inline Transparent und True Transparent Proxy ermöglichen eine Prüfung inline, ohne den IP-Adressplan zu ändern; sie werden in Umgebungen bevorzugt, in denen Eingriffe in die bestehende Architektur teuer sind.
Der Modus Offline Sniffing überwacht den Verkehr lediglich über einen Mirror-Port (SPAN) und blockiert nicht. Er ist ein nützlicher erster Schritt, um vor der Inbetriebnahme zu bewerten, die vorhandene Angriffsfläche zu messen und das Machine-Learning-Modell mit Produktivverkehr reifen zu lassen. Der WCCP-Modus wiederum sorgt dafür, dass der Verkehr von einem vorgelagerten Gerät (typischerweise einer FortiGate) an FortiWeb weitergeleitet wird.
Wie fügt sich FortiWeb in die bestehende Infrastruktur und die Compliance-Anforderungen in der Türkei ein?
FortiWeb ist nicht als allein stehende Box, sondern als Komponente der Fortinet Security Fabric positioniert. Die Integration mit FortiGate und FortiSandbox ermöglicht die Tiefenanalyse verdächtiger Datei-Uploads und den Austausch von Informationen über kompromittierte interne Ressourcen; Informationen zu unter Quarantäne gestellten IP-Adressen werden zwischen den Geräten übertragen. Nach Angaben von Fortinet umfasst das Ökosystem der Security Fabric mehr als 500 Drittanbieterlösungen (Fortinet, 2026), und FortiGuard Labs verarbeitet und analysiert täglich mehr als 100 Milliarden Ereignisse (Fortinet, 2026). Für die FortiGuard-Antiviren-Engine, die FortiWeb beim Scannen von Datei-Uploads einsetzt, gibt Fortinet an, dass wöchentlich 1,8 Millionen neue Signaturen erzeugt werden (Fortinet FortiSASE Datenblatt, 2026).
Auf FortiGuard-Seite stehen für FortiWeb fünf separate Abonnementoptionen zur Verfügung: IP-Reputation-Service, FortiWeb Security Service (Signaturen für die Anwendungsebene, Machine-Learning-Bedrohungsmodelle, Listen schädlicher Robots, Muster verdächtiger URLs und Aktualisierungen des Web-Schwachstellenscanners), Credential Stuffing Defense, Cloud Sandbox und Antivirus. Welche Abonnements erforderlich sind, hängt von der Art der geschützten Anwendung ab; bei einer Anwendung mit Zahlungsfunktion werden Credential-Stuffing-Abwehr und das Scannen von Datei-Uploads meist gemeinsam eingeplant. Auch der Phishing-Druck über E-Mail gehört in dasselbe Bild; auf dieser Ebene übernimmt FortiMail und auf Endpoint-Seite FortiEDR eine ergänzende Rolle. Wenn der Zugriff von Remote-Teams auf interne Anwendungen identitätsbasiert gesteuert werden soll, wird dies gemeinsam mit FortiSASE bewertet.
Worauf ist im Hinblick auf KVKK und den lokalen Betrieb zu achten?
Der Leitfaden zur Sicherheit personenbezogener Daten der KVKK (türkisches Datenschutzgesetz; technische und administrative Maßnahmen, Januar 2018) definiert Firewall und Gateway als „erste Verteidigungslinie" gegen unbefugte Zugriffe aus dem Internet und führt in der Übersichtstabelle der technischen Maßnahmen neben der Netzwerksicherheit auch Anwendungssicherheit, Angriffserkennungs- und -verhinderungssysteme, Protokollaufzeichnungen sowie Penetrationstests als eigene Posten auf (KVKK, 2018). Fehlt vor einer öffentlich erreichbaren Anwendung, die personenbezogene Daten verarbeitet, eine Prüfschicht, bleibt der Posten Anwendungssicherheit in dieser Tabelle faktisch leer.
Auf der Betriebsseite stehen drei Themen im Vordergrund. Erstens die Frage, wo die Protokolle aufbewahrt werden: Werden FortiWeb-Ereignisse an einen FortiAnalyzer im Inland übertragen, bleiben sowohl die Aufbewahrungsdauer als auch der Speicherort der Daten unter Kontrolle. Zweitens der Zeitplan für den Wechsel in den Blockiermodus; in einer produktiven Anwendung kann eine fehlerhafte Blockierung schneller Geschäftsverluste verursachen als ein Angriff. Drittens die Anbindung der WAF-Richtlinie an den Release-Zyklus der Anwendung — wird ein neuer Endpunkt veröffentlicht, muss auch die Richtlinie aktualisiert werden. Als autorisierter Fortinet-Channel-Partner übernehmen wir Lizenzierung, Installation, Migration von einer bestehenden WAF und Managed Services mit Support auf Türkisch; für weitere Fortinet-Komponenten sehen Sie sich unsere Fortinet-Lösungsfamilie und für das gesamte Portfolio unsere Lösungsseite an.
Um das richtige FortiWeb-WAF-Modell zu wählen, müssen zunächst die Anzahl der zu schützenden Anwendungen, das Volumen des zu prüfenden HTTPS-Verkehrs, der PCI-DSS-Geltungsbereich und die bevorzugte Bereitstellung (Hardware, virtuelle Maschine, Container oder SaaS) geklärt werden. Sobald Sie uns Ihr Anwendungsinventar und Ihr Verkehrsprofil mitteilen, erarbeiten wir gemeinsam das passende Modell, das Abonnementpaket und den Einführungsplan und erstellen ein Angebot, das Hardware-, Lizenz- und Managed-Service-Positionen umfasst. Für ein Bewertungsgespräch und ein Angebot erreichen Sie uns über unsere Kontaktseite.