SnowPro Core Certification: Data Protection and Data Sharing（6/8）
✅CHECK SNOWFLAKE DOCUMENTATION FOR THE LATEST RELEASE/FEATURE
✅Data Protection
👉Cloud services layer
👉Snowflake-provided clients
Snowflake SQL API provides operations that we can use to:
Submit SQL statements for execution.
Check the status of the execution of a statement.
Cancel the execution of a statement.
Fetch query results concurrently.
Snowflake has the following Cloud Partner Categories:
Data Integration
Business Intelligence (BI)
Machine Learning & Data Science
Security Governance & Observability
SQL Development & Management, and
Native Programmatic Interfaces.
👉Database Storage
The benefits of The Data Cloud are Access, Governance, and Action (AGA).
Access means that organizations can easily discover data and share it internally or with third parties without regard to geographical location.
Governance is about setting policies and rules and protecting the data in a way that can unlock new value and collaboration while maintaining the highest levels of security and compliance.
Action means you can empower every part of your business with data to build better products, make faster decisions, create new revenue streams and realize the value of your greatest untapped asset, your data.
👉Time Travel
👉Fail-safe
👉Replication and Failover
Database and share replication are available to all accounts.
Replication of other account objects & failover/failback require Business Critical Edition (or higher). To inquire about upgrading, please contact Snowflake Support.
👉Private connectivity
Private connectivity enables you to ensure that access to your Snowflake instance is via a secure connection and, potentially, to block internet-based access completely. Private connectivity to Snowflake requires the Business-Critical edition as a minimum.
👉Securable Object
Securable Object is an entity to which access can be granted. Unless allowed by a grant, access will be denied.
👉NETWORK POLICY
The SHOW PARAMETERS command determines whether a network policy is set on the account or for a specific user.
For Account level: SHOW PARAMETERS LIKE 'network_policy' IN ACCOUNT;
For User level : SHOW PARAMETERS LIKE 'network_policy' IN USER <username>;
Example - SHOW PARAMETERS LIKE 'network_policy' IN USER john;
👉Tri-Secret Secure
Tri-Secret Secure refers to the combination of a Snowflake-managed key and a customer-managed key, which results in the creation of a composite master key to protect your data. Tri-Secret Secure requires the Business Critical edition as a minimum and can be activated by contacting Snowflake support.
https://docs.snowflake.com/en/user-guide/security-encryption-manage
👉encryption keys
By default, Snowflake manages encryption keys automatically, requiring no customer intervention. Snowflake-managed keys are
--> rotated regularly (at 30-day intervals), and
--> an annual rekeying process re-encrypts data with new keys. The data encryption and key management processes are entirely transparent to the users. Snowflake uses
--> AES 256-bit encryption to encrypt data at rest.
https://docs.snowflake.com/en/user-guide/security-encryption-manage
Snowflake encrypts all data in transit using Transport Layer Security (TLS) 1.2. This applies to all Snowflake connections, including those made through the Snowflake Web interface, JDBC, ODBC, and the Python connector.
👉Snowflake-managed keys
All Snowflake-managed keys are automatically rotated by Snowflake when they are more than 30 days old. Active keys are retired, and new keys are created. When Snowflake determines the retired key is no longer needed, the key is automatically destroyed. When active, a key is used to encrypt data and is available for usage by the customer. When retired, the key is used solely to decrypt data and is only available for accessing the data.
https://docs.snowflake.com/en/user-guide/security-encryption-end-to-end
👉Multi-factor authentication
MFA is enabled by default for all Snowflake accounts and is available in all Snowflake editions.
All Snowflake client tools, including the web interface, SnowSQL, and the various connectors and drivers, support MFA.
Snowpipe is a snowflake-managed serverless service. A Snowflake user can not log into it; therefore, it doesn't require MFA. https://docs.snowflake.com/en/user-guide/security-mfa
Multi-factor authentication adds additional protection to the login process in Snowflake. Snowflake provides key pair authentication as a more secure alternative to the traditional username/password authentication approach. Additionally, Snowflake offers federated authentication, enabling users to access their accounts via a single sign-on (SSO). Users authenticate using SAML 2.0-compliant single sign-on (SSO) via an external identity provider (IdP).
Snowflake strongly recommends that all users with the ACCOUNTADMIN role be required to use MFA.
Okta and Microsoft ADFS provide native Snowflake support for federated authentication and SSO.
After a specified period of time (defined by the IdP), a user’s session in the IdP automatically times out, but this does not affect their Snowflake sessions. Any Snowflake sessions that are active at the time remain open and do not require re-authentication. However, to initiate any new Snowflake sessions, the user must log into the IdP again.
Snowflake SQL API supports Oauth, and Key Pair authentication.
👉external Tokenization
Snowflake supports masking policies that may be applied to columns and enforced at the column level to provide column-level security. Column-level security is achieved by dynamic data masking or external Tokenization.
https://docs.snowflake.com/en/user-guide/security-column
👉IP Addresses
If you provide both Allowed IP Addresses and Blocked IP Addresses, Snowflake applies the Blocked List first. This would block your own access. Additionally, in order to block all IP addresses except a select list, you only need to add IP addresses to ALLOWED_IP_LIST. Snowflake automatically blocks all IP addresses not included in the allowed list.
👉Sharing
Standard views cannot be shared. Direct data sharing enables sharing of the following types of objects: Tables, External tables, Secure views, Secure materialized views, Secure UDFs.
Database sharing across regions and clouds (via replication) is supported in all Snowflake editions; thus, the minimum edition that supports it is the Standard edition.
Snowsight lets you share worksheets and folders with other Snowflake users in your account, allowing others to view and execute SQL in your worksheets and folders.
https://docs.snowflake.com/en/user-guide/ui-snowsight
A share acts as a container for objects that need to be shared and specifies the consumer accounts. A share contains USAGE privileges on the database & the schema to be shared, privileges on the tables, secure views which will be shared, and the consumer account(s) to which the Share will be available.
A virtual warehouse is not part of a share.
If a Snowflake customer consumes a share, they will use their own virtual warehouse.
If a non-Snowflake customer is consuming the Share, they will use the data provider compute through a data provider-created virtual warehouse (which would have been separately configured)
Snowflake data providers can share data that resides in different databases by using secure views. A secure view can reference objects such as schemas, tables, and other views from one or more databases, as long as these databases belong to the same account.
👉Consumer accounts
Consumer accounts can only access and query data but cannot add, modify, or create database objects to a shared database.
Consumer accounts cannot clone a shared database, its schemas, or any of its tables.
Consumer accounts cannot use Time Travel on the shared data.
Consumer accounts cannot further share a shared database.
Shared databases have the following limitations for consumers:
Shared databases are read-only. Users in a consumer account can view/query data, but cannot insert or update data, or create any objects in the database.
The following actions are not supported:
Creating a clone of a shared database or any schemas/tables in the database.
Time Travel for a shared database or any schemas/tables in the database.
Editing the comments for a shared database.
Shared databases and all the objects in the database cannot be re-shared with other accounts.
Shared databases cannot be replicated.
A Snowflake share can be defined without a consumer added to it. One or more consumers can be added to the Share afterward
👉Different cloud platform
It is possible to share data with Snowflake accounts in another cloud platform, but the provider must enable replication and replicate your existing database to the other cloud platform.
https://docs.snowflake.com/en/user-guide/secure-data-sharing-across-regions-plaforms
👉Reader account
A reader account can only consume data from the data provider account that created it.
https://docs.snowflake.com/en/user-guide/data-sharing-reader-create#what-is-restricted-allowed-in-a-reader-account
Sharing with a non-Snowflake user requires the creation of a reader account. The reader account provides the non-Snowflake user with a Snowflake account through which they can consume the shared data. The data providers own the reader account, and all costs (including query costs) are charged to the data provider.
https://docs.snowflake.com/en/user-guide/data-sharing-reader-create
👉Data Exchange
Data Exchange is your own private hub for sharing data with a small group of people or organizations who have been invited to join. The owner of the Data Exchange account is in charge of inviting members and specifying whether they can share, consume, or do both.
https://docs.snowflake.com/en/user-guide/data-exchange
👉Direct data sharing
Standard views cannot be shared. Direct data sharing enables sharing of the following types of objects: Tables, External tables, Secure views, Secure materialized views, Secure UDFs.
https://docs.snowflake.com/en/user-guide/data-sharing-intro
👉Securable Object
Securable Object is an entity to which access can be granted. Unless allowed by a grant, access will be denied.
👉NETWORK POLICY
The SHOW PARAMETERS command determines whether a network policy is set on the account or for a specific user.
For Account level: SHOW PARAMETERS LIKE 'network_policy' IN ACCOUNT;
For User level : SHOW PARAMETERS LIKE 'network_policy' IN USER <username>;
Example - SHOW PARAMETERS LIKE 'network_policy' IN USER john;
👉Tri-Secret Secure
Tri-Secret Secure refers to the combination of a Snowflake-managed key and a customer-managed key, which results in the creation of a composite master key to protect your data. Tri-Secret Secure requires the Business Critical edition as a minimum and can be activated by contacting Snowflake support.
https://docs.snowflake.com/en/user-guide/security-encryption-manage
👉encryption keys
By default, Snowflake manages encryption keys automatically, requiring no customer intervention. Snowflake-managed keys are
--> rotated regularly (at 30-day intervals), and
--> an annual rekeying process re-encrypts data with new keys. The data encryption and key management processes are entirely transparent to the users. Snowflake uses
--> AES 256-bit encryption to encrypt data at rest.
https://docs.snowflake.com/en/user-guide/security-encryption-manage
Snowflake encrypts all data in transit using Transport Layer Security (TLS) 1.2. This applies to all Snowflake connections, including those made through the Snowflake Web interface, JDBC, ODBC, and the Python connector.
👉Snowflake-managed keys
All Snowflake-managed keys are automatically rotated by Snowflake when they are more than 30 days old. Active keys are retired, and new keys are created. When Snowflake determines the retired key is no longer needed, the key is automatically destroyed. When active, a key is used to encrypt data and is available for usage by the customer. When retired, the key is used solely to decrypt data and is only available for accessing the data.
https://docs.snowflake.com/en/user-guide/security-encryption-end-to-end
👉Multi-factor authentication
MFA is enabled by default for all Snowflake accounts and is available in all Snowflake editions.
All Snowflake client tools, including the web interface, SnowSQL, and the various connectors and drivers, support MFA.
Snowpipe is a snowflake-managed serverless service. A Snowflake user can not log into it; therefore, it doesn't require MFA. https://docs.snowflake.com/en/user-guide/security-mfa
Multi-factor authentication adds additional protection to the login process in Snowflake. Snowflake provides key pair authentication as a more secure alternative to the traditional username/password authentication approach. Additionally, Snowflake offers federated authentication, enabling users to access their accounts via a single sign-on (SSO). Users authenticate using SAML 2.0-compliant single sign-on (SSO) via an external identity provider (IdP).
Snowflake strongly recommends that all users with the ACCOUNTADMIN role be required to use MFA.
Okta and Microsoft ADFS provide native Snowflake support for federated authentication and SSO.
After a specified period of time (defined by the IdP), a user’s session in the IdP automatically times out, but this does not affect their Snowflake sessions. Any Snowflake sessions that are active at the time remain open and do not require re-authentication. However, to initiate any new Snowflake sessions, the user must log into the IdP again.
Snowflake SQL API supports Oauth, and Key Pair authentication.
👉external Tokenization
Snowflake supports masking policies that may be applied to columns and enforced at the column level to provide column-level security. Column-level security is achieved by dynamic data masking or external Tokenization.
https://docs.snowflake.com/en/user-guide/security-column
👉IP Addresses
If you provide both Allowed IP Addresses and Blocked IP Addresses, Snowflake applies the Blocked List first. This would block your own access. Additionally, in order to block all IP addresses except a select list, you only need to add IP addresses to ALLOWED_IP_LIST. Snowflake automatically blocks all IP addresses not included in the allowed list.
No comments:
Post a Comment