Bezpieczeństwo i Microsoft

Bezpieczeństwo w SQL Server 2000 - biblioteki protokołów sieciowych.
Na podstawie http://www.databasejournal.com/features/mssql/article.php/3334851
Ciekawym zjawiskiem w obecnej informatyce jest wzrost roli bezpieczeństwa systemów, które traktowane jest na równi ze wskaźnikami efektywności i kosztów. Obecnie każda nowa technologia jest oceniana z punktu widzenie bezpieczeństwa wykorzystania. Poważny wpływ na bezpieczeństwo ma wybór biblioteki sieciowej (Net Libraries) realizującej połączenie serwera (w tym przypadku MS SQL Sever) z klientem.
Wymiana informacji między C<->S w przypadku MS SQL ma miejsce w formie pakietów Tabular Data Streams (TDS). Pakiety te są czytane/wysyłane przez: SQL Server OLE DB Provider, ODBC Driver lub DB-Library DLL i przekazywane do biblioteki Net Library DLL. Biblioteka ta umożliwia wymianę pakietów TDS między procesami (IPC-interprocess communication) serwera i klienta. Dlatego w większości przypadków (za wyjątkiem wymiany poprzez shared memory lub local procedure call) wymagany jest jakiś protokół sieciowy do realizacji tej wymiany poprzez sieć. Z tego powodu większość dedykowanych komponentów biblioteki jest nazwa zgodnie z protokołem sieciowym realizującym tę wymianę np. TCP/IP, IPX/SPX (NWLink), Apple Talk lub Banyan Vines. Są też komponenty uniwersalne np. Named Pipes lub Multiprotocol Net Libraries mogące wybrać jeden powyższych protokołów. W SQL 2000 wprowadzono również nowy protokól SuperSocket Net Library (jest to otoczka służąca do obudowania pozostałych protokołów w mechanizm Secure Socket Layer - SSL). Do prawidłowej współpracy między C/S obie strony muszą wybrać zgodne protokoły wymiany. Dobrym zwyczajem (praktyką) jest zminimalizowanie ilości realizowanych przez oba końce protokołów, choćby z uwagi na bezpieczeństwo i wydajność (zminejsza się czas na uzgodnienie wspólnego protokołu i nawiązanie połączenia). Przy wyborze komponentu biblioteki należy się kierować następującymi kryteriami:
Wydajność - najszybsze są protokoły TCP/IP i IPX/SPX (pominięcie rdzeniowego komponentu Net Library Router),
Zdolność do obsługi wielu instancji bazy na jednym komputerze (named instances),
Autentykacja: a) zależność od bezpiecznego kanału serwer/klient - biblioteki Named Pipes i Multiprotocol wymagają do swej pracy (przed próbą autentykacji na poziomie MS SQL) istnienie bezpiecznego połączenia na bazie autentykacji poprzez mechanizm Windows. W konsekwencji te metody są dobre tylko w przypadku łączenia do serwera w obrębie jednej domeny lub domen zaufanych. Utrudniają one połączenie z serwerem MS SQL w środowisku rozproszonym z drugiej jednak strony jest to jeszcze jeden poziom zabezpieczenia b) wsparcie dla delegowania, ma to miejsce w przypadku kiedy uruchamiane są zapytania rozproszone,
Wsparcie szyfrowania - do skutecznego zaszyfrowania transmisji można wykorzystać Multiprotocol Net Library (jak w poprzednich wersja serwera) obecnie można skorzystać dodatkowo z protokołu SSL (poprzez SuperSocket Net Library)
Multiprotocol Net Library wykorzystuje API najnowszej biblioteki szyfrowania (można ją włączyć przez check-box "Enable encryption", należy pamiętać aby obie strony miały tę opcję włączoną). Protokół SuperSocket oferuje dodatkową możliwość: silniejszej enkrypcji, integralności komunikatów oraz autentykacji przez serwer. Jest on jednak trochę trudniejszy do skonfigurowania: wymagany jest serwer certyfikatów w postaci Certificate Authority (CA) do wystawiania certyfikatów oraz konfiguracja u kilenta tak, by zaufał certyfikatom wystawionym przez CA. Informacje o implementacji szyfrowania SSL do komunikacji między SQL Server i klientami można znaleźć: http://support.microsoft.com/default.aspx?scid=kb;en-us;276553&sd=tech i http://support.microsoft.com/default.aspx?scid=kb;EN-US;316898). Decyzje do podjęcia:
Rodzaj i typ CA. Można wybrać między CA na bazie platformy Windows 2000 / 2003 (idealne rozwiązanie dla domeny, lub domen zaufanych) lub komercyjny np. Verisign lub Thawte (dla użytkowników spoza zakresu zarządzania administratora MS SQL, tym bardziej, że wielu z nich korzysta i ufa z certyfikatów wystawionych przez firmy trzecie, wadą jest konieczność kupienia certyfikatu),
Kupienie ceryfikatu dla serwera (autentykacja na poziomie serwera) i jego instalacja systemie Windows na którym jest zainstalowany MS SQL Sever. W przypadku CA bazującym na Windows jest to proste: należy się zalogować do MS SQL Servera na konto serwisowe MSSQLServer i zażądać certyfilatu poprzez połączenie się z CA serverem w przeglądarce (adres: http://CAserverName/certsv),
Restart SQL Server Service (certyfikat musi być wczytane po każdym starcie serwisu),
Konfiguracja na każdym kliencie wystawcy CA jako Trusted Root Authority (zaufany główny ośrodek wystawiania klucza). Dzieje się to za pośrednictwem exportu z komputera na którym jest zainstalowany MS SQL tzw. autoryzacji zaufanego głównego wystawcy certyfikatów (Trusted Root Certificate Authority) i importu tej autoryzacji na komputerze klienta,
W przypadku, gdy serwer 200x goszczący MS SQL ma zainstalowane wiele certyfikatów, to trzeba podać który z nich jest używany przez MS SQL. Dzieje się to przy pomocy SETCERT.EXE (z Res.Kit do MS SQL Server 2000), lub poprzez ręczne poprawienie rejestru,
Wybranie opcji check-box "Force protocol encryption" w Server Network Utility powoduje szyfrowanie wszystkich wchodzących do serwera połączeń, lub użycie tej samej opcji na kliencie co skutkuje szyfrowaniem tylko połączeń przez niego inicjowanych.
Generalnie mówiąc należy używać biblioteki sieciowej TCP/IP Net Library z uwagi na wydajność i bezpieczeństwo, które oferuje. Można również zmienić domyślny port TCP 1433 i wybrać opcje "Hide server" (wtedy zmieni się port na 2433) i zmienić te ustawienia u klienta. Nie jest to zalecane przez MS (KB 308091 and 814064). Należy pamiętać o zablokowaniu w sieci portu UDP 1434 (Slammer).