Why access control protects sensitive data in Snowflake - Visual Breakdown

Process Flow - Why access control protects sensitive data

User tries to access data

↓

Check user identity

↓

Verify user permissions

↓

Allow access

↓

User sees data

This flow shows how access control checks who the user is and what they are allowed to see before giving access to sensitive data.

Execution Sample

Snowflake

GRANT SELECT ON TABLE customers TO ROLE analyst;
-- Analyst role can read customer data

SELECT * FROM customers;
-- Analyst runs this query

This code grants read access on the customers table to the analyst role, then the analyst queries the data.

Process Table

Step	Action	User Role	Permission Check	Access Result	Data Visible
1	User 'analyst' runs SELECT query	analyst	Check if 'analyst' has SELECT on customers	Permission found	Data rows returned
2	User 'intern' runs SELECT query	intern	Check if 'intern' has SELECT on customers	Permission not found	Access denied, no data
3	User 'admin' runs SELECT query	admin	Check if 'admin' has SELECT on customers	Permission found	Data rows returned
4	User 'analyst' tries to UPDATE customers	analyst	Check if 'analyst' has UPDATE on customers	Permission not found	Access denied, no update
5	User 'admin' tries to UPDATE customers	admin	Check if 'admin' has UPDATE on customers	Permission found	Update allowed

💡 Access control stops users without proper permissions from seeing or changing sensitive data.

Status Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4	After Step 5
User Role	none	analyst	intern	admin	analyst	admin
Permission (SELECT)	none	granted	not granted	granted	granted	granted
Permission (UPDATE)	none	not granted	not granted	granted	not granted	granted
Access Result	none	allowed	denied	allowed	denied	allowed
Data Visible	none	yes	no	yes	no	yes

Key Moments - 3 Insights

Why can't the 'intern' user see the customer data?

Because the 'intern' role does not have SELECT permission on the customers table, as shown in step 2 of the execution table where permission check fails and access is denied.

Why is the 'analyst' allowed to read but not update the data?

The 'analyst' role has SELECT permission but not UPDATE permission on the customers table, so reading is allowed (step 1) but updating is denied (step 4).

How does access control protect sensitive data?

It checks user roles and permissions before allowing data access or changes, blocking unauthorized users as seen in multiple steps where permission is missing and access is denied.

Visual Quiz - 3 Questions

Look at the execution table, what is the access result when 'intern' tries to SELECT from customers?

A Permission found, data returned

B Permission not found, access denied

C Permission found, but no data returned

D Access allowed without permission

💡 Hint

Check step 2 in the execution table where 'intern' role permission is checked.

At which step does the 'analyst' role try to update the customers table and what happens?

A Step 4, update denied

B Step 1, update allowed

C Step 5, update allowed

D Step 2, update denied

💡 Hint

Look at step 4 in the execution table for 'analyst' update attempt.

If the 'intern' role was granted SELECT permission, how would step 2 change?

A User role would change to 'analyst'

B Access result would remain 'Permission not found' and data visible 'no'

C Access result would be 'Permission found' and data visible 'yes'

D Data visible would be 'no' regardless

💡 Hint

Refer to variable_tracker for permission and access result changes.

Concept Snapshot

Access control checks who you are and what you can do.
Permissions like SELECT or UPDATE control data access.
Users without permission are blocked from sensitive data.
Roles group permissions for easier management.
Always grant least privilege needed to protect data.

Full Transcript

Access control protects sensitive data by checking user identity and permissions before allowing access. When a user tries to read or change data, the system verifies if their role has the needed permission. If yes, access is granted and data is visible. If no, access is denied and data remains protected. For example, an analyst role with SELECT permission can read customer data but cannot update it. An intern without SELECT permission cannot see the data at all. This ensures only authorized users can view or modify sensitive information, keeping data safe.