Security & Governance

Holistic security, uniform across your entire stack

Your data deserves security that thinks like you do: who should access what, and when. Manage users, service accounts, roles and groups, set organization-wide guardrails and federate your identity providers (SSO, OIDC).

Request a demo CIO Solution →

Specifications

IAM: Users, service accounts, roles, groups
Identity federation: GitHub, Google, OIDC
Guardrails: Rules enforced across the whole organization
Zero-trust: No administrator bypass
Access window: Start and end time in UTC
Row-level: Row labels against account attributes
Multi-level: Organization then SQL cluster
Contextual: Nationality, contract type, clearance
Configurable: Per-service settings, no policy code to write
Traceability: Access decisions and audit log in the console

Use cases

Regulatory compliance

Rules set organization-wide then refined per SQL cluster, and every access decision stays explainable

Traced decisions, audit log

Identity federation

Plug in your corporate identity provider over OIDC, and manage users, groups and service accounts from the console

GitHub, Google, OIDC

Partition by nationality and by contract

A table carrying a geo-restriction label is readable only by accounts whose declared nationality matches, and trade secret data stays closed to external contractors

Data labels against account attributes

In action

The access window on sensitive data

A security lead restricts data access to office hours and to the required clearance level

In the organization's security settings, the office-hours window is enabled, with a start time and an end time in UTC
Each SQL cluster inherits the organization setting, or overrides it for its own scope
Tables are classified by sensitivity level: a query on a table classified above the caller's clearance is denied, and access-label checking can additionally go down to column level
A query issued outside the configured window is denied before it reaches the data, and the decision is recorded in the audit log

Sensitive data stays out of reach outside the allowed windows, and every denial can be justified in an audit

Permissions matched to the actual need

A marketing team needs a subset of the sales data for a campaign

A group is created in IAM and the team members are added to it: each of them inherits whatever the group is granted
A role is bound to the group, or permissions are granted directly on a precise resource path rather than organization-wide
Attributes in namespace::value format are set on the accounts, region for example: row-level security returns only the rows whose labels match
An organization guardrail additionally closes the most sensitive subtree for everyone, owners included

The team reaches the subset it needs, without permanent privilege escalation

Reviewing denied access

A security team reviews the access decisions evaluated on the platform

The console shows the feed of access decisions, allowed and denied, over a window of 1 hour, 24 hours or 7 days
A filter isolates denied decisions only, or those of a given user
Each entry carries the reason for the denial, the restrictions evaluated, the IP address and the client used
The audit log keeps the full event, filterable by user, event type and period

Abnormal access behavior is visible in the console, and every denial stays documented for the audit

Intelligent security

IAM Complete IAM: Users, service accounts, roles and groups in one place. A group is granted a role or permissions, and every member inherits them.
OIDC Identity federation: Plug in GitHub, Google or any OIDC provider. The client id is set from the console, the client secret is never kept there.
Guardrail Organization guardrails: An organization rule gates an action over a resource subtree for everyone, owners included: access is denied unless every condition holds.
Zero-trust Zero-trust mode: Once enabled, it removes the implicit bypass administrators enjoy: every call goes through policy evaluation, with no exception.
Office hours Access window and read-only: The access window is defined in UTC hours at organization level, and each SQL cluster inherits it or overrides it. A cluster can also be switched to read-only: any write is then denied.
Sensitivity Sensitivity levels: The account clearance must reach the sensitivity level carried by the table. Access-label checking applies to tables and, if you enable it, to columns.
Context rules Contextual rules: A rule matches the labels set on the data against the account's declared attributes: nationality, contract type, clearance level. Nothing is inferred from an IP address or from geolocation.
Row-level Row-level filtering: Enabled per catalog, per schema or per table. A label column carried by the table is compared to the account's namespace::value attributes, and only the matching rows are returned.
Audit log Traced decisions: Every decision carries its reason, the restrictions evaluated, the IP address and the client used. The console shows them over 1 hour, 24 hours or 7 days, and the audit log keeps the full event.

How it works

The request arrives

A user or a service account queries a table from a SQL cluster.
The rules are evaluated

Access window, read-only mode, sensitivity level, table and column labels, contextual rules and organization guardrails.
The decision is made, then traced

Access allowed, denied with its reason, or rows filtered by their labels. The event joins the audit log and the decision feed.

Key benefits

Complete IAM: users, service accounts, roles and groups
Identity federation: GitHub, Google and any OIDC provider
Guardrails enforced across the whole organization, owners included
Zero-trust mode: even administrators go through policy evaluation
Access control by UTC time window, sensitivity level and account attributes
Row-level filtering, enabled per catalog, per schema or per table
Access decisions readable in the console over 1 hour, 24 hours or 7 days

Ready to secure your data intelligently?

Discover how our contextual security can protect your organization.

Request a demo Catalog overview →