Saltar al contenido principal

Requisitos de permisos para la ejecución de clmBot

Al realizar la renovación automática de certificados, clmBot necesita leer y escribir los archivos de certificado de destino y, después de la actualización, recargar o reiniciar el servicio de middleware correspondiente. Este artículo describe la configuración de permisos mínimos recomendada en distintos escenarios de middleware.

Nota

Los comandos de reload / restart del middleware se definen en el campo servers[].after_script de config.yaml y el usuario puede ajustarlos según su entorno real. clmBot no requiere ejecutarse de forma permanente con cuentas de privilegios elevados como root o Administrator.

Principio de privilegios mínimos​

Se recomienda ejecutar clmBot con una cuenta de sistema dedicada (por ejemplo, clmbot) y seguir estos principios:

  • Conceder a esa cuenta únicamente los permisos necesarios para leer la configuración de clmBot, el directorio de registros y la ubicación de instalación de los certificados de destino.
  • Conceder permisos de escritura solo a los archivos de certificado, los archivos de clave privada y los directorios donde se encuentren gestionados por clmBot.
  • Permitir únicamente la ejecución de los comandos de reload / restart del middleware que hayan sido verificados; no conceder NOPASSWD: ALL ni permisos completos de root.
  • before_script y after_script deben someterse a auditoría manual; los permisos que necesiten los scripts deben autorizarse uno a uno.

Prácticas no recomendadas:

  • Deje que clmBot se ejecute a largo plazo con la identidad root o Administrator.
  • Abra por completo el directorio de configuración del middleware, el directorio de certificados o el control de servicios del sistema a clmBot.
  • Otorgue permisos de ejecución sin restricciones a bash, powershell.exe y systemctl.

Requisitos de permisos de cada middleware​

nginx​

clmBot necesita los siguientes permisos:

  1. Permisos de lectura y escritura en el directorio de certificados: tener permisos de lectura y escritura en el directorio donde se encuentran el archivo de certificado de destino (.crt), el archivo de cadena de CA (opcional) y el archivo de clave privada (.key), para poder escribir el nuevo certificado y crear la copia de seguridad .bak.
  2. Ejecutar el comando reload: after_script genera de forma predeterminada el siguiente script, que se utiliza para recargar nginx después de la renovación del certificado:
nginx -t && nginx -s reload

Sugerencias de privilegios mínimos:

  • Solo otorgue acceso al directorio de certificados de destino, no conceda permisos de lectura y escritura sobre todo /etc/nginx.
  • Autorice de forma precisa mediante sudoers nginx -t y nginx -s reload, sin otorgar un shell de root completo.

Apache HTTP Server​

clmBot necesita los siguientes permisos:

  1. Permisos de lectura y escritura en el directorio de certificados: debe tener permisos de lectura y escritura en los directorios donde se encuentran SSLCertificateFile, SSLCertificateChainFile y SSLCertificateKeyFile.
  2. Ejecutar el comando de reinicio del servicio: after_script genera de forma predeterminada uno de los siguientes scripts (según la distribución):
systemctl restart httpd.service
systemctl restart apache2.service

Recomendaciones de privilegios mínimos:

  • Solo abra el directorio de certificados de destino, no otorgue acceso a todo el directorio de configuración de Apache.
  • A través de sudoers, conceda únicamente el permiso restart para el nombre de servicio de Apache que el sistema esté utilizando actualmente.

Tomcat​

clmBot requiere los siguientes permisos:

  1. Permiso de lectura y escritura en el directorio de certificados: tener permisos de lectura y escritura en el directorio donde se encuentran los archivos de certificado/clave privada PEM o el archivo de almacén de claves JKS.
  2. Ejecutar scripts de detención e inicio: after_script genera por defecto los siguientes scripts:
export JAVA_HOME="<java_home>" && "<catalina_base>/bin/shutdown.sh" && "<catalina_base>/bin/startup.sh"

Recomendaciones de privilegios mínimos:

  • Prioriza que clmBot y Tomcat utilicen el mismo grupo de negocio, concediendo únicamente permisos de lectura y escritura sobre el keystore objetivo o el directorio de certificados.
  • Permite ejecutar solo shutdown.sh y startup.sh de la instancia Tomcat correspondiente; no concedas permisos sobre todo el directorio /opt.
  • En entornos Tomcat con múltiples instancias, la autorización debe dividirse por instancia.

IIS​

El escenario de IIS depende de scripts de Windows PowerShell para importar el PFX y actualizar los enlaces HTTPS; se requieren privilegios de administrador.

clmBot necesita los siguientes permisos:

  1. Ejecución con cuenta de administrador: ejecutar powershell.exe -NoProfile -ExecutionPolicy Bypass para importar el PFX temporal y actualizar los enlaces del sitio IIS.
  2. Permisos de lectura y escritura en el directorio de certificados: para la creación y limpieza del archivo PFX temporal.

Recomendaciones de privilegios mínimos:

  • Usa una cuenta de servicio dedicada de Windows y concédele únicamente los permisos necesarios para administrar los enlaces del sitio IIS objetivo.
  • La política de ejecución de PowerShell y los permisos de módulos deben auditarse por separado según la línea base de seguridad del host.

Ejemplo de configuración de sudoers en Linux​

Los siguientes ejemplos solo expresan la granularidad de la autorización; ajusta las rutas reales según el host objetivo.

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

Ejemplo de permisos de directorio de certificados:

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 necesita permitir que clmBot escriba y realice copias de seguridad de los archivos mencionados, puede usar ACL para otorgar permisos precisos:

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

Lista de verificación de permisos antes del despliegue​

Sugerencia

Antes de implementar clmBot, se recomienda confirmar las siguientes configuraciones de permisos una por una.

  • ¿clmBot utiliza una cuenta dedicada para su ejecución, en lugar de root o un administrador?
  • ¿config.yaml solo permite la lectura y escritura a las cuentas necesarias?
  • ¿Los archivos de certificado a los que apunta cada servers[].format solo están abiertos con los permisos de lectura y escritura necesarios?
  • ¿El directorio donde se encuentran los archivos de certificado permite crear y limpiar los archivos de respaldo .bak?
  • ¿before_script y after_script ya han sido auditados manualmente?
  • Si el archivo sudoers contiene únicamente comandos exactos, en lugar de ALL, bash o el systemctl completo.
  • Si los permisos de recarga o reinicio de nginx / Apache / Tomcat cubren únicamente la instancia objetivo.
  • Si la dirección y el puerto de escucha del modo de servicio (clm-bot server) cumplen con la política de firewall del host.
Última actualización en