Reputation und verteilte Deployments

Instanzen, die dieselben Routen schützen, müssen Rate-Limit- und Authentifizierungsfehler-Zähler teilen.

npm install ioredis

import Redis from "ioredis";
import { RedisRateLimitStore, RedisSignalStore, createDhal } from "@rokadhq/dhal";

const redis = new Redis(process.env.REDIS_URL!);
const protection = createDhal({
  configPath: "dhal.json",
  rateLimitStore: new RedisRateLimitStore(redis, {
    prefix: "production:dhal:rate-limit"
  }),
  signalStore: new RedisSignalStore(redis, {
    prefix: "production:dhal:signals"
  })
});

{
  "rateLimit": { "enabled": true, "store": "redis" }
}

Verwenden Sie getrennte Präfixe je Anwendung und Umgebung. Schützen Sie Redis oder Valkey mit Authentifizierung, Netzwerkisolation, TLS und geeigneter Eviction-Policy.

Dhal v1 verweigert den Start im Enforcement-Modus, wenn Redis deklariert, aber kein verteilter rateLimitStore übergeben wurde. Damit wird eine globale Kontrolle nicht unbemerkt prozesslokal.

IP-Reputation

{
  "ip": {
    "reputation": {
      "enabled": true,
      "provider": "abuseipdb",
      "apiKeyEnv": "ABUSEIPDB_API_KEY",
      "minScore": 75,
      "cacheTtlSeconds": 86400,
      "maxAgeInDays": 30,
      "mode": "async",
      "timeoutMs": 750
    }
  }
}

Speichern Sie den Schlüssel in ABUSEIPDB_API_KEY. Nutzen Sie async für allgemeinen Traffic und blocking nur, wenn die Route Latenz und Provider-Ausfälle toleriert.

Eine enforcing Konfiguration mit blockierender Reputation startet ohne verfügbaren Provider nicht.

Alternativ kann eine eigene IpReputationProvider-Implementierung an createDhal() übergeben werden.

Checkliste

• Limits und Signale zwischen Instanzen teilen.
• Präfixe nach Anwendung und Umgebung trennen.
• Datastore-Latenz und Fehler überwachen.
• Ausfälle vor Enforcement testen.
• Secrets nicht in dhal.json speichern.