Configurando permisos de acceso con GRANT y REVOKE

Imagina que tus datos son una fortaleza, y cada habitante de la fortaleza tiene sus propios permisos: uno solo puede pasear por el patio, otro guarda las llaves del tesoro, y otro está sentado en la sala del trono controlando todo. En nuestra base de datos, los comandos GRANT y REVOKE cumplen ese papel. Son los que deciden quién puede ir a dónde y para qué.

El comando GRANT, como cualquier grant decente, te deja dar acceso a recursos (por ejemplo, bases de datos, tablas, esquemas) a ciertos roles. Es como una "invitación a la fiesta", donde tú decides quién puede leer, escribir o incluso romper los muebles.

El comando REVOKE, al contrario, quita los permisos que ya diste antes. Es como decir: "Oye, la fiesta se acabó para ti, deja las llaves en la puerta".

Dar permisos usando GRANT

Vamos a empezar desde el nivel más alto: la base de datos. Para que un usuario pueda conectarse a la base, hay que darle permisos de conexión. Para eso se usa el comando:

GRANT CONNECT ON DATABASE database_name TO role_name;

Por ejemplo, si tenemos una base de datos university y un rol student, podemos dejar que los estudiantes se conecten con esta consulta:

GRANT CONNECT ON DATABASE university TO student;

Pero solo conectarse no significa que puedan hacer lo que quieran. Para que el usuario pueda crear objetos en la base de datos, también necesita el permiso de creación:

GRANT CREATE ON DATABASE university TO student;

Puedes comprobar los permisos en la base de datos con el comando:

\l+ university

Quitar permisos usando REVOKE

Si de repente el estudiante empieza a portarse raro (por ejemplo, intenta crear más tablas de las que esperabas), puedes quitarle el permiso de creación con el comando:

REVOKE CREATE ON DATABASE university FROM student;

Y después de eso, el estudiante solo podrá conectarse, pero nada de "libertad creativa".

Configurando permisos a nivel de esquemas

Un esquema es básicamente una "habitación" dentro de nuestra base de datos, donde se guardan tablas, vistas y otros objetos. Para que un usuario pueda trabajar con objetos dentro del esquema, puedes configurar permisos de lectura, escritura o creación de objetos.

Dar permisos sobre un esquema

Supón que tenemos el esquema public (se crea por defecto en cada base de datos). Podemos dejar que el usuario vea el contenido del esquema:

GRANT USAGE ON SCHEMA public TO student;

Pero solo con USAGE no basta para trabajar con las tablas. Para que el usuario pueda crear nuevos objetos, añadimos:

GRANT CREATE ON SCHEMA public TO student;

Así, el estudiante puede no solo leer, sino también crear tablas en el esquema public.

Quitar permisos sobre un esquema

Si el estudiante empieza a llenar el esquema con tablas raras con nombres tipo bad_idea_01, podemos limitar sus permisos:

REVOKE CREATE ON SCHEMA public FROM student;

Ahora el estudiante ya no podrá añadir nuevas tablas. ¡Orden restaurado!

Configurando permisos a nivel de tablas

La tabla es probablemente el objeto más popular de la base de datos. Vamos a ver cómo configurar el acceso específicamente a las tablas. Aquí hay tres categorías principales de acciones: lectura, escritura y modificación.

Permisos de lectura

Para dejar que un usuario lea el contenido de una tabla, se usa el comando:

GRANT SELECT ON TABLE table_name TO role_name;

Por ejemplo, para que los estudiantes puedan leer los registros de la tabla courses:

GRANT SELECT ON TABLE courses TO student;

Ahora el usuario student puede lanzar consultas SELECT sobre la tabla courses.

Permisos de escritura

Si quieres que el usuario pueda insertar nuevas filas en la tabla, puedes configurarlo así:

GRANT INSERT ON TABLE table_name TO role_name;

Ejemplo:

GRANT INSERT ON TABLE courses TO student;

Ahora los estudiantes pueden añadir nuevos cursos a la tabla. Pero espera... ¿Estamos seguros de que es buena idea?

Permisos de modificación y borrado

Si el usuario debe poder actualizar filas existentes o borrarlas, hay que darle los permisos UPDATE y DELETE respectivamente.

GRANT UPDATE ON TABLE courses TO student;
GRANT DELETE ON TABLE courses TO student;

Consejo: no te pases dando estos permisos. Si les das a los estudiantes acceso para borrar datos, pueden romperlo todo sin querer (o queriendo).

Ejemplos: crear un rol con permisos limitados

Imagina que creamos un rol para profesores, que deben poder leer datos sobre estudiantes y cursos, pero no pueden borrar registros. Así se hace:

1. Creamos el rol:

CREATE ROLE teacher;

2. Damos permisos de lectura sobre las tablas students y courses:

GRANT SELECT ON TABLE students, courses TO teacher;

3. Restringimos el acceso para borrar:

REVOKE DELETE ON TABLE students, courses FROM teacher;

Ahora nuestros profes solo tendrán los permisos necesarios y nada más.

Cómo combinar GRANT y REVOKE para una configuración flexible

Supón que tenemos un rol intern al que queremos limitar. Solo debe tener acceso a los datos de cursos, pero bajo ningún concepto a los datos de estudiantes. Así se hace:

1. Permitimos acceso solo a la tabla courses:

GRANT SELECT, INSERT ON TABLE courses TO intern;

2. Nos aseguramos de que el rol intern no tenga permisos sobre la tabla students:

REVOKE ALL ON TABLE students FROM intern;

Esta combinación te permite ajustar los permisos exactamente como quieras.

Ejemplos de uso en proyectos reales

Este sistema de gestión de permisos se usa mucho en proyectos reales. Por ejemplo:

1. En tiendas online, los permisos sobre las tablas de usuarios y pedidos se reparten entre los roles "administrador", "operador" y "invitado".
2. En sistemas universitarios, los administradores pueden añadir y modificar cursos, y los estudiantes solo pueden verlos.
3. En sistemas bancarios, el acceso a las cuentas de los clientes está separado entre empleados de diferentes departamentos.