Saltar al contenido principal

Requisitos de permisos de ejecución de clmBot

clmBot, al realizar la actualización automática de certificados, necesita leer y escribir en los archivos de certificados de destino, y después de la actualización, recargar o reiniciar el servicio de middleware correspondiente. Este documento explica la configuración de permisos mínimos recomendada para varios 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 a largo plazo con cuentas de altos privilegios como root o Administrator.

Principio de privilegios mínimos​

Se recomienda utilizar una cuenta de sistema dedicada (como clmbot) para ejecutar clmBot, y seguir los siguientes principios:

  • Otorgar a esta cuenta solo los permisos necesarios para leer la configuración de clmBot, el directorio de registros y los puntos de instalación de certificados de destino.
  • Otorgar permisos de escritura solo a los archivos de certificados, archivos de claves privadas y sus directorios administrados por clmBot.
  • Permitir solo la ejecución de comandos de reload / restart del middleware confirmados, sin otorgar NOPASSWD: ALL ni permisos completos de root.
  • before_script y after_script deben pasar por auditoría manual, y los permisos necesarios en los scripts deben otorgarse uno por uno.

Prácticas no recomendadas:

  • Hacer que clmBot se ejecute de forma permanente con la identidad root o Administrator.
  • Abrir por completo a clmBot los directorios de configuración de middlewares, los directorios de certificados o los permisos de control del servicio del sistema.
  • Otorgar permisos de ejecución sin restricciones a bash, powershell.exe y systemctl.

Requisitos de permisos por middleware​

nginx​

clmBot necesita los siguientes permisos:

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

Recomendación de privilegios mínimos:

  • Abrir únicamente el directorio del certificado de destino, sin otorgar permisos de lectura y escritura sobre todo /etc/nginx.
  • Autorizar con precisión mediante sudoers nginx -t y nginx -s reload, sin otorgar un shell root completo.

Apache HTTP Server​

clmBot necesita los siguientes permisos:

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

Recomendación de permisos mínimos:

  • Solo abrir el directorio del certificado de destino, sin otorgar acceso a todo el directorio de configuración de Apache.
  • A través de sudoers, otorgar únicamente el permiso restart al nombre del servicio de Apache realmente utilizado por el sistema actual.

Tomcat​

clmBot requiere 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 los archivos de certificados/claves PEM o los archivos JKS keystore.
  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"

Recomendación de privilegios mínimos:

  • Priorizar que clmBot y Tomcat utilicen el mismo grupo de negocio, otorgando únicamente permisos de lectura y escritura sobre el keystore o directorio de certificados de destino.
  • Permitir únicamente la ejecución de shutdown.sh y startup.sh de la instancia de Tomcat correspondiente, sin otorgar permisos sobre todo el directorio /opt.
  • En entornos Tomcat con múltiples instancias, la autorización debe dividirse por instancia.

IIS​

El escenario IIS depende de scripts de Windows PowerShell para importar 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 de los sitios IIS.
  2. Permisos de lectura y escritura sobre el directorio de certificados: creación y limpieza del archivo PFX temporal.

Recomendación de privilegios mínimos:

  • Utilizar una cuenta de servicio dedicada de Windows, otorgando únicamente los permisos necesarios para administrar los enlaces de los sitios IIS de destino.
  • 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​

El siguiente ejemplo solo expresa la granularidad de la autorización; las rutas reales deben ajustarse según el host de destino.

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

Para permitir que clmBot escriba y respalde los archivos mencionados, puede utilizar 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 previa al lanzamiento​

Consejo

Antes de implementar clmBot, se recomienda confirmar los siguientes permisos de configuración punto por punto.

  • ¿Se ejecuta clmBot con una cuenta dedicada, en lugar de root o un administrador?
  • ¿config.yaml solo permite que las cuentas necesarias lean y escriban?
  • ¿Cada archivo de certificado apuntado por servers[].format solo tiene abiertos 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, after_script ya han sido auditados manualmente?
  • ¿sudoers contiene solo comandos exactos, en lugar de ALL, bash o el systemctl completo?
  • ¿Los permisos de reload o restart de nginx / Apache / Tomcat cubren solo la instancia objetivo?
  • ¿La dirección de escucha y el puerto del modo de servicio (clm-bot server) cumplen con la política del firewall del host?
Última actualización en