Tema 3
La seguridad de una base de datos no depende solo de contraseñas y permisos. Depende también de cómo está diseñada la arquitectura, qué componentes la rodean, por dónde puede ser alcanzada y qué caminos podrían usar atacantes o errores operativos para comprometerla.
Una base de datos rara vez existe aislada. Forma parte de una arquitectura compuesta por aplicaciones, APIs, servicios de autenticación, sistemas operativos, redes, herramientas de administración, procesos de integración, respaldos y, en muchos casos, componentes en la nube. Cada uno de esos elementos agrega funcionalidad, pero también expone nuevas rutas de acceso y nuevas posibilidades de falla.
Por eso, para proteger correctamente una plataforma de datos no basta con revisar el motor. Hay que comprender su arquitectura completa. Una base puede estar bien configurada internamente y aun así quedar expuesta por una aplicación vulnerable, una consola administrativa mal publicada, una réplica abierta o un flujo de exportación sin controles.
Analizar la arquitectura permite responder preguntas fundamentales: desde dónde se conectan los usuarios, cómo llegan las aplicaciones, qué servicios hablan con la base, qué relaciones de confianza existen, qué dependencias críticas sostienen la operación y dónde aparecen puntos de exposición innecesarios.
La arquitectura de bases de datos es la forma en que se organizan los componentes técnicos y lógicos que almacenan, procesan, replican, respaldan y exponen datos. Incluye tanto la estructura interna del motor como el ecosistema en el que opera.
En términos prácticos, la arquitectura abarca:
No todas las plataformas exponen el mismo nivel de riesgo. La arquitectura elegida influye directamente en la superficie de ataque y en la complejidad de los controles.
| Arquitectura | Características | Riesgos típicos |
|---|---|---|
| Monolítica local | Aplicación y base en un entorno reducido o mismo servidor | Poca separación de funciones, dependencia de un único host |
| Cliente-servidor tradicional | Usuarios o aplicaciones se conectan a un servidor central | Exposición de puertos, credenciales en clientes, acceso amplio |
| Tres capas | Presentación, lógica de negocio y base separadas | Errores en APIs, abuso entre capas, cuentas técnicas excesivas |
| Distribuida o replicada | Múltiples nodos, replicación, alta disponibilidad | Exposición de réplicas, sincronización insegura, complejidad operativa |
| Cloud administrada | Servicio gestionado por proveedor con accesos remotos y automatización | Mala configuración de red, secretos expuestos, dependencia del plano de control |
La superficie de ataque es el conjunto de puntos desde los cuales un actor podría intentar acceder, alterar, extraer o interrumpir la base de datos. Identificarla es esencial porque muchas brechas no entran por el punto más obvio.
En una plataforma de datos típica, esa superficie puede incluir:
Cuantos más caminos de acceso existan y menos control haya sobre ellos, más amplia será la superficie de ataque y más difícil será defenderla con consistencia.
No todos los riesgos nacen de conexiones directas al motor. De hecho, en muchas organizaciones la base no es accesible al usuario final, pero sí es alcanzable a través de componentes intermedios.
Los accesos indirectos son especialmente relevantes porque una aplicación insegura puede transformar una base internamente aislada en un objetivo alcanzable. Si la lógica de negocio no valida entradas, usa cuentas con privilegios excesivos o expone funciones administrativas, la protección perimetral pierde efectividad.
Una arquitectura madura no ubica todos sus componentes en el mismo nivel de confianza. Separar zonas reduce el alcance de un incidente y obliga a controlar mejor las comunicaciones entre capas.
En un diseño razonable suelen existir zonas como:
Si la base de datos comparte red o nivel de confianza con aplicaciones expuestas, estaciones de trabajo o herramientas de terceros, la arquitectura se vuelve mucho más frágil. La segmentación no elimina el riesgo, pero limita la propagación y mejora la capacidad de control.
Uno de los caminos más frecuentes hacia la base de datos es la propia aplicación. El usuario no necesita hablar con el motor si puede abusar del software que sí tiene permiso para hacerlo.
Entre los vectores más comunes se encuentran:
La infraestructura también introduce riesgo. No alcanza con revisar tablas y roles si el servidor, la red o los servicios de soporte presentan debilidades evidentes.
Muchas intrusiones no comienzan en la base, sino en el host o en la cuenta del operador. Una vez que el atacante obtiene posición sobre la infraestructura, la base de datos se convierte en un objetivo natural.
Una plataforma de datos suele tener copias. Réplicas de lectura, snapshots, backups, exportaciones para análisis y dumps para desarrollo son útiles operativamente, pero también multiplican el número de lugares donde existe la información.
Estos activos derivados presentan riesgos característicos:
Desde el punto de vista del atacante, una copia menos protegida puede ser más atractiva que la base principal. Desde el punto de vista defensivo, el contenido conserva su sensibilidad aunque cambie el formato o el lugar donde reside.
La arquitectura moderna de datos rara vez termina en el perímetro de la organización. Intervienen proveedores cloud, servicios SaaS, plataformas de integración, herramientas de observabilidad, sistemas de ticketing, conectores ETL y consultores externos.
| Dependencia | Uso habitual | Riesgo asociado |
|---|---|---|
| Proveedor cloud | Hosting, backups, replicación, gestión | Errores de configuración, exposición por IAM o red |
| Herramientas ETL | Movimientos y transformaciones de datos | Credenciales embebidas, exceso de permisos |
| BI y analítica | Consultas, dashboards, exportaciones | Extracción masiva o acceso indirecto no controlado |
| Soporte externo | Mantenimiento o administración puntual | Accesos temporales mal retirados o poco auditados |
| APIs de terceros | Integración funcional con otros sistemas | Intercambio inseguro de datos o validación débil |
Agregar componentes puede mejorar escalabilidad, disponibilidad y flexibilidad, pero también aumenta la complejidad. Y la complejidad, si no se gobierna bien, suele convertirse en riesgo.
Una arquitectura compleja presenta problemas como estos:
La complejidad no siempre es evitable, pero sí debe ser comprendida y administrada. Una arquitectura segura no es necesariamente la más simple, pero sí la más entendida y gobernada.
Los conceptos anteriores se vuelven más claros cuando se los lleva a escenarios concretos.
Existen patrones que suelen repetirse en plataformas con exposición elevada o controles poco maduros.
Estas señales no implican necesariamente una brecha en curso, pero sí revelan una arquitectura que facilita errores, abuso de confianza y movimientos laterales.
Reducir la superficie de ataque no significa dejar la plataforma inutilizable. Significa exponer solo lo necesario y bajo condiciones estrictas.
Comprender la arquitectura de una plataforma de datos es indispensable para defenderla. Solo cuando se identifican sus componentes, flujos y puntos de exposición es posible entender por dónde puede ser comprometida y qué controles tienen mayor prioridad.
En el próximo tema estudiaremos las amenazas más comunes sobre bases de datos, en especial SQL Injection, abuso de privilegios, fuga de información y manipulación maliciosa de datos.