Seguridad en la nube: mejores prácticas (guía 2025)

La seguridad en la nube no es “un producto”, es un conjunto de decisiones repetibles: identidad, datos, red, aplicaciones y operación. Da igual si usas AWS, Azure o Google Cloud: los incidentes más graves suelen venir de permisos excesivos, secretos expuestos, falta de monitorización o copias de seguridad insuficientes.

El modelo mental correcto: responsabilidad compartida

Los proveedores aseguran “la nube” (data centers, hardware, servicios base) y tú aseguras “lo que pones dentro”: usuarios, configuraciones, datos, apps y accesos. En la práctica:

• Tú: IAM, políticas, cifrado, redes, configuración, compliance, backups, hardening, respuesta a incidentes.
• Proveedor: seguridad física, infraestructura, disponibilidad del servicio, parches del plano gestionado (según servicio).

1) Identidad y acceso (IAM): la base de todo

Si lo clavas en IAM, reduces un porcentaje enorme del riesgo. Estas son las reglas de oro:

• MFA obligatorio en cuentas privilegiadas (admin/root) y accesos críticos.
• Principio de mínimo privilegio: permisos justos, no “*”.
• Separación de roles: admin, seguridad, dev, lectura, CI/CD… cada uno con su ámbito.
• Acceso temporal: roles asumibles (STS), Just-In-Time para tareas sensibles.
• Revisión periódica: usuarios inactivos, llaves antiguas, permisos heredados.

Errores típicos en IAM

• Llaves de acceso permanentes en repositorios o en el portátil sin rotación.
• Políticas “admin” para desbloquear rápido un problema (y quedarse así meses).
• Sin logging de eventos de IAM (luego no sabes qué pasó).

2) Cifrado de datos: en tránsito y en reposo

Para datos en tránsito, el estándar práctico es TLS 1.2+ (ideal 1.3 cuando sea posible). Para datos en reposo, la referencia habitual es AES-256. Pero lo más importante no es “cifrar”, sino cómo gestionas las claves.

• En tránsito: HTTPS, mTLS si hay servicios internos críticos, y deshabilitar protocolos antiguos.
• En reposo: cifrado por defecto en almacenamiento/BD/objetos.
• Claves: rotación, separación por entorno (prod/dev), y permisos mínimos para usar la clave.

Secretos y credenciales

Contraseñas, API keys, tokens, certificados: todo debe vivir en un gestor de secretos o, como mínimo, fuera del código y con acceso controlado.

• No guardes secretos en variables de entorno “eternas” sin rotación.
• Evita “copiar/pegar” credenciales en documentación pública o tickets.
• Audita qué identidades acceden a secretos y cuándo.

3) Seguridad de red: segmentación y exposición mínima

El objetivo no es “cerrar todo”, sino exponer lo mínimo necesario y segmentar para que un fallo no se convierta en desastre.

• Segmenta: subredes públicas/privadas, entornos separados (dev/stage/prod).
• Firewall restrictivo: solo puertos necesarios, solo orígenes necesarios.
• Acceso privado a servicios críticos (VPN, enlaces privados, endpoints internos).
• Administración: evita SSH abierto a Internet; usa bastion, VPN o acceso gestionado.

4) WAF y protección DDoS: protege la puerta de entrada

Si publicas APIs o web, necesitas capas anti-abuso:

• WAF: reglas contra inyecciones, bots, scraping agresivo y patrones maliciosos.
• DDoS: protección específica, rate limits, y arquitectura con escalado.
• CDN: reduce carga, mejora rendimiento y absorbe tráfico (y ataques) mejor.

5) Logging, monitorización y auditoría: “verlo todo”

Sin telemetría, no hay seguridad: hay fe. Debes registrar:

• Eventos de auditoría (quién hizo qué y cuándo): por ejemplo, CloudTrail en AWS.
• Logs de red: flujos, firewalls, WAF.
• Logs de aplicación: auth, errores, acciones sensibles.
• Alertas: intentos de login sospechosos, cambios de políticas, creación de llaves, puertos abiertos.

Consejo clave

Centraliza logs (SIEM o stack de observabilidad), define retención, y crea alertas mínimas: cambios IAM, uso de root, deshabilitar logging, y accesos anómalos.

6) Hardening, parches y configuración segura

Muchos ataques aprovechan lo básico: sistemas sin parches, servicios con configuraciones por defecto o paneles expuestos.

• Actualiza imágenes base y dependencias (no solo el sistema operativo).
• Deshabilita servicios innecesarios y cierra puertos.
• Evita paneles/administraciones públicas sin protección fuerte.

7) Backups, recuperación y defensa frente a ransomware

La seguridad real incluye poder recuperarte. Un buen backup no es “tener una copia”, es: prueba + aislamiento + inmutabilidad.

• 3-2-1: varias copias, distintos soportes/ubicaciones.
• Inmutabilidad o WORM cuando sea viable.
• Pruebas de restauración programadas (si no, no cuenta).
• DR: RPO/RTO definidos y ensayados.

8) Checklist rápido (para revisar hoy)

• ✅ MFA en admin/root + acceso privilegiado.
• ✅ Sin llaves antiguas; rotación y mínimos privilegios.
• ✅ Cifrado en reposo y en tránsito activado.
• ✅ Secretos fuera del código (y con auditoría).
• ✅ Firewall/SG/NACL: puertos mínimos, sin exposición accidental.
• ✅ WAF + rate limits en endpoints públicos.
• ✅ Logging centralizado + alertas básicas de seguridad.
• ✅ Backups probados y, si es posible, inmutables.

Conclusión

La ciberseguridad en la nube no se arregla con “un botón”. Se logra con disciplina: IAM fuerte, cifrado, mínima exposición, detección y recuperación. Si aplicas estas prácticas y las conviertes en estándar, reduces drásticamente incidentes y mejoras compliance sin frenar al negocio.