API Gateway Security: Schutzmaßnahmen für moderne API-Infrastruktur

In Microservices-Architekturen kommunizieren Dutzende Services über APIs miteinander. Ohne zentrale Sicherheitssteuerung muss jeder Service selbst Authentifizierung, Rate Limiting und Input-Validierung implementieren - inkonsistent, fehleranfällig und schwer zu auditieren. API Gateways lösen dieses Problem: sie sind der einzige Einstiegspunkt für alle API-Anfragen und durchsetzen Sicherheitsrichtlinien zentral.

API Gateway Sicherheitsarchitektur

In klassischen Microservices-Architekturen ohne Gateway kommuniziert der Client direkt mit jedem einzelnen Service - mit unterschiedlichen, inkonsistenten Auth-Verfahren oder gar keiner Authentifizierung. Jede Service-Schwachstelle ist direkt von außen erreichbar, Logging ist fragmentiert.

Mit einem API Gateway ändert sich das grundlegend: Der Client kommuniziert ausschließlich mit dem Gateway, das dann intern an die Services weiterleitet. Die internen Services sind nicht direkt erreichbar (privates Subnet), Security-Policy wird einmal definiert und überall durchgesetzt.

Ein API Gateway konsolidiert folgende Sicherheitsfunktionen:

Funktion	Beschreibung
Authentication	API Keys, OAuth 2.0 Bearer, mTLS, OIDC
Authorization	RBAC, JWT Claims-basiert, Policy-Engine (OPA)
Rate Limiting	Pro User, Pro IP, Pro API-Key, Global
Input Validation	Schema-Validierung, Payload-Inspektion
TLS Termination	HTTPS extern, HTTP/mTLS intern (service mesh)
Logging	Alle Requests zentral, für SIEM-Integration
WAF-Integration	SQL Injection, XSS, OWASP-Regeln
API Versioning	Routing basierend auf Version-Header oder URL

Authentifizierung im API Gateway

Methode 1: API Keys (einfach, begrenzt sicher)

API Keys (Authorization: X-API-Key: sk-prod-abc123xyz...) sind einfach zu implementieren, haben aber wesentliche Schwachstellen: keine Ablaufzeit (Revokation muss manuell erfolgen), kein User-Kontext (wer benutzt diesen Key?), und sie landen häufig in .env-Dateien, Git-Repos und Logs.

Empfohlen nur für Server-zu-Server-Kommunikation ohne User-Kontext. Sichere Implementierung erfordert mindestens 256-Bit-Entropie (32+ Bytes random), typisierte Prefixes (sk-prod-, sk-dev-, pk-), einen Key-Rotation-Mechanismus mit gleichzeitig gültigen Keys, sofortigen Revoke-Mechanismus, und die strikte Regel: keine Keys in URLs (Logs, Referrer-Header). HMAC-signierte Keys erlauben Server-seitige Validierung ohne DB-Lookup.

Methode 2: OAuth 2.0 + JWT (empfohlen für User-Auth)

Das Gateway validiert JWTs via den Public Key des Authorization Servers ohne Backend-Call - das spart Performance. Claims-Prüfung umfasst iss, aud, exp und nbf.

Beispiel Kong Gateway JWT-Plugin-Konfiguration:

plugins:
- name: jwt
  config:
    secret_is_base64: false
    claims_to_verify:
      - exp
      - nbf
    key_claim_name: iss  # Welcher Claim ist der Key-Identifier
    cookie_names: []  # Kein Cookie-Auth (nur Authorization Header)

JWT-Sicherheitsfallen:

• alg: none-Angriff - das Gateway muss den Algorithmus explizit konfigurieren
• RS256 statt HS256 verwenden (asymmetrisch: Public Key im Gateway, Private im Auth-Server)
• Kurzlebige Tokens: exp maximal 15 Minuten für API-Calls
• Refresh Token Rotation: jeder Refresh rotiert das Token

Methode 3: mTLS (höchste Sicherheit für B2B)

Der Client präsentiert ein Client-Zertifikat, der Server validiert gegen bekannte CAs. Keine Secrets in Transit, bidirektionale Authentifizierung. Ideal für Partner-APIs, Payment-Provider und Healthcare. Bei AWS API Gateway: Truststore als PEM in S3, Client-Certificate-CN als Identifier, CRL/OCSP-Checking für revoked Certificates.

Methode 4: OIDC / PKCE für Browser-Apps

SPAs mit Backend nutzen Authorization Code + PKCE. Kein Implicit Flow (Tokens im Fragment sind unsicher). Das Gateway kann OIDC-Tokens validieren und User-Info in den Downstream-Request injizieren.

Rate Limiting und DDoS-Schutz

Effektives Rate Limiting arbeitet auf mehreren Ebenen gleichzeitig:

IP-basiertes Rate Limiting (Anti-DDoS): Verhindert einfache Angriffe, hat aber das Bypass-Problem bei Botnets mit vielen IPs. Lösung: IP-Reputation kombiniert mit CDN-basiertem Rate Limiting.

API-Key-basiertes Rate Limiting (Fair Use): Pro API-Key z.B. 1.000 Requests/Minute. Die Response-Header X-RateLimit-Limit, X-RateLimit-Remaining und X-RateLimit-Reset machen das Limit transparent für Entwickler.

User-basiertes Rate Limiting (JWT Claims): Aus dem JWT werden user_id und subscription_tier extrahiert und daraus die Rate-Limit-Klasse bestimmt: Premium-User 10.000 req/min, Standard-User 1.000 req/min, kostenloser Plan 100 req/min.

Endpoint-spezifisches Rate Limiting: /auth/login maximal 5 Attempts/Minute pro IP (Brute Force!), /api/search 100 req/min (teuer), /api/health unlimitiert (Monitoring).

Beispiel Kong Gateway Rate Limiting:

plugins:
- name: rate-limiting
  config:
    minute: 1000
    hour: 10000
    policy: redis       # Redis-basiert (Cluster-aware!)
    fault_tolerant: true  # Bei Redis-Ausfall: Pass-Through statt Block
    hide_client_headers: false
    redis_host: redis.internal

Beim Algorithmus-Typ gilt: Token Bucket erlaubt kurze Bursts, Fixed Window ist streng aber einfach, Sliding Window ist fair aber komplexer. Empfohlen für reale APIs: Token Bucket kombiniert mit IP-Reputation.

Input Validation im Gateway

1. JSON Schema Validation

# AWS API Gateway Request Validation:
RequestValidator:
  Type: AWS::ApiGateway::RequestValidator
  Properties:
    ValidateRequestBody: true
    ValidateRequestParameters: true

# Schema für /api/user POST:
RequestModels:
  application/json: !Ref UserSchema
UserSchema:
  type: object
  required: [email, name]
  additionalProperties: false  # KEINE unbekannten Felder!
  properties:
    email:
      type: string
      format: email
      maxLength: 254
    name:
      type: string
      maxLength: 100
      pattern: "^[\\w\\s]+$"  # Nur alphanumerisch + Leerzeichen

Ungültige Requests werden mit 400 Bad Request abgelehnt bevor sie das Backend erreichen.

2. Content-Type-Erzwingung

Nur application/json für JSON-Endpoints erlauben, Content-Type-Sniffing verhindern, und ein Payload-Size-Limit von maximal 10 MB gegen ReDoS und Memory-Exhaustion setzen.

3. Parameter-Validierung

• URL-Parameter: nur alphanumerisch
• Path-Parameter: maximale Länge, Whitelist-Pattern
• Query-Parameter: keine kritischen Daten in URLs (landen in Logs)
• Header-Injection: CR/LF in Headers filtern

4. SQL/NoSQL Injection im Gateway

Das Gateway bietet Basis-Filterung als Defense-in-Depth. Das Backend muss jedoch trotzdem Prepared Statements nutzen - das Gateway ersetzt Backend-Validierung nicht, es ergänzt sie.

WAF-Integration:

• AWS: API Gateway + AWS WAF (Managed Rules)
• Azure: APIM + Azure Front Door + WAF
• Google: Apigee + Cloud Armor
• In allen Fällen: OWASP Core Rule Set (CRS) im WAF aktivieren

Logging und Monitoring

Was geloggt werden muss

• Request-Timestamp (UTC)
• Client-IP (via validiertem X-Forwarded-For)
• HTTP-Methode, URL-Path und Query-Params (kein Passwort in URL)
• Response-Status-Code
• Latenz in Millisekunden
• API-Key-Hash oder User-ID (kein Plaintext-Key)
• Authentication-Ergebnis (Success / Fail / MissingToken)
• Rate-Limit-Treffer

Was nicht geloggt werden darf

• Passwörter (auch in POST-Bodies)
• Plaintext-API-Keys oder Token
• Session-IDs
• Kreditkartendaten, IBAN
• DSGVO-sensitive PII ohne Anonymisierung

SIEM-Integration und Alerts

Kritische Alert-Regeln für ein API Gateway:

• 401/403-Rate pro API-Key über 100/Minute: Alert (Brute Force?)
• 500-Error-Rate über 5%: Alert (Angriff verursacht Backend-Fehler?)
• Neue Geo-Location für API-Key: Alert
• Payload-Size-Anomalie: plötzlich 10× größere Payloads
• Endpoint-Scanning-Pattern: viele 404-Fehler von einer IP

AWS CloudWatch → Microsoft Sentinel Integration:
EventBridge → Kinesis → Sentinel Custom Log
Enables: Korrelation mit Identity-Events, MDI-Alerts, etc.

Gateway-spezifische Konfigurationen

Kong Gateway (Self-Hosted)

Folgende Plugins sollten immer aktiviert sein:

• rate-limiting (Redis-Backend)
• jwt (mit explizitem Algorithm: RS256)
• request-size-limiting (max: 10 megabytes)
• ip-restriction (Blocklist für bekannte Malicious IPs)
• bot-detection (User-Agent Filtering)
• response-transformer (Security Headers hinzufügen)

Security-Response-Headers werden über das Gateway gesetzt:

Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
Content-Security-Policy: default-src 'none'  # Für reine APIs

AWS API Gateway

Checkliste für sicheres Setup:

• Custom Authorizer (Lambda) für JWT und Business-Logik
• Resource Policies: IP-Whitelist für interne APIs
• mTLS: Truststore-S3-Bucket konfiguriert
• WAF Association: Managed Rules und Custom Rules
• Access Logging via CloudWatch und CloudTrail Integration
• Throttling: Default 10.000 req/s, pro Stage konfiguriert
• API Keys nur für Usage-Plan-Tracking verwenden, nicht für Security - Auth via Authorizer

Azure API Management (APIM)

<policies>
  <inbound>
    <validate-jwt header-name="Authorization" failed-validation-httpcode="401">
      <openid-config url="https://login.microsoftonline.com/.../v2.0/.well-known/openid-configuration"/>
      <required-claims>
        <claim name="aud"><value>api://myapp</value></claim>
      </required-claims>
    </validate-jwt>
    <rate-limit calls="1000" renewal-period="60"/>
    <ip-filter action="allow">
      <address-range from="10.0.0.0" to="10.255.255.255"/>
    </ip-filter>
  </inbound>
</policies>

APIM mit Private Endpoint stellt sicher dass Backend-Services nicht öffentlich erreichbar sind. Managed Identity eliminiert Service-Principal-Secrets für Backend-Auth.

API Security Testing mit der Gateway-Perspektive

Typische Tests die bei einem API-Gateway-Security-Review durchgeführt werden:

• Bypass-Test: Direkt gegen Backend-Service (interne IP/Port erreichbar?)
• Auth-Bypass: Gateway-Header fälschen (X-User-ID: admin?)
• Rate-Limit-Bypass: Header X-Forwarded-For manipulieren
• JWT-Alg-None: alg: "none" in JWT-Header
• Routing-Anomalien: Path-Traversal in URL

---

API Gateways sind keine Sicherheitslösung aus der Box - sie sind Werkzeuge die korrekt konfiguriert werden müssen. Die häufigsten Fehler: JWT-Algorithmus nicht fixiert, Rate-Limiting nur auf IP-Ebene, keine Input-Validierung, und Backend-Services direkt erreichbar. AWARE7 prüft API-Gateway-Konfigurationen im Rahmen von Cloud-Security-Reviews und API-Penetrationstests.

API Penetrationstest anfragen | Cloud Security Services