Gobernanza de datos: control de accesos con GRANT en SQL

João Barros 05 de July de 2026 5 min de lectura

Controlar quién puede leer y modificar cada tabla es uno de los pilares de la gobernanza de datos. El principio de privilegio mínimo dice que cada persona debe tener solo los permisos estrictamente necesarios para su trabajo: ni más, ni menos. Con los comandos GRANT, REVOKE y DENY de SQL Server, y usando roles para organizar los permisos, este principio resulta sencillo de aplicar y fácil de auditar. Además de reducir riesgos de seguridad, este enfoque facilita las auditorías y ayuda a cumplir normativas como el RGPD, que exigen saber quién accede a qué datos.

Requisitos previos

Una instancia de SQL Server o una base de datos en Azure SQL Database.
SQL Server Management Studio (SSMS) o Azure Data Studio para ejecutar las consultas.
Una cuenta con permisos de administración (por ejemplo, miembro de db_owner) para crear roles y conceder permisos.
Nociones básicas de SQL: SELECT, tablas y esquemas.

Paso 1: Crear un rol para agrupar usuarios

En lugar de conceder permisos persona a persona, crea un rol por función de negocio. Así, cuando alguien entra o cambia de equipo, solo tocas el rol y no decenas de cuentas. Vamos a crear un rol para los analistas de ventas.

CREATE ROLE analistas_vendas;

El rol empieza sin ningún permiso. Es exactamente lo que queremos: partir de cero y añadir solo lo necesario.

Paso 2: Conceder solo lo necesario con GRANT

El comando GRANT asigna un permiso. Para respetar el privilegio mínimo, damos solo lectura (SELECT) y únicamente sobre los datos de ventas, no sobre toda la base de datos.

-- Ler todas as tabelas do esquema "vendas"
GRANT SELECT ON SCHEMA::vendas TO analistas_vendas;

-- Permissão mais fina: apenas uma tabela
GRANT SELECT ON OBJECT::vendas.encomendas TO analistas_vendas;

El operador SCHEMA:: aplica el permiso a todas las tablas actuales y futuras del esquema, mientras que OBJECT:: actúa sobre una sola tabla. Elige el nivel adecuado según la granularidad que necesites. Fíjate en que no concedimos INSERT, UPDATE ni DELETE: un analista que solo necesita consultar datos no debería poder modificarlos.

Paso 3: Añadir usuarios al rol

Ahora vinculamos a las personas con el rol. Cada miembro hereda exactamente los permisos del rol, sin excepciones.

ALTER ROLE analistas_vendas ADD MEMBER [maria];
ALTER ROLE analistas_vendas ADD MEMBER [joao];

Si mañana entra otro analista, el proceso es una sola línea. Puedes ver a qué roles pertenece un usuario en cualquier momento en las propiedades de la base de datos o con consultas al catálogo del sistema. Esta simplicidad es lo que hace que la gobernanza sea sostenible con el tiempo.

Paso 4: Bloquear datos sensibles con DENY

A veces queremos dar acceso a un esquema, pero proteger una tabla concreta con datos personales (PII). Ahí entra DENY, que tiene prioridad sobre GRANT.

-- Mesmo com SELECT no esquema, bloquear a tabela de dados pessoais
DENY SELECT ON OBJECT::vendas.clientes_pii TO analistas_vendas;

Regla de oro: cuando existen un DENY y un GRANT para el mismo permiso, gana el DENY. Es la red de seguridad ideal para proteger datos sensibles.

Paso 5: Quitar permisos con REVOKE

Las funciones cambian. REVOKE quita un permiso concedido (o anula un DENY), dejando el rol en un estado neutro para ese permiso.

-- Retirar uma permissão de escrita concedida por engano
REVOKE INSERT ON SCHEMA::vendas FROM analistas_vendas;

-- Retirar um utilizador do papel
ALTER ROLE analistas_vendas DROP MEMBER [joao];

No confundas REVOKE con DENY: REVOKE elimina la regla existente, mientras que DENY bloquea activamente, aunque exista un GRANT.

Comprobar el resultado

Hay dos formas sencillas de confirmar que todo quedó bien: consultar el catálogo de permisos y probar en la piel del usuario con EXECUTE AS.

-- Ver as permissões atribuídas ao papel
SELECT dp.permission_name, dp.state_desc, o.name AS objeto
FROM sys.database_permissions AS dp
LEFT JOIN sys.objects AS o ON o.object_id = dp.major_id
WHERE dp.grantee_principal_id = DATABASE_PRINCIPAL_ID('analistas_vendas');

-- Testar as permissões como se fosse a utilizadora
EXECUTE AS USER = 'maria';
SELECT TOP (1) * FROM vendas.encomendas;    -- deve funcionar
SELECT TOP (1) * FROM vendas.clientes_pii;  -- deve falhar (DENY)
REVERT;

Ejecuta cada consulta y observa el resultado. Un error de permiso en una de las líneas no es un fallo del tutorial: es la gobernanza haciendo su trabajo. Si María puede leer vendas.encomendas pero queda bloqueada en vendas.clientes_pii, el privilegio mínimo está funcionando como se espera.

Conclusión

Con roles, GRANT, DENY y REVOKE tienes las piezas esenciales para aplicar el privilegio mínimo y mantener la gobernanza de datos bajo control. El siguiente paso es revisar estos permisos periódicamente y combinarlos con enmascaramiento de datos (Dynamic Data Masking) y etiquetas de confidencialidad para una protección completa. Documenta también qué rol da acceso a qué; esa documentación vale oro el día de una auditoría. Mirando tu propia base de datos, ¿qué tabla merece un DENY hoy mismo?