En un sistema de administración de bases de datos (DBMS), los controles de acceso basados en roles (RBAC) son una restricción de los recursos de la base de datos basada en un conjunto de grupos de privilegios predefinidos y se ha convertido en uno de los principales Métodos para el control de acceso avanzado. Los roles de la base de datos se pueden crear y eliminar, así como otorgarles y revocarles privilegios. Los roles se pueden otorgar y revocar desde cuentas de usuario individuales. Los roles activos aplicables para una cuenta pueden seleccionarse entre los otorgados a la cuenta y cambiarse durante las sesiones de esa cuenta.
En esta publicación de blog, cubriremos algunos consejos y trucos sobre el uso de la función de la base de datos para administrar los privilegios de los usuarios y como un mecanismo de control de acceso avanzado para el acceso a nuestra base de datos. Si desea obtener información sobre los conceptos básicos de los roles en MySQL y MariaDB, consulte esta publicación de blog, Administración de usuarios de bases de datos:administración de roles para MariaDB.
Funciones de MySQL frente a MariaDB
MySQL y MariaDB usan dos mecanismos de roles diferentes. En MySQL 8.0 y posteriores, el rol es similar a otro usuario, con nombre de usuario y host ('role1'@'localhost'). Sí, ese es el nombre del rol, que es prácticamente similar a la definición estándar de usuario-host. MySQL almacena la definición de roles al igual que almacenar los privilegios de usuario en la tabla del sistema mysql.user.
MariaDB había introducido funciones y privilegios de acceso en MariaDB versión 10.0.5 (noviembre de 2013), unos buenos 8 años antes de que MySQL incluyera esta característica en MySQL8.0. Sigue una gestión de roles similar en un sistema de base de datos compatible con SQL, más robusto y mucho más fácil de entender. MariaDB almacena la definición en la tabla del sistema mysql.user marcada con una columna recién agregada llamada is_role. MySQL almacena el rol de manera diferente, usando una combinación de usuario-host similar a la administración de usuarios estándar de MySQL.
Dicho esto, la migración de roles entre estos dos DBMS ahora es incompatible entre sí.
Funciones administrativas y de copia de seguridad de MariaDB
MySQL tiene privilegios dinámicos, que proporcionan un conjunto de privilegios para tareas de administración comunes. Para MariaDB, podemos configurar cosas similares usando roles, especialmente para los privilegios de copia de seguridad y restauración. Para MariaDB Backup, dado que es una copia de seguridad física y requiere un conjunto diferente de privilegios, podemos crear un rol específico para que se asigne a otro usuario de la base de datos.
Primero, cree un rol y asígnele los privilegios correctos:
MariaDB> CREATE ROLE mariadb_backup;
MariaDB> GRANT RELOAD, LOCK TABLES, PROCESS, REPLICATION CLIENT ON *.* TO mariadb_backup;Luego podemos crear el usuario de respaldo, otorgarle el rol mariadb_backup y asignarle el rol predeterminado:
MariaDB> CREATE USER [email protected] IDENTIFIED BY 'passw0rdMMM';
MariaDB> GRANT mariadb_backup TO [email protected];
MariaDB> SET DEFAULT ROLE mariadb_backup FOR [email protected];Para mysqldump o mariadb-dump, los privilegios mínimos para crear una copia de seguridad se pueden configurar de la siguiente manera:
MariaDB> CREATE ROLE mysqldump_backup;
MariaDB> GRANT SELECT, SHOW VIEW, TRIGGER, LOCK TABLES ON *.* TO mysqldump_backup;Luego podemos crear el usuario de respaldo, otorgarle el rol mysqldump_backup y asignarle el rol predeterminado:
MariaDB> CREATE USER [email protected] IDENTIFIED BY 'p4ss182MMM';
MariaDB> GRANT mysqldump_backup TO [email protected];
MariaDB> SET DEFAULT ROLE mysqldump_backup FOR [email protected];Para la restauración, normalmente requiere un conjunto diferente de privilegios, que es un poco:
MariaDB> CREATE ROLE mysqldump_restore;
MariaDB> GRANT SUPER, ALTER, INSERT, CREATE, DROP, LOCK TABLES, REFERENCES, SELECT, CREATE ROUTINE, TRIGGER ON *.* TO mysqldump_restore;Luego podemos crear el usuario de restauración, otorgarle la función mysqldump_restore y asignar la función predeterminada:
MariaDB> CREATE USER [email protected] IDENTIFIED BY 'p4ss182MMM';
MariaDB> GRANT mysqldump_restore TO [email protected];
MariaDB> SET DEFAULT ROLE mysqldump_restore FOR [email protected];Al usar este truco, podemos simplificar el proceso de creación de usuarios administrativos al asignar un rol con privilegios predefinidos. Por lo tanto, nuestra declaración GRANT puede acortarse y ser fácil de entender.
Creación de rol sobre rol en MariaDB
Podemos crear otro rol sobre un rol existente similar a una membresía de grupo anidado con un control más detallado sobre los privilegios. Por ejemplo, podríamos crear los siguientes 4 roles:
MariaDB> CREATE ROLE app_developer, app_reader, app_writer, app_structure;Otorgue los privilegios para administrar la estructura del esquema al rol app_structure:
MariaDB> GRANT CREATE, ALTER, DROP, CREATE VIEW, CREATE ROUTINE, INDEX, TRIGGER, REFERENCES ON app.* to app_structure;Otorgue los privilegios para el Lenguaje de manipulación de datos (DML) al rol app_writer:
MariaDB> GRANT INSERT, DELETE, UPDATE, CREATE TEMPORARY TABLES app.* to app_writer;Otorgue los privilegios para el lenguaje de consulta de datos (DQL) al rol app_reader:
MariaDB> GRANT SELECT, LOCK TABLES, SHOW VIEW app.* to app_reader;Y finalmente, podemos asignar todos los roles anteriores a app_developer, que debería tener control total sobre el esquema:
MariaDB> GRANT app_structure TO app_developer;
MariaDB> GRANT app_reader TO app_developer;
MariaDB> GRANT app_writer TO app_developer;Los roles están listos y ahora podemos crear un usuario de base de datos con el rol app_developer:
MariaDB> CREATE USER 'michael'@'192.168.0.%' IDENTIFIED BY 'passw0rdMMMM';
MariaDB> GRANT app_developer TO 'michael'@'192.168.0.%';
MariaDB> GRANT app_reader TO 'michael'@'192.168.0.%';Dado que Michael ahora pertenece a los roles app_deleloper y app_reader, también podemos asignar los privilegios más bajos como el rol predeterminado para protegerlo contra errores humanos no deseados:
MariaDB> SET DEFAULT ROLE app_reader FOR 'michael'@'192.168.0.%';Lo bueno de usar un rol es que puede ocultar los privilegios reales del usuario de la base de datos. Considere el siguiente usuario de la base de datos que acaba de iniciar sesión:
MariaDB> SELECT user();
+----------------------+
| user() |
+----------------------+
| [email protected] |
+----------------------+Al intentar recuperar los privilegios usando SHOW GRANTS, Michael vería:
MariaDB> SHOW GRANTS FOR 'michael'@'192.168.0.%';
+----------------------------------------------------------------------------------------------------------------+
| Grants for [email protected] |
+----------------------------------------------------------------------------------------------------------------+
| GRANT `app_developer` TO `michael`@`localhost` |
| GRANT USAGE ON *.* TO `michael`@`localhost` IDENTIFIED BY PASSWORD '*2470C0C06DEE42FD1618BB99005ADCA2EC9D1E19' |
+----------------------------------------------------------------------------------------------------------------+Y cuando Michael intenta buscar los privilegios de app_developer, ve este error:
MariaDB> SHOW GRANTS FOR FOR app_developer;
ERROR 1044 (42000): Access denied for user 'michael'@'localhost' to database 'mysql'Este truco permite que los DBA muestren solo la agrupación lógica a la que pertenece el usuario y nada más. Podemos reducir el vector de ataque desde este aspecto, ya que los usuarios no tendrán idea de los privilegios reales que se les asignan.
Imposición del rol predeterminado en MariaDB
Al imponer un rol predeterminado, un usuario de la base de datos puede estar protegido en la primera capa contra errores humanos accidentales. Por ejemplo, considere al usuario Michael al que se le ha otorgado el rol app_developer, donde el rol app_developer es un superconjunto de los roles app_strucutre, app_writer y app_reader, como se ilustra a continuación:
Dado que Michael pertenece al rol app_deleloper, también podemos establecer el privilegio más bajo como el rol predeterminado para protegerlo contra la modificación accidental de datos:
MariaDB> GRANT app_reader TO 'michael'@'192.168.0.%';
MariaDB> SET DEFAULT ROLE app_reader FOR 'michael'@'192.168.0.%';En cuanto al usuario "michael", verá lo siguiente una vez que haya iniciado sesión:
MariaDB> SELECT user(),current_role();
+-------------------+----------------+
| user() | current_role() |
+-------------------+----------------+
| [email protected] | app_reader |
+-------------------+----------------+Su función predeterminada es app_reader, que es un privilegio de solo lectura para una base de datos llamada "aplicación". El usuario actual tiene la capacidad de cambiar entre los roles aplicables mediante la función ESTABLECER ROL. En cuanto a Michael, puede cambiar a otro rol usando la siguiente declaración:
MariaDB> SET ROLE app_developer;En este punto, Michael debería poder escribir en la base de datos 'aplicación' ya que app_developer es un superconjunto de app_writer y app_structure. Para verificar los roles disponibles para el usuario actual, podemos consultar la tabla information_schema.applicable_roles:
MariaDB> SELECT * FROM information_schema.applicable_roles;
+-------------------+---------------+--------------+------------+
| GRANTEE | ROLE_NAME | IS_GRANTABLE | IS_DEFAULT |
+-------------------+---------------+--------------+------------+
| [email protected] | app_developer | NO | NO |
| app_developer | app_writer | NO | NULL |
| app_developer | app_reader | NO | NULL |
| app_developer | app_structure | NO | NULL |
| [email protected] | app_reader | NO | YES |
+-------------------+---------------+--------------+------------+De esta manera, estamos configurando una función principal para el usuario, y la función principal puede ser el privilegio más bajo posible para un usuario específico. El usuario debe dar su consentimiento sobre su rol activo, cambiando a otro rol privilegiado antes de ejecutar cualquier actividad de riesgo para el servidor de la base de datos.
Asignación de roles en MariaDB
MariaDB proporciona una tabla de mapeo de roles llamada mysql.roles_mapping. El mapeo nos permite comprender fácilmente la correlación entre un usuario y sus roles, y cómo se asigna un rol a otro rol:
MariaDB> SELECT * FROM mysql.roles_mapping;
+-------------+-------------------+------------------+--------------+
| Host | User | Role | Admin_option |
+-------------+-------------------+------------------+--------------+
| localhost | root | app_developer | Y |
| localhost | root | app_writer | Y |
| localhost | root | app_reader | Y |
| localhost | root | app_structure | Y |
| | app_developer | app_structure | N |
| | app_developer | app_reader | N |
| | app_developer | app_writer | N |
| 192.168.0.% | michael | app_developer | N |
| localhost | michael | app_developer | N |
| localhost | root | mysqldump_backup | Y |
| localhost | dump_user1 | mysqldump_backup | N |
| localhost | root | mariadb_backup | Y |
| localhost | mariabackup_user1 | mariadb_backup | N |
+-------------+-------------------+------------------+--------------+
A partir del resultado anterior, podemos decir que un usuario sin host es básicamente un rol sobre un rol y los usuarios administrativos (Admin_option =Y) también se asignan automáticamente a los roles creados. Para obtener la lista de roles creados, podemos consultar la tabla de usuarios de MySQL:
MariaDB> SELECT user FROM mysql.user WHERE is_role = 'Y';
+------------------+
| User |
+------------------+
| app_developer |
| app_writer |
| app_reader |
| app_structure |
| mysqldump_backup |
| mariadb_backup |
+------------------+Reflexiones finales
El uso de roles puede mejorar la seguridad de la base de datos al proporcionar una capa adicional de protección contra la modificación accidental de datos por parte de los usuarios de la base de datos. Además, simplifica la administración de privilegios y las operaciones de mantenimiento para organizaciones que tienen muchos usuarios de bases de datos.
