API Gateway Sicherheit: Authentifizierung, Threat Protection und Härtung

IRC-Mania Die Seite rund um Sicherheit und Programmierung

Internet, Sicherheit , Internet Relay Chat

Gesponsert

Das API Gateway ist der zentrale Eingang für gesamten API-Verkehr. Wenn es unsicher ist, sind alle dahinterliegenden Services unsicher. Wenn es sicher konfiguriert ist, schützt es die gesamte Infrastruktur — vom Auth-Check bis zum Bot-Schutz.

Was ist API Gateway Sicherheit?

API Gateway Sicherheit umfasst alle Maßnahmen, die das API Gateway selbst und die durch es geleiteten APIs vor Angriffen, Missbrauch und Fehlkonfiguration schützen. Da das Gateway der einzige Eingangspunkt für externen Traffic ist, ist es die ideale Stelle, um Sicherheitsrichtlinien zentral durchzusetzen.

Die Sicherheitsebene des API Gateway gliedert sich in vier Bereiche:

1. Zugriffskontrolle: Wer darf die API aufrufen? (Authentifizierung und Autorisierung)
2. Verkehrskontrolle: Wie viel darf ein Client abfragen? (Rate Limiting, Quotas, Throttling)
3. Bedrohungsschutz: Welche Angriffe werden blockiert? (WAF, Bot Protection, Schema Validation)
4. Härtung: Wie ist das Gateway selbst geschützt? (mTLS, IP-Whitelisting, Admin-API-Schutz, Audit Logs)

Wer nutzt API Gateway Sicherheit?

• Platform-Teams konfigurieren zentrale Sicherheitsrichtlinien für alle APIs
• Security-Engineers definieren Threat-Protection-Regeln und überwachen Angriffe
• API-Teams hinterlegen Auth-Requirements pro Endpunkt
• DevOps-Engineers härten die Gateway-Infrastruktur (TLS, Admin-Access, Secrets)

Warum ist das Thema in der Informatik und für Prüfungen wichtig?

API Gateway Sicherheit ist ein Kernthema in Cloud-Zertifizierungen (AWS Certified Security, Azure Security Engineer) und in der OWASP API Security Top 10. In IHK-Prüfungen wird häufig nach zentraler vs. dezentraler Authentifizierung gefragt. Die Architekturentscheidung, Sicherheit am Gateway zu zentralisieren, reduziert Komplexität und Fehlerquellen — wird aber zum Single Point of Failure, wenn nicht richtig abgesichert.

Kernkonzepte im Detail

1. Zentrale Authentifizierung am Gateway

Das Gateway übernimmt die Authentifizierung für alle APIs. Der Client sendet sein Token (JWT, API-Key, OAuth Access Token) an das Gateway. Das Gateway validiert das Token, extrahiert die Claims und leitet die Anfrage — mit angereicherten Headern — an das Backend weiter.

Der Flow:

1. Client sendet Authorization: Bearer <token>
2. Gateway validiert Token-Signatur und Ablauf
3. Gateway extrahiert Claims (User-ID, Rollen, Scopes)
4. Gateway leitet Anfrage weiter mit Headern wie X-User-Id, X-Roles
5. Backend vertraut diesen Headern (da sie vom Gateway stammen) und führt Autorisierungslogik aus

Wichtig: Das interne Netz zwischen Gateway und Backend muss vertrauenswürdig sein. Die Header dürfen nicht von extern manipulierbar sein. In Cloud-Setups wird das durch VPC-Isolation oder mTLS erreicht.

OAuth 2.0 Integration

Das Gateway kann als OAuth Resource Server fungieren. Es validiert Access Tokens gegen den Authorization Server (Introspection oder JWKS-Verifikation). Pro Endpunkt wird definiert, welche Scopes erforderlich sind:

• /api/orders — Scope orders:read für GET, orders:write für POST
• /api/admin/users — Scope admin:users

API-Key Management

Für B2B-Clients ohne OAuth-Infrastruktur verwaltet das Gateway API-Keys. Jeder Key ist einem Consumer zugeordnet und hat spezifische Berechtigungen. Das Gateway kann Keys rotieren, widerrufen und Quotas zuweisen.

2. Rate Limiting und Quotas

Rate Limiting am Gateway ist die erste Verteidigungslinie gegen Missbrauch. Es unterscheidet sich von Reverse-Proxy-Rate-Limiting durch seine Granularität:

• Pro Consumer: Jeder API-Key hat sein eigenes Limit
• Pro Endpunkt: Kritische Endpunkte haben niedrigere Limits
• Pro Verbund: Ein Consumer kann 100 req/min globally, aber nur 10 req/min auf /api/export
• Tiered: Free-Tier 100 req/h, Pro-Tier 1000 req/min, Enterprise unbegrenzt

Algorithmen:

• Fixed Window: Zählt pro Zeitfenster (z.B. 100 pro Minute). Einfach, aber Burst an Fenstergrenzen.
• Sliding Window: Gleitendes Zeitfenster, glattere Verteilung.
• Token Bucket: Bucket füllt sich mit Tokens pro Zeiteinheit, jede Anfrage verbraucht ein Token. Erlaubt Bursts bis Bucket leer.

Bei Überschreitung: 429 Too Many Requests mit Retry-After Header.

3. Web Application Firewall (WAF) am Gateway

Eine WAF am Gateway filtert bösartige Anfragen bevor sie das Backend erreichen:

• SQL Injection: Patterns wie ' OR 1=1 -- in Query-Parametern blockieren
• XSS: <script> Tags in Eingaben erkennen und blockieren
• Path Traversal: ../../etc/passwd in URL-Pfaden abblocken
• **Command Injection: ; rm -rf /` in Parametern erkennen
• Anomalie-Erkennung: Ungewöhnliche Request-Größen, Header-Kombinationen

WAF-Regeln können positiv (Whitelist: nur bekannte gute Anfragen) oder negativ (Blacklist: bekannte Angriffe blockieren) sein. Best Practice ist eine Kombination: Whitelist für kritische Endpunkte, Blacklist für allgemeinen Traffic.

4. Schema Validation

Das Gateway validiert jede Anfrage gegen ein OpenAPI-Schema:

• Sind alle Pflichtfelder vorhanden?
• Sind die Datentypen korrekt?
• Sind Strings in der erlaubten Länge?
• Sind Enum-Werte gültig?

Ungültige Anfragen werden mit 400 Bad Request abgewiesen, bevor sie das Backend erreichen. Das schützt das Backend vor Invalid-Input-Fehlern und reduziert die Last.

5. Bot Protection und Anomalie-Erkennung

• Bot Detection: User-Agent-Analyse, Headless-Browser-Erkennung, CAPTCHA-Challenge
• Behavioral Analysis: Ungewöhnliche Zugriffsmuster (z.B. 1000 logins in 1 Sekunde von einer IP)
• Geo-Blocking: Anfragen aus bestimmten Ländern blockieren
• IP-Reputation: Bekannte bösartige IPs blockieren (Threat Intelligence Feeds)

6. mTLS (Mutual TLS)

Bei mTLS authentifizieren sich nicht nur Clients am Server, sondern auch der Server am Client. Beide Seiten präsentieren Zertifikate. Das Gateway kann Client-Zertifikate verlangen und validieren — das ist sicherer als API-Keys, da Zertifikate schwerer zu stehlen sind und automatisch ablaufen.

Einsatz: B2B-APIs, interne Service-to-Service-Kommunikation, hochregulierte Branchen (Banken, Gesundheitswesen).

7. Audit Logging und Security Monitoring

Das Gateway protokolliert jede Anfrage:

• Wer (Consumer-ID, IP)
• Wann (Timestamp)
• Was (Endpunkt, Methode)
• Wie (Statuscode, Latenz)
• Warum abgelehnt (welche Sicherheitsregel hat getriggert)

Diese Logs speist Security Monitoring (SIEM), Alerting und Compliance-Audits.

Warum ist API Gateway Sicherheit in der Praxis wichtig?

Szenario 1: Credential Stuffing

Ein Angreifer probiert 10.000 gestohlene Passwort/E-Mail-Kombinationen gegen den Login-Endpunkt. Ohne Gateway-Rate-Limiting kommen alle 10.000 Requests durch. Mit Consumer-basiertem Rate Limiting (5 Login-Versuche pro Minute pro IP) werden 9.995 blockiert.

Szenario 2: API Scraping

Ein Konkurrent schreibt einen Bot, der die /api/products Endpunkte in hoher Frequenz abfragt, um das gesamte Katalog zu scrapen. Ohne Quotas und Bot Detection bekommt er alle Daten. Mit Token-Bucket-Limiting (100 req/min) und Bot Detection (Headless-Browser-Erkennung) wird der Bot blockiert.

Szenario 3: Internal Service Exposure

Ein Backend-Service hat versehentlich einen Admin-Endpunkt ohne Auth-Check implementiert. Ohne Gateway-Auth-Pflicht für alle Endpunkte ist der Endpunkt öffentlich erreichbar. Mit zentraler Gateway-Auth wird jede Anfrage authentifiziert, auch an den vergessenen Endpunkt.

Praxisbeispiel: Kong API Gateway Sicherheitskonfiguration

Dieses Beispiel zeigt eine vollständige Sicherheitskonfiguration für Kong: JWT-Auth, Rate Limiting pro Consumer, CORS, IP-Restriction, Request-Size-Limiting und Audit Logging. Es wurde gewählt, weil es die vier Sicherheitsbereiche (Zugriffskontrolle, Verkehrskontrolle, Bedrohungsschutz, Härtung) in einer deklarativen Konfiguration vereint.

# kong-security.yml
# Vollständige Sicherheitskonfiguration für ein Kong API Gateway

services:
  - name: payment-api
    url: http://payment-service.internal:3000
    routes:
      - name: payment-route
        paths:
          - /api/payments
        methods:
          - GET
          - POST
          - DELETE
        strip_path: false

  - name: user-api
    url: http://user-service.internal:3001
    routes:
      - name: user-route
        paths:
          - /api/users
        methods:
          - GET
          - POST
          - PUT
        strip_path: false

plugins:
  # --- 1. ZUGRIFFSKONTROLLE ---

  # JWT Authentifizierung für alle Routes
  - name: jwt
    config:
      secret_is_base64: false
      run_on_preflight: true
      maximum_expiration: 3600
      header_names:
        - Authorization

  # ACL für rollenbasierte Zugriffskontrolle
  - name: acl
    config:
      allow:
        - admin
        - user
      hide_groups_header: false

  # --- 2. VERKEHRSKONTROLLE ---

  # Rate Limiting: 100 req/min pro Consumer, 1000 req/h
  - name: rate-limiting
    config:
      minute: 100
      hour: 1000
      policy: redis
      redis_host: redis.internal
      redis_port: 6379
      limit_by: consumer
      fault_tolerant: true
      retry_after: true

  # Request Size Limiting: max 1MB Body
  - name: request-size-limiting
    config:
      allowed_size: 1000000
      size_unit: bytes

  # --- 3. BEDROHUNGSSCHUTZ ---

  # CORS: Nur erlaubte Origins
  - name: cors
    config:
      origins:
        - https://app.example.com
        - https://admin.example.com
      methods:
        - GET
        - POST
        - PUT
        - DELETE
      headers:
        - Authorization
        - Content-Type
        - X-Request-ID
      credentials: true
      max_age: 3600

  # IP Restriction: Nur bekannte IP-Ranges
  - name: ip-restriction
    config:
      allow:
        - 10.0.0.0/8
        - 192.168.0.0/16
        - 203.0.113.0/24

  # Request Transformer: Security Headers hinzufügen
  - name: response-transformer
    config:
      add:
        headers:
          - Strict-Transport-Security:max-age=31536000; includeSubDomains
          - X-Content-Type-Options:nosniff
          - X-Frame-Options:DENY
          - Cache-Control:no-store

  # --- 4. HÄRTUNG ---

  # Prometheus Metriken für Security Monitoring
  - name: prometheus
    config:
      per_consumer: true
      status_code_metrics: true
      latency_metrics: true

  # Audit Logging via HTTP Log Plugin
  - name: http-log
    config:
      http_endpoint: https://siem.internal/api/logs
      method: POST
      timeout: 5000
      keepalive: 30000
      retry_count: 3

consumers:
  - username: web-app
    acls:
      - group: user
    jwt_secrets:
      - key: web-app-key
        secret: ${WEB_APP_SECRET}

  - username: admin-panel
    acls:
      - group: admin
    jwt_secrets:
      - key: admin-key
        secret: ${ADMIN_SECRET}

// jwt-validation.js
// Beispiel: JWT-Validierung mit Scope-Check (Node.js)
// So würde ein Custom Plugin oder Backend die Validierung ergänzen

const jwt = require('jsonwebtoken');
const jwksClient = require('jwks-rsa');

// JWKS Client für Key-Rotation
const client = jwksClient({
  jwksUri: 'https://auth.example.com/.well-known/jwks.json',
  cache: true,
  cacheMaxEntries: 10,
  cacheMaxAge: 36000000
});

function getKey(header, callback) {
  client.getSigningKey(header.kid, (err, key) => {
    if (err) return callback(err);
    callback(null, key.getPublicKey());
  });
}

function validateToken(token, requiredScopes) {
  return new Promise((resolve, reject) => {
    jwt.verify(token, getKey, {
      algorithms: ['RS256'],
      audience: 'api.example.com',
      issuer: 'https://auth.example.com'
    }, (err, decoded) => {
      if (err) {
        reject({ code: 'INVALID_TOKEN', message: err.message });
        return;
      }

      // Scope-Prüfung: Token muss alle requiredScopes enthalten
      const tokenScopes = decoded.scope ? decoded.scope.split(' ') : [];
      const hasAllScopes = requiredScopes.every(s => tokenScopes.includes(s));

      if (!hasAllScopes) {
        reject({
          code: 'INSUFFICIENT_SCOPES',
          message: `Erforderliche Scopes: ${requiredScopes.join(', ')}`
        });
        return;
      }

      // Token ist gültig und hat alle Scopes
      resolve(decoded);
    });
  });
}

// Middleware für Express
function requireScopes(...scopes) {
  return async (req, res, next) => {
    const authHeader = req.headers.authorization;
    if (!authHeader || !authHeader.startsWith('Bearer ')) {
      return res.status(401).json({
        error: 'UNAUTHORIZED',
        message: 'Bearer Token erforderlich'
      });
    }

    try {
      const decoded = await validateToken(authHeader.split(' ')[1], scopes);
      req.user = decoded;
      next();
    } catch (err) {
      const status = err.code === 'INSUFFICIENT_SCOPES' ? 403 : 401;
      res.status(status).json({
        error: err.code,
        message: err.message
      });
    }
  };
}

Detaillierte Informationen

Gateway-Härtung: Schutz des Gateways selbst

Das Gateway selbst ist eine Angriffsfläche. Härtungsmaßnahmen:

• Admin-API schützen: Die Verwaltungs-API des Gateways (z.B. Kong Admin API auf Port 8001) darf nicht öffentlich erreichbar sein. Nur über VPN, VPC oder localhost.
• Secret Management: Secrets (JWT-Secrets, API-Keys, TLS-Keys) nicht in Klartext-Konfiguration, sondern in Vault, AWS Secrets Manager oder Kubernetes Secrets.
• TLS-Härtung: Nur TLS 1.2 und 1.3, keine alten Cipher Suites, HSTS Header.
• DDoS-Schutz: Cloudflare oder AWS Shield vor das Gateway schalten für Volumetric DDoS Protection.
• Konfiguration als Code: Gateway-Konfiguration versioniert in Git, Änderungen über CI/CD, kein manuelles Ändern in Produktion.

Zero Trust am API Gateway

Im Zero-Trust-Modell vertraut das Gateway niemandem. Jede Anfrage wird authentifiziert, auch interne. Jede Verbindung ist verschlüsselt (mTLS). Jede Anfrage wird geloggt. Das Gateway wird nicht zum vertrauenswürdigen inneren Netz gezählt — es ist Teil der Verteidigungslinie.

API Key Rotation

API-Keys müssen rotierbar sein. Best Practice:

• Keys haben ein Ablaufdatum
• Rotation alle 90 Tage oder bei Verdacht auf Kompromittierung
• Grace Period: Alter und neuer Key sind parallel gültig während der Migration
• Automatische Benachrichtigung des Consumers vor Ablauf

Security Headers am Gateway

Das Gateway setzt zentrale Security Headers für alle Antworten:

Monitoring und Alerting

Das Gateway sollte Alerts auslösen bei:

• Plötzlichem Anstieg der 401/403-Antworten (möglicher Angriff)
• Rate-Limit-Überschreitungen (möglicher Missbrauch)
• Ungewöhnlichem Traffic von einer IP oder einem Consumer
• Backend-Fehlerraten über Schwellwert
• Admin-API-Zugriffen

FAQ: API Gateway Sicherheit

Weiter im API Lernpfad

Der nächste Artikel behandelt API Gateway Patterns — Architekturmuster wie Backend for Frontend, API Composition, Protocol Translation und Aggregation, die am Gateway implementiert werden.

Quellen und weitere Ressourcen

1. https://docs.konghq.com/hub/
2. https://owasp.org/API-Security/
3. https://learn.microsoft.com/en-us/azure/api-management/api-management-howto-policies
4. https://docs.aws.amazon.com/apigateway/latest/developerguide/
5. https://www.cloudflare.com/learning/ddos/glossary/web-application-firewall-waf/

Buchempfehlungen zur API-Entwicklung

API-Entwicklung

Bücher über API-Design, REST, GraphQL, OpenAPI und API-Architektur

REST und HTTP: Entwicklung und Integration nach REST-Prinzipien von Stefan Tilkov

Bei Amazon ansehen

Affiliate-Link: Bei einem Kauf erhalten wir möglicherweise eine Provision.

API-Design: Praxishandbuch für Java- und Webservice-Entwickler

Bei Amazon ansehen

Affiliate-Link: Bei einem Kauf erhalten wir möglicherweise eine Provision.

Microservices: Grundlagen flexibler Softwarearchitekturen von Eberhard Wolff

Bei Amazon ansehen

Affiliate-Link: Bei einem Kauf erhalten wir möglicherweise eine Provision.

Premium VPS Hosting

Schnelle und sichere VPS Server

Gesponsert