Tema 18

18. Seguridad en bases de datos en la nube y servicios administrados

Mover bases de datos a la nube o utilizar servicios administrados no elimina la necesidad de protegerlas. Cambia el modelo operativo, redistribuye responsabilidades y agrega nuevas capas de configuración, identidad y exposición que deben entenderse con claridad para no convertir la comodidad operativa en una nueva fuente de riesgo.

Objetivo Proteger bases de datos cloud sin depender ciegamente del proveedor
Enfoque Responsabilidad compartida, configuración y control de acceso
Resultado Reducir errores de exposición y gobierno en entornos administrados

18.1 Introducción

La nube ofrece ventajas claras para bases de datos: elasticidad, servicios administrados, automatización, alta disponibilidad integrada y menor carga sobre ciertos aspectos de infraestructura. Sin embargo, estas ventajas no implican que la seguridad quede resuelta por el simple hecho de usar un servicio cloud.

De hecho, muchas exposiciones graves en bases de datos en la nube se originan en configuraciones incorrectas, permisos excesivos, endpoints abiertos, snapshots mal compartidos, claves mal gobernadas o una comprensión incompleta del modelo de responsabilidad compartida.

El desafío principal es que la nube simplifica algunas tareas técnicas, pero agrega otras: gestionar identidades cloud, redes virtuales, políticas de acceso, servicios auxiliares, regiones, planos de control y automatizaciones que también deben protegerse. Por eso, la seguridad en entornos administrados exige tanto disciplina como entendimiento del servicio utilizado.

18.2 Qué cambia cuando la base está en la nube

En un entorno on-premise, la organización suele controlar directamente el servidor, la red, el almacenamiento y el motor. En la nube, parte de ese control pasa al proveedor, pero aparecen nuevas capas de configuración y de dependencia técnica.

Entre los cambios más relevantes se encuentran:

  • Uso de redes virtuales, grupos de seguridad y políticas cloud.
  • Mayor dependencia de identidades y permisos del proveedor.
  • Servicios administrados con opciones predeterminadas o automatizadas.
  • Snapshots, backups y réplicas integradas en el ecosistema cloud.
  • Operación distribuida entre consola, APIs, IaC y automatizaciones.
En la nube, la base de datos no es solo el motor. También es el conjunto de configuraciones, identidades, redes y servicios administrados que la hacen existir y operar.

18.3 Responsabilidad compartida

Uno de los conceptos centrales en seguridad cloud es la responsabilidad compartida. El proveedor protege ciertos componentes de la infraestructura y del servicio, pero el cliente sigue siendo responsable de muchas decisiones críticas sobre configuración, acceso, cifrado, monitoreo y uso del dato.

Responsabilidad típica del proveedor Responsabilidad típica del cliente
Infraestructura física y base del servicio Configuración lógica, acceso, redes y uso del servicio
Disponibilidad del plano administrado Definición de quién puede conectarse y con qué permisos
Algunas tareas de parcheo de plataforma Gestión de datos, claves, identidades y monitoreo

El error frecuente es asumir que "administrado" significa "completamente seguro". En realidad, solo desplaza parte del trabajo; no elimina la responsabilidad del cliente sobre el dato y su exposición.

18.4 Riesgos típicos en servicios administrados de bases de datos

La mayoría de los incidentes en bases de datos cloud no nacen en una falla extraordinaria del proveedor, sino en malas decisiones de configuración o de gobierno por parte del cliente.

  • Exposición del endpoint a internet sin necesidad real.
  • Grupos de seguridad o reglas de red demasiado amplias.
  • Políticas IAM excesivas para administrar o consultar el servicio.
  • Snapshots o backups compartidos sin control.
  • Uso inseguro de secretos y cadenas de conexión en aplicaciones.
  • Falta de monitoreo sobre el plano de control y los cambios de configuración.
En cloud, muchas brechas son configuracionales antes que técnicas. La pregunta crítica deja de ser solo "qué vulnerabilidad tiene el motor" y pasa a ser "qué exposición habilitó la propia configuración del servicio".

18.5 Identidades cloud e IAM

En entornos administrados, la seguridad de la base de datos depende en gran medida de cómo se gestionan identidades, roles y permisos en la plataforma cloud. El acceso al motor, a sus backups, a sus parámetros y a su ciclo de vida puede pasar por distintos niveles de autorización.

Por eso conviene controlar con cuidado:

  • Quién puede crear, modificar, restaurar o eliminar instancias.
  • Quién puede acceder a snapshots, backups o exportaciones.
  • Qué servicios automatizados tienen permisos sobre la base.
  • Qué roles humanos pueden operar en consola, API o IaC.

Un rol IAM excesivo puede ser tan peligroso como una cuenta administrativa sobredimensionada dentro del motor.

18.6 Redes virtuales y exposición del servicio

Uno de los controles más importantes en bases de datos cloud es decidir desde dónde será accesible la instancia. Aunque el servicio esté administrado, exponerlo innecesariamente a redes amplias o a internet multiplica el riesgo.

Las decisiones críticas suelen incluir:

  • Si la base será pública o privada.
  • Qué subredes y segmentos pueden alcanzarla.
  • Qué grupos de seguridad o listas de control permiten tráfico.
  • Cómo se conectan aplicaciones, bastiones, herramientas y administradores.

Una base de datos en la nube debe ser tratada como un activo interno de alta sensibilidad, no como un servicio que se publica por facilidad salvo que exista una necesidad técnicamente justificada y muy controlada.

18.7 Configuración segura del servicio administrado

Los servicios administrados suelen ofrecer múltiples parámetros y opciones de seguridad. Algunas vienen bien configuradas por defecto; otras no. Además, diferentes equipos pueden cambiar estas opciones desde consola o automatizaciones sin plena conciencia del impacto.

Conviene revisar especialmente:

  • Requerimiento de TLS en conexiones.
  • Cifrado en reposo y gestión de claves.
  • Backups automáticos, snapshots y retención.
  • Parámetros del motor expuestos desde el servicio.
  • Logs, auditoría y exportación de eventos a sistemas centrales.

La comodidad del servicio administrado no debe llevar a aceptar configuraciones por defecto sin validación explícita.

18.8 Backups, snapshots y copias en la nube

La nube facilita la creación y administración de snapshots y respaldos, pero eso también aumenta el riesgo de proliferación de copias poco gobernadas. Una instantánea compartida erróneamente o restaurada en un entorno inseguro puede exponer información crítica sin tocar la base productiva.

Desde la seguridad, conviene prestar atención a:

  • Quién puede crear y compartir snapshots.
  • Qué cifrado protege esas copias.
  • En qué regiones o cuentas se almacenan.
  • Cómo se audita su uso y restauración.

La facilidad operativa de la nube no reduce la sensibilidad de las copias. Solo hace más sencillo crearlas, moverlas y, si no hay gobierno, perder control sobre ellas.

18.9 Seguridad del plano de control

En servicios administrados, no solo importa proteger la conexión a la base. También importa proteger el plano de control: consola, APIs, automatizaciones e infraestructura como código que permiten crear, modificar, restaurar, replicar o eliminar instancias.

Un atacante con control sobre ese plano puede no necesitar entrar al motor. Puede cambiar configuraciones, abrir redes, restaurar snapshots, rotar secretos o generar nuevas instancias con datos sensibles.

En cloud, comprometer el plano de control puede ser tan grave como comprometer el motor de base de datos. A veces incluso más, porque permite cambiar toda la topología y persistencia del servicio.

18.10 Automatización e infraestructura como código

La automatización es una gran ventaja de la nube, pero también requiere disciplina. Las configuraciones inseguras pueden replicarse rápidamente en múltiples entornos si se incorporan a plantillas, pipelines o módulos reutilizables.

Las buenas prácticas en este punto incluyen:

  • Definir baselines seguras en plantillas y módulos.
  • Revisar cambios de infraestructura con criterio de seguridad.
  • Evitar secretos embebidos en definiciones de despliegue.
  • Versionar y auditar modificaciones del entorno.

La automatización bien diseñada mejora seguridad. La automatización sin revisión acelera errores de exposición a escala.

18.11 Monitoreo y trazabilidad en cloud

Los servicios administrados generan eventos tanto del motor como del plano de control. Para sostener seguridad real, ambos deben observarse. No alcanza con monitorear consultas si no se vigilan también cambios de configuración, restauraciones, ampliaciones de permisos o creación de snapshots.

Tipo de evento Por qué importa Ejemplo de riesgo
Cambios de red Pueden exponer la base a nuevos orígenes Apertura accidental a internet
Restauración de snapshots Crea nuevas copias del dato Uso no autorizado de backups
Modificación de parámetros Altera el perfil de seguridad del motor Desactivación de TLS o logging
Cambios en IAM Expanden control sobre la base o sus copias Escalada de privilegios

18.12 Multi-cuenta, multi-región y gobierno

En arquitecturas cloud maduras, las bases pueden distribuirse entre varias cuentas, proyectos, suscripciones o regiones. Esta separación puede mejorar aislamiento y resiliencia, pero también complejiza el gobierno de seguridad.

Los principales desafíos aparecen en:

  • Homogeneidad de configuraciones seguras entre entornos.
  • Control de replicación y copias entre regiones.
  • Consistencia en políticas IAM y rotación de secretos.
  • Visibilidad centralizada sobre cambios y eventos distribuidos.

Cuanto más distribuido es el entorno, más importante se vuelve la estandarización y el control central del riesgo.

18.13 Errores frecuentes en seguridad de bases de datos cloud

  • Confiar en que el servicio administrado ya resuelve toda la seguridad.
  • Exponer endpoints públicamente por facilidad de conexión.
  • Otorgar permisos IAM demasiado amplios para operar o automatizar.
  • Compartir snapshots o restaurar copias sin suficiente control.
  • No monitorear el plano de control ni los cambios de configuración.
  • Replicar configuraciones inseguras mediante infraestructura como código.
El error más común en la nube no es técnico en el sentido clásico. Es de modelo mental: asumir que delegar infraestructura equivale a delegar responsabilidad sobre el riesgo del dato.

18.14 Qué debes recordar de este tema

  • La nube cambia la operación de la base, pero no elimina la responsabilidad del cliente sobre configuración, acceso y protección del dato.
  • El modelo de responsabilidad compartida debe entenderse con precisión para no dejar vacíos de seguridad.
  • IAM, redes virtuales, snapshots y plano de control son piezas críticas de la seguridad cloud.
  • Los servicios administrados simplifican tareas, pero también exigen gobierno sobre configuraciones y automatizaciones.
  • Una base en la nube sigue necesitando mínimo privilegio, cifrado, monitoreo y control de exposición igual que cualquier otra plataforma crítica.

18.15 Conclusión

La seguridad en bases de datos cloud exige combinar comprensión del servicio administrado con disciplina sobre configuración, identidades, redes y copias. Cuando ese gobierno existe, la nube puede aportar resiliencia y eficiencia. Cuando no existe, la facilidad operativa puede transformarse en exposición amplificada.

En el próximo tema estudiaremos la seguridad en bases NoSQL, almacenes distribuidos y nuevos modelos de datos, donde cambian las estructuras, los patrones de acceso y también muchas de las amenazas y controles relevantes.