Brama HITL zapewnia, że żadna akcja agenta o wysokim ryzyku nie przebiegnie bez ludzkiego osądu. Ta receptura przeprowadza przez pełny cykl życia zatwierdzania — od momentu, gdy zarządzana akcja uruchamia żądanie, przez rozwiązanie poziomu ryzyka, ludzkie decyzje i zawór bezpieczeństwa break-glass — abyś mógł prześledzić każdy ruchomy element zanim napotkasz go w produkcji.
Jeśli nie czytałeś jeszcze modelu autoryzacji, zacznij od Zarządzanie. Przewodnik Zarządzaj i zatwierdzaj obejmuje tę samą mechanikę z perspektywy operatora; ta strona to referencja krok po kroku.
Cykl życia żądania
Żądanie zatwierdzania otwiera się domyślnie odrzucająco i z ograniczeniem czasowym.
Zaczyna ze statusem pending, niesie wygaśnięcie i nie autoryzuje niczego, dopóki
wystarczająca liczba ludzi nie zdecyduje. Żądanie nie może obniżać własnej poprzeczki —
pasująca polityka zatwierdzania jest autorytatywna dla progu i timeoutów.
Żądanie jest powiązane z hashem planu dokładnego ładunku wywołania narzędzia. To obrona anty-TOCTOU: jeśli bazowa akcja zmieni się między żądaniem a decyzją, hash nie będzie pasował i zatwierdzenie nie może zostać powiązane. Przestarzałe zatwierdzenie nigdy nie autoryzuje innej akcji.
Rozwiązanie poziomu ryzyka
Cztery poziomy sterują tym, ile ludzkiej kontroli wymaga zarządzana akcja:
| Poziom | Co oznacza |
|---|---|
low / medium | Przypisywany tylko przez wyraźną politykę zatwierdzania — nic nie trafia tu domyślnie |
high | Domyślny dla wszystkiego, co trafia do kolejki zatwierdzania. Wymagane jedno ludzkie zatwierdzenie |
critical | Obowiązkowy próg dwuosobowy (NIST SP 800-53 AC-3(2) podwójna autoryzacja) |
Poziom jest ponownie wyprowadzany z aktywnego zbioru polityk przy każdej decyzji, nigdy czytany z zapisanego snapshotu. Zmiana polityki zaczyna obowiązywać natychmiast. Przestarzały wiersz nigdy nie może utrzymać poprzeczki niżej niż bieżąca klasyfikacja — to domyślne odrzucanie z konstrukcji.
Wbudowany zbiór critical obejmuje prawdziwie nieodwracalne: wdrożenie i wycofanie
produkcyjne, usunięcie i kasowanie danych, zmiany w egzekucji bezpieczeństwa i
wyłącznika awaryjnego, opieka nad kluczami i rotacja, oraz wyłączanie NHI.
Polityka zatwierdzania z wyraźnym risk_tier może podnosić lub obniżać domyślny
poziom per akcja. Ale nigdy nie może obniżyć akcji critical poniżej progu
podwójnej kontroli.
Krok po kroku
1. Zarządzana akcja uruchamia żądanie
Zarządzana akcja — deploy apply, agent fire, nadpisanie budżetu lub jakakolwiek
akcja pasująca do polityki zatwierdzania — dociera do silnika zatwierdzania. Silnik
otwiera nowe żądanie ze statusem pending.
2. Żądanie wiąże się z hashem planu
Żądanie rejestruje hash dokładnego ładunku wywołania narzędzia. To wiązanie z hashem planu jest obroną TOCTOU: decyzja autoryzuje tylko akcję, dla której żądanie zostało utworzone.
3. Poziom ryzyka jest rozwiązywany z bieżącej polityki
Silnik ewaluuje aktywny zbiór polityk (RBAC, natywny ABAC i dowolny zewnętrzny PDP) w celu wyprowadzenia poziomu ryzyka. Poziom nigdy nie jest buforowany z wcześniejszej ewaluacji.
4. Ludzki recenzent decyduje
Człowiek z wystarczającą rolą wydaje approve lub deny. Serwer wymusza trzy
niezmienniki w tym punkcie, kluczowane na stabilnej tożsamości użytkownika:
- Rozdzielenie obowiązków. Wnioskujący nie może decydować o własnym żądaniu. To kluczuje na stabilnej tożsamości użytkownika, nie na łańcuchu poświadczeń, który jedna osoba mogła zmieniać.
- Ochrona przed duplikatem decydenta. Unikalny indeks stanowi zabezpieczenie przed wyścigiem duplikatu decydenta — jeden człowiek liczy się raz wobec progu.
- Wygaśnięcie wiąże. Wygasłe żądanie nigdy nie może otrzymać wiążącej decyzji, nawet zanim przegląd zmaterializuje wygaśnięcie. Efektywny status jest ponownie wyprowadzany przy każdej decyzji.
5. Krytyczne akcje: podwójna kontrola z AAL3
Dla poziomu critical: próg jest ustawiony na minimum dwóch różnych ludzkich
zatwierdzających. Próg jest wymuszany zarówno przy tworzeniu (zapisany próg nigdy
nie może zaczynać poniżej dwóch) jak i ponownie stosowany przy decyzji (żądanie
utworzone zanim akcja stała się krytyczna nadal nie może przejść z jednym człowiekiem).
Każdy decydujący człowiek musi mieć świeżą sesję weryfikowaną sprzętowo — WebAuthn lub podwyższenie PIV (AAL3). Token systemowy nie niesie ludzkiej pewności i jest odrzucany.
6. Decyzja jest rejestrowana w rejestrze
Każda decyzja dołącza niezmienny wiersz do śladu decyzji żądania i zdarzenie rejestru zapisujące decyzję, wynikowy status i poziom ryzyka, w ramach którego została podjęta. Rejestr jest tylko-do-dopisywania, z łańcuchem haszy i podpisany Ed25519 — przepisywanie historii jest kryptograficznie wykrywalne.
Wygaśnięcie
Wygaśnięcie jest wyprowadzane przy odczycie, nie zapisywane raz. Wygasłe żądanie nigdy nie może otrzymać wiążącej decyzji, nawet jeśli żaden przegląd w tle nie zmaterializował jeszcze wygaśnięcia. Efektywny status jest zawsze ponownie wyprowadzany, więc wolny przegląd to opóźnienie kosmetyczne, nie luka bezpieczeństwa.
Konfiguracja polityk
Polityki zatwierdzania pozwalają nadpisać domyślny poziom ryzyka per klasa akcji.
Polityka z wyraźnym risk_tier może przesunąć akcję z high do low lub podnieść
medium do critical. Jedno ograniczenie: nigdy nie możesz obniżyć critical
poniżej progu podwójnej kontroli. Wymóg dwuosobowy dla nieodwracalnych akcji jest
strukturalny, nie konfigurowalny.
Break-glass
Gdy kworum jest nieosiągalne — incydent o 03:00, gdy drugi zatwierdzający śpi — break-glass zapewnia audytowany zawór bezpieczeństwa. Jest głośny z konstrukcji.
Aktywacja wymaga wszystkiego naraz:
- Aktywujący jest adminem, zawsze prawdziwym człowiekiem — token systemowy jest odrzucany.
- Świeże podwyższenie AAL3 (WebAuthn lub PIV).
- Pisemne uzasadnienie rejestrowane w tej samej transakcji.
- Aktywnie nagrywana sesja jako warunek wstępny.
Ograniczenie czasowe: nadanie domyślnie trwa godzinę, z twardym limitem 24. Sytuacja awaryjna, która potrzebuje dłużej, to tryb operacyjny, nie sytuacja awaryjna, i musi przejść przez normalną podwójną kontrolę.
Każde użycie jest rejestrowane. Każda akcja podjęta w ramach break-glass dołącza niezmienny wiersz i zdarzenie rejestru nazywające nadanie, akcję i podmiot. Akcja, która przebiegła w ramach break-glass, jest trwale odróżnialna od prawidłowo zatwierdzonej.
Wymuszona kontrola po fakcie. Nowe nadanie nie może być aktywowane, gdy jakiekolwiek poprzednie nadanie jest niesprawdzone. Przegląd musi pochodzić od innego człowieka niż aktywujący. Nie możesz spiętrzać sytuacji awaryjnych, by uniknąć kontroli.
Break-glass łagodzi brakujące kworum; nigdy nie nadpisuje jawnego odrzucenia. Żądanie, które ktoś celowo odrzucił, pozostaje odrzucone.
Co jest rejestrowane
Każda decyzja — approve, deny, expire lub użycie break-glass — dołącza do dwóch miejsc:
- Ślad decyzji żądania: niezmienna sekwencja wierszy decyzji na samym żądaniu, każdy niosący decydenta, werdykt i znacznik czasu.
- Rejestr audytu: zdarzenie z łańcuchem haszy, podpisane Ed25519, zapisujące decyzję, wynikowy status żądania i poziom ryzyka, w ramach którego została podjęta.
Oba zapisy następują w tej samej transakcji co zmiana stanu. Nie możesz podjąć zarządzanej decyzji, która rejestr cicho zapomni.
Powiązane
- Zarządzaj i zatwierdzaj — przewodnik operatora obejmujący tę samą mechanikę.
- Zarządzanie — model autoryzacji, postawa samoaudytu i mechanika wyłącznika awaryjnego.
- Receptura: ćwiczenie wyłącznika awaryjnego — ćwiczenie bramy odrzucania całej infrastruktury.
- Wyłącznik awaryjny — strona produktowa zatrzymania awaryjnego.