RBAC for Shared NDB With Contractors and Cross-Project Cloning
A shared NDB deployment supports three teams: production DBAs, application developers, and analytics. All 45 users are currently members of the NDB Admin role because the platform was built quickly. Production contains 25 databases; development contains 60 clones. Developers need to clone production databases into the development project but must not delete or patch production. Analytics users need read-only visibility into their own databases and should not see production credentials. Ten contractors will join for six weeks and need to create clones for a specific application, but those clones must expire after seven days. An auditor finds that contractors can delete time machines and that developers have restored a production clone over a production database. The security team asks for a least-privilege redesign without breaking the daily clone workflow.
1. Design the project, role, and ownership model. Which privileges must be separated and why?
Read the worked answer
Separate projects first: production, development, analytics, and optionally a contractor area inside development. NDB projects should contain the databases and time machines each team is allowed to see. Users should be assigned to projects through directory groups where possible, not added individually.
Use built-in roles only where they match least privilege, and create narrower custom roles if the release supports them. Production DBAs get a project administrator or operator role scoped to production. Developers get a clone-only role on production time machines plus normal development privileges inside the development project. Analytics gets read-only access to analytics databases only. Contractors get clone-only access to the named application, no time-machine delete, no restore-over-production, and a seven-day clone expiration. Keep NDB server administration limited to a small platform team.
The critical separations are clone versus delete, restore versus overwrite, patch versus provision, time-machine access versus database access, and credential visibility versus metadata visibility. The incident happened because global admin collapsed those boundaries. Clone rights should not imply delete rights, and restore should land in a non-production project unless an approved production change explicitly allows otherwise.
2. How should existing global-admin users, existing clones, and contractor access be remediated? What audit evidence should be collected?
Read the worked answer
Inventory all 45 users and map each to a business role and project. Remove NDB Admin from everyone except a small break-glass group, then add users to directory-backed groups with project-scoped roles. Reassign ownership of the 60 development clones to the correct developers or service accounts, expire stale clones, and delete clones that no longer have an owner. Investigate the production overwrite, preserve logs, and confirm whether the production database needs restoration or reconciliation.
For contractors, create time-bound accounts, add them to a contractor group with clone-only rights, enforce a seven-day clone expiration, and remove access at the end of the engagement. Test the design with a developer account: it should be able to clone production into development but should fail when attempting to delete or patch production. Test a contractor account similarly, including the inability to delete a time machine.
Collect NDB audit logs, Prism audit logs, role-change history, clone and restore events, and database logs for the overwrite. Review the evidence weekly during the transition and retain it according to policy. The goal is not only fewer admin accounts but demonstrable separation between production control, clone creation, and read-only analytics access.