Con Docker#

Esta sección está dirigida al administrador de la distribución Docker de Sherpa Orchestrator. Los comandos requieren acceso al servidor y a Docker Compose. Los archivos de cliente y las imágenes deben tener la misma versión. Es necesario comprobar que la distribución instalada incluya el parámetro o script requerido.

Diagnóstico después de instalar o actualizar#

El instalador y el script de actualización ofrecen ejecutar el diagnóstico. Para repetirlo, se utiliza este comando desde el directorio de instalación:

cd /opt/SherpaOrchestrator
sudo bash sh_scripts/diagnostics.sh

Se comprueban los contenedores, componentes seleccionados, versiones, espacio libre, conexión a la base de datos, migraciones, Vault, SIEM, nginx, Almacenamiento, interfaz web y registros. Las correcciones que ofrece el script requieren una confirmación independiente. Antes de confirmar, es necesario leer la descripción de la acción.

Un resultado sin observaciones indica que las comprobaciones implementadas se completaron correctamente. No sustituye la prueba de un escenario de usuario ni de la entrega a SIEM. En caso de error, es necesario guardar el nombre de la comprobación y el mensaje, resolver la causa y repetir el diagnóstico. La comprobación de migraciones de esta distribución no demuestra que todos los objetos del esquema de la base de datos sean correctos.

Retención de métricas del sistema#

El parámetro STORE_SYSTEM_METRICS_DAYS de .env establece los días de retención de las métricas del sistema. El valor predeterminado es 30. El valor 0 desactiva la limpieza automática de estas métricas. Debe usarse un entero no negativo.

El planificador elimina los registros antiguos. Reducir el plazo puede eliminar un historial que no se recupera al aumentar después el valor. Este parámetro no establece la retención de Trabajos, auditoría ni mensajes de Robots.

Ejemplo: para conservar los últimos 14 días de métricas del sistema, indique en .env:

STORE_SYSTEM_METRICS_DAYS=14

Para aplicar el plazo, vuelva a crear solo el contenedor backend durante la ventana acordada:

cd /opt/SherpaOrchestrator
sudo docker compose up -d --no-deps --force-recreate orchestrator

Requisitos de contraseñas#

Estos parámetros de .env se aplican a las contraseñas nuevas de Usuarios y Cuentas al crear un registro o cambiar su contraseña:

La longitud se comprueba en bytes y puede diferir del número de caracteres cuando no son ASCII. Las longitudes mínima y máxima deben ser enteros positivos. Si el máximo es inferior al mínimo, se utiliza el mínimo. Los valores de longitud y las expresiones regulares no válidos se sustituyen por los predeterminados. La expresión regular se introduce sin delimitadores.

Cambiar la política no modifica las contraseñas guardadas. Si se rechaza una contraseña nueva, es necesario revisar su longitud y formato. Para aplicar cambios en las variables de entorno, se debe recrear el contenedor backend durante una ventana de mantenimiento acordada:

cd /opt/SherpaOrchestrator
sudo docker compose up -d --no-deps --force-recreate orchestrator

Reiniciar un contenedor no vuelve a cargar las variables de entorno de .env.

Copia de seguridad y migración#

Antes de actualizar o migrar se requiere una copia de seguridad verificada. El volcado de la base de datos no incluye Almacenamiento, configuración ni secretos de Vault. El contenido de la copia y sus limitaciones se describen en Copia de seguridad y recuperación.

La migración de una distribución local a Docker requiere la misma versión, el mismo servidor y el mismo motor de base de datos. Es necesario conservar HOST_IP, la clave de cifrado, las bases principal y de archivo, Almacenamiento, certificados y la instalación original para la reversión. Durante la copia y verificación deben detenerse la aplicación y los demás procesos de escritura.

Antes de la migración, es necesario obtener del soporte técnico de Sherpa el procedimiento de migración de local a Docker para la versión y el motor de base de datos utilizados. Cambiar el servidor, la IP, la versión o el motor requiere un plan aparte. No deben ejecutarse simultáneamente la instalación nueva y la anterior con la misma base de datos de producción.

Al cambiar de servidor conservando la base de datos puede ser necesario restaurar la vinculación de licencias. Antes de comenzar, es necesario obtener del soporte técnico de Sherpa el procedimiento para la versión y el motor utilizados: MariaDB o PostgreSQL. Lo realiza un administrador después de crear una copia de seguridad. El acceso temporal a setup.php y los archivos temporales deben eliminarse inmediatamente después de la comprobación.

Auditoría de base de datos y SIEM#

La auditoría de la base de datos puede contener consultas SQL y valores sensibles. Antes de activarla, es necesario definir permisos, retención, rotación y espacio libre. La activación puede requerir reiniciar la base de datos durante una ventana de mantenimiento. Para una fuente de auditoría MariaDB independiente, es necesario obtener del soporte técnico de Sherpa los procedimientos de configuración del complemento y monitoreo para la versión utilizada.

La integración SIEM estándar requiere una distribución completa con orchestrator-siem-exporter. En una instalación nueva, el componente se selecciona en el instalador. Durante una actualización, en el menú de componentes. Antes de comenzar, es necesario obtener del soporte técnico de Sherpa el procedimiento de instalación o actualización con SIEM para la versión y el motor utilizados. A continuación se describen los requisitos y la comprobación, no el procedimiento completo de instalación.

El receptor SIEM debe admitir Syslog mediante una conexión protegida TLS, el formato RFC 5424 y la separación de mensajes RFC 6587 octet-counting. Estos requisitos definen el formato y el transporte de los eventos. El backend de Orchestrator establece la conexión.

El administrador SIEM proporciona:

• dirección y puerto del receptor;
• nombre del servidor indicado en su certificado;
• certificado de una autoridad de certificación (CA) de confianza para comprobar el receptor;
• certificado y clave privada del cliente si se exige verificación mutua de certificados (mTLS).

El administrador de Orchestrator configura:

• SYSLOG_HOST — dirección del receptor proporcionada por el administrador SIEM;
• SYSLOG_PORT — puerto de recepción de eventos;
• SYSLOG_TLS_* — ajustes de certificados y conexión protegida. Los nombres y valores concretos se comprueban en los archivos de la distribución instalada;
• credenciales de servicio — para que el componente de integración acceda a la fuente de auditoría;
• SIEM_DB_FILTER — filtro de eventos de auditoría de la base de datos enviados a SIEM.

Un SYSLOG_HOST vacío no habilita el envío. Los datos pueden seguir acumulándose con la auditoría activa. El exportador envía los eventos de la fuente de auditoría de la base de datos aceptados por el filtro. No es una copia de todas las acciones del Usuario en la interfaz. Las reglas de detección y alertas se configuran por separado en SIEM.

Para verificar la entrega, el administrador de la base de datos ejecuta una consulta segura con una cuenta habitual autorizada y el administrador SIEM busca el marcador entre los eventos recibidos:

SELECT 'SHERPA_SIEM_CHECK_001' AS marker;

El filtro debe permitir select. El usuario de servicio de la integración está excluido de la exportación. Un diagnóstico correcto sin recibir el evento de prueba no confirma la entrega. Si el receptor permanece inaccesible, es necesario controlar la cola, los registros y el espacio libre.