Systemy Zarządzania Bazami Danych

Prezentacja na temat: "Systemy Zarządzania Bazami Danych"— Zapis prezentacji:

1 Systemy Zarządzania Bazami Danych
Laboratorium 05 Role i uprawnienia

2 Agenda laboratorium Bezpieczeństwo Wprowadzenie – Role CREATE ROLE
CREATE ROLE – Management Studio ALTER ROLE ALTER ROLE – Management Studio DROP ROLE Wprowadzenie – Uprawnienia GRANT (role serwera) GRANT (role serwera) – Management Studio GRANT GRANT– Management Studio ROLE ROLE – Management Studio REVOKE DENY Zadania

3 Bezpieczeństwo Bezpieczeństwo bazy danych jest bardzo istotną kwestią w każdej firmie czy korporacji. Zapewnienie dostępu do systemu bazodanowego tylko dla osób korzystających z systemu bazodanowego nie gwarantuje jego bezpieczeństwa. W różnego typu przedsiębiorstwach i organizacjach bazy danych służą do przechowywania ogromnej ilości danych. Często jest tak, że część danych jest mocno powiązana z „biznesem” firmy. Od informacji zawartych w systemie zależy pozycja finansowa przedsiębiorstwa. Na przykład firma, która w przeciągu miesiąca wystawia tysiące rachunków swoim klientom na podstawie zgromadzonych danych w bazie, może ponieść ogromne straty jeśli osoba nie powołana do pewnych operacji będzie miała do nich dostęp. Usunięte lub błędnie zmodyfikowane dane można przywrócić z kopii zapasowej, jednak jeśli nieprawidłowości nie zostaną wykryte w odpowiednim momencie to strat finansowych nie będzie można cofnąć. Im większa firma, tym większa bywa baza danych i liczba jej użytkowników. Różni użytkownicy korzystają z bazy danych na różne sposoby i nie koniecznie z tych samych danych. Zdarza się również, że osoba mająca dostęp do nieodpowiednich danych w sposób nieświadomy, przez pomyłkę usunęła bądź zmieniła dane. Takie sytuacje mają miejsce, kiedy dana grupa użytkowników, lub użytkownik posiadają nadmiarowy dostęp do systemu. Aby zapobiec tego typu sytuacją, wykorzystuje się warstwę języka SQL: DCL.

4 Wprowadzenie Role bazy danych są istotną kwestią bezpieczeństwa w każdym systemie bazodanowym. Warstwa DDL obejmuje jedynie tworzenie, zmienianie i usuwanie ról. Aby zarządzać rolami należy się odwołać do części DCL języka SQL, w której to określono jak przydzielać i poszerzać role. Bieżący rozdział jest poświęcony warstwie DDL tak więc zakres przedstawienia ról bazy danych będzie przedstawiony z perspektywy tej warstwy. Generalnie wyróżnia się trzy typy ról: Systemowe Bazy danych Aplikacji Role systemowe są zintegrowane w systemie SQL Server 2005 i nie można modyfikować istniejących czy dodawać nowych. Aby wyświetlić te role należy rozwinąć gałąź Server Roles w oknie Object Explorer. Role bazy danych czy aplikacji można modyfikować i tworzyć nowe.

5 CREATE ROLE Stworzenie roli za pomocą języka SQL prezentuje poniższa komenda. W miejscu role_name należy podać unikalną w przestrzeni bazy danych nazwę roli. Administrator tworząc role może ją „przekazać” dla innego użytkownika jako jego własną. Do tego służy opcja AUTHORIZATION, gdzie jako owner_name podaje się nazwę użytkownika, który ma być jego właścicielem. Pominięcie tej opcji, powoduje automatycznie nadanie praw własności do roli osobie ją tworzącej. CREATE ROLE role_name [ AUTHORIZATION owner_name ]

6 CREATE ROLE – Management Studio
Od strony graficznej, czyli za pomocą Management Studio tworzenie roli wygląda następująco. W Object Explorer należy kliknąć prawym przyciskiem myszy na folder Database Roles i wybrać z menu kontekstowego New Database Role.

7 CREATE ROLE – Management Studio
Kolejnym krokiem jest wypełnienie pola nazwy roli oraz opcjonalnie właściciela i schematu. W interfejsie graficznym jest również możliwość dodania odpowiednich właściwości ról, jednak nie leży to w zakresie warstwy DDL.

8 ALTER ROLE Za pomocą komendy ALTER ROLE można jedynie zmienić nazwę wcześniej stworzonej roli. Schemat polecenia poniżej prezentuje polecenie ALTER TABEL. Jako role_name należy podać nazwę roli zaś jako new_name podaje się jej nową nazwę. ALTER ROLE role_name WITH NAME = new_name

9 ALTER ROLE – Management Studio
Edycja roli w Management Studio wygląda identycznie jak jej tworzenie. W tym celu należy odnaleźć żądaną rolę w folderze Databases Roles w danej bazie danych i wybrać polecenie Properties. Okno , które ukaże się po wybraniu tej opcji prezentuje się podobnie jak okno tworzenia roli i prezentuje takie same możliwości.

10 DROP ROLE Aby pozbyć się roli z system bazy danych wystarczy użyć poniższej składni usuwania. W miejscu elementu role_name należy podać nazwę roli i wykonać polecenie a rola zostanie skasowana. Aczkolwiek kasowanie roli, która jest przypisana np. do użytkownika, nie może być usunięta. Aby usunąć rolę należy wyłączyć z niej wszystkich członków. DROP ROLE role_name Usunięcie roli w Management Studio jest dość proste do wykonania. Wystarczy rozwinąć menu kontekstowe roli i wybrać polecenie Delete.

11 Wprowadzenie - Uprawnienia
Jednym z przywilejów a zarazem obowiązków administratora systemu bazodanowego jest nadawanie i kontrola uprawnień użytkowników. Generalnie zasada, którą powinien się kierować administrator to nadawanie użytkownikom praw w taki sposób aby mogli wykonywać swoje codzienne zadania w bazie danych ale nie mając możliwości przeglądania, modyfikacji i usuwania jakichkolwiek danych niebędących w zakresie ich pracy. Inaczej, użytkownik musi mieć odpowiedni dostęp tylko do danych, które są mu niezbędne. Tak więc, opiekun systemu powinien znać aplikacje i stanowiska w firmie aby móc nadać im odpowiednie przywileje.

12 GRANT Poleceniem do nadawania uprawnień jest GRANT. Między innymi rozróżnia się dwa rodzaje nadawani uprawnień. Są to uprawnienia dla użytkowników systemu (Login) i użytkowników bazy danych (User). Dla danego login’u można nadać uprawnienia w skali administracyjnej systemu. Wykorzystuje się to jedynie kiedy prace administracyjne są dzielone na kilku administratorów. Przykładowo można stworzyć użytkownika systemu i zezwolić ma na modyfikowanie struktur baz danych (ALTER ANY DATABASE) aby miał możliwość wsparcia głównego administratora w danych zadaniach. Dokumentacja SQL Server 2005, Books Online

13 GRANT (role serwera) Poniższy schemat komendy GRANT służy do nadawania praw użytkownikom systemu. W miejscu permission podaje się co najmniej jedno pozwolenie, które ma być nadane. Pełna lista zezwoleń znajduje się w dokumentacji SQL Server 2005 Books Online. Zezwoleń dostępnych w SQL Server jest 25i dotyczą one wszelkich aspektów związanych z systemem. Po wyrażeniu TO należy określić dla kogo mają być nada przywileje. Istnieje możliwość nadania uprawnień dla wielu użytkowników jednym poleceniem (należy jednak tego unikać a w zamian to użyć ról serwera). Osoba, której zostaną nadane przywileje nie może przekazywać ich innym użytkownikom. Aczkolwiek, zastosowanie opcji WITH GRANT OPTION zezwala użytkownikom na nadawanie przyjętych uprawnień innym osobom. WITH GRANT OPTION w przypadku przywilejów systemu należy używać z dużą ostrożnością, aby uprawnienia nie zostały przekazane świadomie lub nieświadomie użytkownikom nie powołanym do administracji z poziomu całej instancji. Słowo kluczowe AS pozwala na przyznanie praw użytkownikowi z poziomu innego użytkownika. Może mieć to zastosowanie jeśli np. ma być dodany nowy administrator, z uprawnieniami nie większymi niż inny, pracujący już w systemie. Gałęzie <grantee_principal> I <grantor_principal> zawierają informacje o tym, z jakiego login’u mają być nadane/otrzymane uprawnienia a dokładnie o jakim typie autentykacji login’u.

14 GRANT (role serwera) GRANT permission [ ,...n ]
TO <grantee_principal> [ ,...n ] [ WITH GRANT OPTION ] [ AS <grantor_principal> ] <grantee_principal> ::= SQL_Server_login | SQL_Server_login_mapped_to_Windows_login | SQL_Server_login_mapped_to_Windows_group | SQL_Server_login_mapped_to_certificate | SQL_Server_login_mapped_to_asymmetric_key <grantor_principal> ::= SQL_Server_login

15 GRANT (role serwera) – Management Studio
Nadawanie ról systemowych można wykonać za pomocą powyższego listingu, lub Management Studio. Wykorzystując interfejs graficzny należy się odwołać do okna Object Explorer. Następnie w folderze Security otworzyć pod folder Logins i klikną na wybranego użytkownika prawym przyciskiem myszy, poczym kliknąć polecenie Properties. Po wykonaniu tej czynności pojawi się okno właściwości użytkownika systemu. Za uprawnienia login’u odpowiada strona Securables. W tabeli w górnej części okna widoczne są obiekty lub serwer, do których są nadane prawa. Za pomocą przycisku Add można dodać obiekty. W tabeli położonej w dolnej części okna są wyszczególnione wszelkie operacje do których można nadać lub odebrać prawa.

16 GRANT Nadawanie szczegółowych uprawnień dla login’u lub user’a wykonuje się zgodnie ze schematem polecenia GRANT z listingu poniżej. Generalnie jest tym samym poleceniem co powyższe, aczkolwiek jest dostosowane do nadawania uprawnień na poziomie bazy danych. Zasadniczą różnicą co do przywilejów systemowych, tutaj można dokładnie określić czy dany użytkownik ma mieć prawo do przeglądania, modyfikacji usuwania danych lun wykonywania procedur/funkcji. Jako permission należy określić jakiego typu ma być uprawnienie. Można użyć opcji ALL w celu nadania wszelkich przywilejów związanych z danym obiektem lub sprecyzować dokładne zezwolenie. Przywileje bazy danych są dostępne w dokumentacji systemu. Są to między innymi EXECUTE (wykonywanie np. procedur), SELECT (przeglądanie danych), UPDATE (modyfikacja danych) itp. Po parametrze ON podaje się obiekt, którego będzie dotyczyć nadane uprawnienie. Może to być między innymi procedura czy tabela/widok. Istnieje również możliwość dokładnego sprecyzowania do jakich kolumn w tabeli/widoku ma być nadanie uprawnienie. Podobnie jak w poprzednim schemacie GRANT, po parametrze TO podaje się obiekt dla którego ma być utworzony przywilej. Obiektem tym może być użytkownik, rola, rola aplikacji lub login.

17 GRANT GRANT <permission> [ ,...n ] ON
[ OBJECT :: ][ schema_name ]. object_name [ ( column [ ,...n ] ) ] TO <database_principal> [ ,...n ] [ WITH GRANT OPTION ] [ AS <database_principal> ] <permission> ::= ALL | permission <database_principal> ::= Database_user | Database_role | Application_role | Database_user_mapped_to_Windows_User | Database_user_mapped_to_Windows_Group | Database_user_mapped_to_certificate | Database_user_mapped_to_asymmetric_key | Database_user_with_no_login

18 GRANT Wygodnym sposobem na przydzielanie przywilejów użytkownikom jest posłużenie się management Studio (rysunek na następnym slajdzie). W tym celu wystarczy w oknie Object Explorer odszukać bazę danych, której znajduje się dany użytkownik. Następnie rozwinąć folder Security oraz Users i kliknąć na użytkownika prawym przyciskiem myszy w celu wykonania pole cenienia Properties. W oknie ustawień użytkownika trzeba wybrać stronę Securables (lewa część okna). Główna częsć okna będzie zawierała dwie tabele. Pierwsza z nich, górna przedstawia spis obiektów do których użytkownik ma dostęp. Aby dodać nowe obiekty bazy danych należy posłużyć się przyciskiem Add, który znajduje się pomiędzy tabelami. Na przedstawionym rysunku wybrano tabelę o nazwie ADRES. W dolnej tabeli znajdują się wszelkie dostępne prawa, które można nadać użytkownikowi. Można również zabronić dostępu do wybranych przywilejów. Kolumna With Grant, umożliwia na zastosowanie opcji WITH GRANT OPTION, pozwalającej na nadawanie przyznanych praw innym użytkownikom przez tego użytkownika.

19 GRANT

20 ROLE W baza danych, zazwyczaj istnieje wielu użytkowników. W zależności od specyfiki systemu, może on zawierać nawet kilkudziesięciu użytkowników. Jeżeli administrator miałby dla każdego z osobna nadawać uprawnienia, zapewne miał by bardzo dużo pracy i mógł by się pomylić co mogło by być destruktywne jeżeli nadał by za wysokie uprawnienia dla osoby nie upoważnionej. Istnieje możliwość grupowania uprawnień, role. System SQL Server 2005 posiada standardowo pewien zbiór ról. Zarówno dla systemu jak i baz danych. W przypadku systemu istnieje kilka kluczowych ról, których nie można modyfikować a nawet tworzyć nowych. Są one z góry określone i dopasowane do odpowiednich zadań administracyjnych. Grupa ról bazy danych nie jest rygorystycznie strzeżona jak role systemu. Administrator ma możliwość komponowania własnych ról na potrzeby bazy danych. Dzięki temu, może on stworzyć odpowiednie grupy z dostosowanymi uprawnieniami, na przykład do stanowisk w firmie. Po utworzeniu roli, można nadać jej uprawnienia zgodnie z poprzednim listingiem GRANT. Uprawnienia dla roli przydziela się dokładnie tak samo jak dla użytkownika. Aczkolwiek niemożliwe jest użycie WITH GRANT OPTION, kiedy nadajemy prawa dla roli. Jest to spowodowane tym, że kiedy użytkownicy ról mogli by dowolnie „rozdawać” przywileje innym użytkownikom to powstały by „dziury” w bezpieczeństwie systemu. Dlatego tworzy się role dla użytkowników lub grup użytkowników bez możliwości rozprzestrzeniania uprawnień. Administrator jest odpowiedzialny za dostęp do danych i musi kontrolować jakie uprawnienia i dla kogo są nadawane. Po utworzeniu roli i nadaniu jej żądanych uprawnień można dołączyć do niej użytkowników. W tym celu należy się posłużyć procedurą przedstawioną na następnym slajdzie.

21 ROLE sp_addrolemember [ @rolename = ] 'role',
= ] 'security_account‘ Przykładowe użycie dołączenia użytkownika do roli: EXEC sp_addrolemember ‘rolaSprzedawcy’, ‘JKowalski’ Wynik powyższej operacji będzie taki, że do wcześniej stworzonej roli o nazwie rolaSprzedawcy został dołączony użytkownik JKowalski. Wyrzucenie użytkownika z roli: sp_droprolemember = ] 'role' , = ] 'security_account'

22 REVOKE Nadanie uprawnienia można również odebrać. W tym celu należy się posłużyć poleceniem REVOKE. Można w nim sprecyzować, jakie dokładnie prawa mają być odebrane lub odebrać wszystkie przywileje do danego obiektu. Poniżej został zaprezentowany schemat zapytania SQL, który służy do odbierania uprawnień. Pierwszą opcją jest GRANT OPTION FOR. Odbiera ona przywilej nadawania uprawnień dla danego użytkownika/roli. Następnie można określić czy mają zostać odebrane wszystkie (ALL) lub wyspecyfikowane przywileje (wymienia się je w miejscu permission). Po parametrze ON można określić do jakiego obiektu ma się odnosić odebranie praw. Dodatkowo istnieje możliwość wypisania kolumn tabeli/widoku. Następnie w zależności od tego czy dobierane są uprawnienia od użytkownika/roli czy od grupy użytkowników, wybiera się TO (użytkownik) lub FROM (grupa). Opcja CASCADE odbiera dane przywileje również od użytkowników, którym zastałe one przyznane z poziomu tego użytkownika. Ostatnią możliwością polecenia REVOKE jest AS. Jeżeli zostanie ono użyte, to trzeba wpisać użytkownika, z którego poziomu ma być odebrane uprawnienie. W Management Studio nie ma takiej opcji jak REVOKE. Wszystkie przywileje nadaje się za pomocą tabel. Odebranie praw polega na „odhaczeniu” danego uprawniania w tabeli zezwoleń.

23 REVOKE REVOKE [ GRANT OPTION FOR ] { [ ALL]
| permission [ ( column [ ,...n ] ) ] [ ,...n ] } [ ON [ class :: ] securable ] { TO | FROM } principal [ ,...n ] [ CASCADE] [ AS principal ]

24 REVOKE Kolejnym poleceniem odbierania uprawnień jest DENY. Zabrania ono na korzystania z danego przywileju pomimo, że dane użytkownik należy do grupy użytkowników mającej dany przywilej. Polecenie DENY posiada te same opcje co REVOKE, z tą różnicą, ze nie nie ma parametru FROM i AS Schemat polecenia według dokumentacji SQL Server wygląda następująco: DENY { ALL [ PRIVILEGES ] } | permission [ ( column [ ,...n ] ) ] [ ,...n ] [ ON [ class :: ] securable ] TO principal [ ,...n ] [ CASCADE] [ AS principal ]

25 Zadania Poniższe ćwiczenia wykonaj za pomocą składni języka SQL. Następnie powtórz zadania za pomocą narzędzi Management Studio. 1. Stwórz dwóch użytkowników w bazie Restauracja. - test1_r dla login’u test1_r (autoryzacja SQL Server) - test2_r dla login’u test2_r (autoryzacja SQL Server) 2. Stwórz rolę r_sprzedawca, której właścicielem będzie test1_r. Rola ma mieć następujące uprawnienia (tabela – uprawnienia): - CENNIK – SELECT, UPDATE - REZERWACJA – SELECT, UPDATE, INSERT, DELETE - STOLIK – SELECT - ZAMOWIENIE - SELECT, UPDATE, INSERT, DELETE - ZAMOWIENIE_PRZEPISY - SELECT, UPDATE, INSERT, DELETE 3. Dodaj użytkownika test2_r do roli 4. Zaloguj się na test2_r i sprawdź czy uprawnienia zostały nadane 5. Zmień nazwę roli na r_sprzedawcaNew 6. Odbierz możliwość wykonywania SELECT dla test2_r (DENY) 9. Sprawdź czy zostały one odebrane (zaloguj się na test2_r i sprawdź) 10. Spróbuj usunąć rolę z systemu 11. Usuń test2_r z roli 12. Ponownie spróbuj usunąć rolę

26 Koniec laboratorium 04