HashiCorp Vault Operations Advanced — Übungsfragen und Probeprüfung

Vault-Audit-Devices hashen sensible String-Werte vor dem Schreiben der Log-Einträge mit einem pro Device gesalzenen HMAC-SHA256. Das Feld auth.accessor enthält deshalb den HMAC des Token-Accessors und nicht den rohen Accessor. Über den Endpoint /sys/audit-hash kannst du einen bekannten Accessor seiner gehashten Form zuordnen. Die Option „Das Klartext-Token, mit dem die Anfrage authentifiziert wurde“ ist falsch – rohe Tokens werden nie in Audit-Logs geschrieben. Die Option „Die IP-Adresse, von der die Anfrage ausging“ beschreibt request.remote_address, ein eigenes Feld. Die Option „Die Liste der Policy-Namen, die dem Token zugeordnet sind“ beschreibt auth.policies, ebenfalls ein anderes Feld. Die Option hmac_accessor kann dieses Hashing deaktivieren, ist aber nicht empfohlen. Ref: developer.hashicorp.com/vault/docs/audit; /vault/docs/audit/schema

Wenn Vault eine Antwort über wrap-ttl wrappt, legt es die eigentliche Antwort im Cubbyhole eines Wrapping-Tokens zur einmaligen Verwendung unter cubbyhole/response ab. Nur wer dieses Token besitzt, kann sie über /sys/wrapping/unwrap entpacken (Ref: developer.hashicorp.com/vault/docs/concepts/response-wrapping). Das Cubbyhole gehört ausschließlich zum Wrapping-Token – kein anderes Token kann darauf zugreifen, und die Daten werden zerstört, sobald das Token abläuft oder verwendet wird. Die Option „In den Metadaten der Identity Entity des Anfragenden, verschlüsselt…“ ist falsch: Metadaten von Identity Entities werden nicht zum Speichern von Antworten genutzt. Die Option „Im Audit-Log, abrufbar über den Pfad des Audit-Devices“ ist falsch: Audit-Logs speichern gehashte Daten zu Compliance-Zwecken, keine abrufbaren Secrets. Die Option „Im Metadaten-Feld des Wrapping-Tokens, zugänglich…“ ist falsch: Metadatenfelder eines Tokens sind für Clients sichtbare Labels, kein Secret-Speicher.