Skip to main content

Data Access Control & Security (Enterprise Edition)

Modern data platforms must ensure that data is accessible to the right users and off-limits to everyone else. Ilum Enterprise edition provides enterprise-grade security features to protect data at every level, including robust identity integration, fine-grained permissions, auditing, and encryption. These controls help organizations meet strict compliance requirements (e.g. SOC 2, HIPAA, GDPR) while using Ilum as their unified data platform. Ilum’s security model is hierarchical and comprehensive: you can manage access from the top (account or workspace level) down to individual databases, tables, rows, and even columns, enforcing the principle of least privilege across all data and AI assets.

Role-Based Access Control (RBAC)​

Ilum implements a flexible role-based access control system to manage who can perform actions or access specific data. Administrators can define roles and assign privileges on various securable objects (clusters, databases, tables, notebooks, etc.) to users and groups. This centralized permission model lets you easily grant or revoke access as team members join or leave, ensuring only authorized users can view or manipulate sensitive datasets. Key aspects of Ilum’s RBAC include:

  • Hierarchical Privileges: Permissions can be granted at different levels (e.g. an entire database or a specific table). Higher-level grants cascade down to contained objects unless overridden. This hierarchy makes administration easier while still allowing exceptions when needed.
  • Users, Groups, and Service Accounts: Ilum supports mapping of individual users, groups (from your identity system), and service principals (non-human accounts) to roles. This means you can set group-based policies (e.g. a “DataScientists” group role) or allow automated services limited data access under controlled roles.
  • Open Standard Policy Engine: Behind the scenes, Ilum Enterprise provides centralized security admin interface where you define fine-grained permissions for various data services. Ilum leverages this to uniformly enforce RBAC across Spark, SQL queries, the data catalog, and other components. Administrators can use UI or APIs to audit and update who has access to what data in Ilum.

With RBAC in Ilum, every action — from running a pipeline to querying a table — can be tied to a permission. Unauthorized actions are blocked by default, and you grant explicit rights to roles as appropriate. This ensures a strong default security posture: access is denied unless explicitly allowed. By using roles (instead of assigning permissions directly to individual users), Ilum makes it simpler to onboard users and maintain least-privilege access over time.

Fine-Grained Data Permissions (Row & Column Level Security)​

While RBAC controls which users can access which objects, Ilum also offers fine-grained access control to restrict how much of a data object a user can see. Fine-grained policies can filter data at the row level and mask or hide specific columns within tables. This is crucial for enforcing privacy and confidentiality policies — for example, limiting a customer support analyst to only see records pertaining to their region, or masking personally identifiable information in a column unless the user has clearance.

Ilum’s allows defining row-level filters and column-level masking rules on data queries. For instance, you can create a policy that dynamically filters rows based on a user’s attributes (e.g. only show WHERE department = 'Sales' for sales team members), or apply a column mask (e.g. show only the last 4 digits of a credit card number for users without a sensitive data role). These policies are enforced transparently at query time – users continue using SQL or tools as usual, but the underlying engine ensures they only retrieve permitted data.

Example of a fine-grained access policy This policy grants all users in the “finance” group access to a sensitive database, denies access to all users in the “interns” group, and then excludes a specific user (scott) from that deny rule, allowing that one intern to query the database. Ilum Enterprise supports such allow/deny exceptions to tailor access at a granular level, ensuring you can enforce strict data restrictions while still granting exceptions when justified. The policy engine evaluates multiple conditions in order (allow, deny, exceptions) to determine the final access outcome, giving administrators precise control over data visibility.

Fine-grained controls help prevent data leaks by ensuring even if a user has access to a table, they might still see only a subset of the data. For example, you could restrict column email or SSN to be fully masked (or simply not returned) for most users, while a compliance officer role can see the true values. Row-level security and column masking in Ilum are configured centrally and apply across all access methods (SQL editor, notebooks, BI tools connecting via JDBC, etc.), so you don’t have to trust individual users or applications to filter out data — the platform does it for you according to the policies set by your governance team.

Attribute-Based Access Control (ABAC) and Data Classification​

In addition to RBAC, Ilum Enterprise supports attribute-based access control to make security policies more dynamic and context-aware. ABAC in Ilum allows you to define policies based on attributes of the data (such as tags or classifications) and/or attributes of the user (such as department, role, or clearance level), rather than just fixed roles on resources. This approach is powerful for organizations with complex security requirements, such as multi-tenant datasets or regulatory constraints.

One way Ilum implements ABAC is through data classification tags. Data can be tagged or categorized (for example, label certain tables or columns as “Public”, “Internal”, or “Restricted”). Policies can then reference these tags to automatically apply rules. For instance, you might tag a column as Sensitive and have a masking policy that says “mask values of Sensitive columns unless the user’s clearance attribute is High.” In Ilum, you could mark datasets with confidentiality levels and create an attribute-driven policy that only users with a matching clearance can access Restricted data. If a table is tagged as containing GDPR personal data, an ABAC policy could ensure only users in the EU-Compliance group can query it, or only return rows where the user’s region matches the data’s region.

ABAC policies evaluate attributes at query time, which means they can adapt to changing metadata or user profiles without rewriting all the role grants. Ilum’s supports tag-based policies: for example Ilum can enforce rules on any data tagged a certain way. This enables policy automation – you set rules like “if data is tagged PII, mask it for all non-Compliance roles,” and any new column tagged PII automatically inherits that rule. It greatly simplifies governance in large, evolving data environments.

Example use cases for ABAC in Ilum: You could implement a policy that uses user attributes, such as allowing access to records where record.owner_department == user.department (so each department only sees its own data). Or use environment attributes – e.g., more permissive access when querying in a dev environment vs. stricter rules in production. These kinds of attribute-driven rules complement the static RBAC roles to handle scenarios where context matters. By combining RBAC and ABAC, Ilum provides a multi-layered security model: roles grant broad entitlements, and attribute-based rules refine access within those entitlements based on data sensitivity, user characteristics, or other context.

Authentication & Identity Integration​

A strong access control system relies on reliable authentication of user identities. Ilum Enterprise integrates with enterprise identity providers to ensure that only authenticated, authorized users can log into the platform and that their identities and group memberships are consistently managed. Rather than maintaining a separate siloed user directory, Ilum can hook into your existing Single Sign-On (SSO) and directory services:

  • LDAP/Active Directory Integration: Ilum can connect to LDAP or Active Directory to synchronize users and groups. This means user accounts and group memberships from your organization can be imported or referenced in Ilum, allowing you to apply data access policies based on your existing org structure. When people join, leave, or change roles in your company, updating your central directory can automatically propagate to Ilum’s access control (via periodic sync or JIT provisioning), keeping permissions up-to-date.
  • OAuth2/OpenID Connect SSO: Ilum supports OAuth2/OIDC for single sign-on, which allows integration with providers like Okta, Azure AD, Google Workspace, or any identity platform that speaks OpenID Connect. Under the hood, Ilum deploys ORY Hydra (an open-source OAuth2/OIDC server) as part of its stack. This enables Ilum to act as an OIDC client, so users can log in through your company’s SSO login page. Credentials are not stored in Ilum; instead, secure tokens from the IdP are used. Ilum’s UI and APIs can be accessed via these SSO tokens, simplifying user management and enabling features like multi-factor authentication (managed by your IdP policy).
  • Internal User Management (for Air-Gapped or Dev setups): For deployments without an external IdP, Ilum provides an embedded OpenLDAP server which can serve as a lightweight user directory. You can create users and groups in Ilum’s internal LDAP if needed. In either case, all authentication attempts go through secure channels, and password storage (when applicable) is hashed and managed according to best practices.

Once authenticated, a user’s identity and group info are used by Ilum’s RBAC/ABAC system to determine what they can do. Ilum issues user-specific tokens for session management, and every action is tied back to a user identity for auditing. Service accounts or API tokens can also be set up for programmatic access by external tools, with each token mapped to a role so that non-interactive access is just as controlled as interactive login access.

Ilum’s identity integration means you can enforce corporate security policies (password complexity, MFA requirements, account lockout, etc.) via your chosen identity provider and have Ilum inherit those standards. All login events and authentication changes can be logged for security reviews. By federating identity, Ilum ensures a seamless yet secure user experience: users use their regular company credentials to access data, and admins have one place (the IdP/LDAP) to deactivate or modify user access across all systems including Ilum.

Auditing & Compliance​

Enterprise security isn’t only about preventing unauthorized access; it’s also about monitoring and tracking authorized access. Ilum provides comprehensive auditing capabilities so that every action on the platform leaves an audit trail. This is vital for compliance and forensic analysis — you need to know who accessed what data, when, and what they did with it. Ilum’s auditing and monitoring features include:

  • Audit Logs: All data access events and security-related actions are recorded. Whenever a user queries a dataset, attempts to read or write a file, or changes a security policy, Ilum logs the event with details (timestamp, user, resource, action, success/failure, etc.). These audit logs can be reviewed in the Ilum UI or exported to external security information and event management (SIEM) systems for continuous monitoring. By centrally capturing access events, Ilum enables administrators to spot unusual access patterns or verify compliance with internal policies.
  • Data Lineage Tracking: Ilum integrates OpenLineage to automatically track how data flows through various jobs and pipelines. Lineage is a form of audit on data itself – it records which source datasets contributed to a result, what transformations were applied, and where data moved. This is extremely useful for compliance, as you can answer questions like “if a user viewed this dashboard, what raw data did it ultimately draw from?” or “did any process use dataset X (which is sensitive) without authorization?”. OpenLineage data, combined with audit logs, gives a full picture from data origin to consumption.
  • Usage Analytics: Beyond raw logs, Ilum provides summary views and analytics of data usage. For example, you can see which users are the top readers of a particular table, which teams haven’t accessed certain data at all, or which queries are run most frequently. These insights can highlight if sensitive data is being widely accessed when it shouldn’t be. Ilum’s Catalog UI includes features to show frequent users and queries for any table, helping data owners understand access patterns (and adjust permissions or training accordingly).
  • Compliance Reporting: With the combination of RBAC rules, ABAC tags, audit logs, and lineage, organizations can build reports to demonstrate compliance. If you need to prove to auditors that only authorized personnel accessed healthcare data or that all access to financial records is tracked, Ilum has the groundwork to do so. The platform’s security features are designed to support standards like SOC 2, HIPAA, and GDPR, which emphasize access control, data integrity, and auditability. For instance, GDPR mandates knowing who accessed personal data and allowing only need-to-know access — Ilum’s fine-grained controls and logs make this achievable. Likewise, HIPAA requires auditing access to electronic health records; Ilum’s audit trails can be used to meet that requirement.

In practice, auditing and compliance in Ilum means you always have evidence of data activity. If a security incident or data breach is suspected, you can trace through logs to see if any unauthorized access occurred. If a user requests to know how their data was used (a GDPR “data subject access request”), you can use lineage to find where their data went. By proactively monitoring these logs (and integrating with alerting systems), Ilum allows security teams to detect anomalies, such as a user suddenly accessing an unusual amount of data or querying resources they never did before. All these capabilities ensure that Ilum not only guards your data but also continuously validates and documents that protection.

Data Encryption & Protection​

To safeguard data privacy and prevent eavesdropping or theft, Ilum Enterprise employs end-to-end encryption for data both at rest and in transit. Encryption is a critical layer of defense that ensures even if network traffic is intercepted or storage media is compromised, the data remains unreadable without proper keys. Ilum’s approach to encryption and data protection includes:

  • Encryption in Transit: All communication with Ilum — whether it’s a user accessing the web interface, a JDBC connection from a BI tool, or inter-service communication between Ilum components — is encrypted via TLS (Transport Layer Security). Ilum adheres to modern best practices by using strong TLS 1.3 protocols and ciphers for data in motion. This means query results, credentials, and any data moving across the network are wrapped in a secure channel. For example, when you run a SQL query from your browser, the response travels over HTTPS; when Ilum’s Spark workers shuffle data or talk to the metadata services, they do so over encrypted links as well.
  • Encryption at Rest: Ilum supports encrypting data at rest using industry-standard algorithms (AES-256, typically). If Ilum is configured with cloud object storage (like S3, ADLS, GCS) or an on-premises storage layer (HDFS, Ceph, MinIO), it either leverages the storage provider’s server-side encryption or manages encryption through integrated tooling. For example, on HDFS or local storage, Ilum can integrate with Hadoop’s Key Management Server to create encrypted zones, ensuring files are stored encrypted on disk. In cloud deployments, you can enable server-side encryption on buckets/containers; Ilum fully supports working with encrypted data stores. The encryption keys can be managed by your cloud KMS or your own key management solution, giving you control over key rotation and access. In essence, data remains encrypted wherever it resides, and only authorized processes with the correct keys can decrypt it.
  • Credential and Secret Management: Beyond data encryption, Ilum secures the secrets and keys it needs to operate. Connection strings, passwords, access keys for external systems – these are stored securely (never in plaintext) and are accessible only to the services that require them. Ilum can integrate with external secret managers or vaults if configured, or use Kubernetes secrets and strong hashing for storing sensitive configuration. This prevents leakage of credentials that could lead to unauthorized data access.
  • Fine-Grained Security Configurations: Ilum allows administrators to configure security policies such as session timeouts, IP access restrictions (e.g., allow access only from specific networks or VPN), and secure cluster isolation. For instance, multiple Kubernetes clusters managed by Ilum can be network-isolated from each other to create sandbox environments. Although network-level security is often handled by your infrastructure, Ilum can work within those constraints (for example, deploying all components into a private VPC with no public endpoints unless explicitly exposed). Moreover, Ilum’s components (Spark, Jupyter, Superset, etc.) run with minimal privileges on the host system and adhere to container security best practices, reducing the attack surface.
  • Data Backups and Recovery Protection: Any backups or checkpoints taken through Ilum (such as metadata store backups, snapshot exports of tables, etc.) can also be encrypted. This ensures that historical copies of data are as secure as live data. Additionally, Ilum’s support for ACID table formats (Delta Lake, Iceberg, etc.) means you can time-travel or rollback data safely without needing insecure manual exports for recovery. You maintain compliance by not having stray unencrypted copies of datasets floating around.

In summary, Ilum encrypts data everywhere and controls the keys tightly. Even if someone were to obtain a hard drive from an Ilum server or intercept network packets, the data would be gibberish to them. These encryption measures, combined with Ilum’s access controls, form a defense-in-depth: even if access controls were misconfigured, encryption adds another layer of protection. Conversely, even if encryption is somehow broken, the access controls would still prevent misuse. Ilum’s security philosophy is to layer these measures to minimize single points of failure.

External & Cross-Platform Data Access Control​

One of Ilum’s advantages is its ability to unify access to various data sources – including those outside of Ilum’s own storage – without compromising on security. In enterprise environments, data may reside in multiple systems (cloud object stores, external databases, streaming systems, etc.) or be consumed by external tools. Ilum Enterprise extends its access control and security model to these scenarios as well:

  • Secure Access to External Data Sources: Ilum can connect to external storage systems and data platforms (for example, an S3 data lake, Azure Data Lake, external SQL databases, or Kafka streams) through its compute engines like Spark and Trino. When it does so, Ilum centralizes the management of credentials and permissions for those sources. Instead of giving all users direct keys or logins to external systems, you configure the connection in Ilum with necessary credentials (e.g., an AWS IAM role or key for S3, a JDBC connection for an external DB). Ilum then allows only authorized users to query those external data through the platform. The same RBAC/ABAC policies apply: if a user isn’t permitted to access a certain external data source or table, the query won’t return data. This approach prevents “back door” access to data – users must go through Ilum (with all its security checks) to get to the data, even if the data is stored elsewhere. Administrators can audit these external data accesses just like internal ones, since queries flow through Ilum’s engines.
  • Managing Access from External Tools: Conversely, Ilum can also serve data to external tools and platforms in a governed way. For example, analysts might connect Tableau or PowerBI to Ilum via JDBC/ODBC, or you might have data scientists using Python notebooks connecting via Ilum’s APIs. All these external accesses are authenticated through Ilum and respect the defined policies. A user connecting Tableau with their Ilum credentials will only be able to see the databases and tables their role allows, and any fine-grained masking still applies. There’s no way to bypass security by using a different tool, because Ilum acts as the gatekeeper. Even if multiple BI tools or clients connect, they funnel through Ilum’s secure interface.
  • Open Standards for Cross-Platform Governance: Ilum is built on open data formats and is embracing emerging open governance standards to ensure security can span platforms. For instance, Ilum plans integration with Apache Iceberg’s REST catalog and Apache Nessie, and even interoperability with Databricks Unity Catalog APIs (as they become available). This means in the future you could manage a consistent set of access policies across Ilum and other platforms that use those catalogs. If an external system queries an Iceberg table managed by Ilum’s catalog, Ilum can enforce that only authorized calls succeed (much like Unity Catalog can govern external accesses via open APIs). The goal is a unified governance layer: regardless of where the request comes from, the same security rules guard the data. Ilum’s commitment to open standards also ensures you’re not locked into one vendor’s proprietary security model – if you use Ilum alongside other tools, they can share governance metadata.
  • Data Sharing and Collaboration: In scenarios where you need to share data with external partners or across departments, Ilum provides secure mechanisms to do so. You can create secure views or share specific tables via controlled channels. Integration with projects like Delta Sharing (an open protocol for data sharing) is possible, allowing you to share a dataset with someone outside your organization without handing them raw files – they would access it via a secure link underpinned by Ilum’s governance. Every external access can thus be logged and subjected to expiration, retraction, or modification as needed. This kind of controlled sharing ensures that collaboration does not equate to losing control of your data.

By extending its security reach to external data and consumers, Ilum acts as a central trust layer in your data ecosystem. You get the convenience of a one-stop platform for analytics and AI across diverse data sources, and at the same time, a one-stop control plane for all data security and access governance. This unified approach reduces the chance of misconfigurations (since policies are managed in one place) and makes it easier to demonstrate compliance, because you can point auditors to a single system (Ilum) that shows all access requests and rules, even in a hybrid or multi-cloud data architecture.

Overall, Ilum Enterprise’s data access control and security features ensure that data is both accessible and protected. By combining strong authentication, granular authorization (RBAC and ABAC), data-level controls, encryption, and comprehensive auditing, Ilum enables organizations to confidently leverage a modern lakehouse platform for all their analytics and AI needs without compromising on governance. Whether dealing with sensitive personal information or mission-critical business data, Ilum provides the tools to keep data secure, private, and compliant, so you can focus on extracting value from the data rather than worrying about its safety. With Ilum, you get the flexibility of an open data platform with the peace of mind that robust enterprise security brings.

Ilum Enterprise provides a layered security model that governs who can access which assets and what data they can actually see. Controls span from identity and workspace boundaries down to row- and column-level policies, with unified auditing and encryption across hybrid and multi‑cluster deployments.

At a glance​

  • Identity & SSO: OAuth2/OIDC (e.g., Okta, Azure AD, Google), LDAP/AD, and service principals.
  • Authorization: Role‑Based Access Control (RBAC) + Attribute‑Based Access Control (ABAC) with tags and user attributes.
  • Fine‑grained policies: Row filters and column masking for PII/PHI and sensitive fields.
  • Catalog governance: Hierarchical privileges across catalogs → schemas → tables/views/functions.
  • Encryption: TLS for data in transit; enterprise key management for data at rest (cloud or on‑prem).
  • Auditability: Centralized audit logs, lineage (OpenLineage), usage analytics; SIEM export.
  • Hybrid & multi‑cluster: Consistent policy enforcement across Spark/Trino clusters and storage backends.

All capabilities in this section are available in Ilum Enterprise.

Securable objects & privileges​

LevelObject examplesTypical privileges
WorkspaceWorkspaces/Projects, compute poolsManage workspace, assign roles, attach clusters
CatalogLogical data catalogsCREATE SCHEMA, USAGE
SchemaNamespaces within a catalogCREATE TABLE/VIEW, USAGE
Data objectsTables, Views, Functions, Materialized ViewsSELECT, INSERT, UPDATE, DELETE, OWNERSHIP
Sub‑objectColumnsMASK (policy), UNMASK (exception)
Sub‑objectRowsAPPLY ROW FILTER

Ownership implies full control (grant/revoke, alter); prefer group ownership over individual users.

Identity, authentication & sessions​

  • SSO (OAuth2/OIDC): Connect Ilum to your IdP; users authenticate via the corporate login page; tokens drive UI & API access.
  • LDAP/AD: Sync users/groups; map directories to Ilum roles; supports JIT provisioning.
  • Service principals: Non‑human identities for pipelines/CI/CD with scoped tokens and expiry.
  • Session security: Configurable TTL, refresh tokens, MFA enforced at the IdP; IP allowlists/deny lists at the ingress.

Authorization: RBAC + ABAC​

RBAC​

Assign permissions to roles and bind roles to users/groups/service principals.

  • Keep grants at catalog/schema when possible; override at object level only when needed.
  • Prefer group‑based grants; avoid direct user grants.
  • Use distinct roles per persona: platform-admin, data-steward, data-engineer, analyst, ml-ops, svc-ci.

ABAC​

Policies can reference data tags (e.g., PII, Confidential, EU-Only) and user attributes (e.g., department=Sales, region=EU, clearance=High).

  • Tag datasets/columns in the catalog.
  • Write policies like: mask columns tagged PII unless user.clearance=high.
  • Enforce regional residency: allow access when data.region == user.region.

RBAC grants entitlements; ABAC constrains entitlements based on context.

Fine‑grained controls (row filters & column masking)​

  • Row filters: Attach predicate logic evaluated at query time, e.g. department = user.department or tenant_id IN user.tenants.
  • Column masking: Deterministic/partial masks, nulling, or tokenization for sensitive fields (emails, SSNs, credit cards). Provide unmask exceptions for specific roles.
  • Applies everywhere: SQL editor, notebooks, BI via JDBC/ODBC, and programmatic APIs.

Examples (illustrative syntax):

-- Row filter: Analysts see only their region
CREATE ROW FILTER rf_region
ON TABLE sales.orders
USING (region = current_user_attribute('region'));

-- Column mask: show last 4 digits unless role has 'pii_read'
CREATE MASK mp_cc ON COLUMN payments.card_number
USING (
  CASE WHEN has_role('pii_read') THEN card_number
       ELSE CONCAT('****-****-****-', RIGHT(card_number, 4)) END
);

Syntax may vary by engine; Ilum attaches the logic to the compute path automatically.

Auditing, lineage & monitoring​

  • Audit log: Every access/DDL/DCL event recorded with user, object, action, outcome.
  • Lineage (OpenLineage): Automatic capture for jobs, queries, and pipelines; surfaced in Catalog.
  • Telemetry: Top users, hotspots, uncommon access; export to SIEM (Splunk/ELK) for alerting.
  • Retention: Configure log retention and immutability for compliance (e.g., WORM storage).

Encryption & secrets​

  • In transit: Enforced TLS for UI, APIs, JDBC/ODBC, and inter‑service traffic.
  • At rest: Leverage cloud KMS/server‑side encryption (S3/ADLS/GCS) or on‑prem key managers (HDFS, MinIO).
  • Secrets: Store credentials in enterprise secret managers or Kubernetes secrets; rotate keys; avoid embedding in notebooks.

External data & tool access​

  • External stores: Configure connections once; Ilum mediates access via policies instead of distributing raw credentials.
  • External tools: Tableau/Power BI/JDBC clients authenticate through Ilum; fine‑grained policies still apply.
  • Sharing: Use governed views/materialized views; optional open sharing protocols; time‑bound, revocable access.

Setup & configuration (step‑by‑step)​

  1. Connect IdP (OIDC): Register Ilum as a client; set issuer, client ID/secret; enable MFA at IdP.
  2. Sync LDAP/AD groups: Map directories to Ilum groups; set periodic sync or JIT provisioning.
  3. Define catalogs & schemas: Establish namespaces; tag data sensitivity (PII, Confidential, EU-Only).
  4. Create roles & bindings: Create least‑privilege roles and bind to groups (avoid direct user grants).
  5. Baseline policies:
    • Apply USAGE/SELECT at catalog/schema for analysts.
    • Attach row filters for tenants/regions.
    • Mask PII columns; grant unmask only to compliance roles.
  6. Storage & keys: Point to object stores/HDFS; enable at‑rest encryption; integrate with KMS; configure service roles.
  7. Audit & lineage: Enable audit export to SIEM; enable OpenLineage for pipelines; set retention.
  8. Network & sessions: Restrict ingress IPs; set session TTL/idle timeout; enforce HTTPS only.
  9. Validation: Run policy unit tests (sample users/queries); verify expected allow/deny/mask outcomes.

Example (illustrative) OIDC config snippet:

auth:
  oidc:
    issuer_url: https://login.example.com
    client_id: ilum-enterprise
    client_secret: ${SECRET_OIDC_CLIENT}
    redirect_uris:
      - https://ilum.example.com/callback
    claim_mappings:
      groups: "claims.groups"
      email:  "claims.email"
      region: "claims.region"

Best practices​

  • Default‑deny: Start with no access; add explicit grants.
  • Group‑centric: Bind roles to groups; automate membership via HRIS/IdP.
  • Tag early: Tag PII/regulated data at ingestion; drive ABAC from tags.
  • Separate duties: Distinct roles for admins, data owners, and consumers.
  • Break‑glass: Time‑boxed, audited elevation for incidents.
  • Test policies: Include sample identities in CI for pipelines and views.
  • Rotate & expire: Short‑lived tokens; rotate service credentials regularly.
TaskDescription
Manage privilegesUnderstand securables and how to grant/revoke access across the hierarchy.
Manage ABACUse tags and user attributes to constrain access dynamically.
Manage identitiesConfigure OIDC/LDAP, groups, and service principals.
Fine‑grained accessApply row filters and column masks for sensitive data.
External storage accessGovern cloud/on‑prem storage and external platforms via Ilum.
Access from external toolsEnforce policies for JDBC/ODBC/BI connections.
Auditing & lineageExport audit logs, visualize lineage, and set retention.

FAQ​

  • Do policies apply in notebooks and BI tools? Yes—policies are enforced in the compute path, regardless of client.
  • Can I exempt certain users from a mask? Yes—grant an explicit UNMASK (or equivalent) permission via a high‑trust role.
  • How do I enforce regional residency? Use row filters keyed on user.region and data tags like EU-Only.
  • What about multi‑tenant B2B? Combine tenant‑scoped row filters with separate catalogs per tenant, as needed.****