SQL Server and Windows

Ćwiczenie 2
Zarządzanie mechanizmami bezpieczeństwa
SQL Servera
1
1.Wprowadzenie teoretyczne. .................................................................................................... 2
2.Tryby zabezpieczeń SQL Servera ........................................................................................... 3
Uwierzytelnianie(zabezpieczenie) może być realizowane na dwa sposoby: ..................... 3
2.1. Tryb uwierzytelniania Windows (Windows integrate mode) ......................................... 3
2.2. Tryb uwierzytelniania „SQL Server and Windows” (Mixed Mode) .............................. 3
2.2.1. SQL Server Authentication Mode ............................................................................ 3
3. Użytkownicy bazy danych ..................................................................................................... 6
3.1. Dodawanie użytkownika do bazy danych ....................................................................... 6
3.2. Nazwa użytkownika — Guest ......................................................................................... 7
3.3. Zmiana właściciela bazy danych ..................................................................................... 8
4. Role ........................................................................................................................................ 8
4.1. Role o zasięgu serwera .................................................................................................... 8
4.2. Przypisanie konta logowania do roli serwera .................................................................. 8
4.3. Role bazy danych ............................................................................................................ 9
4.3.1. Role w bazie danych zdefiniowane przez użytkownika ........................................... 9
4.4. Role aplikacji................................................................................................................. 10
5. Uprawnienia użytkownika.................................................................................................... 11
5.1. Instrukcje uprawnień ..................................................................................................... 12
5.2. Przydzielanie uprawnień polecenia ............................................................................... 12
5.3. Uprawnienia obiektu ..................................................................................................... 13
5.3.1. Przyznawanie uprawnień obiektu........................................................................... 13
6.Przebieg ćwiczenia. ............................................................................................................... 15
7.Treść sprawozdania. .............................................................................................................. 18
8. Przykładowe pytania kontrolne. ........................................................................................... 18
1.Wprowadzenie teoretyczne.
Zarządzanie mechanizmami bezpieczeństwa polega na kontrolowaniu dostępu do SQL
Servera, jego baz danych i obiektów, które zawierają oraz na przydzieleniu uprawnień
użytkownikom wykonującym czynności administracyjne. Uwierzytelnianie to proces, w
którym SQL Server sprawdza dane użytkownika.
Jeżeli SQL Server działa w systemie Windows 2000/NT, przy próbie połączenia z SQL
Serverem 2000 zabezpieczenia są sprawdzane w trzech różnych miejscach(Rys.1).
Sprawdzenie może występować: 1)- na poziomie Windows 2000, 2)-samego SQL Servera (w
formie logowania do niego), 3)- na poziomie bazy danych (w formie nazwy użytkownika
bazy danych). Aby połączyć się z SQL Serverem należy podać prawidłowe hasło i nazwę
użytkownika lub korzystać z istniejącego konta Windows. Jeżeli dane logowania są
prawidłowe, nastąpi połączenie z SQL Serverem. Jeżeli dane nie są prawidłowe, nastąpi
odmowa dostępu. Podanie nazwy przy logowaniu do SQL Serwera nie mówi nic o tym, z
którą bazą danych użytkownik chce się połączyć, jedynie nazwa użytkownika na poziomie
bazy ustawia tą zasadę. Logowanie nie daje również faktycznego dostępu do jakiegokolwiek
obiektu bazy danych; wymaga to praw dostępu.
2
Rys.1
System bezpieczeństwa bezpośrednio samego SQL Serwera jest oparty ma modelu
dwuwarstwowym. Pierwsza warstwę stanowi sam proces uzyskiwania dostępu do SQL
Servera. Ostatnią warstwą zabezpieczeń są prawa dostępu. Po pomyślnym załogowaniu się do
SQL Servera i przełączeniu się do bazy danych, należy uzyskać odpowiednie prawa dostępu
do obiektów bazy (zarówno do odczytu jak i modyfikacji).
2.Tryby zabezpieczeń SQL Servera
Uwierzytelnianie(zabezpieczenie) może być realizowane na dwa sposoby:
 Uwierzytelnianie przez Windows (Windows only)
 Tryb mieszany (SQL Server and Windows).
Tryb uwierzytelniania określa czy system Windows lub obydwa Windows i SQL Server są
odpowiedzialne za kontrolę poprawności żądań połączenia z SQL Serverem.
2.1. Tryb uwierzytelniania Windows (Windows integrate mode)
W tym trybie połączenia z SQL Serverem uwierzytelniane są na podstawie konta w systemie
Windows, z którego łączy się użytkownik. SQL Server sprawdza, czy w tabeli syslogins bazy
danych Master znajduje się login odpowiadający danemu kontu i jeśli tak, pozwala na
nawiązanie połączenia. To połączenie nazywa się zaufanym, ponieważ w procesie
uwierzytelniania SQL Server ufa informacjom otrzymanym od kontrolera domen. To
rozwiązanie ma tę zaletę, że aby połączyć się z SQL Serverem, wystarczy załogować się tylko
raz – w systemie Windows, a poza tym pozwala ono korzystać z domenowych mechanizmów
bezpieczeństwa, takich jak określenie minimalnej długości i okresu ważności hasła,
blokowanie kont czy szyfrowanie danych.
2.2. Tryb uwierzytelniania „SQL Server and Windows” (Mixed Mode)
Mieszany tryb uwierzytelniania pozwala na jednoczesne stosowanie mechanizmów
uwierzytelniania SQL Servera i systemu Windows. W tym przypadku zabezpieczenia
użytkownik może się połączyć z SQL Serverem przy pomocy systemu Windows ( Windows
Integrated Mode) lub przez SQL Server (SQL Server Authentication Mode). Mixed Mode jest
najlepszym wyborem dla zachowania zgodności wstecz z wcześniejszymi wersjami i
dostarcza wiele możliwości połączeń z komputerami nie korzystającymi z systemu Windows
w celu połączenia, jak np. klienci Novell NetWare, Linuks.
2.2.1. SQL Server Authentication Mode
Ten tryb wchodzi do trybu mieszanego oraz wyznacza konsekwentność czynności SQL
Servera do uwierzytelniania użytkowników. W trybie „SQL Server 2000 and Windows”
uwierzytelnianie przez SQL Server (SQL Server Authentication Mode) występuje kiedy SQL
Server akceptuje identyfikator logowania — ID i hasło użytkownika oraz sprawdza czy dane
3
są poprawne, bez żadnej pomocy systemu Windows. Metoda ta zawsze jest używana na
komputerach z systemem Windows 9x i jest opcjonalna na komputerach z systemem
Windows 2000/NT. Tryb ten nie jest tak bezpieczny jak Windows Integrated Mode i nie jest
polecany dla SQL Servera przechowującego bardzo istotne informacje. Informacje na temat
logowania przechowywane są na SQL Serverze (w bazie danych master, w tablicy
systemowej sysxlogins).
Po zainstalowaniu SQL Servera 2000, istnieje jedynie standardowy login sa. Na komputerach
z systemem Windows 2000, grupa administratorów lokalnych jest również dodana jako
alternatywa do sa (jako członkowie roli sysadmin).
Hasła logowania w trybie SQL Server Authentication Mode są przetrzymywane w
kolumnie password tabeli sysxlogins w bazie danych master. Aby obejrzeć wpisy w tabeli
sysxlogins, należy uruchomić SQL Server Query Analyzera i uruchomić poniższe zapytanie
(należy posiadać uprawnienia roli sysadmin, aby uruchomić to zapytanie):
SELECT substring (name,1,25) AS name,
substring (password,1,20) as password, language
FROM sysxlogins
name
password
language
............. ........................ ..............................
BUILTIN\Administrators
NULL
us_english
RHOME\SQLService
NULL
us_english
sa
0x2131214A212C312939442439285B585D NULL
NULL
NULL
NULL
(4 row(s) affected)
Pierwszy wiersz w wydruku wyjściowym prezentuje grupę lokalnych administratorów
systemu Windows. Następny wiersz reprezentuje konto usługi jakie zostało wybrane dla usług
SQL Servera podczas instalacji. Identyfikator logowania sa pokazany w następnym wierszu
jest instalowany wraz z hasłem podczas instalacji systemu. Wszystkie konta i hasła SQL
Servera są trzymane w tabeli systemowej. Jeżeli hasło jest zerowe (puste), w kolumnie
password pojawi się słowo kluczowe NULL. Jeżeli hasło jest nie puste, jest ono
przechowywane jako zaszyfrowany tekst, w systemie szesnastkowym (jak pokazano dla sa).
Należy zwrócić uwagę na następne:

Jedynie użytkownik posiadający uprawnienia roli sysadmin (również użytkownik sa) może zobaczyć
kolumnę password. Żaden inny użytkownik nie może jej zobaczyć, chyba, że zostanie mu bezpośrednio
przydzielone prawo do przeglądania tej kolumny.

Algorytm szyfrowania jest jednokierunkowy. Jeżeli hasło zostało zaszyfrowane, nie może być
odszyfrowane. Podczas logowania, podane hasło jest szyfrowane a następnie porównywane z
zaszyfrowanym hasłem w tabeli sysxlogins. Jeżeli do siebie pasują, użytkownik otrzymuje dostęp do
serwera. Jeżeli nie pasują, użytkownik otrzyma komunikat Login Failed i nie uzyska połączenia.
Również w przypadku korzystania z logowania z wykorzystaniem zabezpieczeń Windows Only, żadne
hasła nie są przechowywane na SQL Serverze.
Pierwszym krokiem w ustawieniach dostępu do SQL serwera jest utworzenie kont logowania.
Można dodać konta przy pomocy systemowej procedury składowej sp_addlogin lub SQL
Server Enterprise Managera:
sp_addlogin [@loginname =] 'login' [,[@passwd =] 'password'
[,[@defdb =] 'database' [,[@deflanguage =] 'language'
[,[@sid =] 'sid' [,[@encryptopt =] 'encryption_option']]]]]
Znaczenie składni:
4

login jest nazwą, używaną przez użytkownika podczas logowania. Nazwa ta musi być poprawnym
identyfikatorem SQL Servera (rozpoczynającym się od litery lub znaku #,@ lub _, a reszta znaków może
być złożona z tych znaków lub liter oraz liczb – do 128 znaków Unicode).

password jest hasłem związanym z nazwą podawaną przy logowaniu. Hasło jest puste, jeśli żadne nie
zostało wybrane.

database jest domyślną bazą danych, do jakiej połdączy się użytkownik po zalogowaniu. Jeżeli ten
parametr nie zostanie określony, domyślnie przyjmowaną bazą danych jest master.

language jest domyślnym językiem używanym dla danego użytkownika po zalogowaniu. Jeżeli parametr
ten nie zostanie określony, domyślnie przyjmowany jest język US_English.

sid jest identyfikatorem zabezpieczeń określanym dla użytkownika (ta opcja nie jest zalecana).

Można użyć opcji encryption_option do wyłączenia szyfrowania hasła (wymienionego wcześniej).
Własność ta pozwala na rozpakowanie zaszyfrowanego hasła z wcześniejszej wersji SQL Servera i
umieszczenie go bezpośrednio w SQL Serverze 2000, tak, że hasło logującego się użytkownika będzie
również działało z tym SQL Serverem. Aby wyłączyć szyfrowanie należy użyć tutaj dosłownego polecenia
skip_encryption.
Aby dodać dane logowania do serwera, należy otworzyć SQL Server Query Analyzer i
zalogować się. Następnie uruchomić następujące polecenie Transact-SQL (T-SQL):
EXEC sp_addlogin 'nazwa_użytkownika', 'hasło_użytkownika'
Kolejną operacją, jaką może wykonać użytkownik jest zmiana hasła. Również w tym
przypadku można skorzystać z SQL Server Enterprise Managera lub z procedury
systemowej sp_password:
sp_password [[@old =] 'old',] {[@new =] 'new'}
[,[@loginame =] 'login']
Składnia:

old oznacza stare hasło.

new oznacza nowe hasło.

W przypadku loginame jeżeli zalogowany użytkownik posiada uprawnienia ról sysadmin lub
securityadmin, może zmienić dowolne hasło. Faktycznie, nie potrzeba znać starego hasło danej osoby;
wystarczy po prostu ustawić stare hasło jako hasło puste.
Jednym z istotnych punktów jest to, że użytkownicy posiadający własności roli securityadmin mogą zmienić
wszystkie hasła za wyjątkiem haseł użytkowników z uprawnieniami roli sysadmin. Natomiast użytkownicy
posiadający uprawnienia roli sysadmin mogą zmieniać wszystkie hasła, bez wyjątku.
Poniżej przedstawiono przykład wykorzystania systemowej procedury składowej
sp_password:
EXEC sp_password NULL, 'newpass', 'richard'
Pomimo tego, że stare hasło użytkownika Richard nie jest znane, administrator może zmienić
hasło. Zwykli użytkownicy nie mogą tego wykonać i muszą znać swoje stare hasło, aby
dokonać zmiany na nowe — jest to jeden ze sposobów zabezpieczenia. Procedura ta nie
powinna być trudna do przestrzegania ponieważ użytkownik musi się najpierw zalogować
(podając stare hasło) zanim będzie mógł uruchomić polecenie zmieniające hasło.
Można również zmienić domyślną bazę danych lub domyślny język zalogowanego
użytkownika. Zmiany można wprowadzić z SQL Server Enterprise Managera lub przy
pomocy procedur sp_defaultdb lub sp_defaultlanguage:
sp_defaultdb loginname, defdb
sp_defaultlanguage loginname [, language]
5
Parametry są identyczne jak omawiane wcześniej. Opcje te pozwalają na zmianę różnych pól
w tabeli systemowej sysxlogins (zmianę domyślnej bazy lub domyślnego języka).
Do zarządzania logowaniem służą jeszcze dwie dodatkowe procedury systemowe:
sp_helplogins i sp_droplogin. Procedura składowa sp_helplogins umożliwia wygenerowanie
raportu na temat kont, jakie zostały utworzone na danym serwerze.
Procedura systemowa sp_droplogin usuwa wpis na temat konta logowania z tabeli
sysxlogins. Po usunięciu wpisu z tabeli, użytkownik nie może już zalogować się do SQL
Servera.
sp_droplogin login
W przypadku tej procedury login ma to samo znaczenie jak w omawianych wcześniej
procedurach.
3. Użytkownicy bazy danych
Po konfiguracji zabezpieczeń logowania i ustawieniu kont, można rozpocząć konfigurację
dostępu do bazy danych. Posiadanie konta w SQL Server nie oznacza dostępu do żadnej z baz
danych na serwerze. Do tego wymagane jest posiadanie nazwy użytkownika bazy danych.
Każda z baz danych ma osobną ścieżkę dostępu, która jest przechowywana w tabeli
systemowej sysusers w każdej z baz danych. Konta logowania są zasadniczo mapowane do
nazw użytkowników w każdej z baz, do której użytkownik ma posiadać dostęp. Można
utworzyć takie mapowanie lub utworzyć użytkownika bazy danych korzystając z procedury
systemowej sp_grantdbaccess lub z SQL Server Enterprise Managera.
3.1. Dodawanie użytkownika do bazy danych
Aby dodać użytkownika do bazy danych, należy uruchomić procedurę systemową
sp_grantdbaccess:
sp_grantdbaccess [@loginame =] 'login' [,[@name_in_db =] 'name_in_db'] OUTPUT
Znaczenie składni:

login jest nazwa stosowaną przy logowaniu dodaną wcześniej (jako konto użytkownika w SQL Serverze
lub konto użytkownika czy grupa Windows NT/2000).

name_in_db jest nazwą, jaka ma zostać nadana użytkownikowi korzystającemu z bazy danych (nazwa
użytkownika). Jeżeli nazwa nie zostanie określona, pozostaje taka sama jak nazwa przy logowaniu.
Zalecane jest aby nazwa użytkownika bazy pokrywała się z nazwą używaną przy logowaniu
do systemu, łatwiej jest wtedy śledzić zabezpieczenia logowań użytkowników w każdej z baz
danych. Nie jest to przymusowe. Jednak gdy przykładowo użytkownik Richard występuje
jako Bill w bazie danych Sales, a jako Johny w bazie danych pubs, wprowadza to
niepotrzebne zamieszanie. Używanie tej samej nazwie eliminuje niejasności z tym związane
(co jest istotną sprawą w tak złożonym produkcie jak SQL Server). Oczywiście, sprawa
wygląda inaczej, jeżeli używane są nazwy użytkowników i grup Windows.
Przykładowo, jeżeli Bob ma mieć dostęp do bazy pubs na serwerze, należy uruchomić
następującą procedurę:
Use pubs
EXEC sp_grantdbaccess 'RHOME\Bob'
W tym przypadku odpowiedzią systemu będzie komunikat:
Granted database access to ‘RHOME\Bob’
6
Można również wykonać tę operację dla grupy:
EXEC sp_grantdbaccess 'RHOME\Marketing'
Ponownie, powinien się pojawić komunikat o pomyślnym wykonaniu operacji. Po dodaniu
grupy, każdy z członków grupy Windows ma dostęp do bazy danych, ale jedynie grupa
posiada użytkownika bazy danych; oznacza to, że wpis nie istnieje dla każdego z członków
grupy osobno, a jedynie dla całej grupy, podobnie jak miało to miejsce z nazwami do
logowania.
Aby odmówić użytkownikowi dostępu do bazy danych, należy uruchomić systemową
procedurę składową sp_revokedbaccess:
sp_revokedbaccess [[@name_in_db =] 'name_in_db']
W tej procedurze, name_in_db jest nazwą użytkownika bazy danych, która ma zostać usunięta.
Jedynie użytkownicy posiadający role db_accessadmin i db_owner (lub stałą rolę serwera
sysadmin) mogą uruchamiać te procedury składowe.
Aby zobaczyć użytkowników w bazie danych i związane z nimi nazwy logowania, można
uruchomić systemową procedurę składową sp_helpuser:
sp_helpuser [[@name_in_db =] 'username']
W tym poleceniu parametr username jest opcjonalny i jest to nazwa użytkownika lub roli.
Jeżeli parametr username nie zostanie określony, tworzony jest raport o wszystkich
użytkownikach i rolach. W przeciwnym przypadku, otrzymuje się raport dotyczący określonej
roli i użytkownika.
Po utworzeniu bazy danych jeden użytkownik tworzony jest domyślnie. Jeden z tych
użytkowników nazywa się dbo (skrót od database owner). Użytkownik dbo jest domyślnie
mapowany jako nazwa logowania sa. Po zainstalowaniu SQL Servera, użytkownik sa jest
właścicielem wszystkich baz danych. Jeżeli inny użytkownik utworzy bazę danych będzie jej
właścicielem. Użytkownik dbo może wykonać w bazie danych wszystkie operacje bez
wyjątku. Użytkownik ten ma te same uprawnienia w bazie danych co użytkownicy
korzystający z roli sysadmin. Jednak, tylko użytkownicy mający przydzieloną stałą rolę
serwera sysadmin (omówioną później) mają wszelkie uprawienia dotyczące całości systemu.
Zostało powiedziane, że logowanie nie zezwala na dostęp do bazy danych, można jednak po
zalogowaniu mieć dostęp do wszystkich baz danych, również do bazy pubs i Northwind.
Należy skorzystać z konta guest. Uruchomienie polecenia sp_grantdbaccess 'guest' w bazie
danych dodaje do bazy danych specjalne konto użytkownika zwane guest.
3.2. Nazwa użytkownika — Guest
W przypadku zalogowania z nazwą, dla której nie została stworzona nazwa użytkownika w
bazie danych pubs, można dostać się do tej bazy jako użytkownik guest. W przypadku próby
dostępu do bazy danych, w której nie została zdefiniowana nazwa i nie istnieje konto guest,
próba dostępu zakończy się komunikatem o błędzie. Przykładowo, przy próbie używania bazy
danych Northwind (poprzez wybór tej bazy w polu Databases w SQL Server Query
Analyser lub uruchomienie polecenia Transact-SQL: use Northwind) po usunięciu nazwy
użytkownika guest (przy użyciu sp_revokedbaccess) otrzyma się komunikat:
Server: Msg 916, Level 14, State 1, Line 1
Server user 'don' is not a valid user in database 'Northwind'
7
Błąd mówi o tym, że konto logowania nie jest prawidłowo zmapowane do użytkownika w
bazie danych Northwind i oznacza, że nie istnieje w tej bazie konto guest. Aby rozwiązać ten
problem, należy dodać konto guest poprzez uruchomienie następującej procedury lub poprzez
dodanie prawidłowego mapowania konta logowania do bazy danych:
Use Northwind
EXEC sp_grantaccess 'guest'
3.3. Zmiana właściciela bazy danych
Może się zdarzyć, że trzeba zmienić właściciela istniejącej bazy danych aby przypisać
odpowiedzialność za daną bazę pojedynczemu administratorowi bazy danych (DBA). Jeżeli
takie zmiany mają być dokonane, w bazie danych nie może istnieć konto logowania jako
nazwa użytkownika.
Aby zmienić właściciela, należy uruchomić systemową procedurę składową
sp_changedbowner:
sp_changedbowner [@loginame =] 'login' [,[@map =] remap_alias_flag]
Znaczenie składni:

login jest identyfikatorem logowania ID SQL Servera, który ma być mapowany.

remap_alias_flag jest opcjonalnym parametrem, który, jeśli nie zostanie określony, powoduje, że
wszyscy użytkownicy posiadający aliasy dbo zostaną usunięci, gdy zostanie zmieniony właściciel bazy
danych. Jeżeli zostanie określony parametr TRUE, wszyscy, którzy posiadali aliasy do starego dbo,
otrzymają aliasy do nowego dbo.
4. Role
Role SQL Servera pozwalają na pogrupowanie nazw użytkowników bazy danych. Nie jest
istotne czy nazwy użytkowników pochodzą z grup, użytkowników Windows 2000 lub nazw
logowania SQL Servera. Role mogą być również przydzielane innym rolom.
4.1. Role o zasięgu serwera
Użytkownik sa ma wszelkie uprawnienia i może dokonać wszelkich operacji w instancji SQL
Servera. Chociaż to prawda, jest to spowodowane tym, że konto sa przynależy do roli serwera
nazwanej sysadmin. SQL Server posiada osiem ról serwera. W każdej chwili można przypisać
konto do jednej lub więcej z tych ról serwera. Jednak, nie można dodać ani usunąć żadnej roli
serwera. Przykładowo, nie można usunąć sa z roli sysadmin.
4.2. Przypisanie konta logowania do roli serwera
Aby przypisać nazwę konta logowania do określonej roli serwera, można skorzystać z SQL
Server Enterprise Managera lub systemowej procedury składowej sp_addsrvrolemember:
sp_addsrvrolemember [@loginame =] 'login', [@rolename =] 'role'
Składnia:

login jest identyfikatorem logowania ID SQL Server, który ma zostać dodany do roli.

role jest nazwą roli serwera, do której ma być przypisane konto.
Pojedyncze konto może należeć do jednej lub wielu ról lub nie należeć do żadnej. Jednak,
rola sysadmin obejmuje wszystkie inne role — zarówno serwera jako i role specyficzne dla
bazy danych — więc jeśli użytkownik przynależy do roli sysadmin, nie ma potrzeby
8
przypisywania mu żadnych innych ról. Aby usunąć konto użytkownika z roli serwera, należy
skorzystać z systemowej procedury składowej sp_dropsrvrolemember:
sp_dropsrvrolemember [@loginame =] 'login', [@rolename =] 'role'

login jest identyfikatorem logowania ID SQL Server, który ma zostać usunięty z roli.

role jest nazwą roli serwera, z której ma być usunięte konto.
Jako przykład, można przypisać konto RHOME\Bob do roli serwera securityadmin, przy pomocy
następującego polecenia:
Exec sp_addsrvrolemember 'RHOME\Bob', 'securityadmin'
W tym przypadku powinien się pojawić komunikat:
'RHOME\Bob' added to role 'securityadmin'.
Aby usunąć konto Bob z tej roli należy uruchomić polecenie:
Exec sp_dropsrvrolemember 'RHOME\Bob', 'securityadmin'
Powinien się pojawić komunikat informujący o udanej operacji:
'RHOME\Bob' dropped from role 'securityadmin'.
Aby wykonać te operacje z SQL Server Enterprise Managera, należy wybrać odpowiedni
serwer, folder zabezpieczeń i podświetlić opcję menu Server Roles (ikona obok ikony z
kluczem). Prawy panel zawiera osiem ról serwera. Należy kliknąć dwukrotnie Security
Administrators aby ukazało się okno Server Role Properties. Następnie nacisnąć przycisk
Add, pojawi się lista dostępnych kont logowania. Należy wybrać RHOME\Bob (lub odpowiednik
na własnym serwerze) i kliknąć OK. Po ponownym kliknięciu OK można uznać, że została
wykonana procedura systemowa sp_addsrvrolemember, tyle, że tym razem w postaci
interfejsu graficznego.
4.3. Role bazy danych
Każda baza danych również zawiera role. Niektóre z tych ról są z góry ustalone, można
również dodawać własne role (inaczej niż w przypadku ról serwera). Należy mieć na uwadze,
że role są specyficzne dla danej bazy, czyli nie można posiadać ról, które dotyczą więcej niż
jednej bazy danych w danym czasie. Jednak, można stworzyć takie same role w każdej z baz
danych.
4.3.1. Role w bazie danych zdefiniowane przez użytkownika
Dodatkowo, oprócz standardowo zdefiniowanych ról, można tworzyć również własne role a
następnie przypisywać użytkowników lub inne role do tych nowoutworzonych ról.
Użytkownik tworzy własne role w bazach danych SQL Servera z tego samego powodu, dla
którego tworzy się grupy w systemie Windows 2000 — aby pogrupować użytkowników,
którzy pełnią podobne funkcje. Należy tworzyć tyle ról, dla ilu istnieje sensowne
uzasadnienie. Nie ma ograniczeń, co do tego, do ilu ról może przynależeć użytkownik. Role
mogą należeć do innych ról.
Aby stworzyć rolę, należy uruchomić systemową procedurę składową sp_addrole:
sp_addrole [@rolename =] 'role' [,[@ownername =] 'owner']
Znaczenie składni:

role jest nazwą, jaka ma być nadana nowej roli.
9

owner jest nazwą użytkownika SQL Servera, który ma być właścicielem tej roli (każdy z użytkowników
może być właścicielem własnych ról). Domyślną wartością jest dbo, i na ogół jest to dokładnie ta pożądana
wartość (nie ma potrzeby jej zmieniać).
Jedynie członkowie roli serwera sysadmin lub ról bazy danych db_owner lub db_securityadmin mogą
dodawać nowe role do bazy danych. Dotyczy to również usuwania ról. Jedną szczególną cechą ról jest to, że
pomimo określenia nazwy właściciela, nazwa roli musi być unikalna w całej bazie danych. Dlatego, nie potrzeba
znać nazwy właściciela roli, którą chce się usunąć, ponieważ nazwa roli jest unikalna w bazie danych.
Aby usunąć rolę z bazy danych należy uruchomić procedurę systemową sp_droprole:
sp_droprole [@rolename =] 'role'
W tej składni, role jest nazwą roli stworzonej przez użytkownika, która ma zostać usunięta.
Nie można usunąć roli, jeśli są do niej przypisani użytkownicy lub inne role. Nie można
również usunąć roli jeśli posiada ona obiekty. Więcej informacji na temat własności obiektów
zostanie podanych w następnym rozdziale. Przynosi to następne interesujące pytanie: Jak
dodaje się użytkowników do ról? Należy skorzystać z systemowej procedury składowej
sp_addrolemember aby dodać użytkowników do zdefiniowanej przez użytkownika lub
ustalonej systemowo roli:
sp_addrolememeber [@rolename =] 'role', [@membername =] 'database_account'
Znaczenie składni:

role jest nazwą roli, do której ma być dodany użytkownik

database_account jest nazwą użytkownika, grupy lub roli, jaka ma zostać dodana do danej roli.
Aby usunąć użytkownika z danej roli, należy uruchomić procedurę sp_droprolemember:
sp_droprolemember [@rolename =] 'role', [@membername =] 'database_account'
Znaczenie składni:

role jest nazwą roli, z której ma być usunięty użytkownik

database_account jest nazwą użytkownika, grupy lub roli, która ma zostać usunięta z danej roli.
Warto zauważyć, że przy próbie usunięcia roli, do której są przypisani użytkownicy
Można otrzymać te same wyniki korzystając z SQL Server Enterprise Managera.
4.4. Role aplikacji
Role aplikacji są bardzo przydatną własnością SQL Servera 2000. Pomimo tego, że role
aplikacji można traktować podobnie jak inne omówione role, pełnią one inne funkcje.
Role aplikacji spełniają niektóre cele, które mają inne role; używanie ich jest dobrym
sposobem grupowania użytkowników, tak więc uprawnienia mogą zostać nadane na wyższym
poziomie. Jest to lepsze niż zarządzanie uprawnieniami dla każdego z użytkowników osobno.
Po stworzeniu i wybraniu roli, wszystkie uprawnienia przyznane użytkownikowi są
zawieszane, wymuszane są jedynie uprawnienia wynikające z roli. Oczywiście, rola wymaga
hasła do prawidłowego uruchomienia (chyba, że użytkownik nie życzy sobie hasła).
Teraz zostanie omówiona ich implementacja. Role aplikacji są dość proste w porównaniu
do ich użyteczności.
Po pierwsze, należy utworzyć rolę aplikacji poprzez systemową procedurę składową
sp_addapprole:
10
sp_addapprole [@rolename =] 'role', [@password =] 'password'
Znaczenie składni:

role jest nazwą roli, jak ma zostać utworzona

password jest to hasło, czyli autoryzacja jakiej musi podlegać aplikacja aby uaktywnić rolę.
Aby usunąć rolę aplikacji, należy uruchomić procedurę systemową sp_dropapprole:
sp_dropapprole [@rolename =] 'role'
W tym przypadku role jest nazwą roli do usunięcia.
Aby używać roli w swoich aplikacjach należy uruchomić systemową procedurę składową
sp_setapprole:
sp_setapprole [@rolename =] 'role',
[@password =] {Encrypt N 'password'}|'password'
[,[@encrypt =] 'encrypt_style']
Znaczenie składni:

role jest nazwą roli, która ma zostać uaktywniona.

password jest hasłem określanym w wywołaniu sp_addapprole.

Encrypt N 'password' żąda zaszyfrowania hasła podczas wysyłania przez sieć (jeżeli hasło zostało już
określone, jest wysłane przez sieć bez szyfrowania).

encrypt_style określa typ używanego szyfrowania. Obecnie, można wybrać z dwóch dostępnych
wartości: none lub odbc. Open database connectivity (ODBC) jest określony, kiedy używa się klientów
opartych na ODBC i oznacza że funkcja kanonicznego szyfrowania ODBC będzie używana do szyfrowania
hasła zanim zostanie ono przesłane przez sieć.
W przypadku korzystania z klienta Object Linking and Embedding Database (OLE DB), możliwość
szyfrowania jest nadal dostępna. Wystarczy określić odbc, a wystąpi ten sam typ szyfrowania.
Aby utworzyć i używać roli aplikacji, należy uruchomić następujący skrypt z poziomu SQL
Server Query Analyzera (jako narzędzia opartego na ODBC):
Use pubs
Exec sp_addapprole 'Payroll', 'password'
Go
Exec sp_setapprole 'Payroll', {Encrypt N 'password'}, 'odbc'
Po pomyślnym wykonaniu operacji pojawi się komunikat:
New application role added.
The application role 'Payroll' is now active.
Od tego momentu wszystkie uprawnienia związane z połączeniem do SQL Servera będą
używały uprawnień wynikających z roli aplikacji. Śledzenie wykonywanych operacji nadal
będzie związane z informacją o logowaniu pojedynczego użytkownika, a nie roli aplikacji.
Można nadal kontrolować działania pojedynczych użytkowników, nawet jeśli ta własność
grupy jest włączona.
5. Uprawnienia użytkownika
Większość osób korzystających z bazy danych to zwykli użytkownicy. Użytkownik bazy
danych, nie posiada przysługujących z góry praw i uprawnień (inaczej, niż użytkownicy
przydzieleni do roli public, omówionej w kolejnej sekcji). Wszystkie prawa muszą być
przyznane bezpośrednio użytkownikowi, rolom użytkownika lub roli public.
11
Uprawnienia przydzielane użytkownikom mogą być podzielone na uprawnienia obiektu i
polecenia:

Instrukcje uprawnień pozwalają użytkownikom tworzyć nowe bazy danych, tworzyć nowe obiekty w
istniejącej bazie, lub tworzyć kopie bezpieczeństwa bazy danych lub dziennika transakcji. Pozwalają one
raczej na uruchamianie poszczególnych poleceń a nie na operacje na poszczególnych obiektach.

uprawnienia obiektu pozwalają użytkownikom na wykonywanie operacji na pojedynczych obiektach.
Przykładowo, użytkownicy mogą mieć możliwość odczytu (select) danych z tabeli, wykonywania (execute)
procedury składowej lub modyfikacji danych w tabeli lub widoku (korzystając z uprawnień INSERT,
UPDATE i DELETE).
5.1. Instrukcje uprawnień
Instrukcje uprawnień pozwalają użytkownikowi bazy danych, roli bazy danych lub
grupie/użytkownikowi Windows na wykonywanie różnych zadań takich jak tworzenie baz
danych, tworzenie obiektów lub tworzenie kopii zapasowych bazy danych. Uprawnienia
wykonywania pozwalają użytkownikowi raczej na uruchamianie poszczególnych poleceń (lub
zbioru poleceń) niż na manipulowanie pojedynczym obiektem.
Należy starannie rozważyć przyznawanie użytkownikom lub rolom uprawnień do tworzenia
obiektów. Jeżeli użytkownik utworzy obiekt, staje się jego właścicielem (chyba, że twórca,
podczas tworzenia obiektu, określił właściciela jako dbo) i posiada wszystkie uprawnienia
związane z tym obiektem bazy danych. W późniejszej części zostanie pokazane, że
posiadanie obiektów, mających różnych właścicieli może stworzyć trudne sytuacje związane
z uprawnieniami.
Instrukcje uprawnień powinny być przyznawane jedynie gdy są one bezpośrednio potrzebne.
Przypadkowe przyznawanie uprawnień polecenia może powodować powstanie w bazie
danych niepotrzebnych i często bezużytecznych obiektów.
Można przyznać uprawnienia polecenia indywidualnym użytkownikom bazy danych,
użytkownikom/grupom Windows lub rolom bazy danych, włączając w to rolę public.
Można przyznawać te uprawnienia indywidualnie lub wszystkim naraz (przy użyciu słowa
kluczowego ALL). Z każdego polecenia wynikają konsekwencje, które muszą być rozważone
przed użyciem danego polecenia.
5.2. Przydzielanie uprawnień polecenia
Można używać Transact-SQL lub SQL Server Enterprise Management aby przyznawać,
odbierać i wstrzymywać uprawnienia polecenia.
Polecenie GRANT
Polecenie GRANT przyznaje użytkownikowi uprawnienia polecenia:
GRANT {ALL | statement_list} TO {account}
Składnia:

ALL oznacza wszystkie możliwe uprawnienia polecenia.

statement_list jest listą uprawnień wykonywania, jakie mają zostać przyznane dla konta.

account jest nazwą użytkownika bazy danych, roli bazy danych, grupy/użytkownika Windows.
Polecenie REVOKE
Polecenie REVOKE zabiera uprawnienia, które zostały wcześniej przyznane:
12
REVOKE {ALL | statement_list} TO {account}
Składnia:

ALL oznacza wszystkie możliwe uprawnienia polecenia.

statement_list jest listą uprawnień polecenia, jakie mają zostać odebrane.

account jest nazwą użytkownika bazy danych, roli bazy danych, grupy/użytkownika Windows.
Polecenie DENY
Inaczej niż w przypadku polecenia REVOKE, polecenie DENY bezpośrednio zabiera uprawnienie
polecenia. Przykładowo, jeżeli Joe jest członkiem roli bazy danych, a rola ta ma uprawnienie
CREATE TABLE, Joe może również tworzyć tabele. Jednak, jeżeli Joe powinien mieć zabronione
tworzenie tabel, mimo tego, że jako członek roli posiada to uprawnienie, można zabronić Joe
wykonywania tego polecenia. Dlatego, Joe nie będzie mógł uruchomić wyrażenia CREATE
TABLE, pomimo tego, że normalnie rola przydzieliła mu to prawo.
DENY {ALL | statement_list} TO {account}
Składnia:

ALL oznacza wszystkie możliwe uprawnienia polecenia.

statement_list jest listą uprawnień, jakie mają zostać wstrzymane.

account jest nazwą użytkownika bazy danych, roli bazy danych, grupy/użytkownika Windows.
Przykłady uprawnień nadawanych z poziomu Transact-SQL
Przegląd kilku przykładów jest najlepszym sposobem na zrozumienie działania omówionych
poleceń:

aby przyznać użytkownikowi Windows Joe uprawnienie do tworzenia widoku w bazie, należy uruchomić:

aby cofnąć uprawnienie do tworzenia widoków i tabel dla użytkowników Joe i Mary należy uruchomić:
GRANT CREATE VIEW TO [Rhome\Joe]
REVOKE CREATE TABLE, CREATE VIEW FROM [Rhome\Mary], [Rhome\Joe]

aby przyznać Joe wszystkie uprawnienia w bazie danych należy uruchomić:
GRANT ALL TO [Rhome\Joe]
5.3. Uprawnienia obiektu
Uprawnienia obiektu pozwalają użytkownikowi, roli lub grupie/użytkownikowi Windows na
wykonywanie działań na poszczególnych obiektach bazy danych. Uprawnienia stosują się
tylko do określonych obiektów nazwanych podczas przyznawania uprawnienia, nie do
wszystkich obiektów znajdujących się w bazie danych. Uprawnienia obiektu pozwalają
użytkownikowi na przypisanie praw do uruchamiania określonych poleceń Transact-SQL
dotyczących danego obiektu do indywidualnych kont użytkowników. Uprawnienia obiektu są
najczęściej przyznawanym typem uprawnień w bazie.
5.3.1. Przyznawanie uprawnień obiektu
Można skorzystać z Transact-SQL lub z SQL Server Enterprise Managera aby przyznać,
odwołać lub wstrzymać uprawnienia obiektu.
Przyznawanie uprawnień obiektu korzystając z Transact-SQL
Polecenie GRANT przyznaje użytkownikowi jedno lub więcej uprawnień obiektu. Usuwa ona
również uprawnienie DENY.
13
GRANT {ALL [PRIVILEGES] | permission_list [,...n]}
{
[(column[,...n])] ON {table | view}
| ON {table |view} [(column[,..n])]
| ON {stored_procedure |extended_stored_procedure}
| ON {user_defined_function}
}
TO account[,...n]
[WITH GRANT OPTION]
[AS {group | role}]
Znaczenie składni:

ALL oznacza wszystkie możliwe uprawnienia obiektu, które stosują się do obiektu danego typu.

Permission_list jest wypunktowaną listą uprawnień obiektu jakie mają zostać przyznane dla danego
konta.

column oznacza poziom, do którego mogą być przyznawane uprawnienia (jedynie do poleceń SELECT i
UPDATE).

account jest nazwą użytkownika bazy danych, roli bazy danych, użytkownika lub grupy Windows

WITH GRANT OPTION pozwala użytkownikowi, który otrzymał dane prawo na przydzielenie tego
otrzymanego prawa innym użytkownikom.

AS {group | role} określa, która grupa lub rola jest używana w przypadku danego przydzielania
uprawnień (grant). Jeżeli jest wiele ról lub grup Windows, które mogą mieć konfliktowe uprawnienia,
należy określić tę opcję.
Polecenie REVOKE — Odwoływanie uprawnień obiektu
Polecenie REVOKE zabiera jedno lub więcej uprawnień obiektu, które zostały wcześniej
przyznane. Nie zostanie wyświetlony komunikat informujący o błędzie, jeżeli zostanie
odwołany przywilej, który nie był wcześniej nadany; polecenie nie przyniesie po prostu
efektu.
REVOKE [GRANT OPTION FOR]
{ALL [PRIVILEGES] | [,...permission_list n]}
{
[(column[,...n])] ON {table | view}
| ON {table |view} [(column[,..n])]
| {stored_procedure |extended_stored_procedure}
| {user_defined_function}
}
FROM account[,...n]
[CASCADE]
[AS {group | role}]
Znaczenie składni:

ALL oznacza wszystkie możliwe uprawnienia obiektu, które stosują się do obiektu danego typu.

Permission_list jest wypunktowaną listą uprawnień obiektu jakie mają zostać odwołane dla danego
konta.

column oznacza kolumnę lub kolumny, z których mają być odwołane uprawnienia. Uprawnienia obiektu na
poziomie kolumny dotyczą jedynie poleceń SELECT i UPDATE.

account jest nazwą użytkownika bazy danych, roli bazy danych, użytkownika lub grupy Windows.

CASCADE odwołuje uprawnienia, które były przyznawane przez użytkownika, który otrzymał je wcześniej
wraz z opcją WITH GRANT OPTION.

AS {group | role} określa, która grupa lub rola jest wykorzystywana do cofnięcia przyznanych
uprawnień. W przypadku wielu ról lub grup Windows, które mogą posiadać konfliktowe uprawnienia,
należy określić tę opcję.
14
Polecenie DENY — dotyczące uprawnienia obiektu
Inaczej niż w przypadku polecenie REVOKE, polecenie DENY bezpośrednio zabiera (neguje)
uprawnienie dotyczące obiektu. Uprawnienie nie musi być wcześniej przyznane
użytkownikowi. Przykładowo, jeżeli Joe należy do roli bazy danych, która ma uprawnienie
SELECT dotyczące tabeli authors, to Joe może odczytywać dane z tej tabeli. Jednak, jeżeli
założeniem jest, że Joe nie może mieć dostępu do danych z tabeli authors, nawet jeśli należy
do roli, posiadającej tą możliwość, w tym przypadku można odebrać użytkownikowi Joe to
uprawnienie (poleceniem DENY). Dlatego, Joe nie będzie miał możliwości odczytu danych z
tabeli authors, nawet poprzez uprawnienia roli, które by na to normalnie pozwalały.
DENY
{ALL [PRIVILEGES] | [,...permission_list n]}
{
[(column[,...n])] ON {table | view}
| ON {table |view} [(column[,..n])]
| ON {stored_procedure |extended_stored_procedure}
| ON {user_defined_function}
}
TO account[,...n]
[CASCADE]
Znaczenie składni:

ALL oznacza wszystkie możliwe uprawnienia obiektu, które stosują się do obiektu danego typu.

Permission_list jest wypunktowaną listą uprawnień obiektu jakie mają zostać wstrzymane (deny) dla
danego konta.

column oznacza kolumnę lub kolumny, z których mają być odwołane uprawnienia. Uprawnienia obiektu na
poziomie kolumny dotyczą jedynie poleceń SELECT i UPDATE.

account jest nazwą użytkownika bazy danych, roli bazy danych, użytkownika lub grupy Windows.

CASCADE wstrzymuje uprawnienia, które były przyznawane przez użytkownika, który otrzymał je
wcześniej wraz z opcją WITH GRANT OPTION.
Przykłady uprawnień nadawanych z poziomu Transact-SQL
Przegląd kilku przykładów jest najlepszym sposobem na zrozumienie działania omówionych
poleceń:

aby przydzielić użytkownikowi Joe uprawnienie do pobierania danych z tabeli sales w bazie danych
pubs, należy uruchomić:
GRANT SELECT ON SALES TO [Rhome\Joe]

aby odwołać uprawnienia Joe i Mery do pobierania danych i umieszczania danych w tabeli authors,
należy uruchomić następujące polecenie:
REVOKE SELECT, INSERT ON AUTHORS FROM [Rhome\Mary], [Rhome\Joe]

aby przyznać Joe uprawnienia na poziomie kolumny do pobierania danych z kolumn au_fname i
au_lname z tabeli authors z bazy pubs należy uruchomić:
GRANT SELECT ON AUTHORS (AU_FNAME, AU_LNAME) TO [Rhome\Joe]
6.Przebieg ćwiczenia.
Uwaga: wszystkie kody wykonywane w programie Query Analizer zapisywać do plików,
gdyż ułatwi to sporządzanie sprawozdania.
6.1.Sprawdzenie użytkowników którzy mają dostęp do servera w trybie logowania SQL
Authentication Mode:
a) -po zapoznaniu z wprowadzeniem teoretycznym wykonać odpowiednie polecenie w
programie Query Analizer do odpowiedniej tabeli w odpowiedniej bazie danych w celu
15
sprawdzenia użytkowników mających dostęp do serwera w tym trybie logowania
b)- zapisać otrzymane
6.2.Tworzenie nowego użytkownika z wykorzystaniem procedury systemowejw programie
QueryAnalizer:
- utworzyć nowego użytkownika o nazwie Nazwisko_studenta z wybranym hasłem, który po
zalogowaniu będzie podłączony do bazy Northwind (sp_addlogin)
6.3.Sprawdzenie dostępu nowego użytkownika w trybie SQL Authentication Mode:
a)- w programie Enterprise Manager z menu kontekstowego dla naszego serwera SQL
(Właściwości-> Security) w lewym panelu upewnić się że włączony jest tryb „Sql Server and
Windows” w opcji Authentication
b)- wykorzystując program Query Analizer połaczyć się z SQl Serwerem wybierając opcję
SQL Server Authentication i wykorzystując nowego użytkownika Nazwisko_studenta
c)- zakończyć połączenie i ponownie połączyć się wykorzystując tryb Windows
Authentication
6.4.Tworzenie nowego użytkownika z wykorzystaniem programu
Enterprise Manager :
- utworzyć nowego użytkowników o nazwie Nazwisko_studenta1 i Nazwisko_studenta2 z
wybranym hasłem, z domyślną bazą Northwind oraz domyślnym językiem polskim
6.5.Wykorzystanie procedur systemowych do zarządzania kontami użytkowników SQL
Servera:
- wykorzystując Query Analizer utworzyć przykłady wykorzystania procedur:
sp_password
sp_defaultdb
sp_defaultlanguage
sp_helplogins
sp_droplogin
dla użytkownika Nazwisko_studenta2
6.6.Ustawianie grup i użytkowników w systemie Windows 2000:
- korzystając z zakładki Użytkownicy i grupy lokalne (Start-Ustawienia-Panel sterowaniaNarzędzia Administracyjne-Zarządzanie komputerem)
stworzyć nowe grupy użytkowników
a) SQL_Administratorzy z członkami : Administrator i SQLDebugger
b)SQL_Uzytkownicy z nowymi użytkownikami Nazwisko_Studenta1, Nazwisko_Studenta2
6.7.Przydzielanie praw dostępu do utworzonych kont:
a)- wykorzystując procedurę sp_grantlogin przydzielić prawo logowania utworzonym
grupom Windows
b)- wykorzystując procedurę s_denylogin zabronić możliwość logowania użytkownikowi
Nazwisko_Studnta2
c)- wylogować z systemu użytkownika domyślnego
d)- logując się na nowo utworzonych użytkowników sprawdzić możliwość nawiązania
połączenia z serwerem SQL (np. wykorzytując Query Analizer) w trybie Windows
Authentication
e)- ponownie przydzielić prawo logowania użytkownikowi Nazwisko_Studnta2
16
g)- ponownie załogować się na konto domyślnego użytkownika (ciwe)
6.8.Użytkownicy bazy danych:
a)- wykorzystując wiedzę z poprzedniego ćwiczenia utworzyć nową bazę danych o nazwie
„baza_Nazwisko_studenta” korzystając z konta „ciwe” (domyślnego na salach CIWE)
b)- wykorzystując procedurę sp_grantdbaccess dodać użytkowników Nazwisko_studenta1i
Nazwisko_studenta2 do nowej bazy danych nie zmieniając jego nazwy
c)- korzystając z procedury sp_helpuser sprawdzić użytkowników bazy
d)- wykorzystując sp_revokedbaccess odmówić użytkownikowi Nazwisko_studenta2 dostępu
do utworzonej bazy danych
e)- ponownie sprawdzić użytkowników bazy
g)- sprawdzić użytkowników innych baz danych
h)-połączyć się z serverem wykorzystując konto Nazwisko_studenta
i)-spróbować wykorzystać bazę „baza_Nazwisko_studenta”
j)- dodać użytkownika guest do utworzonej bazy danych
k)-ponownie spróbować wykorzystać bazę „baza_Nazwisko_studenta” będąc zalogowanym
jako użytkownik Nazwisko_studenta (np. USE „baza_Nazwisko_studenta” w Query
Analizer )
6.9.Zmiana właściciela bazy danych:
a)- wykorzystując wiedzę z poprzedniego ćwiczenia utworzyć nową bazę danych o nazwie
„baza_Nazwisko_studenta1” korzystając z konta „ciwe” (domyślnego na salach CIWE)
b)- wykorzystując procedurę sp_changedbowner zmienić właściciela nowej bazy danych
6.10.Przypisanie kont logowania do ról serwera:
a)- wykorzystując procedurę sp_addsrvrolemember przypisać użytkownika
Nazwisko_studenta do roli serwera sysadmin
b)- wykorzystując program Enterprise Manager przypisać użytkownika Nazwisko_studenta1
do roli serwera securityadmin, natomiast użytkownika Nazwisko_studenta2 do roli dbcreator
c)- opracować przykładowe operacje na serwerze lub bazie danych obrazujące uzyskane
uprawnienia z przypisaniem użytkowników do ról serwera
6.11.Przypisanie do ról bazy danych:
a)- wykorzystując procedury sp_addrolemember i sp_droprolemember przypisać wybranych
użytkowników dla wybranej bazy danych do poszczególnych ról bazy danych (np.
db_datareader, db_datawriter)
b)- (dla chętnych) – wykorzystując procedury sp_addrole, sp_addrolemember i ewentualnie
sp_droprole lub sp_droprolemember
utworzyć włąsne role bazy danych i przypisać do nich wybranych użytkowników
c)- wykorzystując program Enterprse Manager sprawdzić czy wybrani użytkownicy są
przypisani do określonych ról bazy danych
6.12. Role aplikacji:
a)- wykorzystując procedury sp_addapprole, sp_dropapprole i sp_setapprole utworzyć i
zademonstrować wykorzystanie roli aplikacji
b)- zastanowić się jaki będzie miało wpływ na uprawnienia zastosowanie roli aplikacji
6.13.Uprawnienia związane z rolami:
c)- wykorzystując procedurę sp_srvrolepermission sprawdzić i wynotować jakie uprawnienia
niesie za sobą przypisanie do poszczególnych ról serwera (opisać przynajmniej 5 ról)
17
d)-wykorzystując procedurę sp_dbfixedpermission sprawdzić i wynotować jakie uprawnienia
niesie za sobą przypisanie do poszczególnych ról
bazy danych (opisać przynajmniej 5 ról)
6.14.Uprawnienia użytkownika – instrukcje uprawnień:
a)- wykorzystując polecenia GRANT,REVOKE i DENY ustawić wybrane 3 uprawnienia
(CREATE DATABASE, CREATE TABLE, CREATE PROCEDURE, CREATE DEFAULT,
CREATE RULE, CREATE VIEW, CREATE FUNCTION, BACKUP DATABASE I
BACKUP LOG) wybranym użytkownikom lub rolom (w razie potrzeby utworzyć
dodatkowych użytkowników lub role)
b)- wykorzystując program Enterprise Manager sprawdzić czy poszczególne uprawnienia
zostały przyznane wybranym użytkownikom lub rolom oraz dodać nowe lub zmodyfikować
istniejące uprawnienia
c)-zobrazować na przykładach skutki przyznania lub zabronienia poszczególnym
użytkownikom, grupom lub rolom
6.15. Uprawnienia użytkownika –uprawnienia obiektu:
a)- wykorzystując polecenia GRANT,REVOKE i DENY ustawić wybrane uprawnienia
(SELECT, INSERT, UPDATE, DELETE, EXECUTE, REFERENCES) dla wybranych
obiektów bazy pubs lub Nortwind poszczególnym użytkownikom, grupom lub rolom
b)- wykorzystując program Enterprise Manager sprawdzić czy poszczególne uprawnienia
zostały przyznane wybranym użytkownikom, grupom lub rolom oraz dodać nowe lub
zmodyfikować istniejące uprawnienia
c)-zobrazować na przykładach skutki przyznania lub zabronienia poszczególnym
użytkownikom, grupom lub rolom
7.Treść sprawozdania.
Odnośnie do każdego punktu ćwiczenia umieścić kod Transact-SQL oraz rzuty okien
Enterprise Manager lub Query Analizer.
Do kilku wybranych punktów zademonstrować własne przykłady np..
8. Przykładowe pytania kontrolne.
1. Omówić wykorzystywane w ćwiczeniu polecenia Transact-SQL
2. Wymienić i omówić kilka przykładowych procedur systemowych wykorzystanych w
ćwiczeniu
3. Opisać wady i zalety trybów autentykacji SQL Serwera (kiedy stosować dany tryb?)
4. Omówić warstwy bezpieczeństwa SQL Serwera.
5. W czym polega różnica pomiędzy autentyfikacją (uwierzytelnianiem) oraz autoryzacją
(prawa dostępu)?
6. Opisać jakie uprawnienia niesie za sobą przypisanie do poszczególnych ról serwera
lub bazy danych.
18