Riesgos de la seguridad en la nube
Casi nunca en el proveedor. Está en el reparto de responsabilidades que nadie leyó: un bucket abierto, una credencial con más permisos de los necesarios, un respaldo que existía pero nunca se probó restaurar.
Servicios de seguridad en la nube
- Revisión de configuración contra buenas prácticas del proveedor.
- Gestión de identidades y permisos, que es donde se concentra el riesgo.
- Plan de continuidad, incluido probar que la restauración funciona.
- Monitoreo continuo, integrado al centro de operaciones.
Seguridad en la nube e ISO 27001
La revisión de 2022 de ISO 27001 agregó controles específicos para servicios en la nube. Si estás en proceso de certificación, este frente aparece sí o sí.
Seguridad en la nube: el modelo de responsabilidad compartida
Es el concepto que explica la mayoría de los incidentes en la nube, y el que casi nadie revisa antes de migrar. Tu proveedor de nube responde por la seguridad de la nube. Tú respondes por la seguridad en la nube.
| Responde el proveedor | Respondes tú |
|---|---|
| Los centros de datos y el hardware | Quién tiene acceso y con qué permisos |
| La red física y la virtualización | Cómo configuras los servicios que contratas |
| Que el servicio esté disponible | Tus datos, y si están cifrados |
| Parchar su propia plataforma | Parchar lo que tú instalas encima |
| Tus copias de seguridad y poder restaurarlas |
La consecuencia práctica: cuando se filtra información desde un almacenamiento en la nube mal configurado, el proveedor cumplió su parte. La configuración era tuya. Y la proporción cambia según el tipo de servicio: mientras más gestionado sea lo que contratas, menos superficie te queda, aunque los accesos y los datos son siempre tuyos.
Dónde falla la seguridad en la nube
Los incidentes rara vez vienen de que alguien rompió la nube del proveedor. Vienen de una lista corta y repetida:
- Almacenamiento abierto a internet. Un contenedor de archivos que quedó público mientras se hacía una prueba y nadie volvió a cerrarlo.
- Permisos de más. Cuentas y servicios con privilegios amplios porque era más rápido que definir el permiso exacto. Cuando una de esas cuentas se compromete, el alcance es total.
- Llaves de acceso en el lugar equivocado. Credenciales dentro del código, en un repositorio, o en un archivo de configuración que se subió sin querer.
- Sin autenticación de varios pasos en las cuentas de administración. Es el control que más incidentes evita y el que más se posterga.
- Nadie mira los registros. La nube los genera. Que alguien los revise es otra decisión, y suele quedar pendiente.
- Servicios que nadie recuerda. Máquinas encendidas de un proyecto que terminó, sin parchar y sin dueño.
Ninguno de esos seis exige un atacante sofisticado. Todos se cierran con configuración y revisión periódica, y por eso el análisis de vulnerabilidades aplica igual a lo que corre en la nube.
Nube privada, pública o híbrida
La decisión suele venir dada por regulación o por lo que ya existe, y cada opción mueve el trabajo de seguridad a un lugar distinto.
- Pública. Infraestructura compartida de un proveedor grande. La seguridad se juega casi toda en configuración e identidad.
- Privada. Infraestructura dedicada. Más control y también más trabajo propio: parches, respaldos y disponibilidad vuelven a ser tuyos.
- Híbrida. Parte en cada una, que es lo más común en empresas con sistemas heredados. El riesgo se concentra en la conexión entre las dos y en tener dos formas distintas de dar accesos.
En un esquema híbrido el error frecuente es proteger bien cada lado y dejar la unión sin vigilancia. Ahí es donde correlacionar señales de varias fuentes deja de ser un lujo.
Qué pasa después
Una configuración segura hoy no lo sigue siendo en seis meses: cambian los servicios, los permisos y quién tiene acceso. Después de la revisión inicial viene el monitoreo continuo de esos cambios, integrado al centro de operaciones.
Preguntas frecuentes sobre seguridad en la nube
¿Qué es la seguridad en la nube?
El conjunto de controles que protegen lo que corre en infraestructura de terceros. Cambia respecto al centro de datos propio porque la responsabilidad se reparte: el proveedor asegura la infraestructura y tú aseguras lo que pones encima. Confundir ese límite es de donde salen la mayoría de los incidentes.
¿Qué es el modelo de responsabilidad compartida?
El acuerdo, explícito en el contrato de cada proveedor, sobre qué asegura cada parte. El proveedor responde por la infraestructura física y la virtualización; el cliente por las configuraciones, los accesos y los datos. Casi ningún incidente en la nube es culpa del proveedor.
¿Se puede evitar depender de un solo proveedor?
Se puede reducir la dependencia diseñando para portabilidad, pero cuesta. La decisión honesta es elegir a conciencia cuánta dependencia se acepta a cambio de cuánta velocidad, y dejarlo escrito.