POL-014: Política de Hardening de Sistemas

Campo	Valor
ID	POL-014
Versión	1.0
Fecha de Emisión	2026-03-13
Próxima Revisión	2027-03-13
Propietario	CISO / Equipo DevOps
PCI DSS	Requisito 2
Preguntas ControlCase	Q20, Q21, Q22, Q23, Q24, Q25, Q26, Q27, Q28, Q29, Q30

---

1. Propósito

Definir los estándares de hardening (endurecimiento) para todos los sistemas en el entorno de datos de tarjetas, garantizando que los sistemas se configuren de forma segura eliminando servicios innecesarios, cambiando credenciales por defecto y aplicando configuraciones de seguridad antes de su puesta en producción.

2. Alcance

Tipo de Sistema	Componentes	Entorno
Contenedores Docker	node:20-alpine, postgres:15-alpine	Todos
Orquestador	Kubernetes (DOKS)	Producción
API Gateway	Kong OSS	Producción
Bases de datos	PostgreSQL 15 (managed + self-hosted)	Todos
VMs de compliance	Ubuntu 22.04 (CDD, VAPT, Collector)	Compliance
CI/CD	GitHub Actions runners	CI

3. Fuentes de Hardening (Q20)

3.1 Estándares de Referencia

Sistema	Fuente de Hardening	URL/Referencia
Linux/Ubuntu	CIS Benchmark for Ubuntu 22.04	cisecurity.org
PostgreSQL	CIS Benchmark for PostgreSQL 15	cisecurity.org
Kubernetes	CIS Kubernetes Benchmark	cisecurity.org
Docker	CIS Docker Benchmark	cisecurity.org
Node.js	OWASP Node.js Security Cheat Sheet	owasp.org
Kong	Kong Security Best Practices	docs.konghq.com
TLS	Mozilla TLS Configuration	ssl-config.mozilla.org

3.2 Proceso de Selección de Fuentes

1. Verificar si existe CIS Benchmark para el componente
2. Si no existe, usar guías del vendor + NIST SP 800-123
3. Documentar las configuraciones aplicadas y desviaciones justificadas

4. Eliminación de Defaults y Servicios Innecesarios (Q21, Q22, Q23)

4.1 Credenciales por Defecto

Control	Implementación
Contraseñas por defecto	Todas cambiadas antes de poner en producción
Usuarios por defecto	Deshabilitados o eliminados si no son necesarios
Claves SSH por defecto	Reemplazadas con claves generadas específicamente
Community strings SNMP	SNMP deshabilitado (no se usa)
Cuentas de vendor	Deshabilitadas o renombradas

4.2 Servicios Innecesarios

Principio: Solo habilitar lo estrictamente necesario.

Sistema	Servicios Permitidos	Servicios Deshabilitados
Contenedores Node.js	Node.js runtime, aplicación	SSH, cron, syslog, todo lo demás
PostgreSQL Managed	PostgreSQL (puerto 25060)	Todos los demás
Kong	HTTP proxy (:8000), HTTPS proxy (:8443), Admin API (:8001 — solo interno)	Todos los demás
VMs de compliance	SSH (:22), servicios de compliance	Telnet, FTP, rsh, rlogin, SNMP
Kubernetes nodes	kubelet, kube-proxy, container runtime	Todos los demás

4.3 Protocolos Inseguros Prohibidos

Protocolo	Estado	Alternativa
Telnet	Prohibido	SSH
FTP	Prohibido	SFTP/SCP
rsh/rlogin	Prohibido	SSH
HTTP (sin TLS)	Prohibido para datos sensibles	HTTPS
SSL 2.0/3.0	Prohibido	TLS 1.2+
TLS 1.0/1.1	Prohibido	TLS 1.2+
SNMP v1/v2c	Prohibido	SNMP v3 o deshabilitado

4.4 Justificación de Servicios Habilitados

Para cada servicio/protocolo habilitado se documenta:

• Nombre del servicio
• Puerto
• Justificación de negocio
• Funciones de seguridad implementadas (cifrado, autenticación)
• Responsable

5. Hardening de Contenedores Docker (Q24)

5.1 Configuraciones Obligatorias del Dockerfile

Control	Implementación
Imagen base	node:20-alpine (imagen mínima)
Usuario no-root	USER node (nunca ejecutar como root)
Read-only filesystem	readOnlyRootFilesystem: true en K8s securityContext
No privilege escalation	allowPrivilegeEscalation: false
Drop all capabilities	drop: ["ALL"] en securityContext
No new privileges	seccomp profile default
Multi-stage build	Separar build de runtime (no incluir devDependencies)
.dockerignore	Excluir node_modules, .git, .env, tests
Health check	HEALTHCHECK configurado
npm ci	Usar npm ci --omit=dev (no npm install)

5.2 Ejemplo de securityContext de Kubernetes

securityContext:
  runAsNonRoot: true
  runAsUser: 1000
  readOnlyRootFilesystem: true
  allowPrivilegeEscalation: false
  capabilities:
    drop: ["ALL"]

6. Hardening de PostgreSQL (Q25)

Control	Configuración
Autenticación	scram-sha-256 (no md5 ni trust)
SSL	ssl = on, ssl_min_protocol_version = 'TLSv1.2'
Usuarios por defecto	Contraseñas cambiadas, postgres user con acceso restringido
Listen addresses	Solo IP interna del cluster (no 0.0.0.0)
pg_hba.conf	Solo conexiones desde subnets autorizados del CDE
Log connections	log_connections = on
Log disconnections	log_disconnections = on
Log statement	log_statement = 'ddl' (mínimo DDL)
Password encryption	password_encryption = 'scram-sha-256'
Row Level Security	Habilitado para tablas multi-tenant

7. Hardening de Kubernetes (Q26)

Control	Configuración
RBAC	Habilitado con roles de menor privilegio
Network Policies	Implementadas por namespace (ver POL-002)
Pod Security Standards	restricted para CDE namespace
Secrets	Cifrados at-rest (DO managed encryption)
API Server	Solo acceso con credenciales válidas
Dashboard	Deshabilitado en producción
etcd	Cifrado habilitado (gestionado por DO)
Audit logging	Habilitado para eventos de seguridad
Service accounts	Token automounting deshabilitado donde no se necesita
Image pull policy	Always para imágenes de producción

8. Hardening de Kong Gateway (Q27)

Control	Configuración
Admin API	Solo accesible desde red interna (loopback o pod local)
TLS	Obligatorio para proxy (:8443)
Rate limiting	Plugin configurado por ruta
IP restriction	Plugin para APIs sensibles
Bot detection	Plugin habilitado
Request size limiting	Limitado a 10MB max
CORS	Configurado con orígenes específicos
Response headers	X-Frame-Options, X-Content-Type-Options, Strict-Transport-Security
Error responses	Sin información de debug en producción
Logging	Access log + error log a stdout

9. Funciones de un Solo Propósito por Servidor (Q28)

9.1 Principio

Cada contenedor/pod ejecuta una sola función:

Contenedor	Función Única
auth-service	Autenticación y autorización
tokenization-service	Tokenización de PAN
card-vault-service	Almacenamiento seguro de tokens
payments-api	Procesamiento de pagos
kong	API Gateway
postgresql	Base de datos (una instancia por BD)
prometheus	Recolección de métricas
grafana	Visualización
alertmanager	Gestión de alertas

9.2 Cuando Múltiples Funciones Coexisten

Si por necesidad técnica dos funciones deben coexistir en un pod:

• Documentar justificación técnica
• Implementar controles de aislamiento adicionales (securityContext separado, network policy restrictiva)
• Aprobar por CISO

10. Parámetros de Seguridad del Sistema (Q29, Q30)

10.1 Parámetros Configurados

Categoría	Parámetro	Valor
Kernel (sysctl)	net.ipv4.ip_forward	Según necesidad de K8s
Kernel	net.ipv4.conf.all.accept_redirects	0
Kernel	net.ipv4.conf.all.send_redirects	0
Node.js	--max-old-space-size	Limitado según pod resources
Kong	proxy_access_log	Habilitado
PostgreSQL	shared_preload_libraries	Solo extensiones necesarias

10.2 Documentación de Parámetros

Cada parámetro de seguridad configurado incluye:

• Nombre del parámetro
• Valor configurado
• Justificación
• Impacto si se cambia
• Referencia al estándar de hardening

11. Proceso de Hardening para Nuevos Sistemas

1. Antes de desplegar un nuevo componente:
   • Identificar CIS Benchmark o guía de hardening aplicable
   • Crear checklist de hardening
2. Aplicar configuraciones de hardening
3. Verificar con herramienta automatizada (si disponible)
4. Documentar configuración final
5. Revisar por segundo par de ojos (DevOps peer review)
6. Aprobar antes de poner en producción
7. Escanear vulnerabilidades post-hardening

12. Revisión Periódica

Actividad	Frecuencia	Responsable
Verificar configuraciones de hardening	Semestral	DevOps
Re-evaluar estándares CIS (nuevas versiones)	Anual	CISO + DevOps
Verificar credenciales por defecto en nuevos componentes	En cada despliegue	DevOps
Auditoría de servicios habilitados	Trimestral	DevOps

---

Historial de Revisiones

Versión	Fecha	Autor	Cambios
1.0	2026-03-13	DevOps / CISO	Documento inicial

Aprobación

Rol	Nombre	Firma	Fecha
CISO / Oficial de Seguridad	_________________	_________________	//____
Gerencia Ejecutiva	_________________	_________________	//____