Réputation et déploiements distribués

Les instances protégeant les mêmes routes doivent partager les compteurs de limitation et d’échecs d’authentification.

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" }
}

Utilisez des préfixes distincts par application et environnement. Protégez Redis ou Valkey par authentification, isolation réseau, TLS si disponible et une politique d’éviction adaptée.

Dhal v1 refuse de démarrer en mode d’application si Redis est déclaré sans rateLimitStore distribué. Cela empêche la transformation silencieuse d’une limite globale en compteurs par processus.

Réputation IP

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

Placez la clé dans ABUSEIPDB_API_KEY. Préférez async pour le trafic général. Utilisez blocking uniquement si la route accepte la latence et les pannes du fournisseur.

Une configuration d’application avec réputation bloquante ne démarre pas sans fournisseur disponible.

Vous pouvez aussi passer une implémentation de IpReputationProvider à createDhal().

Vérifications

• Partagez les limites et signaux entre toutes les instances.
• Séparez les préfixes par application et environnement.
• Surveillez latence et erreurs du datastore.
• Testez les pannes avant le blocage.
• Gardez les secrets hors de dhal.json.