Usuarios, roles y permisos en bases de datos SQL

1. Conceptos fundamentales

Los sistemas gestores de bases de datos permiten controlar qué operaciones puede realizar cada usuario. Esto ayuda a proteger la información y evita que una aplicación tenga más privilegios de los necesarios.

Usuario (User)

Es una identidad que puede utilizarse para acceder a una base de datos o trabajar dentro de ella, según el sistema gestor.

Rol (Role)

Es una identidad o conjunto de privilegios que puede asignarse a usuarios o a otros roles.

Los roles facilitan la administración porque permiten definir permisos una vez y asignarlos a varias cuentas.

La diferencia exacta entre usuario y rol depende del gestor. En PostgreSQL, por ejemplo, ambos conceptos se representan mediante roles; un rol con el atributo LOGIN puede iniciar sesión.

Privilegio (Privilege)

Es la autorización para realizar una operación sobre un objeto de la base de datos.

Ejemplos:

• SELECT: consultar datos.
• INSERT: insertar registros.
• UPDATE: modificar registros.
• DELETE: eliminar registros.
• TRUNCATE: vaciar una tabla.
• EXECUTE: ejecutar una función o procedimiento.
• USAGE: utilizar determinados objetos, como un esquema o una secuencia en PostgreSQL.
• CREATE: crear objetos, según el contexto.

Propietario (Owner)

Es quien posee un objeto de la base de datos, como una tabla o un esquema.

Ser propietario no es lo mismo que recibir un permiso mediante GRANT: la propiedad concede facultades propias sobre el objeto. Por eso, en PostgreSQL es importante distinguir entre el rol que administra el esquema y el rol que utiliza la aplicación.

2. Los comandos principales

En muchos gestores SQL encontrarás estos comandos:

Comando	Función
CREATE USER	Crear un usuario, con diferencias según el gestor.
CREATE ROLE	Crear un rol.
GRANT	Conceder permisos.
REVOKE	Retirar permisos o concesiones.
ALTER ROLE	Modificar atributos o membresías de roles, según el gestor.
DROP USER / DROP ROLE	Eliminar usuarios o roles.

La estructura conceptual de GRANT es:

GRANT privilegio
ON objeto
TO usuario_o_rol;

Por ejemplo:

GRANT SELECT
ON TABLE categoria
TO usuario_app;

Significa que usuario_app recibe permiso para consultar la tabla categoria.

Importante: la sintaxis exacta cambia entre PostgreSQL, MySQL y SQL Server. Además, el usuario que ejecuta GRANT debe tener autoridad suficiente para conceder ese permiso.

3. Tipos de permisos

Los permisos pueden aplicarse a diferentes niveles:

• Servidor: administrar el servidor o la instancia.
• Base de datos: conectarse o crear determinados objetos.
• Esquema: acceder a un espacio de nombres y, según el gestor, crear objetos en él.
• Tabla o vista: consultar, insertar, modificar o eliminar registros.
• Secuencia: utilizar objetos que generan valores numéricos, como ciertas secuencias de identificadores.

Conceder permisos sobre una tabla no implica necesariamente tener todos los permisos necesarios para acceder a la base de datos, al esquema o a otros objetos relacionados.

---

4. PostgreSQL

4.1. Crear roles para separar responsabilidades

PostgreSQL utiliza roles para representar tanto usuarios como grupos de privilegios. El atributo LOGIN permite iniciar sesión.

Ejemplo de separación entre el propietario de los objetos y la aplicación:

CREATE ROLE prueba_owner
    NOLOGIN;

CREATE ROLE prueba_app
    LOGIN
    NOSUPERUSER
    NOCREATEDB
    NOCREATEROLE
    NOREPLICATION
    PASSWORD 'cambiar_por_una_clave_segura';

• prueba_owner: rol propietario de los objetos y destinado a tareas administrativas o migraciones.
• prueba_app: rol utilizado por la aplicación para conectarse a la base de datos.

La contraseña del ejemplo es un marcador ilustrativo; no debe utilizarse literalmente en producción.

4.2. Conceder acceso a la base de datos

GRANT CONNECT
ON DATABASE Prueba
TO prueba_app;

Este permiso permite conectarse a Prueba. No concede automáticamente acceso a todas sus tablas.

4.3. Permitir el acceso al esquema

Dentro de la base de datos Prueba:

GRANT USAGE
ON SCHEMA public
TO prueba_app;

USAGE permite acceder a los objetos del esquema para los que el rol también tenga los permisos necesarios.

No es lo mismo que CREATE: este último permite crear objetos en el esquema.

4.4. Conceder permisos sobre tablas existentes

GRANT SELECT, INSERT, UPDATE, DELETE
ON ALL TABLES IN SCHEMA public
TO prueba_app;

Esto concede permisos sobre las tablas y vistas aplicables que ya existen en el esquema.

No significa que el rol pueda crear tablas, administrar usuarios o modificar la estructura de cualquier objeto.

Si la aplicación solo necesita consultar información, conviene limitar el permiso:

GRANT SELECT
ON ALL TABLES IN SCHEMA public
TO prueba_app;

4.5. Permisos sobre secuencias

Algunas operaciones de inserción necesitan utilizar secuencias para generar identificadores.

GRANT USAGE
ON ALL SEQUENCES IN SCHEMA public
TO prueba_app;

USAGE permite utilizar las secuencias para operaciones como nextval. Los permisos necesarios dependen de la operación y de cómo esté definido el identificador.

Idea clave: los permisos sobre tablas y secuencias son independientes en PostgreSQL.

4.6. Permisos para objetos futuros

Un error común es conceder permisos sobre las tablas existentes y asumir que las tablas nuevas recibirán automáticamente los mismos permisos.

Para establecer permisos predeterminados:

ALTER DEFAULT PRIVILEGES
FOR ROLE prueba_owner
IN SCHEMA public
GRANT SELECT, INSERT, UPDATE, DELETE
ON TABLES
TO prueba_app;

Y para las secuencias:

ALTER DEFAULT PRIVILEGES
FOR ROLE prueba_owner
IN SCHEMA public
GRANT USAGE
ON SEQUENCES
TO prueba_app;

Muy importante: estas reglas se aplican a los objetos que prueba_owner cree en el futuro. Si las migraciones crean los objetos con otro rol, hay que configurar los privilegios predeterminados para ese rol creador.

Además, ALTER DEFAULT PRIVILEGES no modifica los permisos de los objetos que ya existen.

4.7. Retirar permisos

REVOKE INSERT
ON TABLE categoria
FROM prueba_app;

Esto retira la concesión directa de INSERT sobre categoria, pero el rol podría conservar ese permiso si lo recibe mediante otro rol o concesión.

Para retirar el permiso de uso de una secuencia:

REVOKE USAGE
ON SEQUENCE categoria_id_categoria_seq
FROM prueba_app;

El nombre de la secuencia es ilustrativo: debes utilizar el nombre real de tu base de datos.

---

5. MySQL

MySQL también permite crear usuarios y conceder permisos, pero su sintaxis y su modelo de cuentas difieren de PostgreSQL.

5.1. Crear un usuario

CREATE USER 'app_user'@'localhost'
IDENTIFIED BY 'cambiar_por_una_clave_segura';

En MySQL, 'app_user'@'localhost' identifica una cuenta asociada al origen de conexión indicado. No equivale necesariamente a un usuario llamado app_user que pueda conectarse desde cualquier lugar.

5.2. Conceder permisos sobre una base de datos

GRANT SELECT, INSERT, UPDATE, DELETE
ON mi_bd.*
TO 'app_user'@'localhost';

mi_bd.* indica que los permisos se aplican a los objetos correspondientes de esa base de datos.

Para conceder únicamente consultas:

GRANT SELECT
ON mi_bd.*
TO 'app_user'@'localhost';

5.3. Conceder permisos sobre una tabla específica

GRANT SELECT, INSERT
ON mi_bd.categoria
TO 'app_user'@'localhost';

El usuario podrá consultar e insertar registros en esa tabla, pero esta concesión no le otorga por sí sola todos los permisos sobre el resto de la base de datos.

5.4. Retirar permisos

REVOKE INSERT
ON mi_bd.*
FROM 'app_user'@'localhost';

Esto retira la concesión de INSERT en ese ámbito. Si la cuenta recibe permisos equivalentes por otras concesiones o roles, puede conservar la capacidad de insertar.

5.5. Consultar los permisos

SHOW GRANTS FOR 'app_user'@'localhost';

Este comando permite revisar las concesiones asociadas a la cuenta.

---

6. SQL Server

SQL Server distingue entre el login, que permite autenticarse en la instancia, y el user, que representa al principal dentro de una base de datos.

6.1. Crear un login y un usuario

Ejemplo simplificado utilizando autenticación de SQL Server:

CREATE LOGIN app_user
WITH PASSWORD = 'Cambiar_por_una_clave_segura_123!';
GO

USE MiBaseDatos;
GO

CREATE USER app_user
FOR LOGIN app_user;
GO

El login existe en el ámbito de la instancia y el usuario corresponde a MiBaseDatos.

En entornos que utilizan autenticación integrada de Windows o Microsoft Entra, el proceso puede ser diferente.

6.2. Crear un rol para la aplicación

CREATE ROLE app_reader;
GO

GRANT SELECT
ON SCHEMA::dbo
TO app_reader;
GO

ALTER ROLE app_reader
ADD MEMBER app_user;
GO

En este ejemplo:

1. Se crea un rol llamado app_reader.
2. Se concede permiso de consulta sobre el esquema dbo.
3. Se incorpora app_user al rol.

De esta forma, el permiso se administra desde el rol y no individualmente para cada usuario.

6.3. Conceder permisos de escritura

Si el usuario también necesita modificar datos:

GRANT INSERT, UPDATE, DELETE
ON SCHEMA::dbo
TO app_reader;
GO

Este ejemplo amplía los permisos del rol. En un entorno real, es preferible separar los roles de lectura y escritura si las responsabilidades son diferentes.

6.4. Retirar permisos

REVOKE UPDATE
ON SCHEMA::dbo
FROM app_reader;
GO

SQL Server también cuenta con DENY, que explícitamente prohíbe un permiso y tiene prioridad sobre las concesiones ordinarias aplicables. No debe confundirse con REVOKE, que retira una concesión o denegación.

---

7. Comparación rápida

Operación	PostgreSQL	MySQL	SQL Server
Crear una cuenta	CREATE ROLE ... LOGIN	CREATE USER	CREATE LOGIN y CREATE USER
Conceder permisos	GRANT	GRANT	GRANT
Retirar permisos	REVOKE	REVOKE	REVOKE
Agrupar permisos	Roles	Roles	Roles
Permisos para objetos futuros	ALTER DEFAULT PRIVILEGES	Depende del tipo de objeto y mecanismo utilizado	Depende del objeto y del ámbito de permisos
Denegación explícita	No existe un DENY equivalente general	No existe un DENY equivalente general	DENY

Aunque los nombres de los comandos se parecen, los ámbitos de los permisos y las reglas de herencia no son idénticos entre gestores.

---

8. Buenas prácticas de seguridad

1. Principio de mínimo privilegio: concede únicamente los permisos que la aplicación necesita.
2. Separar aplicación y administración: utiliza cuentas distintas para ejecutar la aplicación y para realizar migraciones o tareas administrativas.
3. Preferir roles: agrupa permisos por responsabilidad, por ejemplo, lectura, escritura y administración.
4. Evitar superusuarios en aplicaciones: una cuenta de aplicación no debería necesitar privilegios administrativos generales.
5. Revisar los objetos futuros: verifica si las nuevas tablas, vistas y secuencias reciben los permisos esperados.
6. Proteger las credenciales: evita guardar contraseñas reales en el repositorio de código.
7. Revisar permisos heredados: retirar una concesión directa no garantiza que desaparezca una capacidad obtenida por otro rol.
8. Probar con la cuenta real de la aplicación: confirma que puede hacer lo necesario y que las operaciones no autorizadas fallan.

9. Resumen para memorizar

• CREATE USER / CREATE ROLE: crear identidades o roles, según el gestor.
• GRANT: conceder un permiso.
• REVOKE: retirar una concesión.
• SELECT: leer datos.
• INSERT: insertar datos.
• UPDATE: modificar datos.
• DELETE: eliminar registros.
• CONNECT: conectarse a una base de datos en PostgreSQL.
• USAGE: utilizar determinados objetos, como esquemas y secuencias en PostgreSQL.
• ALTER DEFAULT PRIVILEGES: establecer permisos para objetos futuros en PostgreSQL.
• Roles: permiten administrar permisos de forma centralizada.
• Mínimo privilegio: cada cuenta debe tener solo las capacidades que necesita.

La regla mental más útil es: crear la identidad, conceder acceso al ámbito necesario, conceder los permisos sobre los objetos y comprobar qué permisos adicionales recibe por sus roles.

Documentación oficial

• PostgreSQL: Privileges
• PostgreSQL: GRANT
• PostgreSQL: ALTER DEFAULT PRIVILEGES
• MySQL: Privileges Provided by MySQL
• SQL Server: Getting Started with Database Engine Permissions