Confini di fiducia e classi di secret
Personal e Community restano operativi senza server. In Enterprise, i secret con controllo rigoroso richiedono una verifica centrale di identità, dispositivo e policy prima di ogni nuovo rilascio del materiale di chiave. La decifratura può avvenire sul client autorizzato senza rivelare il contenuto al coordinatore.
La revoca server non cancella materiale crittografico già copiato o memorizzato localmente. Riservatezza e controllo centralizzato sono garanzie diverse, non una promessa di revoca retroattiva.
Identità, policy e nuova autorizzazione
Gli attori sono persone o identità macchina, associati a ruoli, gruppi, dispositivi e policy per secret. Lettura, rilascio, modifica, rotazione e amministrazione sono autorizzazioni separate. Nuove chiavi per secret controllati richiedono una nuova decisione server.
La decisione lega soggetto, secret e versione, revisione policy, scadenza e correlazione. Se il controllo centrale non è disponibile, il nuovo rilascio di materiale sensibile viene negato.
Audit centralizzato e valore probatorio
Gli eventi contengono tempo UTC, ID, soggetto, dispositivo o workload, secret e versione, azione, policy, esito e correlazione. Valori, token e chiavi in chiaro non entrano nei log.
Uno storage centrale protetto può impiegare append-only/WORM, firme e catene di integrità. Un client compromesso può tuttavia occultare decifrature o copie locali: l’audit documenta il rilascio autorizzato, non ogni utilizzo.
Per secret altamente sensibili una conferma di registrazione può essere richiesta prima del rilascio. Senza autorizzazione o servizio audit disponibile, nuove chiavi non vengono fornite.
Offboarding, inventario delle esposizioni e rotazione
Revocare account, ruoli, gruppi, device e identità tecniche. Correlare grant ed eventi per individuare secret, versioni e copie locali note potenzialmente accessibili. La mancanza di telemetria non prova che non esistano copie.
Ruotare o invalidare le credenziali nei sistemi esterni, aggiornare i servizi dipendenti e verificare la chiusura. Il solo rewrapping della chiave di un vault non invalida una password già copiata.
Identità macchina, OIDC e CI/CD
Ogni workload riceve identità, scope e scadenza specifici. Una pipeline usa un issuer OIDC attendibile; firma, issuer, audience, subject, scadenza e claim contestuali vengono controllati.
Lease e credenziali sono a durata ridotta. Token e secret non compaiono nei log di build o di audit. Ogni rilascio registra workload, versione e correlazione; copie pregresse rimangono valide fino a scadenza o rotazione nel servizio target.
Integrazioni opzionali
Le policy rimangono indipendenti dal backend storage. OpenBao e prodotti simili possono essere integrati più avanti con connettori opzionali, senza obblighi server per Personal o Community.
L’audit prova decisioni e rilasci, non l’assenza di copie. La revoca blocca nuovi rilasci; la rotazione tratta credenziali già esposte.