Sécuriser OpenClaw : auth, SSL, reverse proxy et vault en production

Un agent IA qui a accès à vos serveurs, vos emails et vos credentials, c'est une surface d'attaque réelle. Voici comment l'équipe BOTUM sécurise OpenClaw en production — de l'authentification à l'audit, en passant par le reverse proxy et la gestion des secrets.

Les deux premiers billets de cette série ont posé les fondations conceptuelles et techniques : ce qu'est OpenClaw, pourquoi le self-hosted s'impose, et comment réaliser une installation opérationnelle en moins de 30 minutes. Ce troisième volet aborde la dimension critique que trop d'équipes repoussent à plus tard : la sécurisation en production.

Un agent qui opère en autonomie sur votre infrastructure n'est pas un chatbot. Il peut lire des fichiers sensibles, exécuter des commandes, envoyer des emails. Cette puissance exige une posture de sécurité rigoureuse dès le premier déploiement — pas en phase 2.

1. Pourquoi la sécurité est critique ici

La plupart des solutions IA SaaS externalisent la sécurité : c'est le problème du fournisseur. Avec le self-hosted, c'est votre responsabilité. Et la surface d'attaque est bien réelle :

• L'agent a accès au système de fichiers — potentiellement à des clés SSH, des tokens, des fichiers de configuration
• Il peut exécuter des commandes shell si le skill correspondant est activé
• Il reçoit des instructions via la messagerie — un canal qu'il faut protéger contre l'injection de prompts malveillants
• Son workspace est souvent versionné dans Git — risque de fuite de secrets dans l'historique

Selon une étude IDC 2025, 43 % des incidents de sécurité liés à l'IA en entreprise impliquent une mauvaise configuration des accès plutôt qu'une faille dans le modèle lui-même. La surface d'attaque n'est pas le LLM — c'est l'infrastructure autour.

2. Authentification — qui peut parler à l'agent

Le premier périmètre de défense : contrôler qui peut envoyer des instructions à l'agent. OpenClaw supporte plusieurs mécanismes :

Authorized senders

OpenClaw filtre les messages entrants par identifiant d'expéditeur (user ID, numéro de téléphone ou email selon le canal). Seuls les expéditeurs explicitement autorisés déclenchent un traitement. Tout message d'une source non reconnue est ignoré silencieusement — aucune confirmation, aucune réponse qui révélerait l'existence du gateway.

Tokens d'API

Les intégrations externes (webhooks, scripts système) s'authentifient via des tokens dédiés. Les équipes BOTUM appliquent une règle simple : un token par intégration, rotation tous les 90 jours, révocation immédiate en cas de doute. Les tokens ne transitent jamais dans les variables d'environnement du workspace Git.

Whitelist de canaux

OpenClaw peut être configuré pour n'accepter des instructions que depuis des canaux spécifiques. En production, l'agent BOTUM n'écoute que le canal privé configuré — toute autre source est bloquée au niveau du gateway, avant même d'atteindre le runtime.

Règle pratique : traiter l'agent comme un compte de service système. Il a des accès étendus — ses permissions d'entrée doivent être aussi restrictives que possible.

3. HTTPS et SSL — ne jamais exposer en HTTP

Le gateway OpenClaw expose une interface réseau. En production, cette interface ne doit jamais être accessible en HTTP clair. Deux raisons : les credentials transitent par ce canal, et un attaquant sur le réseau local pourrait intercepter ou injecter des instructions.

Reverse proxy + Let's Encrypt

L'architecture recommandée par les équipes BOTUM : un reverse proxy (Nginx ou équivalent) devant le gateway, avec un certificat TLS géré automatiquement. Le gateway lui-même écoute en local sur un port non exposé — le reverse proxy fait la terminaison TLS et proxyfie vers localhost.

Configuration type Nginx :

server {
    listen 443 ssl;
    server_name agent.votre-domaine.com;

    ssl_certificate     /etc/letsencrypt/live/agent.votre-domaine.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/agent.votre-domaine.com/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:PORT_GATEWAY;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

Le renouvellement automatique du certificat (certbot --renew) s'intègre en cron système — zero coût opérationnel une fois en place.

4. Isolation réseau — ne pas exposer sur internet public

La règle la plus importante, et la plus souvent contournée pour "simplifier le déploiement" : l'agent ne doit pas être accessible depuis internet public.

L'interface gateway d'OpenClaw n'a pas besoin d'une IP publique. La communication entre l'agent et vos appareils (téléphone, laptop) passe par votre messagerie — pas par une connexion directe au gateway. Le gateway lui-même peut rester entièrement privé.

Réseau privé virtuel

Pour les équipes qui ont besoin d'accéder au dashboard ou à des endpoints de monitoring, un réseau privé virtuel permet d'accéder au gateway sans l'exposer publiquement. L'agent reste sur le réseau interne, accessible uniquement depuis des machines autorisées connectées au réseau privé.

Cette configuration réduit drastiquement la surface d'attaque : un attaquant externe ne peut pas atteindre le gateway, même s'il connaît l'IP du serveur. Les seuls vecteurs d'attaque restants sont les canaux de messagerie eux-mêmes — qui ont leurs propres mécanismes de sécurité.

Firewall

Sur le serveur hôte, les équipes BOTUM appliquent une règle simple avec UFW :

• Port 22 (SSH) : accès restreint aux IPs de gestion uniquement
• Port 443 (HTTPS reverse proxy) : accessible si besoin d'un endpoint public, sinon fermé
• Port du gateway OpenClaw : uniquement en loopback (127.0.0.1)
• Tout le reste : DROP par défaut

5. Gestion des secrets — le vault est obligatoire

C'est le point où la plupart des déploiements maison échouent. Les credentials (tokens API, mots de passe, clés SSH) se retrouvent dans des fichiers plats, dans l'historique Git, ou pire — directement dans des prompts système.

Gestionnaire de secrets dédié

Les équipes BOTUM utilisent un gestionnaire de secrets self-hosted. Toutes les credentials sont stockées dans ce vault chiffré, accessible uniquement via CLI avec un master password ou une clé de session à durée limitée. Le workspace Git ne contient aucune credential en clair — uniquement des références à des entrées vault.

Règles absolues

• Jamais de credentials dans le workspace Git — même dans un fichier .gitignore (l'historique garde tout)
• Jamais de secrets dans les fichiers de configuration d'agent (SOUL.md, MEMORY.md, AGENTS.md)
• Jamais de tokens dans les prompts système — un agent compromis pourrait les exfiltrer
• Variables d'environnement chiffrées — injectées au démarrage du processus, pas persistées sur disque

Pattern recommandé : les scripts qui ont besoin de credentials les récupèrent dynamiquement depuis le vault au moment de l'exécution. La session vault expirée = credential inaccessible = blast radius limité en cas de compromission.

6. Sandboxing — principe du moindre privilège

L'agent n'a pas besoin d'être root. Il n'a pas besoin d'accéder à tous les fichiers du système. Il n'a pas besoin de modifier des configurations système. Appliquer le principe du moindre privilège n'est pas du perfectionnisme — c'est ce qui transforme une compromission partielle en incident mineur plutôt qu'en catastrophe.

Utilisateur système dédié

OpenClaw tourne sous un compte utilisateur dédié (sans privilèges sudo) sur le serveur BOTUM. Ce compte a accès uniquement aux répertoires nécessaires : le workspace, les logs, et les répertoires de données des skills activés. Aucun accès aux répertoires système, aux fichiers d'autres utilisateurs, ou aux sockets de service.

Limiter les skills activés

Chaque skill activé élargit le périmètre d'action de l'agent. Le skill exec (exécution de commandes shell) est le plus puissant — et le plus dangereux. Les équipes BOTUM appliquent une règle : n'activer que les skills réellement utilisés, et documenter explicitement pourquoi chaque skill est présent.

Isolation Docker

Pour les déploiements qui nécessitent le skill exec, faire tourner OpenClaw dans un conteneur Docker avec des montages de volumes explicites est une couche de sécurité supplémentaire. Le conteneur ne voit que ce que vous lui montez — et si l'agent est compromis, le blast radius reste confiné au conteneur.

7. Audit et logs — traçabilité native Git

Un des avantages sous-estimés d'OpenClaw self-hosted : la traçabilité est native. Le workspace est un dépôt Git. Chaque action significative de l'agent est commitée — avec timestamp, auteur (l'agent), et message de commit.

Ce que surveiller

• Commits inhabituels : modifications de fichiers de configuration, ajout de clés ou tokens, création de scripts
• Activité en dehors des heures habituelles : une action à 3h du matin mérite investigation
• Tentatives d'accès refusées : dans les logs du gateway, les messages d'expéditeurs non autorisés
• Appels API anormaux : pics inhabituels de tokens consommés, requêtes vers des endpoints inconnus

Intégration monitoring

Les équipes BOTUM font tourner un cron qui analyse les commits Git des dernières 24h et génère un digest quotidien. Si une modification touche un fichier de configuration sensible (credentials, whitelist, SOUL.md), une alerte est générée automatiquement. Simple, efficace, zero dépendance externe.

8. Checklist sécurité production

Résumé actionnable avant tout déploiement OpenClaw en production :

• ✅ Authorized senders configurés et restreints aux identifiants connus
• ✅ Reverse proxy HTTPS devant le gateway (Nginx + Let's Encrypt)
• ✅ Gateway non exposé sur internet public — réseau privé ou loopback
• ✅ Firewall UFW configuré — seuls les ports nécessaires ouverts
• ✅ Vault de secrets en place — aucune credential en clair dans Git ou dans les fichiers d'agent
• ✅ Utilisateur système dédié — sans sudo, accès fichiers minimal
• ✅ Skills limités au strict nécessaire — exec uniquement si indispensable
• ✅ Logs Git — monitoring des commits, alertes sur fichiers sensibles
• ✅ Rotation des tokens — planifiée (90 jours max), révocation documentée
• ✅ Tests de pénétration basiques — tenter d'atteindre le gateway depuis l'extérieur, vérifier que c'est impossible

Conclusion

Sécuriser OpenClaw n'est pas une tâche de "phase 2". Les mécanismes décrits dans ce billet ne sont pas complexes — ils demandent une heure de configuration initiale et quelques règles à maintenir. Ce qui est complexe, c'est de revenir en arrière après un incident.

Le self-hosted donne un contrôle total. Ce contrôle s'accompagne d'une responsabilité totale. Les équipes BOTUM ont fait de cette checklist un prérequis non négociable pour tout déploiement agent en production — pas une option.

→ Billet 4 : Ne jamais exposer ses secrets dans le contexte IA — comment structurer SOUL.md, MEMORY.md et les fichiers d'agent sans y mettre ce qu'un LLM ne devrait jamais voir.