Tema 7
Antes de decidir qué puede hacer cada usuario o servicio en una base de datos, es necesario resolver algo más básico: quién es realmente esa identidad, cómo se autentica y bajo qué reglas se administran sus credenciales a lo largo del tiempo.
La autenticación es la puerta de entrada a la base de datos. Si esa puerta está mal diseñada, poco importa cuán buenos sean los controles posteriores. Un atacante con una credencial válida o una cuenta mal gestionada puede ingresar al entorno de datos sin necesidad de explotar vulnerabilidades más complejas.
En muchas organizaciones, los problemas de seguridad vinculados a identidades no aparecen por tecnologías sofisticadas sino por prácticas deficientes: cuentas compartidas, contraseñas débiles, usuarios que no se desactivan, secretos expuestos en scripts, cuentas de servicio sin rotación o integración incompleta con directorios corporativos.
Por eso, gestionar identidades correctamente no es una tarea administrativa menor. Es una capa esencial de seguridad que condiciona auditoría, autorización, trazabilidad y capacidad de respuesta ante incidentes.
Una identidad es cualquier entidad reconocida por el sistema como sujeto de autenticación y acceso. Puede representar a una persona, una aplicación, un proceso automático, un servicio técnico o incluso un componente externo integrado.
En entornos de datos es habitual encontrar varios tipos de identidades:
Autenticación y autorización son conceptos relacionados, pero distintos. Confundirlos lleva a errores de diseño.
Una autenticación fuerte no compensa autorizaciones excesivas, y permisos muy bien diseñados no sirven si cualquiera puede hacerse pasar por una cuenta legítima. Por eso, primero debe resolverse con seguridad la identidad y luego asignarse privilegios acordes a su función.
Los motores de base de datos y sus entornos asociados permiten distintos mecanismos de autenticación. La elección depende del contexto, del nivel de integración con otros sistemas y de la criticidad del acceso.
| Tipo | Descripción | Riesgos o consideraciones |
|---|---|---|
| Usuario y contraseña local | Credenciales administradas directamente por el motor | Mayor carga de gestión, riesgo de mala rotación |
| Directorio centralizado | Integración con LDAP, Active Directory u otro IAM | Mejor gobierno, pero dependencia del sistema central |
| Certificados o claves | Autenticación basada en material criptográfico | Requiere buena gestión de claves y ciclo de vida |
| Tokens o identidades federadas | Acceso delegado o integrado con proveedores externos | Complejidad adicional y dependencia del proveedor |
| Mecanismos mixtos | Combinación según tipo de usuario o entorno | Riesgo de inconsistencias si no se gobierna bien |
No todas las cuentas deben gestionarse del mismo modo. Una cuenta usada por una persona tiene necesidades distintas a una cuenta usada por una aplicación o un proceso automatizado.
Las cuentas humanas suelen requerir identificación individual, trazabilidad nominal, controles de acceso interactivo y a menudo autenticación reforzada. Las cuentas técnicas, en cambio, necesitan ser estables, no interactivas y estrictamente limitadas al proceso que las usa.
Mezclar ambos tipos de cuenta genera problemas de auditoría y seguridad. Una cuenta compartida entre operadores o reutilizada por una aplicación pierde contexto: ya no es posible saber con claridad quién actuó ni bajo qué justificación.
Las políticas de contraseñas buscan reducir la probabilidad de acceso indebido mediante credenciales débiles, reutilizadas, predecibles o expuestas. Sin embargo, una política útil no se mide por la cantidad de reglas arbitrarias, sino por su capacidad de producir credenciales realmente más seguras y operables.
Una política madura suele contemplar:
En el contexto de bases de datos, las contraseñas adquieren una sensibilidad especial porque suelen habilitar acceso directo a información crítica o a funciones administrativas.
Las credenciales de aplicaciones y automatizaciones merecen especial atención porque, al no ser usadas directamente por personas, muchas veces quedan olvidadas durante largos períodos.
La seguridad de las identidades no termina en la creación de la cuenta. Debe considerarse todo su ciclo de vida: alta, uso, cambio, revisión y baja.
Un esquema de gestión madura responde preguntas como estas:
Muchas cuentas peligrosas no nacen mal, sino que permanecen activas demasiado tiempo o sobreviven a cambios de contexto sin revisión.
Los procesos de alta, baja y modificación son una de las bases del gobierno de accesos. Si son informales, lentos o poco auditables, tienden a proliferar accesos heredados y excepciones permanentes.
| Evento | Riesgo si se gestiona mal | Control esperado |
|---|---|---|
| Alta | Privilegios excesivos desde el inicio | Aprobación, justificación y rol mínimo |
| Modificación | Acumulación de permisos no revisados | Reevaluación del acceso por cambio de función |
| Baja | Cuentas huérfanas o persistentes | Revocación rápida y verificable |
| Suspensión temporal | Reactivación sin contexto ni control | Plazo definido y revisión posterior |
| Emergencia | Accesos excepcionales permanentes | Trazabilidad, limitación y cierre posterior |
Cuando es posible, integrar la autenticación con servicios centralizados de identidad suele mejorar la gobernanza. Permite aplicar políticas comunes, desactivar accesos con más rapidez y alinear la base de datos con el ecosistema corporativo.
Sin embargo, esta integración no elimina por sí sola el riesgo. Si el directorio central está mal gobernado o si se otorgan permisos excesivos una vez autenticado el usuario, la mejora es parcial. Además, una dependencia externa puede introducir nuevos puntos de falla o complejidad operativa.
La clave está en usar la centralización para fortalecer identidad, no para relajar controles locales.
No todos los accesos merecen el mismo nivel de verificación. Las tareas administrativas, el acceso remoto, la gestión de cuentas privilegiadas y las operaciones sobre datos altamente sensibles suelen requerir mecanismos reforzados.
Según el entorno, esto puede incluir:
La autenticación reforzada no debe aplicarse solo porque "es más segura", sino donde el impacto potencial justifica la capa adicional de control.
Uno de los mayores riesgos en bases de datos modernas está en las credenciales que no usan directamente personas, sino aplicaciones, pipelines, tareas programadas o integraciones. Esas credenciales suelen terminar en archivos de configuración, variables de entorno, repositorios o scripts con protección insuficiente.
Una gestión madura de secretos debería contemplar:
Hay síntomas bastante claros de que la gestión de identidades y autenticación está lejos de un nivel maduro.
Estas señales indican que el problema no es solo técnico, sino también de gobierno y disciplina operativa.
Muchas organizaciones creen tener una política segura cuando en realidad aplican reglas incómodas pero poco efectivas.
Una política útil debe equilibrar seguridad, trazabilidad y operabilidad. Si no, se vuelve una formalidad que los usuarios intentan eludir.
Gestionar identidades y autenticación de forma correcta es un requisito básico para cualquier estrategia seria de seguridad en bases de datos. Sin control sobre quién accede y cómo lo hace, el resto de los mecanismos defensivos queda debilitado desde el inicio.
En el próximo tema estudiaremos la autorización, los roles, los permisos granulares y el control de acceso, es decir, cómo traducir identidades verificadas en privilegios concretos y bien acotados.