Lista kontrolna rotacji sekretów serwera domowego dla aplikacji, baz danych i kopii zapasowych

Bezpieczne podejście polega na traktowaniu rotacji opartej na inwentaryzacji, z nakładającymi się poświadczeniami, walidacją konsumentów, unieważnieniem i aktualizacją materiałów odzyskiwania, jako sekwencji obserwowalnych etapów, a nie pojedynczego polecenia.

Na domowym serwerze z aplikacjami hostowanymi samodzielnie, bazami danych, zadaniami tworzenia kopii zapasowych i automatyzacją praktyczne ryzyko polega na tym, że rotacja jednego poświadczenia może przerwać działanie ukrytych konsumentów, zaplanowanych kopii zapasowych lub zależności aplikacji. Zapisz bieżącą tożsamość i punkt odzyskiwania, zacznij od najmniej inwazyjnego rozróżnienia, zinterpretuj wyniki pozytywne i negatywne przed zmianą kolejnej zmiennej oraz przerwij, gdy pamięć masowa stanie się niestabilna lub jedyna możliwa do odzyskania kopia zostałaby ujawniona. Poniższy proces kończy się dopiero wtedy, gdy pierwotne obciążenie zakończy się powodzeniem albo dowody osiągną granicę wymagającą eskalacji.

Spisz każde poświadczenie i zakres jego oddziaływania

Wymień hasła do baz danych, tokeny API, klucze repozytoriów kopii zapasowych, klucze szyfrowania, sekrety webhooków, poświadczenia serwerów proxy i klucze kont usług. Dla każdego zapisz wystawcę, uprawnienia, miejsce przechowywania, konsumentów, metodę przeładowania, zależność od kopii zapasowych, właściciela odzyskiwania oraz dowody ostatniego użycia, ale nie zapisuj samej wartości.

Lista kontrolna zakresu oddziaływania rotacji poświadczeń GitGuardian przedstawia rotację w kontekście zakresu oddziaływania i odpowiedzialności: poświadczenie może przetrwać osobę lub usługę, która je utworzyła, a sama ważność nie pozwala zidentyfikować każdego konsumenta. Przeszukaj konfigurację, magazyny sekretów, zaplanowane zadania i zmienne CI przed zaplanowaniem unieważnienia.

Klasyfikuj rotację awaryjną oddzielnie od planowanej. Jeśli podejrzewasz naruszenie, powstrzymanie zagrożenia i szybkie unieważnienie mogą mieć większe znaczenie niż dostępność; w przeciwnym razie przed zmianą sekretu używanego przez bazy danych lub kopie zapasowe wymagaj punktu odzyskiwania i przetestowanej ścieżki wycofania.

Utwórz okres nakładania i najpierw zaktualizuj wystawcę

Jeśli jest to obsługiwane, utwórz drugie poświadczenie z tymi samymi minimalnymi uprawnieniami, pozostawiając stare ważne. W przypadku baz danych użyj drugiej roli lub funkcji dwóch haseł; w przypadku usług API wystaw drugi token; w przypadku kluczy szyfrowania postępuj zgodnie z procedurą ponownego opakowania lub slotów kluczy danego produktu, zamiast doraźnie zastępować pliki kluczy.

Przewodnik dotyczący rotacji poświadczeń bazy danych bez przestojów opisuje wzorzec rotacji poświadczeń dwóch użytkowników, w którym konsumenci przechodzą na drugiego użytkownika przed unieważnieniem oryginalnego. Ta metoda jest bezpieczniejsza niż zmiana jednego współdzielonego hasła w miejscu, ponieważ każdego konsumenta można niezależnie zweryfikować.

Jeśli nakładanie jest niemożliwe, zaplanuj okno serwisowe, zatrzymaj zależne procesy zapisujące i zadania tworzenia kopii zapasowych oraz udokumentuj dokładne polecenie wycofania. Nigdy nie nadpisuj jedynego znanego poprawnego hasła do repozytorium ani klucza szyfrowania, dopóki osobny test odzyskiwania nie potwierdzi poprawności zamiennika.

Zaktualizuj każdego konsumenta i potwierdź nowe użycie

Zaktualizuj chronione pliki sekretów lub menedżer sekretów, a następnie przeładuj albo odtwórz po jednym konsumencie naraz. Przetestuj logowanie do aplikacji, odczyt i zapis w bazie danych, procesy robocze działające w tle, monitorowanie, webhooki, replikację zdalną oraz zaplanowane i ręczne operacje tworzenia kopii zapasowych. Działający kontener może nadal przechowywać starą wartość w pamięci.

Skorzystaj z przewodnika ZimaSpace dotyczącego przechowywania sekretów Dockera, aby nie umieszczać poświadczeń w plikach YAML Compose. Upewnij się, że wyrenderowana konfiguracja, inspekcja środowiska, logi, historia powłoki i pakiety pomocy technicznej nie ujawniają ani starych, ani nowych wartości.

Potwierdź, że każdy konsument używa nowego poświadczenia, sprawdzając dzienniki audytu wystawcy lub tymczasowo testując stare poświadczenie z bezpiecznej, odizolowanej ścieżki. Nie unieważniaj go, dopóki macierz konsumentów nie będzie miała właściciela i pozytywnego wyniku dla każdej zależności.

-15% OFF

ZimaBoard 2 – Mini serwer domowy dla Twojego wielkiego pomysłu

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Unieważnij, posprzątaj i przetestuj odzyskiwanie

Unieważnij stare poświadczenie, usuń je z aktywnych magazynów sekretów i wyłączonych zadań, a następnie obserwuj błędy uwierzytelniania i alerty kopii zapasowych przez co najmniej jeden pełny cykl normalnego harmonogramu. W razie potrzeby produktu obróć tokeny sesji zależne lub buforowane połączenia.

Zaktualizuj zaszyfrowaną dokumentację odzyskiwania i chronione kopie kluczy przechowywane offline. Zdecyduj, czy kopie zapasowe zawierające stary sekret są bezpiecznie zaszyfrowane i objęte okresem przechowywania, czy wymagają szczególnego postępowania; przepisywanie historycznych kopii zapasowych może uszkodzić możliwość odzyskania danych i rzadko jest pierwszą reakcją.

Rotacja kończy się, gdy stare poświadczenie przestaje działać, wszyscy konsumenci działają z nowym, kopia zapasowa zostaje ukończona, a przywrócenie lub logowanie odzyskiwania kończy się powodzeniem. Wycofuj zmiany wyłącznie wcześniej spisaną metodą; niewyjaśnione błędy uwierzytelniania oznaczają, że inwentaryzacja była niepełna, a unieważnienia nie należy ukrywać za pomocą nowych poświadczeń o szerokich uprawnieniach.