20. Hardening en nube, contenedores y plataformas virtualizadas

20.1 Introducción

La infraestructura moderna suele combinar máquinas virtuales, servicios en la nube, contenedores, plataformas de orquestación, almacenamiento administrado, identidades y APIs. Estos entornos permiten desplegar rápido, pero también pueden multiplicar errores de configuración.

El hardening en nube, contenedores y virtualización se enfoca en controlar identidades, permisos, redes, imágenes, secretos, configuraciones, registros y automatización.

En este tema veremos principios y controles aplicables a estos entornos, sin depender de un proveedor específico.

20.2 Responsabilidad compartida

En la nube, la seguridad se comparte entre proveedor y cliente. El proveedor protege la infraestructura base, pero el cliente sigue siendo responsable de configurar identidades, redes, datos, cargas de trabajo y accesos.

20.3 Identidades y permisos en nube

En nube, la identidad es un perímetro central. Muchas acciones se realizan mediante APIs y permisos. Una cuenta o rol con privilegios excesivos puede crear recursos, modificar redes, acceder a datos o desactivar controles.

Buenas prácticas:

• Aplicar mínimo privilegio.
• Usar MFA en cuentas administrativas.
• Separar roles por función.
• Evitar cuentas compartidas.
• Rotar claves y eliminar credenciales no usadas.
• Auditar permisos excesivos.
• Registrar acciones administrativas.
• Usar identidades temporales cuando sea posible.

20.4 Redes cloud

Las redes cloud suelen construirse con redes virtuales, subredes, tablas de rutas, gateways, firewalls, grupos de seguridad y balanceadores. El hardening exige que cada comunicación esté justificada.

Controles recomendados:

• Separar subredes públicas y privadas.
• Evitar exponer administración directamente a internet.
• Usar grupos de seguridad con reglas específicas.
• Registrar flujos de red cuando sea posible.
• Aplicar WAF en aplicaciones web públicas.
• Controlar rutas hacia internet y redes internas.
• Usar endpoints privados para servicios sensibles si el proveedor lo permite.

20.5 Almacenamiento en nube

El almacenamiento cloud mal configurado puede exponer datos sensibles. Muchas brechas ocurren por permisos públicos, enlaces compartidos sin control o credenciales filtradas.

Buenas prácticas:

• Bloquear acceso público por defecto.
• Aplicar permisos mínimos.
• Cifrar datos en reposo.
• Registrar accesos y cambios de permisos.
• Clasificar datos sensibles.
• Revisar enlaces compartidos.
• Activar versionado o protección contra borrado cuando corresponda.

20.6 Máquinas virtuales

Las máquinas virtuales necesitan hardening similar a servidores físicos: parches, firewall local, control de usuarios, logs, EDR, servicios mínimos y configuración base.

Además, en entornos virtualizados conviene revisar:

• Imágenes base confiables.
• Plantillas actualizadas.
• Acceso administrativo al hipervisor o consola cloud.
• Snapshots con datos sensibles.
• Redes virtuales y reglas entre VM.
• Agentes de monitoreo y seguridad.
• Backups y recuperación.

20.7 Hipervisores y plataformas de virtualización

El hipervisor y la plataforma de administración virtual son componentes críticos. Si se comprometen, pueden afectar muchas máquinas virtuales.

Controles recomendados:

• Administración desde red dedicada.
• MFA para cuentas administrativas.
• Roles y permisos mínimos.
• Actualizaciones de seguridad.
• Logs de acciones administrativas.
• Backups de configuración.
• Separación de entornos de producción, pruebas y desarrollo.

20.8 Contenedores

Un contenedor empaqueta una aplicación con sus dependencias. Es liviano y rápido, pero no debe tratarse como una barrera de seguridad absoluta.

Riesgos comunes:

• Imágenes con vulnerabilidades.
• Contenedores ejecutándose con privilegios excesivos.
• Secretos incluidos dentro de imágenes.
• Puertos expuestos innecesariamente.
• Falta de límites de recursos.
• Uso de imágenes desconocidas o no verificadas.

20.9 Hardening de imágenes

La seguridad de un contenedor empieza en la imagen. Una imagen insegura se replica cada vez que se despliega.

Buenas prácticas:

• Usar imágenes base confiables y mínimas.
• Eliminar herramientas innecesarias.
• Actualizar dependencias.
• Escanear vulnerabilidades.
• No incluir secretos en la imagen.
• Firmar o verificar imágenes cuando sea posible.
• Versionar imágenes y evitar etiquetas ambiguas como latest en producción.

20.10 Ejecución de contenedores

Un contenedor debe ejecutarse con los mínimos privilegios necesarios.

Controles recomendados:

• No ejecutar como root si no es necesario.
• Evitar modo privilegiado.
• Montar volúmenes con permisos mínimos.
• Limitar capacidades del sistema.
• Definir límites de CPU y memoria.
• Restringir acceso a sockets del host.
• Usar políticas de seguridad del runtime u orquestador.

20.11 Orquestadores y Kubernetes

Los orquestadores administran despliegues, redes, secretos, escalado y permisos. Kubernetes es un ejemplo común. Su hardening requiere controlar tanto nodos como plano de control y cargas de trabajo.

Buenas prácticas generales:

• Proteger API del orquestador.
• Usar RBAC con mínimo privilegio.
• Separar namespaces por entorno o aplicación.
• Aplicar políticas de red.
• Proteger secretos.
• Restringir contenedores privilegiados.
• Monitorear auditoría del clúster.
• Actualizar nodos y componentes.

20.12 Secretos

Los secretos incluyen contraseñas, tokens, claves API, certificados y credenciales de servicio. En entornos cloud y contenedores, su gestión es crítica.

Buenas prácticas:

• Usar gestores de secretos.
• Evitar secretos en código fuente o imágenes.
• Limitar acceso por identidad y rol.
• Rotar secretos periódicamente o ante sospecha.
• Registrar accesos a secretos.
• Cifrar secretos en reposo y tránsito.
• Separar secretos por ambiente.

20.13 Políticas como código

La infraestructura como código permite definir recursos, redes y permisos en archivos versionados. Esto facilita revisión, auditoría y repetibilidad, pero también exige controles.

Controles recomendados:

• Revisión de cambios antes de aplicar.
• Escaneo de configuraciones inseguras.
• Control de secretos en repositorios.
• Separación de ambientes.
• Versionado y aprobación.
• Pruebas de seguridad en pipelines.

20.14 Monitoreo y logs en nube

La nube genera muchos eventos útiles: cambios de permisos, creación de recursos, acceso a datos, llamadas API, flujos de red y eventos de seguridad.

Eventos a registrar:

• Inicios de sesión y uso de cuentas privilegiadas.
• Cambios de roles y permisos.
• Creación o eliminación de recursos.
• Cambios en reglas de red.
• Accesos a almacenamiento.
• Eventos de clústeres y contenedores.
• Alertas de postura o configuración insegura.

20.15 Postura de seguridad

La postura de seguridad describe el estado general de configuración y riesgo. En nube y contenedores cambia con frecuencia, por lo que conviene evaluarla continuamente.

Aspectos a revisar:

• Recursos expuestos públicamente.
• Permisos excesivos.
• Almacenamiento público.
• Imágenes vulnerables.
• Secretos mal gestionados.
• Falta de logs.
• Contenedores privilegiados.
• Reglas de red demasiado amplias.

20.16 Ejemplo práctico: aplicación en contenedores

Una aplicación desplegada en contenedores podría endurecerse con estas medidas:

1. Usar imagen base mínima y actualizada.
2. Escanear imagen antes de desplegar.
3. No incluir secretos en la imagen.
4. Ejecutar contenedor sin privilegios innecesarios.
5. Aplicar límites de recursos.
6. Publicar solo el puerto requerido.
7. Aplicar políticas de red entre componentes.
8. Enviar logs a plataforma central.
9. Monitorear comportamiento en runtime.

20.17 Ejemplo práctico: cuenta cloud administrativa

Una cuenta administrativa en nube debe protegerse de forma estricta.

• MFA obligatorio.
• Uso solo para tareas que lo requieran.
• Preferencia por roles temporales.
• Alertas por inicio de sesión inusual.
• Registro de llamadas API.
• Revisión periódica de permisos.
• Separación entre cuentas de administración y uso diario.

20.18 Errores frecuentes

• Creer que el proveedor protege todo: el cliente sigue configurando identidades, datos y accesos.
• Permisos excesivos: roles amplios aumentan impacto de una credencial comprometida.
• Almacenamiento público accidental: puede exponer datos sensibles.
• Secretos en imágenes o repositorios: facilitan robo de credenciales.
• Contenedores privilegiados sin necesidad: aumentan riesgo de escape o abuso.
• No activar logs cloud: dificulta investigación.
• Usar imágenes sin verificar: introduce vulnerabilidades o código no confiable.

20.19 Lista de verificación inicial

• Aplicar MFA en cuentas administrativas cloud.
• Revisar permisos y roles con mínimo privilegio.
• Separar subredes públicas y privadas.
• Bloquear almacenamiento público por defecto.
• Activar logs de auditoría y flujos de red.
• Usar imágenes base confiables y escaneadas.
• Evitar secretos en código, imágenes o variables expuestas.
• Restringir contenedores privilegiados.
• Aplicar políticas de red en contenedores y clústeres.
• Monitorear postura de seguridad continuamente.

20.20 Ideas clave para recordar

• La nube usa responsabilidad compartida: el cliente sigue teniendo tareas críticas.
• La identidad es un perímetro central en entornos cloud.
• Las redes virtuales deben segmentarse y registrarse.
• Las imágenes de contenedores deben ser mínimas, confiables y escaneadas.
• Los secretos nunca deben quedar expuestos en código o imágenes.
• La postura de seguridad debe revisarse de forma continua.

20.21 Conclusión

El hardening en nube, contenedores y virtualización requiere adaptar los principios defensivos a entornos dinámicos. Identidades, permisos, redes, imágenes, secretos y logs deben gestionarse como controles centrales.

En el próximo tema estudiaremos validación defensiva: escaneo, pruebas de configuración, auditorías y benchmarks CIS.