Zarządzanie mechanizmami bezpieczeństwa sql servera Wprowadzenie teoretyczne



Pobieranie 165,88 Kb.
Data21.06.2018
Rozmiar165,88 Kb.

Ćwiczenie 2

Zarządzanie mechanizmami bezpieczeństwa SQL Servera





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

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.



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 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:


  • 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]


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’
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'

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 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.

  • 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:


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.

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:
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ć:

GRANT CREATE VIEW TO [Rhome\Joe]



  • aby cofnąć uprawnienie do tworzenia widoków i tabel dla użytkowników Joe i Mary należy uruchomić:

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.
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ę.

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 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 sterowania-Narzę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
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)
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.






©operacji.org 2017
wyślij wiadomość

    Strona główna