Administrator roles on cloud data warehouses and lakehouses sit above every dataset the business has consolidated, yet they are usually granted by the platform team that set the account up and rarely governed with the rigour applied to domain admins. Each platform has its own top-level roles, its own control plane and its own way of hiding standing admin rights inside groups and cloud IAM. Organisations running more than one platform end up with several unrelated admin populations and no single view of who can change access to everything. This guide sets out a common governance model for data platform administrator access: a tier model that maps each platform's roles, how many holders to allow, how to elevate, how to keep automation out of admin roles and how to review it all in one place. It is for data platform owners, IAM teams and security architects. Platform-specific hardening lives in each platform's own guide, linked below.
Platforms are listed alphabetically: Amazon Redshift, Databricks, Google BigQuery and Snowflake. The order is not a ranking, and each platform's current role names and behaviour should be confirmed in its own documentation.
Key takeaways
- Map roles to tiers, not names. Every platform has an account-level tier, a security or identity-admin tier and a data-admin tier; govern the tiers consistently even though role names differ.
- Keep the top tier small and personal. Two to four named humans per platform account (our recommendation), phishing-resistant MFA, no default use and no automation.
- Treat identity admins as top tier. Any role that can create users or grant roles can grant itself the top tier, so it is governed the same way.
- Look at the cloud control plane too. Cloud IAM roles that can create, modify or reset a platform's administrative principals are an indirect admin path.
- Run production through service identities. When jobs and pipelines run as service principals with scoped rights, humans need no standing write or admin access in production.
Why data platforms need their own admin model
Three things make data platform admin access different from database admin access on a single engine (covered in DBA Privileged Access):
- Concentration: a warehouse or lakehouse account often holds copies of data from dozens of source systems, so one admin role reaches far more than any one source database.
- Two control planes: access is set both inside the platform (roles, grants, workspace and metastore admins) and in the cloud provider or organisation account that hosts it (cloud IAM, billing and network). Each can affect the other.
- Admin roles are not always superusers: some top-level roles see only objects their role hierarchy has been granted, while others bypass all checks. Reviewers must understand what each role actually reaches before certifying it.
A common tier model
Map each platform's roles to four tiers so that one policy, one review and one set of metrics can apply across platforms. The mapping below is our interpretation of each vendor's documentation as of November 2026.
| Tier | Meaning | Amazon Redshift | Databricks | Google BigQuery | Snowflake |
|---|---|---|---|---|---|
| T0 Account | Controls the whole account, its settings and every other admin | Superusers, including the admin user created at cluster launch; sys:superuser role | Account admins | roles/bigquery.admin at project level, plus project or organisation roles that can change IAM policy | ACCOUNTADMIN |
| T1 Security and identity | Creates users and roles, grants access, manages policies | sys:secadmin (users, roles, grants, row-level security and masking policies) | Workspace admins; group managers and service principal managers for their scope | Principals that can set IAM policy on projects or datasets; roles/bigquery.dataOwner on datasets | SECURITYADMIN (MANAGE GRANTS) and USERADMIN |
| T2 Data and platform admin | Creates and drops schemas, tables and compute | sys:dba (schemas, tables, procedures, views) | Catalog and schema owners in Unity Catalog; workspace compute policy owners | roles/bigquery.dataEditor on datasets | SYSADMIN and custom roles beneath it |
| T3 Operations and monitoring | Runs maintenance, reads system views, cancels queries | sys:operator, sys:monitor | Users with CAN MANAGE on specific jobs or clusters | roles/bigquery.jobUser plus read roles on admin views | Custom monitoring roles with MONITOR privileges |
Each vendor documents what its top role reaches, and reviewers should read that before certifying it. Amazon Redshift documents that a superuser keeps all permissions regardless of GRANT and REVOKE. Databricks documents that account admins add, update and delete users, service principals and groups and assign admin roles. Google documents that BigQuery Admin can manage all resources and data in the project. Snowflake documents that ACCOUNTADMIN views or manages objects where it, or a role below it, holds the privileges. Each belongs in T0 because each can change who has access to everything else.
Platform notes
Amazon Redshift
The admin user created when a cluster is launched is a superuser. AWS recommends doing most work as a non-superuser and using role-based access control for narrower administrator roles. Redshift provides five system-defined roles with the sys: prefix: sys:monitor, sys:operator, sys:dba, sys:superuser and sys:secadmin. Assign named administrators sys:dba or sys:secadmin for routine work, keep the launch admin user as an emergency credential, and treat AWS IAM permissions that can change cluster configuration or the admin credential as T0. See the Amazon Redshift Security Guide.
Databricks
Account admins add, update and delete users, service principals and groups in the account, assign admin roles and grant workspace access. Workspace admins grant access to their workspaces and can add users and service principals to the account. Databricks recommends a limited number of account admins per account and workspace admins per workspace. Databricks also recommends running production jobs and production data changes with service principals, so interactive users need no write, delete or modify privileges in production, and syncing identities from the identity provider at account level. See the Databricks Security Guide.
Google BigQuery
BigQuery Admin (roles/bigquery.admin) manages all resources in the project, including all data, and can cancel other users' jobs; Google describes it as typically granted at project level. Data Owner grants all permissions on a dataset and its contents, and Data Editor covers creating, updating and deleting tables and views and changing data. Because BigQuery access is Google Cloud IAM, the admin population also includes anyone who can change IAM policy on the project, folder or organisation. Google notes it may add permissions to predefined roles over time and suggests custom roles where definitions must stay fixed. See the BigQuery Security Guide.
Snowflake
Snowflake advises assigning ACCOUNTADMIN to a limited number of people, and to at least two users so one can reset the other's password; requiring MFA for every ACCOUNTADMIN user; never making it a default role; not using it to create objects or run scripts; and using SYSADMIN or lower roles for warehouses and database objects, with SECURITYADMIN or USERADMIN for users and roles. Snowflake also suggests keeping current employee email addresses on ACCOUNTADMIN users so support can reach the right people. Direct grants to users can be listed from SNOWFLAKE.ACCOUNT_USAGE.GRANTS_TO_ROLES where granted_to is USER. See the Snowflake Security Guide.
Controls for each tier
| Control | T0 Account | T1 Security and identity | T2 Data and platform admin |
|---|---|---|---|
| Holders (our recommendation) | 2 to 4 named humans per account; one emergency credential | Small named group, often the IAM team | Platform engineering group |
| Assignment | Direct to named people, recorded | Through a directory group synced to the platform | Through directory groups |
| Authentication | SSO plus phishing-resistant MFA; emergency credential in a vault with split custody | SSO plus MFA | SSO plus MFA |
| Use | Not a default role or default session; elevate per task through PAM or the platform's role switch | Just in time where the platform or PAM supports it | Standing allowed, scoped to domains |
| Automation | Never | Only a dedicated provisioning identity (for example the SCIM connector) | Service principals per pipeline with scoped grants |
| Review | Monthly | Quarterly | Quarterly or with data owner certification |
| Alerting | Every session and every grant of the role | Every grant of T0 or T1 | Grants outside the owning domain |
The cloud control plane path
A platform admin model is incomplete if the cloud account around it is ignored. Cloud principals that can do any of the following hold indirect T0 access and belong in the same review:
- Reset or replace platform admin credentials: for example permissions to modify a cluster's admin credentials or to re-run account setup.
- Change IAM policy on the project, folder, subscription or account that hosts the platform.
- Change identity federation or SCIM configuration, which can add a new admin from outside the platform.
- Reach the storage underneath: object storage buckets holding lakehouse tables or external stages can bypass in-platform grants if storage permissions are wider than intended. See the Data Lake Security Guide.
Platform-issued tokens and keys held by admins are a further path; see Database platform tokens for what to do if one leaks.
Keeping automation out of admin roles
Pipelines, orchestration tools, BI connectors and AI agents often end up with admin roles because they were set up by an administrator. Our recommended pattern:
- One service identity per workload: a Databricks service principal, a Snowflake service user, a Google Cloud service account or a Redshift user or role mapped to an IAM role, owned by a named team.
- Scoped grants: only the schemas, catalogs or datasets the workload touches, at T2 or below.
- No interactive login and credentials from workload identity federation or a vault, never a personal access token belonging to an admin.
- Ownership transfer: objects created by automation owned by a role, not by the admin who first ran it.
See the Service Account Security Guide.
Implementing the model
- Discover: for each platform account, list holders of every T0 and T1 role, directly and through groups, plus cloud principals with control plane paths. Expect to find setup users, former contractors and automation in T0.
- Map: fill in the tier table for your actual roles, including custom roles that hold T0 or T1 privileges.
- Prepare emergency access first: create and test the emergency credential for each platform before removing anyone, so a mistake does not lock out the account. See the Break-Glass Account Guide.
- Move automation out: create service identities and switch workloads one at a time, watching job failures. Roll back by restoring the previous role grant for that workload only.
- Reduce humans: move routine admin work to T1 and T2 roles; remove standing T0 except for the agreed holders.
- Turn on alerting and review: stream platform audit logs to your SIEM and run the first combined review.
Size matters. A small team running one platform can combine T0 and T1 holders and review monthly. Larger organisations with several platforms should run one cross-platform review, owned by IAM, rather than leaving each platform team to certify itself.
Detection and measurement
Watch for: activation of any T0 role, grants of T0 or T1 roles, changes to SSO, SCIM or network policy, new service identities with admin roles, and admin sessions from unusual locations. Each platform writes these events to its own audit source (for example Snowflake ACCOUNT_USAGE views, Databricks audit logs, Google Cloud Audit Logs for BigQuery and Redshift system views and AWS CloudTrail).
| Metric | Target (our recommendation) |
|---|---|
| T0 holders per platform account | 2 to 4, all named humans |
| Service identities holding T0 or T1 roles | Zero, except the provisioning connector |
| T0 and T1 holders with phishing-resistant MFA | 100% |
| Cloud principals with control plane paths reviewed in the same cycle | 100% |
| T0 sessions with a matching ticket | 100% |
Framework mapping
| Framework | Reference | Application here |
|---|---|---|
| NIST SP 800-53 Rev. 5 | AC-6(5) Privileged Accounts; AC-6(7) Review of User Privileges; AC-6(9) Log Use of Privileged Functions; IA-2(1) Multi-factor Authentication to Privileged Accounts; AC-2 Account Management | Tier holders, MFA, review cadence, alerting |
| NIST CSF 2.0 | PR.AA-01; PR.AA-05; DE.CM-03 | Identity sync, least privilege, admin activity monitoring |
| MITRE ATT&CK | T1078.004 Cloud Accounts; T1098 Account Manipulation | Admin account abuse and role grants |
Common failure patterns
- Setup users never revisited: the engineer who created the account keeps the top role years later.
- Identity admins left out of scope: reviews cover ACCOUNTADMIN or account admins but not the roles that can grant them.
- Admin as default: top roles used for everyday queries, so every session runs at full privilege.
- Pipelines running as admins: scheduled jobs or BI connectors authenticate as an administrator's personal identity or token.
- Cloud IAM blind spot: project or account owners in the cloud console are never reviewed alongside the platform.
- Separate reviews per platform: no one sees that the same person holds T0 on every platform the company runs.
Practitioner checklist
- Every platform's roles are mapped to the four tiers, including custom roles.
- T0 holders are two to four named humans per account, each with phishing-resistant MFA.
- T1 identity and security admin roles are governed as strictly as T0.
- No user has a T0 role as a default role or default session.
- A tested emergency credential exists per platform, held in a vault with split custody.
- No pipeline, connector or agent holds a T0 or T1 role.
- Cloud principals that can change IAM, federation or admin credentials are in the same review.
- Platform audit logs feed the SIEM with alerts on T0 activation and T0 or T1 grants.
- One cross-platform admin review runs on a fixed cadence with an owner outside the platform teams.
Standards and references
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- AWS: Superusers (Amazon Redshift)
- AWS: Amazon Redshift system-defined roles
- Databricks: Manage users, service principals and groups
- Databricks: Identity best practices
- Google Cloud: BigQuery IAM roles and permissions
- Snowflake: Access control considerations
Related NHI Mgmt Group resources: DBA Privileged Access · Privileged Access Management Guide · Access Reviews Guide · Database Privileged Access Review Template · Data Lake Security Guide