Seguridad del servidor

Esta sección abarca la verificación de los controles de seguridad a nivel de servidor para una implementación de Passwork on-premise. En las instancias alojadas en la nube, los controles de red y de certificados los gestiona la infraestructura de Passwork; centre esta revisión en la configuración a nivel de aplicación.

---

1. TLS / HTTPS

Qué verificar

1.1 HTTPS aplicado

Todas las solicitudes HTTP deben redirigir a HTTPS. Verifíquelo con:

curl -I http://your.passwork.url/
# Expected: HTTP/1.1 301 Moved Permanently
# Location: https://your.passwork.url/

1.2 Certificado válido en producción

Los certificados autofirmados solo son aceptables en entornos aislados de desarrollo o de PoC. Las implementaciones de producción requieren un certificado firmado por una CA de confianza (Let's Encrypt, una CA interna para redes aisladas, o una CA comercial).

Compruebe el certificado:

openssl s_client -connect your.passwork.url:443 -servername your.passwork.url 2>/dev/null \
  | openssl x509 -noout -issuer -subject -dates

Verifique:

• El emisor es una CA de confianza (no self-signed)
• notAfter está al menos 30 días en el futuro
• El sujeto coincide con el nombre de host (CN o SAN)

1.3 Versión de TLS

TLS 1.2 como mínimo. TLS 1.3 preferido. SSLv3, TLS 1.0 y TLS 1.1 deben estar desactivados.

nmap --script ssl-enum-ciphers -p 443 your.passwork.url

O utilice un escáner externo: SSL Labs, testssl.sh.

Calificación esperada: A o superior.

1.4 Cabecera HSTS presente

La cabecera Strict-Transport-Security impide que los navegadores accedan al sitio a través de HTTP tras la primera conexión HTTPS.

curl -s -I https://your.passwork.url/ | grep -i strict
# Expected: strict-transport-security: max-age=31536000; includeSubDomains

Configuración predeterminada

En las compilaciones de Docker, HSTS se configura en conf/nginx/nginx.conf. En Apache2/IIS, se establece en la configuración del host virtual. Si falta la cabecera, consulte Terminación SSL.

---

2. Cabeceras de seguridad HTTP

Passwork establece las siguientes cabeceras de forma predeterminada en Docker (Nginx extra/security-headers.conf) y Apache2 (.htaccess). Verifique que todas están presentes.

curl -s -I https://your.passwork.url/ | grep -iE "x-frame|x-content|x-xss|referrer|permissions|strict"

Cabecera	Valor esperado	Riesgo si falta
X-Frame-Options	DENY	Clickjacking
X-Content-Type-Options	nosniff	Ataques de MIME sniffing
X-XSS-Protection	1; mode=block	XSS en navegadores antiguos
Referrer-Policy	strict-origin-when-cross-origin	Fuga del referrer
Permissions-Policy	camera=(), microphone=(), geolocation=()	Acceso innecesario a API
Strict-Transport-Security	max-age=31536000; includeSubDomains	Ataques de degradación/MITM

Para conocer los detalles de configuración, consulte Cabeceras.

Si falta alguna cabecera

En Docker: verifique que extra/security-headers.conf está incluido en la configuración de Nginx y que el contenedor se ha reiniciado tras los cambios. En Apache2: verifique que el procesamiento de .htaccess está activado (AllowOverride All).

---

3. Configuración de CORS

CORS controla qué orígenes externos pueden realizar solicitudes a la API de Passwork.

Riesgo de la configuración predeterminada: el archivo cors.conf predeterminado de Docker establece Access-Control-Allow-Origin: *, lo que permite que cualquier origen realice solicitudes de origen cruzado. Esto es aceptable cuando Passwork se implementa en una red privada sin acceso externo, pero debe revisarse si la instancia es accesible desde Internet.

Qué verificar

Compruebe la cabecera CORS actual:

curl -s -I -H "Origin: https://attacker.example.com" https://your.passwork.url/api/ \
  | grep -i access-control

Hallazgo: si la respuesta incluye Access-Control-Allow-Origin: * y el servidor es accesible desde Internet, restrinja el origen a la URL exacta de Passwork.

Cómo restringirlo (Docker):

Edite conf/nginx/extra/cors.conf y sustituya el comodín por un patrón de origen específico. Consulte Cabeceras — Configuración de CORS para conocer la configuración exacta.

---

4. Endurecimiento de red

MongoDB

MongoDB no debe ser accesible desde Internet. Verifique:

# From an external host:
nc -zv your.passwork.url 27017
# Expected: Connection refused

Configuración correcta: MongoDB se enlaza únicamente a 127.0.0.1 (loopback) o a una interfaz de red privada. Nunca debe enlazarse a 0.0.0.0 en un entorno de producción.

Las implementaciones on-premise también deben verificar que la autenticación de MongoDB está activada. Consulte Configuración de la autorización de MongoDB.

Firewall / puertos expuestos

Solo los siguientes puertos deben ser accesibles desde redes no confiables:

Puerto	Protocolo	Propósito
443	TCP	HTTPS (interfaz web y API de Passwork)
80	TCP	HTTP (solo redirección a HTTPS)

Todos los demás puertos (27017 para MongoDB, puertos de replicación de la base de datos, interfaces de administración internas) deben bloquearse a nivel del firewall de red.

Proxy inverso y proxies de confianza

Si Passwork se implementa detrás de un proxy inverso (Nginx, Apache, HAProxy, balanceador de carga en la nube), configure los proxies de confianza en config.env:

CLIENT_IP_SOURCES=REMOTE_ADDR

O restrinja a las IP de proxy conocidas para evitar la suplantación de IP a través de la cabecera X-Forwarded-For. Consulte Proxies de confianza.

---

5. Endpoint de comprobación de estado

Passwork expone un endpoint de comprobación de estado en /api/latest/health-check. Este endpoint puede revelar información sobre el estado del sistema.

Qué verificar

Compruebe si el endpoint requiere autenticación:

curl -s https://your.passwork.url/api/latest/health-check

Si el endpoint devuelve datos sin un token, configure HEALTH_CHECK_TOKEN en config.env:

HEALTH_CHECK_TOKEN=<random-256-bit-string>

Tras la configuración, el endpoint requiere el token en la cabecera de la solicitud. Consulte Comprobación de estado.

---

6. Modo de restablecimiento de emergencia

El indicador IS_EMERGENCY_RESET_ENABLED=1 en config.env permite restablecer la contraseña y la 2FA de la cuenta de propietario a través de la consola del servidor sin autenticación. Se trata de un potente mecanismo de recuperación que no debe permanecer activado tras su uso.

Qué verificar

En el servidor, compruebe el archivo de configuración:

# Linux
grep "IS_EMERGENCY_RESET_ENABLED" /var/www/init/config.env

# Docker
grep "IS_EMERGENCY_RESET_ENABLED" /<passwork>/conf/keys/config.env

Valores aceptables:

• Ajuste no presente → correcto
• IS_EMERGENCY_RESET_ENABLED=0 → correcto
• IS_EMERGENCY_RESET_ENABLED=1 → hallazgo: debe establecerse en 0 o eliminarse

Si este indicador se utilizó recientemente, verifique en el registro de auditoría que solo se accedió a la cuenta de propietario esperada.

Para conocer el procedimiento de restablecimiento de emergencia, consulte Modo de emergencia.

---

7. Actualidad de las tareas en segundo plano y de la sincronización LDAP

Las tareas en segundo plano impulsan la sincronización LDAP, las comprobaciones de caducidad de contraseñas y otras tareas de mantenimiento automatizadas. Si cron no se está ejecutando, la pertenencia a grupos LDAP puede quedar desactualizada: los usuarios que abandonaron un grupo de AD pueden conservar el acceso a las bóvedas en Passwork.

Qué verificar

En el panel de administración de Passwork, vaya a Configuración → Tareas en segundo plano y verifique:

• Todas las tareas muestran una marca de tiempo de Hora de inicio reciente (dentro de la ventana de programación esperada)
• Ninguna tarea muestra un estado de error

Para conocer los detalles de configuración de cron, consulte Configuración de Cron para Linux o Configuración del Programador de tareas de Windows.

---

Lista de comprobación resumida

#	Control	Estado
1.1	Redirección HTTP → HTTPS activa
1.2	Certificado SSL válido firmado por una CA
1.3	Solo TLS 1.2+; TLS antiguo desactivado
1.4	Cabecera HSTS presente con includeSubDomains
2	Las 6 cabeceras de seguridad presentes
3	Origen CORS restringido (si es accesible desde Internet)
4.1	Puerto 27017 de MongoDB no accesible externamente
4.2	Autenticación de MongoDB activada
4.3	Solo los puertos 80/443 expuestos a redes no confiables
4.4	Proxies de confianza configurados (si está detrás de un proxy inverso)
5	Endpoint de comprobación de estado protegido con token
6	IS_EMERGENCY_RESET_ENABLED es 0 o está ausente
7	Tareas en segundo plano ejecutándose según lo programado

LLM version