Snowflake Encryption, Network Policies, Network Rules and Private Connectivity

1.Encryption: the baseline every account gets, and the extra layer some need

Every other security control in this lesson sits on top of encryption. Snowflake uses end-to-end encryption (E2EE), which stops third parties from reading customer data while it is at rest or moving to and from Snowflake. The E2EE design covers two kinds of stage. Internal stages are provided by Snowflake. External stages are containers in a cloud storage service, such as Amazon S3, that the customer controls. When a user uploads files to an external stage, the user may also encrypt them with client-side encryption before they leave the corporate network.

Some regulated customers need more control over keys. For them, Snowflake offers Tri-Secret Secure. This dual-key model combines a key maintained by Snowflake with a customer-managed key (CMK) that the customer creates on the cloud platform hosting the account. Together they form a composite master key, which wraps the account's key hierarchy. For example, it wraps table master keys, and those are used to derive the file keys that encrypt raw data. The composite key itself never encrypts raw data. Owning the CMK brings responsibility: if the customer revokes it, Snowflake can no longer decrypt the data. So choose Tri-Secret Secure when a requirement says the customer must control a key. Don't choose it as a default upgrade.

Sources12

2.Network rules: grouping identifiers by type and mode

Encryption protects the data itself. Network controls decide who can reach Snowflake at all, and where Snowflake code can send data. Both directions use network rules. A rule holds identifiers of a single TYPE: IPv4 ranges in CIDR notation, IPv6 ranges (AWS only), AWS VPCE IDs, Azure LinkIDs, Google Cloud PSC connection IDs, Snowpark Container Services compute pools for inbound traffic, or domains with ports for outbound traffic. The rule's MODE says which direction of traffic the feature using it will restrict.

To create a rule, you need the CREATE NETWORK RULE privilege on its schema. By default, only ACCOUNTADMIN, SECURITYADMIN and the schema owner hold that privilege, so a custom network-admin role must be granted it explicitly. Snowflake recommends many small rules with clear purposes. For example, keep one rule for North American client IPs and another for privileged and service users. Use the COMMENT property to record what each rule is for.

Sources3

3.Network policies: allowed lists, blocked lists and precedence

By default, anyone can connect from any device. A network policy changes that by adding network rules to an allowed list and a blocked list. The workflow has three steps, and a policy does nothing until the last one: you activate it on an account, a user or a security integration. New policies should use network rules. The older ALLOWED_IP_LIST and BLOCKED_IP_LIST parameters still work, but you should not mix the two styles in one policy.

Three evaluation rules come up again and again. First, an allowed list implicitly blocks: if you allow one IPv4 address, every other IPv4 address is blocked, with no blocked-list entry needed. Second, when the same value appears in both lists, the blocked list is applied first. You can use this to allow a range except for one address. Third, the most specific policy wins. An account policy is overridden by a user policy, and a user policy is overridden by a security-integration policy. One exception: for Snowflake OAuth, the user-level policy is ignored on token requests. The only integration that still enforces it there is the built-in SNOWFLAKE$LOCAL_APPLICATION. Snowflake recommends scoping policies to groups of users or to integrations instead of the whole account.

CREATE NETWORK RULE allow_access_rule
  MODE =  ? 
  TYPE = IPV4
  VALUE_LIST = ('192.168.1.0/24');

Sources4

4.Private connectivity: PrivateLink, Private Link and Private Service Connect

Traffic to Snowflake can travel over the public internet or through a private IP address on the cloud platform that hosts the account. Which service you use depends on that platform: AWS PrivateLink, Azure Private Link or Google Cloud Private Service Connect. With private endpoints, inbound traffic can stay private for the Snowflake service, Snowsight, Streamlit in Snowflake, internal stages, Snowflake-managed storage volumes and Snowpark Container Services.

CREATE NETWORK RULE block_public_access
  MODE = INGRESS
  TYPE = IPV4
  VALUE_LIST = ('0.0.0.0/0');

CREATE NETWORK RULE allow_vpceid_access
  MODE = INGRESS
  TYPE = AWSVPCEID
  VALUE_LIST = ('vpce-0fa383eb170331202');

CREATE NETWORK POLICY allow_vpceid_block_public_policy
  ALLOWED_NETWORK_RULE_LIST = ('allow_vpceid_access')
  BLOCKED_NETWORK_RULE_LIST=('block_public_access');

When a private request matches an allowed AWSVPCEID or AZURELINKID rule, Snowflake ignores all IPv4 and IPv6 rules for that request. On Azure, the function SYSTEM$GET_PRIVATELINK_AUTHORIZED_ENDPOINTS returns the account's LinkID. Sometimes several VPCs, business units or overlapping subnets share one endpoint. In that case, tuple syntax pairs the endpoint ID with IP ranges, so Snowflake judges the pair and not the IP alone. Note one platform gap: on Azure, a network rule cannot restrict an internal stage, but Azure Private Link can block all public access to it.

Sources5

5.External access: controlling outbound traffic

Network policies only protect inbound traffic. To let a UDF or procedure call an external API, you need external network access. You create EGRESS network rules that list allowed domains. If no port is given, it defaults to 443, and port 0 means all ports. You then list those rules in an external access integration, which can also name the secrets and API authentication security integrations the handler is allowed to use.

CREATE [ OR REPLACE ] EXTERNAL ACCESS INTEGRATION <name>
  ALLOWED_NETWORK_RULES = ( <rule_name_1> [, <rule_name_2>, ... ] )
  [ ALLOWED_API_AUTHENTICATION_INTEGRATIONS = { ( <integration_name_1> [, <integration_name_2>, ... ] ) | none } ]
  [ ALLOWED_AUTHENTICATION_SECRETS = { ( <secret_name_1> [, <secret_name_2>, ... ] ) | all | none } ]
  ENABLED = { TRUE | FALSE }
  [ COMMENT = '<string_literal>' ]

Setting ENABLED = FALSE works as a kill switch. Any handler code that relies on a disabled integration can no longer reach the external location.

Sources36

Exam traps

Each one states something that sounds right. Open it to see what is actually true.

1. 1.Allowing a VPCE ID or Azure LinkID in a network policy automatically blocks public internet access.Why is that wrong?

   Private-endpoint rules do not apply to public requests. You must also add an IPv4 rule such as 0.0.0.0/0 to the blocked list.

   Covered in Private connectivity: PrivateLink, Private Link and Private Service Connect

2. 2.A user-level network policy always overrides every other policy that applies to that user.Why is that wrong?

   A policy activated on a security integration is the most specific, so it overrides both user and account policies.

   Covered in Network policies: allowed lists, blocked lists and precedence