HashiCorp Vault Operations Advanced — Preguntas de práctica y simulacro de examen

Los audit devices de Vault aplican un hash a los valores de texto sensibles con un HMAC-SHA256 con sal propia de cada device antes de escribir las entradas del log. Por eso el campo auth.accessor contiene el HMAC del accessor del token y no el accessor en bruto. Puedes correlacionar un accessor conocido con su forma hasheada mediante el endpoint /sys/audit-hash. La opción “El token en texto plano que autenticó la solicitud” es incorrecta: los tokens en bruto nunca se escriben en los audit logs. La opción “La dirección IP desde la que se originó la solicitud” describe request.remote_address, un campo aparte. La opción “La lista de nombres de políticas asociadas al token” describe auth.policies, que también es otro campo. La opción hmac_accessor puede desactivar este hasheo, pero no se recomienda. Ref: developer.hashicorp.com/vault/docs/audit; /vault/docs/audit/schema

Cuando Vault envuelve una respuesta mediante wrap-ttl, almacena la respuesta real dentro del cubbyhole de un wrapping token de un solo uso, en cubbyhole/response. Solo quien tenga ese token puede desenvolverla mediante /sys/wrapping/unwrap (Ref: developer.hashicorp.com/vault/docs/concepts/response-wrapping). El cubbyhole pertenece exclusivamente al wrapping token: ningún otro token puede acceder a él, y los datos se destruyen cuando el token expira o se usa. La opción “En los metadatos de la identity entity de quien hizo la solicitud, cifrados…” es incorrecta: los metadatos de una identity entity no se usan para almacenar respuestas. La opción “En el audit log, recuperable por la ruta del audit device” es incorrecta: los audit logs guardan datos hasheados con fines de cumplimiento, no secretos recuperables. La opción “En el campo de metadatos del wrapping token, accesible…” es incorrecta: los campos de metadatos de un token son etiquetas visibles para el cliente, no un almacén de secretos.