Skip to main content

Understanding Snowflake’s Newer Network Security Model: Network Rules & Policies Explained

Snowflake customers previously relied Network Policies to control access based on IP addresses. However, starting in 2024, Snowflake introduced Network Rules, a new approach to defining and managing network security. This shift brings greater flexibility, reusability, and improved security management.

In this guide, we’ll break down the differences between the old and new approach, explain how network rules work, and provide a step-by-step guide on implementing the new security model in your Snowflake environment.

The Old Way: Network Policies in Snowflake (Before 2024)

Before Snowflake introduced Network Rules, security access based on IPs was controlled through Network Policies, which directly contained allowed or blocked IP lists. I point this out because a lot of knowledge articles and even AI tools you use may be out dated.

  • Admins would create a Network Policy using an ALLOWED_IP_LIST or BLOCKED_IP_LIST.
  • The policy would then be applied to an account or specific users.
  • Every change required editing the policy manually, making updates cumbersome if multiple environments required different access rules.

Limitations of the Old Model:

  1. No Reusability: Each policy was a static list of IPs, requiring duplicate entries across multiple policies.
  2. Difficult to Manage at Scale: Updating policies meant modifying each policy separately.
  3. No Separation of Concerns: Network security was tied directly to policies, with no modular approach

The New Approach: Network Rules + Policies (2024 and Beyond)

To solve these challenges, Snowflake introduced Network Rules, which act as building blocks for Network Policies.

How It Works Now:

  • Network Rules define individual sets of allowed or blocked IPs.
  • Network Policies reference these rules instead of directly storing IP lists.
  • The policy is applied at the account, user, or security integration level.
  • Changes to a network rule automatically update all policies using it.

We will break down the nuances of each in this step by step tutorial:

Step 1: Create a Dedicated Security Schema

CREATE DATABASE IF NOT EXISTS SECURITY_DB;
CREATE SCHEMA IF NOT EXISTS SECURITY_DB.SECURITY_SCHEMA;
USE DATABASE SECURITY_DB;
USE SCHEMA SECURITY_SCHEMA;

Why Use a Dedicated Security Schema?

  1. Network Rules Must Be Created in a Schema
    • Since network rules are schema-level objects, they must be stored somewhere.
    • Placing them in a dedicated SECURITY_DB.SECURITY_SCHEMA keeps them isolated from application data.
  2. Separation of Duties & Access Control
    • You can restrict access to the schema to security admins only.
    • This prevents accidental changes by developers or analysts.
  3. Consistency & Maintainability
    • Centralizing network rules in one schema avoids scattering security objects across multiple schemas.
    • It simplifies maintenance when updating or auditing security settings.
  4. Alignment with Snowflake’s Best Practices
    • Snowflake recommends storing security-related objects (like masking policies, row access policies, and network rules) in dedicated security schemas.
    • While not explicitly required for network rules, this approach follows similar principles outlined in Snowflake’s security documentation.

Step 2: Define a Network Rule

A Network Rule specifies the IPs that should be allowed or blocked.

  • Corporate Network: If you’re within a corporate network, ensure that all relevant office IP addresses are included in the allow list.
  • VPN Network: If you’re within a VPN and users need to access Snowflake you will need to whitelist the IP subnets that your VPN provider uses for your business.
CREATE NETWORK RULE SECURITY_SCHEMA.yourcompanyname_allowed_ips
    TYPE = IPV4
    VALUE_LIST = ('192.0.0.1/24', 184.0.23.212)
    MODE = INGRESS
    COMMENT = 'Allow access from specified IPs and subnets';

You can review your rules in 2 ways:

    SHOW NETWORK RULES IN SCHEMA SECURITY_DB.SECURITY_SCHEMA;

Step 3: Create your network Policy policy

I find the Snowflake UI much faster and easier to create and enable a network policy than code, so for this article I provide the UI approach becuase it only involves a fe clicks.

Simply select your rules, then click “Create Network Policy”

As a trick if you really want to see the code that executed in the UX, you can go to Monitoring>Query History and then find the action:

CREATE 
        NETWORK POLICY IDENTIFIER('"YOURCOMPANYNAME_POLICY"')
        ALLOWED_NETWORK_RULE_LIST = ('"SECURITY_DB"."SECURITY_SCHEMA"."YOURCOMPANYNAME_ALLOWED_IPS"')
        BLOCKED_NETWORK_RULE_LIST = ()
        ALLOWED_IP_LIST = ()
        BLOCKED_IP_LIST = ()
        COMMENT = ?;

Step 4: Apply the Policy at the Account Level

Since you want the policy to be effective for the entire Snowflake account, apply it globally:

🚀 Summary:

  • Network rule is created to store allowed (or restricted) IPs.
  • Network policy is created to reference the rule(s).
  • Network policy is applied at the account level, ensuring it restricts access to all Snowflake objects
  • You can only enable 1 Network Policy at a time