pobierz plik referatu

Transkrypt

Rozdział monografii: 'Bazy Danych: Rozwój metod i technologii', Kozielski S., Małysiak B., Kasprowski P., Mrozek D. (red.), WKŁ 2008
Rozdział 1
w
Przegląd zagrożeń dla systemów baz danych oraz
sposoby ochrony
w
1 Wstęp
da
.b
w
Streszczenie. Jednym z stale aktualnych problemów w systemach informatycznych jest odpowiednie zabezpieczenie tychże systemów przed nieupoważnionym dostępem, a także przede wszystkim przed kradzieżą oraz manipulacją danych. Spośród możliwych rodzajów zagrożeń w rozdziale zwrócono uwagę szczególnie na te, które mają na celu ataki na bazy danych. Niniejsze opracowanie przedstawia również możliwości ochrony baz danych.
Dane zgromadzone w bazach danych, powinny – i najczęściej są – chronione przed nieuprawnionym dostępem, utratą czy manipulacją. Chronienie danych jest nie tylko kwestią polityki czy wizerunku organizacji zajmującej się zarządzaniem nimi, jest także obowiązkiem
regulowanym przez przepisy prawne.
Bazy danych są obecnie zazwyczaj częścią trójwarstowej architektury, przykład której
znajduje się na rysu. 1. Architektura trójwarstwowa jest rozszerzeniem architektury dwuwarstwowej klient-serwer o dodatkową warstwę pośrednią, czyli warstwę aplikacji.
pl
s.
Rys. 1. Architektura trójwarstwowa.
Anna Kotulla
Politechnika Śląska, Instytut Informatyki, ul. Akademicka 16, 44-100 Gliwice, Polska
email:[email protected]
(c) Copyright by Politechnika Śląska, Instytut Informatyki, Gliwice 2008
A.Kotulla
w
Spośród znanych zagrożeń dla systemów informatycznych, wyodrębnić można takie,
które odpowiednio dopasowane bezpośrednio dotyczyć mogą również baz danych, przykładem mogą tu być narzędzia typu rootkit, omówione w punkcie 2.4. Inną grupę stanowią
zagrożenia typowe dla systemów zawierających bazy danych, jak wstrzykiwanie kodu
SQL, omówione w punkcie 2.3.
W rozdziale scharakteryzowane zostały te zagrożenia (które wykorzystane mogą być
w sposób celowy), dotyczące bezpośrednio baz danych [4], [8], [9], [10]:
− łamanie haseł użytkowników,
− przepełnienie bufora,
− ataki Denial of Service,
− wirusy, robaki i trojany,
− narzędzia typu rootkit,
− wstrzykiwanie kodu SQL.
W drugiej częsci wskazane zostały możliwości przeciwdziałania wymienionym zagrożeniom.
Systemy zarządzania bazami danych zawierają w kolejnych wersjach coraz więcej dodatkowych komponentów, co powoduje, że czasem trudno jest jednoznacznie rozgraniczyć,
co jest, a co nie jest bazą danych – jako przykład można podać tu środowisko Oracle, z którym – w zależności od dystrybucji - wraz z bazą danych otrzymuje się bogaty zestaw narzędzi i przykładowych aplikacji.
Niektóre zagrożenia próbują wykorzystywać potencjalne luki wynikające z architektury
konkretnego systemu zarządzania bazami danych (SZBD). W przypadku baz danych
Oracle, przykładem może być tu omówiony w punkcie 2.2 atak na TNS Listener. Innym
przykładem jest podejmowanie prób autentyfikacji z wykorzystywaniem typowych użytkowników (czasem nawet z standardowo im przypisanymi hasłami), w zależności od tego,
jak SZBD został rozpoznany. W ramach zabezpieczania SZBD należy w tym przypadku
przypisać nowe hasła i zablokować niepotrzebnych użytkowników.
da
.b
w
w
2 Przegląd zagrożeń typowych dla baz danych
2.1 Nieuprawniony dostęp, łamanie haseł
pl
s.
Zagrożenia dla baz danych [8] wynikają z zaniedbań organizacyjnych (np. brakujące czy
nieaktywne mechanizmy ochrony, niewystarczające planowanie i przetestowanie systemu),
z błędów ludzkich (np. błędy w administracji, przypadkowa manipulacja danych), z zawodności technologii (np. niedostępność bazy danych, utrata integralności danych) oraz z zamierzonych działań – przegląd których przedstawiono w tym rozdziale.
Zdobycie hasła, najlepiej użytkownika z dużymi uprawnieniami, jest prostą drogą do zdobycia dostępu do bazy danych. Próby łamania haseł [1], [9], [10] podejmowane są poprzez:
− atak metodą siłową (ang. brute force attack), polegający na sprawdzaniu wszystkich
możliwych kombinacji znaków mogących wystąpić w haśle. Efektywność metody
zależy od długości hasła i złożoności algorytmu szyfrowania oraz mocy obliczeniowej komputera.
− atak słownikowy (ang. dictionary attack), wykorzystujący słownik haseł – większość
użytkowników stosuje hasła mające jakieś realne znaczenie. Inną możliwością jest
14
Przegląd zagrożeń dla systemów baz danych oraz sposoby ochrony
−
w
−
−
w
słownik złożony z potencjalnych haseł (np. standardowe hasła w bazach danych
przydzielane podczas tworzenia tych baz).
atak za pomocą tęczowych tablic [6] (ang. rainbow table attack), czyli przygotowanej bazy kryptogramów (ang. hash) wykorzystywaną w łamaniu haseł. Wyliczenie
tęczowych tablic dla możliwych haseł i używanych algorytmów, jest wprawdzie
akcją czasochłonną, ale jednorazową. P. Oechslin zaproponował również algorytmy,
które pomimo tego, że używaja ułamka możliwych kryptogramów, gwarantują
otworzenie ok. 90% haseł w parę minut.
sniffing, czyli przechwycenie hasła bądź jego kryptogramu w sieci, za pomocą specjalnych programów (ang. sniffer).
keylogger, służący do protokołowania naciskanych klawiszy i umożliwiający w ten
sposób również wykradanie haseł. Keyloggery dzielą się na sprzętowe (z własną
pamięcią, podłaczane np. przez USB, czy w formie przejściówki) oraz programowe.
śledzenie klawiatury, odbywające się za pomocą urządzeń rejestrujących, takich jak
kamera.
przeszukiwanie komputera / serwera. Czasem hasła mogą być znalezione w postaci
niezaszyfrowanej, np. w skryptach, plikach historii shella, plikach konfiguracyjnych.
−
−
w
Tabela 1. Algorytmy kryptograficzne używane do szyfrowania haseł w wybranych bazach
danych
da
.b
Baza danych
Algorytmy kryptograficzne używane do szyfrowania haseł
Oracle
DES (wersje 7-10g R2) [11]
SHA-1 (od wersji 11g R1) [11]
MS SQL
SHA-1 (wersja 2000, 2005) [3],[12]
Server
Oracle
pl
s.
Metody łamania haseł zostały przytoczone jako pierwsze, ponieważ niestety w dalszym
ciągu hasła są zbyt często na tyle proste (składające się z niewielu znaków, nie zawierające
znaków specjalnych, cyfr), że przedstawione metody mogą poradzić sobie z nimi bez większego problemu.
W przypadku licznych baz danych użytkownicy są po prostu dodatkowymi użytkownikami systemu operacyjnego, hasła są również pamiętane w systemie operacyjnym i tam
przede wszystkim powinny być chronione. Z wiodących baz danych Oracle i MS SQL
Server (tabela 1) zarządzają same użytkownikami, dlatego te dwa systemy zostaną dokładniej opisane.
W przypadku haseł, Oracle [3], [11] używa dla wersji 7-10g R2 algorytmu Data Encryption
Standard (DES), tworząc dla konkatenacji postaci <użytkownik><hasło> kryptogram 8bitowy, który pamiętany jest w tablicy SYS.USER$. Przykładowo, kombinacje sys/temp1
oraz system/p1 mają tę samą wartość kryptogramu 2E1168309B5B9B7A. Hasła mogą mieć
długość do 30 znaków, nie są rozróżniane małe i wielkie litery. Od wersji 11g R1
opcjonalnie można stosować hasła długości do 50 znaków, a dzięki stosowaniu algorytmu
SHA-1 także z rozróżnienem na duże/małe litery. Aby utrudnić złamanie haseł, stosuje się
tzw. salt (w j. angielskim sól), czy liczbę losową, która konkatenowana jest przed zaszyfrowaniem z hasłem. Technika ta stosowana jest również od wersji Oracle 11gR1.
Jednym z najbardziej znanych programów do ataków typu brute force, jest Orabf, który
jest w stanie przeliczyć ponad 1.000.000 haseł na sekundę. Przy założeniu, że hasło
15
A.Kotulla
ma długość 5 znaków i składa się z liter (26-znakowy alfabet), istnieje 11881376 możliwych haseł, do wyliczenia których współczesne komputery nie potrzebują nawet minuty.
Microsoft SQL Server
w
W przypadku haseł, Microsoft SQL Server [3] używa dla wersji 2000 oraz 2005 algorytmu
SHA-1. Dla wersji 2005, kryptogram pamiętany jest w tablicy sysxlogins i wyznaczany
jest przez funkcję haszującą konaktenację <salt> + <hasło>. Jako salt używany jest wynik
funkcji rand(), hasło składa się z znaków unicode (możliwe duże i małe litery). Maksymalna długość hasła to 128 znaków.
Dostępne są darmowe programy sprawdzające złożoność haseł dla Microsoft SQL
Server, jak NGSSQLCrack czy SQLdict.
w
2.2 Ataki Denial of Service
da
.b
w
Ataki Denial of Service (DoS) [4] przeprowadzane są w celu uniemożliwienia uprawnionym użytkownikom dostępu do usług informatycznych. Ataki DoS dzielą się na dwie grupy
pod względem sposobu działania:
− Ataki DoS mające na celu wyczerpanie zasobów bazy danych, która nie może wtedy
oferować żadnych usług.
Dla Oracle może to być próba zakończenia Transparent Network Substrate (w skrócie TNS) Listener, za pomocą przekazanego polecenia stop. TNS Listener jest procesem nasłuchu (od ang. listen) serwera bazy danych (standardowy port 1521), odbierającym żądania nawiązania połączenia z bazą danych. Dalsza komunikacja po
nawiązaniu połączenia odbywa się bez udziału procesu nasłuchu.
− Ataki DoS zaburzające komunikację pomiędzy bazą danych a potencjalnymi klientami.
Dla przykładu, biuletyn zabezpieczeń firmy Microsoft (ang. Microsoft security
bulletin) MS99-059 opisuje błąd typu DoS na poziomie protokołu sieciowego w SQL
Server 7, występujący wówczas, gdy pakiet TDS (ang. Tabular Data Stream) wysyłano z informacją o wielkości pakietu w nagłówku mniejszą od minimalnej dopuszczalnej wartości.
Ataki DDoS (ang. Distributed Denial of Service) wykorzystują liczne komputery,
tzw. zombi, do przeprowadzenia ataku DoS.
pl
s.
2.3 Wstrzykiwanie kodu SQL
Wstrzykiwanie kodu SQL (ang. SQL Injection) [1],[4] polega na zmanipulowaniu przekazanego bazie danych do wykonania kodu SQL w taki sposób, aby skłonić bazę danych do
wykonania dodatkowych bądź zmienionych poleceń. Powodzenie tego typu ataków można
wykluczyć, a przynajmniej znacznie ograniczyć poprzez sprawdzenie wprowadzonych danych przed wykonaniem polecenia SQL.
Przed zmanipulowanym kodem SQL należy chronić się także, kiedy przekazany jest
w mniej typowej formie – dla przykładu możliwe jest zawarcie poleceń SQL w kodach
kreskowych i wstrzykiwanie kodu SQL przy skanowaniu etykiet.
Poniższy przykład ilustruje [1] wstrzyknięcie dodatkowego kodu dla MS SQL Server.
Załóżmy, że w bazie danych istnieje tablica autorzy, zawierająca pola id, imie oraz
nazwisko. Zapytanie SQL, zwracające dane dla autorów o imieniu Jan i nazwisku
Kowalski może wyglądać tak:
16
select id, imie, nazwisko from autorzy where imie = 'Jan' and nazwisko
= 'Kowalski'
Ważny - i stanowiący potencjalne zagrożenie - w tym przypadku jest fakt, że imię i nazwisko w zapytaniu ograniczone jest znakiem ', będącym dla MS SQL Server znakiem
kończącym napis. Jeżeli aplikacja przekaże dalej zapytanie dla imienia J'an (i poprzedniego nazwiska Kowalski), wówczas zapytanie wygląda tak:
w
select id, imie, nazwisko from autorzy where imie = 'J'an' and
nazwisko = 'Kowalski'
Baza danych zwraca w tym przypadku błąd, ponieważ jako imię przekazane zostało
J (ze względu na kończący znak '), natomiast dalszą część tekstu baza danych próbuje
interpetować. W przykładzie baza danych nie potrafi zinterpretować an:
w
Server: Msg 170, Level 15, State 1, Line 1
Line 1: Incorrect syntax near 'an'.
w
Samo zwrócenie takiego komunikatu o błędzie jest sygnałem, że baza danych może być
podatna na iniekcję SQL w tym miejscu. Jeżeli jednak jako imię podstawione zostanie
polecenie J'; drop table autorzy--, wówczas baza danych wykona poprawne składniowo polecenie drop table autorzy i skasuje tabelę autorzy.
2.4 Narzędzia typu rootkit
da
.b
Mianem narzędzi typu rootkit [5], [10], potocznie nazywanych rootkitami, określane są zestawy narzędzi używanych po włamaniu do systemów komputerowych, aby ukryć ślady włamania oraz obecność intruza, np. próby logowania, dodatkowe elementy – jak utworzonych
przez intruza użytkowników, czy procesy.
Tabela 2. Wybrane podobieństwa pomiędzy poleceniami systemu operacyjnego (Linux)
oraz bazami danych, za [10]
System
operacyjny
ps
Oracle
MS SQL Server
list
application;
select * from
sysprocesses;
select * from
view;
select * from view;
exec procedure
Postgres
select * from
pg_stat_activity;
pl
s.
select *
from
v$process;
execute
select *
from
view;
exec
procedure
kill
alter
<id_procesu> system
kill
session
’12,55’
DB2
select * from
view;
execute
procedure;
force
SELECT @var1 =
application
<id_procesu>
(<id_procesu>) FROM sysprocesses
WHERE
nt_username='andrew'
AND
spid<>@@spidEXEC
('kill '+@var1);
Pierwsze narzędzia typu rootkit pojawiły się dla systemów operacyjnych. Jednak bazy
danych są również podatne na taki rodzaj ataków, ponieważ posiadają podobne elementy,
będące celami narzędzi typu rootkit. Zarówno dla baz danych jak i dla systemów operacyj17
A.Kotulla
w
nych istnieją użytkownicy, procesy, zadania, wykonywalny kod. Przykład poleceń i struktur występujących w systemach operacyjnych oraz w bazach danych podano w tabeli 2.
Pierwsze generacje narzędzi typu rootkit dla systemów operacyjnych ukrywały dodatkowych użytkowników - to samo może zdarzyć się w przypadku bazy danych Oracle [5],
która pamięta użytkowników w tabeli systemowej SYS.USER$. Większość narzędzi administracyjnych (np. Oracle Enterprise Manager, Oracle Gird Control, Quest SQL Navigator,
Quest TOAD) korzysta jednak nie z tabeli SYS.USER$ bezpośrednio, ale z perspektyw (ang.
views) DBA_USERS oraz ALL_USERS. Narzędzie typu rootkit będzie się więc starało
zmodyfikować te perspektywy dodając dodakowy warunek w ten sposób, aby nie pokazywały dodanych użytkowników, np. dopisując:
AND U.USER# <> numer_dodatkowego_użytkownika
da
.b
w
w
Narzędzia typu rootkit dla baz danych Oracle dzielą się na następujące grupy [5]:
− Pierwsza generacja
Narzędzia modyfikują obiekty słownika danych lub tworzą nowe. Są stosunkowo
proste do wykrycia, przy regularnym porównywaniu sum kontrolnych obiektów
w bazie danych z oryginalnymi wartościami.
− Druga generacja
Narzędzia typu rootkit wykorzystwać będą kompilację PL/SQL do kodu
wewnętrznego lub mechanizm wirtualnych prywatnych baz danych VPD
(ang. Virtual Private Database). Możliwe do wykrycia pod warunkiem znajomości
sum kontrolnych plików zewnętrznych lub posiadania dodatkowych uprawnień.
− Trzecia generacja
Podobne do narzędzi typu rootkit jądra dla systemów operacyjnych, czy w przypadku
Oracle modyfikujące obiekty bazy danych bezpośrednio w obszarze SGA. Narzędzia
tej generacji będą bardzo trudne do wykrycia.
2.5 Błędy przepełnienia bufora. Trojany, robaki, wirusy.
pl
s.
Przepełnienie bufora (ang. buffer overflow) [1], [4] jest błędem polegającym na załadowaniu do wyznaczonego obszaru pamięci zwanego buforem większej niż przewidziana ilości
danych. W tej sytuacji następuje przepełnienie stosu i wykonany może być dowolny przekazany kod. Aby ustrzec się przed tego rodzaju błędami, konieczna jest weryfikacja rozmiaru przyjmowanych danych.
Błędy umożliwiające przepełnienie bufora często wykorzystywane są przez omówione
poniżej złośliwe oprogramowanie.
Trojany, robaki i wirusy zostały ujęte we wspólnym podpunkcie, ponieważ są kategorią
złośliwego kodu, wykorzystującego jakieś luki, np. przepełnienie bufora.
Wirus [14] definiowany jest jako kod programu, który rozmnaża się. Obecnie termin wirus odnosi się do wszystkich rodzajów szkodliwego oprogramowania lub określa wszystkie
„szkodliwe zmiany” powstałe w wyniku działania szkodliwego programu w zaatakowanym
systemie.
Robak [14] uznawany jest za podkategorię wirusów. Jest programem komputerowym
rozprzestrzeniającym się samodzielnie i nie infekującym innych plików. Instaluje się
na komputerze ofiary i szuka sposobu rozprzestrzeniania się.
Trojan [14] jest pozornie użytecznym programem, który nie potrafi samodzielnie się
rozprzestrzeniać, a jego celem jest wykonanie jakieś szkodliwej czynności na komputerze
ofiary.
18
Jednym z bardziej znanych robaków jest SQL Slammer [4],[13], który atakował bazę
danych MS SQL Server 2000. SQL Slammer ujawnił się w styczniu 2003 (w tym czasie
dostępna była już łata naprawiająca lukę) i szybko się rozprzestrzeniał, szczególnie w Azji.
Robak przeprowadził atak DDoS wykorzystując lukę przepełnienia bufora w SQLDesktop-Engine MSDE. SQL Server, otrzymując pakiet UDP z wiodącym bajtem 0x04,
próbował otworzyć klucz w rejestrze, wskazany w potencjalnie niebezpiecznym ciągu
znaków znajdującym się za wiodącym bajtem. Przykładowo pakiet
w
\x04\x52\x45\x47\x4B\x45\x59
powodował, że SQL Server próbował otworzyć w rejestrze klucz
HKLM\Software\Microsoft\Microsoft SQL Server\REGKEY\MSSQLServer\Curren
tVersion
w
Jeżeli przekazany ciąg znaków był znacznie dłuższy od pokazanego 6-bajtowego pakietu,
występowało przepełnienie wewnętrznego bufora, wykorzystane przez robaka Slammer.
w
2.6 Bezpieczeństwo komputerów klienckich
da
.b
Nie wolno zapominać o aspektach bezpieczeństwa komputerów klienckich [10]. W przypadku, kiedy bazy danych i centralne systemy są dobrze chronione, ataki poprzez komputery klienckie, mające dostęp do baz danych, a czasem nawet, jak to ma miejsce w przypadku
programistów, posiadające stosunkowo duże uprawnienia, mogą być łatwiejszą i skuteczniejszą metodą atakowania baz danych. Dodatkowo często komputery klienckie łączą się
z większą liczbą baz danych, wówczas wszystkie bazy mogą być zagrożone.
Niektóre programy klienckie umożliwiające dostęp do baz danych mogą być łatwo użyte
do wykonania w tle komend SQL w czasie łączenia się z bazą danych. Przykłady dla
potencjalnie niebezpiecznych plików oraz ustawień dla programów klienckich bazy danych
Oracle:
− SQL*Plus – skrypty glogin.sql, login.sql
− TOAD – toad.ini
− SQLWorksheet – sqlplusWorksheetInit.sql
− SQL*Navigator – w rejestrze pod Session_Auto_Run_Script.
Bazy danych podatne są również na specjalnie spreparowane pliki biblioteczne (np. DLL
pod Windows).
Przygotowania i instalacja bazy danych [4], [5]
pl
s.
3 Możliwości zabezpieczenia baz danych
Już podczas przygotowania do instalacji i samej instalacji bazy danych i aplikacji konieczne jest zachowanie obecnie obowiązujących standardów - aby baza danych była możliwie
jak najlepiej zabezpieczona, należy starannie przeprowadzić instalację, wgrać dostępne łaty
i deaktywować wszystkie niepotrzebne elementy (jak użytkowników, funkcje, itp.).
W późniejszym czasie łaty należy wgrywać również regularnie.
Warto również dla pakietów i definicji wyznaczać sumy kontrolne i regularnie je porównywać, wówczas możliwe jest szybkie wykrycie manipulacji. W przypadku sum kontrolnych dla plików często wyznaczane są sumy MD5. Algorytm został opracowany przez
Ronalda Rivesta w roku 1991. Algorytm MD5 [15] z dowolnego ciągu danych generuje
19
A.Kotulla
128-bitowy skrót. Nazwa algorytmu pochodzi od angielskich słów Message-Digest algorithm 5, co w tłumaczeniu na język polski oznacza Skrót Wiadomości wersja 5. Popularną
implementacją algorytmu MD5 jest md5sum, dostępny w systemach operacyjnych Unix
bądź Linux. Implementacje istnieją również dla systemu Windows [16].
Aplikacje [4], [5]
w
Aplikacje, jak pokazano na rys. 1, są warstwą pośredniczącą pomiędzy bazą danych a komputerami klienckimi.
Newralgiczne zapytania, np. zwracające użytkowników bazy danych, bezpieczniej jest
wykonywać w taki sposób, aby nie korzystać ze struktur pośredniczących, takich jak perspektywy, a zamiast tego konstruować zapytania bezpośrednio do tabel. Jeżeli doszło
do manipulacji w bazie danych, celem często są kody perspektyw, jak przedstawione
to zostało w punkcie 2.4.
Struktura bazy danych – szczególnie kluczowe tabele (np. przechowujące nazwy użytkowników i hasła), procedury i funkcje powinny mieć nazwy trudne do odgadnięcia.
Funkcje należy wywoływać używając pełnych nazw, np. dla Oracle SYS.DBMS_CRYPTO,
zamiast DBMS_CRYPTO.
w
w
Komputery klienckie [4], [10]
Hasła [3], [4]
da
.b
Ochronę przed zagrożeniami zapewnia przeanalizowanie używanych aplikacji klienckich
i pamiętanie newralgicznych plików np. na szyfrowanych obszarach dysku czy w obszarach
tylko do odczytu.
pl
s.
Jedną z najczęściej wykorzystywanych słabych stron są zbyt proste hasła. Należy dołożyć
starań, aby hasła były odpowiednio złożone. Duża moc obliczeniowa obecnych komputerów oraz nowe metody, np. tęczowe tablice, stanowią duże zagrożenie. Hasła powinny
mieć przynajmniej 10 znaków, aby zapobiec atakom za pomocą tęczowych tablic. Hasła nie
powinny się powtarzać dla różnych baz danych. Warto ustalić odpowiednie reguły dla haseł.
Hasła, o ile są przechowywane w bazie danych, nie powinny nigdy pamiętane być
w postaci jawnej, konieczne jest używanie kryptogramów.
Funkcje weryfikujące hasła również stanowią dobry cel do manipulacji, dlatego ważne
jest ich zabezpieczenie (np. przez wygenerowane i sprawdzane regularnie sumy kontrolne).
Kanały transmisji danych, w tym haseł bądź ich kryptogramów, powinny być bezpieczne. Przykładowo w przypadku danych przekazywanych przez internet należy używać protokołu HTTPS zamiast HTTP.
Twórcy systemów zarządzania bazami danych również starają się przeciwdziałać
zagrożeniom, jak atakom za pomocą tęczowych tablic. Aby utrudnić złamanie haseł,
stosuje się wspomniany już salt. Dzięki temu zabiegowi trudniejszcze staje się złamanie
hasła za pomocą tęczowych tablic, ponieważ trzeba je wyliczyć dla każdej możliwej
wartości salt i dodatkowo użyte muszą być podczas ataku właściwe tęczowe tablice.
20
4 Podsumowanie
w
Bazy danych odgrywają bardzo ważną rolę w systemach informatycznych. Przechowują
dane, które muszą być chronione przed nieuprawnionym dostępem i manipulacją.
W rozdziale dokonano przeglądu zagrożeń dla baz danych i przedstawiono możliwości ochrony.
Bazy danych [4] będą jednak dopiero wtedy odpowiednio zabezpieczone, kiedy w całym
środowisku wprowadzone zostaną odpowiednie procedury bezpieczeństwa. W szczególności analizy i postępowania według ustalonej polityki bezpieczeństwa wymagają, oprócz samych baz danych:
− infrastruktura, np. sieci LAN,
− stosowane systemy operacyjne,
− serwery aplikacji,
− aplikacje klienckie,
− komputery użytkowników o większych uprawnieniach, czyli administratorów oraz
programistów,
− komputery użytkowników korzystających pośrednio lub bezpośrednio z baz danych,
− zachowania użytkowników.
Do poprawy bezpieczeństwa z pewnością przyczyni się stosowanie rozwiązań identyfikacji
biometrycznej lub z użyciem zewnętrznych narzędzi, takich jak karty identyfikacyjne.
Wspomniane zagrożenia nie dotyczą w jednakowym stopniu wszystkich baz danych,
a nawet dystrybucji konkretnego systemu. Nie można też jednoznacznie wskazać baz danych, które są bezpieczniejsze niż pozostałe. Producenci baz danych odpowiadają
na zagrożenia i udostępniają łaty oraz wprowadzają poprawki w nowszych wersjach. Zgromadzone dane są jednak ciągle przedmiotem zainteresowania, więc nieustannie pojawiają
się coraz doskonalsze narzędzia do przeprowadzania ataków.
Dużym problemem jest istnienie firm wyspecjalizowanych na wyszukiwanie dziur
w systemie bezpieczeństwa konkrentnych baz danych i oferujących gotowe programy,
wykorzystujące poznane luki, lub elementy umożliwiające przeprowadzenie ataków,
jak wyliczone tablice tęczowe.
da
.b
w
w
1.
2.
3.
4.
5.
6.
7.
pl
s.
Literatura
Anley Ch.: Advanced SQL Injection In SQL Server Applications, Next Generation Security
Software Ltd, 2002.
Birkholz E. P. (red): Special Ops: Host and Network Security for Microsoft, Unix and Oracle.
Syngress Publishing, Inc. 2003.
Bon G., van Loon S.: Research report : Password cracking in the field. Operating Systems and
Database Management Systems. University of Amsterdam, 2006.
Litchfield D., Anley Ch., Haesman J., Grindlay B.: The Database Hacker’s Handbook,
Defending Database Servers.Wiley Publishing, Inc. Indianapolis, 2005, ISBN 13: 978-0-76457801-4.
Kornbrust A. Rootkity w bazach danych Oracle. Hakin9, Hard Core It Security Magazine,
Nr 1/2006, ISSN: 1731/7150.
Oechslin P.: Making a Faster Crytanalytical Time-Memory Trade-Off, Advances in Cryptology CRYPTO 2003, 23rd Annual International Cryptology Conference, Santa Barbara, California,
USA, August 17-21, 2003, Proceedings. Lecture Notes in Computer Science 2729 Springer
2003, ISBN 3-540-40674-3.
Wright J., Cid C.: An Assessment of the Oracle Password Hashing Algorithm.
21
A.Kotulla
8.
9.
10.
11.
12.
w
Bundesamt für Sicherheit in der Informationstechnik, IT-Grundschutz-Kataloge
(8. Ergänzugngslieferung), Bonn 2006, URL: http://www.bsi.bund.de/gshb/deutsch/index.htm
(sprawdzono 16.03.2008).
http://www.petefinnigan.com (sprawdzono 16.03.2008).
http://www.red-database-security.com (sprawdzono 16.03.2008).
http://www.red-database-security.com/whitepaper/oracle_passwords.html
Litchfield D.: Threat profiling Microsoft SQl Server (A Guide to Security Auditing), Next
Generation Security Software, 2002, URL: http://www.nextgenss.com/papers/tp-SQL2000.pdf
TecChannel: MS-SQL Slammer: Ein Wurm und die Konsequenzen, 2003,
URL: http://www.tecchannel.de/server/sicherheit/402050/ (sprawdzono 16.03.2008).
Słownik
złośliwego
oprogramowania,
URL:
http://www.viruslist.pl/glossary.html
Network Working Group: The MD5 Message-Digest Algorithm, RFC 1321,
URL: http://tools.ietf.org/html/rfc1321 (sprawdzono 16.03.2008).
Microsoft File Checksum Integrity Verifier, URL:
http://www.microsoft.com/downloads/details.aspx?FamilyID=B3C93558-31B7-47E2-A6637365C1686C08&displaylang=en (sprawdzono 16.03.2008).
13.
14.
w
15.
16.
da
.b
w
pl
s.
22

pobierz plik referatu

Transkrypt

Podobne dokumenty

Programista SQL, PL/SQL, PHP - Polisa

Projekty z Baz Danych (wytyczne)

Badanie wydajności zapytań SQL na przykładzie wybranych

Analityk danych / programista baz danych SQL

harmonogram-szkolenia-redziny

Analityk/Programista baz danych – SQL Server

Administrator baz danych_cv

Wiadomości SQL Server 2012

wytyczne projekt zaliczeniowy