Motivation

When you grant someone a role in an RBAC system, how often do you think about when it should be revoked?

Most RBAC systems grant access forever, and defer to the identity provider to revoke someone’s authentication (e.g. if they leave the company) when it’s no longer needed.

This “all or nothing” access model is broken — in truth, all access is temporary. It could take weeks or decades, but no data access should last forever.

Your internal users need temporary access for many reasons. And the current approach of quarterly membership audits and setting calendar reminders to revoke role grants simply doesn’t work at scale.

Use Cases

Here are a few common examples where short lived roles are needed:

• A customer support representative needs to access a single customer’s shipping information for 1 hour in order to provide help over the phone.
• A developer is debugging one of your enterprise customer’s inventory and needs access for a 5 days in order to investigate and resolve the issue.
• A member of your sales engineering team needs to access marketing analytics for a 3 months as part of a cross-team collaboration effort to research new features.

As you can see, this kind of access is common in the normal operations of a business, and access can be needed on time scales of hours to months.

Benefits

One of the major benefits of temporary access is it reduces the overhead of having to regularly audit role membership. Most access is only ever needed on a temporary basis, and setting a time boundary ensures the access expires automatically.

This significantly improves the security posture of your data. Since access expires frequently, you don’t have to worry as much about “users who have more access than they should.” Think of it as an automatic garbage collection process.

Implementation

Since temporary access tends to increase the number of access requests your data infrastructure team handles, it makes sense to provide self-service options.

Certainly there should be policies for who can access what (e.g. “Customer support reps can request up to an hour of access to customer shipping tables”), but as a general rule, these requests shouldn’t be a heavy operational burden to your team.

Snowflake Role Management

Unfortunately, today Snowflake doesn’t support temporary role grants. You can try to hack around this by experimenting with expiring users (see docs for days_to_expiry), but now you have a user management problem, further complicating things.

At Spyglass, one of our core product offerings is self-service access request workflows with support for custom approval policies and expiring access, built exclusively for Snowflake. We’ll go into the details of that in a future post.

About Spyglass

Since you’re here, let me tell you what we’ve cooked up at Spyglass. In short, we make Snowflake data access controls easy - or provide an automated and better way to do the above.

If you’ve nodded your head while reading this, reach out at spyglass.software (or demo@spyglass.software) and we’ll show you a product demo to give you a taste of the future of data access management.

‍