Het is altijd lastig... je moet een nieuwe gebruikersrol toevoegen of een aantal privileges wijzigen, en je moet het een... voor... een toewijzen. Dit is een normale taak, vooral in grote organisaties, of in een bedrijf waar u een complexe privilegestructuur heeft, of zelfs als u een groot aantal databasegebruikers moet beheren.
Laten we bijvoorbeeld zeggen dat u het UPDATE-privilege moet toevoegen aan een specifieke database voor het hele QA-team, als ze een team van vijf zijn, is er geen probleem, maar als ze 50... of 100... zijn, kan dat hard worden. Je kunt er natuurlijk altijd een script voor schrijven, maar op deze manier is er altijd een risico.
In deze blog zullen we zien hoe we dit probleem met het beheer van databasegebruikers kunnen oplossen door rollen te gebruiken en met specifieke tips voor het gebruik ervan met MariaDB.
Wat is een rol?
In de databasewereld is een rol een groep privileges die aan een of meer gebruikers kan worden toegewezen, en aan een gebruiker kan een of meer rollen worden toegewezen. Om een vergelijking te maken, het is als een groep op Linux OS.
Als we het vorige voorbeeld zien over het UPDATE-privilege op het QA-team, als we de QA-rol hebben gemaakt en alle QA-leden hebben deze rol toegewezen, maakt het niet uit hoeveel leden, u hoeft alleen het recht te wijzigen op deze QA-rol en deze zal worden verspreid voor alle QA-gebruikers.
Rollen op MariaDB
Om rollen op MariaDB te beheren, moet u de rol maken met de CREATE ROLE-instructie, het privilege aan die rol toewijzen met een GRANT-instructie en vervolgens het privilege toewijzen aan de gebruiker om deze rol te kunnen gebruiken. Je kunt ook een standaardrol instellen, zodat de gebruiker deze overneemt bij het verbinden.
Als databasegebruiker moet u de rol instellen wanneer u de database opent (als er geen standaardrol is), en u kunt de rol indien nodig wijzigen met een SET ROLE-instructie.
Aan de kant van de applicatie moet je de rol kunnen instellen (of de standaard gebruiken) voordat je een query uitvoert om dit te laten werken, dus in oude applicaties kan het ingewikkeld zijn om te implementeren.
Laten we eens kijken naar wat specificaties voor rollen op MariaDB.
- Er kan slechts één rol tegelijkertijd actief zijn voor de huidige gebruiker.
- Sinds MariaDB 10.1 hebben we een standaardrol. Deze rol wordt automatisch ingeschakeld wanneer de gebruiker verbinding maakt.
- Rollen worden in het geheugen opgeslagen.
Hoe rollen te controleren
Op MariaDB zijn er meerdere manieren om het te controleren:
- TOET SUBSIDIES [ VOOR (gebruiker | rol) ]:Lijst van de subsidies voor de huidige gebruiker of voor een specifieke.
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) - SELECT user FROM mysql.user WHERE is_role='Y':Lijst met de rollen die in de database zijn gemaakt.
MariaDB [testing]> SELECT user FROM mysql.user WHERE is_role='Y'; +--------+ | user | +--------+ | qateam | +--------+ 1 row in set (0.000 sec) - SELECTEER * FROM information_schema.applicable_roles:het is een lijst met beschikbare rollen voor de huidige gebruiker.
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) - SELECTEER * FROM information_schema.enabled_roles:lijst de huidige actieve rollen op.
MariaDB [testing]> SELECT * FROM information_schema.enabled_roles; +-----------+ | ROLE_NAME | +-----------+ | qateam | +-----------+ 1 row in set (0.000 sec) - SELECT * FROM mysql.roles_mapping:Maak een lijst van de relaties tussen rollen en gebruikerstoelagen.
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)
Hoe rollen op MariaDB te beheren
Laten we een voorbeeld bekijken van hoe u het op MariaDB kunt beheren. In dit geval gebruiken we MariaDB 10.3-versie die draait op CentOS 7.
Laten we eerst een nieuwe databasegebruiker maken:
MariaDB [testing]> CREATE USER [email protected]'%' IDENTIFIED BY 'PASSWORD';Als we de subsidies voor deze nieuwe gebruiker controleren, zien we zoiets als dit:
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)Laten we nu proberen in te loggen met deze gebruiker en verbinding te maken met de testdatabase:
$ 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'Zoals we konden zien, kunnen we geen verbinding maken met de testdatabase met deze gebruiker, dus nu zullen we een "qateam" -rol maken met de privileges en we zullen deze rol toewijzen aan deze nieuwe gebruiker.
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)Als we deze rol proberen te gebruiken zonder de GRANT, zien we de volgende fout:
MariaDB [(none)]> SET ROLE qateam;
ERROR 1959 (OP000): Invalid role specification `qateam`Dus nu zullen we de GRANT uitvoeren zodat de gebruiker deze kan gebruiken:
MariaDB [(none)]> GRANT qateam TO [email protected]'%';
Query OK, 0 rows affected (0.000 sec)Stel de rol in op de huidige gebruiker:
MariaDB [(none)]> SET ROLE qateam;
Query OK, 0 rows affected (0.000 sec)En probeer toegang te krijgen tot de database:
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]>We kunnen de subsidies voor de huidige gebruiker controleren:
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)En de huidige rol:
MariaDB [testing]> SELECT CURRENT_ROLE;
+--------------+
| CURRENT_ROLE |
+--------------+
| qateam |
+--------------+
1 row in set (0.000 sec)Hier kunnen we de toekenning zien voor de qateam-rol, en dat is het, we hebben niet het privilege dat rechtstreeks aan de gebruiker is toegewezen, we hebben de privileges voor de rol en de gebruiker neemt de privileges van daaruit over.
Conclusie
Het beheren van rollen kan ons leven gemakkelijker maken in grote bedrijven of databases met een groot aantal gebruikers die er toegang toe hebben. Als we het willen gebruiken vanuit onze applicatie, moeten we er rekening mee houden dat de applicatie het ook moet kunnen beheren.