1. Rozdziel to, co opisuje obliczenie, od tego, co daje dostęp
Zacznij od informacji, które Twój program faktycznie konsumuje. Rozmiar partii, nazwa modelu i tryb przetwarzania opisują doświadczenie. Token uprawniający do pobrania lub klucz otwierający magazyn dają dostęp. Pierwszy zbiór musi być możliwy do wyjaśnienia; drugi powinien pozostać dostępny tylko tam, gdzie jest potrzebny.
Granica nie sprowadza się do nazw zmiennych. Ścieżka może ujawnić klienta, URL może zawierać identyfikator, a niewielka próbka danych może być poufna. Oceń więc także zawartość parametrów, którymi można się podzielić. Opublikowanie konfiguracji i opublikowanie wszystkich jej ścieżek bezwzględnych to nie ta sama decyzja.
Tabela proponuje roboczy podział. Nie opisuje usług zainstalowanych na maszynie Kernodeck. Ustal dla swojego projektu, kto może czytać każdy element, w jakim momencie i w której kopii; nie zostawiaj tej decyzji ostatniemu eksportowi notebooka.
Przewiń tabelę, aby zobaczyć wszystkie kolumny.| Element | Rola | Proponowane postępowanie |
|---|---|---|
| Rozmiar partii, tryb, próg | Parametry obliczeń | Wersjonuj i waliduj ich wartości. |
| Token, klucz prywatny, hasło | Środki dostępu | Dostarczaj osobno i nie dołączaj do wyników. |
| Ścieżka, URL, identyfikator korpusu | Potencjalnie wrażliwy kontekst | Sprawdź przed udostępnieniem; preferuj identyfikator logiczny. |
| Wyniki i dzienniki | Dowody wykonania | Wybierz zachowywane pola i kontroluj przekazywany katalog. |
2. Wybierz jedną regułę pierwszeństwa
Parametr obecny w kodzie, pliku i opcji uruchomienia staje się niejednoznaczny, jeśli nikt nie wie, który wygrywa. Ustal prostą regułę, na przykład: udokumentowane wartości domyślne, potem plik konfiguracyjny, potem publiczne opcje polecenia. To kontrakt Twojej aplikacji, a nie uniwersalny priorytet dostarczany przez Python.
Waliduj po tym rozstrzygnięciu. Odrzuć nieznany klucz, aby literówka taka jak batch_szie nie została po cichu zastąpiona wartością domyślną. Rozróżnij liczbę całkowitą, łańcuch znaków reprezentujący liczbę całkowitą i wartość logiczną. Następnie dodaj przydatne ograniczenia: wartość dodatnia, dozwolony tryb, spójna kombinacja parametrów.
Na koniec zapisz efektywną konfigurację ograniczoną do dozwolonych pól. Wyjaśnia ona, czego program użył, nawet gdy opcja zastąpiła plik. Nie uzyskuj tego dokumentu przez serializację całego obiektu konfiguracji przed usunięciem kilku znanych haseł: najpierw wybierz, co może się w nim znaleźć.
3. Przećwicz przykład bez podłączania usługi
Poniższy przykład ma charakter dydaktyczny i nie jest wykonywany. Opisuje fikcyjną operację generowania wektorów z partią ośmiu elementów. Słowo embedding jest tu wyborem interfejsu; żaden model nie jest ładowany i nie zakłada się, że jakakolwiek zależność GPU jest zainstalowana. Do odczytania lub walidacji tego pliku nie jest potrzebny żaden sekret.
Standardowy moduł tomllib, dostępny od Pythona 3.11, odczytuje format TOML. Przekształca wartości dokumentu w obiekty Pythona; nie decyduje, że partia równa zero jest niedozwolona w Twojej aplikacji. Kontrola domeny pozostaje jawna po odczycie.
Ten fragment akceptuje dokładnie dwa klucze i dwa tryby. Aby użyć go w projekcie, podłącz następnie argumenty, obsługę błędów i ścieżki wyjściowe. Oczekiwane odrzucenia są łatwe do przeanalizowania: batch_size równy zero, batch_size jako łańcuch znaków lub dodanie klucza token. To przypadki do sprawdzenia u siebie, a nie wyniki zmierzone tutaj.
batch_size = 8
mode = "embedding"import tomllib
with open("config.toml", "rb") as source:
config = tomllib.load(source)
if set(config) != {"batch_size", "mode"}:
raise ValueError("CONFIG_KEYS")
if type(config["batch_size"]) is not int or config["batch_size"] <= 0:
raise ValueError("CONFIG_BATCH_SIZE")
if config["mode"] not in ("embedding", "classification"):
raise ValueError("CONFIG_MODE")
public_config = {
"batch_size": config["batch_size"],
"mode": config["mode"],
}4. Udostępniaj sekret tylko krokowi, który go potrzebuje
Krok pracujący na już obecnym pliku nie powinien wymagać tokenu pobierania. Poproś o sekret na granicy, na której dostęp staje się konieczny. Jeśli ten krok jest aktywny, ale brakuje mu dostępu, zatrzymaj go z komunikatem wskazującym oczekiwany kanał, bez wyświetlania otrzymanej wartości ani kopiowania całego żądania.
Kanał zależy od dostępnego środowiska: menedżer sekretów, plik poświadczeń o ograniczonym dostępie lub mechanizm wstrzykiwania przewidziany przez Twoją organizację. Zmienna środowiskowa może służyć jako interfejs, ale pozostaje daną dostępną dla procesu i może pojawić się w diagnostyce. Nie myl wygody wstrzykiwania z pełną ochroną.
Ogranicz dostęp do niezbędnego zakresu i zaplanuj jego wymianę. Żądanie przygotowania oprogramowania nie gwarantuje obecności menedżera sekretów. Sprawdź mechanizm faktycznie dostępny, zanim zbudujesz wokół niego swoje uruchomienie, a następnie unikaj przekazywania sekretu do podprocesów, które go nie potrzebują.
5. Projektuj przydatny dziennik bez kopiowania danych wejściowych
Zdefiniuj kilka zdarzeń: konfiguracja zaakceptowana, plik zweryfikowany, partycja zakończona, wynik zatwierdzony. Przypisz im identyfikator uruchomienia, krok i licznik. Błąd CONFIG_BATCH_SIZE wystarcza, aby odnaleźć daną regułę; nie musi zawierać całego pliku.
OWASP zaleca w szczególności wykluczanie z dzienników haseł, tokenów dostępu i kluczy. Stosuj tę zasadę również do wyjątków, obiektów wyświetlanych do debugowania i wyników komórek. Maskowanie zastosowane na ostatnim ekranie nie usuwa tego, co zostało już zapisane w pliku lub zrzucie.
Aby udostępnić incydent, przygotuj niewielki wybór: przydatne wersje, dozwolone parametry, błąd i syntetyczny przykład odtwarzający problem. Unikaj automatycznej archiwizacji całego katalogu. Sprawdź również adresy URL, nagłówki, ścieżki i wiersze sąsiadujące z błędem; pozornie niegroźny komunikat może być otoczony danymi wrażliwymi.
6. Sprawdź separację przed udostępnieniem
Przygotuj trzy próby: poprawna konfiguracja bez kroku zdalnego, niepoprawna konfiguracja i krok wymagający nieobecnego dostępu. Pierwsza powinna móc dojść do swojej granicy funkcjonalnej bez zbędnego sekretu; pozostałe dwie powinny dawać odrębne błędy. Sprawdź też, czy publiczna zmiana rozmiaru partii pojawia się w efektywnej konfiguracji.
Aby sprawdzić swoją procedurę udostępniania, użyj oczywiście fikcyjnego łańcucha wartowniczego bez uprawnień dostępu. Przeprowadź go przez to samo miejsce co sekret podczas izolowanego ćwiczenia, a następnie poszukaj go w dziennikach, eksportach i wybranych plikach. Jego brak jest ograniczoną kontrolą tej ścieżki, a nie dowodem, że wszystkie wycieki są niemożliwe.
Dodaj odpowiednie pliki prywatne do wykluczeń Git, ale sprawdź też pliki już śledzone. Dokumentacja Git precyzuje, że gitignore dotyczy plików nieśledzonych; dodanie wzorca nie usuwa już zapisanego sekretu. Przejrzyj to, co zamierzasz przekazać, a nie tylko reguły, które mają to wykluczyć.
7. Reaguj na ujawnienie i zachowaj użyteczny ślad
Jeśli dostęp został ujawniony, przestań go używać i zleć jego unieważnienie lub wymianę w systemie, który go wydał. Usunięcie wiersza z bieżącego pliku nie czyni poprzednich kopii nieszkodliwymi. Zidentyfikuj odpowiednie miejsca, aby usunąć to, co można, i zrozumieć zakres ujawnienia.
Twój odtwarzalny katalog może następnie zachować nazwę użytego kanału i dozwolone parametry, bez zachowywania samego sekretu. Przyszłe uruchomienie poprosi o ważny dostęp w odpowiednim momencie. Otrzymujesz w ten sposób procedurę, którą można przekazać, bez zamieniania archiwum eksperymentu w pęk kluczy dostępu.
Ta metoda dotyczy Twojej aplikacji i jej rezultatów. Nie gwarantuje ani izolacji całego środowiska, ani braku śladów technicznych gdzie indziej. Aby przejść do wykonania, połącz ją z udokumentowanym środowiskiem, kontrolowanymi danymi i śledzeniem, które odróżnia postęp od zatwierdzonego wyniku.