Въведение
Контролът на достъпа и управлението на потребителите са две области, които могат бързо да станат сложни, тъй като броят на потребителите и различните обекти на база данни във вашата система се увеличава. Управлението на много различни привилегии върху различни обекти на база данни, гарантиране на едно и също ниво на достъп на потребителите, които имат едни и същи отговорности, и одитът и стесняването на достъпа стават все по-трудни с времето.
За да помогне за справянето с това, MySQL има концепция, наречена "роли", която ви позволява да групирате пакети от привилегии под дадено име, което ви позволява да задавате и променяте настройките масово. В това ръководство ще разгледаме как работят ролите в MySQL и как да ги използвате, за да улесним управлението на достъпа до данни за вашите потребители.
Команди
Ето основните SQL команди, които ще обсъдим във връзка с управлението на MySQL роли.
CREATE ROLE:CREATE ROLEкомандата дефинира нова роля в системата на базата данни.DROP ROLE:DROP ROLEкомандата прави обратното, изтривайки съществуваща роля.GRANT:GRANTкомандата има две различни цели, свързани с ролите:добавяне на привилегии към ролите и добавяне на потребителски акаунти като членове на ролите.REVOKE:В контекста на ролитеREVOKEкоманда премахва привилегиите от роля и също така премахва членството в роли от потребителските акаунти.SHOW GRANTS:SHOW GRANTSкомандата показва привилегиите на дадения потребителски акаунт или роля.SET ROLE:SET ROLEкоманда променя ролите, които потребителски акаунт използва активно. Това ви позволява да диктувате кои набори от разрешения се прилагат към акаунта за сесията.SET DEFAULT ROLE:SET DEFAULT ROLEкомандата дефинира ролите, които се прилагат автоматично, когато клиент влезе като конкретен потребителски акаунт.
Задължителни привилегии
За да следвате това ръководство, ще ви трябват следните привилегии:
CREATE ROLEGRANT OPTIONCREATE USER(за да зададете ролите по подразбиране за друг потребител)ROLE_ADMIN(за да зададете системни променливи, които променят поведението на ролите)SYSTEM_VARIABLES_ADMIN(за да зададете системни променливи, които променят поведението на ролите)
CREATE ROLE privilege е по-малка версия на CREATE USER привилегия, която ви позволява да създавате и управлявате роли. Профили, които вече имат CREATE USER privilege автоматично разполагат с цялата функционалност, необходима за управление на роли.
GRANT OPTION изисква се привилегия за присвояване на привилегии на роля. Трябва да имате GRANT OPTION активирани за всички привилегии, които искате да присвоите на роля.
Какво представляват ролите?
В MySQL ролята е обект, който функционира като контейнер или колекция от привилегии. Администраторите могат да присвояват привилегии на роли по същия начин, по който присвояват привилегии на потребителски акаунти. След това можете да добавите потребителски акаунти като членове на ролята, позволявайки на тези акаунти достъп до привилегиите, свързани с ролята.
По принцип ролите работят като начин за обединяване на различни свързани привилегии заедно, за да се улесни управлението на привилегиите. Вместо да се уверите, че всеки потребител има точното ниво на достъп, което му е необходимо, като присвоява индивидуални привилегии, използването на наименувани групи от привилегии ви позволява да управлявате по-малко, по-лесни за разбиране назначения.
Това има ясно предимство при задаване на нива на достъп, тъй като е по-лесно да зададете developer , sysadmin , или financeteam роля за потребител, отколкото индивидуално да управлява десетки привилегии. Освен това прави бързо настройване на достъп до няколко акаунта наведнъж. Ако създадете нова база данни за екипа по продажбите, можете да дадете salesteam ролеви достъп до него, вместо да проследявате всеки акаунт, който трябва да има достъп.
Създаване на роли
Ако имате акаунт с CREATE ROLE привилегия, можете да управлявате роли с помощта на CREATE ROLE команда.
Какъв е синтаксисът на MySQL за ролите?
Имената на ролите трябва да следват определен формат, за да може MySQL да ги счита за валидни. В много отношения те отразяват формата, използван за дефиниране на MySQL потребителски акаунти, но с някои важни разлики.
Ролите следват следния формат:
'<role>'@'<host>'
Подобно на потребителите, ролите имат два компонента:името на ролята и хоста, от който клиентът се свързва. Въпреки това, начинът, по който MySQL интерпретира тези компоненти, е различен.
С ролите, '<role>' част от името никога не може да бъде празна. Няма концепция за ролята да е „анонимна“, както при потребителите. От друга страна, пропускането на '<host>' порция е все още е разрешено и MySQL ще използва % като домакин. Въпреки това, % в този контекст се тълкува като буквален знак, а не заместващ знак.
На практика това означава, че въпреки че имената на ролите повърхностно споделят формата на имената на потребителските акаунти, те не се подлагат на какъвто и да е тип оценка, както правят потребителските акаунти, и са само етикет с два компонента. Причината, поради която правят Има две части в името им е, че можете да създавате потребителски акаунти, които могат да функционират както като потребители, така и като роли. Когато се използват като потребител, компонентите подлежат на специалните правила за оценка, описани в статията за управление на потребителите, а когато се използват като роля, името просто се съпоставя директно с помощта на буквалните имена на компоненти.
Поради тези правила в много случаи администраторите избират да дефинират роли, използвайки само '<role>' съставна част. Това кара MySQL да замести литерал % знак за '<host>' компонент, което ефективно прави тази част от името невидима и незначителна. Ако не възнамерявате името да се използва едновременно като потребителски акаунт и роля, можете да направите същото.
Как създавате роли?
За да създадете нови роли, използвайте CREATE ROLE команда.
Основният синтаксис изглежда така:
CREATE ROLE '<role>'@'<host>';
Можете също да създадете няколко роли едновременно, като разделите името на всяка роля със запетая:
CREATE ROLE '<role_1>'@'<host>', '<role_2>'@'<host>', '<role_3>'@'<host>';
Ако някоя от посочените от вас роли вече съществува в системата, командата ще се провали с грешка.
За да избегнете това и да накарате MySQL да издава само предупреждение, можете да включите IF NOT EXISTS клауза след CREATE ROLE команда преди имената на ролите:
CREATE ROLE IF NOT EXISTS '<role>'@'<host>';
Както бе споменато по-горе, много пъти администраторите пропускат '<host>' част от името на ролята за простота, неявно задаване на литерала % характер. Така че на практика много от вашите команди за създаване на роли може да изглеждат по-скоро така:
CREATE ROLE '<role>';
Как предоставяте привилегии на роля?
След като създадете нови роли, следващият ви приоритет обикновено е да ги направите значими, като им предоставите привилегии.
Вие предоставяте привилегии на ролите по същия начин, по който предоставяте привилегии на потребителски акаунти. Вие предоставяте точните привилегии, които искате да предоставите, указвате обхват, като предоставяте базата данни и обекта на базата данни, където привилегията е валидна, и обекта, на който трябва да бъдат предоставени привилегиите — в този случай роля:
GRANT <privileges> ON <database>.<object> TO '<role>'@'<host>';
Например, за да предоставите SELECT привилегия за роля, наречена readapp в appdb база данни и всички обекти, които съдържа, можете да въведете:
GRANT SELECT ON appdb.* TO 'readapp';
По същия начин можете да предоставите привилегии за запис на същата база данни на роля, наречена writeapp като напишете:
GRANT SELECT,INSERT,UPDATE,DELETE ON appdb.* TO 'writeapp';
Можете да предоставяте привилегии и да ги отменяте от ролите точно както бихте направили директно с потребителски акаунти. Така че винаги можете да промените привилегиите, свързани с роля, ако трябва да коригирате нивото на достъп, което искате да предоставите.
Как предоставяте на потребителите членство на роля?
След като добавите привилегии към ролите си, можете да започнете да добавяте членове към ролята, за да им предоставите свързаните привилегии.
За да направи това, MySQL използва различна форма на същия GRANT използваме за предоставяне на привилегии на потребители и роли. Този нов формуляр обаче добавя роли към потребител, което позволява на потребителския акаунт достъп до всички привилегии, дадени на ролята.
Основният синтаксис изглежда така:
GRANT '<role>'@'<host>' TO '<user>'@'<host>';
Например, ако 'reports'@'localhost' потребителят трябва да може да чете данни от appdb база данни за генериране на отчети, можем да добавим readapp роля на потребителския акаунт, като му давате привилегии за избор:
GRANT 'readapp' TO 'reports'@'localhost';
По същия начин, за да дадете 'appuser'@'localhost' възможността за управление на данните в рамките на една и съща база данни, можем да направим този потребител член на writeapp роля:
GRANT 'writeapp' TO 'appuser'@'localhost';
'appuser'@'localhost' акаунтът вече ще има възможност да вмъква, актуализира и премахва данни от базата данни. Ако към writeapp се добавят нови привилегии роля, 'appuser'@'localhost' акаунтът веднага ще получи тези привилегии.
Как автоматично предоставяте определени роли на всеки потребител?
Понякога може да има роли, до които искате всеки потребител във вашата система да има достъп. Можете да дефинирате кои роли се предоставят автоматично на всеки акаунт, като зададете mandatory_roles променлива.
За да промените mandatory_roles променлива, вашият потребител трябва да има ROLE_ADMIN и SYSTEM_VARIABLES_ADMIN привилегии. Можете да зададете ролите, които искате да дадете на всеки потребител, като напишете:
SET PERSIST mandatory_roles = '`<role_1>`@`<host>`, `<role_2>`@`<host>`, `<role_3>`@`<host>`';
Тук ние автоматично даваме на всеки потребител в системата три роли. Когато задавате системната променлива, стойността на mandatory_roles трябва да бъде низ, така че капсулираме целия списък с роли в единични кавички и използваме обратни отметки, за да цитираме отделни ролеви компоненти.
Не можете да добавите роля към mandatory_roles списък, който съдържа SYSTEM_USER привилегия. Това е мярка за сигурност, за да се гарантира, че не всички сесии в системата са системни сесии автоматично.
Как използвате привилегиите от ролите?
След като предоставите членство на потребителски акаунти за роли, как ги използвате? За достъп до привилегиите, предоставени на акаунт от роля, той трябва да бъде активиран.
Преглед на текущите активни роли
Преди да активирате нови роли, можете да проверите кои роли са активни в момента за вашата потребителска сесия.
За да видите активните роли за вашата сесия, въведете:
SELECT CURRENT_ROLE()
Резултатът ще покаже нула или повече роли, които са активни във вашата текуща сесия. Привилегиите, свързани с тези роли, ще добавят към действията, които имате право да извършвате.
Как да активирате роли за сесията
За да промените кои роли са активни по време на вашата сесия, използвайте SET ROLE команда. Можете да използвате тази команда по различни начини.
Основният синтаксис изглежда така:
SET ROLE '<rolename>'@'<host>';
Това ще активира въпросната роля. Важно е да се отбележи, че всички по-рано активни роли, които не са споменати в SET ROLE командата вече ще бъде деактивирана.
За да активирате повече от една роля наведнъж, отделете всяка роля със запетая:
SET ROLE '<role_1>'@'<host>', '<role_2>'@'<host>', '<role_3>'@'<host>';
За да активирате всички роли, които са предоставени на вашия акаунт, можете да посочите ALL вместо конкретна роля:
SET ROLE ALL;
Можете също да кажете на MySQL да активира всичките ви роли с конкретно изключение, като използвате ALL EXCEPT :
SET ROLL ALL EXCEPT '<role_1>'@'<host>';
Друга възможност е да деактивирате всички роли във вашия акаунт, като посочите NONE :
SET ROLE NONE
Това ще деактивира всички ваши потребителски роли за сесията, като ви дава само привилегиите, присвоени конкретно на вашия потребителски акаунт.
За да се върнете към списъка по подразбиране с роли, дефинирани за вашия акаунт, използвайте DEFAULT ключова дума:
SET ROLE DEFAULT
Как да дефинирате роли по подразбиране за потребителски акаунт
Ролите, които се активират автоматично, когато влезете като потребител, и тези, които се активират повторно, когато използвате SET ROLE DEFAULT могат да се конфигурират.
За да дефинирате ролите, които ще бъдат активирани по подразбиране, използвайте SET DEFAULT ROLE команда, подобна на начина, по който използвате SET ROLE команда:
SET DEFAULT ROLE '<role_1>'@'<host>';
Това ще зададе ролите по подразбиране, които ще бъдат активирани за вашия собствен акаунт при влизане или при използване на SET ROLE DEFAULT .
Ако вашият потребител има CREATE USER привилегия, можете да зададете ролите по подразбиране за други акаунти:
SET DEFAULT ROLE ALL TO '<user>'@'<host>';
Тук указваме, че '<user>'@'<host>' акаунтът трябва автоматично да активира всички свои роли при удостоверяване.
Този синтаксис може да се използва и за дефиниране на ролите по подразбиране за повече от един акаунт чрез разделяне на всеки потребител със запетая:
SET DEFAULT ROLE ALL TO '<user_1>'@'<host>', '<user_2>'@'<host>';
Активиране на всички роли за всички потребители по подразбиране
Ако искате всеки акаунт на вашия MySQL сървър да активира всичките си роли по подразбиране, можете да промените системна настройка, за да го направите.
Когато activate_all_roles_on_login променливата е зададена на true, MySQL автоматично ще активира всички роли, свързани с акаунт при влизане. Това заменя настройките, посочени от SET DEFAULT ROLE .
За да активирате тази функция, трябва да имате SYSTEM_VARIABLES_ADMIN и ROLE_ADMIN привилегии. Активирайте функцията, като напишете:
SET PERSIST activate_all_roles_on_login = ON;
Това ще накара потребителските акаунти да активират автоматично всички роли при влизане. Въпреки това, SET ROLE DEFAULT ще ви позволи да активирате само ролите по подразбиране, свързани с акаунт.
Показване на съществуващите привилегии, получени от роли
За да разберете какви привилегии са налични във вашия акаунт, можете да използвате SHOW GRANTS команда.
За да проверите разрешенията за даден потребител, въведете:
SHOW GRANTS FOR '<user>'@'<host>';
Резултатът ще ви покаже всички привилегии, директно присвоени на потребителския акаунт, както и всички роли, на които потребителят е член.
След като научите на какви роли членува даден акаунт, можете да проверите какви привилегии предоставя тази роля на потребителя, като напишете:
SHOW GRANTS FOR '<user>'@'<host>' USING '<role>'@'<host>';
Например, за да проверите привилегиите на 'reports'@'localhost' потребител, включително тези, предоставени от членството му в readapp роля, можете да използвате:
SHOW GRANTS FOR 'reports'@'localhost' USING 'readapp';
Това ще ви покаже всички привилегии, изрично предоставени на 'reports'@'localhost' потребителски акаунт, както и тези, добавени от readapp роля.
Отмяна на роля от потребител
И така, какво се случва, когато искате да премахнете роля от потребител? Подобно на GRANT командата може или да добави нови привилегии към потребител или роля, или да добави роли към потребител, REVOKE командата може да премахне привилегиите от потребител или роля и може също да премахне членството в роля от потребител.
Основният синтаксис, използван за премахване на роля от потребителски акаунт, изглежда така:
REVOKE '<role>' FROM '<user>'@'<host>';
След като изпълни изявление като това, потребителят вече няма да има достъп до привилегиите, предоставени чрез ролята.
Като пример можем да отменим writeapp роля от 'appuser'@'localhost' потребителски акаунт, като напишете:
REVOKE 'writeapp' FROM 'appuser'@'localhost';
Ако обаче на потребителя е предоставена привилегия по друг начин (или пряко предоставена, или предоставена чрез членство с различна роля), той все още ще има достъп до тази привилегия. Така че, ако 'appuser'@'localhost' потребителят също е бил член на readapp роля, която предоставихме по-рано, те пак ще имат SELECT привилегии в appdb база данни.
Заключение
Използването на роли за разпределяне на привилегии във вашите MySQL бази данни може да помогне за опростяване на административните разходи и сложността на вашата система за контрол на достъпа. Много по-лесно е да се гарантира, че потребителите с еднакви отговорности имат едни и същи привилегии, използвайки роли, отколкото да се предоставят много различни привилегии директно.
По същия начин ролите ви позволяват да бъдете изрични относно намерението зад предоставянето на привилегии. Вместо да предоставят голям брой привилегии на акаунти без никакви коментари, внимателно подбраните имена на роли могат да помогнат за разграничаването на различните причини за достъп. Като отделите време за създаване и организиране на роли преди време, способността ви да управлявате достъпа на потребителите до различни части от вашите данни ще бъде по-лесна в дългосрочен план.
