Limites de confiança e tipos de segredos
Personal e Community mantêm o acesso sem servidor. No Enterprise, os segredos sob controlo rigoroso exigem autorização central da identidade, do dispositivo e da política antes de cada nova entrega de material criptográfico. A desencriptação pode ocorrer no cliente autorizado sem expor o texto em claro ao coordenador.
A revogação central não apaga uma chave já copiada ou guardada localmente. A confidencialidade e o controlo central são propriedades distintas, não uma garantia ilimitada de recuperação de segredos divulgados.
Identidade, políticas e nova autorização
As entidades principais incluem utilizadores e identidades de máquina, com grupos, funções, contexto do dispositivo e políticas por segredo. Ler, entregar, modificar, rodar e administrar são permissões distintas. Cada nova entrega de chaves restritas requer uma decisão do servidor.
A decisão fica associada à entidade principal, ao segredo e à versão, à política, à validade e à correlação. Se a verificação central falhar, a nova entrega é recusada de forma segura.
Registo central e alcance das evidências
Cada evento inclui a data UTC, o ID, a identidade, o dispositivo ou serviço, o segredo e a versão, a ação, a política, a decisão e o ID de correlação. Nunca são registados valores, tokens nem chaves em claro.
Um armazenamento protegido pode incorporar registos append-only/WORM, assinaturas e cadeias de integridade. Porém, um cliente comprometido pode ocultar desencriptações e cópias: o registo comprova entregas autorizadas, não todas as utilizações posteriores.
Para segredos críticos, pode ser exigida a receção do evento pelo sistema de auditoria antes da libertação de chaves. Se o serviço falhar, a nova entrega é bloqueada.
Saída de colaboradores, inventário de exposição e rotação
Revogar adesões, grupos, funções, dispositivos e identidades técnicas. Correlacionar permissões e eventos para identificar segredos e versões potencialmente acessíveis, incluindo cópias locais conhecidas. A ausência de telemetria não demonstra que não existam cópias.
Rodar ou invalidar credenciais em cada sistema de destino e atualizar os sistemas consumidores. Reencapsular uma chave do cofre não invalida um token nem uma palavra-passe já extraídos.
Identidades de máquina, OIDC e CI/CD
Cada serviço recebe uma identidade, um âmbito e uma validade próprios. O pipeline autentica-se com OIDC; verificam-se a assinatura, o emissor, a audiência, o sujeito, a validade e o contexto do fluxo.
As permissões são de curta duração; tokens e segredos não são escritos em logs. Cada entrega regista o serviço, a versão e a correlação. As credenciais copiadas só deixam de ser válidas após expiração ou rotação no destino.
Integrações opcionais
A camada de políticas permanece separada do armazenamento. OpenBao ou ferramentas semelhantes poderão ser integradas mais tarde através de conectores opcionais, sem dependências obrigatórias para Personal ou Community.
O registo documenta decisões e entregas, não todas as cópias. A revogação bloqueia entregas futuras; a rotação trata as credenciais já divulgadas.