# Usuarios, roles y permisos en bases de datos

**Categoría:** Bases de datos · **Nivel:** Intermedio · **Lectura:** 21 min
**Publicada:** 2026-07-28 · **Actualizada:** 2026-07-28 · **Autoría:** Underc0de
**Versión HTML (canónica):** https://underc0de.org/guias/bases-de-datos/usuarios-roles-y-permisos-en-bases-de-datos/

## Respuesta rápida

El control de acceso en una base de datos se apoya en tres piezas: **usuarios**, **permisos** y **roles**. Un **usuario** es una identidad que se conecta a la base de datos (con su nombre y su contraseña) —puede ser una persona o, muy a menudo, una *aplicación*—. Los **permisos** (o privilegios) definen **qué puede hacer** cada usuario: leer una tabla (`SELECT`), insertar (`INSERT`), modificar (`UPDATE`), borrar (`DELETE`), crear tablas, administrar… Se conceden con `GRANT` y se retiran con `REVOKE`, y se pueden dar de forma muy fina: sobre una base entera, una tabla concreta o incluso columnas. Los **roles** son **agrupaciones de permisos** con un nombre: en vez de asignar diez permisos a mano a cada usuario, creás un rol (por ejemplo «solo lectura» o «editor de ventas») con esos permisos, y se lo asignás a los usuarios que lo necesiten —cambiás el rol una vez y todos los usuarios que lo tienen se actualizan a la vez—. La **regla de oro** que rige todo esto es el **principio de privilegio mínimo**: cada usuario debe tener **solo los permisos que necesita para su función, y ni uno más**. La razón es de **contención del daño**: si una cuenta se ve comprometida —o si comete un error—, el alcance del problema queda limitado a lo que ese usuario podía hacer. Un usuario todopoderoso comprometido es un desastre total; uno acotado, un incidente controlado. La aplicación más importante de esta regla: cada **aplicación debe tener su propio usuario**, con acceso **solo a su base de datos** y **solo a las operaciones que necesita** —nunca el usuario administrador—. Así, si esa aplicación tiene un fallo de seguridad, el atacante no obtiene control total de la base, sino solo lo que tenía ese usuario limitado. Es el mismo principio de privilegio mínimo que rige la [seguridad del servidor](../../linux/como-asegurar-mysql-o-mariadb-en-un-servidor-linux/index.md) y los permisos de todo sistema: dar lo justo, nunca de más. Usuarios para saber *quién*, permisos para *qué*, roles para *gestionarlo con orden*, y privilegio mínimo como brújula.

## Usuarios y permisos

El control de acceso responde a dos preguntas: **quién** y **qué**. Los **usuarios** responden el «quién»: cada usuario es una identidad, con su nombre y su contraseña, que se conecta a la base de datos. Un usuario puede representar a una persona, pero en las aplicaciones lo más habitual es que represente a la propia **aplicación**, que se conecta con su usuario para operar. Los **permisos** (o privilegios) responden el «qué»: definen las operaciones que cada usuario tiene autorizadas —desde leer datos hasta administrar la base—. La combinación de ambos determina exactamente qué puede hacer cada quien.

> **GRANT y REVOKE: conceder y retirar**
>
> Los permisos se gestionan con dos instrucciones complementarias: **`GRANT`** (conceder) da un permiso a un usuario, y **`REVOKE`** (revocar) se lo quita. Lo potente es la **granularidad**: los permisos no son «todo o nada», sino que se pueden dar con mucha precisión. Podés conceder solo `SELECT` (leer) sobre *una tabla concreta*, o `SELECT` e `INSERT` pero no `DELETE`, o permisos sobre *toda una base de datos*, o incluso —en algunos motores— sobre **columnas específicas** de una tabla. Esta finura es la que hace posible el privilegio mínimo: podés darle a cada usuario exactamente el conjunto de operaciones que necesita, ni más ni menos. Los tipos de permiso más comunes se corresponden con las operaciones SQL: leer (`SELECT`), insertar (`INSERT`), modificar (`UPDATE`), borrar (`DELETE`), y luego los de estructura y administración (crear tablas, gestionar usuarios). Diseñar bien los permisos es decidir, para cada usuario, qué subconjunto de estas operaciones necesita de verdad.

## Los roles

Los **roles** resuelven un problema práctico: gestionar los permisos de muchos usuarios a mano es tedioso y propenso a errores. Un rol es una **agrupación de permisos con nombre**:

| Sin roles | Con roles |
|---|---|
| Asignar cada permiso a cada usuario, uno a uno | Agrupar los permisos en un rol y asignar el rol |
| Cambiar un permiso: editar todos los usuarios | Cambiar el rol una vez: todos se actualizan |
| Fácil equivocarse y dejar accesos inconsistentes | Consistencia: el rol define un conjunto claro |

> **Atención**
>
> La idea del rol es **separar «qué permisos» de «quién los tiene»**. En vez de darle a cada usuario su lista de permisos individualmente, definís **roles** que representan *funciones* —por ejemplo, un rol «solo lectura» con permiso de `SELECT`, un rol «editor de ventas» con lectura y escritura sobre las tablas de ventas, un rol «administrador de informes»—, y a cada usuario le asignás el rol o los roles que le corresponden. Las ventajas son grandes en cuanto hay más de unos pocos usuarios. Primera, **gestión centralizada**: si mañana el rol «editor de ventas» necesita acceso a una tabla nueva, cambiás *el rol* una sola vez y **todos** los usuarios que lo tienen quedan actualizados al instante —sin tener que editar uno por uno—. Segunda, **consistencia**: todos los que hacen la misma función tienen exactamente los mismos permisos, sin las discrepancias que aparecen cuando se asignan a mano. Tercera, **claridad**: mirar qué roles tiene un usuario dice de un vistazo qué puede hacer, mejor que revisar una lista de permisos sueltos. Los roles son, en esencia, la forma **escalable y mantenible** de gestionar los permisos, y encajan de forma natural con el privilegio mínimo: se diseñan roles acotados a cada función.

## El privilegio mínimo

Por encima de las tres piezas está el principio que debe guiar todas las decisiones de acceso: el **privilegio mínimo**. Su enunciado es simple: **cada usuario, solo los permisos que necesita, y ni uno más**. Sus aplicaciones concretas:

- **Un usuario por aplicación.** Cada aplicación con su propio usuario, no compartido, con acceso solo a su base de datos.
- **Solo las operaciones necesarias.** Si una app solo lee y escribe en unas tablas, su usuario no debe poder borrar bases ni crear usuarios.
- **Nunca el usuario administrador para el día a día.** El administrador (que puede todo) se reserva para tareas de administración puntuales.
- **Revisar y retirar lo que sobra.** Con el tiempo se acumulan permisos que ya no hacen falta; revisarlos y revocarlos.

> **Atención**
>
> La razón por la que el privilegio mínimo es *la* regla de oro de la seguridad de bases de datos es la **contención del daño**. Toda cuenta puede, tarde o temprano, verse **comprometida** (un atacante roba sus credenciales, o explota un fallo en la aplicación que la usa) o **cometer un error** (un borrado accidental). Cuando eso pasa, el **alcance del desastre depende directamente de los permisos que tuviera esa cuenta**. Si el usuario comprometido podía *todo* —leer, escribir, borrar, administrar toda la base—, el atacante obtiene **control total**: puede robar todos los datos, destruirlos, crear puertas traseras. Si el usuario estaba **acotado** a leer y escribir en unas pocas tablas, el atacante solo puede hacer *eso* —un incidente grave, pero **contenido**—. La diferencia entre un desastre total y un problema acotado es, muchas veces, si se aplicó el privilegio mínimo. Su aplicación más importante y olvidada es **que cada aplicación tenga su propio usuario limitado**: es tentador conectar la app con el usuario administrador «para que no dé problemas de permisos», pero eso convierte cualquier fallo de la aplicación en un compromiso total de la base de datos. Dar a cada aplicación un usuario con *solo* lo que necesita es una de las medidas de seguridad más rentables que existen, y es la misma lógica que ordena la [seguridad del servidor de base de datos](../../linux/como-asegurar-mysql-o-mariadb-en-un-servidor-linux/index.md) y de todo el sistema.

## Errores frecuentes

- **Conectar las aplicaciones con el usuario administrador.** Un fallo en la app daría control total; cada app con su usuario acotado.
- **Dar más permisos de los necesarios «por comodidad».** Rompe el privilegio mínimo y agranda el daño potencial.
- **Compartir un mismo usuario entre varias aplicaciones o personas.** Impide acotar y auditar; un usuario por cada quien.
- **Asignar permisos a mano en vez de usar roles.** Con varios usuarios, es tedioso, inconsistente y propenso a errores.
- **No revisar los permisos con el tiempo.** Se acumulan accesos que ya no hacen falta; revisar y revocar.
- **Usar contraseñas débiles en los usuarios de base de datos.** Facilitan el compromiso que el privilegio mínimo busca contener.
- **Confundir usuario con rol.** El usuario es quien se conecta; el rol es un conjunto de permisos que se le asigna.

## Preguntas frecuentes

**¿Qué son los usuarios, los permisos y los roles en una base de datos?**
Los usuarios, los permisos y los roles son las tres piezas fundamentales del control de acceso en una base de datos, que en conjunto determinan quién puede conectarse y qué está autorizado a hacer. Un usuario es una identidad que se conecta a la base de datos, identificándose habitualmente con un nombre y una contraseña. Un usuario puede representar a una persona, pero en el contexto de las aplicaciones lo más habitual es que represente a la propia aplicación, que se conecta a la base de datos con su usuario para realizar sus operaciones. Los usuarios responden, por tanto, a la pregunta de quién accede a la base de datos. Los permisos, también llamados privilegios, definen qué puede hacer cada usuario, es decir, las operaciones que tiene autorizadas, que van desde leer datos de una tabla, insertar nuevos datos, modificar los existentes o borrarlos, hasta operaciones de estructura como crear tablas, o de administración como gestionar otros usuarios. Los permisos se conceden mediante una instrucción de concesión y se retiran mediante una de revocación, y una de sus características más importantes es que se pueden otorgar de forma muy fina o granular, ya sea sobre toda una base de datos, sobre una tabla concreta o incluso, en algunos motores, sobre columnas específicas de una tabla. Los permisos responden, por tanto, a la pregunta de qué puede hacer cada usuario. Los roles son agrupaciones de permisos identificadas con un nombre, que sirven para gestionar los permisos de forma más ordenada y eficiente. En lugar de asignar individualmente muchos permisos a cada usuario, se crea un rol que agrupa un conjunto de permisos correspondientes a una función, como por ejemplo un rol de solo lectura o un rol de editor de una determinada área, y se asigna ese rol a los usuarios que lo necesiten. Los roles responden, por tanto, a la pregunta de cómo gestionar los permisos de forma escalable y mantenible. La combinación de estas tres piezas permite establecer un control de acceso preciso, indicando quién se conecta mediante los usuarios, qué puede hacer cada uno mediante los permisos, y organizando todo ello de forma ordenada mediante los roles. Por encima de estas piezas, la regla que debe guiar su uso es el principio de privilegio mínimo, según el cual cada usuario debe tener solo los permisos que necesita para su función y ni uno más, lo que constituye una de las defensas más importantes de los datos.

**¿Qué son GRANT y REVOKE?**
La concesión y la revocación, expresadas en SQL mediante las instrucciones de conceder y revocar, son las dos operaciones complementarias con las que se gestionan los permisos en una base de datos, sirviendo la primera para otorgar un permiso a un usuario y la segunda para retirárselo. La instrucción de concesión se utiliza para dar a un usuario un permiso determinado, es decir, para autorizarle a realizar cierta operación sobre cierto objeto de la base de datos. La instrucción de revocación realiza la operación inversa, retirando a un usuario un permiso que tenía concedido, de modo que deja de estar autorizado a realizar esa operación. Juntas, permiten administrar de forma dinámica lo que cada usuario puede hacer, concediendo permisos cuando se necesitan y retirándolos cuando ya no proceden. Una de las características más potentes de este sistema de permisos es su granularidad, es decir, la posibilidad de conceder o revocar los permisos con gran precisión, ya que los permisos no funcionan de forma indivisible o de todo o nada, sino que se pueden ajustar a distintos niveles. Se puede conceder un permiso sobre toda una base de datos, sobre una tabla concreta dentro de ella, o incluso, en algunos motores de base de datos, sobre columnas específicas de una tabla. Asimismo, se puede conceder solo un tipo de operación y no otras, por ejemplo permitir a un usuario leer datos de una tabla pero no modificarlos ni borrarlos, o permitirle leer e insertar pero no borrar. Los tipos de permiso más comunes se corresponden con las operaciones fundamentales sobre los datos, como leer, insertar, modificar y borrar, y existen además permisos relativos a la estructura, como crear o modificar tablas, y a la administración, como gestionar usuarios y sus permisos. Esta granularidad es precisamente lo que hace posible aplicar el principio de privilegio mínimo, ya que permite dar a cada usuario exactamente el conjunto de operaciones que necesita, ni más ni menos, ajustando con precisión sus capacidades. Diseñar correctamente los permisos consiste, por tanto, en decidir para cada usuario qué subconjunto de operaciones necesita realmente, y en usar la concesión y la revocación para otorgarle exactamente esos permisos y retirarle los que no correspondan. Cuando el número de usuarios crece, en lugar de gestionar los permisos individualmente con estas instrucciones para cada usuario, resulta más práctico agruparlos en roles y gestionar los permisos a través de ellos, aunque internamente los roles también se construyen concediendo permisos.

**¿Para qué sirven los roles?**
Los roles sirven para gestionar los permisos de forma ordenada, eficiente y escalable, agrupando conjuntos de permisos bajo un nombre que representa una función, de modo que en lugar de asignar los permisos individualmente a cada usuario se le asigna el rol correspondiente, lo que simplifica enormemente la administración cuando hay más de unos pocos usuarios. El problema que resuelven los roles es que gestionar los permisos de muchos usuarios de forma individual resulta tedioso, propenso a errores e inconsistente. Sin roles, cada vez que se da de alta un usuario hay que asignarle uno por uno todos los permisos que necesita, y cada vez que cambia lo que puede hacer una determinada función hay que modificar los permisos de todos los usuarios que la desempeñan, lo que es laborioso y fácil de hacer mal, dejando a unos usuarios con unos permisos y a otros con otros distintos aunque hagan lo mismo. Los roles resuelven esto separando el qué permisos del quién los tiene. Se definen roles que representan funciones, como por ejemplo un rol de solo lectura que tiene permiso para leer datos, un rol de editor de una determinada área que tiene permiso para leer y escribir en las tablas de esa área, o un rol de administrador de informes, y a cada usuario se le asigna el rol o los roles que correspondan a su función. Las ventajas de este enfoque son considerables. La primera es la gestión centralizada, ya que si en el futuro una función necesita un permiso adicional, por ejemplo acceso a una tabla nueva, basta con modificar el rol una sola vez para que todos los usuarios que lo tienen queden actualizados automáticamente, sin necesidad de editar a cada uno. La segunda es la consistencia, ya que todos los usuarios que desempeñan la misma función tienen exactamente los mismos permisos al compartir el mismo rol, evitando las discrepancias que surgen al asignar permisos a mano. La tercera es la claridad, ya que mirar qué roles tiene asignado un usuario indica de un vistazo qué puede hacer, lo que es mucho más comprensible que revisar una larga lista de permisos individuales. Por todo ello, los roles son la forma escalable y mantenible de gestionar los permisos, especialmente en bases de datos con muchos usuarios, y encajan de forma natural con el principio de privilegio mínimo, ya que se pueden diseñar roles acotados a cada función que otorguen solo los permisos necesarios para ella.

**¿Qué es el principio de privilegio mínimo?**
El principio de privilegio mínimo es la regla fundamental de seguridad según la cual cada usuario debe tener únicamente los permisos que necesita para desempeñar su función, y ni uno más, y constituye la brújula que debe guiar todas las decisiones sobre el control de acceso en una base de datos. Su enunciado es sencillo pero sus implicaciones son profundas, ya que va en contra de la tentación de dar permisos amplios por comodidad y obliga a pensar cuidadosamente qué necesita realmente cada usuario. La razón de ser de este principio es la contención del daño ante un posible incidente. Cualquier cuenta puede, tarde o temprano, verse comprometida, por ejemplo si un atacante roba sus credenciales o explota un fallo de seguridad en la aplicación que la utiliza, o puede cometer un error, como un borrado accidental de datos. Cuando esto ocurre, el alcance del daño depende directamente de los permisos que tuviera esa cuenta. Si el usuario comprometido tenía todos los permisos, es decir, podía leer, escribir, borrar y administrar toda la base de datos, el atacante obtiene control total y puede robar todos los datos, destruirlos o crear puertas traseras, lo que supone un desastre completo. En cambio, si el usuario estaba acotado y solo podía, por ejemplo, leer y escribir en unas pocas tablas concretas, el atacante solo puede hacer eso, lo que sigue siendo un incidente grave pero queda contenido y limitado. La diferencia entre un desastre total y un problema acotado radica, en muchos casos, en si se aplicó o no el principio de privilegio mínimo. Este principio tiene varias aplicaciones concretas. La más importante, y a menudo la más descuidada, es que cada aplicación debe tener su propio usuario, con acceso solo a su base de datos y solo a las operaciones que necesita, y nunca conectarse con el usuario administrador, ya que aunque sea tentador usar el administrador para evitar problemas de permisos, eso convierte cualquier fallo de seguridad de la aplicación en un compromiso total de la base de datos. Otras aplicaciones son dar a cada usuario solo las operaciones que necesita, reservar el usuario administrador exclusivamente para tareas de administración puntuales, no compartir un mismo usuario entre varias aplicaciones o personas para poder acotar y auditar, y revisar periódicamente los permisos para retirar los que ya no sean necesarios. El principio de privilegio mínimo es, en definitiva, una de las medidas de seguridad más eficaces y rentables, y es el mismo principio que rige la seguridad de los servidores y de los sistemas informáticos en general, aplicándose siempre la misma lógica de dar lo justo y nunca de más.

**¿Por qué cada aplicación debe tener su propio usuario?**
Cada aplicación debe tener su propio usuario, con permisos acotados a lo que necesita y nunca el usuario administrador, porque de ese modo, si la aplicación sufre un fallo de seguridad y es comprometida, el atacante solo obtiene las capacidades limitadas de ese usuario y no el control total de la base de datos, lo que es la aplicación más importante del principio de privilegio mínimo. Las aplicaciones se conectan a la base de datos utilizando un usuario para realizar sus operaciones, y la elección de qué permisos tiene ese usuario tiene enormes consecuencias de seguridad. Las aplicaciones, especialmente las que están expuestas, como las aplicaciones web, pueden tener vulnerabilidades que un atacante logre explotar para ejecutar operaciones en la base de datos a través de ellas. Cuando esto ocurre, el atacante actúa con los permisos del usuario con el que la aplicación se conecta a la base de datos, por lo que el alcance del daño que puede causar viene determinado directamente por esos permisos. Si la aplicación se conecta con un usuario que tiene su propio acceso limitado exclusivamente a su base de datos y solo a las operaciones que realmente necesita, como leer y escribir en ciertas tablas, entonces un atacante que comprometa la aplicación solo podrá hacer esas operaciones limitadas, sin poder acceder a otras bases de datos, ni borrar la base entera, ni crear usuarios, ni realizar otras acciones peligrosas, de modo que el incidente, aunque grave, queda contenido. En cambio, si la aplicación se conecta con el usuario administrador, que tiene todos los permisos sobre todo, un atacante que comprometa la aplicación obtiene control total de la base de datos, pudiendo robar o destruir todos los datos y causar un daño catastrófico. Existe la tentación de conectar las aplicaciones con el usuario administrador o con un usuario de muchos permisos para evitar tener que preocuparse por los permisos y por los errores que puedan surgir si a la aplicación le falta alguno, pero esta comodidad tiene un coste de seguridad altísimo, ya que convierte cualquier fallo de la aplicación en un compromiso total de la base de datos. Por ello, la práctica correcta y muy recomendable es crear para cada aplicación un usuario propio, no compartido con otras aplicaciones ni con personas, con acceso restringido únicamente a su base de datos y con solo los permisos correspondientes a las operaciones que la aplicación necesita realizar. Esta medida, que es una aplicación directa del principio de privilegio mínimo, es una de las defensas más rentables y eficaces para proteger una base de datos, ya que limita drásticamente el impacto de los fallos de seguridad de las aplicaciones que la utilizan.

**¿Cuál es la diferencia entre un usuario y un rol?**
La diferencia entre un usuario y un rol es que un usuario es una identidad que se conecta a la base de datos, es decir, responde a la pregunta de quién accede, mientras que un rol es una agrupación de permisos con un nombre, es decir, responde a la pregunta de qué se puede hacer, de modo que los usuarios se conectan y los roles se asignan a los usuarios para otorgarles conjuntos de permisos. Un usuario representa una identidad concreta que puede autenticarse y conectarse a la base de datos, habitualmente mediante un nombre y una contraseña, y puede corresponder a una persona o, muy frecuentemente, a una aplicación que se conecta para operar. El usuario es, por tanto, el sujeto que accede a la base de datos y que realiza las operaciones, y es a él a quien se le atribuyen unos permisos que determinan qué puede hacer. Un rol, en cambio, no es una identidad que se conecte, sino un conjunto de permisos agrupados bajo un nombre que representa una función, como por ejemplo solo lectura o editor de una determinada área. El rol no accede por sí mismo a la base de datos, sino que se asigna a los usuarios para concederles de una sola vez todos los permisos que agrupa. Dicho de otro modo, el usuario es quien se conecta y actúa, y el rol es una plantilla o paquete de permisos que se le da al usuario para definir lo que puede hacer. La relación entre ambos es que a un usuario se le pueden asignar uno o varios roles, y al hacerlo el usuario adquiere todos los permisos que esos roles contienen, sumándose así las capacidades. Esta separación entre la identidad, que es el usuario, y el conjunto de permisos, que es el rol, es precisamente lo que aporta las ventajas de los roles, ya que permite definir los permisos una vez en el rol y asignarlos a muchos usuarios, gestionarlos de forma centralizada modificando el rol, y mantener la consistencia entre todos los usuarios que desempeñan la misma función. Es importante no confundir ambos conceptos, ya que aunque en algunos sistemas de bases de datos la distinción entre usuarios y roles puede ser flexible y a veces se manejan de forma unificada, conceptualmente cumplen papeles distintos: el usuario es el quién y el rol es el qué. Comprender esta diferencia es esencial para diseñar correctamente el control de acceso, asignando a cada usuario los roles apropiados según su función y aplicando el principio de privilegio mínimo tanto en el diseño de los roles, que deben otorgar solo los permisos necesarios para su función, como en la asignación de roles a los usuarios, que deben recibir solo los roles que realmente necesitan.

## Fuentes

Documentación oficial y material de la comunidad consultados para esta guía. Fecha de consulta: 28 de julio de 2026.

### Aportes de la comunidad Underc0de

1. **Underc0de, foro.** [Bases de datos](https://underc0de.org/foro/bases-de-datos/). Seguridad y control de acceso.
2. **Underc0de, foro.** [Seguridad informática](https://underc0de.org/foro/seguridad-informatica/). Gestión de privilegios.

### Documentación oficial

1. **PostgreSQL.** [Database Roles](https://www.postgresql.org/docs/current/user-manag.html). Roles y privilegios.
2. **Oracle (MySQL).** [Access Control](https://dev.mysql.com/doc/refman/8.0/en/access-control.html). Usuarios y privilegios.
3. **OWASP.** [Database Security Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Database_Security_Cheat_Sheet.html). Buenas prácticas.
4. **NIST.** [Least Privilege](https://csrc.nist.gov/glossary/term/least_privilege). El principio de privilegio mínimo.

## Guías relacionadas

- [Asegurar MySQL/MariaDB](../../linux/como-asegurar-mysql-o-mariadb-en-un-servidor-linux/index.md)
- [MySQL: primeros pasos](../mysql-instalacion-y-primeros-pasos/index.md)
- [Respaldos y restauración](../respaldos-y-restauracion-de-bases-de-datos/index.md)
- [SIEM y SOC](../../seguridad-informatica/que-es-un-siem-y-como-funciona-un-soc/index.md)
- [Índice de Bases de datos](../index.md)