sql >> Databasteknik >  >> RDS >> Mysql

Hur man hanterar privilegier med roller i MySQL


Introduktion

Åtkomstkontroll och användarhantering är två områden som snabbt kan bli komplexa när antalet användare och olika databasenheter inom ditt system ökar. Hantera många olika privilegier på olika databasobjekt, se till att användare som har samma ansvar har samma åtkomstnivå, och granskning och begränsning av åtkomst blir allt svårare med tiden.

För att hjälpa till med detta har MySQL ett koncept som kallas "roller" som låter dig gruppera buntar av privilegier under ett givet namn, vilket gör att du kan tilldela och ändra inställningar i massor. I den här guiden går vi igenom hur roller fungerar inom MySQL och hur man använder dem för att göra det enklare att hantera dataåtkomst för dina användare.


Kommandon

Här är de primära SQL-kommandon som vi kommer att diskutera i samband med att hantera MySQL-roller.

  • CREATE ROLE :CREATE ROLE kommandot definierar en ny roll i databassystemet.
  • DROP ROLE :DROP ROLE kommandot gör det motsatta, tar bort en befintlig roll.
  • GRANT :GRANT kommandot har två distinkta syften relaterade till roller:lägga till privilegier till roller och lägga till användarkonton som medlemmar av roller.
  • REVOKE :I samband med roller, REVOKE kommandot tar bort privilegier från en roll och tar även bort rollmedlemskap från användarkonton.
  • SHOW GRANTS :SHOW GRANTS kommandot visar privilegierna för det givna användarkontot eller rollen.
  • SET ROLE :SET ROLE kommandot ändrar rollerna som ett användarkonto aktivt använder. Detta låter dig diktera vilka uppsättningar behörigheter som gäller för kontot för sessionen.
  • SET DEFAULT ROLE :SET DEFAULT ROLE kommandot definierar de roller som automatiskt tillämpas på när en klient loggar in som ett specifikt användarkonto.


Obligatoriska rättigheter

För att följa med i den här guiden behöver du följande privilegier:

  • CREATE ROLE
  • GRANT OPTION
  • CREATE USER (för att ställa in standardrollerna för en annan användare)
  • ROLE_ADMIN (för att ställa in systemvariabler som ändrar rollbeteende)
  • SYSTEM_VARIABLES_ADMIN (för att ställa in systemvariabler som ändrar rollbeteende)

CREATE ROLE privilegiet är en mindre version av CREATE USER privilegium, så att du kan skapa och hantera roller. Konton som redan har CREATE USER behörighet har automatiskt alla funktioner som krävs för att hantera roller.

GRANT OPTION privilegier krävs för att tilldela privilegier till en roll. Du måste ha GRANT OPTION aktiverat för alla privilegier som du vill tilldela en roll.




Vad är roller?

I MySQL är en roll en enhet som fungerar som en behållare eller samling av privilegier. Administratörer kan tilldela privilegier till roller på samma sätt som de tilldelar privilegier till användarkonton. Du kan sedan lägga till användarkonton som medlemmar av rollen, vilket ger dessa konton åtkomst till de privilegier som är kopplade till rollen.

I grund och botten fungerar roller som ett sätt att kombinera olika relaterade privilegier för att göra privilegiehantering enklare. Istället för att se till att varje användare har exakt den åtkomstnivå de behöver genom att tilldela individuella privilegier, kan du använda namngivna grupper av privilegier för att hantera färre, lättare att förstå tilldelningar.

Detta har en klar fördel när man tilldelar åtkomstnivåer, eftersom det är lättare att tilldela en developer , sysadmin , eller financeteam roll för en användare än att individuellt hantera dussintals privilegier. Det gör det också snabbt att justera åtkomst till flera konton samtidigt. Om du skapar en ny databas för säljteamet kan du ge salesteam rollåtkomst till det istället för att spåra alla konton som borde ha åtkomst.



Skapa roller

Om du har ett konto med CREATE ROLE privilegium kan du hantera roller med CREATE ROLE kommando.


Vad är MySQL:s syntax för roller?

Rollnamn måste följa ett specifikt format för att MySQL ska anses vara giltiga. På många sätt speglar de formatet som används för att definiera MySQL-användarkonton, men med några viktiga skillnader.

Roller följer följande format:

'<role>'@'<host>'

Liksom användare har roller två komponenter:rollnamnet och den värd som klienten ansluter från. Men hur MySQL tolkar dessa komponenter skiljer sig åt.

Med roller, '<role>' en del av namnet får aldrig vara tom. Det finns inget koncept för att en roll ska vara "anonym" som det är med användare. Å andra sidan, utelämna '<host>' del är fortfarande tillåtet, och MySQL kommer att använda % som värd. Men % i detta sammanhang tolkas som en bokstavlig karaktär, inte ett jokertecken.

Detta innebär i praktiken att även om rollnamn ytligt delar formatet på användarkontonamnen, så genomgår de inte någon typ av utvärdering som användarkonton gör och är bara en etikett med två komponenter. Anledningen till att de gör har två delar till sitt namn är att man kan skapa användarkonton som kan fungera som både användare och roller. När de används som användare är komponenterna föremål för de särskilda utvärderingsreglerna som beskrivs i användarhanteringsartikeln och när de används som en roll matchas namnet bara direkt med hjälp av de bokstavliga komponentnamnen.

På grund av dessa regler väljer administratörer i många fall att definiera roller med endast '<role>' komponent. Detta får MySQL att ersätta en bokstavlig % tecken för '<host>' komponent, vilket effektivt gör den delen av namnet osynlig och betydelselös. Om du inte har för avsikt att ett namn ska användas som både ett användarkonto och en roll, kan du göra detsamma.



Hur skapar du roller?

För att skapa nya roller, använd CREATE ROLE kommando.

Den grundläggande syntaxen ser ut så här:

CREATE ROLE '<role>'@'<host>';

Du kan också skapa flera roller samtidigt genom att separera varje rollnamn med ett kommatecken:

CREATE ROLE '<role_1>'@'<host>', '<role_2>'@'<host>', '<role_3>'@'<host>';

Om någon av rollerna du anger redan finns i systemet, kommer kommandot att misslyckas med ett fel.

För att undvika detta och få MySQL att bara utfärda en varning kan du inkludera IF NOT EXISTS sats efter CREATE ROLE kommandot före rollnamnen:

CREATE ROLE IF NOT EXISTS '<role>'@'<host>';

Som nämnts ovan utelämnar administratörer '<host>' många gånger del av rollnamnet för enkelhets skull, underförstått ställer du in den till bokstaven % karaktär. Så i praktiken kan många av dina rollskapande kommandon se mer ut så här:

CREATE ROLE '<role>';



Hur ger man privilegier till en roll?

När du har skapat nya roller är din nästa prioritet vanligtvis att göra dem meningsfulla genom att ge dem privilegier.

Du ger privilegier till roller på samma sätt som du ger privilegier till användarkonton. Du anger exakt de privilegier du vill bevilja, anger ett omfång genom att tillhandahålla databasen och databasobjektet där privilegiet är giltigt, och den enhet som ska beviljas privilegierna – i det här fallet en roll:

GRANT <privileges> ON <database>.<object> TO '<role>'@'<host>';

Till exempel för att ge SELECT privilegium till en roll som heter readappappdb databasen och alla objekt den innehåller, kan du skriva:

GRANT SELECT ON appdb.* TO 'readapp';

På samma sätt kan du ge skrivbehörigheter till samma databas till en roll som heter writeapp genom att skriva:

GRANT SELECT,INSERT,UPDATE,DELETE ON appdb.* TO 'writeapp';

Du kan ge privilegier till och återkalla dem från roller precis som du skulle göra direkt med användarkonton. Så du kan alltid ändra de privilegier som är kopplade till en roll om du behöver justera åtkomstnivån du vill ge.



Hur beviljar du användare medlemskap till en roll?

När du har lagt till privilegier till dina roller kan du börja lägga till medlemmar i rollen för att ge dem associerade privilegier.

För att göra detta använder MySQL en annan form av samma GRANT vi använder för att ge privilegier till användare och roller. Det här nya formuläret lägger dock till roller till en användare, vilket ger användarkontot åtkomst till alla privilegier som ges till rollen.

Den grundläggande syntaxen ser ut så här:

GRANT '<role>'@'<host>' TO '<user>'@'<host>';

Till exempel, om 'reports'@'localhost' användaren måste kunna läsa data från appdb databas för att generera rapporter kan vi lägga till readapp roll till användarkontot, vilket ger det valda privilegier:

GRANT 'readapp' TO 'reports'@'localhost';

På samma sätt, för att ge 'appuser'@'localhost' möjligheten att hantera data inom samma databas, kan vi göra den användaren till medlem i writeapp roll:

GRANT 'writeapp' TO 'appuser'@'localhost';

'appuser'@'localhost' kontot kommer nu att ha möjlighet att infoga, uppdatera och ta bort data från databasen. Om nya privilegier läggs till i writeapp rollen, 'appuser'@'localhost' kontot kommer omedelbart att få dessa privilegier.


Hur beviljar du automatiskt vissa roller till varje användare?

Ibland kan det finnas roller som du vill att alla användare på ditt system ska ha tillgång till. Du kan definiera vilka roller varje konto automatiskt beviljas genom att ställa in mandatory_roles variabel.

För att ändra mandatory_roles variabeln måste din användare ha ROLE_ADMIN och SYSTEM_VARIABLES_ADMIN privilegier. Du kan ställa in de roller du vill ge till varje användare genom att skriva:

SET PERSIST mandatory_roles = '`<role_1>`@`<host>`, `<role_2>`@`<host>`, `<role_3>`@`<host>`';

Här ger vi varje användare på systemet tre roller automatiskt. När du ställer in systemvariabeln, värdet på mandatory_roles måste vara en sträng, så vi kapslar in hela rolllistan i enstaka citattecken och använder backticks för att citera enskilda rollkomponenter.

Du kan inte lägga till en roll till mandatory_roles lista som har SYSTEM_USER privilegium. Detta är en säkerhetsåtgärd för att säkerställa att inte alla sessioner på systemet automatiskt är systemsessioner.




Hur använder du privilegier från roller?

När du har beviljat användarkontomedlemskap till roller, hur använder du dem? För att få åtkomst till de privilegier som ges till ett konto av en roll, måste det aktiveras.


Visa de nuvarande aktiva rollerna

Innan du aktiverar nya roller kan du kontrollera vilka roller som för närvarande är aktiva för din användarsession.

För att se de aktiva rollerna för din session, skriv:

SELECT CURRENT_ROLE()

Utdata kommer att visa noll eller fler roller som är aktiva i din nuvarande session. Behörigheterna som är kopplade till dessa roller kommer att lägga till vilka åtgärder du får utföra.



Hur man aktiverar roller för sessionen

För att ändra vilka roller som är aktiva under din session, använd SET ROLE kommando. Du kan använda det här kommandot på ett antal olika sätt.

Den grundläggande syntaxen ser ut så här:

SET ROLE '<rolename>'@'<host>';

Detta kommer att aktivera rollen i fråga. Det är viktigt att notera att alla tidigare aktiva roller som inte nämns i SET ROLE kommandot kommer nu att avaktiveras.

För att aktivera mer än en roll åt gången, separera varje roll med ett kommatecken:

SET ROLE '<role_1>'@'<host>', '<role_2>'@'<host>', '<role_3>'@'<host>';

För att aktivera alla roller som har tilldelats ditt konto kan du ange ALL istället för en specifik roll:

SET ROLE ALL;

Du kan också be MySQL att aktivera alla dina roller med specifika undantag genom att använda ALL EXCEPT :

SET ROLL ALL EXCEPT '<role_1>'@'<host>';

Ett annat alternativ är att inaktivera alla roller på ditt konto genom att ange NONE :

SET ROLE NONE

Detta kommer att inaktivera alla dina användarroller för sessionen, vilket ger dig endast de privilegier som specifikt tilldelats ditt användarkonto.

För att komma tillbaka till standardlistan över roller som definierats för ditt konto, använd DEFAULT nyckelord:

SET ROLE DEFAULT


Hur man definierar standardroller för ett användarkonto

Rollerna som aktiveras automatiskt när du loggar in som användare och de som återaktiveras när du använder SET ROLE DEFAULT är konfigurerbara.

För att definiera de roller som kommer att aktiveras som standard, använd SET DEFAULT ROLE kommando som liknar hur du använder SET ROLE kommando:

SET DEFAULT ROLE '<role_1>'@'<host>';

Detta kommer att ställa in standardrollerna som kommer att aktiveras för ditt eget konto vid inloggning eller vid användning av SET ROLE DEFAULT .

Om din användare har koden CREATE USER privilegium kan du ställa in standardrollerna för andra konton:

SET DEFAULT ROLE ALL TO '<user>'@'<host>';

Här anger vi att '<user>'@'<host>' kontot bör automatiskt aktivera alla sina roller vid autentisering.

Den här syntaxen kan också användas för att definiera standardrollerna för mer än ett konto genom att separera varje användare med ett kommatecken:

SET DEFAULT ROLE ALL TO '<user_1>'@'<host>', '<user_2>'@'<host>';


Aktivera alla roller för alla användare som standard

Om du vill att alla konton på din MySQL-server ska aktivera alla sina roller som standard, kan du ändra en systeminställning för att göra det.

När activate_all_roles_on_login variabeln är inställd på true, kommer MySQL automatiskt att aktivera alla roller som är kopplade till ett konto vid inloggning. Detta ersätter inställningarna som anges av SET DEFAULT ROLE .

För att aktivera den här funktionen måste du ha SYSTEM_VARIABLES_ADMIN och ROLE_ADMIN privilegier. Aktivera funktionen genom att skriva:

SET PERSIST activate_all_roles_on_login = ON;

Detta gör att användarkonton automatiskt aktiverar alla roller vid inloggning. Men SET ROLE DEFAULT kommer fortfarande att tillåta dig att aktivera endast de standardroller som är kopplade till ett konto.




Visa befintliga privilegier som erhållits från roller

För att förstå vilka privilegier som är tillgängliga på ditt konto kan du använda SHOW GRANTS kommando.

För att kontrollera vilka anslag som är aktiverade för en användare, skriv:

SHOW GRANTS FOR '<user>'@'<host>';

Utdatat kommer att visa dig alla privilegier som är direkt tilldelade användarkontot samt alla roller som användaren är medlem i.

När du har lärt dig vilka roller ett konto är medlem i kan du kontrollera vilka privilegier rollerna ger användaren genom att skriva:

SHOW GRANTS FOR '<user>'@'<host>' USING '<role>'@'<host>';

Till exempel för att kontrollera privilegierna för 'reports'@'localhost' användare, inklusive de som beviljats ​​av dess medlemskap i readapp roll kan du använda:

SHOW GRANTS FOR 'reports'@'localhost' USING 'readapp';

Detta kommer att visa dig alla privilegier som uttryckligen beviljats ​​'reports'@'localhost' användarkonton såväl som de som lagts till av readapp roll.



Återkalla en roll från en användare

Så vad händer när du vill ta bort en roll från en användare? Liknar hur GRANT kommandot kan antingen lägga till nya privilegier till en användare eller roll eller lägga till roller till en användare, REVOKE kommando kan ta bort privilegier från en användare eller roll och kan också ta bort rollmedlemskap från en användare.

Den grundläggande syntaxen som används för att ta bort en roll från ett användarkonto ser ut så här:

REVOKE '<role>' FROM '<user>'@'<host>';

Efter att ha kört en sats som denna kommer användaren inte längre att ha tillgång till de privilegier som beviljades genom rollen.

Som ett exempel kan vi återkalla writeapp roll från 'appuser'@'localhost' användarkonto genom att skriva:

REVOKE 'writeapp' FROM 'appuser'@'localhost';

Om användaren har beviljats ​​ett privilegium på andra sätt (antingen direkt beviljat eller beviljat genom medlemskap med en annan roll) kommer de fortfarande att ha åtkomst till det privilegiet. Så om 'appuser'@'localhost' användaren var också medlem i readapp roll som vi gav tidigare, skulle de fortfarande ha SELECT privilegier på appdb databas.



Slutsats

Att använda roller för att distribuera privilegier i dina MySQL-databaser kan hjälpa till att förenkla administrationskostnaderna och komplexiteten i ditt åtkomstkontrollsystem. Det är mycket enklare att se till att användare med samma ansvar har samma privilegier med roller än att ge många olika privilegier direkt.

På samma sätt tillåter roller dig att vara tydlig om avsikten bakom din privilegiegivning. Istället för att ge ett stort antal privilegier till konton utan några kommentarer, kan noggrant utvalda rollnamn hjälpa till att skilja mellan olika orsaker till åtkomst. Genom att ta dig tid att skapa och organisera roller i förväg blir din förmåga att hantera användaråtkomst till olika delar av din data enklare i det långa loppet.




  1. MySQL-tidszon ändras?

  2. *VARNING* Kan inte öppna fler databaser buggar med Microsoft Office build 2201

  3. Varför uppstod ett nätverksrelaterat eller instansspecifikt fel när en anslutning till SQL Server upprättades?

  4. Django modellerar en främmande nyckel till många tabeller