permisos

La gestión de permisos en SQL Server es un aspecto fundamental para garantizar la seguridad y el acceso controlado a los datos. En entornos empresariales, lo más eficiente es utilizar grupos de Active Directory (AD) junto con roles en SQL Server para simplificar la administración y reducir la carga de trabajo asociada a la asignación individual de permisos.

Además, con la evolución de la gestión de identidades en la nube, Microsoft Entra ID (antes Azure AD) nos da la posibilidad de utilizar grupos de seguridad automáticos, lo que facilita aún más la administración de accesos en SQL Server y Azure SQL Database. En este artículo, vamos a ver como cómo combinar estas tecnologías para una gestión eficiente y segura de los permisos en SQL Server.

Uso de grupos de Active Directory en SQL Server

Cuando gestionamos el acceso a una base de datos SQL en un entorno corporativo, es una mala práctica asignar permisos directamente a usuarios individuales. En su lugar, la mejor estrategia es utilizar grupos de seguridad de Active Directory.

¿Por qué? Porque la asignación de permisos a nivel usuario no solo es más costosa sino que también más propensa a errores. Una vez que has asignado y validado los permisos a un grupo ya solo deberás añadir o quitar usuarios a ese grupo. Esto facilita enormemente tanto el alta como la baja de usuarios y permite reutilizar los grupos por los distintos servidores SQL Server de la empresa.

Creación de grupos de AD

Para una gestión correcta se pueden crear diferentes grupos en Active Directory, como por ejemplo:

• DB_Admins: Administradores de la base de datos.
• DB_ReadOnly: Usuarios con solo lectura.
• DB_Editors: Usuarios con permisos de modificación.
• DB_Backups: Grupo con permisos para realizar copias de seguridad.

Estos grupos están muy simplificados y seguramente en tu entorno empresarial debas crear bastantes más. Aquí no hay una solución correcta para todas las empresas y dependerá de tus necesidades, hay quien crea los grupos por departamento, servicio, servidor o una combinación de estos factores. Sin embargo, una de las buenas prácticas que he aplicado en estos ejemplos es seguir una nomenclatura estandarizada. Si te fijas, querido lector, todos mis grupos empiezan por DB_ lo que hace más sencillo localizarlos en el directorio activo y, de un simple vistazo, saber su finalidad. Te recomiendo combinar una nomenclatura estándar con el uso de unidades organizativas de Active Directory.

Asignación de permisos a los grupos de AD en SQL Server

Una vez creados los grupos en AD, podemos agregarlos a SQL Server y asignarles roles adecuados.

USE [master]
CREATE LOGIN [DOMAIN\DB_ReadOnly] FROM WINDOWS;
USE [MiBaseDeDatos]
CREATE USER [DB_ReadOnly] FOR LOGIN [DOMAIN\DB_ReadOnly];
ALTER ROLE db_datareader ADD MEMBER [DB_ReadOnly];

De este modo, cualquier usuario añadido al grupo de AD DB_ReadOnly tendrá acceso de solo lectura a la base de datos sin necesidad de configurar permisos individualmente en SQL Server.

Mantenimiento de accesos

La ventaja de este enfoque es que los administradores pueden gestionar accesos desde Active Directory sin necesidad de tocar SQL Server. Por ejemplo, si un empleado cambia de departamento y ya no debe acceder a la base de datos, basta con eliminarlo del grupo de AD correspondiente y no hay que tocar nada en los servidores SQL Server. Además, estos grupos también pueden llevar asociados otros permisos a nivel recursos de red como directorios compartidos o acceso a equipos.

Gestión de permisos con roles de SQL Server

SQL Server proporciona roles que permiten agrupar permisos y facilitar la administración. Podríamos decir que es el equivalente a los grupos de AD pero dentro de SQL Server. La particularidad de estos roles es que pueden ser de dos tipos, a nivel de servidor o a nivel de base de datos. 

Los roles de servidor permiten asignar permisos globales dentro de SQL Server que afecten a tareas relacionadas con la instancia como sysadmin que da acceso total, securityadmin que permite gestionar accesos y permisos, dbcreator que permite crear y modificar bases de datos o public que es el rol básico asignado a todos los logins y permite la conexión a la instancia. Un ejemplo de asignación de un grupo de AD a un rol de servidor:

ALTER SERVER ROLE sysadmin ADD MEMBER [DOMAIN\DB_Admins];

Los roles a nivel de base de datos, como su propio nombre indica, se crean dentro de cada base de datos. Podemos crear nuestros propios roles o usar los roles predefinidos. Estos roles predefinidos son los que trae ya la base de datos y gestionan los permisos básicos. Tenemos db_owner para otorgar control total sobre la base de datos, db_datareader que permite leer los datos, db_datawriter que permite insertar, actualizar y eliminar datos y db_ddladmin que otorga la capacidad de modificar esquemas y objetos. 

Ejemplo de asignación de un grupo de AD a un rol de base de datos:

ALTER ROLE db_datareader ADD MEMBER [DB_ReadOnly];

Además de los roles predefinidos, podemos crear roles personalizados para necesidades específicas. Es muy común, por ejemplo, necesitar los accesos solo para determinados esquemas y no toda la base de datos y, en ese caso ya no podremos usar roles predefinidos. Para crear un rol personalizado, asignar permisos y añadir miembros usaremos:

CREATE ROLE db_reporter; /*crear rol*/
GRANT SELECT ON SCHEMA::Sales TO db_reporter; /*asignar permisos*/
ALTER ROLE db_reporter ADD MEMBER [DB_Reports];-/*añadir miembros*/

Grupos de seguridad automáticos en Entra ID

No quería cerrar este artículo sin hablar de los grupos de Entra ID (Azure Active Directory)

que básicamente es el equivalente a Active Directory en la nube de Azure. Igual que en Active directory en Entra ID vamos a poder crear grupos para asignar a nuestros usuarios y que puedan iniciar sesión en Azure SQL y Azure SQL Database además de en los SQL Server locales gracias a la integración con Azure ARC. 

Una de las ventajas que ha introducido Entra ID son los grupos de seguridad dinámicos y automáticos, lo que permite gestionar accesos sin intervención manual. Estos grupos pueden usarse para SQL Server y Azure SQL Database como hemos vistos antes y, especialmente, en entornos híbridos donde se combinan identidades locales y en la nube.

Creación de grupos dinámicos en Entra ID

Desde el portal de Entra ID, se puede configurar un grupo dinámico basado en reglas. Realmente es como un grupo normal solo que los miembros se van a añadir en base a unas reglas que definamos sobre sus propiedades. Por ejemplo, para asignar automáticamente usuarios al grupo SQL_ReadOnly si pertenecen al departamento de Finanzas:

1. Iremos a Entra ID > Grupos y seleccionaremos Nuevo grupo.
2. En “Tipo de grupo” elegiremos “Seguridad”
3. En “Asignación de miembros” marcaremos la opción “Asignación dinámica de usuarios”.
4. Aquí ya podremos definir nuestra regla, en este caso “user.department -eq «Finance»”
5. Por último podremos hacer ya la asignación del grupo de Entra ID a SQL Server.

En Azure SQL Managed Instance o bases de datos en Azure, podemos usar Entra ID para autenticación y gestión de permisos:

CREATE USER [SQL_ReadOnly] FROM EXTERNAL PROVIDER;
ALTER ROLE db_datareader ADD MEMBER [SQL_ReadOnly];

Esto permite que los usuarios asignados automáticamente al grupo SQL_ReadOnly en Entra ID obtengan acceso sin intervención manual.

Ventajas de este enfoque

Como hemos visto antes, administrar permisos desde Active Directory reduce la complejidad de SQL Server y evita errores humanos al configurar accesos manualmente. Si ya lo sincronizamos con Entra ID nos permite una centralización total de la seguridad. Si hay cambios en la organización, basta con modificar los grupos en AD o Entra ID sin necesidad de tocar SQL Server. A mayores, el acceso se gestiona de manera consistente y auditable desde un único punto de control lo que minimiza riesgos de accesos indebidos.

Además con Entra ID, los permisos pueden gestionarse tanto para SQL Server on-premises como para Azure SQL, facilitando la migración a la nube y otorgando al usuario un inicio de sesión único (single sign-on) que le hará las cosas mucho más sencillas.

Conclusión

El uso de grupos de Active Directory y roles de SQL Server proporciona una forma eficiente de gestionar permisos en bases de datos. La integración con Entra ID y sus grupos de seguridad dinámicos añade una capa adicional de automatización y control, ideal para entornos híbridos o en la nube. Si implementamos estas estrategias, podemos lograr una administración más segura, flexible y escalable, reduciendo la carga administrativa y mejorando el control de accesos a nuestros datos en SQL Server.

Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!