Sicherheitsprofile

Synit WAF startet bewusst kontrolliert: erst Sichtbarkeit, dann Durchsetzung. Profile können pro Tenant, Domain oder Wildcard kombiniert und verschärft werden.

Wiederverwendbare Schutzprofile

Base Protection

Für erste Rollouts und allgemeine Websites.

Geeignet für:

• geringe False-Positive-Toleranz
• Beobachtungsphase
• Marketingseiten
• Portale und Standard-Websysteme

Advanced Protection

Für öffentliche APIs, login-starke Anwendungen und höhere Angriffsfläche.

Geeignet für:

• Scanner- und Bot-Muster
• strengere Anfrageprüfung
• API-Endpunkte
• Kundenportale

Optimized Protection

Für getunte Produktion mit klaren Ausnahmen.

Geeignet für:

• Adminbereiche
• compliance-sensitive Systeme
• eigene Geschäftsregeln
• höhere Paranoia-Level nach Log-Prüfung

CRS und Paranoia-Level

Synit WAF kann Coraza- und OWASP-CRS-kompatible Regeln nutzen. Das Paranoia-Level steuert, wie streng die Regelprüfung arbeitet.

Level	Einsatz
1	sinnvoller Start für die meisten Websites und Portale
2	mehr Abdeckung für APIs und exponierte Anwendungen
3	stärkerer Schutz für sensible Systeme nach Tuning
4	nur für sehr kontrollierte Umgebungen mit hoher False-Positive-Toleranz

Für produktive Rollouts gilt: Level 1 zuerst, danach anhand echter Logs erhöhen. Höhere Level können gültige Nutzer-Workflows treffen.

Einsatzfeld: Website- und CMS-Schutz

Ziel: öffentliche Websites und CMS-Systeme vor automatisierten Scans und häufigen Angriffsmustern schützen.

tenants:
  "www.example.test":
    upstreams:
      - url: "http://website:8080"
    security:
      waf_enabled: true
      audit_mode: true
      include_rule_sets:
        - "base-protection"
        - "cms-protection"
      custom_rules: |
        SecRule REQUEST_URI "@contains wp-config.php" "id:200002,phase:1,deny,status:403,log,msg:'Blocked access to wp-config.php'"
        SecRule REQUEST_URI "@contains xmlrpc.php" "id:200003,phase:1,deny,status:403,log,msg:'Blocked access to xmlrpc.php'"

Empfehlung: zuerst Audit Mode für Redaktions- und Admin-Workflows, danach Blocking für echte Scanner-Muster.

Einsatzfeld: API-Härtung

Ziel: Missbrauch reduzieren und Backend-Dienste schützen.

tenants:
  "api.example.test":
    upstreams:
      - url: "http://api-service:8080"
    security:
      waf_enabled: true
      audit_mode: true
      jwt_validation:
        enabled: true
        jwks_endpoint: "https://auth.example.test/.well-known/jwks.json"
      rate_limit:
        requests_per_minute: 1000
        burst: 200

Typische Kontrollen:

• JWT/JWKS-Prüfung
• Rate Limits
• Methoden- und Content-Type-Regeln
• strengere Profile für öffentliche APIs

Beispiel für ein API-Profil:

waf_rule_sets:
  "api-strict": |
    SecRule REQUEST_METHOD "!@rx ^(GET|POST|PUT|DELETE|PATCH|OPTIONS)$" "id:210001,phase:1,deny,status:405,log,msg:'Method not allowed'"
    SecRule REQUEST_METHOD "@rx ^(POST|PUT)$" "id:210002,phase:1,chain,deny,status:415,log,msg:'JSON Content-Type required'"
      SecRule REQUEST_HEADERS:Content-Type "!@contains application/json" "t:none"
    SecRule REQUEST_URI "@rx \\.(env|git|bak|sql)$" "id:210003,phase:1,deny,status:403,log,msg:'Blocked sensitive file access'"

Nutzen Sie dieses Profil nur für APIs, die tatsächlich JSON für schreibende Requests erwarten.

Einsatzfeld: Adminbereiche

Ziel: sensible Oberflächen zusätzlich schützen.

tenants:
  "admin.example.test":
    upstreams:
      - url: "http://admin-service:8080"
    header_transform:
      inject_request:
        X-Synit-Tenant: "{{TENANT}}"
        X-Client-IP: "{{CLIENT_IP}}"
    security:
      waf_enabled: true
      audit_mode: true
      geoip_enabled: true
      blocked_countries: ["RU", "CN"]
      basic_auth:
        - user: "admin"
          password: "<bcrypt-password-hash>"

Hinweis: GeoIP und Basic Auth nur mit klarer fachlicher Freigabe einsetzen.

Einsatzfeld: Multi-Tenant-SaaS

Ziel: viele Kundendomains mit einheitlicher Governance schützen.

tenants:
  "customer-42.example.test":
    upstreams:
      - url: "http://customer-42-service:8080"
    security:
      waf_enabled: true
      audit_mode: true
      include_rule_sets:
        - "base-protection"

Bei vielen Tenants kann eine modulare Tenant-Datei pro Kunde sinnvoll sein. Dadurch bleiben Onboarding, Rollback und Profilwechsel übersichtlich.

Einsatzfeld: GraphQL

Ziel: Schema-Offenlegung, zu tiefe Queries und große Batch-Anfragen begrenzen.

tenants:
  "graphql.example.test":
    upstreams:
      - url: "http://graphql-service:8080"
    security:
      waf_enabled: true
      audit_mode: true
      graphql:
        enabled: true
        block_introspection: true
        max_query_depth: 8
        max_batched_queries: 10

Empfehlung: Grenzwerte anhand echter Client-Nutzung festlegen.

Einsatzfeld: LLM- und AI-Endpunkte

Ziel: Prompt-Injection- und Prompt-Extraction-Muster vor internen AI-Services sichtbar machen oder blockieren.

tenants:
  "ai.example.test":
    upstreams:
      - url: "http://llm-gateway:8080"
    security:
      waf_enabled: true
      audit_mode: true
      include_rule_sets:
        - "base-protection"
        - "llm-protection"
      llm_protection:
        enabled: true
        mode: "rules"
        action: "audit"
        inspect_paths:
          - "/v1/chat"
        inspect_json_fields:
          - "messages[].content"

Starten Sie mit action: "audit". Blocking sollte erst nach Prüfung echter Prompts, erwarteter Systemantworten und fachlicher Freigabe erfolgen.

Einsatzfeld: Compliance-orientierter Betrieb

Ziel: Traffic-Verarbeitung, Logs und Change Control an interne Anforderungen anpassen.

Empfehlungen:

• Self-Hosted prüfen, wenn Traffic intern bleiben muss.
• Log-Aufbewahrung und Zugriff dokumentieren.
• Regeländerungen versionieren.
• Blocking-Freigaben klar benennen.
• Ausnahmen eng und begründet halten.

Regeln für sicheres Tuning

• Mit weniger Regeln und mehr Sichtbarkeit starten.
• Neue Regeln im Audit Mode testen.
• Blocking nur mit Log-Evidenz aktivieren.
• Ausnahmen klein und nachvollziehbar halten.
• Schutzprofile pro Tenant statt global erzwingen.
• Hohe Blockraten immer gegen echte Nutzerwirkung prüfen.
• Release-Tags und Regelversionen dokumentieren, damit Rollback und Vergleich möglich bleiben.