Procédure opérationnelle d’exposition du Gateway

​

Choisir le mode d’exposition

​

Inventaire préalable

• L’hôte du Gateway, l’utilisateur du système d’exploitation et le répertoire d’état (~/.openclaw par défaut).
• L’URL du Gateway et le mode de liaison (gateway.bind ; port 18789 par défaut).
• Le mode d’authentification, la source du jeton/mot de passe ou la source d’identité du proxy de confiance.
• Chaque canal activé et s’il accepte les messages privés, les groupes ou les Webhooks.
• Les agents accessibles aux expéditeurs non locaux.
• Le profil d’outils, le mode de bac à sable et la politique des outils avec privilèges élevés pour chaque agent accessible.
• Les identifiants externes auxquels ces agents ont accès.
• L’emplacement de sauvegarde de ~/.openclaw/openclaw.json et des identifiants.

​

Vérifications de référence

openclaw doctor
openclaw security audit
openclaw security audit --deep
openclaw health

openclaw gateway probe --url ws://127.0.0.1:18789 --token "$OPENCLAW_GATEWAY_TOKEN"

​

Configuration minimale sûre

{
  gateway: {
    bind: "loopback",
    auth: {
      mode: "token",
      token: "replace-with-a-long-random-token",
    },
  },
  session: {
    dmScope: "per-channel-peer",
  },
  agents: {
    defaults: {
      sandbox: { mode: "non-main" },
    },
  },
  tools: {
    profile: "messaging",
    exec: { security: "deny", ask: "always" },
    elevated: { enabled: false },
  },
}

​

Exposition des messages privés et des groupes

• Préférez dmPolicy: "pairing" ou une liste allowFrom stricte à dmPolicy: "open".
• Ne combinez pas les listes d’autorisation "*" avec un large accès aux outils.
• Exigez des mentions dans les groupes, sauf si le salon est strictement contrôlé.
• Définissez session.dmScope: "per-channel-peer" (ou "per-account-channel-peer" pour les canaux multicomptes) lorsque plusieurs personnes peuvent envoyer des messages privés au bot, afin que les sessions de messages privés ne partagent pas leur contexte.
• Acheminez les canaux partagés vers des agents disposant d’un minimum d’outils et d’aucun identifiant personnel.

​

Vérifications du proxy inverse

• Le proxy doit authentifier les utilisateurs avant de transmettre les requêtes au Gateway.
• Le pare-feu ou la politique réseau doit bloquer l’accès direct au port du Gateway.
• gateway.trustedProxies ne doit répertorier que les adresses IP sources du proxy.
• Le proxy doit supprimer ou remplacer les en-têtes d’identité et de transfert fournis par le client.
• Définissez gateway.auth.trustedProxy.allowUsers lorsque le proxy dessert plusieurs publics.
• Utilisez gateway.auth.trustedProxy.allowLoopback uniquement pour un proxy situé sur le même hôte, lorsque les processus locaux sont fiables et que le proxy contrôle les en-têtes d’identité.

​

Examen des outils et du bac à sable

• Vérifiez quelles sessions s’exécutent sur l’hôte et lesquelles s’exécutent dans le bac à sable.
• Refusez l’exécution sur l’hôte ou exigez une approbation.
• Laissez les outils avec privilèges élevés désactivés, sauf si un expéditeur précis et fiable en a besoin.
• Évitez les outils de navigateur, de canevas, de Node, de Cron, de Gateway et de création de sessions pour les surfaces de messagerie ouvertes ou semi-ouvertes.
• Limitez les montages liés au strict nécessaire ; évitez les chemins des identifiants, du répertoire personnel, du socket Docker et du système.
• Utilisez des Gateways, des utilisateurs du système d’exploitation ou des hôtes distincts pour les frontières de confiance sensiblement différentes.

​

Validation après modification

1. Relancez openclaw security audit --deep.
2. Vérifiez qu’une connexion autorisée réussit.
3. Vérifiez qu’un expéditeur ou une session de navigateur non autorisés sont refusés.
4. Vérifiez que les journaux masquent les secrets.
5. Vérifiez que le routage des messages privés/groupes n’atteint que l’agent prévu.
6. Vérifiez que les outils à fort impact demandent une approbation ou sont refusés.
7. Documentez les avertissements résiduels acceptés.

​

Plan de retour en arrière

{
  gateway: {
    bind: "loopback",
  },
  channels: {
    whatsapp: { dmPolicy: "disabled" },
    telegram: { dmPolicy: "disabled" },
    discord: { dmPolicy: "disabled" },
    slack: { dmPolicy: "disabled" },
  },
  tools: {
    exec: { security: "deny", ask: "always" },
    elevated: { enabled: false },
  },
}

1. Arrêtez la redirection publique, Tailscale Funnel ou les routes du proxy inverse.
2. Renouvelez les jetons/mots de passe du Gateway et les identifiants d’intégration concernés.
3. Supprimez "*" et les expéditeurs inattendus des listes d’autorisation.
4. Examinez les journaux d’audit récents, l’historique des exécutions, les appels d’outils et les modifications de configuration.
5. Relancez openclaw security audit --deep.
6. Réactivez l’accès avec le mode le plus restrictif qui répond aux besoins du flux de travail.

​

Liste de contrôle de l’examen

• Le Gateway reste limité à local loopback, sauf raison documentée.
• L’accès hors local loopback dispose d’une authentification et d’un pare-feu, sans route publique directe.
• Les déploiements avec proxy de confiance imposent des adresses IP de proxy strictes et des contrôles des en-têtes.
• Les messages privés utilisent l’appairage ou des listes d’autorisation, et non un accès ouvert par défaut.
• Les groupes exigent des mentions ou des listes d’autorisation explicites.
• Les canaux partagés n’ont pas accès aux identifiants personnels.
• Les sessions non principales s’exécutent en mode bac à sable.
• L’exécution sur l’hôte et les outils avec privilèges élevés sont refusés ou soumis à approbation.
• Les journaux masquent les secrets.
• Les problèmes critiques de l’audit sont corrigés.
• Les étapes de retour en arrière sont testées et documentées.