About This Episode

You’re planning your data platform; before you know it, access control becomes a topic. Sure, Snowflake offers built-in masking and segmenting controls. Somehow these have to be configured according to your access matrix. 

We’ve been scaling up Snowflake platforms for a while now. Here are some learnings to share: 

Key Takeaways

The Do’s

✅ Start from a control matrix and a change process. Any sort of technology implementation is opaque at best – thus unusable – in the absence of a transparent and well-communicated process;

✅ Use native platform capabilities, and enforce access at the storage level if applicable. It will minimize the risk of exposure when access rules are overlooked or misconfigured;

✅ Automate access rules and integrate them with applicable business processes. A good example would be to integrate an LMS (learning management system) so data can only be accessed by individuals after taking appropriate training;

The Don’t’s

❌ Don’t let your engineering team define and maintain individual access controls. In particular, when you’re dealing with sensitive data, you may want to enforce strict controls before data enters the engineering cycle;

❌ Don’t write your access controls in code. Even though we’re firm believers in a code-first approach, access should be defined by business processes. Code often isn’t the suitable method to interface with business partners;

❌ Don’t replicate access rules across platforms. Any copy imposes additional governance processes and increases risk. Try querying datasets on single platforms instead;

Bart (Immuta) and Joris (Tropos.io) discussed scaling up access controls. In this second episode of the podcast, they discuss processes, build-vs-buy, and the added value of using technology to overlay access control across different data platform technologies.