Sécurité de Hermes Agent : risques et bonnes pratiques
Oct 15, 2026
/
By Faradilla A.
/
13 minutes de lecture
Hermes Agent intègre plusieurs mécanismes de sécurité qui contribuent à protéger les agents IA auto-hébergés contre les accès non autorisés, l’exécution de commandes dangereuses, la divulgation d’identifiants, les attaques par injection de prompt et d’autres risques de sécurité.
Voici les principaux mécanismes de sécurité de Hermes Agent :
- Autorisation des utilisateurs grâce aux listes d’autorisation et aux mécanismes d’appairage sur les plateformes de messagerie prises en charge.
- Procédures d’approbation des commandes de terminal à haut risque.
- Protections intégrées bloquant les commandes irréversibles et destructrices.
- Exécution des commandes dans des environnements isolés avec Docker et d’autres backends.
- Protection des clés API, des tokens et des autres identifiants sensibles.
- Filtrage des variables d’environnement et masquage des identifiants pour les serveurs MCP.
- Détection des injections de prompt dans les fichiers de contexte et les contenus externes.
- Isolation des sessions entre les utilisateurs et les conversations.
- Restrictions d’accès aux sites web et protection contre les attaques SSRF visant les réseaux privés.
- Mesures de protection de la chaîne d’approvisionnement pour les dépendances facultatives et les packages d’exécution.
Fonctionnement des mécanismes de sécurité de Hermes Agent
La sécurité de Hermes Agent repose sur plusieurs niveaux de protection indépendants qui déterminent qui peut accéder à l’agent, quelles actions il peut effectuer, quelles ressources lui sont accessibles et comment les contenus externes sont traités.
Les contrôles d’accès limitent l’utilisation de l’agent aux utilisateurs, plateformes et conversations autorisés. Les plateformes de messagerie et les passerelles peuvent appliquer des listes d’autorisation, des procédures d’appairage et des règles d’accès avant que les requêtes ne parviennent à l’agent.
Lorsque Hermes Agent effectue une action potentiellement dangereuse, une procédure d’approbation peut exiger une confirmation humaine avant l’exécution de la commande.
Pour certaines opérations particulièrement destructrices, Hermes applique des protections strictes qui empêchent leur exécution, quels que soient les paramètres d’approbation.
Vous pouvez également isoler l’exécution des commandes grâce à des backends de terminal utilisant des conteneurs ou d’autres environnements isolés.
L’exécution des outils dans des conteneurs Docker ou d’autres environnements isolés limite leur accès au système hôte et réduit les conséquences d’actions malveillantes, d’actions effectuées dans un environnement compromis ou d’actions involontaires.
Hermes protège également les identifiants sensibles en filtrant les variables d’environnement, en masquant les identifiants, en s’intégrant à des gestionnaires de secrets et en limitant la transmission des identifiants.
Les intégrations externes, comme les serveurs MCP, ne reçoivent qu’un ensemble limité de variables d’environnement, sauf si des accès supplémentaires sont explicitement configurés.
Pour réduire les risques d’injection de prompt, Hermes analyse les fichiers de contexte pris en charge et les contenus externes afin d’y détecter les instructions potentiellement dangereuses avant que ces contenus ne soient intégrés aux processus de l’agent.
Les listes de blocage de sites web et les protections contre les attaques SSRF contribuent à empêcher l’accès aux réseaux privés, aux points de terminaison des services de métadonnées cloud, aux services accessibles sur localhost et à d’autres ressources sensibles.
D’autres mécanismes complètent ces protections, notamment l’isolation des sessions entre les conversations, l’assainissement des données d’entrée, les mesures de protection de la chaîne d’approvisionnement pour les dépendances facultatives et les restrictions réseau configurables.
Ensemble, ces protections réduisent le risque qu’un prompt compromis, des identifiants divulgués, une intégration non sécurisée ou une erreur de configuration ne provoquent un incident de sécurité plus grave.
Bonnes pratiques pour sécuriser Hermes Agent
Pour protéger Hermes Agent, combinez des contrôles d’accès, des procédures d’approbation des commandes, des environnements d’exécution isolés, des mesures de protection des identifiants et des restrictions réseau.
Une fois Hermes Agent configuré, commencez par définir les listes d’autorisation et mettre en place l’appairage par message privé afin que seuls les utilisateurs approuvés puissent interagir avec l’agent.
Configurez ensuite les règles d’approbation des commandes dangereuses, choisissez un backend de terminal isolé comme Docker, limitez la transmission des identifiants et vérifiez les protections relatives aux contenus externes et aux accès réseau.
Pour sécuriser au mieux Hermes Agent, associez les paramètres définis dans ~/.hermes/config.yaml et ~/.hermes/.env (ou les fichiers équivalents dans un répertoire de profil) à des mesures de protection de l’infrastructure, comme les pare-feu, les VPN, les réseaux privés, l’isolation des conteneurs et la restriction des droits d’accès au système hôte.
Limitez l’accès à Hermes Agent
Hermes Agent limite les accès grâce à des listes d’autorisation et des mécanismes d’appairage. Avant de rendre l’agent accessible via Telegram, Discord, des passerelles ou d’autres intégrations, définissez précisément les utilisateurs autorisés à interagir avec lui.
Les paramètres de contrôle d’accès se configurent dans ~/.hermes/.env et, le cas échéant, dans ~/.hermes/config.yaml.
Pour un déploiement sur Telegram, ajoutez les noms d’utilisateur autorisés à TELEGRAM_ALLOWED_USERS dans ~/.hermes/.env.
Les déploiements sur Discord utilisent DISCORD_ALLOWED_USERS, tandis que les passerelles utilisent GATEWAY_ALLOWED_USERS. L’accès est refusé à tout utilisateur absent de ces listes d’autorisation.
Évitez d’autoriser un accès sans restriction avec des paramètres tels que GATEWAY_ALLOW_ALL_USERS=true. Cette option peut être utile pour les tests, mais en production, l’accès doit toujours être réservé aux utilisateurs explicitement autorisés.
Si vous utilisez l’appairage par message privé, examinez et approuvez les demandes d’appairage avant d’accorder l’accès à l’agent.
Hermes propose notamment les commandes hermes pairing approve et hermes pairing revoke pour gérer les utilisateurs autorisés et révoquer les autorisations d’accès devenues inutiles.
Les contrôles d’accès de Hermes sont plus efficaces lorsqu’ils sont associés à des protections réseau. Dans la mesure du possible, limitez l’accès aux réseaux de confiance, aux VPN, aux proxys inverses ou aux infrastructures privées, en particulier lorsque les points de terminaison d’une passerelle sont accessibles à plusieurs utilisateurs.
Vérifiez régulièrement les listes d’autorisation et les utilisateurs appairés. La suppression des utilisateurs inactifs, des intégrations inutilisées et des règles d’accès obsolètes réduit la surface d’attaque et contribue à prévenir les accès non autorisés.
Exigez une approbation pour les commandes dangereuses
Hermes Agent intègre un système d’approbation qui suspend l’exécution des commandes dangereuses jusqu’à ce qu’un utilisateur les examine et les approuve. Ce mécanisme contribue à prévenir les modifications accidentelles du système, l’exécution de commandes risquées et les actions déclenchées par des prompts malveillants.
Configurez le comportement du système d’approbation dans la section approvals du fichier ~/.hermes/config.yaml. Hermes prend en charge trois modes : manual, smart et off.
En production, privilégiez approvals.mode: manual ou approvals.mode: smart afin que les commandes dangereuses ne puissent pas être exécutées sans examen préalable ou évaluation des risques.
Évitez d’activer le mode YOLO sur les systèmes de production. Lancer Hermes avec hermes --yolo, utiliser la commande /yolo ou définir HERMES_YOLO_MODE=1 désactive les contrôles d’approbation et permet d’exécuter les commandes sans confirmation.
Hermes conserve toutefois une liste de blocage stricte pour les opérations catastrophiques, comme l’effacement du système de fichiers racine, les bombes fork (fork bombs) ou les commandes qui détruisent directement le contenu d’un disque.
Le système d’approbation permet d’examiner les commandes risquées qui peuvent néanmoins être légitimes. Une liste de blocage distincte empêche quant à elle toute exécution des opérations catastrophiques, indépendamment des paramètres d’approbation.
Examinez attentivement les demandes d’approbation avant de les valider. Soyez particulièrement vigilant face aux commandes inattendues, aux actions qui dépassent le cadre de la tâche initiale ou à celles qui ciblent des systèmes sensibles.
Exécutez les commandes dans un environnement isolé
Hermes Agent peut exécuter les commandes de terminal via des backends isolés plutôt que directement sur le système hôte. Pour les passerelles déployées en production, utilisez un backend comme docker, singularity, modal ou daytona afin de séparer l’environnement d’exécution des commandes de la machine sur laquelle fonctionne Hermes.
Lorsque vous utilisez un backend reposant sur des conteneurs ou un environnement sandbox dans le cloud, Hermes considère cet environnement isolé comme la principale barrière de sécurité et n’applique pas les contrôles d’approbation des commandes dangereuses à l’intérieur de la sandbox.
Définissez le backend du terminal dans ~/.hermes/config.yaml. Pour isoler l’exécution avec Docker, utilisez la configuration suivante :
terminal: backend: docker docker_image: "nikolaik/python-nodejs:python3.11-nodejs20" docker_forward_env: [] container_cpu: 1 container_memory: 5120 container_disk: 51200 container_persistent: true
Avec le backend de terminal Docker, Hermes applique des paramètres de sécurité renforcés, notamment la suppression des capacités Linux, la protection contre l’élévation des privilèges, la limitation du nombre de processus et des restrictions sur les systèmes de fichiers temporaires.
Les limites de ressources définies par container_cpu, container_memory et container_disk contribuent à empêcher les commandes qui s’exécutent de manière incontrôlée de monopoliser les ressources du système hôte.
Laissez docker_forward_env vide, sauf si une tâche nécessite explicitement une variable d’environnement particulière. Toute variable ajoutée à cette liste est injectée dans le conteneur et peut être lue par le code qui s’y exécute.
Choisissez le mode de persistance en fonction de vos besoins. Avec container_persistent: true, Hermes conserve le système de fichiers du conteneur d’une session à l’autre.
Avec container_persistent: false, l’espace de travail est temporaire et supprimé lors du nettoyage. Privilégiez le mode persistant lorsque les tâches nécessitent de conserver leur état entre les sessions, et le mode éphémère lorsque l’isolation est plus importante que la conservation de cet état.
Pour renforcer l’isolation réseau, exécutez les commandes sur un serveur distinct à l’aide du backend de terminal ssh. Stockez les paramètres de connexion SSH dans ~/.hermes/.env plutôt que de les inclure dans une configuration exportée.
Protégez les clés API et les autres identifiants
Par défaut, Hermes Agent stocke les clés API, les tokens et les autres secrets dans ~/.hermes/.env.
Hermes permet également de gérer les secrets avec un service externe comme Bitwarden Secrets Manager. Cette intégration permet de stocker les identifiants en dehors du système de fichiers local et de les récupérer au démarrage.
Restreignez l’accès au fichier ~/.hermes/.env et évitez de l’ajouter à un système de contrôle de version, de le partager entre plusieurs utilisateurs ou de l’exposer dans des sauvegardes ou des journaux.
Sous Linux et macOS, limitez les droits d’accès au fichier avec la commande suivante :
chmod 600 ~/.hermes/.env
Ainsi, seul le propriétaire du fichier peut lire ou modifier les identifiants qui y sont enregistrés.
Vérifiez attentivement les paramètres de transmission des variables d’environnement lorsque vous utilisez des backends d’exécution isolés. Hermes ne transmet que les variables répertoriées dans docker_forward_env ou dans les paramètres de transmission propres aux autres backends.
Limitez ces listes au strict nécessaire et n’incluez que les identifiants explicitement requis pour la tâche concernée.
Hermes filtre également les variables d’environnement avant de les rendre accessibles aux sessions de terminal, aux environnements d’exécution de code et aux serveurs MCP.
Les identifiants ne sont pas automatiquement transmis aux processus enfants, aux conteneurs ni aux services externes, sauf si leur transmission est explicitement autorisée par les paramètres ou la configuration.
Les fichiers contenant des identifiants nécessitent le même niveau de protection. Si vous utilisez terminal.credential_files pour transmettre des fichiers d’identifiants, ne rendez accessibles que ceux dont la tâche a besoin.
Lorsque vous utilisez des serveurs MCP, définissez explicitement les variables d’environnement nécessaires à chacun d’eux. Vérifiez régulièrement les identifiants stockés et supprimez les clés API, les tokens et les fichiers d’identifiants inutilisés.
Bloquez les attaques par injection de prompt
Hermes Agent intègre plusieurs protections contre les attaques par injection de prompt, notamment l’analyse des fichiers de contexte, l’assainissement des données d’entrée et l’analyse de sécurité facultative avec Tirith.
Ces mécanismes contribuent à repérer les instructions malveillantes dissimulées dans les fichiers de contexte, les documents, les contenus web et d’autres sources externes avant qu’elles n’influencent le comportement de l’agent.
Hermes analyse automatiquement les fichiers de contexte chargés pour y détecter des signes d’injection de prompt. Cette analyse permet de repérer les instructions visant à modifier le comportement du système, à contourner les protections, à accéder aux identifiants ou à pousser l’agent à effectuer des actions non autorisées.
Activez Tirith, un outil facultatif d’analyse de sécurité intégré à Hermes Agent, dans ~/.hermes/config.yaml afin de détecter les comportements potentiellement dangereux dans les commandes et les requêtes.
Hermes propose plusieurs paramètres liés à Tirith, notamment security.tirith_enabled et security.tirith_fail_open. Le paramètre tirith_fail_open détermine ce qui se passe lorsque Tirith ne parvient pas à terminer une analyse de sécurité.
Lorsque ce paramètre est activé, Hermes autorise l’exécution de la commande malgré l’échec de l’analyse. Lorsqu’il est désactivé, Hermes bloque l’exécution jusqu’à ce que l’analyse aboutisse ou que le problème soit résolu.
Examinez attentivement ce paramètre avant de déployer Hermes dans un environnement où il exécute des commandes ou interagit avec des systèmes de production.
Les protections contre les injections de prompt sont plus efficaces lorsqu’elles sont associées à des procédures d’approbation des commandes et à des environnements d’exécution isolés. Même si des instructions malveillantes parviennent jusqu’au modèle, ces mécanismes réduisent le risque qu’elles entraînent des actions dommageables.
Examinez régulièrement les commandes bloquées, les demandes d’approbation et les avertissements de sécurité afin de repérer les activités inhabituelles et les tentatives de contournement des règles.
Limitez l’accès aux contenus externes
Hermes Agent intègre des mécanismes qui limitent les sites web, les URL et les ressources externes auxquels il peut accéder, tout en contribuant à empêcher les connexions à des ressources réseau dangereuses ou sensibles.
Ces protections réduisent les risques liés aux attaques par injection de prompt, aux sites web malveillants et aux attaques par falsification de requête côté serveur (Server-Side Request Forgery, ou SSRF).
Configurez les restrictions d’accès aux sites web dans ~/.hermes/config.yaml à l’aide du paramètre security.website_blocklist.
Ajoutez les domaines auxquels l’agent ne doit jamais accéder, comme les portails d’administration internes, les systèmes sensibles de l’entreprise ou les sites web dont il n’a pas besoin pour accomplir ses tâches.
Par défaut, Hermes bloque l’accès aux réseaux privés, aux adresses de bouclage, aux adresses de lien local, aux services de métadonnées cloud et aux autres destinations non publiques.
Cette protection contribue à prévenir les attaques SSRF qui cherchent à exploiter l’agent pour accéder à des services internes qui ne sont pas accessibles publiquement.
Évitez de désactiver cette protection, sauf si un cas d’usage précis l’exige. Le paramètre security.allow_private_urls permet de contourner cette restriction et ne doit être activé qu’après avoir évalué ses conséquences sur la sécurité.
Vérifiez régulièrement les outils d’accès au web, les intégrations aux navigateurs et les services externes afin de vous assurer que l’agent n’a accès qu’aux ressources nécessaires à ses tâches.
Le nombre et le type d’intégrations nécessaires varient considérablement selon les cas d’usage de Hermes Agent. Les règles d’accès doivent donc être adaptées aux tâches que l’agent est censé accomplir.
Limiter les accès externes permet de réduire le nombre de sources par lesquelles des instructions malveillantes, des données sensibles ou des contenus inattendus peuvent pénétrer dans le système.
Activez la journalisation et la surveillance
Par défaut, Hermes enregistre les journaux dans ~/.hermes/logs/. Assurez-vous que les administrateurs peuvent accéder à ce répertoire et que celui-ci est intégré à vos procédures de surveillance opérationnelle.
Consultez régulièrement les journaux pour repérer d’éventuels problèmes de sécurité ou de fonctionnement, notamment :
- Tentatives d’accès non autorisé
- Échecs répétés de commandes
- Demandes d’approbation inattendues
- Actions bloquées
- Problèmes d’authentification
- Comportements inhabituels de l’agent
L’examen rapide de ces événements peut aider à identifier les erreurs de configuration et les problèmes de sécurité potentiels avant qu’ils ne prennent de l’ampleur.
Pour les déploiements en production, envisagez de transférer les journaux de Hermes vers la plateforme de journalisation centralisée de votre organisation.
La centralisation des journaux facilite la recherche d’événements passés, le rapprochement des activités entre différents systèmes et la conservation des enregistrements sur de plus longues périodes.
La journalisation est particulièrement efficace lorsqu’elle est associée aux autres mesures de sécurité présentées dans ce guide.
Consultez régulièrement les avis de sécurité et exécutez périodiquement hermes doctor pour identifier les problèmes de sécurité connus, les dépendances vulnérables et les erreurs de configuration susceptibles de nécessiter une intervention.
Principales menaces de sécurité liées à Hermes Agent
Les mesures de sécurité de Hermes Agent visent à protéger contre les risques couramment associés aux agents IA auto-hébergés et à l’exécution automatisée de commandes, notamment :
- Accès non autorisés – Des utilisateurs qui ne devraient pas avoir accès à l’agent peuvent lui soumettre des requêtes, exécuter des commandes ou interagir avec les outils et services connectés. Ce risque augmente lorsque les points de terminaison des passerelles sont accessibles publiquement ou que les listes d’autorisation sont mal configurées.
- Fuites de données entre les sessions – Si les mécanismes d’isolation ne sont pas correctement appliqués, des informations propres à un utilisateur, à une conversation ou à une session peuvent devenir accessibles à un autre utilisateur. Hermes utilise des mécanismes d’isolation des sessions pour empêcher qu’une conversation puisse accéder aux données ou à l’état d’une autre session.
- Exécution de commandes dangereuses – L’agent peut générer des commandes qui modifient des fichiers, installent des logiciels, suppriment des données ou changent la configuration du système. Sans procédures d’approbation ni contrôles d’exécution, ces actions peuvent affecter le système hôte ou l’infrastructure connectée.
- Attaques par injection de prompt – Des instructions dissimulées dans des documents, des sites web, des e-mails ou des contenus récupérés peuvent chercher à modifier le comportement attendu de l’agent. Une attaque réussie peut influencer l’utilisation des outils, l’exécution des commandes ou les décisions relatives à l’accès aux données.
- Divulgation d’identifiants – Les clés API, les tokens d’accès et les autres secrets peuvent être divulgués par l’intermédiaire des prompts, des journaux, des intégrations, du code généré ou d’environnements d’exécution mal configurés. Leur divulgation peut donner un accès direct à des services externes et à des données sensibles.
- Contenus externes malveillants – Les documents, sites web, fichiers de contexte, e-mails et autres contenus externes peuvent renfermer des instructions dissimulées, des commandes dangereuses ou des liens trompeurs destinés à manipuler le comportement de l’agent. Hermes intègre des mécanismes d’analyse des contenus, de restriction d’accès aux sites web et de validation de sécurité pour réduire ces risques.
Hermes Agent est-il plus sécurisé qu’OpenClaw ?
Hermes Agent et OpenClaw adoptent des approches différentes en matière de sécurité et répondent à des besoins opérationnels distincts. Le niveau de sécurité de chaque solution dépend notamment de son déploiement, de sa configuration et de son administration.
Hermes privilégie la sécurisation de l’exécution des agents auto-hébergés grâce aux contrôles d’accès des utilisateurs, à l’approbation des commandes, à l’isolation des environnements d’exécution, au filtrage des identifiants, aux protections contre les injections de prompt et aux restrictions d’accès aux ressources externes.
OpenClaw met davantage l’accent sur les audits de déploiement, les vérifications de sécurité des passerelles, la validation des configurations et les procédures de gestion des secrets.
Les principales différences entre les mécanismes de sécurité de Hermes Agent et d’OpenClaw sont les suivantes :
| Critère de sécurité | Hermes Agent | OpenClaw |
|---|---|---|
| Contrôle d’accès des utilisateurs | Listes d’autorisation et mécanismes d’appairage | Contrôles de sécurité au niveau des passerelles et audits de déploiement |
| Exécution des commandes | Procédures d’approbation intégrées et protections contre les commandes dangereuses | Règles d’exécution configurables avec contrôles d’audit de sécurité |
| Isolation de l’exécution | Backends Docker, Modal, Daytona, Singularity et SSH | Backends Docker, SSH et environnements d’exécution isolés |
| Protection des identifiants | Filtrage des identifiants pour les serveurs MCP et transmission contrôlée des variables d’environnement | Gestion des secrets avec SecretRef et audits des identifiants |
| Protection contre les injections de prompt | Analyse avec Tirith, analyse des fichiers de contexte et assainissement des données d’entrée | Approche principalement axée sur les contrôles de sécurité du déploiement et de l’exécution |
| Audit de sécurité | Journaux d’exécution et surveillance | Commandes d’audit de sécurité intégrées et vérifications de configuration |
| Protections réseau | Listes de blocage de sites web et protections contre les attaques SSRF | Renforcement de la sécurité des passerelles et contrôles de validation de sécurité |
Hermes Agent peut être particulièrement adapté aux utilisateurs individuels et aux petites équipes qui recherchent un agent auto-hébergé capable d’écrire du code, d’exécuter des commandes, d’interagir avec des API et d’automatiser des processus, tout en conservant un contrôle strict sur l’exécution, les identifiants et les accès externes.
OpenClaw peut être plus adapté aux déploiements partagés dans lesquels plusieurs utilisateurs accèdent au même environnement et où les administrateurs ont besoin d’audits de sécurité intégrés, de vérifications de configuration, de contrôles visant à renforcer la sécurité des passerelles et d’une supervision centralisée de l’activité des agents.
Comment déployer Hermes Agent de la manière la plus sûre ?
Pour sécuriser au mieux un déploiement de Hermes Agent, combinez une infrastructure isolée, des accès réseau restreints, des mises à jour régulières et des contrôles d’accès rigoureux.
Il existe trois principales façons d’exécuter Hermes Agent :
| Option de déploiement | Aspects à prendre en compte pour la sécurité |
|---|---|
| Ordinateur local | Facile à configurer, mais l’agent partage les ressources, les identifiants et les fichiers de votre ordinateur personnel. |
| VPS autogéré | Offre une meilleure isolation et davantage de contrôle, mais nécessite de configurer vous-même les pare-feu, les mises à jour, les sauvegardes, la surveillance et les contrôles d’accès. |
| Hermes Agent infogéré | Fournit un environnement dédié à Hermes sans que vous ayez à mettre en place ni à maintenir vous-même l’infrastructure sous-jacente. |
Pour les déploiements de longue durée, privilégiez un environnement dédié plutôt que votre ordinateur personnel. L’offre Hermes Agent infogéré prend en charge les mises à jour de l’infrastructure, les correctifs de sécurité, les sauvegardes et la maintenance des serveurs. Elle constitue donc une solution plus simple si vous ne souhaitez pas vous occuper vous-même de ces tâches. Un VPS autogéré vous donne quant à lui davantage de contrôle sur les règles de pare-feu, les accès réseau, l’isolation de l’exécution et les autres protections du serveur présentées dans ce guide.
Si Hermes exécute des commandes, écrit du code ou interagit avec des systèmes externes, utilisez un backend isolé comme Docker. L’isolation des conteneurs limite les conséquences des commandes inattendues et réduit le risque de modifications du système hôte.
Si vous choisissez un VPS autogéré, privilégiez les fonctionnalités qui facilitent la mise en place d’un environnement sécurisé.
Le déploiement de Hermes Agent en un clic proposé par Hostinger fournit un environnement préconfiguré avec des ressources VPS dédiées, un pare-feu intégré, des sauvegardes automatisées et des outils de gestion Docker.
Cette solution réduit les opérations de configuration manuelle nécessaires avant la mise en place des mécanismes de sécurité de Hermes et facilite la gestion d’un environnement dédié, distinct de votre ordinateur personnel.
Quel que soit l’environnement dans lequel vous exécutez Hermes, respectez les bonnes pratiques de déploiement suivantes :
- Exécutez Hermes avec un compte utilisateur autre que root.
- Restreignez les accès à l’aide de pare-feu, de VPN ou de réseaux privés.
- Protégez le fichier
~/.hermes/.envet excluez-le du contrôle de version. - Vérifiez régulièrement les listes d’autorisation et les paramètres d’approbation.
- Mettez à jour Hermes dès la publication de correctifs de sécurité.
- Utilisez des backends d’exécution isolés pour les tâches nécessitant l’exécution de nombreuses commandes.
Cet article est une version localisée de Hermes Agent security: Risks and best practices, initialement publié en anglais.
Tout le contenu des tutoriels de ce site est soumis aux normes éditoriales et aux valeurs rigoureuses de Hostinger.
Commentaires
0 responses