Zero Trust and Snowflake
Zero trust is not a new concept in cybersecurity. As a model for securing resources on networks within and beyond the enterprise’s control, the term zero trust carries a lot of marketing power. But what exactly is zero trust? Is it a technology? A set of guiding principles? Or maybe a combination of the two? First coined by John Kindervag while at Forrester, the concept of zero trust can be reduced to „never trust and always verify“ every user, device, and IP address accessing a resource. 1
NIST SP 800-27 provides a good description of zero trust. “Zero trust is a cybersecurity paradigm focused on resource protection and the premise that trust is never granted implicitly but must be continually evaluated. Zero trust architecture is an end-to-end approach to enterprise resource and data security that encompasses identity (person and nonperson entities), credentials, access management, operations, endpoints, hosting environments, and the interconnecting infrastructure.”2
Traditional data platforms have long defended data through a layered approach. Many on-premises data platform solutions were deep within organizations’ networks and have benefited from security defenses built around them in layers over a long time. When clients deep within these layers “talked to” a data platform that was also on the inside, they usually trusted that client because of where it lived in relation to the platform. With data workloads migrating to the cloud, data architects have had to rethink data security. Zero trust security models are popular for applications, but architects must consider whether they are the right choice to protect the data itself.
Traditional data platform defense is at the perimeter, controlling traffic flowing in and out of a well-defined, enterprise-owned network. The rise of cloud applications and employees working from home means the perimeter is harder to define and, therefore, defend. Paul Simmonds coined the term deperimeterization to describe the breakdown of network boundaries. 3 The concepts of deperimeterization evolved and improved into the larger concept of zero trust, which was later coined by John Kindervag”2 This means that SaaS applications must provide multiple controls to achieve a zero trust model.
Snowflake fits well into an organization’s zero trust model. The following Snowflake product security features allow on-premises or cloud assets to remain untrusted until validated and approved:
Network Security Measures: All customer data is encrypted in transit and at rest with Snowflake. Using network policies, organizations can specify which IP addresses can connect to the Snowflake platform. Trusted resources can come from only the defined IP addresses that you control. If required, Snowflake can be used with cloud service providers‘ private networking technologies as well.
Identity Management: Snowflake supports a variety of open standards. It can integrate with an organization’s identity provider to ensure federated authentication via SAML2 and allow for multi-factor authentication, adding layers of trust to a user or resource authenticating to Snowflake. Automating the System for Cross Domain Identity Management (SCIM) is a great way to manage the user life cycle. This is particularly handy when automating user off-boarding.
Authorization: Ensuring users act with least privilege and separation of duties is enforced through Snowflake’s flexible and granular role-based access controls. By default, Snowflake users have least privilege, receiving a more privileged role as business needs require. Conditional policies built on Snowflake Dynamic Data Masking become a powerful tool to further protect sensitive data, so only users with trusted roles can see data in clear text, while data is obfuscated for users with other roles.
Encryption: All data is encrypted at rest for all editions of Snowflake. SaaS vendors that offer a bring-your-own-key (BYOK) option provide a powerful capability to never trust not only users, but the service itself. Snowflake’s Tri-Secret Secure feature lets you control access to your data using a master encryption key maintained in the key management service for the cloud provider that hosts your Snowflake account. Snowflake combines your key with a Snowflake-maintained key to create a composite master key. This composite master key is then used to encrypt all data in your account. If you revoke your key, your data in Snowflake cannot be decrypted.
Monitoring Snowflake: Zero trust means that activity should be monitored on enterprise-owned networks and SaaS applications.The Snowflake’s Account Usage schema is an excellent way to monitor Snowflake and understand what is normal activity, including user login behavior, authentication types, granting of administrative privileges, and IP addresses of resources connecting to Snowflake. For example, the average number of seconds between failed login attempts can be fed into an organization’s SIEM for trend analysis to understand what baseline normal is, enabling alerts on abnormal behaviors.
With the continued deperimeterization of organizations’ networks, organizations should evaluate SaaS application product security features to determine the feasibility of using a zero trust model to allow access to an application. Snowflake provides robust zero trust product security features out of the box. Achieving zero trust with a single technology is unlikely, especially on a network that is not owned by the enterprise. Snowflake’s product security features provide:
- Secure access to Snowflake
- Standards-based and strong-authentication methods
- Granular role-based access controls
- Encryption of customer data in transit and at rest with a BYOK option
- Audit activity for continuous monitoring
In totality, these features provide a mechanism across security domains to, in fact, never trust and always verify. Snowflake is positioned well to fit into a zero trust model, providing a service that is secure and resilient so you can focus on analyzing your data, not protecting it.