Rozdział 5.
Ustawienia zabezpieczeń logowania i użytkownika

We wcześniejszym rozdziale omówione zostało tworzenie baz danych oraz ich plików. Zostało również powiedziane jak i kiedy korzystać z grup plików SQL Servera 2000. Grupy plików są rzadko używane ale dobrze jest znać podstawy ich działania. Wszelkie działania wykonane na SQL Serverze są rejestrowane (łącznie z tworzeniem bazy danych i plików we wcześniejszym rozdziale). Zrozumienie zabezpieczeń SQL Servera 2000 jest niezbędne do prawidłowej konfiguracji działania SQL Servera. Ten rozdział przedstawi działanie uwierzytelniania połączeń do SQL Servera oraz uwierzytelnianie przez system Windows 2000. Platforma Windows 98 nie posiada żadnych mechanizmów zabezpieczających dostępnych użytkownikom Windows 2000, dlatego przedstawione jest jedynie krótkie porównanie różnic. Prawa dostępu do poszczególnych obiektów każdej z baz danych zostaną omówione w rozdziale 6.

Model bezpiecznego dostępu do SQL Servera

Połączenie z SQL Serverem było do tej pory odpowiednio łatwe. Wykorzystywany był tryb zabezpieczeń SQL Server Mixed Mode (wybrany podczas instalacji) i logowanie przy użyciu uwierzytelniania Windows, korzystając z uprawnień grupy administratorów lokalnych. Po połączeniu zachodzi kilka zdarzeń, które mogą wydawać się nie jasne.

Jeżeli SQL Server działa w systemie Windows 2000, przy próbie połączenia z SQL Serverem 2000zabezpieczenia są sprawdzane w trzech różnych miejscach (zobacz rysunek 5.1). Sprawdzenie może występować na poziomie Windows 2000, samego SQL Servera (w formie logowania do niego) a następnie na poziomie bazy danych (w formie nazwy użytkownika bazy danych).

Posiadanie nazwy przy logowaniu 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, które będą omawiane w kolejnym rozdziale.

Rysunek 5.1. Warstwy uwierzytelniania przez zabezpieczenia sieciowe i SQL Server

Uwierzytelnianie Windows

Podczas połączenia z komputera klienta do komputera z Windows NT/2000 i SQL Serverem 2000, system Windows może wymagać sprawdzenia poprawności danego połączenia sieciowego. Możne to również zależeć od biblioteki sieciowej SQL Servera. W przypadku używania biblioteki Named Pipes lub Multiprotocol dane połączenie musi być zatwierdzone jak autoryzowane połączenie Windows 2000, zanim zostanie udostępnione połączenie z SQL Serverem.

Jak pokazano na rysunku 5.2 zarówno Named Pipes jak i Multiprotocol przechodzą przez usługę Windows 2000 Server, która przeprowadza sieciowe potwierdzenie żądania połączenia użytkownika. W związku z tym należy posiadać poprawny zbiór danych uwierzytelniających w systemie Windows 2000 aby było możliwe połączenie z komputerem serwerem Windows 2000. Ponieważ protokół sieciowy Transmission Control Protocol/Internet Protocol (TCP/IP) Sockets nie przechodzi poprzez usługę Server, nie ma potrzeby posiadania prawidłowego konta Windows aby połączyć się z SQL Serverem 2000. Poczynając od SQL Servera 2000 (jak zostało wcześniej wspomniane) TCP/IP Sockets jest domyślnym protokołem sieciowym, dlatego też ta sprawa nie jest tak istotna jak w przypadku połączeń z wcześniejszymi wersjami serwera. Jednak, w przypadku klientów z oprogramowaniem po stronie klienta w wersji SQL Server 7.0 (lub wcześniejszej), domyślnie będzie zapewne używany protokół sieciowy Named Pipes.

Rysunek 5.2. Komunikacja sieciowa SQL Servera.

System Windows 98/ME nie uwierzytelnia połączeń sieciowych w ten sam sposób co system Windows NT/2000, więc sprawdzanie zabezpieczeń na poziomie logowania do SQL Servera rozpoczęło się w SQL Serverach działających na komputerach z systemem Windows 9x. Systemy te nie obsługują również Named Pipes dla aplikacji serwera, czyli nie można uzyskać połączenia z serwerem Windows 9x przy pomocy tego protokołu.

Zrozumienie architektury zabezpieczeń może być przydatne przy rozwiązywaniu problemów. Nielubiany komunikat Specified SQL Server Not Found może być wynikiem nie udzielenia użytkownikowi uprawnień do połączenia z komputerem Windows 2000 na którym jest zainstalowany SQL Server. Aby sprawdzić czy w tym tkwi problem, należy utworzyć zasób udostępniony na komputerze z SQL Serverem i spróbować połączyć się z serwerem (można też spróbować podłączyć się do istniejącego udziału, jeśli taki istnieje). Jeżeli połączenie kończy się niepowodzeniem lub system żąda podania nazwy użytkownika i hasła, oznacza to, że nie można się połączyć z SQL Serverem. Aby się upewnić, że występuje ten problem, należy zakończyć połączenie do wymienionego wcześniej zasobu a następnie znowu spróbować połączyć się z SQL Serverem.

Jeżeli połączenie doszło do skutku, należy zmodyfikować ustawienia zabezpieczeń systemu Windows 2000 na danym komputerze. Można to zrobić na jeden z trzech sposobów:

Włączyć konto gość (guest) —nie zalecane. Uaktywnienie konta guest pozwala w pewnej mierze na kompromis z zabezpieczeniami Windows 2000. Aby utrzymać bezpieczeństwo systemu, najlepiej tworzyć indywidualne konta dla każdego z użytkowników.

Utworzyć lokalne konto Windows 2000 z interfejsem Zarządzanie Komputerem, używające tego samego hasła jak bieżące konto (w ostateczności).

Dołączyć serwer do domeny, która jest członkiem domeny lub ufa domenie, w której jest utworzone dane konto użytkownika (lepsze rozwiązanie) lub umieścić serwer w tej samej grupie domen w Active Directory. Ta opcja jest najlepszą z dostępnych. Jeżeli jest możliwa do zastosowania w danej sieci, powinno się ją zastosować. Należy zwrócić się do lokalnego administratora lub zapoznać się z książka na temat Windows 2000 Active Directory aby dowiedzieć się więcej na temat domen Windows 2000, Active Directory i zabezpieczeń.

W przypadku przełączenia się do domyślnej biblioteki sieciowej TCP/IP Sockets, połączenia nie powinny stanowić problemu, jednak w przypadku, gdy jest się zmuszonym do korzystania z Named Pipes należy zastosować powyższe reguły.

Uwierzytelnianie logowania do SQL Servera

Aby połączyć się z SQL Serverem należy podać prawidłowe hasło i nazwę użytkownika (lub korzystać z prawidłowego połączenia Windows Integrated). W tej sekcji zostaną krótko omówione szczegóły tej operacji. 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 — nawet jeśli powiodło się uwierzytelnienie sieciowe Windows (sieciowe połączenie z Windows 2000 Server).

Nazwa użytkownika bazy danych SQL Servera

Aby korzystać z każdej bazy danych w systemie, użytkownik musi mieć prawo dostępu bezpośrednio do każdej z baz. Można otrzymać dostęp do bazy w różny sposób. Wszystkie sposoby zostaną omówione później. Jeżeli użytkownik nie posiada nazwy użytkownika bazy danych, podczas próby połączenia nastąpi odmowa dostępu.

Prawa dostępu

Ostatnią warstwą zabezpieczeń są prawa dostępu. Po pomyślnym zalogowaniu 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). Prawa dostępu zostaną przedstawione szczegółowo w kolejnym rozdziale.

Tryby zabezpieczeń SQL Servera (uwzględniając logowania)

SQL Server 2000 dostarcza dwóch rodzajów zabezpieczeń: Windows Integrated Mode i Mixed Mode (zarówno Windows Integrated i uwierzytelnianie SQL Servera). Tryb zabezpieczeń określa czy system Windows lub obydwa Windows i SQL Server są odpowiedzialne za kontrolę poprawności żądań połączenia z SQL Serverem. Kontrola ta jest zupełnie niezależna od uwierzytelniania połączenia sieciowego przez system Windows, omówionego wcześniej. Zrozumienie różnic jest bardzo istotne dla prawidłowej implementacji zabezpieczeń SQL Servera.

Mixed Mode

W przypadku zabezpieczenia SQL Server 2000 Mixed Mode, użytkownik może się połączyć z SQL Serverem przy pomocy Windows Integrated Mode lub 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. Aby zrozumieć obydwa tryby uwierzytelniania należy się im bliżej przyjrzeć. Łatwiej jest zrozumieć SQL Server Authentication Mode; tryb, który z powodów historycznych został zastosowany jako sposób łączności z SQL Serverem.

SQL Server Authentication Mode

SQL Server Authentication Mode jest trybem, w którym SQL Server akceptuje identyfikator logowania — ID i hasło użytkownika oraz sprawdza czy dane są poprawne, bez żadnej pomocy systemu Windows. Metoda ta jest zawsze używana na komputerach z systemem Windows 9x i jest opcjonalna na komputerach z systemem Windows 2000. 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). Wcześniejsze wersje przed SQL Serverem 7.0 używały trybu uwierzytelniania przez SQL Server zwanego Standard Security, który jest odpowiednikiem SQL Server Authentication Mode. Dlatego nie należy się zniechęcać czytając starą dokumentację, wystarczy zapamiętać nowy odpowiednik starej nomenklatury.

Jeżeli połączenie nastąpiło przy pomocy logowania, został użyty tryb SQL Server Authentication Mode. Dlatego, tabela systemowa sysxlogins zawiera wpis dla identyfikatora logowania sa, jak również hasło, jeśli zostało określone (w niniejszej książce podczas instalacji hasło zostało określone jako password). 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).

Konto sa jest dodawane domyślnie nawet jeśli zostanie wybrana domyślna instalacja w trybie Windows Integrated Mode.

Hasła 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)

Wiersze w powyższym zbiorze wyników, zawierające grupę BUILDIN\Administrators a także konto usługi SQL Servera (SQLService), nie występują w instalacjach SQL Servera w systemie Windows 9x, jak zostało już wcześniej wspomniane.

Pierwszy wiersz w wydruku wyjściowym prezentuje grupę lokalnych administratorów systemu Windows; zabezpieczenia Windows Integrated zostaną omówione w tej sekcji. 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 — hasło password (w przypadku tej książki) jest zaszyfrowane. 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). W kontekście zabezpieczeń logowania, dla celów porównawczych lepiej jest traktować null jako pusty tekst.

Hasła widoczne w wynikach zapytania mogą się wydać w pierwszym momencie mało przekonujące. Należy jednak rozważyć kilka faktów:

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 (w rozdziale 6 zostanie powiedziane jak przydzielić to prawo).

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 Integrated, żadne hasła nie są przechowywane na SQL Serverze.

Jeżeli rozważasz zabezpieczenia, szczególnie z wykorzystaniem haseł, najlepszym rozwiązaniem jest użycie Windows Authentication.

Administracja logowaniem w trybie SQL Server Authentication Mode Pierwszym krokiem w ustawieniach dostępu do serwera jest utworzenie kont logowania. Można dodać konta przy pomocy systemowej procedury składowej sp_addlogin lub SQL Server Enterprise Managera. Warto zauważyć, że w przypadku korzystania z Windows 2000, tryb Windows Integrated Mode jest preferowaną metodą administracyjną zabezpieczeń i zostanie omówiony w dalszej części tego rozdziału.

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'

Autor książki użył polecenia: exec sp_addlogin 'richard', 'password'. Zaleca się skorzystanie z tej samej nazwy i hasła w celu zachowania zgodności z kolejnymi przykładami w tej książce. W innym przypadku, gdy w książce pojawi się nazwa richard należy ją zastąpić własną nazwą przy logowaniu. Również, ponieważ domyślna instancja nie jest w trybie Mixed, należy uruchomić te polecenia w kopii nazwanej (TRADE).

Można ponownie uruchomić poprzednie zapytanie dotyczące tabeli sysxlogins, aby zobaczyć nowy wiersz z wpisaną nazwą i zaszyfrowanym hasłem. W przypadku tworzenia nowego połączenia z SQL Serverem można posłużyć się nowododaną nazwą i hasłem podczas logowania.

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 (do których wróci się później) 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.

Zalecana jest regularna zmiana haseł. Niestety, SQL Server 2000 nie posiada mechanizmu wymuszającego ograniczenia nakładane na hasło i innych tego typu zabezpieczeń. Jest to jedna z przyczyn dla której warto zaimplementować zabezpieczenia zintegrowane. System Windows 2000 może określić minimalną wymaganą długość hasła, częstotliwość obowiązkowej zmiany hasła i minimalne wymagania co do złożoności hasła.

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. Rysunek 5.3 przedstawia przykładowe uruchomienie procedury składowej.

Warto zauważyć, że na rysunku 5.3 pojawia się znowu kolumna SID; która była wcześniej związana z procedurą sp_addlogin. SID (security identifier) jest sposobem w jaki SQL Server śledzi logowania i użytkowników działających na SQL Serverze. W przypadku uwierzytelniania logowań przez SQL Server , jest to 16-bajtowa wartość binarna generowana przez SQL Server. W przypadku użytkowników zabezpieczeń Windows Integrated, jest to unikalny, globalny numer identyfikujący użytkownika w sieci Windows.

Rysunek 5.3. Wyniki działania procedury sp_helplogins.

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.

W tej sekcji zostało omówione zarządzanie logowaniem w trybie SQL Server Authentication Mode korzystając z różnych systemowych procedur składowych. W kolejnych sekcjach zostanie omówione zarządzanie zabezpieczeniami przy pomocy SQL Server Enterprise Managera.

Tryb Windows Authentication Mode w zabezpieczeniach Mixed Security

Windows Authentication Mode jest drugą opcją w zabezpieczeniach Mixed Mode, która zostanie omówiona później, ponieważ tryby te są identyczne w zakresie administracji i funkcjonalności. Przed omówieniem połączeń Windows niezbędna jest wzmianka dotycząca terminologii. Połączenia korzystające z uwierzytelniania Windows zwane są połączeniami zaufanymi. Dlatego, gdy będzie mowa o połączeniach zaufanych, oznacza to połączenia uwierzytelniane przez system Windows, które są kontrolowane przez Windows NT lub Windows 2000.

Windows Authentication Mode

W zabezpieczeniach Windows Authentication Mode, po połączeniu z SQL Serverem poprzez sieć należy przedstawić SQL Serverowi dane zabezpieczeń Windows (zwane znacznikiem dostępu). Referencje te są tworzone w procesie logowania do sieci Windows 2000. Referencje zabezpieczające są podawane i weryfikowane bez udziału użytkownika. Można przyznać dostęp do SQL Servera bezpośrednio przez konta Windows 2000 lub pośrednio poprzez grupy Windows 2000.

Zaletą Windows Authentication Mode jest to, że użytkownicy nie muszą się martwić o odrębne logowanie do SQL Servera. Możliwość ta jest zgodna z koncepcją, że użytkownicy muszą logować się do sieci tylko raz i pamiętać tylko jedno hasło. Nie jest to jedyna zaleta, kolejną jest mniejsza potrzeba zarządzania kontami SQL Servera w przypadku, gdy większość użytkowników posiada konta w systemie Windows.

Ustawienia grup i użytkowników w systemie Windows 2000

Pierwszy krok do konfiguracji zabezpieczenia Windows Authentication Mode nie jest związany bezpośrednio z SQL Server ale z narzędziem Zarządzanie komputerem (lub Menedżerem użytkowników w systemie Windows NT). Po pierwsze, należy stworzyć grupy dla użytkowników w systemie Windows 2000, utworzyć użytkowników (jeśli nie zostali wcześniej stworzeni) i dodać ich do nowoutworzonych grup a następnie przypisać im prawa do logowania do SQL Servera. W tym celu należy kliknąć przycisk Start, Programy, Narzędzia administracyjne, Zarządzanie komputerem (w przypadku zarządzania domeną należy skorzystać z konsoli Użytkownicy i komputery Active Directory). Należy rozwinąć opcję Użytkownicy i grupy lokalne, jak pokazano na rysunku 5.4.

Rysunek 5.4. Zarządzanie komputerem: Użytkownicy i grupy lokalne.

Oczywiście, narzędzie Zarządzanie komputerem nie występuje w systemie Windows 9x. Również, w komputerach z systemem Windows NT aplikacja ta nazywa się Menedżer użytkowników lub Menedżer użytkowników domen.

Należy dodać nową grupę lokalną do bazy danych menedżera kont systemu Windows (SAM security account manager) na komputerze, na którym działa SQL Server. Jest to wewnętrzna baza danych systemu Windows 2000, a nie baza danych SQL Servera. W przypadku, gdy potrzebna jest kontrola zdalnego komputera, należy kliknąć prawym klawiszem myszy Zarządzanie komputerem (Lokalne) wybrać Połącz do innego komputera a następnie wpisać nazwę komputera, którym zamierza się administrować. W przypadku administracji domeną Active Directory, należy użyć zestawu narzędzi Active Directory, jak zostało wcześniej wspomniane.

Jak w większości operacji wykonywanych w tej książce, należy zalogować się do komputera jako członek grupy administratorów lokalnych. W przeciwnym przypadku nie będzie możliwe wykonywanie kolejnych przedstawionych tutaj operacji.

Należy utworzyć trzy nowe grupy lokalne do pracy z SQL Serverem: jedna grupa zawierająca użytkowników, którzy mogą się zalogować jako administratorzy SQL Servera (użytkownicy Windows 2000, którzy mogą w pełni administrować SQL Serverem), druga grupa dla osób z departamentu Sales, a trzecia dla użytkowników zwanych Marketingiem. Następnie można przypisać użytkowników do poszczególnych grup. Po przeanalizowaniu dalszej części tej lekcji i rozdziału 6 będzie jasne jakie operacje użytkownicy mogą wykonywać po zalogowaniu się.

Pierwsza grupa jest tworzona dla dostępu administracyjnego do SQL Servera. Należy podświetlić folder Grupy, kliknąć prawym klawiszem myszy i wybrać polecenie Nowa grupa. Uzupełnić pola Nazwa grupy i Opis, jak pokazano na rysunku 5.5

Rysunek 5.5. Dodawanie nowej grupy lokalnej do zabezpieczeń systemu Windows 2000

Następnie należy dodać konto do grupy, jak pokazano na rysunku 5.6. Należy kliknąć przycisk Dodaj, aby zobaczyć listę kont, które zostały dodane. Lista zawiera globalne grupy i konta z domyślnej domeny, lub tylko konta, jeśli komputer z SQL Serverem nie należy do żadnej domeny.

Rysunek 5.6. Okno Wybieranie: Użytkownicy lub Grupy.

Jeżeli w polu Szukaj w: nie widać nazwy danego komputera, należy ją wybrać z listy rozwijanej. Lista ta zawiera nazwę danego komputera, domyślną domenę i wszelkie zaufane domeny. W przypadku korzystania z domeny, zalecane jest dodanie do listy konta domeny, zamiast tworzenia i dodawania identycznego konta lokalnego Windows 2000. Następnie z odpowiedniej listy należy wybrać własną nazwę użytkownika i dodać do grupy, poprzez podświetlenie nazwy, kliknięcie Dodaj a następnie OK.

Należy również dodać konto używane przez usługę SQL Server Agent podczas instalacji (zgodnie z instalacją przedstawioną w rozdziale 2, jest to konto SQLService). Do prawidłowego funkcjonowania usługa SQL Server Agent wymaga utworzenia zaufanego połączenia do SQL Servera. Jeżeli to konto nie zostanie dodane, usługa SQL Server Agent nie będzie miała możliwości utworzenia zaufanego połączenia z SQL Serverem, funkcje dostarczane przez tę usługę zawiodą, łącznie z zadaniami (jobs), alertami i replikacją.

Kompletna grupa została pokazana na rysunku 5.7.

Rysunek 5.7. Uzupełnione okno Nowa Grupa.

Należy kliknąć Utwórz a następnie powtórzyć operację tworząc grupę zwaną Sales, a następnie grupę Marketing. Za każdym razem należy dodać użytkowników do grup. W przykładowym systemie, do tego celu, zostali stworzeni trzej dodatkowi użytkownicy — Ann, Bob i Cat. Użytkownik Ann i Bob zostali dodani do grupy Sales, a Bob i Cat do grupy Marketing. Bob został celowo dodany do dwóch grup. W systemie Windows 2000 aby dodać użytkownika do grupy należy podświetlić wybraną grupę, kliknąć prawym klawiszem myszy, wybrać Dodaj do grupy, a następnie kliknąć Dodaj, jak poprzednio i wybrać użytkowników, którzy mają zostać dodani do grupy. Jeżeli użytkownicy są tworzeni na bieżąco, należy wyczyścić pole wyboru Użytkownik musi zmienić hasło przy kolejnym zalogowaniu. Przykładowi użytkownicy mają wszyscy jednakowe hasło: password.

Aby wykonać operację dodawania użytkowników szybciej, można uruchomić skrypt dodający użytkowników, grupy i przydzielający użytkowników do grup. Na płycie CD dołączonej do tej książki należy kliknąć dwukrotnie plik PATH\CH05\Ad Groups\Users.CMD. Skrypt ten dodaje użytkowników lokalnych Ann, Bob i Cat, tworzy grupę Sales, Marketing i SQL_Administrators i przydziela użytkowników do odpowiednich grup. Nie przydziela jednak konta administracyjnego, (z którego korzysta aktualnie zalogowany użytkownik) do grupy SQL_Administrators.

Przydzielanie prawd dostępu do SQL Servera dla kont Windows 2000

Po ustawieniu grup i użytkowników, należy przydzielić grupom odpowiednie prawa dostępu do SQL Servera. Można tego dokonać przy pomocy systemowych procedur składowych sp_grantlogin, sp_revokelogin i sp_denylogin. Procedury te działają bardzo podobnie jak procedury sp_addlogin i sp_droplogin, omówione wcześniej, w sekcji na temat SQL Server Authenitcation Mode. Najpierw należy przydzielić prawo logowania dla grup Windows a następnie w razie potrzeby przydzielić to prawo indywidualnym użytkownikom. Metoda ta pozwala na uruchomienie mniejszej ilości poleceń i ma najmniejsze koszty administracyjne, jednocześnie pozwalając nadal na indywidualną kontrolę praw logowania. Aby przyznać prawo do logowania, należy użyć procedury składowej sp_grantlogin:

sp_grantlogin [@loginname =] 'login'

W powyższej składni login jest nazwą grupy Windows 2000 lub użytkownika, któremu jest przyznawane prawo do logowania do SQL Servera. Nazwa login powinna mieć postać: SECURUTY_DATABASE\Username, przykładowo: MYDOMAIN\Richard.

Przykładowo, aby przyznać prawo logowania do SQL Servera grupie Sales należy wpisać polecenie:

EXEC sp_grantlogin 'RHMOE\Sales'

zastępując RHOME nazwą własnego komputera (lub nazwą domeny w przypadku uruchomienia SQL Servera na kontrolerze domeny). Na ekranie powinien się pojawić komunikat:

Granted login access to 'RHOME\Sales'.

Po tej operacji, każdy z użytkowników Windows 2000 należący do grupy Sales może zalogować się do SQL Servera. Można sprawdzić tę możliwość poprzez zalogowanie się do systemu Windows 2000 jako Ann lub Bob, uruchomienie SQL Server Query Analyzera i wybranie opcji Windows NT Authentication, aby wymusić zaufane połączenie z SQL Serverem. W pasku tytułowym zapytania pojawi się nazwa użytkownika Windows 2000. Warto zauważyć, że nadal istnieje połączenie z Windows 2000 na własne konto logowania, nawet jeśli grupa Sales jest tym elementem, który otrzymał uprawnienia do logowania do SQL Servera. Połączenie tym sposobem gwarantuje możliwość śledzenia (auditing) i pozwala na lepszą kontrolę przyznanych praw w przyszłości.

Jeżeli nie ma możliwości zalogowania się jako Ann lub Bob i pojawia się komunikat The local policy of this system does not permit you to logon interactively, nie należy się niepokoić. Należy zalogować się do komputera na konto administratora, wybrać Start, Uruchom i wpisać GPEdit.msc. Rozwinąć Ustawienia systemu Windows, Ustawenia zabezpieczeń, Zasady lokalne i folder Przyznawanie praw użytkownika, wybrać opcję Logowanie lokalne. Kliknąć prawym klawiszem, wybrać Zabezpieczenia i kliknąć przycisk Dodaj, aby dodać grupę Sales do listy. Pojawi się okno podobne do pokazanego na rysunku 5.8. Należy kliknąć OK. i wszyscy użytkownicy będą mogli logować się lokalnie do danego komputera.

Rysunek 5.8. Okno dialogowe Ustawienia zasad lokalnych.

Można również cofnąć prawa do logowania do SQL Servera przyznane użytkownikom lub grupom Windows 2000. Należy skorzystać z procedury sp_revokelogin:

sp_revokelogin [@loginame =] 'login'

W tej procedurze, login oznacza nazwę grupy lub użytkownika Windows 2000, dla którego ma być odwołane prawo logowania do SQL Servera.

sp_revokelogin usuwa przyznane wcześniej prawo logowania. Następujące polecenie usuwa możliwość zalogowania się do SQL Servera dla wszystkich użytkowników grupy Sales (grupa ta otrzymała wcześniej to prawo):

Exec sp_revokelogin 'RWHOMENT\Sales'

Jednak, następująca procedura nie odniesie rezultatów, ponieważ grupa Marketing nie miała wcześniej przyznanego prawa do logowania do SQL Servera:

Exec sp_revokelogin 'RWHOMENT\Marketing'

Również, warto zauważyć, że odwołanie prawa do logowania dla użytkownika Ann, nie powoduje cofnięcia praw, jakie Ann otrzymuje przynależąc do danej grupy:

Exec sp_revokelogin 'RWHOMENT\Ann'

Dlatego, jeżeli grupa Sales posiada prawo logowania i zostanie uruchomione powyższe polecenie, nie zmieni ono prawa Ann (wynikającego z praw grupy) do logowania do SQL Servera.

Jeżeli zachodzi potrzeba, można określić, że prawo logowania do SQL Servera w grupie Sales posiadają wszyscy z wyjątkiem Ann. Należy skorzystać z systemowej procedury składowej sp_denylogin:

sp_denylogin [@loginame =] 'login'

W tej procedurze, login oznacza nazwę grupy lub użytkownika Windows 2000, dla którego nie zezwala się na logowanie do SQL Servera.

Przykładowo można użyć kodu (zastępując jak poprzednio nazwę bazy danych RHOME własną nazwą):

Exec sp_grantlogin 'RHOME\Sales'

Exec sp_denylogin 'RHOME\Ann'

Teraz dla sprawdzenia można się zalogować do systemu Windows 2000 jako Ann, i spróbować połączyć się do SQL Servera. Nastąpi odmowa zalogowania. Należy zalogować się do Windows 2000 jako Bob i połączyć się z SQL Serverem, logowanie powinno zakończyć się sukcesem. Użytkownik Ann nie ma uprawnień do logowania, natomiast Bob, jako członek grupy Sales posiada to prawo. Prawa odmowy zwykle zastępują inne przyznane prawa.

SQL Server 2000 używa Security support Provider Interface (SSPI) do połączenia z Windows 2000. Może się zdarzyć, że wystąpi błąd odnoszący się do SSPI. Komunikat ten oznacza, że wystąpił błąd, podczas gdy SQL Server próbował wywołać Windows 2000; na ogół, oznacza to, że nie można zlokalizować kontrolera domeny.

Ustawienia Security Mode

Do tej pory, omówione zostało dodawanie użytkowników w trybie SQL Server Authetication Mode i użytkowników i grup Windows 2000 do SQL Servera. Jednak, należy wiedzieć, jaki tryb zabezpieczeń zastosować. Aby ustalić jaki tryb zabezpieczeń jest obecnie używany przez serwer, należy uruchomić SQL Server Enterprise Managera, kliknąć prawym przyciskiem myszy odpowiedni serwer w lewym panelu. Wybrać Właściwości z menu kliknąć zakładkę Zabezpieczenia.

W przypadku komputera z systemem Windows 2000, ukaże się okno pokazane na rysunku 5.9 i będzie możliwy wybór opcji: Windows only (domyślnie) lub SQL Server and Windows. W przypadku komputera z systemem Windows 9x, większość pozycji w tym oknie jest niedostępnych (szary kolor czcionki), ponieważ systemy te obsługują uwierzytelniania Windows. Aby zmienić ustawienia zabezpieczeń, wystarczy kliknąć wybraną opcję. Zmiany przyniosą efekt po ponownym uruchomieniu usługi SQL Server (w przypadku kopii domyślnej — MSSQL Server, w przypadku kopii nazwanej — MSSQL$nazwa_kopii).

Rysunek 5.9. Okno dialogowe konfiguracji zabezpieczeń.

W razie potrzeby można włączyć śledzenie (auditing) dla danego serwera. Domyślnie śledzenie nie jest włączone. Można śledzić Failure (nieudane próby logowania do SQL Servera), Success (udane logowania do SQL Servera) lub obydwa (opcja All). Autor książki zaleca wybór śledzenia obydwóch (udanych i nieudanych) prób logowania, jak pokazano na rysunku 5.9. Można przeglądnąć wyniki śledzenia w dzienniku błędów SQL Servera lub w aplikacji Podgląd zdarzeń Windows NT. Aby rozpocząć śledzenie należy zatrzymać usługę SQL Server i uruchomić ją ponownie. Warto zauważyć, że SQL Server 2000 stosuje znacznie szerszy zakres śledzenia, który zostanie omówiony w rozdziale. Rozdział ten omawia szczegółowo narzędzie SQL Server Profiler.

Blok Startup service account pozwala na zmianę konta, używanego przez SQL Server do uruchomienia usługi SQL Server. Opcja ta została omówiona w rozdziale 2.

Po dokonaniu zmian w tym oknie, należy zatrzymać i uruchomić ponownie SQL Server, aby zmiany odniosły skutek. Ponieważ prawdopodobnie zmiany tego typu nie będą wykonywane więcej niż raz, zatrzymanie i ponowne uruchomienie SQL Servera nie powinno stanowić problemu.

Konta logowania — zarządzanie graficzne

Teraz należy sprawdzić w praktyce wiadomości przedstawione dotychczas w tym rozdziale. SQL Server posiada dwa rodzaje logowania:

logowanie przez Windows NT/2000, przez identyfikatory (ID) grup lub indywidualnych użytkowników.

logowanie przez konta SQL Servera, przechowywane w tabeli systemowej sysxlogins w bazie danych master.

Każdy ze sposobów ma swoje zalety. Konta logowania SQL Servera mogą być używane na platformie Windows 9x i nie wymagają posiadania zorganizowanych domen Windows 2000 w systemach Windows 2000. Logowanie poprzez konta Windows 2000 jest preferowane, w prawidłowo skonfigurowanej sieci Windows, ponieważ konta te zostały już wcześniej stworzone i identyfikują każdego użytkownika w danej organizacji. W niniejszej książce zostały omówione obydwa sposoby logowania — tworzenie kont oraz pozwolenie na logowanie do SQL Servera. Można to wykonać poprzez procedury systemowe sp_addlogin i sp_password. Jednak, łatwiejsze jest skorzystanie z SQL Server Enterprise Managera.

Przy pomocy Enterprise Managera można łatwo utworzyć obydwa typy kont logowania z pojedynczego interfejsu graficznego. Należy jednak rozumieć z czym wiąże się korzystanie z tych typów logowania przed przystąpieniem do omawiania tego interfejsu.

Rysunek 5.10 pokazuje, jak wygląda system po uruchomieniu procedur z wcześniejszej części tego rozdziału. Dla grupy Windows 2000 Sales zostały przyznane prawa logowania do SQL Servera i została przydzielona odmowa logowania użytkownikowi Windows 2000 — Ann. Grupa BUILTIN\Administrators jest dodawana podczas instalacji systemu, również podczas instalacji tworzone jest konto sa. Konto Richard zostało dodane jako standardowe logowanie (SQL Servera).

Rysunek 5.10. Informacje na temat kont w SQL Server Enterprise Manager

Aby dodać grupę Marketing jako prawidłową nazwę konta, należy kliknąć prawym klawiszem myszy w dowolnym miejscu prawego panelu okna Enterprise Managera i wybrać opcję New login. Ukaże się okno pokazane na rysunku 5.11. Należy uzupełnić w tym oknie informacje (patrz rysunek 5.11) potrzebne aby dodać grupę Marketing.

Rysunek 5.11. Dodawanie konta Windows 2000 korzystając z SQL Server Enterprise Managera

Należy kliknąć OK. aby zakończyć dodawanie konta, a następnie wykonać tą samą operację aby dodać konto Bob (tak naprawdę nie ma potrzeby dodawania konta Bob, ponieważ Bob może się zalogować z grupy Sales lub z grupy Marketing). Należy dodać konto SQL Servera o nazwie Don, z hasłem: password. Na rysunku 5.12 pokazano okno konfiguracyjne. Po kliknięciu OK należy potwierdzić wpisane hasło.

Rysunek 5.12. Dodawanie konta SQL Servera korzystając z Enterprise Managera

Aby zabronić dostępu z danego konta wystarczy wybrać Deny Access. Wybór tej opcji ma sens jedynie w przypadku kont Windows 2000. Aby zabronić dostępu z konta SQL Servera po prostu nie należy tworzyć takiego konta.

Aby edytować istniejące konto, należy kliknąć prawym przyciskiem myszy konto w prawym panelu, z podświetlonym folderem Logins i wybrać Właściwości z menu. Warto zauważyć, że są jeszcze dwie dodatkowe zakładki Server Roles i Database Access. Zostaną omówione w kolejnych sekcjach.

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.

Można znaleźć również kilka innych procedur systemowych, które wykonują podobne zadania. Są to m.in. sp_adduser, sp_dropuser, sp_addgroup i sp_changegroup. Te starsze systemowe procedury składowe są używane w wersjach wcześniejszych, przed wersją SQL Server 7.0. Pomimo tego, że procedury te nadal działają jako kontrola logowania SQL Server Authentication do mapowania nazwy użytkownika, nie działają one prawidłowo jako kontrola nazw użytkowników i grup Windows NT/2000 Authentication. Dlatego nie należy ich używać, chyba, że serwer został uaktualniony z wersji SQL Server 6.5, gdzie były używane. Jednak, dobrze jest, nawet w przypadku takiej instancji, zmienić procedury składowe na nową ich wersję.

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_revoke

dbaccess:

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. Role zostaną omówione w dalszej części tego rozdziału.

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.

W wersji SQL Server 7.0, domyślnie w każdej bazie danych istnieje użytkownik zwany INFORMATION_SCHEMA. Użytkownik ten jest właścicielem kilku widoków używanych do dostarczania informacji o systemie podlegającej specyfikacji American National Standards Institute (ANSI). W wersji SQL Server 2000 widoki, których właścicielem jest INFORMATION_SCHEMA istnieją jedynie w bazie master, pomimo tego, w przypadku uruchomienia zapytania, widoki te pokazują informacje o bazie danych w której obecnie znajduje się użytkownik.

Teraz należy utworzyć użytkownika w bazie danych pubs. Zgodnie z tym co było powiedziane poprzednio, powinien istnieć użytkownik Don na SQL Serverze. Użytkownik ten został stworzony jako nazwa logowania do SQL Servera we wcześniejszej części tego rozdziału. Należy uruchomić z SQL Server Query Analyzera następujące polecenie T-SQL:

Use pubs

EXEC sp_grantdbaccess Don

Ten przykład dodaje nowego użytkownika Don do bazy danych pubs, mapowanego do nazwy logowania ID — Don w tabeli sysxlogins w bazie danych master. Można to sprawdzić poprzez uruchomienie procedury sp_helpuser w bazie danych pubs. (zobacz rysunek 5.13).

Rysunek 5.13. Wyniki działania procedury sp_helpuser.

Można zobaczyć, że Don został dodany do użytkowników bazy danych, z nazwą logowania Don. Widać, dlaczego używanie tutaj różnych nazw mogłoby być mylące. Warto zauważyć, że w tym miejscu zapisane są również prawa przyznane użytkownikom i grupom Windows 2000, łącznie z dbo i guest.

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. Na rysunku 5.13 można zobaczyć konto guest jako rezultat działania procedury systemowej sp_helpuser. Można również zauważyć, że nie jest ono mapowane jako konto logowania; jest mapowane na puste konto NULL. Jest to specjalny użytkownik nie podlegający zwykłym regułom. Jeżeli w bazie danych jest konto dostępowe guest, każdy zalogowany do systemu użytkownik, który zażąda dostępu do bazy danych i nie posiada nazwy, stworzonej specjalnie w bazie danych (jako grupa lub indywidualny użytkownik) otrzyma zezwolenie na dostęp. Dlatego, podczas instalacji, konto guest zostało wbudowane do każdej domyślnej bazy danych na serwerze.

Nie można usunąć nazwy użytkownika guest z bazy danych master ani tempdb. Jeżeli zostałoby to zrobione, użytkownik posiadający konto logowania, ale nie mający określonego dostępu do bazy danych nie mógłby się dostać do żadnej z baz danych.

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'

SQL Server 2000 zawiera domyślnie konto guest w każdej z baz danych (z wyjątkiem bazy model), dlatego nie ma potrzeby dodawania w tym przypadku bezpośrednio konta guest. Jednak, po usunięciu go, należy go wprowadzić ponownie. Jeżeli baza model zawiera konto guest, każda nowoutworzona baza danych będzie również zawierała konto guest.

Jak do tej pory, zostały omówione dwa sposoby dostępu do bazy danych: poprzez mapowanie użytkownika z konta logowania lub poprzez użycie konta guest. Użytkownik można również posiadać przywileje dbo, co oznacza, że tworzył on tę bazę danych. Może się również zdarzyć, że z powodów historycznych występuje alias do innego użytkownika.

Następna sekcja, dotycząca aliasów, jest wprowadzona jedynie dla zachowania zgodności wstecz z wcześniejszymi wersjami. Nie powinno się używać aliasów w SQL Server 2000. Jak zostanie omówione później role dostarczają znacznie bardziej przejrzystego rozwiązania.

Dodawanie aliasu

Można dodać alias użytkownika bazy danych (database username alias) przy pomocy systemowej procedury składowej sp_addalias. Alias zezwala, aby użytkownik podawał się za innego użytkownika bazy zamiast mapować jego konto na jego własną nazwę lub nazwę grupy.

sp_addalias login_name, username

W powyższej składni:

login_name jest nazwą konta użytkownika do zmapowania.

username jest nazwą użytkownika, za którego będzie się podawał dany użytkownik.

Nadawanie aliasów zostało stworzone aby pomóc w zabezpieczeniach streamline w bazie danych. Można nadawać nieograniczoną ilość aliasów pojedynczemu użytkownikowi w bazie danych. Jeżeli konto logowania ma już zmapowaną nazwę w bazie danych, nazwa tego konta nie może być równocześnie aliasem użytkownika. W tym przypadku, role dostarczają również znacznie prostszego i lepszego modelu zabezpieczeń.

Ta opcja dostępu do bazy danych jest na ogół używana do mapowania kont jako nazwę użytkownika dbo w bazie danych. Jednak, może istnieć tylko jeden prawdziwy właściciel bazy w danym czasie. Ponieważ większość firm ma więcej niż jednego administratora, może istnieć zapotrzebowanie na to, aby więcej użytkowników występowało jako właściciel bazy danych. Role potrafią rozwiązać ten problem.

Jeżeli alias nie jest potrzebny i należy go usunąć, można to uczynić przy pomocy procedury systemowej sp_dropalias:

sp_dropalias login_name

W tym przypadku, login_name oznacza nazwę logowania użytkownika.

Aliasy powinny istnieć jedynie w bazie danych uaktualnionej z SQL Server 6.5 do SQL Server 2000 i powinny być usunięte jak tylko jest to możliwe, ponieważ nie są obsługiwane przez kolejne wersje Microsoft SQL Servera.

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.

Zostały omówione cztery odrębne sposoby dostępu do bazy danych po udanym zalogowaniu do SQL Servera. Zostały wymienione w następującej kolejności:

sa — nazwa sa (lub jakakolwiek inny użytkownik posiadający rolę serwera sysadmin) może zawsze uzyskać dostęp do bazy danych i zawsze pojawiać się jako dbo, nawet gdy własność tej bazy danych została przypisana do innego konta logowania przy pomocy sp_changedbowner.

nazwa użytkownika bazy danych — używanie nazwy użytkownika mapowanej do identyfikatora logowania ID SQL Servera (również jako nazwa użytkownika lub grupy Windows 2000) jest to „normalny” sposób dostępu do bazy danych. Stosuje się to również do grup Windows 2000, do których zostały przydzielone prawa dostępu.

alias — można stosować alias do prawidłowego użytkownika bazy danych. Wówczas w bazie danych, użytkownik może korzystać z przywilejów i praw innego użytkownika.

Guest — jeżeli poprzednie sposoby zawiodą, SQL Server sprawdza, czy istnieje konto guest w tabeli systemowej sysusers w bazie danych. Jeżeli istnieje, dostęp jest udzielany jako guest. W przeciwnym wypadku następuje odmowa dostępu.

Można zauważyć, że konta użytkowników Windows NT/2000 nie są mapowane z powrotem do kont logowania. Jeżeli użytkownik Windows otrzyma konto logowania i dostęp do bazy danych przez członkostwo w grupie Windows 2000, dalsze mapowania przy użyciu indywidualnych kont logowania będą nadmiarowe. Na ogół taka sytuacja nie zostaje stworzona przez użytkownika, może się zdarzyć, że stworzy ją sam SQL Server. Przykładowo, do bazy danych zostaje dodana grupa Windows 2000, a następnie użytkownik tworzy tabelę. Aby prześledzić, kto stworzył tabelę, SQL Server tworzy nowego użytkownika dla użytkownika Windows 2000; ale użytkownik utworzony przez SQL Server jest wykorzystywany jedynie do celów śledzenia i nie ma naprawdę przydzielonego dostępu do bazy danych.

Role

Role zostaną omówione dopiero teraz ponieważ łączą w jedno wszystkie zagadnienia związane z SQL Serverem 2000. Można myśleć o rolach jako o grupach SQL Servera. Pojęcie grupa nie jest używane, aby nie powodowało mylnej interpretacji tych opcji w SQL Serverze jako grup Windows NT/2000.

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.

Rola Public

W każdej bazie danych, SQL Server 2000 zawiera jedną rolę wbudowaną zwaną public. Wszyscy użytkownicy, grupy i role przynależą do roli public, która nie może zostać usunięta. Rolę public można traktować podobnie jak grupę Wszyscy w Windows 2000 (ściśle mówiąc — podobnie jak grupę Authentication users, ponieważ użytkownik jest najpierw kontrolowany przez SQL Server). Odwołanie się do wszystkich użytkowników bez podawania bezpośrednio ich nazw jest znaczącym skrótem. Podejście to zostanie omówione w dyskusji na temat praw w rozdziale 6. Na rysunku 5.13 można zobaczyć nazwę roli public wyświetloną dla większości użytkowników.

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.

Dostępne role serwera

Następująca lista opisuje cały zbiór dostępnych ról serwera. Opis pozwoli zrozumieć, kiedy należy używać tych ról:

sysadmin — członkowie tej roli mogą wykonać wszelkie operacje na SQL Serverze. Można powiedzieć, że mają uprawnienia dbo do każdej z baz danych (nawet jeśli nie mają). Ściśle mówiąc są ponad uprawnieniami i systemami zabezpieczeń.

serveradmin — członkowie tej roli mogą ustawiać opcje konfiguracyjne przy pomocy procedury systemowej sp_configure i mogą wyłączać serwer. Mogą również konfigurować usługę Full-Text. Do tej roli powinni być przypisani operatorzy serwera.

Członkowie roli serveradmin mogą uruchamiać jedynie polecenie Transact-SQL SHUTDOWN aby wyłączyć serwer. Ich prawa do kontroli usług są prawami Windows 2000, a nie prawami SQL Servera.

setupadmin — członkowie tej roli mogą instalować i konfigurować przyłączone serwery i zaznaczać procedury, które mają być uruchamiane podczas uruchamiania systemu.

securityadmin — członkowie tej roli mogą tworzyć i kontrolować konta logowania serwera jak również mają prawa do tworzenia baz danych. Mogą konfigurować ustawienia zabezpieczeń serwera przyłączonego. Mogą również zmieniać hasła SQL Server Logins (z wyjątkiem haseł członków roli sysadmin). Również w tym przypadku, operatorzy są dobrymi kandydatami do tej roli, również pracownicy helpdesk mogą przynależeć do tej roli.

processadmin — członkowie tej roli mogą kontrolować procesy uruchomione na serwerze bazy danych. Na ogół uprawnienia te wykorzystuje się do usuwania działających zapytań i pracownicy helpdesku mogą potrzebować tego prawa.

dbcreator — członkowie tej roli mogą tworzyć, zmieniać i usuwać bazy danych na serwerze. Mogą również odtwarzać bazę danych na danym serwerze. Administratorzy DBA są dobrymi kandydatami do tej roli (jeżeli DBA nie należą do roli sysadmin).

bulkadmin — członkowie tej roli mogą uruchamiać polecenie BULK INSERT. Więcej informacji na temat tego polecenie dostarczy rozdział.

diskadmin — członkowie tej roli mogą zarządzać plikami i wzrostem plików na serwerze. Jednak, polecenia są używane głównie dla zachowania zgodności z SQL Serverem 6.5, czyli zapewne rola ta będzie rzadko używana. Administratorzy DBA są dobrymi kandydatami do tej roli (jeżeli DBA nie należą do roli sysadmin).

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. Powinno się pojawić okno podobne do pokazanego na rysunku 5.14. Po ponownym kliknięciu OK można uznać, że została wykonana procedura systemowa sp_addsrvrolemember, tyle, że tym razem w postaci interfejsu graficznego.

Rysunek 5.14. Okno właściwości roli Security Administrators.

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.

Ustalone role bazy danych

Każda baza danych posiada zbiór ustalonych ról jakie mogą być przypisane do nazwy użytkownika. Domyślnie jest dziewięć ról i te dziewięć ról istnieje w bazie zawsze (nie można ich usunąć). Każda rola bazy danych, podobnie jak każda rola serwera, przypisuje użytkownikom określone prawa i możliwości. Więcej informacji na temat praw zostanie podanych w następnym rozdziale.

db_owner — przynależący do tej roli użytkownicy, mogą wykonać wszelkie operacje — ale jedynie w obrębie ich bazy danych. Przynależenie do roli db_owner daje użytkownikowi prawie takie same uprawnienia i przywileje jakie posiada użytkownik dbo tej bazy (właściciel). Wyjątek stanowi polecenie restore. Wyjątek ten zostanie omówiony szerzej w rozdziale 8 przy omawianiu polecenia restore.

db_accessadmin — członkowie tej roli mogą zezwalać i zabraniać użytkownikom dostępu do bazy danych (przykładowo, poprzez uruchomienie procedury systemowej sp_grantdbaccess).

db_securityadmin — członkowie tej roli mogą kontrolować wszystkie uprawnienia, role, przynależność do ról i właścicieli obiektów w bazie danych.

db_ddladmin — członkowie tej roli mogą tworzyć, modyfikować i usuwać wszystkie obiekty bazy danych, ale nie mogą uruchamiać poleceń związanych z bezpieczeństwem (grant, revoke, deny). Kolejny rozdział zawiera więcej informacji na ten temat.

db_backupoperator — członkowie tej roli mogą uruchamiać wybrane polecenia DBCC, jak również ustawiać punkty kontrolne oraz uruchamiać polecenia dotyczące kopii bezpieczeństwa.

db_datareader — członkowie tej roli posiadają uprawnienia wybierania danych z każdej tabeli, widoku lub funkcji w bazie danych.

db_datawriter — członkowie tej roli mają prawo dodawania, modyfikacji i usuwania każdej tabeli lub widoku w bazie danych.

db_denydatareader — członkowie tej roli nie mogą pobierać danych z żadnej z tabel, widoków lub funkcji z bazy danych.

db_denydatawriter — członkowie tej roli nie mogą modyfikować żadnych danych w bazie przy pomocy poleceń insert, update lub delete w żadnej z tabel lub widoków w bazie danych.

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.

Następujący kod pokazuje jak można korzystać z tych systemowych procedur składowych. Aby dodać nową rolę do bazy danych pubs, a następnie przypisać do niej użytkownika, należy uruchomić kod:

Use pubs

Exec sp_addrole 'Management'

Exec sp_addrole 'Operations'

Exec sp_addrolemember 'Management', 'Don'

Exec sp_addrolemember 'Operations', 'RHOME\Marketing'

Odpowiedź systemu powinna być następująca:

New role added.

New role added.

'Don' added to role 'Management'.

'RHOME\Marketing' added to role 'Operations'.

Warto zauważyć, że przy próbie usunięcia roli, do której są przypisani użytkownicy poleceniem:

Exec sp_droprole 'Operations'

pojawi się błąd:

Server: Msg 15144, Level 16, State 1, Procedure sp_droprole, Line 53

The role has members. It must be empty before it can be dropped.

name

.................

RHOME\Marketing

Poprzednie rezultaty mogą być uzyskane w trybie Results in text w SQL Server Query Analyzer. W przypadku wybrania trybu domyślnego Results in Grid, komunikat o błędzie pojawi się na zakładce Messages a lista użytkowników, którzy są przypisani do tej roli pojawi się na zakładce Grids.

SQL Server informuje, którzy użytkownicy pozostali przypisani do danej roli. Aby usunąć pozostałych użytkowników należy uruchomić:

Exec sp_droprolemember 'Operations', 'RHOME\Marketing'

Exec sp_droprole 'Operations'

W wyniku pozytywnego wykonania tej operacji pojawi się komunikat:

'RHOME\Marketing' dropped from role 'Operations'.

Role dropped.

Członkostwo w każdej roli jest przechowywane w połączeniach tabel systemowych sysusers i sysmembers. Obydwie procedury składowe pobierają pojedynczy parametr: nazwę roli w pojedynczym cudzysłowiu.

Można otrzymać te same wyniki korzystając z SQL Server Enterprise Managera. Należy powrócić do folderu Logins dla danego serwera i kliknąć dwukrotnie konto lub kliknąć prawym klawiszem myszy i wybrać Properties z menu rozwijanego. W tym przykładzie zostało wybrane konto DOM-1\Bob. Można skonfigurować role serwera z tego menu lub z zakładki Server Roles. Jednak, na razie należy się skupić na zakładce Database Access. Należy podświetlić bazę danych pubs, powinna się pojawić lista ról w oknie Database roles, jak pokazano na rysunku 5.15.

Rysunek 5.15. Okno właściwości logowania do SQL Servera pokazujące dostęp do bazy danych.

Pojawiają się zarówno ustalone role systemowe, jak również role zdefiniowane przez użytkownika. Należy przejść na dół listy, do roli Management. Aby przypisać użytkownika bazy danych do tej roli, należy zaznaczyć pole wyboru obok nazwy roli. Aby usunąć go z roli wystarczy wyczyścić to pole.

Aby utworzyć nową rolę korzystając z SQL Server Enterprise Managera należy rozwinąć folder Databases i rozwinąć właściwą bazę danych. Przykładowo, należy rozwinąć bazę pubs. Następnie należy podświetlić folder Roles; w prawym panelu pojawi się lista ról. Aby dodać nową rolę, należy kliknąć prawym klawiszem myszy puste miejsce w prawym panelu i wybrać New Database Role. Następnie należy dodać rolę o nazwie Finance i dodać do niej użytkownika Don. Po wykonaniu tej operacji okno powinno wyglądać podobnie jak na rysunku 5.16. Należy kliknąć OK. aby zakończyć tworzenie roli. W kolejnej sekcji zostanie powiedziane więcej na temat opcji Application role.

Rysunek 5.16. Dodawanie nowej roli do bazy danych.

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

Można sobie wyobrazić aplikację payroll (lista płac) jako doskonały przykład użycia tych ról. Chociaż wszyscy administratorzy w departamencie payroll muszą okresowo uaktualniać wypłaty pracowników i dodatkowe informacje, lepiej jest jeśli używają do tego aplikacji niż aby bezpośrednio zadawali zapytania do bazy danych SQL Servera (z potencjalnymi katastrofalnymi konsekwencjami tych działań). Kiedy aplikacji uruchamia się, użytkownicy mogą być zalogowani do SQL Servera na swoje konta (na konta SQL Servera lub raczej poprzez dane uwierzytelniające Windows 2000, więc mogą nawet nie wiedzieć, że nastąpiło logowanie). Następnie należy uruchomić odpowiedni kod (procedurę systemową sp_setapprole) aby włączyć rolę aplikacji payroll. Od tego momentu, dopóki aplikacja określa połączenia do bazy danych, wymuszane są uprawnienia roli, a uprawnienia użytkowników są wyłączone. Dlatego, jeżeli rola payroll ma uprawnienia do modyfikacji tabel payroll, ale administratorzy payroll nie mają, mogą oni nadal uruchamiać tę aplikację. Jeszcze lepiej, nie mogą oni świadomie (lub nieświadomie) ominąć żadnych zabezpieczeń lub kontroli, która została wprowadzona wraz z aplikacją. Najlepszą sprawą jest to, że wszelka działalność jest stale monitorowana poprzez informacje związane z logowaniem użytkowników.

Role aplikacji są bardzo istotne. Teraz zostanie omówiona ich implementacja. Role aplikacji są dość proste w porównaniu do ich użyteczności. W kolejnym rozdziale zostanie powiedziane jak przypisywać uprawnienia do roli.

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.

Jedyny problem tej metody związany jest z uprawnieniami. Istotne jest, aby zauważyć, że gdy rola aplikacji jest włączona, jest ona nadal członkiem roli public, dlatego uprawnienia wynikające z roli public nadal funkcjonują mimo korzystania z roli aplikacji.

2 Część I ♦ Podstawy obsługi systemu WhizBang (Nagłówek strony)

34 H:\Książki\!Marcin\SQL Server 2000 dla każdego\5 po odbiorze technicznym\r05-1.doc

---