Firmowa baza danych rzadko zostaje wystawiona na działanie internetu dlatego, że ktoś celowo wybiera niebezpieczny projekt. Częściej ekspozycja wynika z ustawienia domyślnego, tymczasowej reguły zapory, pominiętej usługi testowej albo skrótu w pracach konserwacyjnych, który z czasem staje się stałym rozwiązaniem.
Konsekwencje mogą być poważne. Atakujący może wykraść dane klientów, zmienić dane finansowe, zaszyfrować systemy produkcyjne albo wykorzystać serwer bazy danych jako drogę do innej infrastruktury. Nawet jeśli dane nie zostaną od razu skradzione, wystawiona usługa tworzy możliwy do uniknięcia punkt wejścia, który trzeba monitorować i chronić.
Poniższe siedem błędów dotyczy serwerów baz danych kontrolowanych przez firmę, agencję lub administratora IT. Mają zastosowanie do PostgreSQL, MySQL, Microsoft SQL Server, MongoDB i innych platform. Konkretne polecenia mogą się różnić, ale decyzje dotyczące bezpieczeństwa pozostają takie same: ograniczyć dostępność, zweryfikować tożsamość, ograniczyć uprawnienia, szyfrować ruch, monitorować aktywność i przechowywać niezależne kopie umożliwiające odzyskanie danych.
1. Powiązanie bazy danych z publicznym interfejsem
Usługa bazy danych może domyślnie nasłuchiwać na każdym interfejsie sieciowym albo administrator może skonfigurować ją tak, aby nasłuchiwała na publicznym adresie IP, by ułatwić zdalny dostęp. Jeśli serwer ma routowalny adres, baza danych może być wtedy osiągalna bezpośrednio z internetu, chyba że inny mechanizm ją blokuje.
Przebieg ataku i wpływ na firmę
Atakujący skanuje zakresy adresów w poszukiwaniu rozpoznawalnych portów baz danych, identyfikuje oprogramowanie i jego wersję, a następnie próbuje ataków na dane uwierzytelniające lub wykorzystuje znaną lukę. Publiczna widoczność nie oznacza automatycznie przejęcia systemu, ale daje atakującym stały i łatwy do znalezienia cel.
Skuteczny dostęp może ujawnić dane osobowe, zamówienia, dane uwierzytelniające, własność intelektualną i informacje operacyjne. Konto bazy danych może również pozwolić atakującemu zmieniać rekordy, tworzyć nowych uprzywilejowanych użytkowników lub wykorzystywać funkcje bazy do uzyskania dostępu do bazowego serwera.
Jak wykryć i naprawić problem
Sprawdź konfigurację nasłuchiwania bazy danych oraz listę gniazd systemu operacyjnego. Polecenia takie jak ss -lntp lub netstat -lntp mogą pokazać, czy usługa nasłuchuje na 0.0.0.0, :: lub publicznym adresie, zamiast wyłącznie na localhost albo prywatnym interfejsie. Wykonaj test spoza sieci, a nie tylko z samego serwera. Zewnętrzne skanowanie portów oraz przegląd grup zabezpieczeń w chmurze lub reguł zapory dostawcy hostingu powinny być zgodne z założonym projektem.
W przypadku większości aplikacji powiąż bazę danych z localhostem lub prywatnym adresem sieciowym i umieść ją za warstwą aplikacji. Jeśli zdalna administracja jest konieczna, wymagaj prywatnego VPN-u, serwera bastionowego lub innej kontrolowanej ścieżki dostępu. Nie traktuj nietypowego portu jako zabezpieczenia. Może on ograniczyć przypadkowy szum, ale nie zapobiega wykryciu usługi.
Administratorzy mogą skorzystać z wiarygodnych wskazówek dotyczących sprawdzania bazy danych dostępnej z internetu i bezpiecznych sposobów jej udostępniania podczas weryfikacji projektu. Celem powinno być usunięcie publicznej dostępności wszędzie tam, gdzie nie jest ona niezbędna, a nie tylko ukrycie usługi.
2. Pozostawienie domyślnych danych uwierzytelniających lub słabego uwierzytelniania
Produkty bazodanowe, urządzenia i obrazy wdrożeniowe czasami zawierają domyślne nazwy użytkowników, tymczasowe hasła lub tryby uwierzytelniania przeznaczone wyłącznie do początkowej konfiguracji. Pośpieszna instalacja może również pozostawić proste hasło, doprowadzić do ponownego użycia sekretu aplikacji albo zezwolić na bezhasłowe połączenia lokalne w szerszym zakresie, niż planowano.
Przebieg ataku i wpływ na firmę
Po wykryciu portu bazy danych atakujący rutynowo próbują opublikowanych danych domyślnych i popularnych haseł. Skuteczne jest również „credential stuffing”, gdy administratorzy ponownie wykorzystują hasła z innych systemów. Po uwierzytelnieniu atakujący może uzyskać znacznie szerszy dostęp, niż wymaga tego pierwotna aplikacja.
Skutkiem może być ciche pobieranie danych, destrukcyjne zapytania, fałszywe zmiany lub przyczółek do późniejszego ataku ransomware. Jeśli tych samych danych uwierzytelniających używają skrypty, deweloperzy i administratorzy, jeden ujawniony sekret może zagrozić każdemu środowisku.
Jak wykryć i naprawić problem
Przejrzyj każde konto bazy danych, jego metodę uwierzytelniania, informacje o ostatnim użyciu i przypisaną rolę. Przetestuj instalację na podstawie spisu kont, zamiast zakładać, że udokumentowane dane domyślne zostały usunięte. Sprawdź pliki konfiguracyjne, manifesty wdrożeniowe, zmienne CI/CD i skrypty pod kątem zapisanych haseł.
Wyłącz nieużywane konta dostawców, w razie potrzeby zmień nazwy kont awaryjnych lub je zablokuj, a dla kont, które muszą pozostać aktywne, wymagaj długich i unikalnych danych uwierzytelniających. Preferuj centralnie zarządzane uwierzytelnianie, uwierzytelnianie wieloskładnikowe dla administratorów oraz krótkotrwałe dane uwierzytelniające dla automatyzacji, jeśli platforma je obsługuje. Przechowuj sekrety w dedykowanym menedżerze sekretów, a nie w kodzie źródłowym, zgłoszeniach, arkuszach kalkulacyjnych czy historii powłoki. Zmieniaj dane uwierzytelniające po zmianach personelu, podejrzeniu ujawnienia i poważnych zmianach systemu.
Logi uwierzytelniania powinny rejestrować nieudane i udane logowania, adresy źródłowe oraz użyte konto. Ustaw alerty dotyczące powtarzających się niepowodzeń, logowań o nietypowych porach, dostępu z nieoczekiwanych sieci i tworzenia nowych uprzywilejowanych kont.
3. Zezwalanie na nieograniczony dostęp sieciowy
Powiązanie bazy danych z prywatnym interfejsem nie wystarczy, jeśli sieć pozwala każdemu wewnętrznemu hostowi, użytkownikowi VPN-u lub obciążeniu w chmurze na połączenie. Szeroka reguła, taka jak „zezwól całej sieci biurowej” lub „zezwól na cały ruch z prywatnej chmury wirtualnej”, często pozostaje aktywna długo po zniknięciu pierwotnej potrzeby diagnostycznej.
Przebieg ataku i wpływ na firmę
W tym scenariuszu atakujący najpierw przejmuje laptop, serwer WWW, konto dewelopera lub niezwiązane obciążenie. Dostęp sieciowy do bazy danych jest już możliwy, więc atakujący może skanować usługę i zaatakować ją bez przekraczania granicy internetowej.
Nadmierna ekspozycja wewnętrzna zwiększa zasięg skutków phishingu, złośliwego oprogramowania i incydentów w łańcuchu dostaw. Może również umożliwić nieautoryzowane przemieszczanie się między systemami produkcyjnymi, testowymi i deweloperskimi. Przejęty serwer testowy nie powinien móc odpytywać danych klientów tylko dlatego, że oba systemy mają wspólną, szeroką regułę sieciową.
Jak wykryć i naprawić problem
Przejrzyj jednocześnie zapory hostów, zapory sieciowe, grupy zabezpieczeń w chmurze, zasady sieciowe Kubernetes oraz reguły dostępu hostów na poziomie bazy danych. Udokumentuj, które serwery aplikacji, narzędzia raportowe, usługi kopii zapasowych i administracyjne hosty przesiadkowe faktycznie potrzebują połączeń. Porównaj tę listę z aktywnymi połączeniami i regułami zapór.
Zastąp szerokie zakresy źródłowe jawnymi listami dozwolonych adresów IP lub grupami zabezpieczeń. Zezwalaj tylko na wymagany port docelowy i protokół. Domyślnie odrzucaj ruch, oddziel sieci produkcyjne od nieprodukcyjnych i usuwaj tymczasowe reguły, przypisując im właściciela oraz datę wygaśnięcia. Jeśli pracownicy łączą się zdalnie, kieruj prace konserwacyjne przez VPN lub serwer bastionowy, zamiast pozwalać każdemu domowemu lub mobilnemu adresowi IP na bezpośrednie połączenie.
Przeglądaj reguły po migracjach i zmianach w sieci biurowej. Kwartalny przegląd dostępu jest przydatny, ale zmiany wysokiego ryzyka należy sprawdzać natychmiast. Reguła zapory bez wskazanego właściciela biznesowego jest kandydatem do usunięcia.
4. Przesyłanie danych bazy bez TLS
Baza danych może być chroniona podczas przechowywania, a mimo to ujawniać dane uwierzytelniające i wrażliwe rekordy podczas przesyłania między aplikacją, stacją roboczą administratora, narzędziem raportowym lub partnerem replikacji. Nieszyfrowane połączenia są szczególnie niebezpieczne we wspólnych sieciach, segmentach chmurowych, sieciach Wi-Fi i podczas zdalnych prac konserwacyjnych.
Przebieg ataku i wpływ na firmę
Atakujący mający dostęp do sieci przechwytuje ruch lub ustawia się między klientem a serwerem. Bez TLS nazwy użytkowników, hasła, zapytania i zwracane dane mogą być czytelne. Słaby lub niezweryfikowany TLS również może umożliwić przechwycenie, ponieważ klient nie potwierdza, że łączy się z prawdziwą bazą danych.
Konsekwencje obejmują kradzież danych uwierzytelniających, ujawnienie danych klientów, modyfikowanie zapytań i problemy z przestrzeganiem przepisów. Kanały replikacji i transferu kopii zapasowych wymagają takiej samej uwagi jak zwykły ruch aplikacji.
Jak wykryć i naprawić problem
Sprawdź parametry połączeń z bazą danych i ustawienia serwera, aby potwierdzić, że TLS jest wymagany, a nie tylko dostępny. Użyj statusu klienta bazy danych, logów audytu połączeń oraz przechwytywania pakietów w kontrolowanym teście, aby zweryfikować szyfrowanie. Sprawdź ważność certyfikatów, weryfikację nazwy hosta, zaufanych wystawców, wersje protokołu i odrzucanie awaryjnego przejścia na tekst jawny.
Instaluj certyfikaty w ramach kontrolowanego procesu odnawiania, ogranicz dostęp do kluczy prywatnych i monitoruj daty wygaśnięcia. Skonfiguruj aplikacje tak, aby w przypadku niepowodzenia walidacji certyfikatu odrzucały połączenie. Zaktualizuj stare sterowniki i biblioteki, które nie obsługują aktualnych ustawień TLS. Udokumentuj, które połączenia są szyfrowane, w tym połączenia administracyjne, monitorujące, replikacyjne i ruch ETL.
TLS chroni dane podczas przesyłania, ale nie decyduje, kto powinien móc je odpytywać. Połącz je z ograniczeniami sieciowymi, silnym uwierzytelnianiem i zasadą minimalnych uprawnień.
5. Przyznawanie nadmiernych uprawnień do bazy danych
Aplikacje często konfiguruje się z użyciem konta administratora lub właściciela, ponieważ ułatwia to instalację. Deweloperzy mogą również przyznać użytkownikom raportowym dostęp do zapisu albo nadać kontu usługi uprawnienia do każdego schematu „na przyszłość”. Narusza to zasadę minimalnych uprawnień i zmienia ograniczone przejęcie w incydent obejmujący całą bazę danych.
Przebieg ataku i wpływ na firmę
Luka SQL injection, skradziony sekret aplikacji lub przejęte narzędzie raportowe daje atakującemu uprawnienia przypisane do tego konta. Jeśli konto jest właścicielem tabel, może tworzyć użytkowników lub wykonywać funkcje systemu operacyjnego, atakujący może zrzucić całą bazę, zmienić rekordy albo wydostać się do hosta.
Nadmierne uprawnienia zwiększają również prawdopodobieństwo przypadkowych szkód. Wadliwa migracja lub skrypt może usunąć dane produkcyjne, gdy działa z użyciem wysoce uprzywilejowanej tożsamości.
Jak wykryć i naprawić problem
Sporządź spis użytkowników, grup, ról i nadanych uprawnień. Szukaj kont aplikacji z prawami administratora, bezpośrednim dostępem do niezwiązanych schematów, nieograniczonym dostępem odczytu do wrażliwych tabel oraz uprawnieniami, z których nigdy nie korzystano. Przejrzyj logi audytu bazy danych, aby porównać przyznane uprawnienia z rzeczywistą aktywnością.
Utwórz oddzielne tożsamości dla każdej aplikacji, środowiska i funkcji. Przyznawaj dostęp tylko do wymaganych tabel, widoków, procedur i operacji. Używaj ról tylko do odczytu na potrzeby raportowania, oddziel dane uwierzytelniające migracji od zwykłych danych runtime oraz ograniczaj dostęp do danych osobowych, finansowych i uwierzytelniających. Cofnij odziedziczone uprawnienia, które nie są potrzebne, i usuń nieaktywne konta.
Dostęp do produkcji nie powinien być domyślnie przyznawany deweloperom ani agencjom obsługującym wielu klientów. Używaj nazwanych kont administratorów, wymagaj zatwierdzenia podwyższonego dostępu, stosuj uprawnienia ograniczone czasowo i rejestruj ścieżkę prac konserwacyjnych. Wspólne dane uwierzytelniające administratora uniemożliwiają skuteczne przypisanie działań do osoby i utrudniają szybkie odebranie dostępu.
6. Wystawianie portów i narzędzi administracyjnych
Interfejsy administracyjne baz danych, usługi zdalnego pulpitu, SSH, konsole internetowe i interfejsy API zarządzania są częstymi celami ataków. Wystawienie ich do publicznego internetu dla wygody tworzy drugą powierzchnię ataku, nawet gdy sam nasłuchujący serwer bazy danych jest ograniczony.
Przebieg ataku i wpływ na firmę
Atakujący skanują popularne porty zarządzania, rozpoznają usługi i próbują ataków na hasła, skradzione dane uwierzytelniające lub znane luki. Przejęta usługa administracyjna może zapewnić bezpośrednią kontrolę nad systemem operacyjnym, dostęp do konfiguracji albo możliwość wyłączenia logowania i usunięcia danych.
W małej firmie jeden wystawiony port zdalnego zarządzania może zmienić incydent dotyczący bazy danych w pełne przejęcie serwera. W przypadku agencji wspólna metoda zarządzania może zagrozić kilku środowiskom klientów, jeśli granice dostępu są słabe.
Jak wykryć i naprawić problem
Wykonaj zewnętrzne skanowanie adresów organizacji oraz wewnętrzne skanowanie z niezaufanych segmentów sieci. Przejrzyj nasłuchujące porty za pomocą narzędzi hosta i porównaj je z polityką zapory. Sprawdź w konsolach chmurowych przypisania publicznych adresów IP, nasłuchujące moduły równoważenia obciążenia i zbyt liberalne grupy zabezpieczeń. Monitoruj logi pod kątem logowań do systemów zarządzania, nieudanego uwierzytelniania, nowych sesji i zmian konfiguracji.
Zamknij nieużywane usługi. Nie udostępniaj SSH, zdalnego pulpitu ani konsol baz danych przez publiczne interfejsy. Wymagaj VPN-u, serwera bastionowego lub bramy dostępu zero trust z uwierzytelnianiem wieloskładnikowym, kontrolą urządzeń i indywidualnymi kontami. W miarę możliwości ograniczaj dostęp administracyjny według źródłowego adresu IP, wyłącz bezpośrednie logowanie roota lub wspólnego administratora oraz rejestruj polecenia i aktywność sesji podczas wrażliwych prac.
Oddziel dostęp produkcyjny od dostępu konserwacyjnego. Aplikacja powinna korzystać z jednej, wąsko uprzywilejowanej ścieżki, a administratorzy z innej, kontrolowanej ścieżki, włączanej tylko wtedy, gdy jest potrzebna. Nie zapewniaj zewnętrznej agencji stałego, nieograniczonego dostępu, gdy wystarczy zatwierdzone i rejestrowane okno prac konserwacyjnych.
7. Opóźnianie aktualizacji i usuwania luk
Silniki baz danych, systemy operacyjne, sterowniki, rozszerzenia i narzędzia zarządzania zawierają luki. System może pozostać narażony, nawet gdy kod aplikacji jest dobrze utrzymywany, jeśli bazowa wersja bazy danych nie jest już wspierana albo krytyczna aktualizacja bezpieczeństwa jest odkładana bezterminowo.
Przebieg ataku i wpływ na firmę
Atakujący identyfikują wersję bazy danych za pośrednictwem wystawionych usług, komunikatów błędów, skradzionych danych inwentaryzacyjnych lub przejętych systemów wewnętrznych. Następnie wykorzystują publiczny exploit, podatne rozszerzenie albo słabość warstwy administracyjnej. Niektóre ataki wymagają uwierzytelnienia, inne nie.
Skuteczne wykorzystanie luki może ujawnić lub zmienić dane, utworzyć uprzywilejowane konto, umożliwić wykonanie kodu albo zakłócić dostępność. Opóźnione aktualizacje zwiększają także złożoność odzyskiwania danych, ponieważ awaryjne zmiany są wykonywane pod presją i bez odpowiednich testów.
Jak wykryć i naprawić problem
Wyznacz właściciela systemu operacyjnego, silnika bazy danych, rozszerzeń, sterowników i narzędzi bezpieczeństwa. Utrzymuj spis zawierający wersje, status wsparcia, ekspozycję, właściciela biznesowego i okno konserwacyjne. Subskrybuj komunikaty bezpieczeństwa dostawców i korzystaj ze skanowania podatności, ale weryfikuj wyniki skanera na podstawie faktycznie zainstalowanych wersji i konfiguracji.
Ustal terminy zależne od ryzyka dla krytycznych luk, testuj aktualizacje w reprezentatywnym środowisku testowym i utrzymuj plan wycofania zmian. Niezwłocznie stosuj aktualizacje bezpieczeństwa, usuwaj niewspierane komponenty i dokumentuj zaakceptowane wyjątki wraz z datą wygaśnięcia. Ustaw alerty, gdy zgodność z aktualizacjami spadnie poniżej polityki organizacji. Aktualizacja nie jest zakończona, dopóki usługi nie uruchomią się poprawnie, a monitoring nie potwierdzi normalnego działania.
Wykrywanie wystawionej bazy danych, zanim zrobi to atakujący
Zacznij od pytania: czy niezaufane urządzenie może dotrzeć do bazy danych lub jej interfejsu administracyjnego? Wykonaj test z publicznego internetu oraz z wewnętrznych sieci, które nie powinny mieć dostępu. Sprawdź rekordy DNS, adresy IPv4 i IPv6, zapory chmurowe, zapory hostów i moduły równoważenia obciążenia. Usługa bezpieczna przez IPv4 może nadal być dostępna przez IPv6.
Następnie sprawdź, co dzieje się po nawiązaniu połączenia. Czy serwer wymaga TLS? Czy uwierzytelnianie odrzuca dane domyślne i słabe hasła? Czy konto aplikacji może odczytywać lub modyfikować tabele poza zakresem swojej roli? Czy nieudane logowania, zmiany uprawnień, zmiany schematu i nietypowe eksporty są rejestrowane centralnie?
Logowanie jest przydatne tylko wtedy, gdy ktoś lub coś je analizuje. Przesyłaj logi bazy danych, systemu operacyjnego i zapory do chronionego centralnego systemu, w którym atakujący nie może ich po cichu edytować. Twórz alerty dotyczące powtarzających się nieudanych uwierzytelnień, nowych uprzywilejowanych użytkowników, dostępu z nowych krajów lub sieci, dużych eksportów, wyłączonego audytu, nietypowej liczby zapytań i nieoczekiwanych restartów usług. Dostosuj alerty tak, aby personel mógł reagować, zamiast ignorować ciągły szum.
Przygotuj się na przejęcie dzięki niezależnym kopiom zapasowym
Bezpieczna konfiguracja zmniejsza prawdopodobieństwo przejęcia, ale nie może zagwarantować, że konto, aplikacja lub stacja robocza administratora nigdy nie zostaną zaatakowane. Plan odzyskiwania powinien zakładać, że atakujący może przejąć kontrolę nad serwerem produkcyjnym i spróbować zaszyfrować, uszkodzić lub usunąć dane oraz lokalne kopie zapasowe.
Przechowuj testowane, szyfrowane kopie zapasowe poza siedzibą, których przejęty serwer nie może usunąć. Safenix zapewnia kopie zapasowe serwerów firmowych przechowywane poza siedzibą; dane są przechowywane w Niemczech, niezmienne przez cały okres retencji i szyfrowane kluczem kontrolowanym przez klienta, którego Safenix nigdy nie posiada. Dowiedz się więcej o szyfrowanych kopiach zapasowych poza siedzibą z kluczami kontrolowanymi przez klienta i ograniczonym dostępem z przejętego serwera.
Projekt kopii zapasowych powinien odpowiadać systemom kontrolowanym przez klienta, w tym serwerowi bazy danych i wspierającej go infrastrukturze. Nie jest to plan tworzenia kopii zapasowych dla witryny działającej na hostingu współdzielonym i nie należy zakładać, że jakikolwiek plan hostingu współdzielonego będzie odpowiedni. Zanim zaczniesz polegać na kopiach zapasowych, potwierdź, że baza danych jest przechwytywana w sposób spójny, retencja spełnia wymagania biznesowe, klucze szyfrujące będą dostępne, gdy okażą się potrzebne, a przywracanie danych zakończyło się pomyślnie.
Niezmienność pomaga zapobiegać usunięciu lub zmianie danych w okresie retencji, a przechowywanie poza siedzibą chroni przed awarią lub incydentem w lokalizacji produkcyjnej. Szyfrowanie kluczem kontrolowanym przez klienta oznacza, że dostawca kopii zapasowych nie posiada klucza potrzebnego do odczytania chronionych danych. Mechanizmy te ograniczają wpływ na odzyskiwanie danych, ale nie naprawiają niezabezpieczonej bazy. Przywrócenie przejętego serwera bez usunięcia jego ekspozycji, poprawy danych uwierzytelniających lub zainstalowania aktualizacji po prostu odtworzy incydent.
Dostęp do produkcji i dostęp konserwacyjny w małych zespołach
Małe firmy i agencje często dysponują ograniczoną liczbą pracowników, dlatego rozdzielenie dostępu jest szczególnie ważne. Zwykła ścieżka aplikacji powinna być wąska i przewidywalna. Prace konserwacyjne powinny wykorzystywać nazwane konta, oddzielną trasę sieciową i podwyższenie uprawnień ograniczone czasowo. Dostawca wsparcia powinien otrzymać wyłącznie dostęp potrzebny do uzgodnionego zadania, a nie stałe hasło administratora współdzielone przez klientów.
Prowadź rejestr dostępu obejmujący pracowników, wykonawców, agencje, konta usług i dane uwierzytelniające awaryjne. Przeglądaj go po zmianach personelu i przekazaniu obsługi klienta. Korzystaj z bezpiecznego procesu zarządzania sekretami, wymagaj zatwierdzania zmian produkcyjnych i rejestruj osoby odpowiedzialne za każdą zmianę. Konto awaryjne może istnieć, ale jego użycie powinno wywoływać alert i być okresowo testowane.
Lista kontrolna weryfikacji ochrony bazy danych
- Publiczna dostępność: Czy zewnętrzny lub niezaufany host wewnętrzny może połączyć się z bazą danych albo portem administracyjnym? Czy uwzględniono zarówno IPv4, jak i IPv6?
- Kontrole sieciowe: Czy reguły zapór i listy dozwolonych adresów IP pozwalają na dostęp wyłącznie nazwanym źródłom aplikacji, raportowania i konserwacji?
- Uwierzytelnianie: Czy usunięto lub odpowiednio kontroluje się domyślne, nieaktywne i współdzielone konta? Czy administratorzy używają silnych danych uwierzytelniających i uwierzytelniania wieloskładnikowego?
- Sekrety: Czy haseł i kluczy nie ma w kodzie źródłowym, skryptach, zgłoszeniach ani repozytoriach konfiguracji? Czy rotacja jest testowana?
- Minimalne uprawnienia: Czy każde konto aplikacji i użytkownika ma tylko potrzebny dostęp, z rolami tylko do odczytu tam, gdzie jest to właściwe?
- Szyfrowanie: Czy TLS jest wymagany i prawidłowo weryfikowany dla połączeń aplikacyjnych, administracyjnych, replikacyjnych i transferu danych?
- Monitoring: Czy zdarzenia uwierzytelniania, uprawnień, eksportu danych, zapór i konfiguracji są rejestrowane centralnie wraz z możliwymi do wykorzystania alertami?
- Odpowiedzialność za aktualizacje: Kto odpowiada za każdą bazę danych, system operacyjny, rozszerzenie i narzędzie zarządzania? Czy luki są śledzone aż do ich zamknięcia?
- Gotowość do przywracania: Czy kopie zapasowe są szyfrowane, przechowywane poza siedzibą, niezmienne przez okres retencji i niedostępne do usunięcia z serwera produkcyjnego? Czy przetestowano pełne przywracanie?
Te pytania zmieniają bezpieczeństwo bazy danych z jednorazowego zadania instalacyjnego w stałą praktykę operacyjną. Przeglądaj je po migracjach, poważnych zmianach aplikacji, rotacji personelu i incydentach bezpieczeństwa. Baza danych, do której trudno dotrzeć, która ma ściśle ograniczone uprawnienia, jest aktualizowana i umożliwia odzyskanie danych, znacznie rzadziej prowadzi do zdarzenia kończącego działalność firmy.