secure views Flashcards
(15 cards)
What is a secure view in Snowflake?
A secure view ensures that users cannot indirectly access underlying base table data through optimizer shortcuts or by inspecting the view definition. It provides stronger privacy and security guarantees than a regular view.
Why might a non-secure view expose hidden data?
Some internal optimizations for non-secure views may access underlying data, which could allow users to infer or access data that should be hidden using user-defined functions or clever queries.
How is a secure view’s definition protected?
A secure view’s query definition is only visible to authorized users with the appropriate roles. Unauthorized users cannot see the SQL text through commands like SHOW VIEWS or GET_DDL.
When should you use a secure view in Snowflake?
Use secure views when you need to limit access to sensitive data and ensure that users cannot infer or access underlying base table details. They should not be used for simple convenience views because secure views can have performance trade-offs.
What is an example of data inference through a non-secure view?
A user could use a query like SELECT * FROM widgets_view WHERE 1/iff(color = 'Purple', 0, 1) = 1; to trigger a division-by-zero error if hidden ‘Purple’ data exists, indirectly exposing its existence.
How does the SECURE keyword work when creating a view?
Add the SECURE keyword to the CREATE VIEW or CREATE MATERIALIZED VIEW statement. You can also convert a view to secure using ALTER VIEW to set or unset the SECURE property.
How do secure views interact with the Query Profile?
The internal logic and query plan of a secure view are not exposed in the Query Profile, even to the owner, to prevent indirect data exposure through profiling details.
How can you check if a view is secure?
Use the IS_SECURE column in INFORMATION_SCHEMA or ACCOUNT_USAGE views, or run SHOW VIEWS or SHOW MATERIALIZED VIEWS to check the secure status of a view.
How can roles and secure views be used together for row-level security?
You can use functions like CURRENT_ROLE() or CURRENT_USER() in a secure view’s WHERE clause to filter rows dynamically based on the user’s role, preventing unauthorized access to rows.
What is a best practice when using sequence-generated keys with secure views?
Avoid exposing sequence-generated IDs because users could deduce information about the data distribution. Use UUIDs or obfuscate the values to prevent inference.
How does Snowflake protect scanned data size for secure views?
Snowflake does not expose data scanned metrics for secure views to prevent indirect insights about underlying data volumes, though query performance might still offer rough hints.
What is a stronger alternative to using secure views for extreme security?
Instead of using a view, create separate physical tables for each user or role containing only the accessible data. This avoids all inference risks but increases management complexity.
Can you use secure views with Secure Data Sharing?
Yes, but when using CURRENT_ROLE or CURRENT_USER in a secure view shared to another account, these functions return NULL because the provider does not control the consumer’s roles or users.
How can you view secure view definitions when needed?
Authorized users with the owning role can view secure view definitions. Users with the ACCOUNTADMIN role or SNOWFLAKE.OBJECT_VIEWER database role can also access secure view details via ACCOUNT_USAGE views.
Why shouldn’t secure views be used just for convenience?
Secure views come with performance trade-offs because they skip certain optimizations. Use them specifically for protecting sensitive data, not for simplifying queries that don’t require extra security.
