Demystifying Network Security in Snowflake

Network Security & Snowflake:

Network security is considered as one of the 1st level of security on Snowflake and it is extremely important as it helps protects all the unwanted access to the data cloud which has all critical data sets. Some of the extremely critical benefits that we get applying network security are :

  1. Protecting all the confidential data.
  2. Prevent the unauthorized access.
  3. Flexibility to apply at various levels.
  4. Secure communication.

IP & Networking Overview:

Network security is primarily dependent on how the communication happens through internet from any client to Snowflake. Now, when it comes to internet it becomes important to know fundamentals about IPv4 protocol. So what is IPV4??

IPv4 (Internet Protocol version 4) is the fourth version of the Internet Protocol (IP), that governs how data packets are transmitted over networks. IPv4 is the most widely used version of the Internet Protocol that has 32-Bit Addressing: IPv4 addresses are 32 bits in length, expressed in dotted-decimal notation (e.g., 167.244.20.10). This translates to having 4.3 billion unique address. These are represented by 4 numbers(octets) separated by 3 dots.

IPv4 → [0–255]. [0–255]. [0–255]. [0–255]

What is a CIDR then ? Imagine we have a use case where we want to allow Snowflake to be accessed from 100+ IPs. Then how do we ensure we just allow from those 100 Ips & block the rest of them. Do we explicitly go on mentioning details about IP in its configurations like :

ALLOWED_IP_LIST=(192.10.10.1, 192.10.10.2, 192.10.10.3, ......., list goes on)

Or do we have a method where we mention things in a range. This is exactly where CIDR comes into picture. The full form of CIDR is Classless Interdomain Routing, which is a method to allocate the IP addresses.

CIDR notation of IPv4 → 187.245.0.0/28.

Now, the challenge ? How do we decode CIDR to IPv4 ?

CIDR to IP range.

As we know we have 4 octets, hence the IP has 4 octets represented as below:

Octet~IP

Below is a simple example on how CIDR to IPv4 can be mapped.

CIDR to IP

To summarize, we understood how can relate a CIDR range to IPv4. Also how in internet the IPs are allocated. IPs actually holds the key to resolve all the domain names.

Snowflake domain name & IPv4:

Whenever we create a any trail account then it is always associated with a domain name. And each domain name is associated with an IPV4 address. Below is how we can check the IPv4 address:

Domain name to IPv4

What we understood till now ?

We understood what is ipv4 and what is an IP address. How to get the IP address of the domain name from the URL. Also understood the concepts of octets, CIDR. To summarize any client which is trying to connect to Snowflake through internet has got a unique IP and the same IP would be used in the network configurations set-up for whitelisting.

Snowflake Network rules & Network Policies:

Network rules: It is a feature which is introduced newly, network rules are schema-level objects that group network identifiers into logical units. They are usually used along with Network policies for setting up the network configurations within Snowflake.

Network policies: A network policy can be used by a security administrator, or higher, to grant or refuse access to a request according to where it came from. While the prohibited list determines which requests should be specifically blocked, the allowed list of the network policy governs which requests are permitted to visit the internal stage or the Snowflake service.

To summarize, Network policies use Network rules to control inbound network traffic to the Snowflake service and internal stages.

One of the important thing to note over here is as below:

Note from Snowflake on network rule & policies
---Traditional Method ----
CREATE NETWORK POLICY demo_network_rule
ALLOWED_IP_LIST = (192.23.10.2)
BLOCKED_IP_LIST=(192.23.10.4/28);

---New Method----
CREATE NETWORK POLICY demo_network_rule
ALLOWED_NETWORK_RULE_LIST = ('rule_allow_01')
BLOCKED_NETWORK_RULE_LIST=('rule_blocked_02');

As we can see above henceforth when applying any network policy in the allowed and blocked details we need to specify the network rules instead of specifying the IPv4 address of CIDR details.

Where all network policy/rules can be applied ?

Within Snowflake as this is the first layer of security, hence it is also significant to understand in which all places the network polciy can be applied. Hence network policies can be applied at the following levels:

  1. Account level.
  2. Security integration.
  3. User level.

A use case explained in detail(applying this at an user level):

Let us now see how we can configure the network policies & network rules. For this I have configured the set-up within Snowsight.

Step 1 → Go to the below console and create a network rule. Use role SECURITYADMIN or higher to do this exercise.

This is where we create the network rule & policies.

Step 2 → Create the network rules over here. Please note that creating network rules would not activate it.

Please note that you need to fire the below command in Snowsight to get the IP which needs to be put in the network rule.

select current_ip_address();

Step 3 → Go to the network policy tab now and create the policy along with these rules.

This is where we assign it

Once created the network policy remains in “Inactive” state. Hence this has to be activated first, the icon is that “3 dots” where you activate this policy.

Step 4 → This is the last step where you now go and assign this network policy to the user.

ALTER USER DEMO_USER_01 SET NETWORK_POLICY = NETWORK_POLICY_01;

Key points in this set-up:

Network policy are very powerful. For an example if we set the network policy at an account level with a network rule which would have allowed_ipv4 address as just one i.e., 10.123.34.8, then Snowflake URL can be accessed just through this one IP. And network connections apart from this trying to connect to Snowflake would not work.

Only one account level network policy can be set per account. Hence before applying it or setting the necessary due diligence has to be done.

Governance around network policy:

Below are some of the key commands that helps in governing the network policies

--To check the current_ip_address from which the network traffic is originating:
select current_ip_address();


--To get the IP address from where the network traffic is originating from:
select * from snowflake.account_usage.login_history;

--To view the network level parameter:
SHOW PARAMETERS LIKE 'network_policy' IN ACCOUNT;
SHOW PARAMETERS LIKE 'network_policy' IN USER DEMO_USER_01;


--To set a network policy:
ALTER USER SOMEN202403 SET NETWORK_POLICY = NTWRK_POLICY_01;


--To view the description of the network policy:
DESCRIBE NETWORK POLICY NETWRK_PLCY_01;


--To unset the network policy from the user or account:
ALTER ACCOUNT UNSET NETWORK_POLICY; ---'NETWRK_PLCY_01;;
ALTER USER DEMO_USER_01 UNSET NETWORK_POLICY; ---'USER DETAILS'


-- Some other key commands on network rules:
-- URL :: https://docs.snowflake.com/en/user-guide/network-rules
CREATE NETWORK RULE --> Creates a network rule.
ALTER NETWORK RULE --> Alters a network rule.
DROP NETWORK RULE --> Drops a network rule.
DESCRIBE NETWORK RULE --> Describes a network rule.
SHOW NETWORK RULES --> Shows a network rule.


-- Bypassing the network policy:
Bypassing a network policy
It is possible to temporarily bypass a network policy for a set number of minutes by configuring the user object property MINS_TO_BYPASS_NETWORK_POLICY, which can be viewed by executing DESCRIBE USER. Only Snowflake can set the value for this object property. Please contact Snowflake Support to set a value for this property.

Important points about Network rules & policies:

Below are some of the important data points on setting up of network rules & policies:

Key data points.

More reads:

Network rule: https://docs.snowflake.com/en/user-guide/network-rules

Network policies: https://docs.snowflake.com/en/user-guide/network-policies

Please keep reading my blogs it is only going to encourage me in posting more such content. You can find me on LinkedIn by clicking here and on Medium here. Happy Learning :)

Awarded consecutively as “Data Superhero by Snowflake for year 2024 & 2023”. Links: here

Disclaimer: The views expressed here are mine alone and do not necessarily reflect the view of my current, former, or future employers.

--

--

Somen Swain
Snowflake Builders Blog: Data Engineers, App Developers, AI/ML, & Data Science

Snowflake Data Superhero 2024 & 2023 | AWS Solution Architect Associate | 2XSnowflake Advanced Certified | Principal-Data Engineering at LTIMindtree