Portal Zarządzających Bezpieczeństwem

Ostatnio problemy dotyczące bezpieczeństwa baz danych zalały media oraz Internet. Rozpoczynając od robaka Slammer, a kończąc na oszustach, którzy dotarli do numerów ponad 8 milionów kart kredytowych.

Siadam więc wygodnie i sam do siebie mówię: „Czy moi administratorzy systemowi zasnęli za kółkiem?” Ponieważ Internet rozkwita i bardziej polegamy na jego wygodzie oraz stosunkowo niskich kosztach systemów informatycznych, staliśmy się bardziej leniwi we wdrażaniu podstawowych praktyk bezpieczeństwa.

Częścią tego problemu jest nacisk, jaki kładą wyższe warstwy amerykańskich firm na dzisiejszych administratorów systemowych. Pytanie zadawane każdemu adminowi systemu jest: „Jak szybko można to zrobić?” a nie „Jak duże jest zagrożenie bezpieczeństwa?”. W świetle bieżących wydarzeń stało się boleśnie oczywiste to, że musimy zmienić nasze myślenie.

Pozwólcie, że zacznę ten artykuł od streszczenia tematu jak powinno się wdrażać polityki bezpieczeństwa (security policies), a następnie przejdę do rzeczywistej konfiguracji systemowej.

Podstawowa struktura zabezpieczeń
Będąc specjalistą ds. zabezpieczeń sieci (Network Security Specialist) ciągle natykam się na firmy, które mają jeden cel „bezpieczeństwo oprogramowania” („software security”). Kładą one tak duży nacisk na mały fragment bezpieczeństwa, że tracą z oczu cały obraz. A całym obrazem jest oczywiście: „bez zbudowania hierarchii zabezpieczeń żadna podstawowa polityka bezpieczeństwa nie będzie skuteczna”!

Zbyt często administratorzy systemowi pozostawieni są sami sobie, a ich zadanie to kontrola bezpieczeństwa systemów im podległym, z małym lub żadnym nadzorem nadrzędnego administratora zabezpieczeń. Wywołuje to następujące pytania:

• Kto sprawdza, że administratorzy systemowi postępują według wytycznych zabezpieczeń?
• W jaki sposób organizacja sprawdza, że administratorzy stosują najnowsze łaty?
• Jaka organizacja zapewnia sprawdzenie najnowszych łat pod kątem powodowania dodatkowych uszkodzeń systemu?

Kto przeprowadza audyty zabezpieczeń w korporacji branej jako całość?

Przykład dobrej, czystej i efektywnej organizacji zabezpieczeń sieci.

Bez odpowiedniej struktury łatwo o chaos, który w przypadku tak ważnego tematu, jakim jest bezpieczeństwo, może przeistoczyć się w kataklizm. Na przykład:

Jim z biura na Wschodnim Wybrzeżu ma aktualne wszystkie łaty, lecz ma niezabezpieczone połączenie z Billem na Zachodnim Wybrzeżu, ponieważ temu drugiemu nie udało się właściwie skonfigurować swojej zapory sieciowej. Sytuacja taka naraża cały system na atak.

Aby zapewnić, że sytuacja taka jak powyższa nie będzie miała miejsca, jedna osoba lub grupa osób powinna spojrzeć na cały obraz.

Teraz, gdy już wygłosiłem tyradę na temat podstawowej organizacji zabezpieczeń, spójrzmy w sposób techniczny na bezpieczeństwo baz danych.

Luki w bezpieczeństwie baz danych (wiele frontów wojny o bezpieczeństwo!)

Generalnie bezpieczeństwo baz danych może zostać rozłożone na następujące kluczowe punkty zainteresowania:

• Bezpieczeńtwo serwera (Server Security)
• Połączenia baz danych (Database Connections)
• Tablica kontroli dostępu (Table Access Control)
• Ograniczenie dostępu do bazy danych (Restricting Database Access).

Bezpieczeństwo serwera
Bezpieczeństwo serwera jest procesem ograniczania rzeczywistego dostępu do samego serwera bazy danych i – moim skromnym zdaniem – jest to najważniejszy aspekt bezpieczeństwa i powinien być dokładnie zaplanowany.

Podstawą jest tutaj: „Nie możesz mieć dostępu do tego, czego nie widzisz.” Z jakiego powodu miałbyś pozwolić całemu światu na oglądanie własnego serwera bazy danych? Nie jest to serwer sieciowy i nie powinno być tu czegoś takiego jak anonimowe połączenie. Teraz ktoś mógłby powiedzieć: „A co, jeśli serwer bazy danych dostarczy informacji na dynamiczne strony WWW?”, ale od razu odpowiem: „Baza danych nigdy nie powinna znajdować się na tym samym komputerze co serwer sieciowy i to nie tylko ze względu na bezpieczeństwo, ale na wydajność!”. Jeśli serwer bazy danych dostarcza informacji do serwera sieciowego, wtedy powinien zostać skonfigurowany, aby dopuszczał połączenia jedynie z tego serwera sieciowego. I oto kolejny punkt naszej dyskusji:

Tutaj Dostęp Zaufanych Adresów IP (Trusted IP Access) ogranicza serwer bazy danych do odpowiedzi na prośby o informacje ze znanych adresów IP serwera sieciowego.

Zaufane adresy IP
Każdy serwer powinien być skonfigurowany tak, aby dopuszczał jedynie zaufane adresy IP. Człowiek nie pozwala, aby ktokolwiek wchodził do jego domu czy rozmawiał z jego dziećmi i w ten właśnie sposób należy wiedzieć kto ma możliwość „mówienia” do serwera bazy danych.

Jeżeli dla serwera sieciowego jest to „back-end”, wtedy jedynie ten adres serwera sieciowego powinien mieć dostęp do serwera bazy danych. Jeśli serwer bazy danych dostarcza informacji do domorosłej aplikacji, która działa w sieci wewnętrznej, wtedy powinien odpowiadać tylko na adresy z tej sieci wewnętrznej.

Należy również zauważyć tanią mentalność hostingu baz danych WWW na tym samym serwerze, który zawiera wewnętrzne informacje bazy danych. Dlaczego miałbyś mieć wewnętrzne informacje w strefie zaufanej DMZ, nie nazywa się ona DMZ bez przyczyny.

Połączenia baz danych
W dzisiejszych czasach, z dużą ilością dynamicznych aplikacji, kuszącym jest umożliwienie natychmiastowych nieautoryzowanych aktualizacji bazy danych. Takiemu lenistwu mówię „nie!”. Jeśli masz zamiar umożliwić użytkownikom robienie aktualizacji bazy danych poprzez stronę WWW, upewnij się, że wszystkie aktualizacje mają atesty, czyli czy są gwarantowanej jakości i bezpieczne. Na przykład: upewnij się, że usuwasz wszystkie możliwe kody SQL z tego, co dostarczasz użytkownikowi.

Jeżeli jesteś jednym z tych administratorów, którzy czują, że muszą używać połączeń ODBC, upewnij się, że każde połączenie korzysta ze swojego własnego użytkownika przy dostępie do współdzielonych danych. Skóra mi cierpnie, gdy widzę, że konto użytkownika „sa” jest używane dla każdego połączenia i źródła danych na serwerze. Czy każdy pracownik firmy ma klucze do każdego pokoju w budynku?

Tablica kontroli dostępu
Tablica kontroli dostępu jest prawdopodobnie jedną z najbardziej pomijanych form zabezpieczenia bazy danych z powodu nieodłącznych problemów z jej zastosowaniem. Poprawne użycie tablicy kontroli dostępu wymaga współpracy zarówno administratora systemu oraz producenta bazy danych, a wszyscy wiemy, że „współpraca” jest obcym słowem w przemyśle IT.

Przykładem może być zezwolenie na publiczny dostęp odczytu informacji przypisanych do użytkownika. Jeśli użytkownik wpisał właśnie informacje, dlaczego miałby na nie patrzyć w ciągu tej samej sesji? Albo jeżeli tablica jest używana jako odniesienie systemowe, dlaczego miałaby mieć inne zezwolenia poza tymi do odczytu?

Ograniczenie dostępu do bazy danych
Teraz, gdy zakończyliśmy podstawowy opis bezpieczeństwa baz danych, chciałbym wejść nieco głębiej w temat bezpieczeństwa serwera. Głównie w temat dostępu do sieci systemu, a konkretnie w internetowe bazy danych, ponieważ to one są ostatnio celami ataków. Wszystkie aplikacje aktywowane w sieci mają porty, na których nasłuchują – wiem, że jest to dość podstawowa informacja dla większości osób, ale muszę do powiedzieć wszystkim początkującym.

Większość cyber-przestępców (zawsze powstrzymuję się przed używaniem określeń „haker” czy „cracker”) robią prosty „skan portów” w poszukiwaniu portów, które są otwarte i których popularne systemy baz danych używają domyślnie. Teraz ja powiem domyślnie: możesz zmienić porty, na których nasłuchuje dana usługa i uważam, że jest to świetny sposób, aby pozbyć się przestępców.

Najpierw próbują oni określić czy komputer jest dostępny na konkretnym adresie. Robią to poprzez pingowanie systemu, czyli otwierają wiersz poleceń i wpisują „ping”.

Reply from 127.0.0.1: bytes=32 time<10ms TTL=128
Reply from 127.0.0.1: bytes=32 time<10ms TTL=128
Reply from 127.0.0.1: bytes=32 time<10ms TTL=128
Reply from 127.0.0.1: bytes=32 time<10ms TTL=128

Ping statistics for 127.0.0.1:
Packets: Sent = 4, Received = 4, Lost = 0 (0%
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms

Przykład polecenia „ping”.

Przestępca teraz wie, że na tym adresie jest system, który odpowiada. Aby temu zapobiec, należy wyłączyć wszystkie pakiety ICMP. Sprawi to, że prośby ping nie otrzymają odpowiedzi.

Istnieje wiele sposobów, aby zapobiec otwartemu dostępowi do Internetu i każdy system z bazą danych ma swój własny zestaw unikatowych funkcji, tak samo jak ma go każdy system operacyjny. Pokrótce opiszę kilka z tych metod:

• Zaufane adresy IP – Serwery UNIX są skonfigurowane w taki sposób, aby odpowiadały jedynie na pingi z listy zaufanych hostów. W UNIXie robi się to poprzez konfigurację pliku rhosts, który ogranicza dostęp do serwera do listy określonych użytkowników.
• Wyłączenie konta serwera – Jeśli zawiesisz ID serwera po trzech próbach wpisania hasła, plany atakujących zostają udaremnione. Bez zawieszenia ID użytkownika, atakujący może uruchomić program, który generuje miliony haseł, aż do momentu, gdy odnajdzie kombinację ID użytkownika i hasła.
• Specjalne narzędzia – Produkty takie jak RealSecure by ISS wysyłają alert, gdy serwer zewnętrzny próbuje naruszyć zabezpieczenia systemu.

Oracle ma cały arsenał metod uwierzytelniania:

• Zabezpieczenie Kerberos – Ten popularny, oparty na „kluczu”, system uwierzytelniania pozwala uniknąć wielu zagrożeń bezpieczeństwa.
• Wirtualne, prywatne bazy danych – Technologia VPD może ograniczyć dostęp to wybranych rzędów tablicy.
• Zabezpieczenia oparte na rolach – Uprawnieniaobiektów mogą zostać pogrupowane według ról, które następnie mogą być przypisane do określonych użytkowników.
• Zabezpieczenia typu „grant-execute” – Uprawnienia wykonania procedur mogą być ściśle połączone z użytkownikami. Kiedy użytkownik wykonuje procedurę, otrzymuje dostęp do bazy danych, ale jedynie w zakresie danej procedury.
• Serwery uwierzytelniania – Serwery bezpiecznego uwierzytelniania dostarczają pozytywnej identyfikacji dla użytkowników zewnętrznych.
• Zabezpieczenia dostępu do portów – Wszystkie aplikacje Oracle są ukierunkowane na nasłuchiwanie konkretnego numeru portu na serwerze. Tak jak każdy standardowy serwer HTTP, tak i Oracle Web Listener może zostać skonfigurowany tak, aby ograniczał dostęp.

Mam nadzieję, że udało mi się poszerzyć temat bezpieczeństwa bazy danych i że być może pomogło to wyeliminować lub choćby zmniejszyć ryzyko ataku przestępcy, szukającego „łatwego łupu”.

Źródło: www.governmentsecurity.org

Tłumaczenie: Julianna Wieczorek, Częstochowa