Dane dostępowe do baz danych należą do najcenniejszych sekretów w środowisku biznesowym. Ujawniona nazwa użytkownika i hasło mogą odsłonić dane klientów, informacje finansowe, dane aplikacji lub cały produkcyjny system. Parametry połączenia mogą ujawniać hosta bazy danych, port, nazwę bazy i metodę uwierzytelniania, nawet gdy hasło nie jest od razu widoczne.
Ryzyko nie ogranicza się do kodu źródłowego aplikacji. Dane dostępowe mogą pojawić się w plikach konfiguracyjnych, zgłoszeniach do pomocy technicznej, logach wdrożeń, obrazach kontenerów, narzędziach monitorujących, kopiach zapasowych serwerów i wiadomościach na czacie. Agencje mierzą się także z dodatkowym wyzwaniem: kilka środowisk klientów może być zarządzanych przez ten sam zespół, ale każdy klient potrzebuje wyraźnego rozdzielenia dostępu, odpowiedzialności i dowodów.
Bezpieczeństwo danych dostępowych do baz danych jest więc procesem, a nie pojedynczym produktem. Obejmuje zarządzanie sekretami, rozdzielenie środowisk, konta o minimalnych uprawnieniach, szyfrowanie, audyt, rotację oraz starannie zaprojektowany dostęp awaryjny.
Zidentyfikuj miejsca, przez które mogą wyciec dane dostępowe do bazy
Zanim wybierzesz narzędzia, wskaż każde miejsce, w którym dane dostępowe mogą zostać utworzone, skopiowane, przetworzone lub zapisane. Takie ćwiczenie często ujawnia większą ekspozycję, niż oczekiwano, ponieważ dane dostępowe podążają za przebiegiem pracy całego systemu, a nie tylko samej aplikacji.
- Kod źródłowy: podczas testów programiści mogą wpisać hasła, klucze API lub kompletne parametry połączenia bezpośrednio w kodzie i zapomnieć usunąć je przed zatwierdzeniem zmian.
- Pliki konfiguracyjne: ustawienia aplikacji, konfiguracja serwera WWW i manifesty wdrożeniowe mogą zawierać sekrety w postaci zwykłego tekstu.
- Zgłoszenia i czaty: inżynier może wkleić hasło lub parametry połączenia, aby przyspieszyć diagnozowanie problemu, pozostawiając je w przeszukiwalnej historii rozmowy.
- Logi: komunikaty o nieudanych połączeniach, dane debugowania, instrukcje SQL i ślady wyjątków mogą zawierać nazwy użytkowników, hosty lub parametry połączeń.
- Kopie zapasowe: kopia zapasowa serwera może jednocześnie zawierać pliki konfiguracyjne, katalogi aplikacji, skrypty, bazy danych, magazyny danych dostępowych i logi.
- Obrazy kontenerów: sekrety skopiowane do pliku Dockerfile, warstwy obrazu lub artefaktu kompilacji mogą pozostać dostępne nawet po usunięciu widocznego pliku.
- Systemy CI/CD: zmienne potoków, dane wyjściowe zadań, pamięci podręczne obszarów roboczych i artefakty kompilacji mogą ujawnić dane dostępowe użytkownikom lub usługom, które ich nie potrzebują.
Utwórz ewidencję dla każdej aplikacji i bazy danych. Zapisz, do czego służy sekret, do którego środowiska należy, kto może uzyskać do niego dostęp, gdzie jest przechowywany, jak jest rotowany i jak można go unieważnić. Traktuj ewidencję jako wrażliwą dokumentację: powinna opisywać sekret, ale nie zawierać jego kopii.
Korzystaj z zarządzania sekretami zamiast rozproszonych konfiguracji
Hasła i klucze powinny być przechowywane w systemie zaprojektowanym do obsługi sekretów, a nie w repozytorium, arkuszu kalkulacyjnym czy ogólnodostępnym dysku współdzielonym. Menedżer sekretów może zapewniać kontrolowany dostęp, szyfrowanie, rejestry audytowe, wersjonowanie i automatyczne pobieranie podczas wdrażania lub działania aplikacji. Aplikacja otrzymuje potrzebną wartość bez konieczności kopiowania jej przez programistów do kodu źródłowego.
Podejścia do zarządzania sekretami są różne. Niektóre organizacje korzystają z dedykowanego sejfu, inne z zarządzanej usługi dostawcy chmurowego, a jeszcze inne z szyfrowanego mechanizmu konfiguracji zintegrowanego z platformą wdrożeniową. Porównując rozwiązania, zapoznaj się z narzędziami do zarządzania danymi dostępowymi do baz i porównaj ich modele dostępu, audytu oraz rotacji z rzeczywistymi wymaganiami operacyjnymi.
Odpowiedni projekt powinien odpowiadać na praktyczne pytania:
- Czy dostęp można przyznać tożsamości obciążenia zamiast długoterminowemu współdzielonemu hasłu?
- Czy uprawnienia można ograniczyć według aplikacji, klienta, środowiska i bazy danych?
- Czy odczyty i zmiany są rejestrowane w ścieżce audytowej?
- Czy sekret można wersjonować i unieważnić bez przebudowywania każdego systemu?
- Czy dostęp może zostać automatycznie odebrany, gdy dana osoba opuszcza projekt lub integracja zostaje wycofana?
- Czy programiści mogą pracować z bezpiecznymi danymi testowymi bez dostępu do wartości produkcyjnych?
Zarządzanie sekretami nie jest automatycznie bezpieczne tylko dlatego, że udostępnia interfejs sejfu. Konto administratora sejfu, klucze odzyskiwania, tokeny integracyjne i zasady dostępu również wymagają ochrony. Ogranicz liczbę osób z szerokimi uprawnieniami do odczytu sekretów, stosuj silne uwierzytelnianie, regularnie przeglądaj dostęp i nie pozwalaj pojedynczemu potokowi ani administratorowi pobierać danych dostępowych wszystkich klientów.
Oddziel środowiska, klientów i zakresy odpowiedzialności
Środowiska deweloperskie, testowe i produkcyjne nie powinny współdzielić danych dostępowych do baz. Aplikacja testowa nie powinna móc łączyć się z produkcyjną bazą danych tylko dlatego, że korzysta z tego samego szablonu konfiguracji. Stosuj oddzielne konta bazodanowe, oddzielne sekrety oraz, jeśli to możliwe, oddzielne instancje lub serwery baz danych.
Ta sama zasada dotyczy różnych klientów. Agencja nie powinna używać jednego konta bazodanowego dla kilku klientów, nawet jeśli takie konto jest wygodne podczas świadczenia wsparcia. Każde środowisko klienta powinno mieć własne dane dostępowe, zasady dostępu i ścieżkę audytową. Ogranicza to skutki wycieku i pozwala ustalić, do którego systemu uzyskano dostęp.
Udokumentuj podział odpowiedzialności. Klient może być właścicielem bazy danych i zatwierdzać uprzywilejowany dostęp, podczas gdy agencja obsługuje aplikację i wykonuje prace utrzymaniowe. Alternatywnie agencja może administrować serwerem, ale wymagać zgody klienta przed zmianą danych dostępowych. Każdy z tych modeli może działać, jeśli jest jasno określony.
Zdefiniuj:
- Kto jest właścicielem bazy danych i zawartych w niej danych
- Kto może tworzyć, odczytywać, rotować i unieważniać dane dostępowe
- Kto zatwierdza dostęp do środowiska produkcyjnego
- Którzy pracownicy wsparcia mogą uzyskać dostęp do poszczególnych środowisk klientów
- Jak dostęp jest odbierany po zakończeniu umowy lub projektu
- Jak dostęp awaryjny jest zgłaszany, rejestrowany i weryfikowany
Nie myl odpowiedzialności operacyjnej z nieograniczonym dostępem. Rola związana z hostingiem, programowaniem lub wsparciem może wymagać utrzymywania aplikacji bez prawa do odczytu każdej tabeli bazy danych lub eksportowania wszystkich danych.
Stosuj zasadę minimalnych uprawnień dla kont bazodanowych
Kontrola dostępu do bazy danych powinna zaczynać się od oddzielnych kont dla oddzielnych funkcji. Konto aplikacji zwykle potrzebuje tylko uprawnień wymaganych przez daną aplikację. Usługa raportowa może potrzebować dostępu tylko do odczytu wybranych widoków, podczas gdy proces migracji może wymagać tymczasowych uprawnień do zmiany schematu. Żadne z nich nie powinno używać konta właściciela bazy do rutynowych działań.
Przydatne granice dla kont
- Konto aplikacji: ograniczone do wymaganej bazy danych, schematu, tabel, procedur lub widoków.
- Konto migracyjne: włączane wyłącznie podczas zatwierdzonych prac wdrożeniowych, a następnie ograniczane lub wyłączane.
- Konto raportowe: tylko do odczytu, najlepiej w odniesieniu do kontrolowanych widoków lub repliki raportowej.
- Konto wsparcia: indywidualny dostęp z ograniczeniem czasowym i ścieżką audytową, a nie stałe, współdzielone hasło administratora.
- Konto kopii zapasowych: ograniczone do operacji tworzenia kopii i, jeśli platforma na to pozwala, pozbawione możliwości modyfikowania danych aplikacji.
Przeglądaj uprawnienia po zmianach w aplikacji. Stare uprawnienia często pozostają długo po usunięciu funkcji, współpracownika lub integracji. Testuj uprawnienia z użyciem tożsamości aplikacji, a nie tylko konta administratora; w przeciwnym razie nadmierny dostęp może pozostać niewidoczny.
Chroń dane dostępowe podczas przesyłania i przechowywania
Szyfrowanie podczas przesyłania jest niezbędne, gdy aplikacja łączy się z bazą danych przez sieć. Skonfiguruj bazę i klienta tak, aby korzystały z TLS, jeśli jest obsługiwany, prawidłowo weryfikuj certyfikaty i unikaj ustawień, które jedynie szyfrują ruch bez sprawdzania miejsca docelowego. Parametry połączenia zawierające hasło nadal są wrażliwe, nawet gdy samo połączenie jest szyfrowane.
W spoczynku sekrety powinny być szyfrowane przez system, który je przechowuje, a dostęp do nich powinien być ograniczony do potrzebnych tożsamości. Szyfrowanie nie eliminuje potrzeby kontroli dostępu. Każdy, kto może odszyfrować sekret, uzyskać dostęp do klucza lub pobrać niezabezpieczony eksport, nadal może zdobyć dane dostępowe.
Nie zakładaj, że usunięcie wiersza z aktualnego pliku konfiguracyjnego usuwa go z historii. Repozytoria Git zachowują wcześniejsze zatwierdzenia, rejestry kontenerów zachowują warstwy obrazów, systemy zgłoszeń zachowują załączniki, a systemy kopii zapasowych przechowują starsze wersje. Jeśli sekret został zatwierdzony w repozytorium lub udostępniony, uznaj go za ujawniony i wykonaj jego rotację, nawet jeśli widoczna kopia została usunięta.
Celowo rotuj i unieważniaj dane dostępowe
Rotację należy zaplanować przed wystąpieniem incydentu. Zdecyduj, jak zostanie zmienione każde hasło do bazy, klucz API i certyfikat, gdzie nowa wartość będzie przechowywana oraz jak aplikacje ją otrzymają. Jeśli usługa nie obsługuje dwóch ważnych danych dostępowych podczas przejścia, zaplanuj kontrolowane okno serwisowe i potwierdź plan wycofania zmian, który nie przywróci starego sekretu na czas nieokreślony.
W miarę możliwości wybieraj dane dostępowe o krótkim czasie życia lub automatyczną rotację. Długoterminowe hasła wymagają silniejszych kontroli operacyjnych, ponieważ mogą pozostać w starych kopiach zapasowych, na laptopach programistów, w pamięciach podręcznych kompilacji lub zapomnianych skryptach.
Unieważnienie różni się od rotacji. Rotacja zastępuje dane dostępowe, podczas gdy stare mogą przez krótki czas pozostać ważne; unieważnienie zatrzymuje dostęp. Unieważniaj je natychmiast, gdy podejrzewasz ujawnienie, gdy pracownik lub dostawca nie potrzebuje już dostępu albo gdy integracja zostaje wycofana. Po unieważnieniu sprawdź w logach użycie starych danych i upewnij się, że zależne usługi działają z użyciem zastępczych danych dostępowych.
Nie umieszczaj sekretów w procesach programistycznych i wdrożeniowych
Lokalny plik .env może być wygodny podczas programowania, ale nie powinien być zatwierdzany w repozytorium, przesyłany w pakiecie do pomocy technicznej ani kopiowany do obrazu produkcyjnego. Udostępnij bezpieczny przykładowy plik zawierający nazwy zmiennych bez rzeczywistych wartości oraz wymuś reguły ignorowania i skanowanie sekretów w repozytorium.
Potoki CI/CD wymagają takiej samej dyscypliny. Przechowuj wrażliwe zmienne w chronionym mechanizmie sekretów potoku albo pobieraj je z sejfu podczas działania. Maskuj wartości w danych wyjściowych, w miarę możliwości nie pozwalaj na pojawianie się sekretów w argumentach wiersza poleceń, ogranicz liczbę osób mogących edytować definicje potoków i chroń gałęzie wdrożeniowe. Przeglądaj artefakty kompilacji i pamięci podręczne, ponieważ sekret może wyciec przez wygenerowaną konfigurację, nawet gdy log potoku wygląda na czysty.
Obrazy kontenerów wymagają osobnej kontroli. Nie używaj argumentów kompilacji ani instrukcji środowiskowych jako stałego magazynu sekretów. Sprawdzaj historię i warstwy obrazu, stosuj wstrzykiwanie podczas działania, utrzymuj prywatne rejestry i usuwaj przejęte obrazy po unieważnieniu danych dostępowych. Kontener, który może odczytać sekret, powinien być również pozbawiony możliwości odczytu niepowiązanych sekretów innych klientów lub środowisk.
Bezpiecznie obsługuj zgłoszenia, logi i rozwiązywanie problemów
Zespoły wsparcia potrzebują standardu dotyczącego żądania informacji diagnostycznych. Proś o zredagowaną konfigurację, kody błędów, znaczniki czasu i identyfikatory zasobów zamiast pełnych parametrów połączenia. Określ pola, które zawsze muszą być usuwane: hasła, tokeny, klucze prywatne, pliki cookie sesji i pełne nagłówki uwierzytelniania.
Bezpieczeństwo logowania należy testować, a nie zakładać. Przeszukuj logi aplikacji, serwera WWW, audytu bazy danych, dane wyjściowe CI oraz alerty monitoringu pod kątem pól przypominających hasła, wzorców tokenów, schematów parametrów połączeń i nazw hostów baz danych. Reguły redakcji powinny obejmować zarówno pola strukturalne, jak i niestrukturyzowane komunikaty wyjątków.
Nigdy nie wysyłaj danych dostępowych zwykłym czatem ani pocztą e-mail. Jeśli awaryjne udostępnienie jest nieuniknione, użyj zatwierdzonego bezpiecznego kanału z ograniczonym dostępem i określonym terminem wygaśnięcia, a następnie wykonaj rotację danych po użyciu. Hasło opublikowane w prywatnym pokoju zespołu nadal jest kopiowane na wiele urządzeń, przechowywane przez dostawcę usługi i potencjalnie widoczne dla osób, które dołączą do pokoju później.
Uwzględniaj dane dostępowe w kopiach zapasowych serwerów
Kopie zapasowe serwerów często zawierają dane dostępowe, ponieważ obejmują konfigurację aplikacji i pliki systemu operacyjnego. Ochrona kopii zapasowych przyczynia się więc do bezpieczeństwa danych dostępowych do baz, ale nie zastępuje menedżera sekretów ani dobrej praktyki rotacji. Kopia może zachować stare hasło długo po przejściu aplikacji na nowe, a każdy, kto może ją odtworzyć, może mieć możliwość przejrzenia plików.
W przypadku serwerów kontrolowanych przez klienta przeanalizuj łącznie szyfrowanie kopii, przechowywanie kluczy, okres retencji i uprawnienia do odtwarzania. Safenix zapewnia kopie zapasowe serwerów firmowych przechowywane poza siedzibą, z danymi składowanymi w Niemczech, szyfrowanymi kluczem, którego Safenix nigdy nie posiada, oraz niezmiennymi przez wybrany okres retencji. Te zabezpieczenia obejmujące szyfrowanie kopii zapasowych i przechowywanie klucza pod kontrolą klienta pomagają ograniczyć ryzyko, że skradziona kopia stanie się źródłem danych dostępowych do bazy.
Ochrona nadal wymaga decyzji operacyjnych. Ustal, kto może zażądać odtworzenia, kto może uzyskać dostęp do odtworzonych plików, czy odtworzenie odbywa się w odizolowanym środowisku oraz jak później obsługiwane są odtworzone dane dostępowe. Odtworzony serwer nie powinien automatycznie stawać się drogą do środowiska produkcyjnego. Jeśli to możliwe, odtwarzaj dane do celów analizy w ograniczonej sieci, montuj dane kopii w trybie tylko do odczytu i usuwaj lub rotuj wszelkie dane dostępowe znalezione w odtworzonej kopii.
Safenix chroni serwery kontrolowane przez klienta; nie jest to plan tworzenia kopii zapasowych dla stron działających na hostingu współdzielonym. Klient lub jego dostawca usług nadal odpowiada za konfigurację zarządzania sekretami serwera, uprawnienia dostępu i decyzje dotyczące zakresu kopii zapasowej.
Stosuj bezpieczną procedurę awaryjną
Gdy dane dostępowe mogły wyciec, liczy się szybkość, ale pochopne zmiany mogą spowodować awarię lub zniszczyć dowody. Udostępnij osobom, które mogą tego potrzebować, krótką i przetestowaną procedurę reagowania na incydenty.
- Ogranicz ekspozycję: ogranicz dostęp do repozytorium, zgłoszenia, czatu, potoku lub magazynu i zachowaj istotne rejestry.
- Sklasyfikuj sekret: określ bazę danych, klienta, środowisko, uprawnienia i systemy, które mogą go używać.
- Unieważnij lub wykonaj rotację: wyłącz ujawnione dane dostępowe i wydaj zastępcze za pośrednictwem zatwierdzonego procesu zarządzania sekretami.
- Sprawdź użycie: przejrzyj logi uwierzytelniania bazy, logi aplikacji, rejestry VPN, dostęp do repozytorium oraz zdarzenia audytowe chmury lub serwera.
- Usuń kopie: w razie potrzeby usuń ujawnione zgłoszenia, artefakty, obrazy lub pliki, zachowując bezpiecznie dowody incydentu.
- Przejrzyj kopie zapasowe: ustal, które wersje kopii zawierają stary sekret, i zapewnij ograniczony dostęp do odtwarzania.
- Potwierdź odzyskanie: przetestuj aplikację z nowymi danymi i sprawdź, czy stare dane dostępowe już nie działają.
- Ulepsz kontrolę: udokumentuj przyczynę i dodaj zabezpieczenie prewencyjne, takie jak skanowanie sekretów, lepsza redakcja lub krótszy czas życia danych dostępowych.
Nie używaj odtwarzania kopii jako pierwszej reakcji na wyciek hasła. Odtworzenie starszego serwera może przywrócić również przejęte dane dostępowe, podatne oprogramowanie lub nieaktualne zasady dostępu. Kopie zapasowe służą do odzyskiwania danych; reakcję na wyciek należy prowadzić przez unieważnienie, analizę i kontrolowane ponowne wdrożenie.
Praktyczne kontrole dla agencji i firm
Wykonuj te kontrole podczas wdrażania nowych klientów, głównych wdrożeń oraz po zmianach personelu lub dostawców:
- Przeszukuj repozytoria, historię zatwierdzeń, skrypty wdrożeniowe i warstwy kontenerów pod kątem haseł, tokenów oraz wzorców parametrów połączeń.
- Sprawdzaj, czy pliki .env, eksporty konfiguracji lub zrzuty baz danych nie są publicznie dostępne ani dołączane do pakietów pomocy technicznej.
- Przeglądaj logi i dane wyjściowe CI/CD pod kątem pól uwierzytelniania, błędów SQL, argumentów poleceń i niezamaskowanych zmiennych.
- Wymień każde produkcyjne konto bazodanowe i potwierdź jego właściciela, przeznaczenie, uprawnienia, datę ostatniej rotacji oraz ostatnie użycie.
- Upewnij się, że systemy deweloperskie i testowe nie mogą uwierzytelniać się w środowisku produkcyjnym przy użyciu swoich zwykłych danych.
- Sprawdź, którzy pracownicy, wykonawcy, konta usługowe i operatorzy kopii zapasowych mogą pobierać sekrety lub odtwarzać dane serwera.
- Potwierdź, że połączenia z bazą weryfikują certyfikaty szyfrowania i nie przechodzą na nieszyfrowany transport.
- Przejrzyj retencję kopii zapasowych i uprawnienia do odtwarzania, w tym osoby mogące uzyskać dostęp do odtworzonych plików konfiguracyjnych.
- Przetestuj unieważnianie i zastępowanie danych dostępowych bez polegania na nieudokumentowanym haśle administratora.
Zadaj jedno końcowe pytanie dotyczące każdego sekretu: jeśli ta wartość pojawiłaby się dziś w publicznym repozytorium, jak szybko można byłoby zatrzymać dostęp, jak zidentyfikowano by zagrożone środowisko i kto odpowiadałby za reakcję? Jeśli odpowiedź zależy od znalezienia osoby pamiętającej stary proces, kontrola nie jest jeszcze niezawodna.