Aller au contenu principal

Exigences de permissions pour l’exécution de clmBot

Lors de l’exécution du renouvellement automatique des certificats, clmBot doit pouvoir lire et écrire les fichiers de certificats cibles, puis recharger ou redémarrer les services middleware correspondants après la mise à jour. Cet article décrit la configuration minimale des permissions recommandée pour les différents scénarios middleware.

Remarque

Les commandes reload / restart des middleware sont définies dans le champ servers[].after_script de config.yaml et peuvent être ajustées par l’utilisateur selon l’environnement réel. clmBot ne nécessite pas de s’exécuter durablement avec un compte à hauts privilèges tel que root ou Administrator.

Principe du moindre privilège​

Il est recommandé d’utiliser un compte système dédié (par exemple clmbot) pour exécuter clmBot, en respectant les principes suivants :

  • N’accorder à ce compte que les permissions nécessaires pour lire la configuration de clmBot, les répertoires de journaux et le point d’installation du certificat cible.
  • N’accorder des droits d’écriture qu’aux fichiers de certificats gérés par clmBot, aux fichiers de clés privées et aux répertoires qui les contiennent.
  • N’autoriser que l’exécution des commandes middleware reload / restart confirmées, sans accorder NOPASSWD: ALL ni les privilèges root complets.
  • before_script, after_script doivent faire l’objet d’un audit manuel, et les permissions requises par les scripts doivent être accordées une par une.

Pratiques non recommandées :

  • Faites fonctionner clmBot à long terme sous l’identité root ou Administrator.
  • Ouvrez entièrement à clmBot le répertoire de configuration du middleware, le répertoire des certificats ou les droits de contrôle des services système.
  • Accordez des droits d’exécution illimités à bash, powershell.exe, systemctl.

Exigences de droits pour chaque middleware​

nginx​

clmBot a besoin des droits suivants :

  1. Droits de lecture et d’écriture sur le répertoire des certificats : disposer des droits de lecture et d’écriture sur le répertoire contenant le fichier de certificat cible (.crt), le fichier de chaîne CA (facultatif) et le fichier de clé privée (.key), afin de pouvoir écrire le nouveau certificat et créer la sauvegarde .bak.
  2. Exécutez la commande reload : after_script génère par défaut le script suivant, utilisé pour recharger nginx après le renouvellement du certificat :
nginx -t && nginx -s reload

Recommandations de moindre privilège :

  • N’exposer que le répertoire cible des certificats, sans accorder de droits de lecture-écriture à l’ensemble de /etc/nginx.
  • Accorder précisément via sudoers les autorisations pour nginx -t et nginx -s reload, sans octroyer un shell root complet.

Apache HTTP Server​

clmBot nécessite les autorisations suivantes :

  1. Droits de lecture-écriture sur le répertoire des certificats : disposer de droits de lecture-écriture sur le répertoire où se trouvent SSLCertificateFile, SSLCertificateChainFile et SSLCertificateKeyFile.
  2. Exécuter la commande de redémarrage du service : after_script génère par défaut l’un des scripts suivants (selon la distribution) :
systemctl restart httpd.service
systemctl restart apache2.service

Suggestions de moindre privilège :

  • N’exposez que le répertoire du certificat cible, sans octroyer l’accès à l’ensemble du répertoire de configuration Apache.
  • Via sudoers, n’accordez la permission restart qu’au nom de service Apache réellement utilisé par le système actuel.

Tomcat​

clmBot nécessite les autorisations suivantes :

  1. Autorisation de lecture/écriture du répertoire du certificat : disposer d’une autorisation de lecture et d’écriture sur le répertoire où se trouvent les fichiers de certificat/clé privée PEM ou le fichier de keystore JKS.
  2. Exécution des scripts d’arrêt et de démarrage : after_script génère par défaut les scripts suivants :
export JAVA_HOME="<java_home>" && "<catalina_base>/bin/shutdown.sh" && "<catalina_base>/bin/startup.sh"

Suggestions d’octroi minimal des droits :

  • Il est préférable de placer clmBot et Tomcat dans le même groupe métier, en accordant uniquement les droits de lecture/écriture sur le keystore cible ou le répertoire des certificats.
  • Autorisez uniquement l’exécution de shutdown.sh et startup.sh de l’instance Tomcat correspondante ; n’accordez pas de droits sur l’ensemble du répertoire /opt.
  • Dans un environnement Tomcat multi-instance, les autorisations doivent être réparties par instance.

IIS​

Dans le scénario IIS, l’importation du fichier PFX et la mise à jour de la liaison HTTPS s’appuient sur un script Windows PowerShell : des droits d’administrateur sont requis.

clmBot a besoin des droits suivants :

  1. Exécution avec un compte administrateur : exécutez powershell.exe -NoProfile -ExecutionPolicy Bypass pour importer le PFX temporaire et mettre à jour la liaison du site IIS.
  2. Droits de lecture/écriture sur le répertoire des certificats : création et nettoyage du fichier PFX temporaire.

Suggestions d’octroi minimal des droits :

  • Utilisez un compte de service Windows dédié et accordez uniquement les droits nécessaires à la gestion des liaisons des sites IIS cibles.
  • La politique d’exécution PowerShell et les droits des modules doivent être examinés séparément, conformément à la base de sécurité de l’hôte.

Exemple de configuration sudoers sous Linux​

Les exemples suivants servent uniquement à illustrer la granularité des autorisations ; adaptez les chemins réels en fonction de l’hôte cible.

nginx :

clmbot ALL=(root) NOPASSWD: /usr/sbin/nginx -t
clmbot ALL=(root) NOPASSWD: /usr/sbin/nginx -s reload

Apache :

clmbot ALL=(root) NOPASSWD: /bin/systemctl restart apache2.service

Tomcat :

clmbot ALL=(tomcat) NOPASSWD: /opt/apache-tomcat/bin/shutdown.sh
clmbot ALL=(tomcat) NOPASSWD: /opt/apache-tomcat/bin/startup.sh

Exemple d’autorisations pour l’inventaire des certificats :

chown -R root:clmbot /etc/ssl/example
chmod 0750 /etc/ssl/example
chmod 0640 /etc/ssl/example/site.crt /etc/ssl/example/ca.crt
chmod 0640 /etc/ssl/example/site.key

Si vous devez autoriser clmBot à écrire et à sauvegarder les fichiers mentionnés ci-dessus, vous pouvez utiliser une ACL pour une autorisation précise :

setfacl -m u:clmbot:rwx /etc/ssl/example
setfacl -m u:clmbot:rw- /etc/ssl/example/site.crt
setfacl -m u:clmbot:rw- /etc/ssl/example/ca.crt
setfacl -m u:clmbot:rw- /etc/ssl/example/site.key

Liste de contrôle des autorisations avant la mise en ligne​

Astuce

Avant de déployer clmBot, il est recommandé de vérifier chaque élément de configuration des autorisations suivants.

  • clmBot s'exécute-t-il avec un compte dédié, et non avec root ni avec un administrateur.
  • config.yaml autorise-t-il uniquement les comptes nécessaires en lecture et en écriture.
  • Les fichiers de certificat pointés par chaque servers[].format n'accordent-ils que les autorisations de lecture et d'écriture nécessaires.
  • Le répertoire contenant les fichiers de certificat permet-il de créer et de nettoyer les fichiers de sauvegarde .bak.
  • before_script et after_script ont-ils fait l'objet d'un audit manuel.
  • Le fichier sudoers ne contient-il que des commandes précises, et non ALL, bash ou le systemctl complet.
  • Les permissions de rechargement ou de redémarrage de nginx / Apache / Tomcat ne couvrent-elles que l’instance cible.
  • L’adresse et le port d’écoute du mode service (clm-bot server) sont-ils conformes à la politique de pare-feu de l’hôte.
Dernière mise à jour le