Leader track 🔑 · six sessions, no SQL
For whoever approves access, signs the review and answers the auditor. What the three counters are, who decides, and what to report monthly.
Who can see what, and who decided
The three counters that trade against each other: leaks, over-blocks and standing privileges. Why an over-block is not the safe way to fail, and where the data goes instead.
🧩 Leader session 2Roles, attributes, and why role sprawl happens
RBAC against ABAC per NIST SP 800-162, what an attribute policy buys you, and the organisational reason a warehouse ends up with 340 roles and one that everybody uses.
⚖️ Leader session 3Least privilege people can actually work with
Break-glass with an expiry, time-bound elevation, and the friction budget. The access request queue as a design signal rather than an annoyance.
🏷️ Leader session 4Classify, then mask
Three or four classes, not seven. Who gets an exception and why the exception is the whole decision. Free-text columns and the class they really belong in.
🧾 Leader session 5Proof, not promises
What an auditor actually asks for, why a screenshot is not evidence, and how to make an access review something a pipeline produces rather than a quarter of somebody's life.
🗺️ Leader session 6The access operating model
Who approves what, who reviews it, and a 90-day tightening plan that does not stall the business. Plus the three numbers to report monthly.
Builder track 🔧 · eight sessions, one policy set
One table, saltbox.customers at Saltbox, locked down control by control. Session 8 scores the finished set request by request.
Grants from first principles
Securable objects, ownership as a privilege, the six system roles, and the direction privileges inherit. Then the written access design everything else is scored against.
🌳 Builder session 2A role hierarchy that survives a reorg
Functional roles against access roles, the two-layer pattern, and why granting a role to a role is the operation most people get backwards.
🚪 Builder session 3Row-level security
Row access policies, mapping tables, CURRENT_ROLE against IS_ROLE_IN_SESSION, and the limitations worth knowing before you ship one.
🎭 Builder session 4Column security and dynamic masking
Masking policies with exception roles, policy tags, and the evaluation order: the row policy runs first, and a column cannot carry both kinds at once.
🔐 Builder session 5Tokenisation and pseudonymisation
Surrogate keys that keep rows joinable, format-preserving tokens, and the re-identification risk that makes a quasi-identifier as good as a name.
🗝️ Builder session 6Secrets, keys and service accounts
Key rotation, short-lived credentials, and the four places a warehouse password ends up in a repo. Nothing in a dbt profile, ever.
🔍 Builder session 7Access review as a pipeline
Query history against grants, the unused-privilege report, over-grant detection, and evidence an auditor accepts without a meeting.
🎛️ Builder session 8The policy bench
150 requests, five personas, three counters. One ACCOUNTADMIN grant puts 109 leaks and 30 standing privileges straight back.
Choose your path 🗺️
Three doors into the same policy set. Both tracks start at their own session 1, because the written access design is what makes everything after it arguable.
Your passport 🎫
Clear all three quiz questions in a session and it gets stamped. Fourteen stamps across both tracks, and they live in this browser only.
What is real here 🧾
A course about proving who can see what should be exact about its own claims.
| Claim | Status |
|---|---|
| The 150 access requests | Every combination of 5 personas, 10 columns and 3 regions. Of those, 41 legitimately need a value in clear, 3 need it masked and 106 have no business being answered |
| The ground truth | A written access design: per job, which columns are needed in clear, which masked, and which regions the job covers. Visible in the widget, not hidden in an answer key |
| The evaluation | A real policy engine. Row policies are applied before masking policies, column grants come from the role split, masking transforms what the grants allowed. All three counters are counted from what came back |
| The ladder: 109, 94, 70, 22, 3, 0 leaks | Computed in the browser. The step from 70 to 22 is the role split, which also takes standing privileges from 17 to 1 |
| Strip every PII column: 0 leaks, 8 over-blocks | Arithmetic. All 8 are the support agent, across name, email, phone and support_notes in both regions they cover |
| Grant ACCOUNTADMIN: 109 leaks, 30 standing privileges | Arithmetic, and identical to the opening state. The policies are still defined and deployed; a role above the policy layer is not constrained by them |
| Nothing on the bench is modelled | Unlike a simulator, there is no human behaviour to estimate here. Every number is a count of policy outcomes against a written design |
| Snowflake role and policy behaviour | Read from the vendor documentation: the system roles and their purposes, ownership and managed access schemas, primary versus secondary roles with the CREATE exception, and that a row access policy is evaluated before any masking policy on the same object |
| RBAC compared with ABAC | Framed per NIST SP 800-162, which defines ABAC as evaluating attributes of subject, object, operation and environment against policy rather than assigning static roles |
| Saltbox | A fictional consumer lending startup. The failure patterns are ordinary ones; the company is not real |
The knowledge map 🧠
Both tracks at a glance - hover a session to spotlight its concepts, click any node to jump in.