Granice zaufania i klasy sekretów
Sejfy Personal i Community pozostają w pełni funkcjonalne offline. Enterprise dodaje centralnie kontrolowane klasy sekretów: każda nowa dostawa niezbędnego materiału kluczowego wymaga serwerowej weryfikacji tożsamości, urządzenia i zasad. Odszyfrowanie może odbywać się po stronie klienta; koordynator nie musi widzieć tekstu jawnego.
Cofnięcie dostępu po stronie serwera nie usuwa materiału kluczowego zapisanego wcześniej w pamięci podręcznej ani ujawnionego przez przejęty klient. Poufne przechowywanie i centralna kontrola dostępu to różne właściwości, a nie bezwarunkowa gwarancja pełnego zero knowledge i natychmiastowego odebrania dostępu.
Tożsamość, zasady i ponowna autoryzacja
Podmiotami mogą być pracownicy i tożsamości maszynowe, z przynależnością organizacyjną, kontekstem urządzenia lub obciążenia, grupami, rolami i zasadami dla sekretów. Odczyt, wydanie, edycja, rotacja i administracja to odrębne uprawnienia. Nowy materiał kluczowy dla ściśle kontrolowanych sekretów wymaga nowej decyzji serwera.
Każda decyzja wiąże podmiot, identyfikator i wersję sekretu, rewizję zasad, czas wygaśnięcia, żądaną operację i identyfikator korelacji. Gdy nie da się zweryfikować autoryzacji, nowe wydania chronionych sekretów są blokowane; wcześniej ujawniony materiał pozostaje poza tą gwarancją.
Centralny dziennik audytu: pola i dowody
Zdarzenia zawierają znacznik czasu UTC, identyfikator zdarzenia, podmiot lub proces, identyfikator i wersję sekretu, kontekst urządzenia lub procesu, operację, odwołanie do zasad, decyzję i identyfikator korelacji. Rejestruje się zgody, odmowy i działania administracyjne. Nigdy nie zapisuj wartości sekretów, tokenów, kluczy jawnych ani pełnych danych.
Chroniony magazyn centralny może stosować zapis tylko do dopisywania/WORM, łańcuchy integralności i podpisane rekordy, aby wykrywać manipulację po przyjęciu zdarzeń. Przejęty klient może jednak ukryć lokalne odszyfrowanie lub niezauważoną kopię: audyt dowodzi autoryzowanego wydania klucza, nie każdego późniejszego użycia.
W politykach wysokiej wrażliwości potwierdzenie przyjęcia zdarzenia audytu może być warunkiem wydania klucza. Gdy ścieżka autoryzacji lub audytu jest niedostępna, nowe wydanie jest blokowane, co stanowi kompromis między dostępnością a silnym centralnym śladem decyzji.
Odbieranie dostępu, wykaz ujawnień i rotacja
Cofnij członkostwa, role, urządzenia i uprawnienia procesów. Zestaw wydania kluczy z zapisami dostępu, aby ustalić potencjalnie osiągalne identyfikatory i wersje sekretów, w tym znane kopie offline i wcześniejsze koperty kluczy. Brak telemetrii klienta nie dowodzi, że sekretu nigdy nie skopiowano.
Zmień lub unieważnij poświadczenie w systemie docelowym, zaktualizuj zależne aplikacje, w razie potrzeby wydaj nowe generacje kluczy i monitoruj ukończenie. Ponowne opakowanie klucza sejfu nie unieważnia tokenu API ani hasła wcześniej skopiowanego z sejfu.
Tożsamości maszynowe, OIDC i CI/CD
Procesy otrzymują osobne tożsamości, wąskie zakresy uprawnień, limity czasu i przypisanie zdarzeń audytu. Procesy CI/CD uwierzytelniają się u zaufanego wystawcy OIDC; przed wydaniem dostępu należy zweryfikować podpis tokenu, odbiorcę, podmiot, wygaśnięcie i roszczenia właściwe dla przepływu pracy.
Krótkie okresy ważności i najmniejsze uprawnienia ograniczają skutki naruszenia. Poświadczenia i tokeny nie mogą pojawiać się w logach procesów ani centralnych zdarzeniach audytu. Każde zatwierdzone wydanie zapisuje proces, wersję sekretu i korelację żądania. Wcześniej skopiowane poświadczenie działa do wygaśnięcia lub rotacji w systemie docelowym.
Opcjonalne integracje
Warstwa zasad i wydawania kluczy jest niezależna od zaplecza przechowywania. OpenBao i podobne systemy mogą być w przyszłości obsługiwane przez opcjonalne integracje bez narzucania serwera edycjom Personal i Community.
Rejestry audytu potwierdzają decyzje i wydania; cofnięcie dostępu blokuje nowe autoryzowane wydania, nie wcześniejsze kopie. Autoryzacja, audyt, rotacja poświadczeń i tożsamości procesów tworzą więc jeden spójny system kontroli.