HashiCorp Vault Operations Advanced — Questões de prática e simulado

Os audit devices do Vault aplicam hash aos valores de texto sensíveis com um HMAC-SHA256 com salt próprio de cada device antes de gravar as entradas do log. Por isso o campo auth.accessor contém o HMAC do accessor do token, e não o accessor bruto. Você pode correlacionar um accessor conhecido com sua forma em hash pelo endpoint /sys/audit-hash. A opção “O token em texto puro que autenticou a requisição” está incorreta: tokens brutos nunca são gravados nos audit logs. A opção “O endereço IP de onde a requisição partiu” descreve request.remote_address, um campo separado. A opção “A lista de nomes de policies anexadas ao token” descreve auth.policies, também um campo diferente. A opção hmac_accessor pode desativar esse hash, mas não é recomendada. Ref: developer.hashicorp.com/vault/docs/audit; /vault/docs/audit/schema

Quando o Vault encapsula uma resposta via wrap-ttl, ele armazena a resposta real dentro do cubbyhole de um wrapping token de uso único, em cubbyhole/response. Só quem detém esse token pode desencapsulá-la via /sys/wrapping/unwrap (Ref: developer.hashicorp.com/vault/docs/concepts/response-wrapping). O cubbyhole pertence exclusivamente ao wrapping token: nenhum outro token consegue acessá-lo, e os dados são destruídos quando o token expira ou é usado. A opção “Nos metadados da identity entity de quem fez a requisição, criptografados…” está errada: metadados de identity entity não são usados para armazenar respostas. A opção “No audit log, recuperável pelo caminho do audit device” está errada: audit logs guardam dados em hash para fins de conformidade, não secrets recuperáveis. A opção “No campo de metadados do wrapping token, acessível…” está errada: campos de metadados de um token são rótulos visíveis ao cliente, não armazenamento de secrets.