Snowflake\u2019s underlying architecture makes it easy to provide high-performance data access to any number of internal and external users with far more efficiency than traditional databases. At least as importantly, it\u2019s possible to fine-tune that access so you can ensure each consumer only sees exactly what you want them to see, right down to the row and column level.<\/strong> You no longer have to make copies of specific data sets or slam the door shut on whole areas of information just because some of it is sensitive.<\/p>\n Information is simultaneously valuable and dangerous. Organizations can extract enormous value from the information they collect if they can keep it organized and accessible. However, we all know the names of organizations that have allowed sensitive information to escape. New privacy and reporting regulations are emerging every day at state, federal and international levels. Moreover, there\u2019s an enormous reputational risk of a loss of trust from consumers and business partners.<\/p>\n To get the most out of the platform, modern organizations need an implementation plan that:<\/strong><\/p>\n While it is ultimately easier to meet all these goals in a Snowflake<\/a> environment than in traditional databases, it also requires a bit more planning to be effective, consistent, and efficient. This six-part series will propose a set of technology, architecture and process standards to support these goals while balancing cost, maintainability and performance.<\/p>\n Core to any data privacy and management exercise is the ability to identify the data at hand across several dimensions. To meet our goals, we need to know which data is sensitive and private (and where such data is stored), where it came from, who owns it, and frankly, as much as possible about how we can apply it to different purposes \u2013 some of which we don\u2019t know yet.<\/strong><\/p>\n At the beginning of each entry in this series, we\u2019ll go over a few important concepts and recent technological developments that will help us achieve our privacy goals. If you have a lot of database experience, you may know these concepts well, but we often need to think about them a little differently in the context of a Snowflake environment.<\/p>\n Data is typically stored in a nested series of structures, each smaller (in terms of volume and complexity) than the last, each giving more detail and specificity. In a traditional database, this might look like:<\/p>\n Server -> Database -> Schema -> Table -> Column \/ Row (which together define a single element).<\/em><\/p>\n This provides a rudimentary path to information security (if you do not have access to the server, you cannot access any of the tables or data within) but generally leads to an all-or-nothing approach unsuitable to today\u2019s goals.<\/p>\n This was largely forced upon users in a traditional database environment:<\/strong><\/p>\n Cloud-native tools like Snowflake eliminate the server paradigm and treat databases as logical containers, so you can choose an organizational structure that better suits your security and usage patterns. Snowflake also enforces a security-first model, which makes it effectively impossible to grant access to an entire database and all its contents in a single step unless you have specifically and intentionally designed your model to support that from the beginning.<\/strong> More on this in a later blog when we discuss role-based access control.<\/p>\n The first and strongest line of defense for keeping data private is isolation \u2013 there\u2019s a reason we keep our valuables all together in a bank and not lying around the house. However, isolation comes at a cost \u2013 you can\u2019t easily use your jewelry if it\u2019s in a safe-deposit box. Snowflake is a highly-secure environment providing multiple layers of isolation we can leverage for appropriate data access, much like a bank has a drive-up, an ATM lobby, a main lobby, a vault and so forth.<\/p>\n No data is stored at the organization level. This concept simply provides control and administration of multiple accounts. A single organizational administrator can manage all of your separate accounts in a single location, including usage and budgeting. An organization does not need to be set up at all if you\u2019ll only be using a single account, but it\u2019s good future-proofing practice if you may need to manage multiple accounts later.<\/p>\n Snowflake stores all the data for a single account across distributed commodity storage in a single public-cloud provider region, such as \u201cAzure\/North Central US.\u201d This storage is effectively unlimited and doesn\u2019t depend on any one server or hard drive. It\u2019s the same underlying storage used for services like Netflix.<\/p>\n You can copy data from a single account across regions to other accounts within your organization, but you cannot query seamlessly between them. Each account is tied to a cloud region, making this the ideal level of separation to comply with regulations such as GDPR and India\u2019s on-soil requirements. You can choose to physically store all data relating to customers from a given country in a single account hosted in that country.<\/strong><\/p>\n If you have a legitimate need to share some of that data across borders, you can easily make backup copies into other accounts or set up internal data shares to expose tightly controlled subsets of data between accounts.<\/p>\nWhy Does Snowflake Security and Data Privacy Matter?<\/h2>\n
\n
\n
\n
Identify, Organize and Isolate Data in Snowflake<\/h2>\n
Physical and Logical Model<\/h3>\n
\n
Data Isolation<\/h3>\n
![\"Snowflake](\"https:\/\/centricconsulting.com\/wp-content\/uploads\/2022\/09\/Snowflake-Security-Series-PT1-Blog-Graphic-01-300x214.jpg\")
<\/a><\/p>\nOrganization (Optional)<\/h3>\n
Account<\/h3>\n
Database<\/h3>\n
![\"Snowflake](\"https:\/\/centricconsulting.com\/wp-content\/uploads\/2022\/09\/Snowflake-Security-Series-PT1-Blog-Graphic-02-1024x185.png\")
<\/a><\/p>\n