Wprowadzenie
Kontrola dostępu i zarządzanie użytkownikami to dwa obszary, które mogą szybko stać się złożone wraz ze wzrostem liczby użytkowników i różnych jednostek bazy danych w systemie. Zarządzanie wieloma różnymi uprawnieniami do różnych obiektów bazy danych, zapewniając użytkownikom, którzy mają te same obowiązki, mają ten sam poziom dostępu, a kontrola i zawężanie dostępu stają się z czasem coraz trudniejsze.
Aby pomóc w rozwiązaniu tego problemu, MySQL ma koncepcję zwaną „role”, która umożliwia grupowanie pakietów uprawnień pod daną nazwą, co pozwala na masowe przypisywanie i modyfikowanie ustawień. W tym przewodniku omówimy, jak działają role w MySQL i jak ich używać, aby ułatwić zarządzanie dostępem do danych dla użytkowników.
Polecenia
Oto główne polecenia SQL, które będziemy omawiać w związku z zarządzaniem rolami MySQL.
CREATE ROLE:CREATE ROLEpolecenie definiuje nową rolę w systemie bazy danych.DROP ROLE:DROP ROLEpolecenie działa odwrotnie, usuwając istniejącą rolę.GRANT:GRANTpolecenie ma dwa różne cele związane z rolami:dodawanie uprawnień do ról i dodawanie kont użytkowników jako członków ról.REVOKE:W kontekście rólREVOKEpolecenie usuwa uprawnienia z roli, a także usuwa członkostwo w roli z kont użytkowników.SHOW GRANTS:SHOW GRANTSpolecenie pokazuje uprawnienia danego konta użytkownika lub roli.SET ROLE:SET ROLEpolecenie zmienia role, z których aktywnie korzysta konto użytkownika. Dzięki temu możesz dyktować, które zestawy uprawnień mają zastosowanie do konta podczas sesji.SET DEFAULT ROLE:SET DEFAULT ROLEpolecenie definiuje role, które są automatycznie stosowane, gdy klient loguje się jako określone konto użytkownika.
Wymagane uprawnienia
Aby postępować zgodnie z tym przewodnikiem, potrzebujesz następujących uprawnień:
CREATE ROLEGRANT OPTIONCREATE USER(aby ustawić domyślne role dla innego użytkownika)ROLE_ADMIN(aby ustawić zmienne systemowe, które modyfikują zachowanie ról)SYSTEM_VARIABLES_ADMIN(aby ustawić zmienne systemowe, które modyfikują zachowanie ról)
CREATE ROLE przywilej to mniejsza wersja CREATE USER przywilej, umożliwiający tworzenie ról i zarządzanie nimi. Konta, które mają już CREATE USER uprawnienia automatycznie posiadają wszystkie funkcje wymagane do zarządzania rolami.
GRANT OPTION uprawnienia są wymagane do przypisania uprawnień do roli. Musisz mieć GRANT OPTION włączone dla wszelkich uprawnień, które chcesz przypisać do roli.
Co to są role?
W MySQL rola to jednostka, która działa jako kontener lub zbiór uprawnień. Administratorzy mogą przypisywać uprawnienia do ról w taki sam sposób, w jaki przypisują uprawnienia do kont użytkowników. Następnie możesz dodać konta użytkowników jako członków roli, umożliwiając tym kontom dostęp do uprawnień związanych z rolą.
Zasadniczo role działają jako sposób na łączenie różnych powiązanych uprawnień, aby ułatwić zarządzanie uprawnieniami. Zamiast upewniać się, że każdy użytkownik ma dokładnie taki poziom dostępu, jakiego potrzebuje, przypisując indywidualne uprawnienia, użycie nazwanych grup uprawnień pozwala zarządzać mniejszą liczbą łatwiejszych do zrozumienia przypisań.
Ma to wyraźną przewagę podczas przypisywania poziomów dostępu, ponieważ łatwiej jest przypisać developer , sysadmin lub financeteam do roli użytkownika niż do samodzielnego zarządzania dziesiątkami uprawnień. Ułatwia również szybkie dostosowanie dostępu do wielu kont jednocześnie. Jeśli utworzysz nową bazę danych dla zespołu sprzedaży, możesz podać salesteam dostęp do roli zamiast śledzenia każdego konta, które powinno mieć dostęp.
Tworzenie ról
Jeśli masz konto z CREATE ROLE przywilej, możesz zarządzać rolami za pomocą CREATE ROLE polecenie.
Jaka jest składnia ról w MySQL?
Nazwy ról muszą mieć określony format, aby MySQL uznawał je za prawidłowe. Pod wieloma względami odzwierciedlają format używany do definiowania kont użytkowników MySQL, ale z pewnymi istotnymi różnicami.
Role mają następujący format:
'<role>'@'<host>'
Podobnie jak użytkownicy, role składają się z dwóch składników:nazwy roli i hosta, z którego łączy się klient. Jednak sposób, w jaki MySQL interpretuje te komponenty, jest inny.
W przypadku ról '<role>' część nazwy nigdy nie może być pusta. Nie ma pojęcia, że rola jest „anonimowa”, jak w przypadku użytkowników. Z drugiej strony, pomijając '<host>' część jest nadal dozwolone, a MySQL użyje % jako gospodarz. Jednak % w tym kontekście jest interpretowany jako znak dosłowny, a nie symbol wieloznaczny.
W praktyce oznacza to, że chociaż nazwy ról powierzchownie współdzielą format nazw kont użytkowników, nie podlegają one żadnemu rodzajowi oceny, jak robią to konta użytkowników, i są tylko etykietą z dwoma składnikami. Powód, dla którego to robią mają dwie części w swojej nazwie, ponieważ możesz tworzyć konta użytkowników, które mogą działać zarówno jako użytkownicy, jak i role. Gdy są używane jako użytkownik, komponenty podlegają specjalnym regułom oceny opisanym w artykule dotyczącym zarządzania użytkownikami, a gdy są używane jako rola, nazwa jest po prostu dopasowywana bezpośrednio przy użyciu dosłownych nazw komponentów.
Ze względu na te reguły w wielu przypadkach administratorzy decydują się na definiowanie ról przy użyciu tylko '<role>' składnik. To powoduje, że MySQL zastępuje dosłowny % znak dla '<host>' składnik, skutecznie czyniąc tę część nazwy niewidoczną i nieistotną. Jeśli nie chcesz, aby nazwa była używana zarówno jako konto użytkownika, jak i rola, możesz zrobić to samo.
Jak tworzysz role?
Aby utworzyć nowe role, użyj CREATE ROLE polecenie.
Podstawowa składnia wygląda tak:
CREATE ROLE '<role>'@'<host>';
Możesz także utworzyć wiele ról jednocześnie, oddzielając każdą nazwę roli przecinkiem:
CREATE ROLE '<role_1>'@'<host>', '<role_2>'@'<host>', '<role_3>'@'<host>';
Jeśli dowolna z podanych ról już istnieje w systemie, polecenie zakończy się niepowodzeniem z błędem.
Aby tego uniknąć i spowodować, że MySQL wyświetli tylko ostrzeżenie, możesz dołączyć IF NOT EXISTS klauzula po CREATE ROLE polecenie przed nazwami ról:
CREATE ROLE IF NOT EXISTS '<role>'@'<host>';
Jak wspomniano powyżej, często administratorzy pomijają '<host>' część nazwy roli dla uproszczenia, domyślnie ustawiając ją na dosłowny % postać. W praktyce wiele poleceń tworzenia ról może wyglądać mniej więcej tak:
CREATE ROLE '<role>';
Jak przyznać uprawnienia do roli?
Po utworzeniu nowych ról następnym priorytetem jest zazwyczaj nadanie im znaczenia poprzez nadanie im uprawnień.
Uprawnienia do ról przyznaje się w taki sam sposób, jak uprawnienia do kont użytkowników. Podajesz dokładnie uprawnienia, które chcesz przyznać, określasz zakres, podając bazę danych i obiekt bazy danych, w których uprawnienie jest ważne, oraz jednostkę, której uprawnienia powinny zostać nadane — w tym przypadku rolę:
GRANT <privileges> ON <database>.<object> TO '<role>'@'<host>';
Na przykład, aby przyznać SELECT uprawnienia do roli o nazwie readapp w appdb bazy danych i wszystkich zawartych w niej obiektów, możesz wpisać:
GRANT SELECT ON appdb.* TO 'readapp';
Podobnie możesz przyznać uprawnienia do zapisu do tej samej bazy danych do roli o nazwie writeapp wpisując:
GRANT SELECT,INSERT,UPDATE,DELETE ON appdb.* TO 'writeapp';
Możesz przyznawać uprawnienia i odwoływać je od ról dokładnie tak samo, jak bezpośrednio w przypadku kont użytkowników. Dzięki temu zawsze możesz zmodyfikować uprawnienia związane z rolą, jeśli chcesz dostosować poziom dostępu, który chcesz zapewnić.
Jak przyznać użytkownikom członkostwo w roli?
Po dodaniu uprawnień do ról możesz rozpocząć dodawanie członków do roli, aby przyznać im powiązane uprawnienia.
W tym celu MySQL używa innej formy tego samego GRANT używamy do nadawania uprawnień użytkownikom i rolom. Ten nowy formularz dodaje jednak role użytkownikowi, umożliwiając dostęp konta użytkownika do wszystkich uprawnień nadanych roli.
Podstawowa składnia wygląda tak:
GRANT '<role>'@'<host>' TO '<user>'@'<host>';
Na przykład, jeśli 'reports'@'localhost' użytkownik musi mieć możliwość odczytywania danych z appdb bazy danych do generowania raportów, możemy dodać readapp rolę do konta użytkownika, nadając mu uprawnienia do wyboru:
GRANT 'readapp' TO 'reports'@'localhost';
Podobnie, aby dać 'appuser'@'localhost' możliwość zarządzania danymi w ramach tej samej bazy danych, możemy uczynić tego użytkownika członkiem writeapp rola:
GRANT 'writeapp' TO 'appuser'@'localhost';
'appuser'@'localhost' Konto będzie teraz miało możliwość wstawiania, aktualizowania i usuwania danych z bazy danych. Jeśli nowe uprawnienia zostaną dodane do writeapp rolę, 'appuser'@'localhost' konto natychmiast uzyska te uprawnienia.
Jak automatycznie przydzielasz określone role każdemu użytkownikowi?
Czasami mogą istnieć role, do których każdy użytkownik w systemie powinien mieć dostęp. Możesz określić, które role są automatycznie przyznawane każdemu kontu, ustawiając mandatory_roles zmienna.
Aby zmodyfikować mandatory_roles zmienna, twój użytkownik musi mieć ROLE_ADMIN i SYSTEM_VARIABLES_ADMIN przywileje. Możesz ustawić role, które chcesz przypisać każdemu użytkownikowi, wpisując:
SET PERSIST mandatory_roles = '`<role_1>`@`<host>`, `<role_2>`@`<host>`, `<role_3>`@`<host>`';
Tutaj automatycznie przydzielamy każdemu użytkownikowi w systemie trzy role. Podczas ustawiania zmiennej systemowej wartość mandatory_roles musi być ciągiem, więc umieszczamy całą listę ról w pojedynczych cudzysłowach i używamy backticków do cytowania poszczególnych składników ról.
Nie możesz dodać roli do mandatory_roles lista zawierająca SYSTEM_USER przywilej. Jest to środek bezpieczeństwa zapewniający, że nie wszystkie sesje w systemie będą automatycznie sesjami systemowymi.
Jak korzystać z uprawnień z ról?
Po przyznaniu członkostw kont użytkowników do ról, jak z nich korzystać? Aby uzyskać dostęp do uprawnień przyznanych kontu przez rolę, należy je aktywować.
Wyświetlanie aktualnie aktywnych ról
Przed aktywacją nowych ról możesz sprawdzić, które role są aktualnie aktywne w Twojej sesji użytkownika.
Aby wyświetlić aktywne role w Twojej sesji, wpisz:
SELECT CURRENT_ROLE()
W wyniku pojawi się zero lub więcej ról, które są aktywne w bieżącej sesji. Uprawnienia związane z tymi rolami zwiększają zakres działań, które możesz wykonywać.
Jak aktywować role dla sesji
Aby zmienić role aktywne podczas sesji, użyj opcji SET ROLE Komenda. Możesz użyć tego polecenia na wiele różnych sposobów.
Podstawowa składnia wygląda tak:
SET ROLE '<rolename>'@'<host>';
To aktywuje daną rolę. Należy zauważyć, że wszystkie wcześniej aktywne role niewymienione w SET ROLE polecenie zostanie teraz wyłączone.
Aby aktywować więcej niż jedną rolę naraz, oddziel każdą rolę przecinkiem:
SET ROLE '<role_1>'@'<host>', '<role_2>'@'<host>', '<role_3>'@'<host>';
Aby aktywować wszystkie role przypisane do Twojego konta, możesz określić ALL zamiast określonej roli:
SET ROLE ALL;
Możesz także powiedzieć MySQL, aby aktywował wszystkie twoje role z określonym wyjątkiem, używając ALL EXCEPT :
SET ROLL ALL EXCEPT '<role_1>'@'<host>';
Inną opcją jest wyłączenie wszystkich ról na koncie, określając NONE :
SET ROLE NONE
Spowoduje to dezaktywację wszystkich ról użytkowników dla sesji, dając tylko uprawnienia przypisane konkretnie do Twojego konta użytkownika.
Aby wrócić do domyślnej listy ról zdefiniowanych dla Twojego konta, użyj DEFAULT słowo kluczowe:
SET ROLE DEFAULT
Jak zdefiniować role domyślne dla konta użytkownika
Role, które są automatycznie aktywowane po zalogowaniu się jako użytkownik i te, które są ponownie aktywowane, gdy używasz SET ROLE DEFAULT są konfigurowalne.
Aby zdefiniować role, które będą domyślnie aktywowane, użyj SET DEFAULT ROLE polecenie podobne do tego, jak używasz SET ROLE polecenie:
SET DEFAULT ROLE '<role_1>'@'<host>';
Spowoduje to ustawienie domyślnych ról, które zostaną aktywowane dla Twojego konta po zalogowaniu lub użyciu SET ROLE DEFAULT .
Jeśli Twój użytkownik ma CREATE USER przywilej, możesz ustawić domyślne role dla innych kont:
SET DEFAULT ROLE ALL TO '<user>'@'<host>';
Tutaj określamy, że '<user>'@'<host>' konto powinno automatycznie aktywować wszystkie swoje role po uwierzytelnieniu.
Ta składnia może być również używana do definiowania domyślnych ról dla więcej niż jednego konta, oddzielając każdego użytkownika przecinkiem:
SET DEFAULT ROLE ALL TO '<user_1>'@'<host>', '<user_2>'@'<host>';
Domyślna aktywacja wszystkich ról dla wszystkich użytkowników
Jeśli chcesz, aby każde konto na serwerze MySQL domyślnie aktywowało wszystkie swoje role, możesz zmienić ustawienia systemowe, aby to zrobić.
Gdy activate_all_roles_on_login zmienna jest ustawiona na true, MySQL automatycznie aktywuje wszystkie role powiązane z kontem po zalogowaniu. Zastępuje to ustawienia określone przez SET DEFAULT ROLE .
Aby włączyć tę funkcję, musisz mieć SYSTEM_VARIABLES_ADMIN i ROLE_ADMIN przywileje. Włącz tę funkcję, wpisując:
SET PERSIST activate_all_roles_on_login = ON;
Spowoduje to, że konta użytkowników będą automatycznie aktywować wszystkie role podczas logowania. Jednak SET ROLE DEFAULT nadal pozwoli Ci aktywować tylko domyślne role powiązane z kontem.
Pokaż istniejące uprawnienia uzyskane z ról
Aby zrozumieć, jakie uprawnienia są dostępne na Twoim koncie, możesz użyć opcji SHOW GRANTS polecenie.
Aby sprawdzić dotacje włączone dla użytkownika, wpisz:
SHOW GRANTS FOR '<user>'@'<host>';
Dane wyjściowe pokażą Ci wszystkie uprawnienia bezpośrednio przypisane do konta użytkownika, a także wszystkie role, których członkiem jest użytkownik.
Po zapoznaniu się z rolami, których członkiem jest konto, możesz sprawdzić, jakie przywileje ta rola zapewnia użytkownikowi, wpisując:
SHOW GRANTS FOR '<user>'@'<host>' USING '<role>'@'<host>';
Na przykład, aby sprawdzić uprawnienia 'reports'@'localhost' użytkownik, w tym te przyznane przez jego członkostwo w readapp rolę, możesz użyć:
SHOW GRANTS FOR 'reports'@'localhost' USING 'readapp';
Spowoduje to wyświetlenie wszystkich uprawnień wyraźnie przyznanych 'reports'@'localhost' konto użytkownika, a także te dodane przez readapp rola.
Odwołanie roli użytkownika
Co się dzieje, gdy chcesz usunąć rolę z użytkownika? Podobnie jak w przypadku GRANT polecenie może albo dodać nowe uprawnienia do użytkownika lub roli, albo dodać role do użytkownika, REVOKE polecenie może usunąć uprawnienia użytkownika lub roli, a także może usunąć członkostwo w roli użytkownikowi.
Podstawowa składnia używana do usuwania roli z konta użytkownika wygląda następująco:
REVOKE '<role>' FROM '<user>'@'<host>';
Po wykonaniu takiej instrukcji użytkownik nie będzie już miał dostępu do uprawnień nadanych przez rolę.
Jako przykład możemy odwołać writeapp rola z 'appuser'@'localhost' konto użytkownika, wpisując:
REVOKE 'writeapp' FROM 'appuser'@'localhost';
Jeśli jednak użytkownikowi przyznano przywilej w inny sposób (bezpośrednio lub poprzez członkostwo z inną rolą), nadal będzie miał dostęp do tego przywileju. Więc jeśli 'appuser'@'localhost' użytkownik był również członkiem readapp rolę, którą przyznaliśmy wcześniej, nadal będą mieli SELECT uprawnienia w appdb baza danych.
Wniosek
Używanie ról do dystrybucji uprawnień w bazach danych MySQL może pomóc uprościć ogólne zarządzanie i złożoność systemu kontroli dostępu. O wiele łatwiej jest zapewnić, że użytkownicy z tymi samymi obowiązkami mają te same uprawnienia przy użyciu ról, niż bezpośrednio przyznawać wiele różnych uprawnień.
Podobnie role pozwalają jasno określić intencje stojące za przyznaniem uprawnień. Zamiast przyznawać dużą liczbę uprawnień do kont bez żadnego komentarza, starannie dobrane nazwy ról mogą pomóc w rozróżnieniu różnych powodów dostępu. Poświęcając czas na tworzenie i organizowanie ról z wyprzedzeniem, Twoja zdolność do zarządzania dostępem użytkowników do różnych części danych będzie prostsza na dłuższą metę.
