Límites de confianza y tipos de secreto
Personal y Community mantienen el acceso sin servidor. En Enterprise, los secretos de control estricto requieren autorización central de identidad, dispositivo y política antes de cada nueva entrega de material criptográfico. El descifrado puede hacerse en el cliente autorizado sin exponer el texto claro al coordinador.
La revocación central no borra una clave ya copiada o almacenada localmente. Confidencialidad y control central son propiedades distintas, no una garantía ilimitada de recuperación de secretos divulgados.
Identidad, políticas y nueva autorización
Los principales incluyen usuarios e identidades de máquina, con grupos, roles, contexto de dispositivo y políticas por secreto. Leer, entregar, modificar, rotar y administrar son permisos diferentes. Cada nueva entrega de claves restringidas requiere una decisión del servidor.
La decisión queda vinculada a principal, secreto y versión, política, caducidad y correlación. Si la comprobación central falla, la entrega nueva se deniega de forma segura.
Registro central y alcance de las pruebas
Cada evento incluye fecha UTC, ID, identidad, dispositivo o servicio, secreto y versión, acción, política, decisión e ID de correlación. No se registran valores, tokens ni claves en claro.
Un almacén protegido puede incorporar registros append-only/WORM, firmas y cadenas de integridad. Pero un cliente comprometido puede ocultar descifrados y copias: el registro prueba entregas autorizadas, no todos los usos posteriores.
Para secretos críticos, la recepción del evento por el sistema de auditoría puede exigirse antes de liberar claves. Si el servicio falla, se bloquea la entrega nueva.
Bajas, inventario de exposición y rotación
Revocar pertenencia, grupos, roles, dispositivos e identidades técnicas. Correlacionar permisos y eventos para identificar secretos y versiones potencialmente accesibles, incluidas copias locales conocidas. La falta de telemetría no demuestra ausencia de copias.
Rotar o invalidar credenciales en cada sistema de destino y actualizar consumidores. Reempaquetar una clave del cofre no invalida un token o contraseña ya extraídos.
Identidades de máquina, OIDC y CI/CD
Cada servicio recibe un principal, alcance y vigencia propios. El pipeline acredita su identidad mediante OIDC; se comprueban firma, emisor, audiencia, sujeto, caducidad y contexto del flujo.
Los permisos duran poco; no se imprimen tokens ni secretos en logs. Cada entrega registra servicio, versión y correlación. Las credenciales copiadas solo pierden vigencia tras caducidad o rotación en el destino.
Integraciones opcionales
La capa de políticas permanece separada del almacenamiento. OpenBao o herramientas similares pueden incorporarse después mediante conectores opcionales, sin dependencia para Personal o Community.
El registro documenta decisiones y entregas, no todas las copias. La revocación bloquea entregas futuras; la rotación aborda credenciales ya divulgadas.