Tema 8
Autenticar correctamente a un usuario o servicio es solo el primer paso. El siguiente desafío es definir con precisión qué puede hacer esa identidad, sobre qué objetos, en qué contexto y con qué límites operativos.
Una vez que el sistema sabe quién es una identidad, debe decidir qué está autorizada a hacer. Ese proceso es la autorización. En bases de datos, una autorización deficiente suele ser tan peligrosa como una autenticación débil, porque permite que usuarios o servicios legítimos operen por encima de lo que realmente necesitan.
Los problemas de autorización aparecen de muchas formas: aplicaciones con privilegios administrativos, analistas que acceden a tablas completas cuando solo necesitan vistas parciales, cuentas técnicas reutilizadas para múltiples funciones y roles heredados que acumulan permisos con el tiempo. En todos esos casos, el daño potencial de un error o una intrusión se multiplica.
Diseñar un buen modelo de autorización no consiste solo en negar accesos. Consiste en alinear privilegios con funciones reales, mantener control sobre el alcance de cada cuenta y conservar una estructura que siga siendo entendible y gobernable cuando el sistema crece.
La autorización es el conjunto de reglas que determinan qué operaciones puede realizar una identidad autenticada sobre determinados objetos o recursos del motor. Estas reglas pueden aplicarse a nivel global, de base, de esquema, de tabla, de vista, de columna, de fila, de procedimiento o de capacidad administrativa.
En términos prácticos, la autorización responde preguntas como estas:
Los motores de base de datos suelen permitir otorgar permisos directamente a una cuenta o hacerlo a través de roles. Aunque ambos caminos son técnicamente válidos, su impacto en gobernanza es muy diferente.
Los permisos directos pueden ser útiles para casos excepcionales, pero si se vuelven la norma generan desorden, acumulación y poca trazabilidad. Los roles, en cambio, permiten estructurar el acceso por función y revisar más fácilmente si la política general sigue teniendo sentido.
Un modelo de autorización basado en roles suele ser más sostenible y auditable que uno apoyado en permisos distribuidos de manera informal.
| Aspecto | Permisos directos dispersos | Modelo basado en roles |
|---|---|---|
| Gobernanza | Difícil de entender y revisar | Más claro y estructurado |
| Escalabilidad | Se vuelve caótico al crecer | Permite reutilización y consistencia |
| Auditoría | Más compleja y fragmentada | Más simple de interpretar |
| Altas y bajas | Requiere ajustes puntuales frecuentes | Facilita asignación y revocación por función |
| Riesgo de acumulación | Muy alto | Menor si los roles se revisan periódicamente |
Los permisos granulares permiten limitar el acceso no solo por identidad, sino también por tipo de acción y por objeto concreto. Esto es esencial en seguridad de bases de datos porque no todas las identidades necesitan el mismo nivel de operación ni sobre el mismo conjunto de datos.
La granularidad puede expresarse de distintas maneras:
Cuanto más precisa sea la definición del acceso, menor será el daño potencial de un error, una mala práctica o un compromiso de credenciales.
En una plataforma de datos, la autorización puede definirse en distintos niveles simultáneamente. Comprender esos niveles ayuda a diseñar un modelo coherente.
El error frecuente es otorgar permisos de un nivel superior cuando en realidad el caso de uso solo requería acceso en uno mucho más limitado.
Una forma efectiva de diseñar autorización es partir de funciones reales del negocio y de la operación técnica. En lugar de pensar primero en usuarios individuales, conviene pensar en perfiles de acceso.
Ejemplos típicos de funciones pueden ser:
El sobredimensionamiento ocurre cuando una identidad recibe más privilegios de los que necesita. Es uno de los problemas más comunes y dañinos en entornos de bases de datos.
Entre sus consecuencias se encuentran:
Muchas veces el sobredimensionamiento nace por pragmatismo: "dar permisos de más para que funcione". El problema es que ese atajo suele volverse permanente.
Con el tiempo, los modelos de acceso tienden a degradarse si no se revisan. Aparecen permisos heredados, excepciones antiguas, cuentas con múltiples roles superpuestos y privilegios otorgados para resolver incidentes urgentes que nunca se retiran.
Este fenómeno se conoce a veces como deriva de privilegios. Sus señales típicas incluyen:
Sin revisiones periódicas, incluso un modelo inicialmente bien diseñado puede terminar siendo inconsistente y riesgoso.
No debe confundirse la administración del motor con el acceso al contenido de los datos. En algunos entornos, quien administra la plataforma necesita capacidades técnicas elevadas, pero no necesariamente requiere consultar información sensible en forma libre.
Separar ambos planos ayuda a reducir riesgo:
Cuando estos planos se mezclan sin control, un administrador técnico pasa a tener capacidad plena sobre información que quizá no necesita ver para cumplir su tarea.
La teoría se vuelve más clara cuando se la aplica a situaciones concretas.
Un buen modelo de autorización mejora la auditoría, porque hace más fácil interpretar la actividad. Si cada rol tiene una función clara, cualquier acción fuera de ese marco se vuelve más visible como anomalía.
Por el contrario, cuando una cuenta tiene permisos demasiado amplios, casi cualquier acción parece posible y por eso resulta más difícil distinguir el uso esperado del abuso.
Autorización y auditoría se refuerzan mutuamente:
Los permisos no deben considerarse permanentes por defecto. Cada cambio de rol, de aplicación, de entorno o de arquitectura puede volver obsoleta una autorización previamente razonable.
Una revisión madura del acceso suele contemplar:
Sin este proceso, el control de acceso se convierte lentamente en una colección de permisos heredados difícil de justificar.
Los fallos más repetidos en autorización suelen ser conceptualmente simples, pero con gran impacto práctico.
Un buen sistema de autorización transforma identidades verificadas en capacidades concretas, limitadas y alineadas con funciones reales. Cuando el control de acceso está bien diseñado, la base de datos resiste mejor errores, abuso interno y compromiso de credenciales.
En el próximo tema estudiaremos la seguridad a nivel de esquema, tablas, vistas, columnas y filas, donde la autorización se vuelve todavía más fina y cercana al dato concreto.