Dlaczego przenosić sekrety serwera domowego z plików konfiguracyjnych do magazynu sekretów?

Sekrety serwera domowego powinny trafiać do magazynu sekretów, ponieważ pliki konfiguracyjne powielają długoterminowe dane uwierzytelniające w aplikacjach, kopiach zapasowych, logach i procedurach administratorów.

Samodzielnie hostowany serwer często zaczyna się od jednego hasła do bazy danych w pliku Compose, a następnie rozrasta się o klucze API, tokeny chmurowe, dane uwierzytelniające SMTP, klucze VPN, hasła szyfrowania, sekrety webhooków i pliki cookie administratora. Te wartości mogą być kopiowane do plików środowiskowych, wyeksportowanych stosów, zrzutów ekranu, kopii zapasowych, historii powłoki i pakietów pomocy technicznej. Magazyn sekretów nie sprawia, że każda aplikacja staje się godna zaufania, ale tworzy jedną kontrolowaną ścieżkę pobierania z oddzielnym uwierzytelnianiem, rotacją, zasadami dostępu i rejestrami audytowymi. Poniższe sekcje wyjaśniają, jak zmienia to granicę ekspozycji.

Pliki konfiguracyjne zamieniają jedno poświadczenie w wiele kopii

Plik konfiguracyjny ma być czytelny dla aplikacji i wygodny we wdrażaniu. Gdy zawiera poświadczenia w postaci zwykłego tekstu, każda kopia tego pliku staje się kolejnym miejscem, w którym sekret może zostać utracony.

HashiCorp opisuje rozprzestrzenianie się sekretów jako występowanie poświadczeń w kodzie źródłowym, konfiguracji, systemach kontroli wersji, wiki i innych systemach bez jednego wiarygodnego rejestru. Na serwerze domowym wyeksportowane stosy Compose i automatyczne kopie zapasowe mogą przechowywać stare wartości długo po zmianie działającej aplikacji.

Ryzyko nie ogranicza się do kradzieży bieżącego pliku. Zredagowany pulpit, skopiowane archiwum diagnostyczne lub wycofana kopia zapasowa mogą zawierać nadal ważny token, którego nikt nie pamięta, aby unieważnić.

Magazyn sekretów oddziela konfigurację od materiału uwierzytelniającego

Aplikacja nadal potrzebuje adresu bazy danych, nazwy użytkownika, nazwy sekretu lub metody pobierania, ale konfiguracja wdrożeniowa nie musi już zawierać samej wartości poświadczenia.

Scentralizowany magazyn tworzy kontrolowaną ścieżkę pobierania, w ramach której uwierzytelnione obciążenie otrzymuje tylko sekret, do którego użycia jest uprawnione. Sekret może być wstrzykiwany w czasie działania, montowany w ograniczonej ścieżce opartej na pamięci lub wymieniany na poświadczenie krótkotrwałe.

Nie zapobiega to użyciu własnego sekretu przez zaatakowaną, ale uprawnioną aplikację. Domyślnie uniemożliwia jednak otrzymanie tej wartości przez niepowiązane aplikacje, kopie zapasowe i osoby odczytujące konfigurację.

Sam magazyn staje się elementem infrastruktury krytycznej, dlatego jego dostępność, tworzenie kopii zapasowych, odzyskiwanie i dostęp administratorów trzeba zaprojektować w sposób jawny.

Tożsamość poszczególnych aplikacji zastępuje współdzielone poświadczenia administratora

Magazyn sekretów jest najbardziej użyteczny, gdy każda aplikacja uwierzytelnia się za pomocą własnej tożsamości. Kilka kontenerów nie powinno pobierać sekretów, współdzieląc jeden token root lub jeden szeroko dostępny plik główny.

Współczesne praktyki zarządzania sekretami łączą tożsamość obciążenia z zasadą najmniejszych uprawnień, dzięki czemu aplikacja do zdjęć może odczytać hasło do swojej bazy danych, podczas gdy narzędzie do pobierania nie może żądać kluczy szyfrowania kopii zapasowych. Tożsamość można powiązać z maszyną, kontem usługi, orkiestratorem, certyfikatem lub krótkotrwałym procesem logowania.

Zmienia to skalę skutków wycieku poświadczeń aplikacji. Osoba atakująca zyskuje jedną ograniczoną ścieżkę dostępu do sekretu zamiast pliku zawierającego poświadczenia wszystkich usług na hoście.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

$799.00 - $2,499.00

Buy Now

Rotacja staje się operacją cyklu życia zamiast wyszukiwaniem plików

Poświadczenia wpisane na stałe w kod są trudne do zmiany, ponieważ trzeba znaleźć, edytować i ponownie uruchomić w odpowiedniej kolejności każdego odbiorcę oraz każdą skopiowaną konfigurację. Ten koszt operacyjny sprzyja używaniu długoterminowych sekretów.

Dynamiczne sekrety mogą być generowane na jedną sesję aplikacji, a następnie unieważniane lub wygaszane bez wpisywania stałego hasła do kilku plików. Sekrety statyczne również można wersjonować i centralnie rotować, gdy backend nie umożliwia dynamicznego wydawania poświadczeń.

Rotacja nadal wymaga od aplikacji obsługi bezpiecznego ponownego wczytywania lub odnawiania poświadczeń. Magazyn nie wyeliminuje przestoju, jeśli aplikacja odczytuje sekret tylko podczas uruchamiania i przez nieograniczony czas utrzymuje nieaktualne połączenia.

Rejestry audytowe pokazują, które obciążenie pobrało sekret

Pliki tekstowe rzadko rejestrują, kto je odczytał. Dzienniki systemu plików mogą w niektórych środowiskach pokazywać dostęp, ale zwykle nie łączą odczytu z nazwą wersji sekretu, decyzją dotyczącą zasad dostępu ani późniejszym użyciem w backendzie.

Wytyczne dotyczące zarządzania sekretami uznają audytowanie dostępu za kluczową korzyść centralizacji. Rejestr pobrania może wskazywać obciążenie, ścieżkę sekretu, czas, źródło i wynik, pomagając odróżnić normalne uruchomienie od nieoczekiwanego masowego dostępu.

Logi audytowe należy przechowywać poza monitorowaną aplikacją i chronić przed wyciekiem sekretów. Rejestrowanie pełnej zwróconej wartości odtworzyłoby pierwotną ekspozycję.

Migracja musi usunąć stare kopie, a nie tylko dodać sejf

Przeniesienie poświadczenia do magazynu nie unieważnia kopii znajdujących się już w historii Git, kopiach zapasowych, eksportach Compose, zrzutach ekranu, historii powłoki ani logach aplikacji.

GitGuardian zaleca łączenie dedykowanego zarządzania z rotacją poświadczeń i skanowaniem, ponieważ sejf zarządza wartościami pobieranymi w prawidłowy sposób, ale nie może usunąć sekretów, które wcześniej wyciekły. Po migracji wykonaj rotację poświadczenia, a następnie w miarę możliwości usuń lub wygaszaj stare, możliwe do odzyskania kopie.

Omówiony przez ZimaSpace zakres montowania bind dotyczy tej samej granicy: plik sekretu zamontowany we wszystkich kontenerach pozostaje szeroko dostępny, nawet jeśli jego źródło nazywa się sejfem.

Przetestuj odzyskiwanie po czystym ponownym uruchomieniu, usuwając sekret z pierwotnej konfiguracji. Migracja jest zakończona dopiero wtedy, gdy właściwe aplikacje pobierają aktualne wartości, nieuprawnione aplikacje otrzymują odmowę dostępu, rotacja działa, a sam magazyn sekretów można bezpiecznie odtworzyć.

FAQ

Czy zmienne środowiskowe są magazynem sekretów?

Nie. Są mechanizmem dostarczania i w zależności od platformy nadal mogą pojawiać się podczas inspekcji procesów, w raportach awarii, metadanych kontenerów, danych wyjściowych debugowania lub eksportach wdrożeń.

Czy każdy serwer domowy powinien korzystać z dedykowanego produktu typu vault?

Niekoniecznie. Wymagana złożoność zależy od liczby aplikacji, modelu zagrożeń, umiejętności odzyskiwania danych oraz od tego, czy prostsze wstrzykiwanie chronionych plików może zapewnić ograniczony dostęp i niezawodną rotację.

Czy magazyn sekretów chroni przed zaatakowaną, uprawnioną aplikacją?

Tylko częściowo. Może ograniczyć zakres sekretów otrzymywanych przez aplikację i skrócić ich czas życia, ale aplikacja nadal może używać poświadczeń, do których pobrania ma prawidłowe uprawnienia.