Aller au contenu principal

Exigences de permissions d'exécution

Lorsque clmBot exécute le renouvellement automatique des certificats, il 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 de privilèges minimaux recommandée pour différents scénarios de middleware.

Information

Les commandes de reload / restart des middlewares sont définies dans le champ servers[].after_script de config.yaml. Vous pouvez les ajuster selon votre environnement réel. clmBot ne nécessite pas d’être exécuté en permanence avec un compte à privilèges élevés 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 :

  • N’accordez à ce compte que les autorisations nécessaires pour lire la configuration de clmBot, les répertoires de journaux et les points d’installation des certificats cibles.
  • N’accordez des autorisations 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’autorisez que les commandes de reload / restart des middlewares préalablement validées ; before_script et after_script doivent être auditées manuellement puis autorisées une par une.

Non recommandé :

  • Faites fonctionner clmBot en permanence avec l’identité root ou Administrator.
  • Accordez globalement à clmBot les droits sur le répertoire de configuration du middleware, le répertoire des certificats ou le contrôle des services système.
  • Attribuez à bash, powershell.exe, systemctl des droits d’exécution illimités ou NOPASSWD: ALL.

Exigences de droits pour chaque middleware​

MiddlewareDroits requisExemple d’after_script
nginxCertificat (.crt), chaîne de CA (facultatif), permissions de lecture/écriture sur la clé privée (.key), les fichiers et leur répertoire, pour écrire le nouveau certificat et créer la sauvegarde .baknginx -t && nginx -s reload
ApacheAutorisations de lecture/écriture sur les répertoires où se trouvent SSLCertificateFile, SSLCertificateChainFile, SSLCertificateKeyFilesystemctl restart httpd.service ou systemctl restart apache2.service
TomcatCertificat/clé privée PEM ou fichier keystore JKS et autorisations de lecture/écriture sur leurs répertoiresJAVA_HOME + shutdown.sh + startup.sh
IISImportation du PFX et mise à jour des liaisons de site via le script PowerShell intégré de clmBot, nécessite des droits d’administrateur ; création et nettoyage du fichier PFX temporaireAucune configuration requise, le script intégré gère automatiquement l’opération
Information
  • Les scripts générés automatiquement par la fonction de découverte des certificats utilisent les chemins absolus des commandes (par exemple, nginx avec les paramètres -p, -c, systemctl utilise des chemins absolus) ; référez-vous au servers[].after_script réellement généré.
  • Si Tomcat est géré par systemd, le script généré automatiquement est systemctl restart <tomcat 服务名> au lieu de shutdown.sh / startup.sh.

Exemple de configuration sudoers sous Linux​

Les exemples suivants illustrent uniquement 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 de droits d’accès à 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 ci-dessus, vous pouvez accorder des permissions précises via 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/site.key

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

Conseil

Avant de déployer clmBot, il est recommandé de vérifier les configurations d’autorisation suivantes une par une.

  • clmBot s’exécute-t-il avec un compte dédié, et non avec root ou un administrateur.
  • config.yaml n’autorise-t-il que les comptes nécessaires à la lecture et à l’écriture.
  • Les fichiers de certificat pointés par chaque servers[].format n’ouvrent-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 déjà fait l’objet d’un audit manuel.
  • Vérifier si sudoers ne contient que des commandes précises, et non ALL, bash ou le systemctl complet.
  • Vérifier si les autorisations de reload ou restart pour nginx / Apache / Tomcat ne couvrent que l'instance cible.
  • Vérifier si l'adresse d'écoute et le port du mode de service (clm-bot server) sont conformes à la stratégie de pare-feu de l'hôte.
Dernière mise à jour le