• Artykuł

Microsoft SQL Server 2008

Przegląd zabezpieczeń SQL Server 2008 dla administratorów baz danych

Opublikowano: 15 lipca 2008

SQL Server 2008 jest zabezpieczony w obszarze projektu, konfiguracji domyślnej i wdrożenia. Firma Microsoft jest zaangażowana w udzielanie informacji o zagrożeniach, metodach przeciwdziałania i poprawkach zabezpieczeń, które są niezbędne do zapewniania możliwie jak największego bezpieczeństwa danych. Niniejszy dokument prezentuje wybrane, najważniejsze funkcje zabezpieczeń systemu SQL Server 2008. Pokazuje, w jaki sposób my - administratorzy możemy instalować SQL Server w sposób bezpieczny i nadal utrzymywać jego bezpieczeństwo wtedy, gdy składowane na serwerze dane są wykorzystywane przez aplikacje i użytkowników.

*

Zawartość strony
Wprowadzenie  Wprowadzenie
Bezpieczna konfiguracja  Bezpieczna konfiguracja
Uwierzytelnianie  Uwierzytelnianie
Autoryzacja  Autoryzacja
Zarządzanie szyfrowaniem i kluczami  Zarządzanie szyfrowaniem i kluczami
Inspekcje w SQL Server 2008  Inspekcje w SQL Server 2008
Wnioski  Wnioski

Wprowadzenie

Ze względu na łączenie coraz większej ilości sieci, aspekty związane z bezpieczeństwem stają się coraz istotniejsze. Trzeba chronić zasoby organizacji, a w szczególności jej bazy danych, które zawierają wiele wartościowych informacji o firmie. Chroniące przedsiębiorstwo przed miliardami zagrożeń zabezpieczenia, stanowią jedną z kluczowych funkcji silnika bazy danych. Funkcje zapewniające bezpieczeństwo serwera Microsoft® SQL Server™ 2008, zostały zaprojektowane tak, aby czynić go jeszcze bezpieczniejszym, przy jednoczesnym zapewnieniu przystępności i łatwości w zarządzaniu dla osób odpowiedzialnych za ochronę danych.

W ciągu ostatnich kilku lat świat osiągnął dużo bardziej dojrzałą świadomość w kwestii tego, jaki musi być bezpieczny system komputerowy. Firma Microsoft stała na czele tego rozwoju, a SQL Server stanowi jeden z pierwszych produktów serwerowych, które w pełni wykorzystują to dojrzalsze podejście do kwestii bezpieczeństwa. Stosuje on ważną regułę najniższych uprawnień, abyśmy nie musieli przyznawać użytkownikom większych uprawnień niż te, które są im niezbędne do wykonywania własnej pracy. Dostarcza wiele narzędzi typu „defense in-depth”, pozwalających zastosować wielowarstwowe mechanizmy przeciwdziałania atakom, które zniechęcą nawet najbardziej utalentowanych włamywaczy.

Inicjatywa Microsoft’s Trustworthy Computing, która przyświeca wszystkim projektom programistycznym w firmie, była już niejednokrotnie szeroko omawiana i opisywana.

Cztery zasadnicze obszary objęte tą inicjatywą to:

  • Bezpieczny projekt. Oprogramowanie wymaga projektu, biorącego pod uwagę kwestie bezpieczeństwa jako fundamentu do odpierania ataków i ochrony danych.
  • **Bezpieczna konfiguracja domyślna.**Administratorzy systemu nie powinni być zmuszeni do dokonywania żadnych działań w celu zabezpieczenia nowej instalacji. Powinna być ona zabezpieczona domyślnie.
  • **Bezpieczne wdrożenie.**Oprogramowanie powinno samo dbać o swoje aktualizacje, korzystając z najnowszych poprawek zabezpieczeń oraz wspierając zadania konserwacyjne.
  • Komunikacja. Należy informować użytkowników o najlepszych praktykach i opracowywać informacje o zagrożeniach, aby administratorzy mogli pro aktywnie chronić swoje systemy.

Te wiodące zasady, znajdują odzwierciedlenie w całym systemie SQL Server 2008, który zapewnia wszystkie narzędzia potrzebne do zabezpieczania baz danych.

Niniejszy dokument zawiera omówienie najważniejszych funkcji zabezpieczeń, pomagające w codziennej pracy administratorów systemów oraz baz danych. Rozpoczyna się on od sekcji ilustrujących, jak prosto jest zainstalować i skonfigurować SQL Server 2008 w bezpieczny sposób. Opisuje funkcje uwierzytelniania i autoryzacji, które kontrolują dostęp do serwera i pozwalają określić, co może zrobić użytkownik, gdy już zostanie uwierzytelniony. A na zakończenie prezentuje funkcje zabezpieczeń bazy danych, które administrator powinien zrozumień, aby zapewniać bezpieczne środowisko dla baz danych oraz aplikacji użytkujących dostęp do tych baz danych.

 Do początku strony Do początku strony

Bezpieczna konfiguracja

Pierwszym wymogiem bezpiecznej instalacji SQL Server jest bezpieczne środowisko. Wymagania ochrony zewnętrznej serwera, na którym mają zostać uruchomione usługi SQL Server 2008, które to nie uległy żadnym poważniejszym zmianom. Zalecane jest fizyczne zabezpieczenie serwera i regularne tworzenie kopi zapasowych. Jeśli serwer jest podłączony do sieci, powinno się umieścić go za jedną lub kilkoma zaporami sieciowymi. Należy także unikać instalowania systemu SQL Server na komputerze z innymi aplikacjami serwerowymi oraz uaktywniania zbędnych protokołów sieciowych. Należy zainstalować SQL Server na komputerze działającym pod kontrolą systemu Microsoft Windows Server® 2003 lub Microsoft Windows Server® 2008, aby móc w pełni korzystać z zabezpieczeń na poziomie systemu operacyjnego. Dodatkowo najbezpieczniejsza będzie instalacja na jednej lub kilku partycjach NTFS.

Po zabezpieczeniu środowiska bardzo ważne jest bezpieczne zainstalowanie serwera SQL Server 2008. Program instalacyjny realizuje wszystkie typowe zadania instalacyjne i obejmuje proces sprawdzania konfiguracji systemu, który powiadamia nas o wszystkich brakach mogących być przyczyną potencjalnych problemów. Instalacja SQL Server 2008 nie uaktywnia domyślnie wszystkich funkcji. Instalator uaktywnia tylko niezbędne elementy podstawowe i funkcje najczęściej wykorzystywane. Inne funkcje, które mogą nie być potrzebne w środowisku produkcyjnym, są domyślnie wyłączone. Możemy wykorzystać wspierane narzędzia do włączenia tylko tych funkcji, które są nam potrzebne.

Te wszystkie aspekty wynikają z nakazu projektu Trustworthy Computing, dotyczącego domyślnych zabezpieczeń. Oznacza to, że SQL Server 2008 jest zabezpieczony od razu po instalacji przy użyciu bezpiecznych ustawień domyślnych. Funkcje, które nie są wymagane przez podstawową konfigurację serwera baz danych, pozostają niezainstalowane bądź nieaktywne, w celu zredukowania obszaru podatnego na ataki. Ponieważ domyślnie nie wszystkie funkcje są aktywne we wszystkich systemach, pewien poziom zróżnicowania pomiędzy wdrażanymi instancjami zostaje wprowadzony już na poziomie instalacji. Podejście to ogranicza liczbę systemów, które zawierają funkcje podatne na potencjalne ataki i pomaga obronić się przed zakrojonymi na szeroką skalę atakami lub robakami, wykorzystującymi powszechnie znane luki.

Windows Update

Nowe zagrożenia i luki w zabezpieczeniach mogą zostać odkryte już po wdrożeniu systemu SQL Server w naszej firmie. Funkcja Windows Update została zaprojektowana tak, aby zapewnić pobieranie i instalowanie na bieżąco poprawek, które w dużym stopniu redukują problemy bezpieczeństwa. Możemy wykorzystać funkcję Windows Update do automatycznego stosowania poprawek SQL Server 2008 i redukowania zagrożeń powodowanych przez znane luki w zabezpieczeniach oprogramowania. W większości środowisk korporacyjnych należy wykorzystywać usługę Windows Server Update Service (WSUS) do zarządzania dystrybucją poprawek w celu przeprowadzania aktualizacji oprogramowania wdrożonego w całej organizacji.

Konfiguracja Surface Area

SQL Server 2008 jest przepełniony funkcjami, a wiele z nich jest instalowanych w stanie nieaktywnym. Na przykład integracja CLR, Database Mirroring, debugowanie, Service Broker oraz funkcje poczty są zainstalowane, ale nie działają i nie są dostępne, dopóki nie zostaną bezpośrednio włączone lub skonfigurowane. Takie zachowanie systemu jest zgodne z paradygmatem redukcji obszaru podatnego na ataki, który wpływa na zabezpieczenia domyślne serwera SQL Server. Zgodnie z tą filozofią, jeśli funkcja nie jest dostępna lub włączona, atakujący nie może jej wykorzystać.

Kosztem takiego rozwiązania jest to, że przeszukiwanie wszystkich instrukcji Transact-SQL w celu włączenia wybranych funkcji bywa dość czasochłonne. I nawet, gdy odkryjemy, że systemowa procedura składowana sp_configurerealizuje to, czego potrzebujemy, nadal musimy napisać mało intuicyjny kod, na przykład:

sp_configure ‘show advanced options’, 1      

reconfigure with override

sp_configure ‘clr enabled’, 1

Istnieje stanowczo zbyt wiele opcji konfiguracyjnych, aby poświęcać czas na pisanie tego typu kodu, w szczególności, gdy w naszej organizacji wdrożonych zostało wiele instancji SQL Server. W odpowiedzi na to, SQL Server 2008 zawiera technologię zarządzania w oparciu o zasady Declarative Management Framework (DMF). Technologia DMF udostępnia wiele aspektów konfiguracyjnych (Facet), każdy z nich definiuje zestaw powiązanych ustawień lub właściwości konfiguracyjnych. Możemy wykorzystać te zestawy właściwości do tworzenia warunków (Condition), które określają pożądane ustawienia dla opcji konfiguracyjnych, a następnie wymuszać respektowanie tychże warunków, jako zasad (Policy) na instancjach SQL Server w całej korporacji.

Jednym z zestawów właściwości dołączonych do SQL Server 2008 jest Surface Area. Aspekt ten można wykorzystać do definiowania zasady, która kontroluje stan różnych funkcji SQL Server 2008. Tworząc zasadę, która precyzuje pożądane ustawienia obszaru udostępnionego naszych serwerów, możemy łatwo egzekwować minimalizowanie obszaru podatnego na ataki na wszystkich instancjach SQL Server w organizacji i zredukować prawdopodobieństwo naruszenia bezpieczeństwa danych.

 Do początku strony Do początku strony

Uwierzytelnianie

Firma Microsoft stworzyła SQL Server 2000 w czasie, gdy dane i serwery wymagały ochrony, ale nie musiały przeciwstawiać się bezustannym atakom, które mają obecnie miejsce w Internecie. Podstawowe pytanie uwierzytelniające pozostaje to samo, kim jesteś i jak możesz to udowodnić? Jednak SQL Server 2008 wprowadza dużo bardziej niezawodne funkcje uwierzytelniania, które dostarczają narzędzia pozwalające lepiej kontrolować, kto powinien otrzymać dostęp do danych, a komu należy go stanowczo odmówić.

Uwierzytelnianie SQL Server pozwala na uwierzytelnianie klientów oraz aplikacji spoza systemu Windows przy użyciu prostego łańcucha połączenia, zawierającego identyfikator i hasło użytkownika. Chociaż ten mechanizm logowania jest łatwy w użyciu i popularny wśród twórców aplikacji, nie jest on tak bezpieczny jak uwierzytelnianie systemu Windows i nie stanowi zalecanej metody uwierzytelniania.

SQL Server 2008 poprawia możliwości uwierzytelniania dostępne w rodzinie produktów SQL Server. Po pierwsze domyślnie wspiera szyfrowanie kanału poprzez wykorzystanie certyfikatów generowanych przez SQL Server. Administratorzy nie muszą zdobywać i instalować ważnego certyfikatu SSL, aby upewnić się, że kanał, którym przepływają dane uwierzytelniające SQL, jest bezpieczny. SQL Server 2008 automatycznie generuje te certyfikaty i domyślnie automatycznie szyfruje kanał podczas transmisji pakietu danych, służących do logowania użytkowników. Ma to miejsce, gdy kod kliencki potrafi wykorzystać funkcje serwera w wersji SQL Server 2005 lub wyższej.

Uwaga Wewnętrzny certyfikat generowany przez SQL Server chroni przed pasywnymi atakami „man-in-the-middle”, gdy atakujący aktywnie ingeruje w ruch pakietów w sieci. Aby efektywniej zabezpieczyć swoje systemy przed atakami typu „man-in-the-middle”, należy wdrożyć i wykorzystywać certyfikaty, którym ufają również systemy klienckie.

SQL Server 2008 dodatkowo ulepsza możliwości uwierzytelniania SQL Server, ponieważ obecnie silnik bazy danych wykorzystuje domyślnie zasady grupy systemu Windows regulujące złożoność haseł, ich wygasanie oraz blokowanie konta użytkowników SQL Server, gdy serwer jest wdrożony w oparciu o system operacyjny Windows 2003 lub nowszy. Oznacza to, że możemy wymuszać zasady stosowane wobec haseł Windows na kontach użytkowników SQL Server.

Wymuszanie zasad haseł

W wersji SQL Server 2008 wymuszanie zasad haseł jest wbudowane w serwer. Wykorzystując API NetValidatePasswordPolicy(), które stanowi część biblioteki NetAPI32 w systemie Windows Server 2003, SQL Server sprawdza poprawność hasła podczas uwierzytelniania oraz podczas operacji ustawiania bądź też zmiany hasła, zgodnie z zasadami systemu Windows dotyczącymi długości hasła, wygasania oraz blokad konta. Tabela 1 zawiera ustawienia, z których składają się zasady.

Tabela 1: Komponenty zasad haseł Windows Server 2003.

Jeśli nie działamy na systemie Windows Server 2003 lub nowszym, SQL Server nadal będzie wymuszać stosowanie mocnego hasła, wykorzystując proste sprawdzenia zapobiegające brakom haseł lub hasłom, które są:

  •  Puste (Null)

  •  Takie same jak nazwa komputera lub użytkownika

  •  Równe wartościom „password”, „admin”, „administrator”, „sa”, „sysadmin”

Ten sam standard złożoności odnosi się do wszystkich haseł tworzonych i wykorzystywanych w SQL Server, w tym haseł dla nazwy użytkownika sa, ról aplikacji, kluczy Database Master Key oraz symetrycznych kluczy szyfrowania.

Domyślnie SQL Server zawsze sprawdza zasadę haseł, ale można zawiesić jej egzekwowanie dla wybranych nazw użytkowników przy użyciu instrukcji CREATE LOGIN lub ALTER LOGIN, jak w poniższym fragmencie kodu:

CREATE LOGIN bob WITH PASSWORD = ‘S%V7Vlv3c9Es8’,

CHECK_EXPIRATION = OFF, CHECK_POLICY = OFF

CHECK_EXPIRATION wykorzystuje część zasady Windows Server 2003 dla minimalnego i maksymalnego okresu ważności hasła, a CHECK_POLICY pozwala na wykorzystanie innej, nazwanej zasady.

Ustawienia administracyjne, umożliwiają: włączanie i wyłączanie mechanizmu sprawdzania zasad haseł, włączanie i wyłączanie mechanizmu sprawdzania wygasania haseł oraz wymuszanie zmiany hasła podczas pierwszego logowania się użytkownika. Opcja MUST_CHANGE w instrukcji CREATE LOGIN wymusza na użytkowniku zmianę hasła, gdy zaloguje się on po raz kolejny. Po stronie klienta umożliwia ona zmianę hasła podczas logowania. Wszystkie nowe klienckie technologie dostępu do danych wspierają to podejście, w tym OLE DB oraz ADO.NET, jak również narzędzia klienckie, takie jak Management Studio.

Jeśli użytkownik zbyt wiele razy usiłuje zalogować się bez powodzenia i przekroczy liczbę prób dozwoloną w zasadzie hasła, SQL Server blokuje konto w oparciu o ustawienia zasady systemu Windows. Administrator może odblokować konto przy użyciu instrukcji ALTER LOGIN:

ALTER LOGIN alice WITH PASSWORD = ‘3x1Tq#PO^YIAz’ UNLOCK

Uwierzytelnianie punktu końcowego

SQL Server 2008 wspiera zarówno tradycyjny, binarny protokół dostępu do danych Tabular Data Stream, jak i natywny dostęp za pomocą XML do usług sieci Web przy użyciu protokołu HTTP. Podstawową zaletą zezwolenia na dostęp za pośrednictwem protokołu HTTP jest to, że dowolne oprogramowanie klienckie i narzędzia programistyczne, które wspierają protokoły usługi sieci Web, mogą uzyskać dostęp do danych znajdujących się na serwerze SQL Server. To oznacza, że SQL Server 2008 może oferować niezależne metody usług sieci Web bądź zapewniać działanie punktów końcowych obecnych w architekturze zorientowanej na usługi (SOA).

Wykorzystanie SQL Server 2008 w roli hosta usług sieci Web wymaga podjęcia dwóch wstępnych kroków (przy czym każdy z nich oferuje wiele możliwych wariantów konfiguracyjnych):

  1. zdefiniowania procedur składowanych lub funkcji definiowanych przez użytkownika, które zapewnią metody usług sieci Web

  2. zdefiniowania punktu końcowego HTTP, który odbiera wywołania poszczególnych metod za pośrednictwem protokołu HTTP i kieruje je do odpowiednich procedur.

Niniejszy dokument koncentruje się na kwestiach związanych z bezpieczeństwem. Szczegółowe informacje odnośnie konfigurowania i wykorzystywania punktów końcowych HTTP znaleźć można w artykule CREATE ENDPOINT (Transact-SQL) w witrynie SQL Server Books Online.

Ponieważ usługi sieci Web na serwerze SQL Server wykorzystują protokół HTTP oraz (domyślnie) port 80, większość zapór sieciowych zezwala na przesyłanie generowanych przez nie plików XML. Jednak bezbronny punkt końcowy stanowi potencjalny cel ataków i trzeba go zabezpieczyć, wykorzystując silne uwierzytelnianie oraz autoryzację SQL Server. Domyślnie SQL Server nie posiada żadnych punktów końcowych i trzeba posiadać wysoki poziom uprawnień, aby tworzyć, modyfikować lub włączać punkty końcowe HTTP.

SQL Server 2008 zapewnia pięć różnych typów uwierzytelniania, podobnych do tych wykorzystywanych przez IIS do uwierzytelniania w witrynie sieci Web.

  •  Uwierzytelnianie podstawoweUwierzytelnianie podstawowe stanowi cześć protokołu HTTP 1.1, który przesyła dane logowania w postaci zwykłego tekstu zakodowane algorytmem base-64. Dane uwierzytelniające muszą stanowić tożsamość Windows, którą SQL Server wykorzystuje do autoryzowania dostępu do zasobów bazy danych. Gdy wykorzystujemy uwierzytelnianie podstawowe, nie możemy ustawiać argumentu PORTS na CLEAR, ale zamiast tego musimy nadać mu wartość SSL i użyć certyfikatu cyfrowego SSL do szyfrowania komunikacji z oprogramowaniem klienckim.

  •  Uwierzytelnienie szyfrowaneUwierzytelnienie szyfrowane również stanowi cześć protokołu HTTP 1.1. Wiąże się ono z zastosowaniem na danych uwierzytelniających algorytmu mieszania MD5 przed wysłaniem ich na serwer, a zatem nie są one wysyłane wcale, nawet w postaci zaszyfrowanej. Dane uwierzytelniające muszą stanowić poprawne konto domenowe systemu Windows. Nie można użyć lokalnych kont użytkowników.

  •  Uwierzytelnianie NTLMUwierzytelnianie NTLM wykorzystuje protokół Challenge-Response wprowadzony pierwotnie w systemie Microsoft Windows NT® i od tej pory wspierany na wszystkich klienckich i serwerowych wersjach systemu Windows. Zapewnia ono bezpieczne uwierzytelnianie, gdy zarówno klient, jak i serwer to systemy z rodziny Windows, wymaga także prawidłowego konta w domenie Windows.

  •  Uwierzytelnianie KerberosUwierzytelnianie Kerberos jest dostępne w systemach Windows 2000 oraz późniejszych i bazuje na protokole standardu przemysłowego dostępnym w wielu różnych systemach operacyjnych. Umożliwia on uwierzytelnianie wzajemne, w którym zarówno klient, jak i serwer mają pewność, co do tożsamości drugiej strony, co stanowi wysoce bezpieczną formę uwierzytelniania. Aby wykorzystywać protokół Kerberos w systemie Windows Server 2003, trzeba zarejestrować główną nazwę usługi (SPN) w Http.sys, wykorzystując narzędzie SetSPN.exe, które stanowi element zestawu narzędzi obsługi systemu Windows.

  •  Uwierzytelnianie zintegrowaneUwierzytelnianie zintegrowane korzysta z zalet uwierzytelniania NTLM oraz Kerberos. Serwer używa tego z dwóch typów uwierzytelnień, którego zażąda klient, umożliwiając dokonanie najbezpieczniejszego uwierzytelniania wspieranego przez klienta, zachowując jednocześnie dostępność usług w starszych wersjach systemu Windows. Można skonfigurować Http.sys w systemie Windows 2003 tak, aby ustaliło ono z oprogramowaniem klienckim, który protokół powinien zostać wykorzystany.

Metoda uwierzytelniania stosowana w punkcie końcowym jest ustawiana przy pomocy atrybutu AUTHENTICATION instrukcji CREATE lub ALTER ENDPOINT. Na przykład następujący kod pozwala stworzyć punkt końcowy, który wykorzystuje uwierzytelnianie Kerberos:

CREATE ENDPOINT myEndpoint

STATE=STARTED

      AS HTTP (PATH = ‘/MyHttpEndpoint’,

      AUTHENTICATION = (KERBEROS),

      PORTS = (CLEAR),

      SITE = ‘MySqlServer’)

FOR SOAP (WSDL = DEFAULT,

      DATABASE = ‘myDB’,

      NAMESPACE = ‘http://example.com/MySqlServer/myDB/WebService’)

SQL Server 2008 wspiera punkty końcowe, które nasłuchują zarówno ruch HTTP, jak i ruch na zdefiniowanym przez użytkownika porcie TCP. Możemy również nadawać żądaniom różne formaty: SOAP, Transact-SQL, format charakterystyczny dla usługi Service Broker oraz inny, wykorzystywany w rozwiązaniach Database Mirroring. Gdy korzystamy z protokołu SOAP, w procesie uwierzytelniania możemy użyć nagłówków WS-Security do przesłania danych logowania SQL Server.

Firma Microsoft zaimplementowała uwierzytelnianie punktu końcowego usług sieci Web z myślą o wspieraniu szerokiego zakresu protokołów i specyfikacji, a niniejszy dokument wspomniał tylko o niektórych z nich. Należy zapamiętać, iż będziemy musieli bezpośrednio włączyć odpowiednią opcję uwierzytelniania i upewnić się, że klienci mogą dostarczyć wymagany typ danych uwierzytelniających. Po uwierzytelnieniu klienta przez SQL Server możemy określić, do których zasobów poszczególni użytkownicy mają autoryzowany dostęp, co zostanie opisane w kolejnej sekcji.

 Do początku strony Do początku strony

Autoryzacja

Po uwierzytelnieniu nadchodzi czas na zastanowienie się, jakie operacje może wykonywać uwierzytelniony podmiot. W tym obszarze wersje SQL Server 2008 oraz SQL Server 2005 są bardziej elastyczne niż wersje wcześniejsze. Uprawnienia są obecnie dużo bardziej szczegółowe, a więc można przyznawać specyficzne, wymagane uprawnienia zamiast wykorzystywać model członkowstwa w stałej roli, która prawdopodobnie obejmuje więcej uprawnień niż to konieczne. Aktualnie mamy do dyspozycji dużo więcej obiektów zabezpieczanych, którym możemy przypisywać bardziej szczegółowe uprawnienia.

Poza ulepszoną ochroną danych użytkownika, informacje o strukturze i metadane dotyczące określonego obiektu zabezpieczanego są teraz dostępne tylko dla podmiotów, które posiadają uprawnienia dostępu do tego obiektu.

Co więcej, możliwe jest tworzenie niestandardowych zestawów uprawnień przy użyciu mechanizmu pozwalającego na definiowanie kontekstu zabezpieczeń, w którym mogą być uruchamiane procedury składowane.

Ponadto SQL Agent wykorzystuje elastyczny schemat Proxy, aby zezwalać zadaniom na uruchamianie i uzyskiwanie dostępu do wymaganych zasobów. Wszystkie te funkcje sprawiają, że SQL Server jest bardziej złożony, ale i dużo bezpieczniejszy.

Uprawnienia szczegółowe

Jednym z wielu aspektów, które czynią SQL Server 2008 oraz SQL Server 2005 dużo bezpieczniejszymi niż wcześniejsze wersje jest zwiększona szczegółowość uprawnień. Dawniej administratorzy musieli wykorzystywać model członkostwa, przypisując użytkownika do stałej roli serwerowej lub bazodanowej, dzięki czemu mógł on realizować określone operacje. Jednak bardzo często role te obejmowały zbyt szerokie uprawnienia w odniesieniu do prostych zadań. Przypisywanie użytkownikom szerokich uprawnień do realizacji wąskich celów stanowiło naruszenie reguły najmniejszych uprawnień, która mówi, że użytkownik powinien mieć jedynie minimum uprawnień koniecznych do wykonania pracy.

Zestaw stałych ról serwerowych oraz bazodanowych pozostał w dużej mierze niezmieniony już od wersji SQL Server 2000, a więc nadal możemy wykorzystywać predefiniowane powiązania uprawnień, gdy użytkownicy lub aplikacje wymagają wszystkich lub większości zdefiniowanych uprawnień. Prawdopodobnie największą zmianę stanowiło dodanie roli serwerowej public. Jednak zasada najmniejszych uprawnień odradza wykorzystywanie tej roli, gdy nie pasuje ona idealnie do potrzeb podmiotu związanych z realizacją zadania. Chociaż określenie i przypisanie wymagań niezbędnych podmiotowi wymaga pewnego nakładu pracy, prawidłowa konfiguracja uprawnień może zaowocować dużo bezpieczniejszym środowiskiem bazodanowym.

Podmioty i obiekty zabezpieczane

Na serwerze SQL Server 2008 podmiotem może być jednostka, grupa lub proces, który może zażądać dostępu do chronionych zasobów i któremu można przyznać uprawnienia dostępu do nich. Podobnie jak w poprzednich wersjach SQL Server, możemy definiować podmiot w systemie Windows lub bazować na danych logowania SQL Server bez odpowiadającego im podmiotu Windows. Następująca lista prezentuje hierarchię podmiotów SQL Server 2008 (z wyłączeniem stałych ról serwerowych i bazodanowych) i pokazuje, w jaki sposób możemy mapować dane logowania oraz użytkowników bazy danych na obiekty zabezpieczane. Zasięg wpływu podmiotu zależy od zakresu jego definicji, a więc podmioty na poziomie systemu Windows mają szerszy zasięg niż podmioty na poziomie SQL Server, które z kolei mają większy zasięg niż podmioty na poziomie bazy danych. Każdy użytkownik bazy danych automatycznie dołączany jest do stałej roli public.

Podmioty na poziomie systemu Windows

  •  Użytkownik domeny Windows

  •  Użytkownik lokalny Windows

  •  Grupa Windows

Podmioty na poziomie SQL Server

  •  Dane logowania w programie SQL Server

  •  Dane logowania w programie SQL Server mapowane na tożsamość Windows

  •  Dane logowania w programie SQL Server mapowane na certyfikat

  •  Dane logowania w programie SQL Server mapowane na klucz asymetryczny

Podmioty na poziomie bazy danych

  •  Użytkownik bazy danych

  •  Użytkownik bazy danych mapowany na dane logowania SQL Server

  •  Użytkownik bazy danych mapowany na tożsamość Windows

  •  Użytkownik bazy danych mapowany na certyfikat

  •  Użytkownik bazy danych mapowany na klucz asymetryczny

  •  Rola bazodanowa

  •  Rola aplikacji

  •  Rola Public

Innym składnikiem autoryzacji są obiekty, które można zabezpieczać poprzez przyznawanie i odmawianie uprawnień. Rysunek 1 prezentuje hierarchię obiektów zabezpieczanych w SQL Server 2008. Na poziomie serwera możemy zabezpieczać punkty końcowe sieci, aby kontrolować kanały komunikacji serwera ze światem zewnętrznym, jak również bazy danych, powiązania i role oraz dane logowania. Na poziomie baz danych oraz schematów praktycznie wszystkie obiekty, jakie możemy utworzyć, umożliwiają odpowiednie konfigurowanie zabezpieczeń, także te znajdujące się w poniższym schemacie.

Rysunek 1: Hierarchia obiektów zabezpieczanych w SQL Server 2008.

Role i uprawnienia

Aby uświadomić sobie liczbę uprawnień dostępnych w SQL Server, warto wywołać funkcję systemową fn_builtin_permissions:

SELECT * FROM sys.fn_builtin_permissions(default)

Oto nowe typy uprawnień dostępne w SQL Server 2005:

  •  CONTROL. Przyznaje uprawnienia podobne do własności, co w rzeczywistości wiąże się z przyznaniem wszystkich zdefiniowanych uprawnień do obiektu i wszystkich obiektów w jego zakresie, w tym możliwości przyznawania innym podmiotom dowolnych uprawnień. CONTROL SERVER stanowi ekwiwalent uprawnień sysadmin.

  •  ALTER. Przyznaje uprawnienie do modyfikowania dowolnych właściwości obiektów zabezpieczanych, poza zmianą właściciela. W gruncie rzeczy przyznaje uprawnienia ALTER, CREATE lub DROP do obiektów zabezpieczanych w danym zakresie. Na przykład przyznanie uprawnienia ALTER w bazie danych uwzględnia prawo do modyfikowania jej tabel.

  •  ALTER ANY . Przyznaje uprawnienie do modyfikowania dowolnych obiektów zabezpieczanych określonego typu. Na przykład przyznanie uprawnienia ALTER ANY ASSEMBLY umożliwia modyfikowanie dowolnego zestawu.NET w bazie danych, natomiast przyznanie uprawnienia ALTER ANY LOGIN na poziomie serwera, pozwala użytkownikowi modyfikować dowolne dane logowania na tym serwerze.

  •  IMPERSONATE ON . Przyznaje uprawnienie personifikowania określonego użytkownika Windows lub SQL Server. Jak będziemy mogli się przekonać w dalszej części niniejszego artykułu, uprawnienie to jest niezbędne do przełączania kontekstów wykonania procedur składowanych. Uprawnienie to jest potrzebne również w przypadku dokonywania personifikacji dla operacji wykonywanych w trybie wsadowym.

  •  TAKE OWNERSHIP. Przyznaje uprawnienie, które pozwala podmiotowi przejmować na własność obiekt zabezpieczany przy użyciu instrukcji ALTER AUTHORIZATION.

SQL Server 2008 nadal wykorzystuje znany schemat GRANT, DENY oraz REVOKE do przypisywania lub odmawiania podmiotowi uprawnień do obiektu zabezpieczanego. Instrukcja GRANT obejmuje obecnie wszystkie nowe opcje uprawnień, takie jak zakres oraz to czy podmiot uprawniony może przyznawać uprawnienie innym podmiotom. SQL Server nie zezwala na stosowanie uprawnień pomiędzy bazami danych. Aby przyznać tego typu uprawnienie, musimy stworzyć zduplikowanego użytkownika w każdej bazie danych i przyznać użytkownikowi uprawnienie w każdej bazie danych z osobna.

Podobnie jak we wcześniejszych wersjach SQL Server, aktywacja którejkolwiek z ról aplikacji zawiesza pozostałe uprawnienia na czas aktywności roli. Jednak w SQL Server 2008 oraz SQL Server 2005 mamy możliwość zmiany roli aplikacji. Inną różnicą między SQL Server 2000, a późniejszymi wersjami jest to, że w przypadku aktywowania roli aplikacji rola ta zawiesza również wszystkie uprawnienia serwerowe, w tym przynależność do roli public . Na przykład, jeśli przyznamy uprawnienie VIEW ANY DEFINITION roli public, rola aplikacji nie będzie go honorować. Jest to najbardziej zauważalne podczas dostępu do metadanych na poziomie serwera w kontekście roli aplikacji.

Uwaga Nową, rekomendowaną alternatywą dla ról aplikacji jest zastosowanie kontekstu wykonania w modułach kodu. Więcej informacji na ten temat zawiera część niniejszego dokumentu zatytułowana Kontekst wykonania.

Przyznanie określonego uprawnienia może w konsekwencji wiązać się z przypisaniem również innych uprawnień. Na przykład uprawnienie ALTER dla schematu „pokrywa” bardziej szczegółowe uprawnienia na niższym poziomie, które są „implikowane.” Rysunek 2 prezentuje implikowane uprawnienia dla ALTER SCHEMA. Artykuł Covering/Implied Permissions (Database Engine) w witrynie SQL Server Books Online zawiera kod Transact-SQL dla definiowanej przez użytkownika funkcji ImplyingPermissions, która buduje listę hierarchii na podstawie widoku katalogowego sys.fn_builtin_permissions i identyfikuje głębokość każdego z uprawnień w hierarchii. Po dodaniu funkcji ImplyingPermissions do bazy danych master wykonaliśmy poniższą instrukcję, przekazując do niej obiekt i typ uprawnienia. Efekt widzimy na Rysunku 2:

SELECT * FROM master.dbo.ImplyingPermissions(‘schema’, ‘alter’)

ORDER BY height, rank

Jest to świetny sposób, aby zapoznać się z hierarchią uprawnień w SQL Server 2008.

Rysunek 2: Hierarchia zaimplementowanych uprawnień ALTER SCHEMA.

Gdy weźmiemy pod uwagę liczbę i typy dostępnych podmiotów, liczbę zabezpieczanych obiektów typowego serwera i bazy danych, a także wysoką liczbę dostępnych uprawnień oraz uprawnień „pokrytych” i implikowanych, szybko uświadomimy sobie, jak szczegółowe mogą być uprawnienia w SQL Server 2008. Tworzenie bazy danych wymaga obecnie bardziej wnikliwej analizy wymagań dotyczących zabezpieczeń i czujnej kontroli nad uprawnieniami definiowanymi dla każdego z obiektów. Pomimo tego warto przeprowadzić tę analizę, ponieważ odpowiednie zastosowanie możliwości SQL Server 2008 owocuje lepiej zabezpieczonymi bazami danych.

Bezpieczeństwo metadanych

Jedną z zalet szczegółowego schematu uprawnień jest to, że SQL Server chroni nie tylko dane, ale i metadane. W wersjach wcześniejszych niż SQL Server 2005, użytkownik, który mógł uzyskać dostęp do bazy danych, mógł przeglądać metadane wszystkich, znajdujących się w niej obiektów, niezależnie od tego czy posiadał on prawo dostępu do danych lub wykonywania procedur składowanych.

SQL Server 2008 sprawdza uprawnienia podmiotu w bazie danych i ujawnia metadane obiektu tylko wtedy, gdy podmiot jest jego właścicielem lub posiada do niego odpowiednie uprawnienia. Istnieje również uprawnienie VIEW DEFINITION, które pozwala przyznać prawo do wyświetlania informacji metadanych bez konieczności posiadania innych uprawnień do obiektu.

To zabezpieczenie wpływa także na komunikaty o błędach, zwracane w wyniku wykonania operacji dostępu lub aktualizacji obiektu, do którego użytkownik nie ma uprawnień. Zamiast potwierdzać, iż faktycznie istnieje tabela o nazwie Address i udzielać atakującemu wskazówki, że jest on na właściwym tropie, SQL Server zwraca komunikat o błędzie z alternatywnymi scenariuszami. Na przykład, jeśli użytkownik, który nie posiada żadnych uprawnień do żadnego z obiektów bazy danych, będzie usiłował usunąć tabelę Address, SQL Server wyświetli następujący komunikat o błędzie:

Msg 3701, Level 14, State 20, Line 1

Cannot drop the table ‘Address’, because it does not exist or you do not have permission.

W ten sposób atakujący nie uzyska potwierdzenia, czy tabela Address istnieje naprawdę. A jednocześnie osoba próbująca rozwiązać problemy w działaniu aplikacji ma jedynie ograniczoną liczbę możliwości do przeanalizowania.

Proxy SQL Server Agent

Jednym z najlepszych przykładów modelu autoryzacji w SQL Server 2008 jest SQL Server Agent. Możemy definiować różne dane uwierzytelniające, które są często powiązane z tożsamościami Windows, połączonymi z użytkownikami o odpowiednich uprawnieniach do realizowania jednego lub więcej kroków zadań, zdefiniowanych przy pomocy SQL Server Agent. Następnie Proxy SQL Server Agent łączy dane uwierzytelniające z każdym z kroków danego zadania w celu dostarczenia niezbędnych uprawnień.

To pozwala na atomowość udzielania uprawnień zgodną z zasadą stosowania najniższego poziomu uprawnień: należy przyznać krokowi danego zadania jedynie te uprawienia, które są mu niezbędne. Możemy tworzyć tyle kont proxy, ile tylko zechcemy, powiązując każde z nich z jednym lub kilkoma podsystemami SQL Server Agent. To diametralna zmiana w porównaniu z szeroko uprawnionym kontem proxy w SQL Server 2000, które umożliwiało użytkownikowi tworzenie kroków zadania w dowolnym podsystemie SQL Server Agent.

Uwaga: Gdy aktualizujemy serwer z wersji SQL Server 2000 do nowszej, tworzone jest pojedyncze konto proxy i do tego konta przypisywane są wszystkie podsystemy, aby istniejące zadania mogły kontynuować działanie. Po aktualizacji należy stworzyć dane uwierzytelniające i konta proxy tak, aby zaimplementować bezpieczniejszy, bardziej szczegółowy zestaw proxy w celu zabezpieczenia zasobów serwera.

Rysunek 3 pokazuje okno Object Explorer w Management Studio, które zawiera listę podsystemów, dostępnych w usłudze SQL Server Agent. Każdemu podsystemowi jest przypisane jedno lub więcej proxy, które przyznają odpowiednie uprawnienia do realizacji kroku zadania. Wyjątkiem od tego schematu są podsystemy Transact-SQL, które wykorzystują uprawnienia właściciela modułu, podobnie jak w SQL Server 2000.

Podsystemy SQL Server Agent, które możemy powiązać z proxy

Rysunek 3: Podsystemy SQL Server Agent, które możemy powiązać z proxy.

W świeżej instalacji SQL Server tylko rola System Administrator posiada uprawnienie do zarządzania zadaniami SQL Server Agent, a panel zarządzania w Management Studio Object Explorer jest dostępny jedynie dla członków roli sysadmins. SQL Server 2008 udostępnia kilka innych ról, które można wykorzystać do przyznawania różnych poziomów uprawnień. Możemy przypisywać użytkownikom role SQLAgentUser, SQLAgentReaderRolelub SQLAgentOperator, z których każda kolejna gwarantuje większy poziom uprawnień do tworzenia, zarządzania i uruchamiania zadań, a także rolę MaintenanceUser, która zawiera wszystkie uprawnienia roli SQLAgentUser plus możliwość tworzenia planów konserwacji.

Oczywiście członkowie roli sysadmin mogą wykonywać dowolne operacje w każdym z podsystemów. Przyznanie uprawnień do wykorzystywania podsystemów jakiemukolwiek użytkownikowi, wymaga stworzenia przynajmniej jednego konta proxy, które przyznaje prawa do jednego lub więcej podsystemów. Rysunek 4 pokazuje, w jaki sposób konto proxy MyProxy jest przypisywane do wielu podmiotów, w tym przypadku użytkownika i roli. Konto proxy wykorzystuje dane uwierzytelniające, które powiązują je z kontem, zazwyczaj domenowym, posiadającym uprawnienia w systemie operacyjnym, niezbędne do realizowania wszelkich zadań wymaganych przez podsystem. Każde proxy może być powiązane z jednym lub wieloma podsystemami, co zapewnia podmiotowi możliwość uruchamiania tych podsystemów.

Konto proxy SQL Server Agent dla różnych podsystemów

Rysunek 4: Konto proxy SQL Server Agent dla różnych podsystemów.

Następujący fragment kodu zawiera kod Transact-SQL potrzebny do zaimplementowania schematu pokazanego na Rysunku 4. Kod rozpoczyna się od stworzenia danych uwierzytelniających, obiektu bazodanowego, który zapewnia połączenie z kontem systemu operacyjnego, posiadającym uprawnienia do realizowania pożądanych akcji w podsystemach. Dodane zostaje konto proxy o nazwie MyProxy, które stanowi po prostu przyjazną nazwę danych uwierzytelniających. Następnie konto proxy zostaje powiązane z dwoma podmiotami, w tym przypadku danymi logowania SQL Server oraz niestandardową rolą. Na zakończenie proxy zostaje powiązane z każdym z czterech podsystemów SQL Server Agent.

CREATE CREDENTIAL MyCredential WITH IDENTITY = ‘MyDOMAIN\user1’

GO

msdb..sp_add_proxy @proxy_name = ‘MyProxy’,

@credential_name = ‘MyCredential’

GO

msdb..sp_grant_login_to_proxy @login_name = ‘MyLogin’,

@proxy_name = ‘MyProxy’

GO

msdb..sp_grant_login_to_proxy @login_name = ‘MyRole’,

@proxy_name = ‘MyProxy’

GO

sp_grant_proxy_to_subsystem @proxy_name = ‘MyProxy’,

@subsystem_name = ‘ActiveScripting’

GO

sp_grant_proxy_to_subsystem @proxy_name = ‘MyProxy’,

@subsystem_name = ‘CmdExec’

GO

sp_grant_proxy_to_subsystem @proxy_name = ‘MyProxy’,

@subsystem_name = ‘ANALYSISQUERY’

GO

sp_grant_proxy_to_subsystem @proxy_name = ‘MyProxy’,

@subsystem_name = ‘DTS’

GO

SQL Server Management Studio zapewnia pełne wsparcie dla tworzenia danych uwierzytelniających oraz kont proxy, jak pokazano na Rysunku 5. Efektem będzie wygenerowanie takiego samego proxy, jak to stworzone przy użyciu zaprezentowanego powyżej kodu.

Nowe proxy SQL Server Agent w SQL Server Management Studio

Rysunek 5: Nowe proxy SQL Server Agent w SQL Server Management Studio.

Proxy nie stanowi sposobu omijania zabezpieczeń systemu operacyjnego. Jeśli dane uwierzytelniające zastosowane w proxy nie gwarantują uprawnień w systemie Windows, takich jak np. uprawnianie do zapisu w katalogu udziału sieciowego, konto proxy również nie będzie ich posiadało. Możemy również wykorzystać proxy do ograniczenia praw wykonywania procedury xp_cmdshell, ponieważ stanowi ona ulubione narzędzie wykorzystywane przez atakujących do przejmowania innych maszyn w sieci, gdy już uda im się włamać na komputer SQL Server. Proxy zapewnia tę ochronę, ponieważ nawet, gdy podmiot posiada nieograniczone prawa w sieci np. jest administratorem domeny, wszelkie polecenia wykonywane za pośrednictwem Proxy, mają jedynie ograniczone uprawnienia konta danych uwierzytelniających.

Kontekst wykonania

SQL Server od dawna wspiera koncepcję łańcucha własności, jako sposobu zapewniania, że administratorzy oraz programiści aplikacji mają możliwość sprawdzania uprawnień z góry w momencie wejścia do bazy danych i nie muszą potwierdzać uprawnień do wszystkich obiektów, do których uzyskiwany jest dostęp. Jeśli użytkownik wywołujący moduł (procedurę składowaną lub funkcję) bądź widok posiada uprawnienie do wykonania tego modułu lub uprawnienie select do widoku oraz właściciel modułu lub widoku jest właścicielem obiektów, do których uzyskiwany jest dostęp (łańcuch własności), nie są sprawdzane żadne uprawnienia do wewnętrznych obiektów, a wywołujący otrzymuje żądane dane.

Jeśli łańcuch własności zostaje rozerwany, ponieważ właściciel kodu nie jest właścicielem obiektu, do którego się odwołuje, SQL Server sprawdza uprawnienia z wykorzystaniem kontekstu zabezpieczeń podmiotu wywołującego. Jeśli podmiot wywołujący posiada prawo dostępu do obiektu, SQL Server zwraca dane. Jeśli nie, SQL Server zgłasza błąd.

Łańcuch własności posiada pewne ograniczenia. Ma zastosowanie jedynie w odniesieniu do operacji przetwarzania danych, ale nie jest wykorzystywany w przypadku dynamicznego kodu SQL. Co więcej, gdy uzyskujemy dostęp do obiektów, należących do różnych właścicieli, zastosowanie łańcucha własności nie jest możliwe. Skutkiem tego, mechanizm sprawdzania uprawnień z góry sprawdza się tylko w pewnych sytuacjach.

SQL Server 2008 oferuje możliwość oznaczania modułów przy pomocy kontekstów wykonania, aby instrukcje w module mogły być wykonywane w kontekście określonego użytkownika zamiast w kontekście użytkownika wywołującego. W ten sposób, chociaż użytkownik wywołujący nadal potrzebuje uprawnień do wykonania modułu, SQL Server sprawdza uprawnienia do wykonania znajdujących się w nim instrukcji przy użyciu kontekstu wywołania modułu. Możemy posłużyć się tym mechanizmem, aby pokonać pewne ograniczenia w stosowaniu łańcucha własności, ponieważ rozwiązanie to obejmuje wszystkie instrukcje w module. Administratorzy, którzy chcą dokonywać sprawdzenia uprawnień z góry, mogą wykorzystywać do tego celu kontekst wykonania.

Obecnie podczas tworzenia funkcji definiowanych przez użytkownika (poza funkcjami tabelarycznymi typu inline), procedur składowanych oraz wyzwalaczy, możemy wykorzystać klauzulę EXECUTE AS w celu określenia użytkownika, którego uprawnienia mają być wykorzystywane przez SQL Server do sprawdzania praw dostępu do obiektów oraz danych, do których odwołuje się procedura:

CREATE PROCEDURE GetData(@Table varchar(40))

WITH EXECUTE AS ‘User1’

SQL Server 2008 oferuje cztery opcje EXECUTE AS.

  •   EXECUTE AS CALLER sprawia, że kod wykonywany jest w kontekście zabezpieczeń podmiotu wywołującego moduł, żadna personifikacja nie ma miejsca. Podmiot wywołujący musi posiadać uprawnienia dostępu do wszystkich wykorzystywanych obiektów. Jednak SQL Server sprawdza uprawnienia jedynie dla przerwanych łańcuchów własności. A zatem, jeśli właściciel kodu jest również właścicielem wykorzystywanych obiektów, sprawdzane jest jedynie uprawnienie do wykonywania modułu. Jest to domyślny kontekst zabezpieczeń, służący do zachowania zgodności z poprzednimi wersjami.

  •   **EXECUTE AS ‘nazwa_użytkownika’**sprawia, że kod wykonywany jest w kontekście zabezpieczeń określonego użytkownika. Opcja ta jest bardzo przydatna, gdy nie chcemy polegać na łańcuchu własności. Zamiast tego tworzymy użytkownika z uprawnieniami niezbędnymi do uruchamiania kodu oraz niestandardowe zestawy uprawnień.

  •   EXECUTE AS SELF stanowi skróconą notację określającą kontekst zabezpieczeń użytkownika, który tworzy lub modyfikuje moduł. SQL Server wewnętrznie zapisuje rzeczywistą nazwę użytkownika powiązanego z modułem, w miejsce „SELF.”

  •   EXECUTE AS OWNER sprawia, że kontekstem zabezpieczeń jest kontekst aktualnego właściciela modułu w czasie jego wykonywania. Jeśli moduł nie posiada właściciela, wykorzystywany jest kontekst właściciela schematu, w którym znajduje się moduł. Opcja ta jest bardzo przydatna, gdy chcemy mieć możliwość dokonania zmiany właściciela modułu bez modyfikowania samego modułu.

Za każdym razem, gdy kontekst użytkownika jest zmieniany przy pomocy opcji EXECUTE AS, twórca lub modyfikator modułu musi posiadać uprawnienia IMPERSONATE dla wybranego użytkownika. Co więcej, nie możemy usunąć określonego użytkownika z bazy danych, dopóki nie zmienimy kontekstu wykonania wszystkich modułów przy użyciu danych innych użytkowników.

Rozdzielenie użytkownika i schematu

W SQL Server 2000 nie istniała taka koncepcja jak schemat, który specyfikacja ANSI SQL-99 definiuje, jako kolekcję obiektów bazodanowych, których właścicielem jest pojedynczy podmiot, kształtujący pojedynczą przestrzeń nazw obiektów. Schemat stanowi zbiornik obiektów bazodanowych, takich jak tabele, widoki, procedury składowane, funkcje, typy i wyzwalacze. Pełniona przez niego funkcja przypomina rolę przestrzeni nazw w.NET Framework czy technologii XML. Stanowi on sposób grupowania obiektów tak, aby baza danych mogła wielokrotnie wykorzystywać nazwy obiektów, umożliwiając na przykład przechowywanie w tej samej bazie danych obiektów dbo.Customer oraz Fred.Customer. Ponadto pozwala grupować obiekty według ich właścicieli.

Uwaga: Będziemy potrzebowali widoków katalogowych, takich jak sys.database_sys.principals, sys.schemas, sys.objects itp. Wynika to z faktu, że stara systemowa tabela sysobjects nie wspierała schematów i dlatego nie mogła wspierać rozdzielenia użytkowników oraz schematów. Poza tym stare widoki katalogowe zostały oznaczone, jako przestarzałe (ang. deprecated), więc zostaną usunięte z przyszłej wersji SQL Server.

Górna część Rysunku 6 prezentuje, w jaki sposób schematy działały w wersji SQL Server 2000. Gdy administrator tworzył użytkownika Alice w bazie danych, SQL Server automatycznie tworzył schemat Alice, który krył się za użytkownikiem Alice. Gdy Alice, nie będąc właścicielem bazy danych, logowała się na serwerze, na którym działa SQL Server i tworzyła obiekt Table1, właściwa nazwa tabeli brzmiała Alice.Table1. To samo odnosiło się do innych obiektów tworzonych przez Alice, takich jak Alice.StoredProcedure1 czy Alice.View1. Natomiast, gdyby Alice była właścicielem bazy danych lub sysadmin, obiekty przez nią tworzone, stanowiłyby część schematu dbo. Chociaż zwykle mawiało się, że dbo byłby właścicielem obiektów, ale prowadzi to do tego samego.

Użytkownik/schemat/obiekty w SQL Server 2000 oraz 2008

Rysunek 6: Użytkownik/schemat/obiekty w SQL Server 2000 oraz 2008.

Problem wynikający ze scalenia użytkowników oraz schematów w SQL Server 2000 ujawnia się, gdy chcemy zmienić właściciela obiektów np. wtedy, gdy Alice opuszcza firmę i Lucinda przejmuje jej obowiązki. W takiej sytuacji administrator systemu musi zmienić właściciela we wszystkich obiektach, będących w posiadaniu Alice. Dodatkowym problemem jest konieczność zmodyfikowania wszystkich fragmentów kodu Transact-SQL lub aplikacji klienckich tak, aby odwołania Alice.Table1 zostały zastąpione odwołaniami Lucinda.Table1, po tym jak Lucinda przejmie własność nad tabelą. Skala tego przedsięwzięcia może być niemała, w zależności od liczby obiektów będących w posiadaniu Alice oraz od tego, w jakiej ilości aplikacji wbudowana została ta nazwa. Firma Microsoft od dawna zaleca, aby w celu ominięcia tych problemów czynić wbudowanego użytkownika dbo właścicielem wszystkich obiektów bazodanowych. Dużo łatwiej jest zmienić właściciela bazy danych niż zmienić wiele obiektów i aplikacji klienckich.

Uwaga: Instrukcja SQL Server 2000 CREATE SCHEMA może być nieco myląca. Jednak należy mieć świadomość, że stanowi ona jedynie prostą metodę tworzenia tabel i widoków, znajdujących się w posiadaniu określonego użytkownika oraz przyznania uprawnień. Mogliśmy wykorzystywać tę instrukcję do nazywania właściciela schematu, ale nie samego schematu. SQL Server 2000 nadal nieodwołalnie łączy właściciela ze schematem, co prowadzi do wszystkich problemów związanych ze zmianą własności.

SQL Server 2008 porządkuje tę kwestię i implementuje schemat SQL-99, rozdzielając użytkownika od schematu, jak pokazano w dolnej części Rysunku 9. Gdy tworzymy nowego użytkownika Alice, przy pomocy nowej instrukcji DDL CREATE USER, SQL Server nie tworzy już automatycznie schematu o tej samej nazwie. Zamiast tego musimy bezpośrednio stworzyć schemat i przypisać jego własność użytkownikowi. Ponieważ wszystkie pokazane obiekty bazodanowe, znajdują się obecnie w schemacie Schema1, będącym początkowo w posiadaniu Alice, łatwo można przenieść własność wszystkich obiektów schematu, zmieniając po prostu właściciela schematu na Lucinda. Do każdego użytkownika może również zostać przypisany schemat domyślny - SQL Server przyjmuje założenie, że wszystkie odwołania do obiektów z użyciem nazwy niezawierającej odwołania do schematu, dotyczą obiektów znajdujących się w schemacie domyślnym. W odniesieniu do Rysunku 9, jeśli Alice posiada Schema1 jako schemat domyślny, może odwoływać się do tabeli jako Schema1.Table1 lub po prostu Table1. Użytkownik Carol, z którego nazwą nie został powiązany żaden schemat domyślny, musiałby odwoływać się do tabeli jako Schema1.Table1. Do każdego użytkownika bez zdefiniowanego schematu domyślnego, domyślne przypisany jest schemat dbo.

W pełni kwalifikowane nazwy obiektów na serwerze SQL Server 2008 zawierają strukturę czteroczęściową, podobną do tej stosowanej w poprzednich wersjach SQL Server:

server.database.schema.object

Tak jak we wcześniejszych wersjach, możemy ominąć nazwę serwera, jeśli obiekt znajduje się na tym samym serwerze, na którym uruchomiony jest kod. Możemy ominąć nazwę bazy danych, jeśli nazwa ta została podana podczas tworzenia połączenia oraz możemy ominąć nazwę schematu, jeśli jest to schemat domyślny aktualnego użytkownika lub dbo, ponieważ jest to schemat ostatniej szansy, przy pomocy którego, SQL Server próbuje ujednoznacznić nazwę obiektu.

Do tworzenia nowych użytkowników należy wykorzystywać instrukcję CREATE USER, zamiast procedury sp_adduser. Ta systemowa procedura składowana nadal występuje w celu zachowania zgodności z poprzednimi wersjami i została odrobinę zmieniona, by odwzorować rozdzielenie użytkowników i schematów. Procedura sp_adduser tworzy schemat o tej samej nazwie, co nazwa użytkownika lub rola aplikacji i przypisuje ten schemat użytkownikowi jako schemat domyślny. W ten sposób naśladowane jest zachowanie SQL Server 2000, ale dostarczany jest osobny schemat.

Uwaga Wykorzystanie instrukcji ALTER AUTHORIZATION może doprowadzić do sytuacji, kiedy osoba1 jest właścicielem w schemacie osoba2. To pociąga za sobą pewne poważne konsekwencje. Na przykład, kto jest właścicielem wyzwalacza na tabeli, osoba1 czy osoba2? Wniosek jest taki, że obecnie określenie prawdziwego właściciela obiektu lub typu o zakresie schematu może przysparzać sporych trudności. Istnieją dwa sposoby radzenia sobie z tą kwestią:

  1. Zastosowanie funkcji OBJECTPROPERTY(id, ‘OwnerId’) w celu wykrycia prawdziwego właściciela obiektu.

  2. Zastosowanie funkcji TYPEPROPERTY(type,’OwnerId’) w celu wykrycia prawdziwego właściciela typu.

Synonimy oferowane w wersji SQL Server 2008, pozwalają nam uniknąć wprowadzania długich nazw. Możemy tworzyć synonim dowolnego obiektu dla dwuczęściowej, trzyczęściowej lub czteroczęściowej pełnej nazwy obiektu. SQL Server wykorzystuje ten synonim do uzyskiwania dostępu do zdefiniowanego obiektu. W następującym fragmencie kodu synonim History reprezentuje określony schemat.tabelę w bazie danych AdventureWorks. Instrukcja SELECT zwraca kontekst tabeli EmployeeDepartmentHistory.

USE AdventureWorks

GO

CREATE SYNONYM History FOR HumanResources.EmployeeDepartmentHistory

SELECT * FROM History

Uwaga: Administrator lub właściciel musi przyznać uprawnienie do synonimu, jeśli ma być on wykorzystywany przez kogoś innego: GRANT SELECT dla synonimu widoków, tabel lub funkcji tabelarycznych oraz GRANT EXECUTE dla synonimu procedur lub funkcji skalarnych itp.

Moglibyśmy również zdefiniować synonim History dla pełnej, czteroczęściowej nazwy, jak w poniższym fragmencie kodu:

CREATE SYNONYM History

FOR MyServer.AdventureWorks.HumanResources.EmployeeDepartmentHistory

Wykorzystanie tego typu pełnej, czteroczęściowej nazwy pozwala nam stosować synonim z kontekstu innej bazy danych - przy założeniu, że aktualny użytkownik posiada uprawnienia do wykorzystywania synonimu i odczytu tabeli:

USE pubs

SELECT * FROM AdventureWorks..History

Warto zauważyć, że jeśli nie dostarczymy nazwy schematu, jako części nazwy nowego synonimu, wykorzystana zostanie nazwa schematu domyślnego.

 Do początku strony Do początku strony

Zarządzanie szyfrowaniem i kluczami

Najwięcej uwagi administratorów systemu koncentruje się prawdopodobnie na zabezpieczeniach na poziomie serwera, ale to w bazie danych zachodzi większość zdarzeń podczas pracy w środowisku produkcyjnym. Na ogół administrator bazy danych może pozwolić programiście bazy danych, zająć się szczegółami w bazie danych, pod warunkiem, że programista pracuje w ramach ograniczeń środowiska. SQL Server 2008 oferuje wiele funkcji zabezpieczania bazy danych.

Szyfrowanie danych

SQL Server 2000 i wersje wcześniejsze nie zawierały wbudowanego wsparcia dla szyfrowania danych składowanych w bazie danych. Dlaczego mielibyśmy szyfrować dane, które są składowane w dobrze zabezpieczonej bazie danych na bezpiecznym serwerze, schowanym bezpiecznie za najnowocześniejszymi zaporami sieciowymi? A mianowicie z powodu ważnej, starej reguły zabezpieczeń o nazwie „defense in depth”. Defense in depth oznacza tworzenie różnych warstw obrony, aby atakujący nawet, jeśli skutecznie przebije się przez zewnętrzne mechanizmy zabezpieczające, nadal musiał przełamywać się przez kolejne warstwy osłonne. W bazie danych oznacza to, że jeśli atakujący przejdzie przez zaporę sieciową oraz przez zabezpieczenia systemu Windows na serwerze i dostanie się do bazy danych, nadal musi dokonać niewdzięcznego ataku typu brute force w celu deszyfrowania danych. Ponadto w dzisiejszych czasach prawnej ochrony danych i ich poufności, bazy danych powinny posiadać mocne zabezpieczenia.

SQL Server 2008 oferuje bogate wsparcie dla różnego typu szyfrowania danych przy użyciu kluczy symetrycznych i asymetrycznych oraz certyfikatów cyfrowych. I co najlepsze sam zajmuje się zarządzaniem kluczami, a warto zauważyć, że zarządzanie kluczami stanowi jak na razie najtrudniejszy aspekt szyfrowania.

Jako administratorzy, prawdopodobnie będziemy musieli zarządzać przynajmniej kluczami górnego poziomu w hierarchii pokazanej na Rysunku 1. Administratorzy baz danych muszą rozumieć znaczenie kluczy Service Master Key na poziomie serwera oraz kluczy Database Master Key na poziomie bazy danych. Każdy klucz chroni swoje klucze podrzędne, które z kolei chronią swoje klucze podrzędne i tak dalej, w dół drzewa. Jedynym wyjątkiem jest sytuacja, gdy klucz symetryczny lub certyfikat jest chroniony przez hasło. Właśnie w ten sposób, SQL Server pozwala użytkownikom zarządzać własnymi kluczami i przejmować odpowiedzialność za utrzymywanie kluczy w tajemnicy.

Hierarchia kluczy szyfrowania w SQL Server 2008

Rysunek 1: Hierarchia kluczy szyfrowania w SQL Server 2008.

Uwaga: Firma Microsoft odradza wykorzystywanie certyfikatów lub kluczy asymetrycznych bezpośrednio do szyfrowania danych. Szyfrowanie z użyciem klucza asymetrycznego jest wielokrotnie wolniejsze, a ilość danych, które można ochronić przy pomocy tego mechanizmu, jest ograniczona w zależności od długości klucza. Możemy chronić certyfikaty oraz klucze asymetryczne przy użyciu hasła zamiast klucza Database Master Key.

Service Master Key to jeden klucz, który rządzi wszystkimi kluczami i certyfikatami w systemie SQL Server. To symetryczny klucz, który SQL Server tworzy automatycznie podczas instalacji. Jest on rzecz jasna ściśle tajny, ponieważ gdyby został przechwycony, atakujący mógłby docelowo rozszyfrować każdy klucz, którym zarządza dana instancja SQL Server. Interfejs Data Protection API (DPAPI) w systemie Windows chroni klucz Service Master Key.

SQL Server zarządza kluczem Service Master Key za nas, chociaż możemy realizować na nim zadania konserwacyjne, takie jak zapisanie go w pliku, ponowne wygenerowanie lub przywrócenie go na podstawie pliku. Jednak w większości sytuacji nie będziemy potrzebowali lub chcieli dokonywać żadnych z wyżej wymienionych operacji na kluczu. Zaleca się administratorom tworzenie kopii zapasowych klucza Service Master Key na wypadek jego uszkodzenia.

W zakresie bazy danych klucz Database Master Key, stanowi nadrzędny obiekt szyfrowania dla wszystkich kluczy, certyfikatów i danych w bazie danych. Każda baza danych, zawiera pojedynczy klucz Master Key i próba stworzenia drugiego klucza zakończy się komunikatem o błędzie. Przed zastosowaniem klucza Database Master Key trzeba go stworzyć przy użyciu instrukcji Transact-SQL CREATE MASTER KEY wraz z hasłem dostarczanym przez użytkownika:

CREATE MASTER KEY

ENCRYPTION BY PASSWORD = ‘EOhnDGS6!7JKv’

SQL Server szyfruje klucz przy pomocy algorytmu Triple DES z kluczem określonym na podstawie hasła oraz klucza Service Master Key. Pierwsza kopia jest składowana w danej bazie danych, natomiast druga jest umieszczana w bazie danych master. Posiadanie klucza Database Master Key zabezpieczonego przy użyciu Service Master Key, umożliwia serwerowi SQL Server automatyczne odszyfrowanie klucza Database Master Key, gdy jest to konieczne. Aplikacja końcowa lub użytkownik nie muszą otwierać klucza Master Key bezpośrednio przy użyciu hasła, co stanowi główną korzyść płynącą z posiadania kluczy chronionych w hierarchii.

Odłączanie bazy danych z istniejącym kluczem Master Key i przenoszenie jej na inny serwer może być dość problematyczne. Problem polega na tym, że Service Master Key na docelowym serwerze różni się od tego na serwerze źródłowym. I w efekcie serwer nie będzie mógł automatycznie deszyfrować klucza Database Master Key. Można obejść to ograniczenie, otwierając Database Master Key przy użyciu hasła, za pomocą, którego został on zaszyfrowany i wykorzystując instrukcję ALTER MASTER KEY do zaszyfrowania go przy użyciu nowego Service Master Key. W przeciwnym wypadku będziemy musieli zawsze bezpośrednio otwierać Database Master Key przed jego użyciem.

Gdy Database Master Key już istnieje, programiści mogą wykorzystać go do tworzenia dowolnego z trzech typów kluczy, w zależności od wymaganego typu szyfrowania:

  •  Klucze asymetryczne, wykorzystywane w kryptografii opartej o ideę klucza publicznego, bazującą na parze kluczy publicznego i prywatnego

  •  Klucze symetryczne, wykorzystywane dla rozwiązań opartych o współdzieloną wartość uwierzytelniającą obie strony komunikacji (ang. shared secrets), gdy ten sam klucz zarówno szyfruje, jak i deszyfruje dane

  •  Certyfikaty, czyli zasadniczo rozwiązania opakowujące klucz publiczny.

Te wszystkie opcje szyfrowania i ich głęboka integracja z serwerem oraz bazą danych sprawiają, że szyfrowanie stanowi obecnie wygodny sposób dodawania ostatniej z warstw obrony danych. Niemniej jednak, należy wykorzystywać to narzędzie z rozsądkiem, ponieważ szyfrowanie może znacznie zwiększyć obciążenie serwera.

Transparentne szyfrowanie danych

W SQL Server 2005 możemy szyfrować dane w bazie danych, pisząc niestandardowy kod Transact-SQL, który wykorzystuje możliwości kryptograficzne silnika bazy danych. SQL Server 2008 dodatkowo polepsza sytuację, wprowadzając transparentne szyfrowanie danych (ang. Transparent Data Encryption).

Transparentne szyfrowanie danych pozwala na wykonanie wszystkich operacji kryptograficznych na poziomie bazy danych, co sprawia, że programiści aplikacji nie muszą już samodzielnie tworzyć niestandardowego kodu szyfrowania i deszyfrowania danych. Dane są szyfrowane podczas zapisywania ich na dysk i deszyfrowane, gdy są odczytywane z dysku. Używając SQL Server do transparentnego zarządzania szyfrowaniem i deszyfrowaniem, możemy zabezpieczać dane biznesowe w bazie danych, bez konieczności dokonywania jakichkolwiek zmian w istniejących aplikacjach, co pokazano na Rysunku 2.

Transparentne szyfrowanie danych

Rysunek 2: Transparentne szyfrowanie danych.

Klucz Database Encryption Key (DEK) służy do realizowania szyfrowania i deszyfrowania. Klucz DEK jest przechowywany w rekordzie startowym bazy danych, aby był dostępny także podczas operacji odzyskiwania. Do ochrony klucza DEK możemy wykorzystać klucz Service Master Key lub moduł Hardware Security Module (HSM). Sprzętowe moduły bezpieczeństwa HSM to zazwyczaj urządzenia USB lub SmartCard, a zatem są one mniej narażone na kradzież lub zaginięcie.

Rozszerzalny mechanizm zarządzania kluczami

Rosnące wymogi prawne oraz potrzeby wynikające z ogólnej troski o poufność danych spowodowały, że coraz więcej organizacji decyduje się na szyfrowanie jako sposób zapewnienia ochrony zgodnej z filozofią tworzenia wielowarstwowych systemów zabezpieczeń. A ponieważ organizacje coraz intensywniej wykorzystują szyfrowanie oraz klucze do zabezpieczania swoich danych, zarządzanie kluczami staje się bardzie skomplikowane. Dobrze zabezpieczone bazy danych wykorzystują nawet tysiące kluczy, więc konieczne jest zbudowanie systemu do składowania, unieważniania oraz ponownego generowania tych kluczy. Co więcej, w celu poprawy bezpieczeństwa klucze te powinny być składowane niezależnie od danych.

SQL Server 2008 udostępnia funkcjonalność szyfrowania do wykorzystania przez zewnętrznych dostawców oprogramowania. Rozwiązania te dyskretnie współdziałają z bazami danych SQL Server 2005 oraz SQL Server 2008 i dostarczają dedykowane systemy do zarządzania kluczami w skali korporacji. To przenosi ciężar zarządzania kluczami z programu SQL Server do dedykowanego systemu zarządzania kluczami.

Funkcja Extensible Key Management w SQL Server 2008 wspiera także wykorzystanie modułów HSM w celu zapewnienia fizycznego oddzielenia kluczy od danych.

Podpisywanie modułów kodu

Jedną z zalet dostępności szyfrowania w SQL Server jest to, że zapewnia ona możliwość cyfrowego podpisywania modułów kodu (procedur składowanych, funkcji, wyzwalaczy oraz powiadomień o zdarzeniach) przy użyciu certyfikatów. To zapewnia dużo bardziej szczegółową kontrolę nad dostępem do tabel bazodanowych i innych obiektów. Podobnie jak w przypadku szyfrowania danych, podpisujemy kod przy użyciu klucza prywatnego, znajdującego się w certyfikacie. Efekt jest taki, że tabele wykorzystywane w podpisanym module kodu są dostępne jedynie za pośrednictwem kodu. Innymi słowy dostęp do tabel jest możliwy tylko przy użyciu certyfikatów, które zostały zastosowane do podpisania danego modułu.

Podobny efekt można osiągnąć przy pomocy procedury składowanej. Na przykład, jeśli łańcuch własności nie jest rozerwany, ostrożnie kontrolujemy, którzy użytkownicy otrzymują uprawnienie EXECUTE do wykonywania procedury, jednocześnie odmawiając prawa do bezpośredniego dostępu do wykorzystywanych tabel. Ale takie rozwiązanie nie jest pomocne w sytuacji, gdy procedura posiada zerwany łańcuch własności lub wykonuje dynamiczny kod SQL, który wymaga, aby użytkownik wykonujący procedurę, posiadał uprawnienia do wykorzystywanych tabel. Innym sposobem na osiągnięcie tego samego efektu jest wykorzystanie instrukcji EXECUTE AS, jednak zmienia ona kontekst zabezpieczeń, w którym wykonywana jest procedura. A to może nie być pożądane, na przykład wtedy, gdy chcemy rejestrować w tabeli informację o tym, który użytkownik w rzeczywistości spowodował uruchomienie procedury (sposób na pominięcie wymagania przesłania nazwy użytkownika, jako parametru wywołania procedury).

Podpisywanie modułów kodu ma dodatkową zaletę, gdyż chroni przed nieautoryzowanymi modyfikacjami modułu kodu. Podobnie jak inne dokumenty, które są podpisywane cyfrowo, certyfikat staje się nieprawidłowy, gdy kod ulegnie zmianie. Kod nie wykona się w kontekście certyfikatu, a więc wszystkie obiekty, do których dostęp jest zapewniany przez certyfikat, przestaną być dostępne.

Aby zastosować to rozwiązanie, tworzymy certyfikat, powiązujemy go z nowym użytkownikiem i podpisujemy procedurę przy użyciu certyfikatu. Użytkownikowi temu, musimy przyznać uprawnienia niezbędne do wykonania procedury składowanej. W zasadzie dodaliśmy tego użytkownika do kontekstu zabezpieczeń procedury składowanej, nadając mu drugą tożsamość. Następnie przyznajemy uprawnienia wykonania wszystkim użytkownikom lub rolom potrzebnym do wykonania procedury. Następujący fragment kodu prezentuje te kroki. Załóżmy, że chcemy podpisać procedurę mySchema.GetSecretStuff i że wszystkie obiekty, do których się odwołujemy, istnieją już w bazie danych:

CREATE CERTIFICATE

certCodeSigning



ENCRYPTION BY PASSWORD

= ‘cJI%V4!axnJXfLC’



WITH SUBJECT =

‘Code signing certificate’

GO



-- Podpisujemy

procedurę składowaną



ADD SIGNATURE TO

mySchema.GetSecretStuff BY CERTIFICATE certCodeSigning



WITH PASSWORD =

‘cJI%V4!axnJXfLC’

GO



-- Mapujemy użytkownika

do certyfikatu



CREATE USER certUser

FOR CERTIFICATE certCodeSigning

GO



-- Nadajemy uprawnienie do operacji

SELECT nowemu użytkownikiem certUser



GRANT SELECT ON

SocialSecurity TO certUser

GO



-- Nadajemy uprawnienie do wykonywania

operacji przez użytkownika, który uruchomi kod



GRANT EXECUTE ON

mySchema.GetSecretStuff TO ProcedureUser

GO

Teraz tylko użytkownicy, którym bezpośrednio przyznane zostało uprawnienie EXECUTE do procedury składowanej, mogą uzyskiwać dostęp do danych tabeli.

 Do początku strony Do początku strony

Inspekcje w SQL Server 2008

Istotną częścią każdego rozwiązania bezpieczeństwa jest możliwość przeprowadzania inspekcji podejmowanych akcji z uwzględnieniem zakresów odpowiedzialności oraz zgodności z przepisami. SQL Server 2008 zawiera wiele funkcji, które umożliwiają aktywne przeprowadzanie inspekcji.

Inspekcja wszystkich akcji

SQL Server 2008 zapewnia wsparcie dla inspekcji przy pomocy obiektu Audit, który umożliwia administratorom monitorowanie aktywności na serwerze baz danych i umieszczanie informacji w dzienniku. W SQL Server 2008 możemy składować informacje o inspekcji w następujących lokalizacjach:

  •  Plik

  •  Dziennik aplikacji systemu Windows

  •  Dziennik zabezpieczeń systemu Windows

Aby dokonywać zapisu w dzienniku zabezpieczeń systemu Windows, SQL Server musi być uruchomiony w kontekście konta Local System, Local Service, Network Service lub konta domeny, które posiada przywilej SeAuditPrivilege i nie jest użytkownikiem interaktywnym.

W celu stworzenia obiektu Audit należy użyć instrukcji CREATE SERVER AUDIT. Instrukcja ta definiuje obiekt Audit i powiązuje go z lokalizacją docelową. Określone opcje wykorzystywane do skonfigurowania obiektu Audit, zależą od lokalizacji docelowej inspekcji. Na przykład, następujący kod Transact-SQL tworzy dwa obiekty Audit. Jeden z nich rejestruje informacje o aktywności w pliku, a drugi w dzienniku aplikacji systemu Windows.

CREATE SERVER AUDIT HIPAA_File_Audit

TO FILE ( FILEPATH=’\\SQLPROD_1\Audit\’);

CREATE SERVER AUDIT HIPAA_AppLog_Audit

TO APPLICATION_LOG

WITH ( QUEUE_DELAY = 500, ON_FAILURE = SHUTDOWN);

Warto mieć na uwadze, że w przypadku rejestrowana do pliku, nazwa pliku nie jest określana w instrukcji CREATE SERVER AUDIT. Nazwy plików inspekcji, przyjmują postać NazwaInspekcji_GUIDInspekcji_nn_TS.sqlaudit, gdzie NazwaInspekcji to nazwa obiektu Audit, GUIDInspekcji to unikalny identyfikator powiązany z obiektem Audit, nn to numer partycji wykorzystywany do określania zbiorów plików, a TS to wartość znacznika czasu. Na przykład obiekt inspekcji HIPAA_FILE_Audit, stworzony w poprzednim przykładzie mógłby wygenerować plik dziennika o nazwie podobnej do następującej:

HIPAA_File_Audit_{95A481F8-DEF3-40ad-B3C6-126B68257223}_00_29384.sqlaudit

Możemy wykorzystać opcję inspekcji QUEUE_DELAY do implementowania asynchronicznego ze względu na wydajność, a także opcję N_FAILURE, określającą akcję, która ma zostać podjęta, jeśli informacje o inspekcji nie będą mogły zostać zapisane w lokalizacji docelowej. W poprzednio pokazanym przykładzie HIPAA_AppLog_Audit opcja ON_FAILURE jest konfigurowana tak, aby instancja SQL Server była wyłączana w przypadku braku możliwości zapisania dziennika. W tej sytuacji użytkownik, który wykonuje instrukcję CREATE SERVER AUDIT, musi posiadać uprawnienie SHUTDOWN.

Po stworzeniu obiektu Audit możemy dodać do niego zdarzenia, wykorzystując instrukcje CREATE SERVER AUDIT SPECIFICATION oraz CREATE DATABASE AUDIT SPECIFICATION. Instrukcja CREATE SERVER AUDIT SPECIFICATION, dodaje do inspekcji grupy akcji na poziomie serwera (to znaczy predefiniowane zbiory powiązanych akcji, pojawiających się na poziomie serwera). Na przykład, poniższy fragment kodu powoduje dodanie do inspekcji HIPAA_File_Auditgrupy akcji FAILED_LOGIN_GROUP, która rejestruje nieudane próby logowania.

CREATE SERVER AUDIT SPECIFICATION Failed_Login_Spec

FOR SERVER AUDIT HIPAA_File_Audit

ADD (FAILED_LOGIN_GROUP);

Instrukcja CREATE DATABASE AUDIT SPECIFICATION dodaje do inspekcji grupę akcji na poziomie bazy danych oraz poszczególne zdarzenia w bazie danych. Dodawanie poszczególnych akcji umożliwia nam filtrowanie akcji, które mają być rejestrowane, w oparciu o obiekty i użytkowników zaangażowanych w tę akcję. Poniższy fragment kodu powoduje dodanie do inspekcji HIPAA_AppLog_Audit grupy akcji DATABASE_OBJECT_CHANGE_GROUP (która rejestruje wszystkie operacje CREATE, ALTER oraz DROP zachodzące w bazie danych) oraz wszystkie instrukcje INSERT, UPDATE lub DELETE wykonywane na obiektach w schemacie Sales przez użytkowników SalesUser lub SalesAdmin.

CREATE DATABASE AUDIT SPECIFICATION Sales_Audit_Spec

FOR SERVER AUDIT HIPAA_AppLog_Audit

ADD (DATABASE_OBJECT_CHANGE_GROUP),

ADD (INSERT, UPDATE, DELETE

ON Schema::Sales

BY SalesUser, SalesAdmin);

Obiekt Audit dostarcza zarządzalną strukturę inspekcji, ułatwiającą definiowanie zdarzeń, które mają zostać zarejestrowane i lokalizacji, w których powinien zostać zapisany dziennik. To rozszerzenie SQL Server pomaga w implementowaniu wszechstronnych rozwiązań do przeprowadzania inspekcji w celu zabezpieczania bazy danych i osiągania wymaganej zgodności z przepisami.

Wyzwalacze DDL

Wyzwalacze DDL, zostały wprowadzone w wersji SQL Server 2005. W odróżnieniu od wyzwalaczy DML, które wykonują kod Transact-SQL, gdy dane w tabelach ulegają zmianie, wyzwalacz DDL uruchamia się, gdy zmienia się struktura tabeli. Jest to świetny sposób śledzenia i inspekcji zmian strukturalnych w schemacie bazy danych.

Składnia tych wyzwalaczy przypomina składnię wyzwalaczy DML. Wyzwalacze DDL są wyzwalaczami typu AFTER, które są uruchamiane w odpowiedzi na zdarzenia języka DDL. Nie są one uruchamiane w odpowiedzi na systemowe procedury składowane, które realizują operacje o charakterze DDL. Są one w pełni transakcyjne, a zatem możemy dzięki nim wycofać (ROLLBACK) zmianę DDL. Możemy uruchomić w nich kod Transact-SQL lub CLR. Wyzwalacze DDL wspierają również klauzulę EXECUTE AS, podobnie do innych modułów.

SQL Server dostarcza informacji o zdarzeniach wyzwalacza w postaci Untyped XML. Są one dostępne za pośrednictwem nowej, emitującej kod XML, wbudowanej funkcji o nazwie EVENTDATA(). Możemy użyć wyrażeń XQuery do parsowania dokumentów XML EVENTDATA(), aby sprawdzić atrybuty zdarzeń, takie jak nazwa schematu, nazwa obiektu docelowego, nazwa użytkownika, jak również całą instrukcję DDL Transact-SQL, która spowodowała uruchomienie wyzwalacza. Przykłady znaleźć można w artykule EVENTDATA (Transact-SQL) w witrynie SQL Server Books Online.

Wyzwalacze DDL na poziomie bazy danych są uruchamiane przez zdarzenia języka DDL, zachodzące na poziomie bazy danych lub niższym, takie jak np. CREATE_TABLE czy ALTER_USER. Wyzwalacze DDL na poziomie serwera są uruchamiane przez zdarzenia języka DDL, zachodzące na poziomie serwera, na przykład CREATE_DATABASE, ALTER_LOGIN itp. Aby zwiększyć wygodę realizacji zadań administracyjnych, możemy wykorzystać grupy zdarzeń np. grupę DDL_TABLE_EVENTS pomocną w odwoływaniu się do wszystkich zdarzeń CREATE_TABLE, ALTER_TABLE oraz DROP_TABLE. Różne grupy zdarzeń i typy zdarzeń DDL, a także powiązane z nimi dokumenty XML EVENTDATA() zostały udokumentowane w witrynie SQL Server Books Online.

W odróżnieniu od nazw wyzwalaczy DML, które mają zakres schematu, nazwy wyzwalaczy DDL mają zakres bazy danych lub serwera.

Możemy użyć następującego nowego widoku katalogowego, aby sprawdzać metadane wyzwalaczy DML oraz wyzwalaczy DDL na poziomie bazy danych:

SELECT * FROM sys.triggers ;

GO

Jeśli kolumna parent_class_desc zawiera wartość ‘DATABASE’, jest to wyzwalacz DDL, a jego nazwa ma zakres bazy danych. Kod Transact-SQL wyzwalacza, można znaleźć w widoku katalogowym sys.sql_modules, który można dodatkowo złączyć z widokiem sys.triggers przy użyciu kolumny object_id. Metadane, dotyczące wyzwalacza CLR, znaleźć można w widoku katalogowym sys.assembly_modules i ponownie możemy złączyć go z widokiem sys.triggers przy użyciu kolumny object_id.

Użyjemy następującego widoku katalogowego, aby odkryć metadane dla wyzwalaczy DDL, działających w zakresie serwera:

SELECT * FROM sys.server_triggers;

GO

Kod Transact-SQL, wyzwalacza funkcjonującego na poziomie serwera, znaleźć można w widoku katalogowym sys.server_sql_modules, który można dodatkowo złączyć z widokiem sys.server_triggers przy użyciu kolumny object_id. Metadane dotyczące wyzwalacza CLR na poziomie serwera znaleźć można w widoku katalogowym sys.server_assembly_modules i ponownie możemy złączyć go z widokiem sys.server_triggers przy użyciu kolumny object_id.

Możemy użyć wyzwalaczy DDL do przechwytywania i inspekcji aktywności DDL w bazie danych. W tym celu tworzymy tabelę inspekcji z kolumną Untyped XML. Tworzymy wyzwalacz DDL EXECUTE AS SELF dla zdarzeń lub grup zdarzeń DDL, które nas interesują. Kod wyzwalacza DDL może zawierać po prostu operację wstawiania EVENTDATA() do tabeli audytu.

Innym interesującym zastosowaniem wyzwalaczy DDL jest uruchamianie ich w wyniku zdarzenia CREATE_USER, następnie dodawanie kodu automatyzującego zarządzanie uprawnieniami. Załóżmy na przykład, że chcemy, aby wszyscy użytkownicy bazy danych otrzymali uprawnienie GRANT EXECUTE do procedur P1, P2 oraz P3. Wyzwalacz DDL może wyodrębnić nazwę użytkownika z wyniku funkcji EVENTDATA(), dynamicznie sformułować instrukcję o postaci ‘GRANT EXECUTE ON P1 TO WybranyUżytkownik', a następnie wykonać ją.

 Do początku strony Do początku strony

Wnioski

SQL Server 2008 zapewnia bogate funkcje zabezpieczeń pozwalające na zabezpieczanie danych oraz zasobów sieciowych. Instalacja, która pomija lub pozostawia nieaktywne wszystkie elementy systemu poza kluczowymi, pozwala na dużo łatwiejsze osiągnięcie bezpiecznej konfiguracji. SQL Server dostarcza wiele narzędzi służących do konfiguracji serwera, w szczególności narzędzie SQL Server Surface Area Configuration Tool. Funkcje zapewniające uwierzytelnianie mają większą moc, ponieważ SQL Server jest ściślej zintegrowany z mechanizmami uwierzytelniania systemu Windows i posiada zabezpieczenia przeciwko słabym lub przestarzałym hasłom. Nadawanie praw i kontrolowanie tego, co użytkownik może zrobić, gdy zostanie już uwierzytelniony, jest dużo bardziej elastyczne. Dzięki uprawnieniom nadawanym na dużym poziomie ziarnistości, elementom proxy usługi SQL Server Agent oraz kontekstom wykonania, nawet metadane są bezpieczniejsze, odkąd systemowe widoki meta danych, zwracają informacje tylko o tych obiektach, do których dany użytkownik posiada uprawniania, pozwalające na ich wykorzystanie. Na poziomie bazy danych szyfrowanie zapewnia ostateczną linię obrony, podczas gdy rozdzielenie użytkowników i schematów sprawia, że zarządzanie użytkownikami jest znacznie łatwiejsze.

Dodatkowe informacje:

https://www.microsoft.com/sql

https://www.microsoft.com/sql/technologies/security/default.mspx

 Do początku strony Do początku strony

 

Microsoft SQL Server 2008