Least Privilege and Nested Groups in a Finance Safe
A shared services company runs a 40-person Finance Application Support team plus 12 offshore contractors. The existing safe FIN-APP-PRD holds 80 production database and application accounts and has 150 direct members; everyone has Retrieve accounts and Use accounts. An internal audit found three leavers with active Vault users, a nested Domain Admins group with full safe ownership, and contractors downloading passwords for 14 accounts in the last quarter. The CISO wants least privilege without stopping 24x7 incident response. The platform team proposes creating a new safe and moving all accounts. The application owner insists that contractors need to connect to production but must never see passwords. The service desk needs to list accounts but not use them.
1. Design the safe member matrix for employees, contractors, on-call, and service desk. Specify exact safe permissions and explain the separation of duties.
Read the worked answer
Use Vault groups, not direct user membership. Service desk: List accounts only, so they can identify an account without seeing or using it. Contractors: List accounts and Use accounts, with connection through PSM; no Retrieve accounts, no Update account content, no Delete accounts. Employees: List accounts, Use accounts, and Retrieve accounts only for a named break-glass subgroup; routine support should not retrieve. On-call: Use accounts, Create access request, and membership in an approver group, but not Access without confirmation by default. Safe owner: View safe members and Manage safe members, but not Retrieve accounts, to keep administration separate from secret access. The separation matters because Use accounts permits a PSM connection without disclosure, while Retrieve accounts exposes the password and defeats session recording. Contractors with Use accounts still get accountability through PSM, which is the control the application owner wants.
2. The nested Domain Admins group currently has Manage Safe Members. What is your remediation and how do you prevent access outages?
Read the worked answer
First export the current safe members and compare them with HR and the identity provider. Remove direct leavers after disabling their Vault users, but do not delete the audit trail. For Domain Admins, remove the group from the safe and replace it with a dedicated owner group whose membership is reviewed monthly; nested groups are a hidden path because membership changes outside the safe are easy to miss. Stage the change: create new groups, assign them, test with a pilot user, then remove old members. Keep one break-glass owner group with dual control and alerting. Before removing anyone, run an access report and notify the application owner; after the change, verify that 24x7 support can still connect through PSM, even if they cannot retrieve. This avoids an outage while closing the audit finding.
3. When would you enable dual control versus access request? What settings and approval workflow would you configure?
Read the worked answer
Use dual control for high-risk retrieval, such as production database passwords, where two authorized people must confirm before the secret is shown. Use access request for time-bound, reason-based access, especially contractor or on-call connections, with an approver and automatic expiry. In the safe, enable dual control and require confirmation for Retrieve accounts; enable access request and name approvers; do not grant Access without confirmation broadly. Combine them for break-glass: request, approve, and still require a second confirmer. The test is whether the control creates evidence: dual control proves two people were involved, while access request proves why and for how long. Neither replaces session recording.