Azure Tri-Secret Secure (BYOK) & External Stage (Service Endpoints) Security Model
When customers onboard a Snowflake account, outside of the core perimeter security guidance applied; one of the first tasks is integrating customer object storage (ie. ADLS) to Snowflake to begin loading data objects. As outlined in Snowflake’s documentation, customers can choose a number of networking and identity integrations. This post walks through the recommended best practices for network security and Service Principals (authZ) for service endpoint integrations for both External Stages (Data Loading from object storage) and Tri-Secret Secure as the BYOK model for customer managed keys to be integrated into Snowflake’s robust 4+1 encryption key hierarchy (4 layers of envelope encryption applied client side, in addition to the underlying infrastructure encryption).
Snowflake Storage Integrations require a Directory tenant trust via a consent URL. Within the integration, fine grained ACLs can be applied to the allowed/ blocked locations in addition to the entitlement model applied to the Service Principal in the sections below.
Azure AD Service Principals leverage the Client Credentials flow in OAuth 2.0; this flow/ grant type is currently part of the RFC standard for machine-to-machine flows. The OAuth 2.0 client credentials grant specified in RFC 6749, sometimes called two-legged OAuth, is leveraged for web-hosted resources by using the identity of an application.
Azure Key Vault
● Integration pattern is to leverage a Service Principal with Network Access Control Lists (ACLs- whitelisting the the subnet IDs of the Snowflake Azure VNet).
● All traffic is encrypted in transit (TLS 1.2) and remains on the CSP backbone (MSFT).
● The Service Principal is deployed in a least privileged model, with only the ability to verify, sign, wrap, and unwrap the customer managed key (CMK) in the dedicated Azure Key Vault (asymmetric).
Azure Storage Integration Security Model (External Stage)
● Recommended pattern is to leverage a Service Principal (vs. a SAS token) with Network Access Control Lists (whitelisting the the subnet IDs of the Snowflake Azure VNet) as outlined below.
● All traffic is encrypted in transit (TLS 1.2) and remains on the CSP backbone (MSFT).
● Access is tightly controlled by the permissions (scope) of the Service Principal and the storage location/ file path of the allowed/ blocked locations in the storage integration ACL created in Snowflake.
○ The role options assigned to the Service Principal are as follows (Access Control>> Add role assignment):
■ Storage Blob Data Reader (recommended under a least privilege model)
■ Storage Blob Data Contributor (allows for read/ write access and the REMOVE command allowing to remove files staged in the account).
● Customers can also leverage client-side encryption at the file level (AES-256) in addition to the TLS 1.2 encryption in transit for data loading use cases.
For customer Azure subscriptions & Snowflake Accounts hosted on Azure, the following command will display the VNet subnet IDs to whitelist:
select system$get_snowflake_platform_info();
Example: Azure Key Vault & Storage Integration Firewall Rules
To whitelist the VNet subnet ID’s, from the Azure CLI the following command will need to be executed for each subnet ID (2–6 subnets dependent on the region) for a Snowflake account hosted on Azure.
See Usage Scenarios below:
MSFT References:
https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/service-accounts-principal
https://docs.microsoft.com/en-us/azure/key-vault/general/overview-vnet-service-endpoints
https://docs.microsoft.com/en-us/azure/virtual-network/virtual-network-service-endpoints-overview
https://docs.microsoft.com/en-us/azure/active-directory/reports-monitoring/concept-sign-ins
Additional Monitoring (Customer):
The customer can monitor all actions from the Snowflake assumed Service Principal created in the customer Azure Active Directory tenant via Azure Monitor, Azure Security Center, and/ or Log Analytics workspaces. The customer maintains implicit control to revoke access and the permissions applied under a least privilege model to the Service Principal created for the integration.
Compensating Controls applied to the Threat Model
● Azure Key Vault encryption in transit is mitigated via TLS 1.2
● Network ACLs (MSFT subnet IDs from the applicable Snowflake VNet)
● Service Principal (Delegated authorization via the consent URL/ Directory tenant trust, OAuth 2.0 client credential flow) controlling scope to the dedicated key vault.
● Least Privilege model constrained to verify, sign, wrap, unwrap the applicable CMK in scope.
● Controls align to the following resource: OAuth 2.0 Threat Model & Security Considerations
Azure Key Vault Security Assurance Testing
● Enumeration (nslookup) of the vault URI displays the service endpoint IP
● Active scanning (nmap) displays all ports are closed with the exception of HTTPS (443) for the TLS 1.2 encrypted traffic restricted to whitelisted Azure subnet IDs.
● Active scanning (nikto) displays the cipher leveraged for the TLS 1.2 encrypted traffic (ECDHE-RSA-AES256-GCM-SHA384)
**For customers looking to leverage Private Network connectivity to External Stages, the pattern can be referenced here.
