Bezpieczeństwo w SQL Server 2008

Autor: Rick Byham

Opublikowano: 5 listopada 2008

Zawartość strony

	Ulepszenia w zakresie szyfrowania
	Ulepszenia w zakresie uwierzytelniania
	Inspekcje zabezpieczeń
	Raportowanie zależności
	Nowe role bazodanowe
	Bezpieczeństwo FILESTREAM
	Zarządzanie oparte na zasadach
	Windows Server 2008
	Na zakończenie

SQL Server 2008 dostarcza wiele ulepszeń i nowych funkcji, które zostały zaprojektowane w celu ogólnej poprawy bezpieczeństwa środowiska bazodanowego. Oferuje możliwości szyfrowania kluczy oraz uwierzytelniania i wprowadza nowy system inspekcji, który pomaga w raportowaniu zachowań użytkowników oraz spełnianiu wymogów prawnych.

W niniejszym artykule zaprezentowany zostanie przegląd najważniejszych zmian w zakresie bezpieczeństwa oferowanych przez wersję SQL Server® 2008. Jednym z pierwszych aspektów, które można zauważyć, jest brak narzędzia SQL Server 2005 Surface Area Configuration. Opcje protokołów, które były udostępniane za pośrednictwem narzędzia Surface Area Configuration, są obecnie dostępne w narzędziu Configuration Manager. Natomiast włączanie i wyłączanie funkcji jest realizowane za pośrednictwem nowej technologii SQL Server 2008 Policy-Based Management.

Ulepszenia w zakresie szyfrowania

W obszarze szyfrowania wprowadzone zostały dwa główne ulepszenia. Po pierwsze, SQL Server może obecnie wykorzystywać klucze szyfrowania przechowywane w zewnętrznym sprzętowym module bezpieczeństwa dostarczanym przez firmy trzecie. Po drugie, dane składowane na serwerze SQL Server mogą być szyfrowane w sposób niewidoczny dla aplikacji, które łączą się z bazą danych. To oznacza, że administratorzy baz danych mogą z łatwością szyfrować wszystkie dane przechowywane w całej bazie danych, bez konieczności modyfikowania kodu istniejących aplikacji.

To pierwsze ulepszenie stało się możliwe dzięki nowej funkcji Extensible Key Management (EKM), która jest dostępna w edycjach Enterprise, Developer oraz Evaluation SQL Server 2008. Dzięki funkcji EKM zewnętrzni dostawcy rozwiązań do zarządzania kluczami w przedsiębiorstwie oraz sprzętowych modułów bezpieczeństwa (HSM) mogą rejestrować własne urządzenia na serwerze SQL Server. Gdy urządzenia te są zarejestrowane, użytkownicy mogą używać kluczy szyfrowania składowanych w tych modułach.

Dostawcy mogą nawet udostępniać w tych modułach zaawansowane funkcje szyfrowania (takie jak wygasanie czy rotacja klucza). W niektórych konfiguracjach mechanizm ten obejmuje ochronę danych przed administratorami baz danych, którzy nie są członkami grupy sysadmin. Instrukcje kryptograficzne T-SQL mogą szyfrować i deszyfrować dane przy użyciu kluczy przechowywanych na zewnętrznym urządzeniu EKM.

Inna nowa funkcja, Transparent Data Encryption (przezroczyste szyfrowanie danych), umożliwia nam szyfrowanie plików baz danych bez konieczności modyfikowania jakiejkolwiek aplikacji. Realizuje ona szyfrowanie i deszyfrowanie w czasie rzeczywistym We/Wy plików danych oraz dzienników. Szyfrowanie wykorzystuje klucz Database Encryption Key (DEK), który jest składowany w rekordzie startowym bazy danych na potrzeby procesu odzyskiwania. Klucz DEK jest zabezpieczony przy użyciu certyfikatu przechowywanego w bazie danych master serwera. Diagram przedstawiony na Rysunku 1 ilustruje architekturę, która umożliwia przezroczyste szyfrowanie danych.

Rysunek 1: Architektura funkcji Transparent Data Encryption.

Mechanizm ten wspomaga ochronę danych w trakcie przechowywania. Choć dostępnych jest szereg środków ostrożności, które pomagają w zabezpieczaniu bazy danych, takich jak szyfrowanie poufnych zasobów oraz umieszczanie zapory sieciowej wokół serwerów bazodanowych, inny słaby punkt stanowią fizyczne nośniki, na których przechowywane są dane (a nawet taśmy z kopiami zapasowymi). Złośliwy użytkownik może wykraść ten nośnik i potencjalnie uzyskać dostęp do składowanych na nim danych.

Jednak funkcja Transparent Data Encryption umożliwia nam szyfrowanie poufnych danych w bazie danych i zabezpieczanie kluczy służących do szyfrowania danych przy użyciu certyfikatu. To może pomóc naszej organizacji w spełnieniu wielu wymogów prawnych, przepisów i dyrektyw przemysłowych dotyczących odpowiedniej ochrony danych.

Funkcja Transparent Data Encryption umożliwia programistom szyfrowanie danych przy użyciu algorytmów Advanced Encryption Standard (AES) oraz Triple Data Encryption Standard (3DES). Szyfrowanie pliku bazy danych jest realizowane na poziomie stron, przy czym strony są szyfrowane przed zapisaniem ich na dysku, a następnie deszyfrowane podczas wczytywania ich do pamięci. Pliki kopii zapasowych bazy danych, dla których włączona jest funkcja Transparent Data Encryption, są również szyfrowane przy użyciu klucza DEK.

Aby przywrócić zaszyfrowaną bazę danych, trzeba posiadać dostęp do certyfikatu lub klucza asymetrycznego, który został wykorzystany do zaszyfrowania bazy danych. Bez certyfikatu lub klucza asymetrycznego baza danych nie może zostać przywrócona. A zatem należy przechowywać wszystkie klucze tak długo, jak długo potrzebny jest dostęp do powiązanych z nimi kopii zapasowych.

 Do początku strony

Ulepszenia w zakresie uwierzytelniania

Jak prawdopodobnie większość czytelników wie, Kerberos to protokół uwierzytelniania sieciowego, który jest wykorzystywany do zapewniania wysoce bezpiecznych sposobów wzajemnego uwierzytelniania jednostek klienta oraz serwera (lub podmiotów zabezpieczeń) w sieci. Kerberos pomaga użytkownikom w pokonywaniu zagrożeń, takich jak ataki typu „luring” oraz „man-in-the-middle”. W porównaniu z uwierzytelnianiem Windows® NTLM, uwierzytelnianie Kerberos jest bezpieczniejsze, bardziej niezawodne i zapewnia większą wydajność.

Aby można było wzajemnie uwierzytelnić połączenie przy użyciu protokołu Kerberos, nazwy główne usługi (SPN) instancji SQL Server muszą być zarejestrowane w usłudze Active Directory®, a sterownik kliencki musi podczas łączenia się dostarczyć zarejestrowaną nazwę SPN. W SQL Server 2008 uwierzytelnianie Kerberos zostało rozszerzone na wszystkie protokoły, w tym TCP, Nazwany Potok, Udostępnioną Pamięć oraz Virtual Interface Adapter (VIA). Domyślnie, sterownik kliencki automatycznie określa odpowiednią nazwę SPN dla instancji SQL Server, z którą się łączy. Można również wprost podać nazwę SPN w parametrze łańcucha połączenia dla poprawy bezpieczeństwa, kontroli i diagnozowania problemów.

Internetowe usługi informacyjne (IIS) nie zapewniają już dostępu do usług sieci Web ASP.NET Report Manager lub Report Server. W SQL Server 2008 usługi Reporting Services obsługują wszystkie żądania uwierzytelnienia za pośrednictwem nowego podsystemu uwierzytelniania, który wspiera uwierzytelnianie oparte na systemie Windows oraz niestandardowe.

Usługi Reporting Services obejmują obecnie technologie Microsoft® .NET Framework oraz ASP.NET wbudowane we wspólne środowisko uruchomieniowe SQL Server (CLR), a także wykorzystują możliwości komponentu systemu operacyjnego HTTP.SYS. Serwer raportów zawiera odbiornik http, który akceptuje żądania kierowane pod adres URL oraz port zdefiniowany podczas konfiguracji serwera. Serwer raportów bezpośrednio zarządza rezerwacjami i rejestracjami adresów URL za pośrednictwem komponentu HTTP.SYS.

 Do początku strony

Inspekcje zabezpieczeń

SQL Server Audit stanowi nową funkcję, która umożliwia tworzenie dostosowanych inspekcji zdarzeń aparatu bazy danych. Funkcja ta wykorzystuje rozszerzone zdarzenia do zapisywania informacji na potrzeby inspekcji i oferuje narzędzia oraz procesy, które są potrzebne do uaktywniania, składowania i wyświetlania inspekcji dla różnych obiektów serwerowych oraz bazodanowych.

Co więcej funkcja SQL Server Audit jest szybsza niż funkcja SQL Server Trace, a SQL Server Management Studio ułatwia tworzenie i monitorowanie dzienników inspekcji. Obecnie można dokonywać inspekcji na bardziej szczegółowym poziomie, przechwytując instrukcje SELECT, INSERT, UPDATE, DELETE, REFERENCES oraz EXECUTE dla poszczególnych użytkowników. Ponadto funkcja SQL Server Audit pozwala także na tworzenie skryptów przy pomocy instrukcji T-SQL CREATE SERVER AUDIT oraz CREATE SERVER AUDIT SPECIFICATION, a także związanych z nimi instrukcji ALTER oraz DROP.

Aby skonfigurować inspekcję, należy stworzyć inspekcję i określić lokalizację, w której zapisywane będą poddawane inspekcji zdarzenia. Inspekcje mogą być zapisywane w dzienniku zabezpieczeń systemu Windows, w dzienniku aplikacji systemu Windows lub w pliku o określonej lokalizacji. Należy nadać inspekcji nazwę i skonfigurować jej opcje, takie jak ścieżka do pliku inspekcji i jego maksymalny rozmiar. Można również wybrać opcję wyłączenia serwera SQL Server, jeśli inspekcja nie powiedzie się. A gdy chcemy rejestrować poddawane inspekcji zdarzenia w więcej niż jednej lokalizacji, tworzymy po prostu więcej niż jedna inspekcję.

Kolejnym krokiem jest stworzenie jednej lub kilku specyfikacji inspekcji. Specyfikacja inspekcji serwera gromadzi informacje dotyczące instancji SQL Server i obejmuje obiekty należące do zakresu serwera, takie jak loginy oraz członkostwo w rolach serwerowych. Zawiera również informacje o bazie danych, które są kontrolowane przez bazę danych master, takie jak prawa dostępu do bazy danych. Gdy definiujemy specyfikację inspekcji, wskazujemy, która inspekcja będzie otrzymywać monitorowane zdarzenia. Możemy definiować wiele inspekcji serwerów i wiele specyfikacji inspekcji serwerów, ale każda inspekcja serwera może zawierać tylko jedną aktywną specyfikację inspekcji serwera.

Możemy również tworzyć specyfikacje inspekcji bazy danych, które monitorują zdarzenia w pojedynczej bazie danych. Możemy dodać do inspekcji wiele specyfikacji inspekcji bazy danych, ale jedna inspekcja serwera może uaktywniać tylko jedną specyfikację inspekcji bazy danych dla danej bazy danych w wybranym momencie.

Zdarzenia akcji inspekcji SQL Server wykorzystywane w specyfikacjach inspekcji serwera są pogrupowane w kolekcje powiązanych ze sobą zdarzeń akcji inspekcji. Są one udostępniane w formie grup akcji inspekcji. Gdy dodajemy grupę do specyfikacji inspekcji, monitorujemy wszystkie zdarzenia znajdujące się w tej grupie. Na przykład, istnieje grupa akcji inspekcji o nazwie DBCC_GROUP, która udostępnia polecenia DBCC. Jednak polecenia DBCC nie są dostępne w ramach indywidualnej inspekcji.

Dostępnych jest 35 grup akcji inspekcji dla serwera, część z nich jest ze sobą ściśle powiązana. Na przykład, istnieją grupy SUCCESSFUL_LOGIN_GROUP, FAILED_LOGIN_GROUP oraz LOGOUT_GROUP. Istnieje również typ akcji inspekcji AUDIT_ CHANGE_GROUP, który można wykorzystać do dokonywania inspekcji procesu inspekcji.

Specyfikacje inspekcji bazy danych mogą również określać grupy zdarzeń dla akcji inspekcji zebrane w grupy akcji inspekcji na poziomie bazy danych. Poza grupami akcji inspekcji specyfikacja inspekcji bazy danych może zawierać poszczególne zdarzenia dla akcji inspekcji służące do inspekcji instrukcji języka DML. Te zdarzenia mogą być konfigurowane w celu monitorowania całej bazy danych lub jedynie wybranych obiektów bazodanowych. Na przykład akcja inspekcji SELECT może posłużyć do dokonywania inspekcji kwerend SELECT dla pojedynczej tabeli lub całego schematu. Zdarzenia te mogą być również konfigurowane w celu monitorowania akcji realizowanych przez określonych użytkowników lub role, takich jak db_writers.

Akcję inspekcji SELECT można wykorzystać na przykład do inspekcji kwerend SELECT dla pojedynczej tabeli realizowanych przez użytkownika Mary bądź rolę bazodanową FINANCE_DEPT lub public. Niewątpliwe mechanizm ten oferuje wiele kontroli i elastyczności w zakresie tworzenia inspekcji dostosowanych do naszych potrzeb.

 Do początku strony

Raportowanie zależności

Raportowanie zależności zostało poprawione poprzez nowy widok katalogowy oraz nowe funkcje systemowe. Korzystając z sys.sql_expression_dependencies, sys.dm_sql_referencing_entities oraz sys.dm_sql_referenced_entities, możemy raportować zależności SQL między serwerami, między bazami danych oraz w ramach jednej bazy danych zarówno dla obiektów powiązanych ze schematem, jak i tych niepowiązanych ze schematem.

 Do początku strony

Nowe role bazodanowe

Baza danych msdb obejmuje zmiany ról bazodanowych. Nazwa roli db_dtsadmin została zmieniona na db_ssisadmin, roli db_dtsltduser zmieniona na db_ssisltduser, a roli db_dtsoperator zmieniona na db_ssisoperator. W celu utrzymywania zgodności z poprzednimi wersjami, stare role są dodawane w roli członków nowych ról podczas aktualizacji serwerów.

Poza tymi zmianami dodane zostały nowe role bazodanowe wspierające nowe funkcje SQL Server 2008. W szczególności baza danych msdb zawiera nowe role dla grup serwerów (ServerGroupAdministratorRole oraz ServerGroupReaderRole), dla funkcji Policy-Based Management (PolicyAdministratorRole) oraz dla funkcji Data Collector (dc_admin, dc_operator oraz dc_proxy). Nowe role dla funkcji Data Collector zawiera również baza danych Management Data Warehouse (mdw_admin, mdw_writer oraz mdw_reader).

 Do początku strony

Bezpieczeństwo FILESTREAM

SQL Server oferuje obecnie wsparcie dla magazynu FILESTREAM, który umożliwia aplikacjom SQL Server składowanie w systemie plików danych nieustrukturalizowanych, takich jak dokumenty oraz obrazy. A to z kolei oznacza, że aplikacje klienckie mogą czerpać korzyści z interfejsów API strumienia oraz wydajności systemu plików, zachowując jednocześnie spójność transakcyjną między nieustrukturalizowanymi danymi, a odpowiadającymi im danymi ustrukturalizowanymi.

Dane FILESTREAM muszą być składowane w grupach plików FILESTREAM, które stanowią specjalną grupę plików zawierającą katalogi systemu plików zamiast właściwych plików. Katalogi te, nazywane pojemnikami na dane, dostarczają interfejs między magazynem aparatu bazy danych a magazynem systemu plików.

Dane FILESTREAM są zabezpieczane tak jak wszystkie pozostałe dane - uprawnienia są przyznawane na poziomie tabel lub kolumn. Jedyne konto, które posiada uprawnienia NTFS do pojemnika FILESTREAM, to konto w kontekście którego uruchomiona jest usługa SQL Server. Gdy baza danych zostaje otwarta, SQL Server zastrzega dostęp do pojemników danych FILESTREAM, za wyjątkiem dostępu dokonywanego za pośrednictwem transakcji T-SQL oraz interfejsów API OpenSqlFilestream.

 Do początku strony

Zarządzanie oparte na zasadach

Funkcja SQL Server 2008 Policy-Based Management wprowadza nowy system zarządzania serwerem SQL Server. Pozwala nam tworzyć zasady w celu testowania oraz raportowania wielu aspektów SQL Server. Zasady mogą być stosowane w pojedynczej bazie danych, na pojedynczej instancji SQL Server lub na wszystkich serwerach SQL Server, którymi zarządzamy.

Dzięki zarządzaniu opartym na zasadach możemy testować opcje konfiguracyjne SQL Server oraz wiele ustawień zabezpieczeń. A w przypadku pewnych ustawień zabezpieczeń możemy tworzyć zasady, które wykrywają niezgodne z zasadami serwery bazodanowe, a następnie przywracają na nich stan zgodności.

W SQL Server 2008 duża część funkcji, które nie są niezbędne, została domyślnie wyłączona w celu zminimalizowania obszaru narażonego na potencjalne ataki. Możemy wykorzystać funkcję Policy-Based Management do selektywnego włączania wybranych, dodatkowych funkcji w zależności od naszych potrzeb. Możemy następnie analizować konfigurację zgodnie z ustalonym harmonogramem i otrzymywać ostrzeżenia, gdy odnalezione zostaną ustawienia konfiguracji niezgodne z zasadami.

Funkcja Policy-Based Management grupuje ze sobą powiązane właściwości i udostępnia je w formie komponentów zwanych aspektami (ang. facet). Na przykład aspekt Surface Area Configuration zawiera właściwości dla Ad Hoc Remote Queries, CLR Integration, Database Mail, OLE Automation, Remote DAC, SQL Mail, Web Assistant oraz xp_cmdshell. Możemy stworzyć zasadę, która włączy funkcję CLR Integration, ale wyłączy wszystkie pozostałe funkcje. Nasza zasada może zawierać złożone instrukcje warunkowe, takie jak wyłączenie funkcji Database Mail na wszystkich instancjach SQL Server, które nie nazywają się Customer_Response.

Gdy już stworzymy zasadę, możemy sprawdzać ją na wszystkich serwerach w celu wygenerowania raportu, który powiem nam, które serwery nie są zgodne z tą zasadą. Gdy naciśniemy przycisk Configure, wszystkie niezgodne instancje zostaną skonfigurowane przy użyciu ustawień zasady. Warto abyśmy stworzyli również harmonogram uruchamiania zasady, by regularnie monitorować stan na serwerach. Aspekty Surface Area Configuration są dostarczane dla aparatu bazy danych oraz usług Analysis Services i Reporting Services.

Jednak należy mieć na uwadze, że funkcja Policy-Based Management nie została stworzona jako mechanizm do wymuszania zabezpieczeń. W większości przypadków użytkownik z wystarczającymi uprawnieniami może albo wykonać instrukcje, które naruszają zasadę albo ominąć zasadę i dokonać ponownej konfiguracji, która może być niezgodna z zasadą zabezpieczeń. Funkcja SQL Server 2008 Policy-Based Management powinna być postrzegana po prostu jako pomoc w monitorowaniu ustawień bezpieczeństwa serwera SQL Server.

Aspekty różnią się pod względem możliwości wymuszania ustawień, w zależności od tego, czy powiązane z nimi instrukcje DDL mogą być uruchamiane w trybach non-autocommit. Czasami aspekt może wymuszać ustawienie konfiguracyjne na instancji aparatu bazy danych, jednak administrator nadal ma możliwość dokonania zmiany tego ustawienia. Pewne aspekty mogą być wymuszane poprzez wyzwalacz na poziomie serwera, co uniemożliwia użytkownikom o ograniczonych uprawnieniach modyfikację ustawienia i zmniejsza prawdopodobieństwo, że administrator przypadkowo zmieni ustawienie. W tym przypadku administrator musiałby tymczasowo wyłączyć zasadę przed zmodyfikowaniem ustawienia. Inne aspekty mogą jedynie raportować stan właściwości, ale nie mogą jej zmieniać. Dotyczy to między innymi zasady, która sprawdza długość klucza symetrycznego i asymetrycznego (jak pokazano na Rysunku 2).

Rysunek 2: Aspekt dla Kluczy asymetrycznych.

Dostępne są aspekty dla większości typów obiektów bazodanowych, wiele z nich ma zastosowanie w zakresie bezpieczeństwa. Na przykład aspekt login może określać, czy zasada hasła jest wymuszana dla każdego loginu, a aspekt procedury składowanej może wykrywać, czy wszystkie procedury są zaszyfrowane. Inne aspekty testują właściwości użytkowników, schematów, dostawców kryptograficznych oraz tryby Common Criteria Compliance oraz audytu C2.

 Do początku strony

Windows Server 2008

SQL Server 2008 został w pełni przetestowany w systemie Windows Server® 2008, który jest dostarczany z włączoną zaporą sieciową. Nadszedł zatem czas, aby ponownie przemyśleć konfigurację ustawień zapory sieciowej. Windows Server 2008 oferuje również funkcję User Access Control, którą można spotkać także w systemie Windows Vista®. Ogranicza ona przywileje, które otrzymujemy automatycznie jako użytkownicy w roli administratora. Funkcje te mają wpływ na wszystkie wersje SQL Server.

 Do początku strony

Na zakończenie

Bezpieczeństwo nadal stanowi obszar przemyślanych ulepszeń programu SQL Server. Wzbogacone funkcje szyfrowania i uwierzytelniania zapewniają nowe możliwości, a nowy system inspekcji oraz funkcja Policy-Based Management SQL Server 2008 stanowią narzędzia pomocne w monitorowaniu stanu zgodności z wymogami bezpieczeństwa.

O autorze

Rick Byham dołączył do firmy Microsoft w 1995 roku. Pracował jako SQL Server Support Engineer w dziale Customer Support Services, a następnie wstąpił do zespołu SQL Server w Microsoft Learning. W 2003 roku jako autor dokumentacji technicznej przeniósł się do zespołu SQL Server Books Online, w którym aktualnie odpowiada za dokumentację dotyczącą zabezpieczeń. Można skontaktować się z Rickiem pod adresem rick.byham@microsoft.com.

Do początku strony