14. Enterprise Security Hardening & Zero Trust Architecture

Learning objective: turn Databricks security controls into an enterprise operating posture: threat-modelled, identity-aware, network-restricted, data-governed, continuously monitored and recoverable.

The earlier Security Model chapter introduced the security building blocks: identity, authentication, authorization, Unity Catalog, compute isolation, cloud IAM, network security, secrets, encryption and audit.

This chapter takes the next step.

It asks how to combine those controls into a real enterprise security architecture, how to test that the controls work, how to prevent data exfiltration, how to detect security incidents and how to respond when a control fails.

The target is not a collection of enabled settings. The target is a verifiable security posture.

Databricks' current security guidance organizes the security and privacy pillar around least-privilege identity, protection of data in transit and at rest, secure networking, compliance/privacy controls and continuous monitoring. This chapter turns those principles into an architecture and implementation method.

Official starting point: https://docs.databricks.com/aws/en/security/

1. Why a second security chapter?

The first security chapter explained the controls.

This chapter explains how an enterprise should operate them together.

Foundational Security Model	Enterprise Hardening
What is SSO?	How do we enforce identity lifecycle and emergency access?
What is Unity Catalog?	How do we prevent cross-workspace and cross-domain exposure?
What is PrivateLink?	What is the complete ingress and egress policy?
What are secrets?	How do we prevent secret leakage and rotate compromised credentials?
What is encryption?	What exactly is covered by each encryption key?
What is an audit log?	How do we detect, investigate and respond to a security event?

The earlier chapter is the component guide.

This chapter is the security architecture, assurance and operating model.

2. The enterprise security objective

A secure platform should be able to answer six questions for every important workload:

Who is requesting access?
From which identity, network and workspace?
Which compute is allowed to execute the workload?
Which data and cloud resources can that workload reach?
Which destinations can data leave for?
Where is the evidence that the request was permitted or denied?

A control is not complete merely because the setting exists.

It must be configured, tested, monitored and assigned to an owner.

3. Animated zero-trust architecture

Animated Databricks zero-trust enterprise security architecture

How to read the architecture: a request passes through identity and ingress checks, isolated compute, Unity Catalog authorization and cloud-resource authorization. Outbound traffic is separately controlled. A denied request enters an incident path. Audit and detection collect evidence across the entire lifecycle.

The most important rule:

Network reachability is not data authorization. Data authorization is not business approval. Each boundary needs its own control.

4. Threat modelling before configuration

Begin with the assets and attack paths, not with a list of product features.

Assets to protect

customer and employee data;
financial and regulatory datasets;
production credentials;
source code and notebooks;
model artifacts and feature data;
cloud storage;
ingestion gateways;
workspace and account configuration;
audit evidence;
deployment pipelines.

Threat sources

compromised human account;
compromised service principal;
malicious or compromised library;
accidental administrator action;
insecure notebook or job code;
misconfigured cloud IAM role;
compromised source system;
data exfiltration through an approved but overly broad network route;
unauthorized access from a development workspace;
leaked credentials in logs or notebook output.

The threat-model output

For each important asset, record:

owner;
data classification;
threat;
trust boundary;
preventive control;
detection signal;
response action;
recovery requirement.

Do not start by assuming that all risk is external. Many serious exposure paths come from excessive legitimate access or unsafe automation.

5. The security boundary model

An enterprise Databricks architecture has multiple boundaries.

CORPORATE IDENTITY
        |
        v
DATABRICKS ACCOUNT
        |
        v
WORKSPACE
        |
        v
COMPUTE
        |
        v
UNITY CATALOG
        |
        v
CLOUD RESOURCE / SOURCE
        |
        v
APPROVED DESTINATION

Every boundary answers a different authorization question.

Boundary	Security question
Identity	Is this human or workload identity trusted?
Account	Is the principal provisioned and assigned correctly?
Workspace	Can this principal reach this environment?
Compute	Can this code execute under the required isolation model?
Data	Is this operation permitted on this governed object?
Cloud	Does the workload have narrowly scoped cloud authorization?
Network	Can this request reach the required endpoint?
Egress	Can the workload send data to this destination?

A single successful check must never be interpreted as permission to bypass the other checks.

6. Zero trust in practical terms

Zero trust means that access is explicitly verified and continuously governed rather than automatically trusted because a user or workload is already inside a network.

For Databricks, translate that into practical controls:

authenticate users through the enterprise identity provider;
enforce MFA through the identity provider;
provision and deprovision identities centrally;
use workload identities for automation;
limit administrative privileges;
use workspace and network restrictions;
authorize data through Unity Catalog;
isolate compute appropriately;
restrict outbound destinations;
audit access and configuration changes;
periodically recertify permissions.

Zero trust does not mean adding a login prompt to every operation.

It means eliminating implicit trust between identities, workspaces, compute, data and network destinations.

7. Identity lifecycle: joiner, mover and leaver

Identity security is a lifecycle problem.

JOINER
  |
  v
IDP ACCOUNT + GROUPS
  |
  v
DATABRICKS PROVISIONING
  |
  v
ROLE-BASED ACCESS
  |
  +------ MOVER: review changed access
  |
  +------ LEAVER: revoke and deprovision

Joiner

create identity in the corporate identity provider;
provision approved groups;
assign the required workspace;
grant role-based access;
verify least privilege.

Mover

remove obsolete groups;
add the new role groups;
re-evaluate production access;
review ownership of jobs, tables and service accounts.

Leaver

disable the corporate identity;
revoke workspace and account access;
remove group membership;
review personal tokens and credentials;
transfer ownership of critical assets;
identify automation that depends on that identity.

Architect rule

A departing employee must not leave behind production jobs, data ownership or long-lived credentials that depend on their personal account.

8. Group-based access and administrative separation

Prefer groups over individual grants.

Example enterprise groups:

platform-security-admins
data-platform-engineers
finance-data-engineers
finance-analysts
customer-data-stewards
production-operators
security-auditors

Separate responsibilities.

Role	Primary responsibility
Account administrator	Account-wide identity and workspace administration
Workspace administrator	Workspace configuration and access
Data owner	Business approval and data access ownership
Platform engineer	Compute and platform operations
Security administrator	Security policy and review
Auditor	Independent evidence and control review
Runtime service principal	Executes a production workload

Databricks security guidance recommends limiting account administrators, restricting workspace admins and enforcing segregation of duties.

Emergency access should exist, but it should be controlled, logged and periodically tested rather than used as a normal operating account.

9. Human identities vs workload identities

Do not use a human identity for unattended production execution.

Human identity

Used for interactive development, exploration and approved operational actions.

Service principal

Used for applications, automation, jobs and controlled machine-to-machine workflows.

Workload identity federation

Allows an external workload to authenticate to Databricks without storing a long-lived Databricks secret.

The identity provider issues a signed identity token. Databricks validates the issuer, audience and subject against a federation policy associated with the service principal.

GITHUB / CLOUD WORKLOAD
          |
          v
SIGNED OIDC TOKEN
          |
          v
DATABRICKS FEDERATION POLICY
          |
          v
SERVICE PRINCIPAL
          |
          v
DATABRICKS API

Databricks strongly recommends workload identity federation for automated workloads when supported.

Official reference: https://docs.databricks.com/aws/en/dev-tools/auth/oauth-federation-policy

10. Federation policy: scope the workload

A federation policy should identify the exact trusted workload.

For GitHub Actions, the policy can constrain:

issuer: GitHub's token issuer;
audience: the expected token audience;
subject: the repository and approved environment.

Example subject pattern:

repo:organization/repository:environment:prod

Do not use a broad subject that allows every repository or branch to authenticate as a production service principal.

Separate identities for development deployment, staging deployment and production deployment when the risk and ownership model justify it.

Important

A valid federated token proves which workload is authenticating.

It does not grant unrestricted Databricks permissions.

The resulting service principal still needs explicit workspace, job, Unity Catalog and cloud-resource permissions.

11. Token and credential hygiene

Treat tokens as credentials, not configuration strings.

Rules:

prefer OAuth and federation over long-lived personal access tokens for automation;
restrict token creation and management;
use short-lived credentials where supported;
rotate secrets when exposure is suspected;
never log token values;
never store secrets in Git;
review service-principal credentials and federation policies;
remove unused tokens and service principals.

A token's existence does not imply that it should have broad workspace access.

Use a narrow identity for each automation boundary.

12. Workspace isolation strategy

A workspace is an important security and operational boundary.

A common enterprise model is:

DATABRICKS ACCOUNT
       |
       +-- DEV WORKSPACE
       |
       +-- STAGING WORKSPACE
       |
       +-- PROD WORKSPACE
       |
       +-- RESTRICTED / REGULATED WORKSPACE

Separate workspaces can isolate:

users and groups;
compute policies;
workspace objects;
network configuration;
operational blast radius;
production credentials;
data access.

Separate catalogs still matter, but they do not by themselves provide the same isolation as separate workspaces.

Do not allow an ordinary development workspace to become a convenient route to restricted production data.

13. Workspace-catalog binding

Unity Catalog catalogs are generally available to workspaces attached to the same metastore unless workspace-catalog bindings restrict them.

A catalog binding can limit a catalog to selected workspaces.

Example:

prod_finance_catalog
       |
       +-- PROD WORKSPACE: ALLOW
       |
       +-- STAGING WORKSPACE: DENY
       |
       +-- DEV WORKSPACE: DENY

A user with a SELECT grant in the production catalog still cannot query it from an unbound workspace.

This is a valuable control for preventing sensitive production data from appearing in development environments.

Workspace binding also applies to external locations and storage credentials, with important object-specific behavior.

Official reference: https://docs.databricks.com/aws/en/data-governance/unity-catalog/access-control/workspace-catalog-binding

14. Storage credential isolation

Storage credentials connect Unity Catalog to cloud storage authorization.

Do not grant broad management rights over storage credentials to ordinary developers.

Databricks recommends granting only CREATE EXTERNAL LOCATION, and no other privileges, on storage credentials where that is sufficient for the intended workflow.

Workspace-bind production storage credentials to the intended production workspaces.

A subtle operational detail: the storage-credential workspace binding is checked when the credential is exercised to create an external location. Once the external location exists, it operates independently of that storage-credential binding. Therefore also govern and bind the external location itself.

Official reference: https://docs.databricks.com/aws/en/connect/unity-catalog/cloud-storage/manage-storage-credentials

15. Compute isolation: Standard vs Dedicated

Compute access mode is part of the security architecture.

Standard

supports multi-user compute;
provides user isolation;
is recommended for most general workloads;
simplifies shared compute management.

Dedicated

assigns compute to a specific user or group;
is useful for specialized workloads that need capabilities not supported on Standard;
creates a different compute ownership and access model.

Databricks recommends Standard compute for most workloads. Dedicated should be chosen when a documented technical requirement justifies it.

Do not select Dedicated merely because it sounds more secure. Select the access mode that provides the correct isolation and capability model for the workload.

Official reference: https://docs.databricks.com/aws/en/compute/standard-overview

16. Compute policies and privileged operations

Restrict who can create arbitrary compute.

Use compute policies to standardize:

allowed node types;
autoscaling limits;
runtime versions;
access modes;
security configuration;
logging settings;
library installation;
approved init scripts;
cost controls.

Avoid giving broad permission to create unrestricted compute.

Privileged machine access, custom init scripts and arbitrary libraries increase the attack surface.

Use the smallest capability set that allows the workload to run.

17. Notebook, library and code supply-chain security

A notebook is executable code.

Treat it as a software artifact.

Controls should include:

trusted Git repositories;
branch protection and code review;
dependency pinning;
vulnerability scanning;
library allowlists;
controlled init scripts;
restricted production editing;
separation of developer and runtime identities;
release traceability.

A malicious or compromised library can execute inside a trusted workload.

Security reviews must cover the code and dependencies, not only the workspace permissions.

18. Data exfiltration: define the threat

Data exfiltration is the unauthorized transfer of sensitive data out of the governed environment.

Possible paths include:

writing to a public storage bucket;
copying data to an unapproved cloud account;
calling an external API;
downloading query results;
using a compromised service principal;
writing to a personal cloud location;
exporting data from a notebook;
allowing excessive outbound network destinations.

No single firewall or table grant is enough.

Databricks describes data-exfiltration protection as a defense-in-depth approach combining network controls and Unity Catalog governance.

Official reference: https://docs.databricks.com/aws/en/security/network/data-exfiltration-protection

19. Defense in depth for exfiltration

Use multiple independent layers.

IDENTITY
  |
  v
WORKSPACE BOUNDARY
  |
  v
COMPUTE ISOLATION
  |
  v
UNITY CATALOG AUTHORIZATION
  |
  v
CLOUD STORAGE IAM
  |
  v
NETWORK EGRESS CONTROL
  |
  v
AUDIT + DETECTION

Network controls

private network deployment;
PrivateLink where required;
controlled outbound access;
firewall or proxy inspection;
serverless egress policies;
storage endpoint restrictions.

Data governance controls

least-privilege grants;
ABAC;
row filters;
column masks;
workspace-catalog bindings;
external-location restrictions;
audit logging.

Network controls restrict where a workload can connect.

Unity Catalog controls restrict what a permitted workload can access and do with governed data.

Both are needed.

20. Ingress vs egress: never confuse them

Ingress

Controls who can reach Databricks.

Examples:

corporate identity;
approved IP range;
registered private endpoint;
request type;
workspace UI or API access.

Egress

Controls where Databricks workloads can connect.

Examples:

approved SaaS API;
approved cloud storage;
internal database;
external service endpoint.

USER / CI
    |
    | INGRESS
    v
DATABRICKS
    |
    | EGRESS
    v
APPROVED DESTINATION

A workspace can have strong inbound PrivateLink and still allow excessive outbound traffic.

That is why ingress and egress need separate policies.

21. Context-based ingress policies

Current Databricks context-based ingress controls can combine conditions such as:

identity;
network source;
request type.

This is more expressive than an IP-only allowlist.

For example:

ALLOW
  identity = approved CI service principal
  source = trusted network
  request = workspace API
  destination = production workspace

A second policy can allow human users from the corporate network to access the workspace UI.

Databricks recommends context-based ingress as the primary method for centrally managing access. Workspace IP access lists can provide an additional restriction and are enforced together with context-based policies.

Official references:

22. PrivateLink: inbound and outbound

PrivateLink is not one single direction.

Inbound PrivateLink

Allows users and clients to reach Databricks workspace endpoints through private network connectivity rather than public internet access.

Outbound PrivateLink

Allows supported Databricks workloads to reach supported customer services through private endpoints.

Both require correct:

VPC endpoints;
DNS;
routing;
security groups;
endpoint registration;
workspace policy;
firewall rules.

Do not enable an inbound-only private connectivity design and assume all outbound traffic is private.

Official reference: https://docs.databricks.com/aws/en/security/network/front-end/front-end-private-connect

23. Classic compute networking

For classic compute on AWS, the architecture includes customer-cloud networking.

A typical hardened design includes:

CUSTOMER AWS ACCOUNT
       |
       v
CUSTOMER-MANAGED VPC
       |
       +-- PRIVATE SUBNETS
       |
       +-- SECURITY GROUPS
       |
       +-- ROUTES / NAT / ENDPOINTS
       |
       +-- SECURE CLUSTER CONNECTIVITY
       |
       +-- PRIVATE CONNECTIVITY TO SERVICES

Important controls:

private subnets across multiple Availability Zones;
carefully scoped security groups;
controlled outbound internet;
Secure Cluster Connectivity;
PrivateLink for required Databricks endpoints;
network segmentation between environments;
VPN or Direct Connect for on-premises sources where required.

The exact network design is cloud-region and workspace-architecture dependent.

Do not copy a CIDR, route or firewall template from another organization without reviewing address space, endpoint requirements and Databricks deployment architecture.

24. Serverless networking

Serverless compute is not inside the customer-managed classic-compute VPC.

Do not assume that a classic VPC firewall automatically governs serverless egress.

Databricks provides serverless network security controls, including network policies that govern outbound connections from serverless workloads.

A serverless policy can control approved:

internet destinations;
cloud storage locations;
Databricks API connections.

Serverless egress control can support a deny-by-default posture for supported traffic types.

Official reference: https://docs.databricks.com/aws/en/security/network/serverless-network-security/network-policies

25. Egress allowlists and destination governance

Create an explicit destination inventory.

Destination	Business purpose	Owner	Required ports	Environment
Salesforce API	CRM ingestion	CRM team	HTTPS	PROD
S3 landing bucket	Data exchange	Data platform	HTTPS	PROD
Internal PostgreSQL	Operational source	DB team	Approved DB port	PROD
Package repository	Dependency retrieval	Platform team	HTTPS	DEV / CI

For each entry, document:

hostname or cloud resource;
purpose;
data sensitivity;
identity;
environment;
owner;
allowed network path;
renewal/review date.

Do not use broad wildcard egress rules merely to make a pipeline succeed.

Start with the smallest required destination list and expand only with a documented approval.

26. DNS, TLS and endpoint validation

A private endpoint is useful only if clients resolve the correct endpoint.

Validate:

public vs private DNS response;
endpoint hostname;
certificate chain;
TLS version;
DNS forwarding;
route reachability;
firewall behavior;
connection from the actual compute plane.

For inbound PrivateLink, the workspace-specific URL must resolve through the expected private endpoint. The custom workspace URL must also be configured if users access that URL.

Test from the client network and from the relevant compute environment.

Do not treat a successful browser connection as proof that a cluster, serverless job or ingestion gateway has the same network route.

27. Cloud IAM: keep the trust chain narrow

For AWS storage access, use Unity Catalog storage credentials backed by the approved IAM role model.

Conceptually:

DATABRICKS WORKLOAD
       |
       v
UNITY CATALOG STORAGE CREDENTIAL
       |
       v
AWS IAM ROLE
       |
       v
S3 BUCKET POLICY
       |
       v
APPROVED PREFIX

Use:

restricted trust relationships;
least-privilege role permissions;
approved external IDs or identity conditions as required by the integration;
resource-level bucket policies;
separate roles for separate data domains;
no embedded long-lived access keys.

A role that can read every S3 bucket is not a reasonable default for a pipeline that needs one data prefix.

28. Secrets: understand the exposure model

Secrets are not automatically invisible to every administrator.

Databricks documents that workspace admins, secret creators and users granted permission can access and read secrets. Output redaction is useful, but it cannot fully prevent authorized users from viewing secret contents.

Therefore:

align scopes with applications or roles;
grant READ, WRITE and MANAGE carefully;
do not give all workspace users access to every secret;
do not print secrets for troubleshooting;
do not embed secret values in Spark configuration or logs without understanding their exposure;
rotate compromised secrets;
prefer governed identity and federation where possible.

Official reference: https://docs.databricks.com/aws/en/security/secrets

29. Workspace secret scopes vs Unity Catalog secrets

Databricks supports multiple secret-management choices.

Option	Typical scope	Use case
Workspace secret scope	One workspace	Existing workspace-level secret usage
Unity Catalog secret	Metastore-governed securable	Centralized secret governance across attached workspaces
External secret manager integration	Cloud/provider secret store	Organization-managed secret lifecycle and rotation

Unity Catalog secrets can be managed by Databricks or backed by supported external secret providers, depending on the current feature and release status.

Do not assume that every secret type or external provider has identical support or GA status.

Verify the exact source, region and feature state before choosing the integration.

Official reference: https://docs.databricks.com/aws/en/security/secrets/unity-catalog-secrets

30. Credential rotation and revocation

Create a rotation plan for:

SaaS API tokens;
database credentials;
OAuth client secrets;
service-principal credentials;
cloud IAM trust relationships;
external integration credentials;
signing keys.

A rotation runbook should define:

who owns the credential;
how a replacement is created;
how consumers are updated;
how overlap is handled;
how the old credential is revoked;
how successful use is verified;
how rollback works if rotation fails.

A credential that is never rotated or reviewed eventually becomes an unknown dependency.

31. Encryption at rest: know the data surface

Encryption at rest can apply to different storage surfaces.

Do not assume that one customer-managed key automatically encrypts every object used by Databricks.

For AWS, distinguish:

Managed-services data

Databricks-managed control-plane data such as notebook source, certain notebook results, secrets and query metadata can have managed-services encryption controls.

Workspace storage

The customer's workspace S3 storage can use a customer-managed key where supported.

Customer cloud storage

Customer-managed S3 buckets can use S3 server-side encryption with AWS KMS keys.

Compute storage

Cluster EBS volumes have their own storage encryption configuration.

Each surface has its own configuration, key scope and lifecycle.

Official reference: https://docs.databricks.com/aws/en/security/keys

32. Customer-managed keys: scope and lifecycle

Before enabling a customer-managed key, document:

which data surface it protects;
which AWS account owns the key;
key policy;
service role permissions;
key rotation policy;
key disablement procedure;
recovery process;
regional and disaster-recovery dependencies;
impact on already stored data.

Do not treat key configuration as a simple checkbox.

If a key is disabled, deleted or made inaccessible, systems relying on it may no longer be able to decrypt the protected data.

Test key lifecycle and emergency access before production rollout.

Also verify the required Databricks plan and feature availability.

33. Encryption in transit

Secure transport applies to multiple connections:

browser to Databricks;
client to API;
control plane to compute plane;
compute to cloud storage;
compute to databases;
worker-to-worker traffic;
serverless to approved external services.

Use TLS for service connections and validate certificate trust.

Do not assume all internal worker-to-worker traffic has the same encryption behavior as browser-to-service traffic. Databricks documents additional configuration for encrypting traffic between classic cluster worker nodes when required.

Official reference: https://docs.databricks.com/aws/en/security/keys

34. Data classification and minimization

Classify data before choosing its security architecture.

Example classification:

Level	Example	Security posture
Public	Approved public reference data	Broad access, integrity controls
Internal	Operational metrics	Group-based access
Confidential	Commercial and employee data	Restricted access, monitored use
Restricted	Highly sensitive PII, financial or regulated records	Dedicated controls, strict access, egress restrictions

Apply:

data minimization;
tokenization or masking;
retention controls;
approved processing regions;
least-privilege access;
purpose limitation;
data-owner approval.

Do not copy an entire source table when the workload needs only a subset of attributes.

35. Fine-grained policies and data boundaries

Use the right Unity Catalog control for the requirement.

Requirement	Suitable mechanism
Baseline object access	Privileges and ownership
Centralized tag-driven policy	ABAC
Per-table row restriction	Row filter
Per-column masking	Column mask
Workspace isolation	Workspace binding
Cloud storage access	Storage credential and external location
Sensitive classification	Governed tags and classification

Databricks recommends ABAC for centralized access policies based on governed tags. Use row filters and column masks for table-specific logic or where ABAC is not adopted.

Official reference: https://docs.databricks.com/aws/en/data-governance/unity-catalog/access-control/

36. Sensitive data in query results and logs

A table can be governed and still leak sensitive information through operational surfaces.

Review:

notebook outputs;
SQL query results;
query history;
job logs;
exception messages;
Spark event logs;
driver logs;
export files;
audit logs;
screenshots and support bundles.

Never use raw personal data as a debugging shortcut.

Mask or tokenize diagnostic samples.

Set retention and access policy for logs as carefully as for the source data.

37. Audit architecture

A security program needs evidence.

Databricks provides audit events and system tables that can be used to investigate platform activity.

The audit log system table is:

system.access.audit

It can be used to inspect activities such as:

authentication events;
workspace and job changes;
permission updates;
cluster configuration changes;
Unity Catalog access and policy changes;
account-level administrative actions.

The current audit-log system table is documented as Public Preview. Verify the feature state and coverage for your workspace and cloud.

Databricks also cautions that audit and system-table data can contain sensitive operational information. Restrict access to the audit datasets and avoid exporting them unnecessarily.

Official references:

38. Example: investigate security events

A basic investigation query:

SELECT
    event_time,
    user_identity.email,
    service_name,
    action_name,
    source_ip_address,
    request_params
FROM system.access.audit
WHERE event_time >= current_timestamp() - INTERVAL 7 DAYS
ORDER BY event_time DESC;

This is a starting point. Check the current schema and available columns for the region and event type before productionizing the query.

Example detection use cases

unexpected administrator activity;
new or modified service principals;
unexpected permission grants;
changes to compute policies;
repeated failed authentication;
unusual job or cluster modifications;
suspicious storage credential changes;
unexpected access from a new network source.

A detection rule should include a severity, owner, response action and false-positive review.

39. Network audit tables

Context-based network controls provide separate evidence for inbound and outbound traffic.

Examples:

system.access.inbound_network
system.access.outbound_network

Use these tables to investigate policy evaluation and network access events.

Do not confuse them with the broader audit log. They answer a more specific question about network policy behavior.

Databricks documents these tables as the audit source for context-based ingress and serverless egress policies.

Official reference: https://docs.databricks.com/aws/en/security/network/context-based-policies

40. Detection engineering

Create detections around meaningful risk.

Signal	Example detection
Identity	Login from unusual source or unexpected identity
Admin	Account-admin or workspace-admin changes
Access	Broad new grants on restricted catalog
Network	New outbound destination or denied egress spike
Compute	New unrestricted compute or privileged configuration
Secrets	Secret-scope permission change
Cloud	Storage credential or role trust change
Data	Unexpected bulk read or unusual export pattern
CI/CD	Production deployment from an unapproved environment

A single signal is rarely enough to declare a compromise.

Correlate identity, source, time, workload, data object and business context.

41. Centralized monitoring and evidence

A mature security operations model combines:

Databricks audit events;
Unity Catalog lineage;
system tables;
cloud provider logs;
identity-provider sign-in events;
network firewall logs;
endpoint security events;
CI/CD deployment logs;
incident-management tickets.

This allows investigators to connect:

WHO
  |
  v
AUTHENTICATED FROM WHERE
  |
  v
WHICH WORKLOAD RAN
  |
  v
WHICH DATA WAS ACCESSED
  |
  v
WHICH DESTINATION WAS REACHED
  |
  v
WHAT CHANGE OR RESULT OCCURRED

Access to centralized evidence must itself be controlled.

42. Incident response: first 30 minutes

When a credible security event is detected, avoid random permission changes.

Use a structured response:

1. Triage

identify the affected identity;
identify the workspace and cloud account;
determine the affected data classification;
identify the suspected access path;
estimate business impact.

2. Contain

Depending on the incident:

disable or restrict a compromised service principal;
revoke or rotate exposed credentials;
remove unnecessary permissions;
stop affected workloads;
restrict network paths;
isolate affected data products.

3. Preserve evidence

capture relevant audit records;
preserve deployment and job logs;
record timestamps and resource identifiers;
preserve cloud and identity-provider evidence;
document every response action.

4. Recover

restore trusted configuration;
redeploy reviewed code;
rotate affected credentials;
reprocess or reconcile affected data;
verify that the unauthorized path is closed.

43. Incident scenario: compromised service principal

Suppose an attacker obtains a service-principal credential.

Potential impact:

running jobs;
querying governed tables;
writing to external locations;
accessing connected services;
modifying supported workspace resources if the principal has deployment rights.

Response sequence:

SUSPECTED COMPROMISE
        |
        v
IDENTIFY PRINCIPAL + SCOPE
        |
        v
REVOKE / DISABLE CREDENTIAL
        |
        v
REVIEW AUDIT + RUN HISTORY
        |
        v
CHECK DATA ACCESS + EGRESS
        |
        v
ROTATE DEPENDENCIES
        |
        v
RESTORE LEAST PRIVILEGE
        |
        v
VALIDATE + MONITOR

Do not merely rotate one credential and assume the incident is over.

Investigate every resource and downstream system the principal could reach.

44. Incident scenario: suspicious data export

Suppose an analyst's job writes restricted customer data to an unapproved S3 location.

Investigate:

which job or notebook performed the write;
which identity executed the workload;
which data objects were read;
which storage credential was used;
which external location or path was targeted;
which network policy allowed the connection;
whether the object was publicly accessible;
whether the data was accessed or downloaded;
whether downstream copies exist.

Contain both the network route and the underlying data authorization.

Do not rely only on deleting the copied file. Determine whether any other copies or credentials remain.

45. Security configuration drift

Security posture degrades when workspace and cloud settings change outside the approved process.

Examples:

a firewall rule is broadened;
a production catalog binding is removed;
a service principal receives excess permission;
an IP allowlist is bypassed by another ingress path;
a serverless egress policy is changed;
a secret scope is granted to all workspace users.

Use infrastructure as code and source-controlled configuration where supported.

Review and detect drift across:

account settings;
workspace configuration;
Unity Catalog grants and bindings;
network policies;
cloud IAM;
storage bucket policies;
CI/CD federation policies.

Emergency changes should be documented and reconciled back into the approved configuration.

46. Compliance: understand shared responsibility

A platform feature or compliance report does not automatically make a customer workload compliant.

The organization still owns:

data classification;
user provisioning;
access approval;
workload design;
retention;
lawful processing;
cloud account controls;
network architecture;
incident response;
evidence collection;
vendor and processor obligations.

Map each regulatory requirement to:

a technical control;
an owner;
a test;
an evidence source;
a review frequency.

The Databricks shared-responsibility model and current compliance scope should be reviewed with the organization's security and legal teams.

Official reference: https://www.databricks.com/trust

47. Three enterprise hardening patterns

Pattern A — Standard enterprise workspace

Appropriate for general data engineering with regulated identity and governance requirements.

enterprise SSO and MFA;
automated provisioning;
service principals;
Unity Catalog;
Standard compute where supported;
restricted compute creation;
audit and system-table monitoring;
baseline network restrictions.

Pattern B — Hardened production workspace

For sensitive operational and financial workloads.

Add:

separate production workspace;
restricted workspace-catalog bindings;
customer-managed VPC where justified;
PrivateLink;
explicit egress policy;
restricted storage credentials;
service-principal-only production execution;
stronger detection and approval workflows.

Pattern C — Isolated or highly restricted environment

For workloads with stringent network and data-transfer requirements.

Add, where supported and justified:

inbound private connectivity;
no public access after validation;
tightly controlled serverless egress;
firewall/proxy inspection;
isolated cloud accounts or networks;
strict workspace and catalog separation;
formal incident and recovery runbooks.

The right pattern depends on source integration, workspace architecture, required features, cost and regulatory obligations.

48. Enterprise security control matrix

Use a matrix to ensure every control has an owner and evidence.

Control area	Preventive control	Detective evidence	Owner
Identity	SSO, MFA, SCIM	IdP and Databricks audit	IAM team
Workload identity	Service principal, federation	Token/federation events	Platform team
Workspace	Restricted assignment	Workspace access events	Platform team
Compute	Access mode and compute policy	Compute configuration history	Platform team
Data	Unity Catalog grants / ABAC	Audit, lineage and access reviews	Data owner
Cloud storage	IAM role and bucket policy	CloudTrail / storage logs	Cloud team
Network	PrivateLink, ingress/egress	Network policy logs	Network team
Secrets	Secret ACLs and rotation	Secret permission changes	Application owner
Encryption	KMS and key policy	Key administration logs	Security / cloud
CI/CD	Protected environments and OIDC	Release logs and approvals	DevOps
Incident response	Approved runbook	Ticket and evidence trail	Security operations

A control without a clear owner is likely to become a control gap.

49. Hands-on lab — build a security baseline

In a non-production workspace:

Review account administrators.
Verify SSO and MFA enforcement.
Review identity provisioning and groups.
Inventory users and service principals.
Identify personal tokens and legacy credentials.
Review workspace access and admin rights.
Inspect compute access modes and policies.
Review Unity Catalog grants.
Review workspace-catalog bindings.
Review external locations and storage credentials.
Inventory secret scopes and permissions.
Inspect network ingress and egress policies.
Confirm audit and system-table availability.
Record gaps, owners and remediation dates.

Deliverable: an approved security baseline with evidence.

50. Hands-on lab — test workspace isolation

Create a non-production Dev and Prod workspace pattern.

Test:

Bind a restricted catalog to Prod only.
Grant a test group SELECT on a table.
Query the table from Prod.
Attempt the same query from Dev.
Confirm that workspace binding prevents access from the unbound workspace.
Review the relevant access and audit evidence.

The learning objective is to prove that a valid table grant does not override the workspace boundary.

Do not run this test against real restricted production data without authorization.

51. Hands-on lab — test egress restrictions

In a test environment:

Inventory required external destinations.
Define a narrow allowlist.
Enable the policy in a test workspace.
Test approved endpoints.
Test an intentionally unapproved endpoint.
Review allow/deny evidence.
Verify that the policy did not block required platform or source connectivity.
Promote only after integration tests pass.

Use dry-run capabilities where available before enforcement.

Do not apply a default-deny policy to production without understanding required service endpoints and recovery access.

52. Hands-on lab — audit investigation

Use the audit system table where enabled.

Example:

SELECT
    event_time,
    user_identity.email,
    service_name,
    action_name,
    source_ip_address
FROM system.access.audit
WHERE event_time >= current_timestamp() - INTERVAL 1 DAY
ORDER BY event_time DESC;

Investigate a controlled test such as:

creating a job;
changing a permission;
modifying a compute resource;
changing a catalog grant.

Record:

who performed the action;
when it occurred;
which workspace or account it affected;
which service and action were logged;
how the event maps to the security control.

53. Hands-on lab — service-principal compromise drill

In a test environment:

Create a dedicated test service principal.
Grant it access to one test catalog.
Use it for a test workload.
Simulate a suspected credential exposure.
Disable or revoke the affected credential.
Inspect audit and run history.
rotate the credential or federation configuration;
verify the old credential no longer works;
confirm no unrelated production identity was affected.

Deliverable: an incident runbook and evidence timeline.

54. Hands-on lab — encryption and key scope

Create a design document for a sensitive workspace.

Map each data surface:

control-plane managed-services data;
workspace S3 storage;
customer-managed S3 data;
cluster EBS;
Databricks SQL query and history data;
secrets;
log and audit storage.

For each surface record:

default encryption behavior;
customer-managed key support;
key owner;
key policy;
rotation;
backup and recovery;
feature-plan requirement;
operational failure impact.

Do not assume that a single CMK covers all these surfaces.

55. Enterprise architect exercise

Design a secure Databricks environment for a bank with:

customer PII;
payment transaction data;
finance reporting;
fraud detection;
data science workspaces;
external SaaS ingestion;
on-premises operational systems;
3 cloud accounts;
4 workspaces;
CI/CD automation;
a 24x7 operations team.

Requirements:

no public access to the restricted production workspace;
only approved identities can deploy;
finance data cannot be accessed from ordinary development;
serverless workloads can reach only approved external destinations;
production jobs cannot depend on human identities;
all administrative and data-access events must be investigable;
compromised credentials must be quickly revoked;
cloud storage must be protected by least-privilege roles;
key ownership and recovery must be documented.

Answer:

How many workspace boundaries are required?
Which identities are human and which are workloads?
How is SSO and identity provisioning configured?
Which service principals are separate?
How are federation policies scoped?
Which catalogs are bound to which workspaces?
How are ABAC and column masks used?
What compute access modes are permitted?
Which VPCs and endpoints are required?
What is the inbound PrivateLink design?
What is the outbound egress design?
How are source systems reached?
Which AWS IAM roles are used?
How are external locations restricted?
Which data surfaces use customer-managed keys?
How are secrets managed and rotated?
What is audited?
How are suspicious exports detected?
What is the first 30-minute incident response?
How is business continuity tested?

Defend each design choice with a threat, a control, a test and an owner.

56. Troubleshooting matrix

Symptom	Security layer to inspect
User cannot log in	IdP, SSO, MFA, federation
API authentication fails	OAuth configuration, token issuer, audience, subject
User reaches workspace but cannot run notebook	Workspace entitlements and object ACL
Notebook runs but table query is denied	Unity Catalog grants, bindings, ABAC, row filters
Job works as developer but not in production	Runtime identity, job permissions, data grants
S3 access fails	Storage credential, role trust, bucket policy, KMS
Cluster fails to launch after IP policy change	Compute-to-control-plane route and allowlist
User UI private endpoint works but source API fails	Egress route, DNS, firewall, source allowlist
Serverless cannot reach endpoint	Serverless egress policy and endpoint support
Secret is visible in logs	Secret handling, output redaction assumptions, log access
Production data visible in Dev	Workspace-catalog binding and external-location boundary
Audit investigation is incomplete	Event coverage, region, system-table enablement, retention

Troubleshoot the boundary that rejected the request. Do not solve every access issue by granting broader permissions.

57. Production security review checklist

Identity

SSO is enforced.
MFA is enforced at the IdP.
Automated identity provisioning is enabled.
Admin count is restricted.
Emergency access is tested.
Groups are the primary access unit.
Service principals are used for automation.
Federation policies are narrowly scoped.
Unused tokens and credentials are removed.

Workspace and compute

Development and production are isolated appropriately.
Restricted catalogs are workspace-bound.
Compute policies restrict unsafe configurations.
Standard access mode is used where suitable.
Dedicated compute has a documented reason.
Production execution uses runtime service principals.
Code and dependency sources are trusted.

Data and cloud

Unity Catalog grants follow least privilege.
ABAC or table-level filters are applied as required.
External locations are scoped.
Storage credentials are restricted.
Cloud roles have least-privilege policies.
Public storage access is blocked.
Sensitive data is classified and minimized.

Network

Ingress is identity- and network-aware.
PrivateLink is used where required.
DNS and endpoint routes are tested.
Classic compute network paths are controlled.
Serverless egress is governed.
Unapproved outbound destinations are denied.
Network policy changes are reviewed.

Secrets and encryption

Secrets are not stored in Git or notebooks.
Secret scopes and UC secret permissions are reviewed.
Rotation ownership is documented.
Encryption surfaces are inventoried.
CMK key policies and lifecycle are tested.
Recovery access to encryption keys is documented.

Monitoring and response

Audit system tables are available and protected.
Network policy events are monitored.
Identity and privilege changes are detected.
Exfiltration scenarios are tested.
Incident runbooks exist.
Evidence preservation is tested.
Security reviews are periodic.

58. Interview questions

Fundamentals and threat modelling

What is the difference between a security model and a security posture?
What does zero trust mean for a data platform?
What are the major trust boundaries in Databricks?
How do you threat-model a lakehouse workload?
Why is network reachability not the same as data authorization?

Identity and authorization

How do you design joiner-mover-leaver automation?
Why should production jobs use service principals?
How does workload identity federation work?
How do you scope a GitHub OIDC federation policy?
How do workspace-catalog bindings improve isolation?

Network and exfiltration

Explain ingress vs egress.
What is the difference between inbound and outbound PrivateLink?
How does serverless egress control differ from classic VPC security?
How would you design a deny-by-default outbound posture?
Why are network controls alone insufficient for exfiltration prevention?

Secrets, keys and data

Who can read Databricks secrets?
What is the difference between workspace secret scopes and Unity Catalog secrets?
What does a customer-managed key protect?
Why must managed-services and workspace-storage encryption be considered separately?
How do you restrict an AWS storage credential?

Monitoring and response

Which system tables support security investigations?
How do you detect unusual access or permission changes?
How would you investigate a compromised service principal?
How would you investigate a suspicious S3 export?
How do you preserve audit evidence?

Architect

Design a zero-trust multi-workspace Databricks environment.
How do you protect serverless and classic workloads consistently?
How do you prevent development workspaces from reaching restricted production data?
How do you design security controls without breaking ingestion integrations?
How do you prove the security posture is effective rather than merely configured?

59. The enterprise security mental model

For every workload, trace the complete path:

WHO IS THE PRINCIPAL?
          |
          v
IS THE IDENTITY TRUSTED?
          |
          v
IS THE WORKSPACE ACCESS ALLOWED?
          |
          v
IS THE COMPUTE ISOLATED?
          |
          v
IS THE DATA ACCESS AUTHORIZED?
          |
          v
IS THE CLOUD RESOURCE ACCESS SCOPED?
          |
          v
IS THE NETWORK DESTINATION APPROVED?
          |
          v
IS THE ACTION AUDITED?
          |
          v
CAN WE CONTAIN AND RECOVER?

A mature security program proves all of these layers work together.

60. Final enterprise takeaway

Enterprise Databricks security is not achieved by enabling SSO, creating a Unity Catalog metastore or putting a firewall around a VPC.

It requires an ongoing operating model that combines:

identity lifecycle;
least privilege;
workload federation;
workspace and compute isolation;
data governance;
cloud IAM;
network ingress and egress;
secret and key management;
data-exfiltration prevention;
audit and detection;
incident response;
continuous configuration review.

Architect principle: Every access path must have an explicit identity, an authorized purpose, a constrained destination, an accountable owner and observable evidence. If the organization cannot explain and test the complete path, the security control is not yet production-ready.

1. Why a second security chapter?​

2. The enterprise security objective​

3. Animated zero-trust architecture​

4. Threat modelling before configuration​

Assets to protect​

Threat sources​

The threat-model output​

5. The security boundary model​

6. Zero trust in practical terms​

7. Identity lifecycle: joiner, mover and leaver​

Joiner​

Mover​

Leaver​

Architect rule​

8. Group-based access and administrative separation​

9. Human identities vs workload identities​

Human identity​

Service principal​

Workload identity federation​

10. Federation policy: scope the workload​

Important​

11. Token and credential hygiene​

12. Workspace isolation strategy​

13. Workspace-catalog binding​

14. Storage credential isolation​

15. Compute isolation: Standard vs Dedicated​

Standard​

Dedicated​

16. Compute policies and privileged operations​

17. Notebook, library and code supply-chain security​

18. Data exfiltration: define the threat​

19. Defense in depth for exfiltration​

Network controls​

Data governance controls​

20. Ingress vs egress: never confuse them​

Ingress​

Egress​

21. Context-based ingress policies​

22. PrivateLink: inbound and outbound​

Inbound PrivateLink​

Outbound PrivateLink​

23. Classic compute networking​

24. Serverless networking​

25. Egress allowlists and destination governance​

26. DNS, TLS and endpoint validation​

27. Cloud IAM: keep the trust chain narrow​

28. Secrets: understand the exposure model​

29. Workspace secret scopes vs Unity Catalog secrets​

30. Credential rotation and revocation​

31. Encryption at rest: know the data surface​

Managed-services data​

Workspace storage​

Customer cloud storage​

Compute storage​

32. Customer-managed keys: scope and lifecycle​

33. Encryption in transit​

34. Data classification and minimization​

35. Fine-grained policies and data boundaries​

36. Sensitive data in query results and logs​

37. Audit architecture​

38. Example: investigate security events​

Example detection use cases​

39. Network audit tables​

40. Detection engineering​

41. Centralized monitoring and evidence​

42. Incident response: first 30 minutes​

1. Triage​

2. Contain​

3. Preserve evidence​

4. Recover​

43. Incident scenario: compromised service principal​

44. Incident scenario: suspicious data export​

45. Security configuration drift​

46. Compliance: understand shared responsibility​

47. Three enterprise hardening patterns​

Pattern A — Standard enterprise workspace​

Pattern B — Hardened production workspace​

Pattern C — Isolated or highly restricted environment​

48. Enterprise security control matrix​

49. Hands-on lab — build a security baseline​

1. Why a second security chapter?

2. The enterprise security objective

3. Animated zero-trust architecture

4. Threat modelling before configuration

Assets to protect

Threat sources

The threat-model output

5. The security boundary model

6. Zero trust in practical terms

7. Identity lifecycle: joiner, mover and leaver

Joiner

Mover

Leaver

Architect rule

8. Group-based access and administrative separation

9. Human identities vs workload identities

Human identity

Service principal

Workload identity federation

10. Federation policy: scope the workload

Important

11. Token and credential hygiene

12. Workspace isolation strategy

13. Workspace-catalog binding

14. Storage credential isolation

15. Compute isolation: Standard vs Dedicated

Standard

Dedicated

16. Compute policies and privileged operations

17. Notebook, library and code supply-chain security

18. Data exfiltration: define the threat

19. Defense in depth for exfiltration

Network controls

Data governance controls

20. Ingress vs egress: never confuse them

Ingress

Egress

21. Context-based ingress policies

22. PrivateLink: inbound and outbound

Inbound PrivateLink

Outbound PrivateLink

23. Classic compute networking

24. Serverless networking

25. Egress allowlists and destination governance

26. DNS, TLS and endpoint validation

27. Cloud IAM: keep the trust chain narrow

28. Secrets: understand the exposure model

29. Workspace secret scopes vs Unity Catalog secrets

30. Credential rotation and revocation

31. Encryption at rest: know the data surface

Managed-services data

Workspace storage

Customer cloud storage

Compute storage

32. Customer-managed keys: scope and lifecycle

33. Encryption in transit

34. Data classification and minimization

35. Fine-grained policies and data boundaries

36. Sensitive data in query results and logs

37. Audit architecture

38. Example: investigate security events

Example detection use cases

39. Network audit tables

40. Detection engineering

41. Centralized monitoring and evidence

42. Incident response: first 30 minutes

1. Triage

2. Contain

3. Preserve evidence

4. Recover

43. Incident scenario: compromised service principal

44. Incident scenario: suspicious data export

45. Security configuration drift

46. Compliance: understand shared responsibility

47. Three enterprise hardening patterns

Pattern A — Standard enterprise workspace

Pattern B — Hardened production workspace

Pattern C — Isolated or highly restricted environment

48. Enterprise security control matrix

49. Hands-on lab — build a security baseline