Snowflake is fast becoming a major player as a SaaS platform for all of an organisation’s data needs – covering a wide array of requirements from your basic analytical data warehouse storage and querying, to their newer offerings including python-based web applications and machine learning functionality. This is all backed by their first class ability to monetise your data and integrate data shared by other Snowflake users through their data marketplace system.
As with any cloud-based system or data storage service, the ability to secure your instance and control access is an absolute fundamental. Snowflake have multiple inbuilt protocols beyond the standard usage of Transport Layer Security (TLS) that you can take advantage of to customise your Snowflake tenant security to meet your needs and in this blog post we will explore how you can utilise some of these options to keep your Snowflake instance secured and your data in the right hands.
Limit Sources of Access
Before you consider what you want to be accessible to who, you can limit the ability of your Snowflake tenant to be reached in the first place. A key tool in your arsenal is the Network Policy and the associated Network Rules to direct it. This restricts which IP addresses can communicate into your Snowflake tenant. We would recommend that a general account-wide policy is set to restrict traffic to your corporate network and VPN.
Note that you can apply policies directly to users or security integrations that need exceptions e.g. a third party IT support company, or the security integrations needed for Microsoft Entra ID single sign-on. These exceptions can increase, limit or change the range of IP addresses the user or security integration can use to access your Snowflake tenant and give you flexibility in how you control this access.
Limit Routes of Access
In addition to controlling the IP address ranges that can be used to connect to your Snowflake tenant, you can also use the Authentication Policy settings to determine whether driver-based connections such as ODBC and JDBC, the web-based Snowsight UI or the SnowSQL command-line interface can be used to connect to your Snowflake instance. Additionally, for any given Authentication Policy, you can determine the allowable authentication methods on the connections covered, with options being SAML-based SSO, OAuth-based SSO, Snowflake password and Snowflake key/pair authentication.
If you only want the service accounts that connect your tech stack to Snowflake to be able to use ODBC and JDBC connections, you can apply an Authentication Policy to your account that does not allow ODBC/JDBC connections, and apply a separate policy to the service account users to allow only those specific users access via ODBC/JDBC. For example, require them to specifically use key/pair authentication.
Role-Based Access Control
Even if your tenant is secured from being easily accessed outside of approved means, it is important to reduce the risk of allowing those who do have access gaining levels of access beyond that intended.
One method is by making use of the principle of, least privilege combined with Snowflake’s role based access control model to limit the accesses and privileges of a user to only those which they will need to fulfil their duties. Snowflake has some very granular permissions which can be tailored to create roles as broad or specific as required for your organisation’s needs. It also includes the ability to grant roles to other roles to allow you to “roll up” privileges and simplify that role structure where appropriate. You can limit not only the kind of actions a user can take within your Snowflake account, but even which areas of your account they can take those actions.
There are also options within Snowflake not just to limit the privileges and areas accessed but also the nature of the data visible making use of their Row Access and Masking Policies and Secure Views.
Strong Authentication
The principle of least privilege is only as strong as the ability to keep people from obtaining privileges they are not supposed to have. As such, the authentication for users should be as strong as possible to prevent unauthorised access to accounts.
Snowflake integrates with industry standard enterprise-level authentication options such as Microsoft Entra Id and Okta to allow single-sign on. Additionally Snowflake allows the ability to use rotating key/pair login and custom password policies to strengthen password-based login with passwords up to 256 characters in length and complexity across symbols, numbers, uppercase and lowercase letters. This is customisable alongside the minimum and maximum password lifespan, with the flexibility to customise password policies not just for the account level but also for specific higher- or lower-risk user accounts.
It is also possible (and recommended) for users to enable multi-factor authentication on their Snowflake login via Duo in addition to their initial authentication.
Limiting Connection Lifespan
A common security nightmare is someone logging in and leaving that connection open for use or abuse by other users. Snowflake allows the ability to control session idle times prior to logout across both the Snowflake UI and other session types separately down to the minute. As per the Authentication, Password and Network Policies this can be customised both at the account level and for individual users who require more tailored policies applied.
Settings to be wary of are the ALLOW_ID_TOKEN and ALLOW_CLIENT_MFA_CACHING parameters for the Snowflake account. Designed to be secure by default, Snowflake disallows these options as standard. Turning on these options allows connection credential caching on the client-side operating system keystore and minimises authentication prompts. Whilst this may be convenient, it is also a potential security risk, particularly as these options can only be enabled account-wide and not for individual user accounts.
Security as a Continuous Practice
As with anything in the IT sphere, very rarely do initial system configurations and user accesses meet business needs ever after. Any initial security setup will be critically undermined if it is not reviewed and maintained.
Those of you who use Qlik may be aware of the Snowflake Monitoring app we have helped Qlik to launch. It not only assists in monitoring your Snowflake costs and usage, but includes the ability to visualise user access to your data through their role-based access. This app is freely available to Qlik customers and can now be installed through a Qlik Application Automation flow included with Qlik Cloud tenants!
For those who want to dig directly into the information in your Snowflake tenant, Snowflake comes with built-in account usage views that can be used for auditing and monitoring purposes and alerting by the ACCOUNTADMIN role or roles that have been granted the necessary imported privileges on the built-in Snowflake database share.
In addition to monitoring what is going on in your current set-up, regular reviews should be carried out. This should not be limited to user-accesses, but also the current security set up and any new features released by Snowflake and any other vendors in your technology stack that connect to your Snowflake instance. A software that only connects via password today may allow key/pair or OAuth access tomorrow, and each connection to Snowflake you can make more secure will reduce the risk of unauthorised access to your data.
Learn more
Snowflake has plenty of options available to ensure your Snowflake tenant is only accessible at the right time, in the right place, by the right people and in the right way. If you would like to discuss options with our qualified Snowflake professionals in securing your tenant, please use the form below to contact us.
Follow us
Follow Ometis on LinkedIn to keep up to date with developments in Qlik, Snowflake and Databricks plus all things data related.
Comments