Siempre es un dolor de cabeza... necesita agregar un nuevo rol de usuario o cambiar algunos privilegios, y debe asignarlo uno... por... uno. Este es un deber habitual, especialmente en organizaciones grandes, o en una empresa donde tiene una estructura de privilegios compleja, o incluso si tiene que administrar una gran cantidad de usuarios de bases de datos.
Por ejemplo, supongamos que necesita agregar el privilegio ACTUALIZAR a una base de datos específica para todo el equipo de control de calidad, si son un equipo de cinco no hay problema, pero si son 50... o 100... eso puede endurecerse. Por supuesto, siempre puedes escribir un guión para ello, pero de esta forma siempre hay riesgo.
En este blog, veremos cómo podemos resolver este problema de administración de usuarios de la base de datos mediante el uso de roles y con consejos específicos sobre cómo usarlos con MariaDB.
¿Qué es un rol?
En el mundo de las bases de datos, un rol es un grupo de privilegios que se pueden asignar a uno o más usuarios, y un usuario puede tener uno o más roles asignados. Para hacer una comparación, es como un grupo en el sistema operativo Linux.
Si vemos el ejemplo anterior sobre el privilegio de ACTUALIZAR en el equipo de QA, si tenemos el rol de QA creado, y todos los miembros de QA tienen asignado este rol, no importa la cantidad de miembros, solo necesita cambiar el privilegio en este rol de control de calidad y se propagará a todos los usuarios de control de calidad.
Funciones en MariaDB
Para administrar roles en MariaDB, debe crear el rol con la declaración CREATE ROLE, asignar el privilegio a ese rol con una declaración GRANT y luego asignar el privilegio al usuario para poder usar este rol. También puede establecer un rol predeterminado, para que el usuario lo asuma cuando se conecte.
Como usuario de la base de datos, debe establecer el rol cuando acceda a la base de datos (si no hay un rol predeterminado), y puede cambiar el rol si es necesario con una instrucción SET ROLE.
Desde el lado de la aplicación, debería poder establecer el rol (o usar el predeterminado) antes de consultar para que esto funcione, por lo que en aplicaciones antiguas, podría ser complejo de implementar.
Veamos algunas especificaciones para Roles en MariaDB.
- Solo un rol puede estar activo al mismo tiempo para el usuario actual.
- Desde MariaDB 10.1 tenemos un rol predeterminado. Este rol se habilita automáticamente cuando el usuario se conecta.
- Los roles se almacenan en la memoria.
Cómo verificar roles
En MariaDB hay varias formas de comprobarlo:
- MOSTRAR CONCESIONES [PARA (usuario | función)]:enumera las concesiones para el usuario actual o para uno específico.
MariaDB [testing]> SHOW GRANTS for [email protected]'%'; +----------------------------------------------------------------------------------------------------------+ | Grants for [email protected]% | +----------------------------------------------------------------------------------------------------------+ | GRANT USAGE ON *.* TO 'testuser'@'%' IDENTIFIED BY PASSWORD '*FAAFFE644E901CFAFAEC7562415E5FAEC243B8B2' | +----------------------------------------------------------------------------------------------------------+ 1 row in set (0.000 sec) - SELECCIONE usuario DESDE mysql.user WHERE is_role='Y':Liste los roles creados en la base de datos.
MariaDB [testing]> SELECT user FROM mysql.user WHERE is_role='Y'; +--------+ | user | +--------+ | qateam | +--------+ 1 row in set (0.000 sec) - SELECT * FROM information_schema.applicable_roles:es una lista de roles disponibles para el usuario actual.
MariaDB [testing]> SELECT * FROM information_schema.applicable_roles; +-------------+-----------+--------------+------------+ | GRANTEE | ROLE_NAME | IS_GRANTABLE | IS_DEFAULT | +-------------+-----------+--------------+------------+ | [email protected]% | qateam | NO | NO | +-------------+-----------+--------------+------------+ 1 row in set (0.000 sec) - SELECT * FROM information_schema.enabled_roles:muestra las funciones activas actuales.
MariaDB [testing]> SELECT * FROM information_schema.enabled_roles; +-----------+ | ROLE_NAME | +-----------+ | qateam | +-----------+ 1 row in set (0.000 sec) - SELECT * FROM mysql.roles_mapping:muestra las relaciones entre los roles y las concesiones de usuarios.
MariaDB [testing]> SELECT * FROM mysql.roles_mapping; +-----------+-----------+--------+--------------+ | Host | User | Role | Admin_option | +-----------+-----------+--------+--------------+ | localhost | root | qateam | Y | | % | testuser | qateam | N | +-----------+-----------+--------+--------------+ 2 rows in set (0.000 sec)
Cómo administrar roles en MariaDB
Veamos un ejemplo de cómo administrarlo en MariaDB. En este caso, usaremos la versión MariaDB 10.3 que se ejecuta en CentOS 7.
Primero, creemos un nuevo usuario de base de datos:
MariaDB [testing]> CREATE USER [email protected]'%' IDENTIFIED BY 'PASSWORD';Si revisamos las concesiones para este nuevo usuario, veremos algo como esto:
MariaDB [testing]> SHOW GRANTS for [email protected]'%';
+----------------------------------------------------------------------------------------------------------+
| Grants for [email protected]% |
+----------------------------------------------------------------------------------------------------------+
| GRANT USAGE ON *.* TO 'testuser'@'%' IDENTIFIED BY PASSWORD '*FAAFFE644E901CFAFAEC7562415E5FAEC243B8B2' |
+----------------------------------------------------------------------------------------------------------+
1 row in set (0.000 sec)Ahora, intentemos iniciar sesión con este usuario y conectarnos a la base de datos de prueba:
$ mysql -utestuser -p
Enter password:
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 54
Server version: 10.3.16-MariaDB-log MariaDB Server
Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.MariaDB [(none)]> use testing
ERROR 1044 (42000): Access denied for user 'testuser'@'%' to database 'testing'Como pudimos ver, no podemos conectarnos a la base de datos de prueba con este usuario, entonces, ahora, crearemos un rol "qateam" con los privilegios y le asignaremos este rol a este nuevo usuario.
MariaDB [testing]> CREATE ROLE qateam;
Query OK, 0 rows affected (0.001 sec)MariaDB [testing]> GRANT SELECT,INSERT,UPDATE,DELETE ON testing.* TO qateam;
Query OK, 0 rows affected (0.000 sec)Si intentamos usar este rol sin GRANT, veremos el siguiente error:
MariaDB [(none)]> SET ROLE qateam;
ERROR 1959 (OP000): Invalid role specification `qateam`Entonces, ahora ejecutaremos GRANT para permitir que el usuario lo use:
MariaDB [(none)]> GRANT qateam TO [email protected]'%';
Query OK, 0 rows affected (0.000 sec)Establezca el rol para el usuario actual:
MariaDB [(none)]> SET ROLE qateam;
Query OK, 0 rows affected (0.000 sec)E intente acceder a la base de datos:
MariaDB [(none)]> use testing;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed
MariaDB [testing]>Podemos verificar las concesiones para el usuario actual:
MariaDB [(none)]> SHOW GRANTS for [email protected]'%';
+----------------------------------------------------------------------------------------------------------+
| Grants for [email protected]% |
+----------------------------------------------------------------------------------------------------------+
| GRANT qateam TO 'testuser'@'%' |
| GRANT USAGE ON *.* TO 'testuser'@'%' IDENTIFIED BY PASSWORD '*FAAFFE644E901CFAFAEC7562415E5FAEC243B8B2' |
+----------------------------------------------------------------------------------------------------------+
2 rows in set (0.000 sec)Y el rol actual:
MariaDB [testing]> SELECT CURRENT_ROLE;
+--------------+
| CURRENT_ROLE |
+--------------+
| qateam |
+--------------+
1 row in set (0.000 sec)Aquí podemos ver la concesión para el rol de qateam, y eso es todo, no tenemos el privilegio asignado directamente al usuario, tenemos los privilegios para el rol y el usuario toma los privilegios de allí.
Conclusión
La gestión de roles puede facilitarnos la vida en grandes empresas o bases de datos con un elevado número de usuarios que acceden a ella. Si queremos utilizarlo desde nuestra aplicación, debemos tener en cuenta que la aplicación también debe poder gestionarlo.
