Data teams audit freshness, volume and schema drift without complaint, yet the question of who can reach production tables with write rights often gets a shrug. AccessOps is the working name for the practice of managing how and when elevated access is granted, and it fits naturally beside data quality checks. This article offers an evidence-led audit you can run in a week against a warehouse, an orchestrator and the secrets that connect them. Each step names what to collect, what the result should tell you, and what to do when it does not look right.<\/p>\n
Warehouses and pipelines concentrate risk in unusual ways. A single service account may be allowed to read raw customer extracts, write to curated marts and trigger backfills that overwrite months of history. Analysts accumulate broad grants during one-off investigations and keep them for years. Orchestration tools hold connection strings for every system they touch.<\/p>\n
The glossary-style Atlas carries a reference page on AccessOps<\/a> and is candid that the label is its own editorial choice rather than an official standard, while the habits underneath it are established ones: temporary elevation, vaulting of privileged credentials, emergency accounts, session recording and periodic reviews. That makes it a handy checklist source even when your stack is nothing like the Atlas examples.<\/p>\n Before measuring anything, list every way a human or a job can obtain write or admin rights on the platform. Include the obvious ones, such as warehouse owner roles, and the quiet ones: shared notebook credentials, cloud console roles, scheduler admin users, database superusers used by migration scripts.<\/p>\n The Atlas recommends sorting this inventory into tiers by blast radius, with the most dangerous tier getting the shortest windows. If you do nothing else this week, do this.<\/p>\n Label each privileged grant with its holder, its scope, the stated purpose, an end date and the approving person or rule. Then count the rows with any gap. That percentage is your first piece of evidence. In my experience a first pass often returns more blanks than anyone expects, and the “why” and “until when” columns are usually the emptiest.<\/p>\n Compare what was granted with what was exercised. The Atlas gives a worked example: four hundred four-hour grants in a month hand out 96,000 minutes, while only 24,000 minutes of recorded activity took place, a utilisation of one quarter. It phrases the lesson bluntly: by default you are handing out four times the access the work needed.<\/p>\n For a data platform, pull query history or audit logs for your admin roles and calculate how many of the granted hours contained any privileged action. If utilisation is low, shorten the window; if it is high, the window may be fine and the real question is whether the role is too broad.<\/p>\n The same example found thirty of a hundred and twenty approved requests went unused, again a quarter. Unused approvals suggest requesters ask for access out of habit, or approvers say yes without reading. Review a sample of justifications. If most say some version of “need access for pipeline work,” your approval step is a formality.<\/p>\n A grant reaching its end date on paper does not guarantee the work session ends. In the Atlas lab experiment, a remote login outlived the certificate that opened it by roughly twenty seconds, since the system checked only at sign-in. Some cloud role sessions persist until their own timeout, and a permission change can take minutes to spread, group edits sometimes far longer. Anyone able to edit permissions can also leave a back door that outlives the expiry.<\/p>\n So run a real test. Request a short grant on a non-production warehouse, keep a long-running query or notebook session open past the end time, and observe what happens. Write down the lag. That number belongs in your audit report.<\/p>\n Every platform needs at least one way in when the identity system is down. The Atlas states the usual guardrails: more than one cloud-only account, sign-in that resists phishing, an alert on any use, and a drill at least every ninety days, matching Microsoft’s published expectation. Importantly, these accounts stay permanently enabled by design. A “zero standing privilege” goal never means zero administrators.<\/p>\n Check when the account was last tested, whether the alert fired in the test, and whether the review of its use happened within a business day.<\/p>\n Schedulers and orchestrators are not neutral. They hold credentials for many systems and run unattended. If you are comparing how pipeline tools express data expectations, our hands-on tour of validating data with an expectations framework<\/a> shows how checks gate a pipeline, and the same discipline should gate who can edit those checks. A person who can loosen a validation rule can quietly let bad data through.<\/p>\n The Atlas makes a related point about approval automation: an automated approver deserves the same protection as the most privileged tier, because whoever steers it can mint access. It also warns that infrastructure code applied authoritatively can overwrite carefully assigned bindings in a privileged-access tool. Check that your deployment scripts do not undo your access model each run.<\/p>\n Summarise in a single table: blank fields, utilisation, unused approvals, expiry lag, emergency-account test date, automation findings. Then choose three actions with owners and dates. A sensible thirty, sixty and ninety day arc, again borrowed from the Atlas, goes like this: inventory the top tiers and run an emergency drill; pilot eligibility with a reason and an automatic approval for on-call staff; add dual approval, recording and a daily reconciliation for the most critical tier.<\/p>\nStep 1: Inventory the privileged paths<\/h2>\n
\n
Step 2: Give every grant a five-part label<\/h2>\n
Step 3: Measure how much access is actually used<\/h2>\n
Step 4: Check the “approved but never used” pile<\/h2>\n
Step 5: Test expiry, not just configuration<\/h2>\n
Step 6: Verify the emergency account and rehearse it<\/h2>\n
Step 7: Look at automation as a privileged actor<\/h2>\n
Step 8: Record what you found, then pick three actions<\/h2>\n