Aller au contenu principal

Exigences de privilèges d’exécution de clmBot

Lors de la mise à jour automatique des certificats, clmBot doit pouvoir lire et écrire les fichiers de certificats cibles, puis recharger ou redémarrer le service middleware correspondant. Ce document décrit la configuration de privilèges minimale recommandée pour les différents scénarios middleware.

Note

Les commandes reload / restart du middleware sont définies dans le champ servers[].after_script du fichier config.yaml. Les utilisateurs peuvent les ajuster selon leur environnement réel. clmBot n’exige pas de fonctionner en permanence avec des comptes à hauts privilèges comme 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 droits de lecture nécessaires pour la configuration de clmBot, les répertoires de journaux et les points d’installation des certificats cibles.
  • N’accorder les droits d’écriture que sur les fichiers de certificats, les fichiers de clés privées gérés par clmBot ainsi que sur leurs répertoires.
  • N’autoriser que l’exécution des commandes reload / restart du middleware préalablement validées, sans octroyer les privilèges NOPASSWD: ALL ni les droits root complets.
  • before_script et after_script doivent faire l’objet d’un audit manuel ; les permissions requises dans les scripts doivent être accordées une par une.

Pratiques non recommandées :

  • Faire fonctionner clmBot en continu sous l’identité root ou Administrator.
  • Ouvrir entièrement à clmBot les droits d’accès aux répertoires de configuration des middlewares, au répertoire des certificats ou au contrôle des services système.
  • Accorder à bash, powershell.exe et systemctl des permissions d’exécution sans restriction.

Exigences de permissions pour chaque middleware​

nginx​

clmBot nécessite les permissions suivantes :

  1. Droits de lecture et d’écriture sur le répertoire des certificats : disposer de droits de lecture et d’écriture sur le répertoire contenant le fichier de certificat cible (.crt), le fichier de chaîne CA (optionnel) et le fichier de clé privée (.key), afin d’écrire le nouveau certificat et de 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 la mise à jour du certificat :
nginx -t && nginx -s reload

Recommandations pour limiter les autorisations au strict nécessaire :

  • N'autorisez que l'accès au répertoire des certificats ciblé, sans accorder de droits en lecture et écriture sur l'ensemble de /etc/nginx.
  • Autorisez précisément nginx -t et nginx -s reload via sudoers, sans accorder un shell root complet.

Apache HTTP Server​

clmBot a besoin des autorisations suivantes :

  1. Lecture et écriture dans les répertoires des certificats : droits en lecture et écriture dans les répertoires contenant SSLCertificateFile, SSLCertificateChainFile et SSLCertificateKeyFile.
  2. Exécution des commandes 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

Recommandation d’autorisation minimale :

  • N’ouvrir que le répertoire du certificat cible, sans accorder l’accès à tout le répertoire de configuration Apache.
  • Via sudoers, n’accorder l’autorisation restart qu’au nom du service Apache réellement utilisé sur le système actuel.

Tomcat​

clmBot nécessite les autorisations suivantes :

  1. Lecture/écriture du répertoire des certificats : disposer des droits de lecture et d’écriture sur le répertoire contenant les fichiers PEM du certificat/clé privée ou les fichiers 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"

Recommandation de privilèges minimaux :

  • Donner la priorité à l'utilisation du même groupe métier pour clmBot et Tomcat, en n'accordant que les droits de lecture/écriture sur le keystore cible ou le répertoire de certificats.
  • Autoriser uniquement l'exécution de shutdown.sh et startup.sh pour l'instance Tomcat correspondante, sans accorder les droits sur l'ensemble du répertoire /opt.
  • Pour un environnement Tomcat multi-instances, l'autorisation doit être décomposée par instance.

IIS​

Le scénario IIS repose sur des scripts Windows PowerShell pour importer le PFX et mettre à jour la liaison HTTPS, ce qui nécessite des privilèges administrateur.

clmBot nécessite les autorisations suivantes :

  1. Exécution avec un compte administrateur : exécuter 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 de certificats : création et nettoyage des fichiers PFX temporaires.

Recommandation de privilèges minimaux :

  • Utiliser un compte de service Windows dédié, en n'accordant que les autorisations nécessaires à la gestion de la liaison du site IIS cible.
  • La stratégie d'exécution PowerShell et les autorisations des modules doivent être auditées séparément conformément à la ligne de base de sécurité de l'hôte.

Exemple de configuration sudoers Linux​

L'exemple suivant exprime uniquement la granularité de l'autorisation ; les chemins réels doivent être ajustés 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 de permissions du répertoire de 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

Pour autoriser clmBot à écrire et sauvegarder les fichiers mentionnés ci-dessus, vous pouvez accorder des autorisations précises via une ACL :

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 vérification des autorisations avant lancement​

Conseil

Avant de déployer clmBot, il est recommandé de vérifier point par point la configuration des autorisations suivante.

  • clmBot fonctionne-t-il avec un compte dédié, et non avec root ou un administrateur.
  • config.yaml n’autorise-t-il que la lecture et l’écriture aux comptes nécessaires.
  • Chaque fichier de certificat pointé par servers[].format n’ouvre-t-il que les droits de lecture et d’écriture nécessaires.
  • Le répertoire contenant les fichiers de certificat autorise-t-il la création et le nettoyage des fichiers de sauvegarde .bak.
  • before_script et after_script ont-ils déjà fait l’objet d’un audit manuel.
  • Vérifiez que sudoers ne contient que des commandes précises, et non ALL, bash ou un accès complet à systemctl.
  • Vérifiez que les droits de rechargement ou de redémarrage de nginx / Apache / Tomcat sont limités à l'instance cible.
  • Vérifiez que l'adresse et le port d'écoute en mode service (clm-bot server) respectent la politique du pare-feu de l'hôte.
Dernière mise à jour le