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