Bezpieczeństwo bazy danych - Database security

Bezpieczeństwo baz danych dotyczy korzystania z szerokiego zakresu kontroli bezpieczeństwa informacji w celu ochrony baz danych (potencjalnie obejmujących dane, aplikacje baz danych lub przechowywane funkcje, systemy baz danych, serwery baz danych i powiązane łącza sieciowe) przed naruszeniem ich poufności, integralności i dostępność. Obejmuje różne rodzaje lub kategorie kontroli, takie jak kontrole techniczne, proceduralne/administracyjne i fizyczne.

Zagrożenia bezpieczeństwa systemów baz danych obejmują na przykład:

  • Nieautoryzowane lub niezamierzone działania lub nadużycia przez autoryzowanych użytkowników baz danych, administratorów baz danych lub menedżerów sieci/systemów lub przez nieautoryzowanych użytkowników lub hakerów (np. niewłaściwy dostęp do danych wrażliwych, metadanych lub funkcji w bazach danych lub nieodpowiednie zmiany programów, struktur lub konfiguracje bezpieczeństwa);
  • Infekcje złośliwego oprogramowania powodujące incydenty, takie jak nieautoryzowany dostęp, wyciek lub ujawnienie danych osobowych lub zastrzeżonych, usunięcie lub uszkodzenie danych lub programów, przerwanie lub odmowa autoryzowanego dostępu do bazy danych, ataki na inne systemy i nieoczekiwana awaria usług baz danych;
  • Przeciążenia, ograniczenia wydajności i problemy z pojemnością skutkujące niezdolnością autoryzowanych użytkowników do korzystania z baz danych zgodnie z przeznaczeniem;
  • Fizyczne uszkodzenie serwerów baz danych spowodowane pożarem lub zalaniem pomieszczeń komputerowych, przegrzaniem, piorunem, przypadkowym rozlaniem płynów, wyładowaniami elektrostatycznymi, awariami/awariami sprzętu elektronicznego i starzeniem się;
  • Luki projektowe i błędy programistyczne w bazach danych i związanych z nimi programach i systemach, tworzące różne luki w zabezpieczeniach (np. nieautoryzowane eskalacje uprawnień ), utratę/uszkodzenie danych, pogorszenie wydajności itp.;
  • Uszkodzenie danych i/lub strata spowodowana wprowadzeniem nieprawidłowych danych lub poleceń, błędami w procesach administrowania bazą danych lub systemem, sabotażem/szkodą kryminalną itp.

Ross J. Anderson często powtarzał, że ze swej natury duże bazy danych nigdy nie będą wolne od nadużyć związanych z naruszeniem bezpieczeństwa; jeśli duży system jest zaprojektowany z myślą o łatwym dostępie, staje się niepewny; jeśli jest wodoszczelny, staje się niemożliwy do użycia. Jest to czasami znane jako Reguła Andersona.

Wiele warstw i rodzajów kontroli bezpieczeństwa informacji jest odpowiednich dla baz danych, w tym:

Bazy danych zostały w dużej mierze zabezpieczone przed hakerami za pomocą środków bezpieczeństwa sieci , takich jak zapory sieciowe i sieciowe systemy wykrywania włamań . Chociaż kontrole bezpieczeństwa sieci pozostają cenne w tym względzie, zabezpieczenie samych systemów baz danych oraz zawartych w nich programów/funkcji i danych stało się prawdopodobnie bardziej krytyczne, ponieważ sieci są coraz bardziej otwarte na szerszy dostęp, w szczególności dostęp z Internetu. Ponadto, kontrola systemu, programu, funkcji i dostępu do danych, wraz z powiązanymi funkcjami identyfikacji użytkownika, uwierzytelniania i zarządzania uprawnieniami, zawsze była ważna dla ograniczenia, aw niektórych przypadkach rejestrowania działań upoważnionych użytkowników i administratorów. Innymi słowy, są to uzupełniające się podejścia do bezpieczeństwa baz danych, działające zarówno od zewnątrz do wewnątrz, jak i od wewnątrz.

Wiele organizacji opracowuje własne „podstawowe” standardy bezpieczeństwa i projekty szczegółowo opisujące podstawowe środki kontroli bezpieczeństwa dla ich systemów baz danych. Mogą one odzwierciedlać ogólne wymagania lub obowiązki w zakresie bezpieczeństwa informacji nałożone przez firmowe polityki bezpieczeństwa informacji oraz obowiązujące przepisy i regulacje (np. dotyczące prywatności, zarządzania finansami i systemów raportowania), wraz z ogólnie przyjętymi dobrymi praktykami bezpieczeństwa baz danych (takimi jak odpowiednie wzmocnienie systemów bazowych) i być może zalecenia dotyczące bezpieczeństwa od odpowiednich dostawców systemów baz danych i oprogramowania. Projekty zabezpieczeń dla określonych systemów bazodanowych zazwyczaj określają dalsze funkcje administracyjne i zarządzania bezpieczeństwem (takie jak administrowanie i raportowanie praw dostępu użytkowników, zarządzanie i analiza dzienników, replikacja/synchronizacja bazy danych i tworzenie kopii zapasowych) wraz z różnymi biznesowymi mechanizmami kontroli bezpieczeństwa informacji w bazie danych programy i funkcje (np. walidacja wprowadzania danych i ścieżki audytu ). Co więcej, różne działania związane z bezpieczeństwem (kontrole ręczne) są zwykle włączane do procedur, wytycznych itp. związanych z projektowaniem, rozwojem, konfiguracją, użytkowaniem, zarządzaniem i konserwacją baz danych.

Przywileje

W odniesieniu do bezpieczeństwa bazy danych w środowisku bazy danych ważne są dwa rodzaje uprawnień: uprawnienia systemowe i uprawnienia do obiektów.

Uprawnienia systemowe

Uprawnienia systemowe umożliwiają użytkownikowi wykonywanie czynności administracyjnych w bazie danych.

Uprawnienia obiektów

Uprawnienia do obiektów pozwalają na wykonywanie pewnych operacji na obiektach bazy danych jako autoryzowane przez innego użytkownika. Przykłady obejmują: użycie, zaznaczanie, wstawianie, aktualizowanie i odniesienia.

Zleceniodawca najmniej uprzywilejowanego i rozdział obowiązków:

Bazy danych podlegające kontroli wewnętrznej (tj. dane wykorzystywane do sprawozdawczości publicznej, raportów rocznych itp.) podlegają rozdzieleniu obowiązków, co oznacza, że ​​musi istnieć oddzielenie zadań między rozwojem a produkcją. Każde zadanie musi zostać zweryfikowane (przez przeglądanie kodu/świeże oczy) przez trzecią osobę, która nie pisze samego kodu. Deweloper bazy danych nie powinien mieć możliwości wykonywania czegokolwiek w środowisku produkcyjnym bez niezależnego przeglądu dokumentacji/kodu wykonywanej pracy. Zazwyczaj rolą programisty jest przekazanie kodu do DBA; jednak biorąc pod uwagę cięcia, które wynikały ze spowolnienia gospodarczego, DBA może nie być łatwo dostępny. Jeśli administrator nie jest zaangażowany, ważne jest, aby co najmniej współpracownik przeprowadził przegląd kodu. Gwarantuje to, że rola dewelopera jest wyraźnie rozdzielona.

Kolejnym punktem kontroli wewnętrznej jest przestrzeganie zasady zapewniania jak najmniejszej ilości uprawnień , zwłaszcza w produkcji. Aby umożliwić programistom większy dostęp do pracy, znacznie bezpieczniej jest używać personifikacji w przypadku wyjątków, które wymagają podwyższonych uprawnień (np. EXECUTE AS lub sudo, aby zrobić to tymczasowo). Często programiści mogą odrzucić to jako „narzut” na swojej drodze do chwały kodowania. Należy jednak pamiętać, że administratorzy baz danych muszą robić wszystko, co uważa się za odpowiedzialne, ponieważ są de facto administratorami danych organizacji i muszą przestrzegać przepisów i prawa.

Oceny podatności w celu zarządzania ryzykiem i zgodnością

Dalsze informacje: bezpieczeństwo aplikacji

Jedną z technik oceny bezpieczeństwa bazy danych jest przeprowadzanie oceny podatności lub testów penetracyjnych w stosunku do bazy danych. Testerzy próbują znaleźć luki w zabezpieczeniach, które można wykorzystać do obejścia lub obejścia kontroli bezpieczeństwa, włamania się do bazy danych, złamania zabezpieczeń systemu itp. Administratorzy baz danych lub administratorzy bezpieczeństwa informacji mogą na przykład użyć automatycznego skanowania luk w celu wyszukania błędnej konfiguracji kontroli (często określane jako jako „drift”) w warstwach wymienionych powyżej wraz ze znanymi lukami w oprogramowaniu bazy danych. Wyniki takiego skanowania są wykorzystywane do wzmocnienia bazy danych (poprawy bezpieczeństwa) i zamknięcia określonych zidentyfikowanych luk w zabezpieczeniach, ale inne luki często pozostają nierozpoznane i nierozwiązane.

W środowiskach baz danych, w których bezpieczeństwo ma kluczowe znaczenie, ciągłe monitorowanie zgodności ze standardami poprawia bezpieczeństwo. Zgodność z zabezpieczeniami wymaga, między innymi, zarządzania poprawkami oraz przeglądania i zarządzania uprawnieniami (zwłaszcza publicznymi) przyznanymi obiektom w bazie danych. Obiekty bazy danych mogą obejmować tabelę lub inne obiekty wymienione w łączu Tabela. W tym procesie są brane pod uwagę uprawnienia nadane dla poleceń języka SQL na obiektach. Monitorowanie zgodności jest podobne do oceny podatności, z tą różnicą, że wyniki oceny podatności na ogół określają standardy bezpieczeństwa, które prowadzą do programu ciągłego monitorowania. Zasadniczo ocena podatności jest wstępną procedurą określania ryzyka, w przypadku gdy program zgodności jest procesem ciągłej oceny ryzyka.

Program zgodności powinien uwzględniać wszelkie zależności na poziomie oprogramowania aplikacji, ponieważ zmiany na poziomie bazy danych mogą mieć wpływ na oprogramowanie aplikacji lub serwer aplikacji .

Abstrakcja

Mechanizmy uwierzytelniania i autoryzacji na poziomie aplikacji mogą być skutecznym sposobem zapewnienia abstrakcji od warstwy bazy danych. Główną zaletą abstrakcji jest możliwość pojedynczego logowania w wielu bazach danych i platformach. System pojedynczego logowania przechowuje poświadczenia użytkownika bazy danych i uwierzytelnia się w bazie danych w imieniu użytkownika. Abstrakcja to idea ułatwiania zrozumienia złożonych pomysłów.

Monitorowanie aktywności bazy danych (DAM)

Inna warstwa bezpieczeństwa o bardziej wyrafinowanym charakterze obejmuje monitorowanie aktywności bazy danych w czasie rzeczywistym , poprzez analizę ruchu protokołu (SQL) w sieci lub obserwację lokalnej aktywności bazy danych na każdym serwerze za pomocą agentów oprogramowania, lub jedno i drugie. Do przechwytywania działań wykonywanych na serwerze bazy danych, które zazwyczaj obejmują działania administratora bazy danych, wymagane jest użycie agentów lub rejestrowanie natywne. Agenci umożliwiają przechwytywanie tych informacji w sposób, którego nie może wyłączyć administrator bazy danych, który ma możliwość wyłączania lub modyfikowania rodzimych dzienników inspekcji.

Można przeprowadzić analizę w celu zidentyfikowania znanych luk w zabezpieczeniach lub naruszeń zasad, lub można przechwycić punkty odniesienia w czasie, aby zbudować normalny wzorzec używany do wykrywania nietypowej aktywności, która może wskazywać na włamanie. Systemy te mogą zapewnić kompleksową ścieżkę audytu bazy danych oprócz mechanizmów wykrywania włamań, a niektóre systemy mogą również zapewniać ochronę poprzez kończenie sesji użytkowników i/lub poddawanie kwarantannie użytkowników wykazujących podejrzane zachowanie. Niektóre systemy są zaprojektowane tak, aby wspierać rozdział obowiązków (SOD), co jest typowym wymogiem audytorów. SOD wymaga, aby administratorzy baz danych, którzy są zwykle monitorowani w ramach programu DAM, nie mogli wyłączać ani zmieniać funkcji programu DAM. Wymaga to bezpiecznego przechowywania ścieżki audytu DAM w oddzielnym systemie, który nie jest administrowany przez grupę administracyjną bazy danych.

Audyt natywny

Oprócz korzystania z zewnętrznych narzędzi do monitorowania lub audytu, na wielu platformach bazodanowych dostępne są również natywne możliwości audytu bazy danych. Natywne ślady audytu są regularnie wyodrębniane i przesyłane do wyznaczonego systemu bezpieczeństwa, do którego administratorzy bazy danych mają/nie powinni mieć dostępu. Zapewnia to pewien poziom podziału obowiązków, który może stanowić dowód na to, że natywne ścieżki audytu nie zostały zmodyfikowane przez uwierzytelnionych administratorów i powinny być przeprowadzane przez grupę DBA zajmującą się bezpieczeństwem z uprawnieniami do odczytu do produkcji. Włączenie natywnego wpływa na wydajność serwera. Ogólnie rzecz biorąc, rodzime ścieżki audytu baz danych nie zapewniają wystarczających kontroli, aby wymusić rozdział obowiązków; w związku z tym możliwości monitorowania na poziomie hosta na poziomie sieci i/lub modułu jądra zapewniają wyższy stopień pewności dla kryminalistyki i ochrony dowodów.

Proces i procedury

Dobry program do zabezpieczania baz danych obejmuje regularny przegląd uprawnień nadawanych kontom użytkowników oraz kont wykorzystywanych przez procesy bezpośrednie. W przypadku kont indywidualnych dwuskładnikowy system uwierzytelniania poprawia bezpieczeństwo, ale zwiększa złożoność i koszty. Konta używane przez zautomatyzowane procesy wymagają odpowiednich środków kontroli przechowywania haseł, takich jak wystarczające szyfrowanie i kontrola dostępu, aby zmniejszyć ryzyko włamania.

W połączeniu z solidnym programem zabezpieczającym bazę danych, odpowiedni program do odtwarzania po awarii może zapewnić, że usługa nie zostanie przerwana podczas incydentu związanego z bezpieczeństwem lub jakiegokolwiek incydentu, który spowoduje awarię środowiska podstawowej bazy danych. Przykładem jest replikacja podstawowych baz danych do lokacji znajdujących się w różnych regionach geograficznych.

Po wystąpieniu incydentu można zastosować analizę śledczą baz danych w celu określenia zakresu naruszenia oraz zidentyfikowania odpowiednich zmian w systemach i procesach.

Zobacz też

Bibliografia

Zewnętrzne linki