Snowflake: Security — Framework SSFW: Compliance & Network Layers (Part #2)
The objective of this blog is to provide a better and deeper understanding of the first layers in the Snowflake Security Framework (SSFW) (Part 1). This is the second part of the Snowflake Security series.
On one hand, here we are going to talk about the Compliance culture and methodology that is being applied to the Snowflake Service Cloud, many customers need to know if these are aligned with their needs.
On the other hand, we will cover the most important components on Network layer provides us, to manage the different connections that Snowflake will allow/deny based on the customer needs.
Compliance
Snowflake is continuosly improving the level of compliance to commit the different regulatory rules to ensure levels of security, governance, and data integrity.
Ownership of this compliance is committed to mitigating the different types of risks: common Internet-based threats, non-authorized access, cyber security best practices, and others.
In this way, we can distinguish the reporting certifications into three main blocks based on the type of appliance: Global, Regional, or Sector.
- Global: These ones are considered cross over the other appliance types. It doesn’t matter the region or the edition you contract. We can list the current the below ones here: CSA Star Level 1, ISO-9001:2015, ISO-27001, ISO-27017, ISO-27018, SOC 1 Type II, SOC 2 Type II
- Regional: It depends on the region, it makes sense to apply some or others. We have to highlight that Snowflake provides strictly specific regions only for Government purposes. In order to check the availability, for specific certifications on determined regions, you will have to check it here.
- Sector: These will depend of the industry needs. We can find some of them like Financial services, Helthcare, Banking,etc. But there is special one like Government that applies directly to country regulatory rules (used for federal and state information). So it will depend of the sector, it will requires a higher level of measures than others.
As you can see here we have done a segmentation, but one compliance certification can be match with other ones or not. For example, CE+ applies both UK Region + Government. But other ones, like ISO-27001 is used globally.
You will have to take into consideration that, except the Global certification, not all Snowflake edition are available to provide specific Regional or Sector regulatory compliance certifications. We should check here in order to plan your edition account.
In addition, Snowflake provides some specific regions for determined purposes such as commercial or government use.
Both If you need assistance to know if there is some certification report that is being covered by Snowflake or if it would be implemented soon, you can contact here and specify the ‘Security Information’ as inquiry type.
Network
In this part, we find the gates to allow determined connections and how to manage these ones. Depending on how we want to connect to or how we want to secure our connections, Snowflake provides us with the following features:
Private Connectivity
Implementing a private connection allows us to establish a direct visibility through your internal enterprise end-point without any address to your service. This scenario allows you not to share the same channel (public) to send your more appreciated data. Without a doubt, this feature is the best option eligible for the most demanding privacy needs.
Nowadays, Snowflake allows us to use this service with three different cloud providers: Azure, AWS, and Google (Service Connect). If you want to use this service, you will have to extend your account edition to Business Critical.
You have to set up your internal Service Cloud private link independently of Snowflake, based on your Cloud or on premise requirements. After that, you establish the setup between the Private endpoint and Snowflake endpoint list to keep the private channel.
Here is an example of Azure Private link connectivity with your enterprise end-point.
- 1- Customer VM into the VPC
- 2- Peering from your enterprise, through connecting into your VPN
- 3- Setup your internal Azure Private Link endpoint, into Azure Cloud
- 4- Snowflake Account VPC setup
Private Connectivity for Stages
We need to highlight that Snowflake provides you the capability to create internal stages. A friendly reminder that stage is a feature defined as an internal location where you can that stores and manages your files into the Cloud provider you have specified. This is very useful when you don’t have your own Cloud provider account that already has this information.
In the case you want access to these objects located in an External VPC (in Snowflake, outside your company), Snowflake provides the option to establish a direct channel for these repositories to create a Private Endpoint (it is only possible with Azure and AWS, currently). While you are accessing to the rest of Snowflake sevices from your Enterprise VPCNet, you can redirect access to a specified stage that contains special information, through this private link. This way, you can provide a most safe channel to access to this information.
In the case of Azure Cloud Provider specified the scenario would be this:
Network policies
Snowflake offers the ability to control different network traffic using network policies, by default it allows everyone both applications or individual persons.
If you decide to use it, we have to take into consideration that these policies allow or deny access to Snowflake specifying the lists of your IP addresses. We can’t specify an url, this is due to Snowflake doesn’t resolve all that connections, only check the IP. In that case, we will have to set up an internal enterprise endpoint, to get an immutable IP, so we will be able to specify our allowing connections and deny the rest ones.
The network policies have three levels of control to our Snowflake Data Platform. And you only can use one of them, the below level overrides the previous one in the following order.
- Account: It manages the access to our main account. This will affect all users.
- User: This will affect only for individual user. So you can specify one per user, in this way, it will only be allowed / denied the access to this user for the specified IP address.
In order to ease with the maintenance, and correctly manage a large list of values, we will be able to use Network Rules. The different lists allowed are:
- IP address
- Azure/AWS for private links
- Host/domain (and port) (only for EGRESS traffic).
The existence of this feature allow us to easily encapsulate lists and specify them directly on our network policies. For details of the use, we will see on next chapters.
Below is an example of how we can use Network policies and Network rules together:
- It will block all access
- It will only allow the AWS VPCE (Virtual Private Customer Endpoint)
Firewall
Snowflake provides us the list of the different hostnames and ports from the different internal services. With this list, you will have to specify in your customer/enterprise in order to manage the different outbound traffic.
Through the different commands, you will be able to retrieve that information, depending on your case:
- ALLOWLIST (No private connectivity)
- ALLOWLIST_PRIVATELINK (Private connectivity)
This is an example, how is it showing the information we would need from the Snowflake side:
Integration
The integration feature is the Snowflake capability used in order to interact with different external third party-services. We will list here what is the purpose of each one. This will apply on Network and Access Layer, but after that we will focus on what part affect on each Layer.
We are going to describe briefly the purpose of the different integrations:
- STORAGE: This method allows us to ease the integration when we use External Stages.
- API: Allow us to interact with external functions/api on the allowed cloud providers in order to use that logic with the Snowflake data.
- CATALOG: It is specified for Internal/External Iceberg Tables use.
- EXTERNAL ACCESS: If we need to access to external network location directly from your handlers / procedures.
- SECURITY: This integration is used to improve the security management of different services that also needs service access. That type of services are mainly for authentication or user/roles management.
Focusing now, on what integrations provide us security extra features and what is based these features:
- EXTERNAL ACCESS: Here we have different methods to allow/block the access through Network rules.
- SECURITY: On the Network Layer we will be able to use Network policies for the features that affect to determined Access Layer capabilities: Authentication (Snowflake OAuth) and User / Role Management (SCIM).
Conclusions
The compliance layer is crucial for emphasizing the importance of this aspect to potential customers considering Snowflake Services. Snowflake has demonstrated a strong commitment to compliance capabilities and is consistently enhancing them, offering reliability to the majority of customers through various compliance certifications. On the other hand, the Network Layer comprises features designed primarily to permit or block connections and establish them in the safest possible manner.
You can go back to the initial Snowflake Security Framework (SSFW) (Part 1).
We will see you soon on the next chapter SSFW — Acces Layer.
References
I am a SME on different Data Technologies, with 20+ years of experience in Data Adventures. An experienced Snowflake Data Jedi and Data Vault Certified Practitioner.
If you want to know more in detail about the aspects seen here, or other ones, you can follow me on medium || Linked-in here.
I hope you have joined and this can help you!
