HashiCorp Vault Operations Advanced — Questions d'entraînement et examen blanc

Les audit devices de Vault hachent les valeurs textuelles sensibles avec un HMAC-SHA256 salé propre à chaque device avant d'écrire les entrées du log. Le champ auth.accessor contient donc le HMAC de l'accessor du token, et non l'accessor brut. Tu peux relier un accessor connu à sa forme hachée via l'endpoint /sys/audit-hash. L'option « Le token en clair qui a authentifié la requête » est incorrecte : les tokens bruts ne sont jamais écrits dans les audit logs. L'option « L'adresse IP d'où provenait la requête » décrit request.remote_address, un champ distinct. L'option « La liste des noms de policies attachées au token » décrit auth.policies, également un autre champ. L'option hmac_accessor permet de désactiver ce hachage, mais ce n'est pas recommandé. Ref: developer.hashicorp.com/vault/docs/audit; /vault/docs/audit/schema

Quand Vault encapsule une réponse via wrap-ttl, il stocke la réponse réelle dans le cubbyhole d'un wrapping token à usage unique, sous cubbyhole/response. Seul le détenteur de ce token peut la déballer via /sys/wrapping/unwrap (Ref: developer.hashicorp.com/vault/docs/concepts/response-wrapping). Le cubbyhole est rattaché exclusivement au wrapping token : aucun autre token ne peut y accéder, et les données sont détruites lorsque le token expire ou est utilisé. L'option « Dans les métadonnées de l'identity entity du demandeur, chiffrées… » est fausse : les métadonnées d'une identity entity ne servent pas à stocker des réponses. L'option « Dans l'audit log, récupérable via le chemin de l'audit device » est fausse : les audit logs conservent des données hachées à des fins de conformité, pas des secrets récupérables. L'option « Dans le champ de métadonnées du wrapping token, accessible… » est fausse : les champs de métadonnées d'un token sont des libellés visibles par le client, pas un stockage de secrets.