Jak zapobiec wyciekowi sekretów Jellyfin do plików Compose lub kopii zapasowych

Nie należy traktować pliku Compose, repozytorium Git i archiwum kopii zapasowej jako równoważnych miejsc przechowywania danych uwierzytelniających Jellyfin. Receptura wdrożenia może być szeroko kopiowana, natomiast wartości sekretów powinny mieć węższy cykl życia, zakres dostępu i ścieżkę odzyskiwania.

W przypadku stosu Jellyfin poufne dane mogą obejmować klucze API, dane uwierzytelniające odwrotnego serwera proxy lub tunelu, tokeny dostawcy DNS, hasła do repozytorium kopii zapasowych, klucze szyfrujące, dane dostępowe do baz danych używanych przez usługi pomocnicze oraz inne tokeny wykorzystywane przez wtyczki lub automatyzację. Najpierw zinwentaryzuj te dane, a następnie zdecyduj, które muszą być odtwarzalne, które możliwe do odzyskania, a które można po prostu wygenerować ponownie.

Oddziel odwołania do sekretów od ich wartości

Zachowaj deklaratywny charakter Compose: obrazy usług, sieci, punkty montowania, porty, nazwy zmiennych i odwołania do sekretów powinny znajdować się w pliku, natomiast surowe dane uwierzytelniające — nie. Symbol zastępczy taki jak BACKUP_PASSWORD dokumentuje wymaganie, nie zmieniając pliku Compose w magazyn danych uwierzytelniających.

Pliki środowiskowe w postaci jawnego tekstu są wygodne, ale łatwo skopiować je do kontroli wersji, pakietów diagnostycznych lub nieszyfrowanych kopii zapasowych. Aktualny przewodnik po zarządzaniu sekretami w Dockerze rozróżnia wycieki podczas kompilacji obrazu, rozprzestrzenianie się lokalnych plików .env oraz ujawnienie zmiennych środowiskowych w czasie działania — są to różne drogi prowadzące do tego samego wycieku danych uwierzytelniających.

Używaj menedżera sekretów, mechanizmu plików sekretów obsługiwanego przez Compose lub innej metody wstrzykiwania danych w czasie działania, odpowiedniej dla zależnej usługi. Nie zakładaj, że każde ustawienie Jellyfin obsługuje konwencję _FILE; wstrzykiwanie za pomocą plików stosuj tylko tam, gdzie obsługuje je konkretny komponent.

Nie dopuszczaj do trafiania sekretów do obrazów, repozytoriów ani historii powłoki

Wykluczaj lokalne pliki sekretów zarówno z kontroli wersji, jak i z kontekstu kompilacji Dockera. Samo umieszczenie pliku na liście .gitignore nie powstrzyma szerokiej instrukcji COPY w pliku Dockerfile przed umieszczeniem go w obrazie, jeśli .dockerignore nadal na to pozwala.

Nie przekazuj długoterminowych danych uwierzytelniających bezpośrednio w wierszu poleceń, który zostanie zapisany w historii powłoki. Nie wyświetlaj sekretów podczas debugowania uruchamiania. Unikaj drukowania całego rozwiązanego środowiska w zgłoszeniach lub udostępnionych czatach, jeśli do zdiagnozowania problemu wystarczy pojedyncza zmienna.

Po podejrzeniu wycieku usunięcie wiersza z najnowszego pliku Compose nie jest działaniem naprawczym. Zmień ujawnione dane uwierzytelniające, unieważnij stare tokeny, jeśli to możliwe, przeanalizuj historię repozytorium i obrazów oraz usuń wyciekniętą wartość z przyszłych kopii zapasowych i danych diagnostycznych.

Projektuj kopie zapasowe tak, aby wymagane sekrety można było odzyskać, ale nie odczytać przypadkowo

Niektóre sekrety są częścią procesu odzyskiwania. Zaszyfrowana kopia zapasowa jest bezużyteczna, jeśli hasło do repozytorium lub klucz deszyfrujący zginie wraz z tym samym serwerem, a przywrócony stos proxy lub automatyzacji może potrzebować danych uwierzytelniających, których nie da się odtworzyć wyłącznie z receptury Compose.

Praktyczny spis zasobów potrzebnych do odzyskania usług hostowanych samodzielnie traktuje klucze, tokeny, kody odzyskiwania i hasła do kopii zapasowych jako podstawowe materiały potrzebne do odtworzenia systemu, jednocześnie przechowując klucze odblokowujące kopie zapasowe poza serwerem, którego kopie są tworzone. To nie jest równoznaczne z umieszczaniem jawnego pliku .env w każdym archiwum.

Utwórz manifest odzyskiwania sekretów, który zawiera nazwę każdego wymaganego poświadczenia, jego właściciela, miejsce przechowywania kopii nadrzędnej, sposób przywrócenia lub ponownego wydania oraz informację, którą kopię zapasową ono odblokowuje. Wartości poufne przechowuj w zaszyfrowanym menedżerze haseł, zaszyfrowanym zestawie kopii zapasowych lub oddzielnym, chronionym pakiecie odzyskiwania, stosując mechanizmy kontroli dostępu odpowiednie dla gospodarstwa domowego.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Nie pozwól, aby logi i pakiety diagnostyczne stały się drugim magazynem sekretów

Adresy URL żądań proxy, zrzuty środowiska, dane debugowania aplikacji i transkrypcje powłoki mogą ujawniać tokeny nawet wtedy, gdy konfiguracja Compose jest prawidłowa. Przed udostępnieniem logów wyszukaj nagłówki autoryzacji, klucze API, tokeny w parametrach zapytań, pliki cookie, prywatne nazwy hostów i dane uwierzytelniające.

Wytyczne dotyczące logowania zalecają redagowanie poufnych pól przed opuszczeniem systemu przez dane telemetryczne. Tę samą zasadę stosuj do pakietów pomocy technicznej dotyczących serwera domowego: w razie potrzeby zachowaj oryginał lokalnie do celów diagnostycznych, ale udostępniaj kopię po usunięciu poufnych danych.

Ograniczaj dostęp do kopii zapasowych i logów niezależnie od siebie. Osoba, która może odczytywać kopie zapasowe multimediów, nie potrzebuje automatycznie dostępu do tokenów DNS ani danych uwierzytelniających odwrotnego serwera proxy. Ujawnienie sekretów jest w takim samym stopniu problemem zakresu dostępu, co formatu pliku.

Przeprowadzaj jednocześnie test wycieku i test odzyskiwania

Utwórz sekret testowy z rozpoznawalną, fałszywą wartością, wdroż stos, a następnie wyszukaj tę wartość w katalogu Compose, historii obrazów, wynikach inspekcji kontenerów, logach, katalogu kopii zapasowych i rozpakowanym środowisku testowym po przywróceniu. Dzięki temu wykryjesz miejsca, w których bieżący proces kopiuje sekrety, bez narażania prawdziwych danych uwierzytelniających.

Następnie wykonaj test odwrotny: przywróć stos Jellyfin do odizolowanego środowiska docelowego, korzystając wyłącznie z udokumentowanych materiałów odzyskiwania. Jeśli odzyskiwanie wymaga poświadczenia istniejącego tylko na uszkodzonym hoście, projekt zawiera zbyt mało sekretów potrzebnych do odzyskania; jeśli każda zwykła kopia zapasowa ujawnia wszystkie poświadczenia w postaci jawnego tekstu, zawiera ich zbyt dużo.

Granica zasady najmniejszych uprawnień w ZimaSpace jest ostatecznym sprawdzianem: każda usługa, zadanie tworzenia kopii zapasowej, administrator i proces odzyskiwania powinny otrzymywać wyłącznie sekrety wymagane do pełnienia swojej roli. Zmień wszystkie sekrety, które nieoczekiwanie przekroczyły tę granicę.