Least Privilege for a Third-Party Backup Vendor
A Prism Central instance manages three registered clusters for a hospital. Today all three clusters share the same 40 local user accounts and one AD group mapped to a cluster-wide Super Admin role. A contracted backup vendor needs to browse VM inventory, take and delete snapshots, and restore VMs, but only for the 25 VMs in the 'Records' project. The vendor must not see or touch the 120 VMs in the 'Research' project. The vendor's staff will log in with their own AD accounts from a dedicated AD group. Security has banned shared local accounts and requires per-person attribution, and the vendor contract ends in 90 days.
1. Design the access model. Name where each control is enforced, and explain why the role must be scoped at project level rather than cluster level.
Read the worked answer
Layers of the design:
- Categories as the scoping primitive. Tag the 25 Records VMs with a category (e.g. Project = Records). Categories, not VM names, are what survive VM rebuilds, clones and restores - a name-based rule breaks the first time a VM is restored with a suffix.
- A Prism Central project bound to that category. The project is the boundary that makes 'only Records' enforceable rather than advisory.
- A custom role - not a built-in one - containing only: VM view/read, snapshot create, snapshot delete, and the restore operations required. Super Admin, Cluster Admin and anything carrying storage, networking, cluster-config or user-management rights are excluded by construction.
- Assignment: the vendor's AD group mapped to that custom role at the project scope, with the vendor's engineers using individual AD accounts so every action is attributable.
Why project-level, not cluster-level:
- Cluster-level roles grant visibility and control across every VM on that cluster, including all 120 Research VMs. There is no way to carve out 'not these' from a cluster-wide role.
- The three clusters have different data sensitivity; one cluster-wide grant to a contractor applies to all of them.
- Project scope also limits blast radius: a mistaken snapshot deletion affects the Records boundary, not the whole estate.
Also address Prism Element: the vendor can still authenticate directly to a cluster if their AD group retains a PE role. Remove that mapping and restrict direct PE access to internal administrators, so Prism Central is the only path.
2. Beyond least privilege, what is wrong with the current model, and what is the operational exposure at the end of the 90-day contract?
Read the worked answer
Current-state problems:
- No attribution. 40 shared local accounts mean audit logs show 'admin', not a person. Any investigation into who deleted a snapshot dead-ends immediately.
- Offboarding debt. Shared accounts cannot be revoked per person; a departing contractor leaves working credentials behind, and nobody can prove otherwise.
- Excessive privilege with cluster-wide blast radius. Super Admin can alter protection domains, delete storage, change networking, and create more Super Admins. A backup vendor has none of those requirements.
- Ungoverned AD mapping. One AD group mapped cluster-wide across three clusters means group membership changes silently grant cluster-wide rights, and nobody reviews it.
The 90-day exposure:
- If the group mapping is not removed on the end date, the vendor keeps working credentials indefinitely, and contract expiry is not an account control.
- Shared local accounts created for the vendor may persist long after the AD group is removed, because they were never tied to the contract.
What to put in place now: an explicit disable date on the AD group mapping, a documented owner, a review before expiry, and an audit-log check after disablement confirming no vendor-authenticated activity. Tie deprovisioning to the contract record, not to someone's memory.
3. How do you verify the design works before go-live and after, and what would you check in the audit trail?
Read the worked answer
Positive and negative testing with a real AD test account in the vendor group:
- Log in to Prism Central as the test vendor account. Confirm the VM list shows the 25 Records VMs and does not show the 120 Research VMs. Visibility is the first test - if they can see it, the model has already failed.
- Take a snapshot of a Records VM - expect success. Delete a snapshot of a Records VM - expect success (it is in scope).
- Attempt the same actions against a Research VM, and attempt an action outside the role (e.g. storage or user management). Expect a hard denial, not a silent no-op. Record the exact error.
- Attempt a direct Prism Element login with the vendor account. Expect denial - this is the check most often skipped, and it is the one that matters most.
Audit review:
- Confirm each Prism Central audit entry names the individual AD account, not a shared login.
- Confirm the denied attempts in step 3 appear in the log as denials - a missing entry can mean the request never reached the policy, which is a different problem.
- After the contract ends, re-check the audit log for any vendor-authenticated activity: absence of entries is the evidence that deprovisioning worked.
Ongoing: an alert on role and project membership changes, so a future grant to the vendor group is noticed rather than discovered a year later.