Podziel się opinią o serwisie
popularne komentowane nowości

popularne

Najczęściej czytane

więcej...

Biblioteka Wiedzy poleca

Kopia bezpieczeństwa a odzyskiwanie danych w środowisku VMware

Dokument obejmuje zagadnienia związane z praktyczną realizacją kopii bezpieczeństwa środowisk wirtualizowanych o dużej skali wdrożenia. W takich...
pobierz »

Biometria głosowa: efektywność, bezpieczeństwo, łatwość korzystania

Zwiększenie liczby oszustw i kradzieży tożsamości wzbudza coraz większe zaniepokojenie klientów możliwością utraty danych osobowych i poufnych danych....
pobierz »

IBM BladeCenter - IT w pudełku

Rozwiązanie IBM BladeCenter integruje serwery blade, pamięć masową i przełączniki sieciowe w jednej obudowie. Zapewnia przy tym redukcję kosztów...
pobierz »

Więcej bezpłatnych raportów w serwisie
powiększ tekst >
AKTUALNOŚCI

Jak zabezpieczyć serwer MS SQL?

31 sierpnia 2010

Paweł Krawczyk
Instancje Microsoft SQL Servera zwykle nie są eksponowane w Internecie, przynajmniej w teorii. SANS w przeszłości kilkukrotnie informował o zwiększonej aktywności automatycznych skanerów poszukujących otwartego portu 1433, używanego przez SQL Server. Co więcej, włamywacze niejednokrotnie mają możliwość prowadzenia "konwersacji" z bazą danych za pośrednictwem aplikacji webowej, wstrzykując do niej kod SQL. Dlatego warto zapoznać się z kilkoma zasadami bezpiecznej konfiguracji serwera Microsoft SQL.

Uwierzytelnienie użytkowników SQL

SQL Server używa kont użytkowników do kontroli dostępu do tablic oraz szeregu innych operacji na bazie. Historycznie baza danych posługiwała się swoją własną listą użytkowników, wśród których najistotniejszy był użytkownik "sa" (SQL administrator). Z punktu widzenia bezpieczeństwa preferowany powinien być tryb uwierzytelnienie Windows (Windows Authentication), wprowadzony w SQL Server 2000, który opiera się o hasła systemu Windows, na którym działa SQL Server. Dzięki temu w bazie będą obowiązywać te same ograniczenia dotyczące np. długości haseł co w systemie, a lista użytkowników będzie spójna - np. skasowanie użytkownika z systemu spowoduje, że straci on również dostęp do bazy.

W przypadku aplikacji ASP.NET zaletą jest także to, że stosując Windows Authentication nie trzeba podawać nazwy użytkownika i hasła w kodzie źródłowym skryptu ASP, skąd mogą wycieknąć w razie włamania.

Natywne hasła SQL Server są nadal dostępne w trybie mieszanym (Mixed Mode). Jeśli korzystamy z tej opcji to kluczowe jest stosowanie silnych haseł. Z konta SA nie należy korzystać do codziennej pracy (chociaż tak jest łatwiej). Należy traktować go jako konto specjalne, służące wyłącznie do wykonywania czynności o charakterze administracyjnym, jak zakładanie użytkowników lub zarządzenie ich uprawnieniami do poszczególnych baz i tablic. Szczególnie rażącym błędem jest natomiast stosowanie konta SA do uwierzytelnienia aplikacji z hasłem zapisanym w jej kodzie źródłowym.

Być na bieżąco

Baza SQL nie działa w próżni - na wypadkowe bezpieczeństwo aplikacji wpływ ma także bezpieczeństwo aplikacji, systemu operacyjnego, serwera Internet Information Server (IIS) oraz środowisk programistycznych takich jak .NET Framework. Wszystkie te komponenty należy aktualizować tak szybko jak to jest możliwe, po publikacji poprawek przez Microsoft, autora aplikacji lub bibliotek zewnętrznych. Należy pamiętać, by przed instalacją poprawek tworzyć kopię zapasową bazy.

Aktualny stan bezpieczeństwa systemu można porównać do zaleceń producenta za pomocą narzędzi takich jak SQL Server 2005 Best Practices Analyzer oraz Microsoft Baseline Security Analyzer.

Poza instalacją aktualizacji warto także być na bieżąco z informacjami publikowanymi na blogu SQL Security Microsoftu. Można się tam dowiedzieć na przykład jaka jest rada Microsoftu na zwalczanie automatycznych ataków SQL injection oraz poznać najnowsze rozwiązania techniczne wprowadzane do SQL Servera przez producenta.


12  dalej »
Wystaw ocenę:
    Średnia ocena (liczba głosów: 0)
wydrukuj wydrukuj wyslij do znajomegowyślij do znajomego

Komentarze

~Krzysztof Kotowicz

  • ocena: brak oceny
  • IP: 83.26.107.141
  • 31-08-2010, 14:49

Artykuł dobry, mam tylko uwagę do podlinkowanego materiału z MS SQL Security - http://blogs.msdn.com/b/sqlsecurity/archive/2010/04/27/blocking-automated-sql-injection-attacks-using-regular-expressions.aspx. Wyrażenia regularne (jako przykład blacklistingu) nie są wg mnie dobrym sposobem obrony przed atakami SQL injection - czasem zadziałają (jeśli atak załapie się na regułki), ale wystarczy drobna zmiana w technice ataku i reguły są już bezbronne.