Secure your Databricks surface
Workspace access, cluster policies allowing arbitrary compute, and notebooks holding credentials. We don’t connect to Databricks to collect evidence for its own sake — we connect to secure it, and the compliance artefacts follow from that work.
Book a Demo[01] What This Surface Exposes
Where Databricks goes wrong
Databricks goes wrong in notebooks: credentials written directly into cells are endemic in analytics environments.
- Notebooks with credentials and tokens written directly into cells
- Cluster policies permitting arbitrary configuration including public networking
- Unity Catalog grants broader than the analysis requires
- Personal access tokens with long or no expiry
- Workspace files and DBFS holding regulated data without classification
[02] What We Secure
What we watch, catch and fix on Databricks
On Databricks we scan notebooks for embedded credentials and review cluster policies as a compute governance control.
- Notebook scanning for embedded credentials, which is endemic in analytics environments
- Cluster policy review as a compute governance control
- Catalog grant scope reduced to actual need
- Token expiry enforced
- Data location classification across catalog and DBFS
[03] Where It Lands
Where Databricks lands in your registers
Every datastore becomes an asset register entry carrying its data classification, encryption state, and retention position. Access reviews cover database roles and grants alongside application access. The risk register maps each store to the specific exposure it represents — a production replica in a development environment is a named risk against a named asset, with an owner and a date.
[04] How We Engage
On Databricks specifically
On Databricks, we remediate embedded credentials and drive rotation, tighten cluster policies, and enforce token expiry. Unity Catalog migration and governance design we project-manage with your data team.
Platform licence
Everything you need to find and fix it yourself, with no ceiling on the depth of the answer.
- Every connected tool monitored for misconfiguration and drift, with findings mapped to the assets and risks they affect
- Remediation guidance that tells you what is wrong and exactly how to fix it — however deep or awkward the issue is. We are engineers running a security company, so the answer is the real one, not a link to vendor documentation
- Assets, access reviews, and risk register populated from the tools themselves rather than from spreadsheets
- Unlimited integrations and unlimited users, with anything missing built within two weeks
Managed service
Every tool you connect through Konfirmity comes under our care, with our team doing the work.
- Continuous misconfiguration and drift monitoring across every connected tool, watched by our analysts rather than by a dashboard waiting for you
- Incident response led by us, with containment coordinated with your team
- Remediation performed directly wherever you have granted us the authority to act — and where we cannot act, we project-manage the fix to completion rather than handing you a ticket
- Decision support on the tools themselves: where something is failing you on capability or costing more than it returns, we will tell you, and help you replace it
[05] Databricks FAQs
What Databricks access does Konfirmity need?
Konfirmity needs a service principal with workspace read access covering clusters, jobs, notebooks and Unity Catalog grants. Notebook access is needed for credential scanning, which we agree with you before enabling.
Why are notebooks such a common problem?
Because they are written for exploration and then quietly become production. A connection string pasted in during analysis stays in the notebook, gets committed, gets shared, and ends up in a scheduled job nobody reviews.
PostgreSQL
MySQL
MongoDB
Snowflake
Google BigQuery