Snowflake Security Isn’t About Who It’s About Where Access Comes From

Introduction

If someone steals your Snowflake credentials today… could they log in from anywhere in the world?

If the answer is yes, your security model is already broken.

Most teams focus heavily on identity: passwords, Single Sign-On (SSO), Multi-Factor Authentication (MFA).

That protects who connects.

But it doesn’t control where connections come from.

And in modern data platforms, that’s where things fail.

In practice, breaches rarely happen because authentication is missing. They happen because access is too permissive.

A valid user, valid credentials… From the wrong place.

This is where Snowflake network policies become critical.

They act as a non-negotiable layer of control, enforcing where connections are allowed from, regardless of who is trying to log in.

Even with valid credentials, access can be instantly denied.

To make this concrete, let’s look at Atlas Data Group, a company running sensitive data on Snowflake.

Their goal is simple: allow trusted access, block everything else.

We’ll see how they use network policies to secure both users and automated workloads.

Understanding the Fundamentals of Network Policies

Before securing different types of users, we need to understand the core mechanism.

A Snowflake network policy acts like a bouncer for your data platform.

Credentials get you to the door.

The network policy decides if you’re even allowed in.

It relies on two simple rules:

• Allowlist → IPs that are allowed to attempt a login
• Blocklist → IPs that are denied immediately, no matter what

And here’s the rule most people overlook: The blocklist always wins.

Even if an IP is part of an allowed range, a single explicit deny overrides everything.

Identifying Where the Connection Comes From

Every connection to Snowflake starts with one simple check: Where is this request coming from?

Snowflake evaluates the public IPv4 address of the client before anything else.

Instead of managing individual IPs one by one, it supports CIDR notation, allowing you to define entire ranges in a single rule.

This is what makes network policies scalable.

You don’t secure users individually you secure environments:

• corporate offices
• VPN networks
• cloud infrastructures

Let’s make this concrete.

Youssef defines a baseline policy for the Casablanca office:

CREATE NETWORK POLICY casablanca_office_policy
  ALLOWED_IP_LIST = ('192.168.1.0/24')
  BLOCKED_IP_LIST = ('192.168.1.50/32');

This does two things:

• Allows the entire office network
• Explicitly blocks a known compromised machine

Snowflake resolves conflicts between rules with a simple principle: the blocklist always takes precedence over the allowlist. This means that even if an IP address belongs to an allowed range, it will still be denied access if it appears in the blocklist.

The Hierarchy of Evaluation

Not all network policies are equal. When multiple policies exist, Snowflake does not combine them

It applies only one, based on priority. The more specific the policy, the higher its priority.

There are three levels of evaluation:

• User Level (most specific) Applies to a single user If a policy is defined here, it overrides everything else
• Integration Level Applies to specific tools or services (BI tools, pipelines) It overrides the account-level policy, but not a user-level policy
• Account Level (least specific) The default rule for everyone It acts as a global baseline when no more specific policy exists

The key rule is simple: the most specific policy always wins

At Atlas Data Group, Youssef uses this to structure access:

• A strict account-level policy as a secure baseline
• More flexible user or integration policies for exceptions

This avoids a common mistake:

• Trying to make one global policy fit every use case
• Instead, define a baseline and handle exceptions explicitly

Securing Access for Human Users

Once the foundations are clear, the next step is securing real users.

• Analysts, engineers
• Administrators
• the people accessing Snowflake every day

Most teams focus on simplifying access, fewer credentials, easier login, SSO everywhere

That improves usability, but it does not reduce exposure.

At Atlas Data Group, Youssef takes a different approach

Access should be simple but never unrestricted.

Establishing the Account-Level Baseline

Every secure system starts with a strong default, not a flexible one a restrictive one.

Youssef defines a global rule:

• Access is allowed only from trusted environments
• Everything else is blocked by default

Concretely, this means:

• Users must be connected to the corporate VPN
• Or physically inside the Casablanca office

ALTER ACCOUNT SET NETWORK_POLICY = casablanca_office_policy;

By setting this baseline, Youssef immediately blocks 99% of internet traffic from even seeing the Snowflake login screen.

This single decision changes everything. Instead of exposing Snowflake to the internet it becomes accessible only from controlled entry points.

In practice, this blocks the vast majority of unauthorized traffic before authentication even begins.

The Cloud Tool Dilemma: BI Platforms and SSO

This is where most security strategies start to break.

The moment a company adopts tools like Tableau Cloud or Power BI, the model changes.

These platforms do not connect from a fixed, controlled network.

They operate from large, dynamic IP ranges that constantly evolve.

This creates a dilemma:

• Allow all traffic → you expose your platform.
• Block unknown IPs → you break business usage.

Most teams choose the easy path.

They allow everything.

And that is the mistake.

At Atlas Data Group, Youssef takes a different approach by layering controls instead of choosing between security and usability.

He restricts access to the official IP ranges published by the BI vendor, while enforcing strict identity verification through SSO and MFA.

This combination is critical.

Network policies control where the connection comes from, while identity controls who is connecting. One without the other is not enough.

This creates a strong security guarantee: even if an attacker gains access to an allowed IP range, they still cannot authenticate without valid identity and MFA.

At the same time, legitimate users can continue to use BI tools without friction.

The takeaway is simple: network controls without identity are fragile, and identity without network controls is incomplete. Real security comes from combining both.

Securing Automated Users (Service Accounts)

Securing human users is only half the problem.

A large part of your data platform runs through automated pipelines and applications.

Tools like Fivetran, dbt, or Airflow connect to Snowflake continuously to move and transform data.

These are not user accounts. They are service accounts running 24/7.

And they are often the most dangerous.

They:

• Do not use MFA
• Run continuously
• Often have elevated permissions

This makes them high-value targets.

At Atlas Data Group, Youssef secures them with two layers.

1. Public / Private Key Authentication

Passwords are the weakest link.

Instead of using passwords, service accounts authenticate using cryptographic key pairs.

Snowflake stores the public key. The application holds the private key securely.

ALTER USER fivetran_service_user SET RSA_PUBLIC_KEY = 'MIIBIjANBgkqhkiG9w0...';

Access is granted only if both keys match.

Unlike passwords, private keys cannot be guessed or brute-forced.

2. Network Policies

Authentication alone is not enough.

Even with a valid key, access must be restricted.

A user-level network policy is applied to the service account, allowing connections only from trusted IP ranges (for example, the official IPs published by the tool).

CREATE NETWORK POLICY fivetran_policy ALLOWED_IP_LIST = ('35.234.12.0/24');
ALTER USER fivetran_service_user SET NETWORK_POLICY = fivetran_policy;

This creates a critical constraint:

Even with a valid private key, a connection is denied if it does not come from an approved network.

Operating, Auditing, and Automating Network Policies

Once network policies are in place, the job is not finished. Security controls must be observable, auditable, and easy to maintain. Youssef relies heavily on Snowflake’s system views and automation tools to keep Atlas Data Group secure.

1. Monitoring Login Activity

The easiest way for Youssef to audit access is through Snowflake’s system view: SNOWFLAKE.ACCOUNT_USAGE.LOGIN_HISTORY. This view records every login attempt, including the user, the IP address used, the client application, and whether the login succeeded or failed. He runs a simple query to review recent authentication activity:

SELECT
  user_name,
  client_ip,
  event_timestamp,
  reported_client_type,
  is_success,
  error_message
FROM SNOWFLAKE.ACCOUNT_USAGE.LOGIN_HISTORY
WHERE event_timestamp >= DATEADD(day, -7, CURRENT_TIMESTAMP())
ORDER BY event_timestamp DESC;

This provides a quick audit trail of recent access patterns , answering operational questions such as who connected recently, from which IP addresses, and which tools are accessing Snowflake.

2. Detecting Network Policy Violations

When a connection attempt comes from an IP address that is not allowed by a network policy, Snowflake blocks it. These blocked attempts appear in LOGIN_HISTORY with a specific error code: INCOMING_REQUEST_BLOCKED_NETWORK_POLICY_REQUIRED.

Youssef monitors these events with the following query:

SELECT
  user_name,
  client_ip,
  event_timestamp,
  error_message
FROM SNOWFLAKE.ACCOUNT_USAGE.LOGIN_HISTORY
WHERE is_success = 'NO'
  AND error_message = 'INCOMING_REQUEST_BLOCKED_NETWORK_POLICY_REQUIRED'
ORDER BY event_timestamp DESC;

This allows his team to quickly identify users connecting from unauthorized networks or misconfigured service accounts.

3. Identifying Unusual Access Patterns

Beyond simple login success or failure, Youssef analyzes where users are connecting from. The following query aggregates login activity by user and IP address:

SELECT
  user_name,
  client_ip,
  COUNT(*) AS login_count
FROM SNOWFLAKE.ACCOUNT_USAGE.LOGIN_HISTORY
WHERE event_timestamp >= DATEADD(day, -30, CURRENT_TIMESTAMP())
GROUP BY user_name, client_ip
ORDER BY login_count DESC;

This makes it easier to detect anomalies such as unexpected geographic locations or users connecting from many different IP addresses.

4. Automating Network Policy Management with Infrastructure as Code

As Atlas Data Group scales, manually managing network policies via SQL quickly becomes difficult. IP ranges change, new tools are integrated, and new environments are deployed.

To keep policies consistent and secure, Youssef manages them using Infrastructure as Code (IaC) tools like Terraform. Instead of manually running CREATE NETWORK POLICY, he defines the infrastructure in a Terraform configuration file:

resource "snowflake_network_policy" "casablanca_office_policy" {
  name            = "CASABLANCA_OFFICE_POLICY"
  allowed_ip_list = ["192.168.1.0/24"]
  blocked_ip_list = ["192.168.1.50/32"]
  comment         = "Managed by Terraform for Atlas Data Group"
}

This approach allows his team to version-control network policies, automatically deploy them, and safely update IP ranges when vendors modify them. It turns security configuration into auditable, reproducible infrastructure rather than manual administration.

Conclusion

Securing a modern data platform requires moving past the outdated mindset of relying solely on passwords. As we’ve seen with Atlas Data Group, true security requires a layered defense combining Multi-Factor Authentication for humans, cryptographic key-pairs for service accounts, and strict Network Policies for both.

Network policies act as your non-negotiable virtual perimeter, instantly dropping unauthorized traffic before an attacker can even attempt to guess a password. However, deploying a policy is only step one. Continuous auditing of your LOGIN_HISTORY and managing your rule sets through Infrastructure as Code are what turn a basic security feature into an enterprise-grade defense system.

Don’t wait for a credential leak to test your boundaries. Start small today: query your LOGIN_HISTORY to understand where your traffic is actually coming from, identify your core office or VPN IP blocks, and implement your first account-level network policy.