W tym wpisie opisuję podstawy kontroli dostępu w Snowflake’u i sugestię jak zabrać się za temat w taki sposób, żeby ułatwić Ci życie poprzez stworzenie hierarchii ról zgodnych z funkcjami biznesowymi Twojej organizacji.
Podstawowe pojęcia kontroli dostępu w Snowflake’u
Przy tworzeniu nowych ról bardzo łatwo pójść na łatwiznę i podpinać pod nie wszelkie uprawnienia, których chcą użytkownicy, jednak to prowadzi do rozprzestrzenienia się zbyt szerokich uprawnień dla wszystkich. Dlatego do tego zagadnienia lepiej usiąść na poważnie od samego początku pracy ze Snowflake’iem, inaczej łatwo stworzyć nieogarnialny chaos.
Kontrola dostępu w Snowflake’u składa się z 2 aspektów:
- Uznaniowa kontrola dostępu (eng. Discretionary Access Control: DAC):
Każdy obiekt ma swojego właściciela, który może zarządzać dostępem do tego obiektu. Rola, która została wykorzystana do stworzenia danego obiektu automatycznie staje się jego właścicielem. - Kontrola dostępu oparta na rolach (eng. Role-based Access Control: RBAC):
Wszelkie uprawnienia są przypisywane do ról, które są przypisywane do użytkowników. Użytkownik sam w sobie nie ma żadnych uprawnień.
Są jeszcze kluczowe pojęcia do omówienia kontroli uprawnień:
- Obiekt zabezpieczony (securable object)
Wszystko, do czego dostęp może być udzielony: tabela, widok, zadanie, schemat, baza danych, etc. - Rola (Role)
Do roli są przypisywane uprawnienia do dostępu i zarządzania obiektami. Role są przypisywane do Użytkowników. Role mogą być też przypisane do innych ról tworząc hierarchie ról. - Uprawnienia (Privelages)
Zdefiniowany poziom dostępu do obiektu. - Użytkownik (User)
Tożsamość użytkownika, która jest przypisana osobie, lub konkretnym programom.
Podstawowe role w Snowflake’u
Konto w Snowflake’u automatycznie przychodzi z kilkoma zdefiniowanymi rolami. Powyższy diagram nie tylko przedstawia listę dostępnych ról, ale też ich hierarchię. USERADMIN jest przypisany do roli SECURITYADMIN, a ta jest przypisana roli ACCOUNTADMIN. Oznacza to, że SECURITYADMIN dziedziczy wszystkie uprawnienia roli USERADMIN, a ACCOUNTADMIN dziedziczy wszystkie uprawnienia roli SECURITYADMIN (oraz roli SYSADMIN).
Własność nad obiektami jest też dziedziczona, co oznacza, że jeśli SYSADMIN utworzy bazę danych, w niej schemat i tabele, to rola SYSADMIN będzie automatycznie właścicielem tych obiektów. Poprzez dziedziczenie rola ACCOUNTADMIN będzie miała do nich pełny dostęp. Ze względu na to, że rola SECURITYADMIN nie jest powiązana z rolą SYSADMIN, to nie będzie miała wglądu w obiekty stworzone przez rolę SYSADMIN, chyba, że zostaną jej nadane dodatkowe uprawnienia.
ACCOUNTADMIN
Wręcz boska rola, która zawiera w sobie wszystkie uprawnienia ról SYSADMIN i SECURITYADMIN. Powinna być udostępniana jedynie nielicznym użytkownikom i regularnie monitorowana. W powyższym screenie zauważysz, że lista uprawnień nadanych tej roli jest dość długa.
SYSADMIN
Rola z uprawnieniami do tworzenia warehouse’ów (klastrów obliczeniowych), baz danych i innych obiektów wewnątrz tych baz danych.
Snowflake rekomenduje tworzenie takich hierarchii ról, żeby najwyższe role funkcyjne były przypisane właśnie do roli SYSADMIN.
SECURITYADMIN
Rola mająca służyć do globalnego zarządzania uprawnieniami na poziomie całego konta (pod warunkiem, że trzymasz się zasad i tworzysz nowe konta wykorzystując rolę USERADMIN ;). Może monitorować i zarządzać użytkownikami i rolami.
USERADMIN
Rola dedykowana jedynie zarządzaniu użytkownikami i rolami. Pamiętaj, że użytkownicy i role to też obiekty w Snowflake’u, więc też dotyczy ich przynależność do roli, która ich stworzyła. Jeśli stworzysz użytkownika i rolę wykorzystując rolę USERADMIN, to poprzez dziedziczenie będą one mogły być zarządzane przez role SECURITYADMIN i ACCOUNTADMIN. Jeśli jednak stworzysz rolę lub użytkownika wykorzystując inną rolę, która nie jest przypisana do roli USERADMIN, to USERADMIN nie będzie w stanie nic zrobić z nimi.
ORGADMIN
ORGADMIN jest rolą pozwalającą na zarządzanie całą organizacją. Wykorzystując tę rolę możesz zarządzać kontami w organizacji, regionami a także monitorować wykorzystanie zasobów w całej organizacji.
Poniższa grafika przedstawia organizację jako nadrzędny byt zarządzany przez rolę ORGADMIN. W organizacji może istnieć wiele kont. Każde konto jest odrębnym bytem – adres każdego konta jest unikatowy i dane wraz z rolami i użytkownikami są odrębnie zarządzane. Grafika nie przedstawia wszystkich obiektów, jednak naświetla ich hierarchię. Wyraźnie możesz zauważyć, że większość obiektów, które stworzysz w codziennej pracy musi być przypisane do konkretnego schematu w konkretnej bazie danych.
PUBLIC
PUBLIC to pseudo-rola, która automatycznie jest przypisywana każdemu użytkownikowi i każdej innej roli. Ta rola też może być właścicielem obiektów w Snowflake’u i spowoduje to, że wszyscy użytkownicy i role będą mieli dostęp do tych obiektów. W związku z powszechnym dostępem do tej roli nie powinna mieć dostępu do żadnych obiektów, które powinny mieć ograniczony dostęp.
Jak zabrać się do zaprojektowania odpowiednich ról i uprawnień w Snowflake’u?
Role i uprawnienia są bardzo istotnym aspektem zarządzania danymi. Mniejsze organizacje oczywiście będą miały zdecydowanie łatwiej, jednak nawet one muszą przysiąść do tematu rzetelnie, bo wraz ze wzrostem organizacji możesz się nagle obudzić z ręką w nocniku, że masz bałagan w uprawnieniach.
By zachować zgodność z zasadą najmniejszych przywilejów Snowflake zaleca tworzenie ról dopasowanych do funkcji biznesowych.
Warto podzielić role na 2 typy (technicznie nie różnią się niczym, poza spełnianą funkcją):
- Role dostępowe służą do zarządzania dostępem do poszczególnych obiektów (bazy danych, schematy, tabele, widoki, etc.)
- Role funkcjonalne mają służyć utworzeniu hierarchii ról w organizacji (młodszy analityk, analityk, inżynier danych, etc.)
Analiza ról funkcjonalnych
Zanim zaczniesz tworzyć nowe role najpierw przeprowadź analizę organizacji wraz ze wszystkimi osobami i funkcjami, jakie pełnią, które będą z tych danych korzystać lub będą za nie odpowiedzialni.
Tworząc listę ról funkcjonalnych ustal od razu jakich uprawnień potrzebują, żeby wykonać swoją pracę.
W poniższych przykładach role podstawowe i kod SQL będę pisał wielkimi literami, a nazwy nowych (przykładowych) ról i użytkowników małymi.
Przykładowo role funkcjonalne mogą wyglądać tak:
| Stanowisko | Rola funkcjonalna |
|---|---|
| Analityk | analyst |
| Młodszy Inżynier Danych | data_engineer_jr |
| Starszy Inżynier Danych | data_engineer_sr |
| Księgowy | accountant |
Tworzenie ról funkcjonalnych:
USE ROLE USERADMIN;
CREATE ROLE analyst;
CREATE ROLE data_engineer_jr;
CREATE ROLE data_engineer_sr;
CREATE ROLE accountant;Hierarchia ról funkcjonalnych
Zgodnie z najlepszą praktyką role funkcjonalne powinieneś ułożyć w hierarchię i najwyższą rolę z hierarchii przypisać do roli SYSADMIN, co w naszym przykładzie stworzy poniższy obraz.
Zgodnie z powyższym przykładem utworzenie hierarchii ról funkcjonalnych jest dość proste. Uwzględnię też przypisanie ról funkcjonalnych do roli SYSADMIN.
USE ROLE USERADMIN;
GRANT ROLE data_engineer_jr TO ROLE data_engineer_sr;
GRANT ROLE data_engineer_sr TO ROLE SYSADMIN;
GRANT ROLE analyst TO ROLE SYSADMIN;
GRANT ROLE accountant TO ROLE SYSADMIN;Zdefiniowanie ról dostępowych
Role dostępowe mają ułatwić nadawanie uprawnień odpowiednim rolom funkcjonalnym. Zakładając, że masz 2 bazy danych:
- HR – zawierającą dane pracowników,
- Sprzedażową – zawierającą dane zamówień klientów, stany magazynowe, produkty itp,
przykładowymi rolami dostępowymi mogą być:
| Nazwa roli | Opis Roli |
|---|---|
| hr_read_only | Dostęp jedynie do odczytu bazy danych HR |
| hr_all | Umożliwia pełną kontrolę obiektów w bazie HR |
| sale_read_only | Dostęp jedynie do odczytu sprzedażowej bazy danych |
| sale_all | Umożliwia pełną kontrolę obiektów w bazie sprzedażowej |
| wh1_usage | Umożliwia używanie klastra obliczeniowego wh1 |
| wh2_usage | Umożliwia używanie klastra obliczeniowego wh2 |
| wh1_monitor | Umożliwia monitorowanie użytkowania klastra wh1 |
| wh2_monitor | Umożliwia monitorowanie użytkowania klastra wh2 |
Utworzenie ról dostępowych:
USE ROLE USERADMIN;
CREATE ROLE hr_read_only;
CREATE ROLE hr_all;
CREATE ROLE sale_read_only;
CREATE ROLE sale_all;
CREATE ROLE wh1_usage;
CREATE ROLE wh2_usage;
CREATE ROLE wh1_monitor;
CREATE ROLE wh2_monitor;Nadawanie przykładowych uprawnień rolom dostępowym:
USE ROLE SECURITYADMIN;
--uprawnienia dla hr_read_only
GRANT USAGE ON DATABASE hr TO ROLE hr_read_only;
GRANT USAGE ON all SCHEMAS IN DATABASE hr TO ROLE hr_read_only;
GRANT USAGE ON future SCHEMAS IN DATABASE hr TO ROLE hr_read_only;
GRANT SELECT ON ALL TABLES IN DATABASE hr TO ROLE hr_read_only;
GRANT SELECT ON future TABLES IN DATABASE hr TO ROLE hr_read_only;
--uprawnienia dla roli hr_all
GRANT ALL ON DATABASE hr TO ROLE hr_all;
--uprawnienia dla roli wh1_usage
GRANT USAGE ON WAREHOUSE wh1 TO ROLE wh1_usage;
--uprawnienia dla roli wh1_monitor
GRANT MONITOR ON WAREHOUSE wh1 TO ROLE wh1_monitor;Przypisywanie ról dostępowych rolom funkcyjnym
Żeby każdy pracownik miał uprawnienia do wykonywania wszystkich czynności, które wchodzą w skład ich obowiązków załóżmy, że role powinny być przypisane zgodnie z poniższym schematem.
Wykorzystując hierarchie ról w Snowflake’u senior data engineer będzie miał dostęp do wszystkich uprawnień juniora, a ponadto będzie mógł też monitorować wykorzystanie klastrów obliczeniowych. Taki podział ułatwia też zarządzanie i monitorowanie uprawnień w organizacji.
USE ROLE USERADMIN;
GRANT ROLE hr_read_only TO ROLE analyst;
GRANT ROLE sale_read_only TO ROLE analyst;
GRANT ROLE wh1_usage TO ROLE analyst;
GRANT ROLE sale_read_only TO ROLE accountant;
GRANT ROLE wh1_usage TO ROLE accountant;
GRANT ROLE sale_all TO ROLE data_engineer_jr;
GRANT ROLE hr_all TO ROLE data_engineer_jr;
GRANT ROLE wh1_usage TO ROLE data_engineer_jr;
GRANT ROLE wh2_usage TO ROLE data_engineer_jr;
GRANT ROLE wh1_monitor TO ROLE data_engineer_sr;
GRANT ROLE wh2_monitor TO ROLE data_engineer_sr;Ostatnią rzeczą jest przypisanie ról funkcjonalnych do poszczególnych użytkowników, żeby mogli wykonywać swoje obowiązki. Zostawię to już Tobie. 😉
Podsumowując zarządzanie uprawnieniami w Snowflake’u
Jakie ryzyka niesie ze sobą bałagan w uprawnieniach?
- naruszenia RODO
- bałagan w modelach danych
- niepotrzebne tabele
- błędne nazewnictwo
- kiepska jakość danych
- duplikacja danych
- brak dokumentacji
- wyższe koszty
- nieefektywny kod SQL
- znowu: zbędna duplikacja danych
Najlepiej nadawać uprawnienia zgodnie z zasadą najmniejszego uprzywilejowania. Jeśli nie monitorujesz i nie dbasz o jakość tworzonych obiektów w bazach danych, to użytkownicy mogący tworzyć nowe obiekty mogą szybko doprowadzić do chaosu, którego porządkowanie będzie czasochłonne i bolesne. Opisana w tym wpisie metoda na zarządzanie uprawnieniami jest świetnym rozwiązaniem na zapanowanie nad tym wszystkim, jednak pamiętaj, żeby stale monitorować role i dostępy, żeby stale spełniały zasady i kryteria jakościowe, które masz ustalone w swojej organizacji.
Dodaj komentarz