Authentication, roles, and the privilege model that locks an account down

Snowflake's security model is built on network security, authentication, authorization via role-based access control (RBAC), and object-level ownership, all enforced through hierarchical containers (organization, account, database, schema). Access to data is never granted directly to users—only to roles, which are then assigned to users, enabling scalable and auditable permission management. Governance features like Dynamic Data Masking, Row Access Policies, Object Tagging, and the Access History in ACCOUNT_USAGE support compliance and data protection at scale.

1 · Learn the must-know

• 1Every securable object in Snowflake has exactly one owner role, and that role initially has full privileges on the object (OWNERSHIP privilege).
• 2Snowflake uses RBAC (not user-based grants); privileges are granted to roles, and roles are granted to users or to other roles, forming a role hierarchy.
• 3System-defined roles (ORGADMIN, ACCOUNTADMIN, SECURITYADMIN, USERADMIN, SYSADMIN, PUBLIC) each have specific scopes—e.g., SECURITYADMIN manages grants and security integrations, USERADMIN manages users and roles, and PUBLIC is automatically granted to every user and role.
• 4ACCOUNTADMIN combines SECURITYADMIN and SYSADMIN and should be assigned to very few users, with MFA strongly recommended/enforced for it.
• 5Snowflake supports network policies (IP allow/block lists), federated authentication/SSO, MFA (via Duo), key pair authentication, and OAuth for authentication, layered on top of RBAC for defense in depth.
• 6Column-level security (Dynamic Data Masking) and row-level security (Row Access Policies) are implemented as policy objects attached to columns/tables, allowing centralized, reusable governance rules enforced regardless of how data is queried.

2 · Check your understanding