Microsoft SQL Server 2008

Podstawowe zagadnienia i rozwiązania zabezpieczeń w SQL Server Udostępnij na: Facebook

Opublikowano: 27 lipca 2009

Zawartość strony
 Bezpieczeństwo fizyczne  Bezpieczeństwo fizyczne
 Bezpieczeństwo sieci  Bezpieczeństwo sieci
 Minimalizacja powierzchni ataku  Minimalizacja powierzchni ataku
Konta usług  Konta usług
 Ograniczanie przywilejów administratora  Ograniczanie przywilejów administratora
 Uwierzytelnianie  Uwierzytelnianie
 Autoryzacja  Autoryzacja
 Wstrzykiwanie SQL  Wstrzykiwanie SQL
 Odzyskiwanie po awarii  Odzyskiwanie po awarii
 Inspekcja  Inspekcja
 Podsumowanie  Podsumowanie

Każdy, kto miał do czynienia z branżą informatyczną, wie, że bezpieczeństwo to gorący temat. W końcu dane są dla firmy jednym z najcenniejszych zasobów, a ich ochrona jest sprawą krytyczną. Zastanawiając się, o czym napisać w tym wydaniu dotyczącym bezpieczeństwa, próbowałem określić, jaka funkcja bezpieczeństwa zasługuje na cały artykuł. Wtedy zacząłem myśleć o tych wszystkich „przypadkowych administratorach baz danych” (tych profesjonalistach IT, którzy przypadkiem stają się odpowiedzialni za instancję SQL Server) oraz o dużym oddźwięku, jaki wywołał artykuł Top Tips for Effective Database Maintenance (Najważniejsze wskazówki efektywnej konserwacji bazy danych), wydany w sierpniu 2008. Przyszło mi do głowy, że powinienem napisać artykuł obejmujący podstawowe zagadnienia bezpieczeństwa SQL Server – rodzaj podstawowego wprowadzenia do dobrych zabezpieczeń instancji SQL Server.

Artykuł opisujący wszystkie problemy bezpieczeństwa, z którymi mamy od czynienia, zająłby całe wydanie pisma, więc zapytałem moich znajomych z tytułem MPV w dziedzinie SQL Server (i moją żonę) o propozycje, co powinienem w nim uwzględnić. Ustaliłem, że wezmę pod uwagę 10 najważniejszych obszarów bezpieczeństwa, o które należy dbać, jeśli nie jest się starym wyjadaczem w dziedzinie administrowania bazami danych, ale okazało się, że trzeba się zająć instancją SQL i powiązanymi z nią aplikacjami. (Trzeba pamiętać, że w żadnym wypadku lista ta nie wyczerpuje wszystkich zagadnień).

Wszystkie odwołania do Books Online dotyczą wersji SQL Server 2008, ale każda witryna sieci Web ma także łącza do wersji SQL Server 2005. W podsumowaniu artykułu podaję łącza do głównych opracowań i części Books Online dotyczących bezpieczeństwa SQL Server 2005 i SQL Server 2008.

Bezpieczeństwo fizyczne

Wiadomo, że bezpieczeństwa SQL Server nie rozpatrujemy samodzielnie, gdyż, aby dotrzeć do SQL Server, trzeba przejść wszystkie warstwy. Ze względu na koncepcję warstwowego bezpieczeństwa, często nazywanego „dogłębną obroną”, nie chronimy tylko jednej warstwy, lecz rozpatrujemy cały system.

Pierwszym oczywistym elementem, jaki bierzemy pod uwagę, jest bezpieczeństwo fizyczne maszyny, na której działa SQL Server – warstwa ta jednak jest często pomijana lub jest przedmiotem samozadowolenia. Nie odnoszę się tylko do kwestii, czy maszyna może być skradziona, ale także do fizycznego dostępu do takich elementów, jak system pamięci przechowujący pliki bazy danych, taśmy kopii zapasowych oraz każdy serwer przechowujący nadmiarowe kopie bazy danych. Tylko ludzie, którzy naprawdę muszą mieć fizyczny kontakt z tymi obiektami, powinni mieć do nich dostęp. Każdy, kto potrzebuje chwilowego dostępu, powinien być monitorowany i wprowadzany przez inną osobę.

Mniej oczywistym wymaganiem jest bezpieczeństwo komputerów biurkowych osób, które mają dostęp z wysokimi przywilejami do SQL Server. Jeśli ktoś ma dostęp do SQL Server na poziomie sysadmin, a pozostawia swój komputer z systemem Windows niewyłączony, to żadne zabezpieczenia na świecie nie przeszkodzą osobie przechodzącej obok niechronionego systemu w możliwości uzyskania dostępu do poufnych danych. Jeszcze bardziej zdradliwy problem pojawi się, gdy ktoś przechodząc zmieni część danych – na przykład nieuczciwy pracownik, który zna schemat bazy danych kadr i zechce zmienić pensje w niemożliwy do wykrycia sposób.

Istnieje bardzo ciekawy raport TechNet (obejmujący slajdy i webcasty), zatytułowany „Physical Security at Microsoft”, w którym opisano, jak firma Microsoft zarządza fizycznym bezpieczeństwem swoich serwerów.

 Do początku strony Do początku strony

Bezpieczeństwo sieci

Choć serwery mogą być fizycznie niedostępne, są z pewnością połączone z jakąś siecią. Może to być izolowana sieć LAN bez połączeń zewnętrznych lub też bezpośrednie połączenie z Internetem. Niezależnie od sytuacji, jest szereg rzeczy, które trzeba wziąć pod uwagę:

  • Sprawdzenie, czy serwer Windows ma odpowiednio skonfigurowane zabezpieczenia sieciowe.
  • Decyzja, które protokoły sieciowe powinny być dozwolone i wyłączenie zbędnych.
  • Sprawdzenie, czy ustawiona jest zapora sieciowa (jak Windows Firewall) i skonfigurowanie jej tak, aby pozwalała na dostęp do SQL Server (Jak widać na rysunku 1).
  • Decyzja, czy szyfrować połączenia z SQL Server i odpowiednia konfiguracja szyfrowania.
  • Jeśli będzie używany Kerberos, trzeba zarejestrować główną nazwę serwera (Server Principal Name). Kerberos jest mechanizmem uwierzytelniania, który współpracuje z uwierzytelnianiem Windows (które opisuję w dalszej części artykułu), ale jest on słabo rozumiany. Jasne i zwięzłe wytłumaczenie zostało podane przez Rona Greene’a, inżyniera Support Escalation, w jego blogu „ Kerberos for the Busy Admin ". Zalecam zapoznanie się z nim.
  • Decyzja, czy używać usługi SQL Server Browser Service, aby pomóc klientom w poszukiwaniu zainstalowanych instancji SQL Server, oraz decyzja, czy chcemy ukryć pewne instancje. Ukrywanie instancji oznacza, że aplikacje klienckie i użytkowników będą musiały znać szczegóły połączenia instancji SQL Server, lecz zapobiega to przeglądaniu sieci w celu znalezienia jakichś instancji SQL Server.

Rysunek 1: Konfiguracja zapory sieciowej Windows w celu zezwolenia TCP na dostęp do serwera SQL Server.

Wszystkie te zadania (i więcej) są wyjaśnione w SQL Server 2008 Books Online, począwszy od tematu Server Network Configuration. Dobra jest też część na temat konfiguracji klienta Client Network Configuration.

 Do początku strony Do początku strony

Minimalizacja powierzchni ataku

Im więcej usług i funkcji jest włączonych, tym większa jest powierzchnia ataku, inaczej obszar ataku, z której mogą skorzystać sieciowi przestępcy. SQL Server 2005 przyjął strategię „domyślne wyłączenie” – funkcje wpływające na bezpieczeństwo są domyślnie wyłączane i włącza się je przed DBA, tylko gdy są potrzebne. (Proces włączania i wyłączania usług jest powszechnie znany jako konfiguracja obszaru powierzchni).

Podstawowym przykładem funkcji, którą lepiej wyłączyć, jest xp_cmdshell, umożliwiająca wykonywanie poleceń na hoście systemu Windows z kontekstu instancji SQL Server. Jeśli intruz ujawni instancję SQL Server, zaś konto usługi SQL Server ma w systemie Windows podwyższone uprawnienia, funkcja xp_cmdshell może być użyta w celu uzyskania dostępu do systemu Windows.

Jest wiele różnych metod konfiguracji obszaru powierzchni. Zarówno SQL Server 2005, jak i SQL Server 2008 obsługują menedżera SQL Server Configuration Manager zapewniającego konfigurację usług i protokołów sieciowych. Oba systemy obsługują wbudowaną procedurę sp_configure do konfiguracji funkcji i opcji mechanizmu bazy danych. Jako przykład podaję kod wyłączający funkcję xp_cmdshell:

-- Pozwolenie na zmianę zaawansowanych opcji 

EXEC sp_configure 'show advanced options', 1;

GO

-- Aktualizacja aktualnie skonfigurowanej wartości dla – zaawansowane opcje 

RECONFIGURE;

GO

-- Wyłączenie xp_cmdshell

EXEC sp_configure 'xp_cmdshell', 0;

GO

-- Aktualizacja aktualnie skonfigurowanej wartości dla tego – funkcja 

RECONFIGURE;

GO

Graficzne metody konfigurowania opcji i funkcji mechanizmu bazy danych w obu wersjach są całkiem inne. SQL Server 2005 wprowadził narzędzie Server Surface Area Configuration (SAC). Pozwala ono na łatwe dokonywanie zmian. Rysunek 2 pokazuje, jak na przykład można wyłączyć xp_cmdshell za pomocą SAC.

Rysunek 2: Wyłączanie xp_cmdshell za pomocą SAC w SQL Server 2005.

W SQL Server 2008, SAC został całkowicie usunięty, a jego funkcje przejęte przez funkcję Policy-Based Management. Więcej informacji na ten temat można znaleźć w SQL Server 2008 Books Online, w temacie „Administering Servers by Using Policy-Based Management”. Rysunek 3 ilustruje tworzenie warunku sprawdzającego, czy polecenie xp_cmdshell jest wyłączone. Po skonfigurowaniu zasady mogą dotyczyć zarówno instancji SQL Server 2005, jak i SQL Server 2008, a mogą zostać także zastosowane z możliwością zmiany ustawień za pomocą jednego kliknięcia.

Rysunek 3: Tworzenie warunku Policy-Based Management w SQL Server 2008.

 Do początku strony Do początku strony

Konta usług

SQL Server działa w systemie Windows jako jedna lub więcej usług, zaś każda usługa musi mieć w Windows konto używane do uruchomienia usługi. Konto musi mieć dostęp do różnych zasobów systemu Windows (jak sieć lub różne katalogi systemu plików). Zgodnie z najlepszą praktyką konto powinno mieć najmniejsze możliwe przywileje wymagane do poprawnego działania SQL Server. Jest to częścią tego, co nazywamy zasadą najmniejszych przywilejów, która mówi, że system będzie bardziej bezpieczny, gdy użytkownicy i procesy otrzymają tylko te przywileje, które są konieczne, i żadnych innych.

Jako takie, konto usług SQL Server nie powinno być kontem wysokiego uprzywilejowania (jak administrator lokalny lub system lokalny – Local System, Local Administrator), gdyż w przypadku zagrożenia bezpieczeństwu SQL Server bezpieczeństwo systemu Windows również może być zagrożone. Usługi są zwykle uruchamiane z wbudowanego konta o nazwie Network Service (Usługa sieciowa), jeśli jednak SQL Server wymaga dostępu do zasobów innych domen, trzeba utworzyć nowe konto użytkownika domeny, z minimalnymi wymaganymi przywilejami i minimalnym dostępem do zasobów. W SQL Server 2008 Books Online, w temacie „Setting Up Windows Service Accounts” podano wyczerpującą listę kont usług, wymaganych przywilejów oraz zasobów. Warto zwrócić uwagę, że w razie konieczności zmiany konta usługowego (lub czegoś z nim związanego), należy zawsze korzystać z SQL Server Configuration Manager, aby mieć pewność, że wszystkie zmiany w konfiguracji zostaną wykonane poprawnie.

 Do początku strony Do początku strony

Ograniczanie przywilejów administratora

Im bardziej ujawniany jest login SA (administratora systemu) lub ustalona rola serwera sysadmin, tym większe jest potencjalne zagrożenie dla bezpieczeństwa. Jest kilka dobrych praktyk, których warto przestrzegać.

Trzeba zminimalizować liczbę osób z dostępem do konta SA i ograniczyć członkostwo w roli sysadmin (i innych rolach uprzywilejowanych), aby przywileje sysadmin mieli tylko ci, którzy naprawdę ich potrzebują. Nie należy wydawać hasła SA każdemu, kto chce mieć tymczasowy dostęp do SQL Server lub użytkownikowi SQL, który chce szybko wykonać jakieś zadania. W takich sytuacjach trzeba utworzyć nowy login SQL i nadać takie przywileje, jakie są w tym momencie potrzebne.

Lepiej, aby poszczególne osoby miały przypisaną rolę sysadmin, zamiast korzystały z konta SA. W ten sposób można usunąć login użytkownika bez zmiany hasła konta SA. Jeśli przejmujemy stary serwer i nie mamy pojęcia, kto miał do nieco wcześniej dostęp, trzeba zmienić hasło kontrolowanego konta SA. Zagadnieniem, które wywołuje dyskusję, jest kwestia, czy usuwać wbudowaną grupę Windows BUILTIN/Administrators z roli sysadmin (jest ona dodawana domyślnie). Czy administrator Windows powinien mieć możliwość przeszukiwania bazy danych działu kadr? Czy dana firma z zasady wierzy w prawość i uczciwość wszystkich administratorów? Jeśli zdecydujemy się na usunięcie, trzeba postępować ostrożnie. Jest to szczególnie ważne w środowisku klastrowym, gdzie niepodjęcie odpowiednich kroków sprawi, że SQL Server nie będzie się uruchamiał. Więcej informacji na ten temat i na temat innych zagadnień związanych z klastrami można znaleźć w bazie Knowledge Base, w artykule „Clustered SQL Server Dos, Don'ts, and Basic Warnings”.

Ci, którzy mają dostęp jako sysadmin, nie powinni logować się z wysokimi uprawnieniami, jeśli nie jest to bezwzględnie konieczne – przy założeniu, że każdy z tych użytkowników ma dwa loginy, jeden uprzywilejowany, a drugi nie. Domyślne korzystanie z nieuprzywilejowanego konta pomaga zminimalizować możliwość popełnienia kosztownych błędów, a także zmniejsza prawdopodobieństwo, że niezablokowany terminal systemu Windows będzie miał otwarte okno z przywilejami sysadmin. Trzeba pamiętać o dogłębnej ochronie!

Ostatnim punktem, który tu wskazuję, to konieczność unikania aplikacji wymagających przywilejów sysadmin. Niestety jest to częsta i niemożliwa do uniknięcia zła praktyka w przypadku niektórych aplikacji, ale trzeba unikać takiej sytuacji we własnych aplikacjach i narzekać na twórców aplikacji, które wymagają uprawnień sysadmin.

 Do początku strony Do początku strony

Uwierzytelnianie

Dostępne są dwa tryby uwierzytelniania: Windows Authentication i tryb mieszany (który stanowi połączenie uwierzytelniania Windows z uwierzytelnianiem SQL Server).

Uwierzytelnianie Windows korzysta z kont sieci/domeny, aby zweryfikować konto Windows używane do połączenia z SQL Server. Jeśli tak zostanie wybrane podczas instalacji, tworzone jest konto SA z wygenerowanym losowo hasłem, które jest jednak wyłączone. Natychmiast po zakończeniu instalacji trzeba zmienić hasło SA na silne i bezpieczne hasło, pozostawiając jednak konto wyłączone, aż do momentu, gdy będzie absolutnie niezbędne.

Uwierzytelnienie SQL Server opiera się na tym, że każdy użytkownik definiuje konto i hasło SQL Server zapisane w SQL Server. I oczywiście oznacza to, że konto SA jest włączone i musi mieć zdefiniowane hasło. Przy uwierzytelnianiu SQL Server użytkownicy mają co najmniej dwie nazwy użytkownika i hasła (jedno dla sieci i jedno dla SQL Server). Ogólnie zaleca się, aby w miarę możliwości używać tylko uwierzytelniania Windows, gdyż jest to rozwiązanie bardziej bezpieczne. W Books Online, pod tematem „Choosing an Authentication Mode", jest to wyjaśnione w sposób bardziej szczegółowy, wraz z podaniem sposobu zmiany trybu uwierzytelniania.

Jeśli używany jest tryb SQL Authentication, wszyscy użytkownicy powinni mieć silne hasło – dostatecznie skomplikowane, aby było odporne na odgadnięcie przez program łamiący hasła. Jest to szczególnie ważne w przypadku kont o wysokich przywilejach, jak konta SA i członkowie roli sysadmin. (Jedną z popularnych, lecz najgorszych praktyk, jest puste hasło SA. Na szczęście od wersji SQL Server 2000 SP3 począwszy nie jest to możliwe).

Hasła powinny być też regularnie zmieniane, a firma powinna publikować zasady korporacyjne pomagające pracownikom w używaniu silnych i bezpiecznych haseł zgodnie z najlepszą praktyką. Przegląd najlepszych praktyk tworzenia i ochrony silnych haseł można znaleźć w artykule „Strong Passwords: How to Create and Use Them". Można włączyć te zasady do swoich zasad korporacyjnych.

Jeśli SQL Server 2005 lub SQL Server 2008 działa w wersji Windows Server 2003 lub późniejszej, do wprowadzenia zasad złożoności i końca ważności haseł może być użyty mechanizm zasad haseł systemu Windows. Część w SQL Server 2008 Books Online o nazwie „Password Policy” zawiera informacje dotyczące obsługi silnych haseł i różnych zasad haseł w SQL Server.

 Do początku strony Do początku strony

Autoryzacja

Jak już wspomniałem, jedną z podstaw systemów bezpieczeństwa jest stosowanie zasady najmniejszych przywilejów. Chociaż dotyczy to bezpośrednio przywilejów poziomu administracyjnego, ma też zastosowanie do uprawnień zwykłych użytkowników baz danych. Użytkownik jednej bazy danych nie powinien (zapewne) mieć możliwości dostępu do innej bazy danych. Właściciel jednego zbioru tabel nie powinien mieć możliwości dłubania przy cudzych tabelach. Użytkownicy mają mieć dostęp tylko do tych danych, do których powinni mieć, a nawet wtedy trzeba ograniczyć tę możliwość tylko do wykonywania potrzebnych działań na danych (na przykład SELECT, ale nie UPDATE lub DELETE).

Wszystko to można zrobić w ramach SQL Server dzięki pełnemu, hierarchicznemu systemowi uprawnień, w którym użytkownicy lub role (nazywane podmioty zabezpieczeń) mają przyznawane lub zabierane uprawnienia do określonych zasobów (nazywanych elementami zabezpieczanymi), takie jak obiekt, schemat lub baza danych. Przegląd hierarchii uprawnień w SQL Server pokazano na rysunku 4. Oznacza to także, że trzeba przestrzegać zasady najniższych przywilejów. Na przykład wszyscy twórcy oprogramowania nie powinni być członkami roli db_owner. Trzeba ograniczyć uprawnienia do roli publicznej i nadawać uprawnienia na najniższym poziomie (użytkownika lub roli), aby zminimalizować bezpośredni dostęp. Pełny opis najlepszych praktyk dla uprawnień wykracza poza zakres tego artykułu, ale SQL Server 2008 Books Online zawiera część o nazwie „Identity and Access Control (Database Engine)”, w której podano szczegółowy opis tych zagadnień.

Rysunek 4: Hierarchia uprawnień w SQL Server.

Aby dopuścić bardziej szczegółowe uprawnienia oraz lepszą separację ról w obrębie bazy danych, w SQL Server 2005 wprowadzono podział według schematu użytkownika, gdzie schematy są niezależne od użytkowników bazy danych i stanowią jedynie kontenery na obiekty. Pozwala to na wiele zmian w działaniu, w tym na uzyskanie znacznie większej precyzji w zarządzaniu uprawnieniami. (Czteroczęściowe nazewnictwo ma w SQL Server 2005 i SQL Server 2008 postać zgodną z formatem serwer.baza_danych.schemat.obiekt, a wcześniej format ten miał postać serwer.baza_danych.właściciel.obiekt).

Na przykład można utworzyć schemat, w którym twórcy oprogramowania mają uprawnienia CONTROL. Mogą tworzyć, zmieniać lub odrzucać ( CREATE, ALTER, DROP) dowolne obiekty w ramach kontrolowanych schematów, ale nie mają domyślnych uprawnień do innych schematów w bazie danych i nie muszą mieć praw db_owner do tworzenia bazy danych. Ponadto oddzielenie użytkownika i schematu pozwala na odrzucanie użytkowników bazy danych bez zapisania wszystkich związanych z nimi obiektów lub aplikacji z nową nazwą użytkownika – obiekty są elementami schematu i nie są już powiązane z kreatorem obiektu.

Z tego powodu najlepszą praktyką jest użycie schematów do własności obiektów. Więcej informacji na ten temat można znaleźć w SQL Server 2008 Books Online, pod tematem „User-Schema Separation”.

Innym sposobem zapewniania, aby użytkownicy nie robili rzeczy, których nie powinni robić, jest uniemożliwienie bezpośredniego dostępu do tabel bazy danych. Można to zrobić za pomocą wbudowanych procedur i funkcji używanych do enkapsulacji, kontrolowania i izolowania operacji, takich jak aktualizacja lub usuwanie, a także zapewniając widoki pozwalające na kontrolowany i optymalny wybór.

 Do początku strony Do początku strony

Wstrzykiwanie SQL

Jedną z najpopularniejszych metod uzyskania nieautoryzowanego dostępu do danych jest korzystanie z ataków wstrzykiwania SQL. Wstrzykiwanie SQL może przyjmować wiele form, ale podstawowe podejście wykorzystuje kod, który używa dynamicznie budowanych łańcuchów i „wstrzykuje” niespodziewany kod do konstrukcji. Na przykład poniższy atak wstrzykiwania wykorzystuje źle napisany kod do sprawdzania wejścia użytkownika, aby oszukać SQL Server w celu zaakceptowania danych ze znakami escape w łańcuchu wejściowym. Choć przykład jest wymyślony, uwypukla on, co się dzieje, gdy kod dynamicznie tworzy łańcuchy za pomocą danych wejściowych, które nie są dokładnie sprawdzone:

DECLARE @password VARCHAR (20);

DECLARE @input    VARCHAR (20);

DECLARE @ExecStr  VARCHAR (1000);



SELECT @password = 'SecretSecret';



-- przyjmijmy, że aplikacja otrzymuje na wejściu 'OR''='

SELECT @input = '''OR''''=''';



SELECT @ExecStr = 'IF ''' + @password + ''' LIKE ''' + @input + ''' PRINT ''Password Accepted''';



EXEC (@ExecStr);

GO

Jeśli uruchomimy ten kod, wydrukuje on frazę „Password Accepted” („Hasło zaakceptowane”), nawet jeśli dane użytkownika w oczywisty sposób nie pasują do łańcucha hasła. Dane użytkownika zawierały sekwencję escape, która zmieniła logikę Transact-SQL, gdyż dane wejściowe nie zostały poprawnie zanalizowane i sprawdzone.

Wstrzyknięcie SQL nie powinno stanowić problemu dla dobrze napisanych aplikacji i mamy na to szereg określonych sztuczek (jak wykorzystanie QUOTENAME do ograniczonych identyfikatorów). Jeśli jednak odziedziczymy starszą aplikację (lub domowy projekt, który stał się aplikacją w korporacji), trzeba wykonać określone testy, aby zobaczyć, czy nie jest ona podatna na ataki wstrzykiwania SQL. Dostępnych jest wiele technik ograniczania ataków wstrzykiwania SQL. W SQL Server 2008 Books Online znajduje się dział, rozpoczynający się od tematu „SQL Injection”.

 Do początku strony Do początku strony

Odzyskiwanie po awarii

Na ile trzeba się tym martwić, zależy od wymagań dotyczących czasu przerwy i utraty danych. (Jeśli wymagania nie zostały jeszcze zdefiniowane, trzeba to zrobić). Problemy bezpieczeństwa mogą pojawić się na wielu poziomach. Problemem może być odzyskiwanie po awarii, które obejmuje przełączenie awaryjne na inny SQL Server lub też konieczność odtworzenia bazy danych zawierającej zaszyfrowane dane.

W pierwszym przypadku problemy pojawiają się, gdy loginy potrzebne do dostępu do bazy danych nie zostały powielone na serwerze awaryjnym – na przykład podczas wysyłania dzienników lub dublowania bazy danych. Jeśli baza danych zostanie przełączona na instancję lustrzaną, zaś aplikacja próbuje połączyć się za pomocą określonego loginu, którego nie ma na serwerze lustrzanym, aplikacja otrzyma informacje o błędzie numer 18456 „login failed” (Nieudane logowanie). Loginy są częścią ekosystemu aplikacji i muszą być zdefiniowane w bazie danych goszczącej instancję. W artykule 918992, w Knowledge Base, „How to Transfer the Logins and the Passwords Between Instances of SQL Server 2005”, wytłumaczono, jak to zrobić, ja zaś dalej omówię sposób naprawienia błędu 18456.

W drugim przypadku problemy pojawiają się, gdy kopia zapasowa bazy danych zawiera zaszyfrowane dane, a nie została wykonana kopia zapasowa klucza (lub kluczy) szyfrowania użytego do zaszyfrowania danych, lub też nie jest dostępna w instancji SQL Server, w której jest przywracana baza danych. W najlepszym przypadku tylko część danych w bazie jest zaszyfrowana, nie ma więc dostępu tylko do pewnego podzbioru danych. W przypadku najgorszym cała baza danych jest zaszyfrowana za pomocą Transparent Data Encryption (TDE) w SQL Server 2008. Wtedy, jeśli certyfikat serwera użyty do ochrony klucza szyfrowania bazy danych nie został zapisany w kopii zapasowej i nie jest dostępny, cała baza danych nie może zostać odzyskana. Pojawią się wówczas następujące błędy:

Msg 33111, Level 16, State 3, Line 1

Cannot find server certificate with thumbprint

'0xFBFF1103AF133C22231AE2DD1D0CC6777366AAF1'.

Msg 3013, Level 16, State 1, Line 1

RESTORE DATABASE is terminating abnormally.

Oczywiście to właśnie jest celem TDE - aby ktoś, kto natrafi na kopię zapasową bazy danych nie mógł jej odzyskać i mieć dostępu do poufnych danych. Jeśli jednak jesteśmy właścicielami danych i chcemy uzyskać dostęp, to musimy mieć dostęp do certyfikatu serwera, gdyż inaczej utracimy dane.

Szyfrowanie stanowi samo w sobie duży odrębny temat, który jest dokładnie omówiony w SQL Server 2008 Books Online, począwszy od działu zatytułowanego „SQL Server Encryption".

 Do początku strony Do początku strony

Inspekcja

Jedną z ważniejszych czynności, jakie trzeba wykonać dla poprawienia bezpieczeństwa systemu, jest wdrożenie inspekcji. Dzięki temu będzie wiadomo, co kto robi. Zależnie od rodzaju prowadzonego biznesu, inspekcja może być obligatoryjna.

W minimalnym przypadku trzeba dokonać inspekcji udanych i nieudanych logowań, aby można było stwierdzić, że na przykład po pięciu nieudanych próbach nastąpiło udane logowanie. Wiemy wtedy, że ktoś próbuje włamać się do naszej instancji SQL Server (i jakiego loginu używa). Rysunek 5 pokazuje konfigurację inspekcji logowania za pomocą okna dialogowego Server Properties (Właściwości serwera) w usłudze SQL Server 2005 Management Studio. Nieudane próby logowania podlegają inspekcji jako komunikat 18456 w dzienniku błędów, zaś stan błędu informuje o przyczynie niepowodzenia. Najlepszy opis różnego rodzaju stanów, jaki udało mi się znaleźć, wraz z długą dyskusją na temat radzenia sobie z nimi, znajduje się w poście umieszczonym przez Il-Sung Lee, na blogu SQL Protocols o nazwie „Understanding 'Login Failed' (Error 18456) Error Messages in SQL Server 2005".

Rysunek 5: Konfigurowanie inspekcji loginów w SQL Server 2005 Management Studio.

Pełna inspekcja wszystkich działań jest w SQL Server 2005 trudna (i wykracza poza zakres tego artykułu). Obejmuje różne wyzwalacze oraz śledzenie SQL Trace. W SQL Server 2008 inspekcja została znacznie uproszczona dzięki wprowadzeniu nowej funkcji: SQL Server Audit (Inspekcja SQL Server). Jest ona omówiona w nowym, bardzo szczegółowym opracowaniu o nazwie „Auditing in SQL Server 2008". Szczegóły dotyczące innych narzędzi inspekcji można znaleźć w SQL Server 2008 Books Online, w dziale „Auditing (Database Engine)".

 Do początku strony Do początku strony

Podsumowanie

Zaprezentowałem tu wiele tematów i podaję wiele odnośników, ale taki jest cel tego artykułu. Chciałem podać przegląd najważniejszych tematów z zakresu bezpieczeństwa, które trzeba wziąć pod uwagę, będąc zmuszonym do zajmowania się administracją baz danych bez przygotowania w zakresie bezpieczeństwa.

Jest szereg narzędzi, które mogą pomóc w sprawdzeniu systemu z punktu widzenia często występujących zagrożeń bezpieczeństwa. Pierwszym jest usługa MBSA, Microsoft Baseline Security Analyzer (MBSA), która sprawdzi Windows, sieć, system plików, a nawet niektóre kwestie bezpieczeństwa w SQL Server 2000 i SQL Server 2005. Najnowszą jej wersją jest Microsoft Baseline Security Analyzer 2.1. Znów tylko dla SQL Server 2000 i SQL Server 2005 istnieje specjalne narzędzie dla SQL Server o nazwie Best Practices Analyzer (BPA). Używa ono zdefiniowanej wcześniej listy reguł sprawdzania konfiguracji SQL Server i oznacza wszelkie problemy (na przykład puste hasła SA).

Żadne z tych narzędzi nie współpracuje z SQL Server 2008. Narzędzie BPA nie będzie nawet przygotowane w wersji dla SQL Server 2008 i zostało zastąpione, wraz z krótko używanym narzędziem SQL Server 2005 Surface Area Configuration, przez nową funkcję Policy-Based Management (Zarządzanie oparte na zasadach), o której pisałem wyżej. Częściową przyczyną tej zmiany jest fakt, że BPA i SAC były narzędziami tylko do odczytu, pozwalającymi znaleźć problemy - nie naprawiały ich jednak. Policy-Based Management oferuje wybór wielu możliwości naprawy, więc można go używać jako docelowe narzędzie nawet dla serwerów SQL Server 2000 i SQL Server 2005.

Oczywiście trzeba zawsze korzystać z Windows Update, aby mieć pewność, że nowe korekty zabezpieczeń i pakiety serwisowe zostały załadowane do instalacji w odpowiednim momencie - jest to najlepszy sposób śledzenia najnowszych aktualizacji. Ich instalacja bez wyłączania systemu wykracza poza zakres tego artykułu, ale pewne pomysły znalazły się w artykule w dziale SQL Q&A, w grudniu 2006 r.

Szukając ogólnych zasobów dotyczących bezpieczeństwa firmy Microsoft możemy znaleźć wiele miejsc, które pokaże nasza ulubiona przeglądarka. Aby zaoszczędzić czas na poszukiwania, polecam dwa poniższe opracowania: „SQL Server 2005 Security Best Practices-Operational and Administrative Tasks" i „SQL Server 2008: Security Overview for Database Administrators".

Dla SQL Server 2005 punktem rozpoczęcia poszukiwań w Books Online jest tytuł „Security Considerations for Databases and Database Applications". Z kolei dla SQL Server 2008, odpowiednim miejscem startu w Books Online jest „Security and Protection (Database Engine)".

W zakresie tego artykułu chciałbym uzmysłowić wszystkim, jakie kroki trzeba podjąć, aby dane zapisane w SQL Server były tak bezpieczne, jak jest to potrzebne. Jest to zwłaszcza ważne, gdy dziedziczymy instancję SQL Server, którą wcześniej zarządzał ktoś inny. Przypomina to kupno od kogoś domu - trzeba dowiedzieć się, czy alarm działa, czy podwórko jest ogrodzone oraz kto ma zapasowe klucze. Trzeba przejrzeć listę zadań zawartą w tym artykule, gdyż jest ona dobra na początek, ale trzeba także zagłębić się w dziedzinach, które w danej sytuacji są najważniejsze. I jak zawsze, czekam na ewentualne komentarze i pytania pod adresem Paul@SQLskills.com.

O autorze

Paul S. Randal jest dyrektorem zarządzającym SQLskills.com i SQL Server MVP. Pracował w zespole SQL Server Storage Engine w firmie Microsoft od 1999 do 2007. Paul napisał materiały DBCC CHECKDB/repair dla SQL Server 2005 i był odpowiedzialny za Core Storage Engine podczas tworzenia SQL Server 2008. Paul jest ekspertem z dziedziny odzyskiwania danych po awarii, wysokiej dostępności oraz utrzymania bazy danych, a także regularnie występuje na konferencjach na całym świecie. Jego blog jest pod adresem SQLskills.com/blogs/paul.

 Do początku strony Do początku strony

Microsoft SQL Server 2008