1: Accounts and Security

Learning Objectives

By the end of this chapter, you will be able to:

• Decide between single-account and multi-account Snowflake topologies based on blast radius, data residency, edition gating, and regulatory boundaries.
• Design account hierarchies under an Organization, including failover groups, replication groups, and listing relationships across cloud providers and regions.
• Define a database and schema layout that maps to business functions, classification tiers, and access patterns without re-creating object hierarchies on every environment change.
• Build authentication and identity strategies that combine SAML SSO, SCIM provisioning, OAuth, key-pair authentication, and MFA with role-aware policies.
• Design network controls using network policies, network rules, private connectivity, and external access integrations.
• Select the appropriate Snowflake edition (Standard, Enterprise, Business Critical, VPS) based on the documented feature gates.
• Apply the principles of least privilege and separation of duties to a functional-plus-access role hierarchy.
• Diagnose and close security gaps that span data ingestion, storage, processing, and sharing.

Executive Summary

• Account topology is the single architectural decision that constrains every downstream control: blast radius, RBAC scope, replication granularity, edition-feature availability, and even cost attribution all derive from how many accounts the organization runs and where they live.
• The Organization construct unifies multiple accounts under a single billing and admin umbrella, exposes failover groups for disaster recovery, and is the only place where cross-account Listings, replication groups, and account-level usage roll up.
• Edition gating is not optional reading: Tri-Secret Secure, Private Link, Failover Groups, PHI/HIPAA support, and several Time Travel features are Business Critical or VPS only. An architect who designs at the Standard tier and then promises Private Link has shipped an unworkable plan.
• The governance fabric is layered: authentication (SAML/OAuth/key-pair/MFA), then network controls (network policies, network rules, private connectivity), then RBAC for object access, then ABAC via object tags for policy attachment at scale, then masking and row-access policies for fine-grained data protection, then audit views for verification.

Assumptions

• The reader has Snowflake practitioner experience and does not need explanations of databases, schemas, warehouses, or basic GRANT syntax. Foundational concepts are referenced by name only.
• Region and cloud-provider names follow Snowflake's published identifiers (for example AWS_US_WEST_2, AZURE_WESTEUROPE, GCP_US_CENTRAL1). Naming conventions for organisations, accounts, databases, and roles use the fictional company acme throughout.
• All numeric limits, edition gates, and feature names are drawn from the official Snowflake documentation linked from the certification page. Where the documentation publishes a tier-dependent value, this chapter calls out the tier explicitly.
• Snowflake's RBAC model is the only access-control surface considered. Cloud-provider IAM (AWS, Azure, GCP) appears solely where it interfaces with Snowflake storage integrations or external access integrations.