How to share data applications securely across teams

Summary

• Sharing applications across teams requires separating read permissions (who can use the app) from data access (what rows/columns each user sees).
• Databricks Apps are built on workspace identity and integrate with Unity Catalog, so row-level and column-level access policies enforce themselves without duplicating logic in the application code.
• Use SQL policies and attribute-based access control to ensure that when a user opens a shared application, they automatically see only the data they're authorized to access.
• Fine-grained credential rotation and audit logging (Delta Lake transaction logs + workspace audit trail) give compliance teams visibility into who accessed what, when, and from where.
• Token and API-key scoping (per-application credentials) prevents a compromised app token from leaking data across all organizational data.

How to share data applications securely across teams
Sharing applications across teams without leaking sensitive data is a paradox: you want the application widely available, but the underlying datasets protected. The traditional solution, row-by-row filtering in application code, doesn't scale. It duplicates access-control logic, drifts from the source of truth, and creates audit blind spots. The better approach is to embed data governance directly into the lakehouse and let it enforce security boundaries within the application.

What is data application security?

Data application security is the practice of enforcing access policies at the data layer so that shared applications automatically surface only the data a user is authorized to see. Instead of filtering in application code, you encode policies in the database layer (row-level and column-level access controls, dynamic masking). The application queries the database; the database enforces the policy transparently.

Key capabilities to evaluate

Capability	Why it matters
Row-level access control (RLAC)	Users see only rows that match their role or attribute (e.g., a regional sales app shows only the current user's region's data). Prevents cross-team data leakage.
Column-level access control (CLAC)	Masks or redacts sensitive columns (SSN, salary, email) for users without permission. Prevents over-sharing of PII or confidential metrics.
Dynamic data masking	Redacts values at query time based on the querying user's role (e.g., shows "..." for IP addresses for junior analysts). Simplifies access tiers without duplicating tables.
Attribute-based access control (ABAC)	Policies reference user attributes (department, location, job title) instead of hardcoding user names, making policies reusable and reducing maintenance overhead.
Audit and compliance logging	Logs query execution, data access, and policy changes so compliance teams can prove who accessed what and when. Supports SOC 2, HIPAA, and regulatory audits.
Workspace and application-level credential management	Issues short-lived tokens scoped to specific applications so that a leaked app token doesn't grant access to all organizational data.

How Databricks approaches secure data sharing

Unity Catalog is Databricks' centralized governance layer. You define access policies once (in SQL) and attach them to tables and views in the Lakehouse. When a Databricks App (or any tool querying the lakehouse) accesses the data, Unity Catalog automatically enforces the policies based on the querying user's identity.
Row-level access control in Unity Catalog uses a simple filter expression: when a user queries a table with RLAC enabled, the database adds your filter criteria to the query. For example, a policy might state "WHERE department = current_user().department". The database applies this invisibly, so the app and user see only their department's data.
Column-level masking works similarly: sensitive columns are redacted at query time based on roles. A junior analyst sees masked salary data ("."), while a manager sees actual values. The application doesn't need to know about the masking; the database handles it.
Unity Catalog policies are version-controlled, auditable, and inherited by all downstream consumers (apps, BI tools, notebooks, jobs). This is called "policy as code": your governance lives in the repository alongside your data models, is peer-reviewed, and has an audit trail of every change.
Databricks Apps integrate with Unity Catalog identity. When opened, users authenticate via workspace SSO, the app queries the lakehouse with their identity, and policies apply automatically. For scoped security, create service accounts with credentials specific to each application.

Governance and audit

Unity Catalog maintains an audit trail of every policy change and data access event. Compliance teams can query it to see who accessed what, which policies were applied, when they changed, and access denials. The trail is immutable (stored as Delta Lake transactions).

Use cases

Multi-tenant SaaS: A SaaS app serves dashboards built on shared tables. Row-level policies ensure each customer sees only their own data. New customers require only a policy, not app changes.
Cross-functional insights platform: Sales, marketing, and operations teams use one insights app. Policies ensure sales see customer data, marketing see campaigns, and ops see metrics. One app, no code duplication.
Regulated data lake: Healthcare or finance builds on a shared data lake. Row-level policies scope clinician access; masking redacts PII for audit analysts. Audit logs prove compliance.

FAQs

Can row-level policies impact query performance?

When a policy is applied, the database adds a filter clause. If the filter can be pushed to storage (e.g., "WHERE department = 'sales'"), performance is negligible. Complex policies may add latency, but Databricks optimizes policy evaluation. For most use cases, overhead is minimal.

How do I grant temporary access?

Unity Catalog supports temporary grants with auto-expiry (e.g., 24 hours). Useful for audits or investigations.

What happens if I revoke access from a user mid-session in an app?

Access checks happen at query time. If a user is querying the lakehouse and you revoke their permission, the next query they run will fail with an authorization error. The app can catch this and show the user a friendly "access denied" message. Mid-query revocation doesn't tear down existing connections, but subsequent queries enforce the new policy.

Can I share an app with external partners?

Yes. Databricks supports external sharing via Delta Sharing or managed instances. External users authenticate via their identity provider and see only policy-allowed data.