One account is not enough. In many cases, organizations using Snowflake use multiple accounts rather than a single account. Sometimes these accounts are temporary and are only used for specific projects or tests, while other times they are created for organizational, operational, or compliance reasons. In this article, we’ll cover some of these reasons, as well as how you can simplify the account creation process with the Snowflake ORGADMIN role, and how you can simplify the security, governance, and privacy management of your organization’s accounts with Satori.
Reasons For Having Multiple Snowflake Accounts
This article is by no means a complete list of use cases for multiple-accounts use in Snowflake but covers some of the most prominent cases I’ve encountered.
Testing and Staging Environments
When developing software, it is important to keep a separation between development, testing, and staging environments. This is done to minimize the impact of bugs on the production environment. A part of healthy DataOps is to do the same for data infrastructure and introduce changes first on a staging environment, and only then on production.
In Snowflake, this can be achieved in several ways. Some organizations put their staging databases on the same account as their production data. This is typically done to reduce overheads in managing multiple environments. However, this is often a shortcut that comes at the expense of a more complete staging environment, which can be achieved by actually having a separate account where changes are made first, and once verified, are applied to production.
Early Access
Another reason for having separate accounts, which usually combines with a staging environment, is an environment where Snowflake early access is enabled. As Snowflake is a SaaS product that continuously changes, it makes sense to also take into account changes introduced by Snowflake. Having an account where tests are run against the early access version, can serve as a canary (i.e. if there are failures, you can either adapt your code or configuration or alert Snowflake to an edge-case bug being introduced).
Multiple Business Units
In many companies, Snowflake is used across multiple business units. This leads to many questions, which depend on specific requirements and organizational structure. These questions can be operational (such as who maintains the schemas, which budget pays for the computer, etc), as well as security-, privacy-, compliance-, and governance-related questions.
Some organizations are solving these challenges within a single account. For example, Snowflake object tagging can be used to tag data for different cost centers. However, this is not always the case, and some organizations decide to simplify the separation, by having several Snowflake accounts and distributing them to their different business units. When data needs to be shared, they then use Snowflake’s native data sharing capabilities.
Regional Accounts
In certain cases, for regulatory and compliance reasons, data from specific regions have to be stored within a certain geographic region. Certain restrictions specific to these regions must also be imposed. As an example, users connecting to the data store may be required to only log into the system from that region.
B2B Multiple Accounts
Some businesses are managing data for other businesses in Snowflake. As with other multi-tenancy architectures, there are several ways to go about designing such a solution, depending on the exact situation. However, in some cases, the best way to separate the data of different customers is to use a separate account for each one of them.
Different Cost Plans
Lastly, organizations occasionally store different types of data with different requirements, where certain data (mostly sensitive data) may require higher account tiers (such as enterprise or business critical). As the different tiers incur additional costs, which you may not always want to apply to other data, you have the option to create standard accounts in addition to these higher tiered accounts.
Learn More:
- How Satori helps secure data access to Snowflake at scale
- Book a demo meeting with one of our Snowflake security experts
Simplifying Account Creation With ORGADMIN
In the past, managing multiple accounts was done using support tickets. However, it is now possible to manage multiple accounts (in terms of creation, deletion, and altering of their characteristics) by using the ORGADMIN role. For example, to span a new account, you can use the following command:
| CREATE ACCOUNT stage2 ADMIN_NAME = stageadmin ADMIN_PASSWORD = 'Aa123456' /* not this password :) */ FIRST_NAME = stage LAST_NAME = admin MUST_CHANGE_PASSWORD = TRUE EMAIL = 'dataops@acme.corp' EDITION = standard REGION = aws_us_east_1; |
Â
Managing Multiple Snowflake Accounts
Opening new accounts is one thing. However, managing them at scale, especially from a security, data governance, and privacy point of view, is not a trivial feat. You will still need to manage the settings per account, and as with all things data, this becomes especially tricky when sensitive data is concerned.
Let’s break down some of the requirements for managing multiple Snowflake accounts in terms of security, governance, and privacy, and see how using Satori can help achieve them.
|
The Challenge |
With Satori |
Alternatives |
| Discovering Sensitive Data | Continuous discovery
Data Inventory for all accounts |
Periodic data classification scans |
| Auditing & Monitoring | Audit across all data platforms, including data classification | Effort when audit is actually required
ETLs to prepare logs |
| Access Control | Simplified access control across any number of accounts | Orchestration, or a data engineering effort |
| Distributed Data Stewardship | Simplified data stewardship including classification and authorization workflows across any number of accounts | Orchestration, or a data engineering effort |
Discovering Sensitive Data Across Multiple Snowflake Accounts
The Challenge
Knowing where sensitive data is located across your multiple Snowflake accounts so that you can place security controls around them, as well as generate reports for compliance requirements.
With Satori
Satori continuously discovers sensitive data, across all your accounts, as it is being accessed. You can then manage the classifications from a centralized location, per account, or even per specific datasets within one or more accounts (for example, for all data that belongs to a certain data owner).
You can also set automatically-applied security policies in Satori, to limit access to such sensitive data. In addition, you can use Satori to propagate the classification to data catalogs such as Collibra to improve your data governance.
Alternative Solutions
An alternative solution may be to scan each account for sensitive data. This must be set up for each account, and must be performed periodically. However, performing periodic sensitive data scans may be ineffective in a data-driven environment, where data is continuously changed. For example, if you have a column where event data is added as semi-structured data, and new events are introduced with sensitive data.
Auditing & Monitoring For Multiple Snowflake Accounts
The Challenge
You require a data access log, mainly for security reasons (investigating security events, detecting anomalies, and more), but also for compliance reasons (keeping logs of queries, especially to sensitive data). You can retrieve such information in Snowflake’s snowflake.account_usage schema, with views such as query_history and access_history.
However, this data is kept per account. This can both add operational overhead, as well as complicate finding answers to your security and compliance requirements.
With Satori
With Satori, all data access is logged, along with enriched contextual information, such as the identity groups of the data consumers, the types of data being accessed, and more. You can then analyze the data in its entirety, slice or dice, or even connect Satori to an external platform for analysis. As an example, you can use our data marketplace integration, and analyze all enriched data in Snowflake.
Alternative Solutions
You have several alternative options. One of these is to do nothing different, and when you require reporting or querying of the logs, to do this in your different accounts. However, this can add significant overhead, especially since accessing the log views is not a very quick process.
Another option is to create an ETL that uses data sharing to centralize all the required logs to a central logging (which can be one of your Snowflake accounts, or a different account). This requires operational resources, does not contain the enrichments that Satori adds (such as locations of the sensitive data), and takes additional resources.
Access Control Across Multiple Snowflake Accounts
The Challenge
Managing access control in Snowflake can be challenging even for a single account, when there are many data consumers, and specific requirements around sensitive data, such as dynamic masking or row-level security. These can be simplified with Snowflake’s dynamic masking and row access policies capabilities, but must still be configured and managed.
When it comes to multiple Snowflake accounts, they may either be handled by different teams with varying knowledge in data engineering and security, or be managed centrally by a data services, infrastructure, or engineering team. Either way, this introduces both operational hurdles in managing access control in scale, as well as potential security and compliance risks.
With Satori
Satori enables security management to be separated from the data infrastructure itself. This means that you can set security controls, including fine-grained access control, across a dataset that can be as granular as a single table or view, or can be across hundreds or even thousands of Snowflake accounts at once.
Alternative Solutions
There are other ways to solve this challenge. Your data engineering team can write scripts that automate such projects across different accounts. Such projects can distract those teams from their core business value and are mostly recommended when the requirements are very minimal.
Another way to solve this is to use an orchestration solution that uses Snowflake’s native capabilities while simplifying the work for you. Some orchestration solutions add significant overhead when adding additional accounts and some can’t apply a security policy globally. Some orchestration services may also require you to change your existing queries to access additional objects.
In addition to this, an orchestration solution is a service that requires you to supply ACCOUNTADMIN credentials to an external product(or other powerful administrative roles). In most cases, this even has to be done with a username and password authentication, against best practices (e.g. not by using key-pair authentication).
Distributed Data Stewardship Across Multiple Accounts
Â
The Challenge
Finally, distributing data stewardship across multiple accounts can be a challenge. Occasionally the data stewards for certain datasets need to control access or tag data across multiple Snowflake accounts. In many cases, this does not correlate with the owners of the Snowflake accounts infrastructure itself.
This means that, as an example, a data steward in charge of the marketing datasets often has to request infrastructure changes across multiple accounts. This can create delays in data accessibility.
With Satori
With Satori, datasets can be defined for specific data stewards. These data stewards can then manage their own datasets, whether they are a single account or across multiple accounts. This involves applying data access controls, including fine-grained access control, providing temporary or permanent access to users or groups, and making changes to data classification. All this is done without a need for data engineering resources.
Alternative Solutions
An alternative is either building your own solution or using a data orchestration solution. Building your own system can be a complicated project with hidden costs and efforts. An orchestration solution can accomplish this but may add significant overhead per account added (such as query changes or pre-configuration that may take a large number of resources).
Conclusion
Splitting your Snowflake Data Cloud to separate accounts is not a bad decision. On the contrary, there are several valid use cases to do so. Satori provides you with several advantages when doing so, to keep your security, governance, and privacy requirements at bay without a need for excessive data engineering resources.
Learn More:
- How Satori helps secure data access to Snowflake at scale
- Book a demo meeting with one of our Snowflake security experts
