Security & Governance

How does security work in Casabase Cube?

Casabase Cube builds on Snowflake’s identity and role model and adds application-specific row-level security for multidimensional data.

At a high level:

Snowflake Identity
        │
        ▼
Snowflake Account Role
        │
        ▼
Casabase Cube Application Role
        │
        ▼
Application Access
        │
        ▼
Optional Row-Level Security
        │
        ▼
Permitted Cube Data

Snowflake controls authentication, account roles, application-role grants, and the underlying platform access boundary.

Casabase Cube provides application roles, row-level security, data classification, audit history, and other application-level governance capabilities.

See Security Model and Access Control.

What application roles does Casabase Cube provide?

Casabase Cube provides two primary application roles:

Application Role	Purpose
CUBE_PUBLIC	Query and discovery access.
CUBE_ADMIN	Modeling and administrative access. Inherits CUBE_PUBLIC.

Application roles are granted to Snowflake account roles.

Most query consumers should normally receive CUBE_PUBLIC, while CUBE_ADMIN should be limited to users whose responsibilities require administrative capabilities.

See Roles and Privileges.

Is an application role the same as row-level security?

No.

They answer different questions:

Application Role
       │
       ▼
What can the user do?


Row-Level Security
       │
       ▼
Which cube data can the user see?

For example, CUBE_PUBLIC can allow a user to query Casabase Cube, while row-level security can restrict that user to a particular branch of the Entity dimension.

See Roles and Privileges and Access Control.

Is Casabase Cube row-level security enabled for every user automatically?

No.

Casabase Cube row-level security is opt-in per user.

Security filtering applies when:

1. Security is enabled on at least one dimension of the cube.
2. The user has at least one active security rule for that cube.

Conceptually:

Security Enabled?
       │
       ├── No ──► No Row-Level Filtering
       │
       └── Yes
              │
              ▼
Active Rule for User?
       │
       ├── No ──► Unrestricted
       │
       └── Yes ──► Apply Security

This behavior is important when configuring and reviewing access.

What happens if a user has no active security rules?

If the user still has application access but has no active security rules for the cube, the user is unrestricted by Casabase Cube row-level security.

For example:

User A
├── CUBE_PUBLIC
└── Active ENTITY Rule

User A is restricted according to the active rule.

By contrast:

User B
├── CUBE_PUBLIC
└── No Active Security Rules

User B is not restricted by Casabase Cube row-level security.

This does not necessarily mean User B has inappropriate access. The user may intentionally require unrestricted cube access or access may be controlled through other Snowflake mechanisms. However, the configuration should be understood and intentional.

See Access Control.

Does enabling security on a dimension restrict everyone?

No.

Enabling security on a dimension makes that dimension available for Casabase Cube row-level security, but it does not automatically restrict every user.

A user must also have at least one active security rule for the cube before Casabase Cube row-level filtering applies to that user.

This allows security to be introduced gradually without automatically changing access for every existing user.

How are security rules defined?

Security rules are defined for individual Snowflake users against members of secured cube dimensions.

For example:

Total Entity
├── North America
│   ├── United States
│   └── Canada
├── Europe
└── Asia Pacific

A user granted access to:

North America

can receive access to that permitted hierarchy branch according to the configured rule behavior.

Multiple active grants can combine to form the user’s effective permitted scope.

See Access Control for rule configuration and supported security modes.

Can a user have security rules on more than one dimension?

Yes.

Security can be configured across multiple secured dimensions.

The user’s effective access is determined by the applicable active rules and the multidimensional intersection of the permitted scopes.

For example:

ENTITY
└── North America

SCENARIO
└── Actual

can restrict a user to the permitted Entity branch within the permitted Scenario context.

See Access Control.

What happens when a user is granted a parent member?

A grant on a hierarchy member can provide access to that member and its permitted descendants according to the configured security mode.

For example:

North America
├── United States
└── Canada

a grant on North America can provide access to the permitted North America branch rather than requiring a separate rule for every descendant.

This makes security definitions hierarchy-aware.

How do shared and alternate hierarchy members affect security?

Shared and alternate hierarchy members resolve to the underlying base-member relationships for security purposes.

A grant through a shared or alternate hierarchy therefore conveys access to the corresponding permitted underlying leaves rather than creating an unrelated copy of the data.

See Access Control and Hierarchy Capabilities.

Can a restricted user see a parent above the branch they are allowed to access?

Yes.

Ancestors above the permitted branch can remain visible where required to represent the requested aggregate.

However, their values are calculated only from the user’s permitted descendants.

For example:

Total Entity
├── North America
├── Europe
└── Asia Pacific

If a user is permitted to see only North America, a query for Total Entity can return:

Total Entity = permitted North America scope

rather than the unrestricted global total.

This is a partial rollup.

What is a partial rollup?

A partial rollup is an aggregate calculated only from the data the current user is permitted to access.

Conceptually:

Requested Parent
       │
       ▼
Apply User Security
       │
       ▼
Permitted Descendants
       │
       ▼
Aggregate Permitted Data
       │
       ▼
Partial Rollup

This allows restricted users to work with meaningful hierarchy totals without exposing restricted descendants.

Can the same parent member have different values for different users?

Yes.

Because security is applied before aggregation, the same parent can represent different permitted populations for different users.

For example:

User A
North America only
        │
        ▼
Total Entity = North America total


User B
Unrestricted
        │
        ▼
Total Entity = Global total

The member label can be the same while the value differs according to the user’s security scope.

Reports containing partial rollups should therefore be interpreted in the context of the viewer’s access.

Is security applied before or after aggregation?

Security is applied before aggregation and formula evaluation.

Conceptually:

Requested Members
       │
       ▼
Apply User Security
       │
       ▼
Permitted Leaf Scope
       │
       ▼
Aggregation
       │
       ▼
Formula Evaluation
       │
       ▼
User Result

This prevents restricted data from contributing to a user’s aggregate or calculated result.

Can a formula expose data that the user cannot otherwise access?

No.

Formula operands are evaluated within the same permitted security scope as the rest of the query.

A formula cannot be used as an alternate path to retrieve restricted cube data.

However, a formula can produce a different valid result for users with different security scopes because the permitted operands can differ.

See Formula Overview and Security Model.

Does security apply to Query Builder?

Yes.

Configured row-level security applies to supported Casabase Cube query paths, including Query Builder.

Users cannot bypass configured security by switching from a programmatic query to the interactive query interface.

Does security apply to QUERY_CUBE?

Yes.

QUERY_CUBE evaluates the current user and applies the applicable Casabase Cube security rules before aggregation and calculation.

The same principle applies to QUERY_CUBE_PIVOT_JSON.

See Querying with SQL.

Does security apply to direct SQL access?

Casabase Cube exposes security-aware views for supported direct SQL access.

Examples include:

<CUBE>_FACT_SECURE
<CUBE>_DIMENSIONS

The secure fact view exposes stored fact rows within the executing user’s applicable security scope.

The secure dimensions view prevents restricted hierarchy metadata from becoming an alternate way to discover members outside the user’s permitted scope.

See Querying with SQL.

Is there a query path that bypasses Casabase Cube security?

Supported security-aware Casabase Cube read paths apply the same configured security model.

This includes:

• Query Builder
• QUERY_CUBE
• QUERY_CUBE_PIVOT_JSON
• Secure fact views
• Secure dimension views
• Formula evaluation

Consumers should use the documented Casabase Cube interfaces when row-level security enforcement is required.

Do security-rule changes require a cube rebuild?

No.

Security configuration is evaluated at query time.

A security-rule change takes effect on subsequent queries without rebuilding dimensions or clearing an aggregation cache.

Conceptually:

Change Security Rule
       │
       ▼
Next Query
       │
       ▼
Updated Security Scope

What Snowflake privilege does row-level security depend on?

Casabase Cube evaluates Snowflake session context, including the current user, for user-aware functionality such as row-level security.

The Native App therefore requires:

READ SESSION

for the applicable functionality.

See Roles and Privileges.

What happens if I deactivate a user’s final active security rule?

The user becomes unrestricted by Casabase Cube row-level security if the user still has application access.

Conceptually:

User Has Active Rules
       │
       ▼
Restricted Access
       │
       ▼
Deactivate Final Active Rule
       │
       ▼
No Active Rules
       │
       ▼
Unrestricted by Casabase Cube
Row-Level Security

For this reason, deactivating or deleting the final rule is an access-control change, not merely administrative cleanup.

Does deleting a user’s security rules remove their access to Casabase Cube?

No.

Deleting security rules removes Casabase Cube row-level restrictions. It does not revoke the user’s Snowflake or application-role access.

If the user still receives CUBE_PUBLIC or CUBE_ADMIN, removing the final active security rule can make the user unrestricted by Casabase Cube row-level security.

To remove application access, remove the applicable Snowflake role or Casabase Cube application-role grant through the organization’s Snowflake access model.

See Operational Tasks for user offboarding.

How should I offboard a Casabase Cube user?

Do not begin by simply deleting the user’s row-level security rules.

A typical offboarding process should first remove the user’s underlying application access through the applicable Snowflake role path.

Then clean up application-specific configuration such as obsolete security rules where appropriate.

Conceptually:

Identify User
      │
      ▼
Remove Application Access
      │
      ▼
Verify Access Removed
      │
      ▼
Clean Up Security Rules
      │
      ▼
Review Audit Information

See Operational Tasks.

What is Data Classification?

Data Classification is governance metadata that describes the sensitivity or business classification of a cube.

Supported classifications are:

PUBLIC
INTERNAL
CONFIDENTIAL
RESTRICTED

For example:

SALES_ANALYTICS       INTERNAL
FINANCE               CONFIDENTIAL
EXECUTIVE_REPORTING   RESTRICTED
PUBLIC_METRICS        PUBLIC

See Data Classification.

Does Data Classification control access?

No.

Classification is a governance label, not an access-control mechanism.

For example:

FINANCE
    │
    ├── Classification: CONFIDENTIAL
    │
    └── Security: Configured Separately

Assigning CONFIDENTIAL or RESTRICTED does not automatically:

• Enable row-level security
• Create security rules
• Revoke existing access
• Change Snowflake role grants
• Change CUBE_PUBLIC or CUBE_ADMIN assignments
• Filter query results

Access must be configured separately through the appropriate Snowflake and Casabase Cube controls.

Why classify a cube if classification does not enforce access?

Classification provides governance context.

It can help administrators answer questions such as:

What cubes contain sensitive data?
          │
          ▼
How are those cubes classified?
          │
          ▼
Is security configured?
          │
          ▼
Who has access?
          │
          ▼
Does the configuration match policy?

Classification can therefore be used to prioritize access reviews, governance activities, and lifecycle decisions.

Should every production cube be classified?

As a governance practice, production cubes should generally be assigned a classification consistent with the organization’s own data-classification policy.

Classification should also be reviewed when:

• The cube’s business purpose changes
• The sensitivity of its data changes
• New data is introduced
• Access requirements change
• The cube is being reviewed for decommissioning

See Data Classification.

How can I review the cubes and their classifications?

Casabase Cube provides a data inventory.

Use:

CALL CUBE.GET_DATA_INVENTORY();

The inventory includes information such as:

• Cube name
• Associated data table
• Data classification
• Dimension count
• Whether security is configured
• Recent query activity

This allows administrators to review classification and security posture together.

See Data Classification.

What does HAS_SECURITY mean in the data inventory?

HAS_SECURITY indicates whether row-level security is configured for the cube.

It does not by itself prove that every user is restricted.

Because Casabase Cube security is opt-in per user, a cube can have:

HAS_SECURITY = TRUE

while some users with application access remain unrestricted because they have no active security rules.

Access reviews should therefore examine both cube security configuration and actual user access.

Is a RESTRICTED cube with HAS_SECURITY = FALSE necessarily misconfigured?

Not necessarily.

For example:

DATA_CLASSIFICATION = RESTRICTED
HAS_SECURITY         = FALSE

deserves administrative review, but it does not automatically prove that access is inappropriate.

Access may be controlled through Snowflake roles or other applicable controls.

The important requirement is that the actual access model be intentional and consistent with the organization’s governance requirements.

Does Casabase Cube provide privacy or compliance reporting?

Yes.

Casabase Cube provides administrative information that can support privacy, governance, and compliance processes.

For example:

CALL CUBE.GET_PRIVACY_REPORT();

returns application-level information related to areas such as:

• Data classifications
• Security rules
• Access patterns
• Audit coverage
• Data-handling posture
• Governance recommendations

See Compliance and Privacy.

Does the Privacy Report certify compliance?

No.

The Privacy Report is not a compliance certification.

Generating a report does not by itself establish compliance with frameworks or regulations such as:

SOC 2
ISO 27001
GDPR
CCPA
HIPAA
PCI DSS

The report provides application-level information that can be used as evidence or input within the organization’s broader compliance program.

The organization’s policies, controls, legal obligations, and assessment conclusions remain the responsibility of the organization and its auditors or assessors.

Does Casabase Cube maintain an audit log?

Yes.

Casabase Cube records administrative and data-access activity in an application audit log within the customer’s Snowflake environment.

Audit information can support:

• Security investigations
• Configuration reviews
• Access reviews
• Operational troubleshooting
• Governance activities
• Compliance evidence

Audit retention is configurable.

See Audit Log.

What kinds of security activity should I review in the audit log?

Audit information can help investigate activity such as:

• Administrative changes
• Security configuration changes
• Governance changes
• Data-access activity
• Other auditable application operations

For example:

Current Security Configuration
        │
        ▼
Access Review
        │
        ▼
Question About a Change
        │
        ▼
Audit Log
        │
        ▼
Administrative History

See Audit Log for the available audit fields, filtering, and retention behavior.

Does Casabase Cube support access reviews?

Yes.

Access reviews should consider both application access and row-level restrictions.

A meaningful review should answer questions such as:

• Who has CUBE_PUBLIC?
• Who has CUBE_ADMIN?
• Which users have active security rules?
• Which users have application access but no active security rules?
• Which dimensions are secured?
• Which hierarchy branches are users permitted to access?
• Are administrative privileges still required?
• Does access remain appropriate for the cube’s classification?

Reviewing only the security-rule configuration is not sufficient because users without active rules can still have unrestricted Casabase Cube access.

See Compliance and Privacy.

Should CUBE_ADMIN access be reviewed separately?

Yes.

CUBE_ADMIN provides modeling and administrative capabilities and should be reviewed separately from ordinary query access.

Administrators can modify application configuration, so access should be limited to users whose responsibilities require those capabilities.

A review should verify:

Who Has CUBE_ADMIN?
        │
        ▼
Do They Still Require It?
        │
        ▼
Is the Snowflake Role Path Appropriate?
        │
        ▼
Retain or Remove Access

See Roles and Privileges.

How should I review security for a sensitive cube?

For a CONFIDENTIAL or RESTRICTED cube, consider reviewing:

• The cube’s classification
• Snowflake role access
• CUBE_PUBLIC membership
• CUBE_ADMIN membership
• Secured dimensions
• Active user security rules
• Users with application access but no active rules
• Recent audit activity
• Whether the cube is still required
• Whether access remains consistent with business need

The exact review frequency and evidence requirements should follow the organization’s own governance and compliance policies.

Does Casabase Cube send security or audit data outside Snowflake?

Core Casabase Cube processing runs within the customer’s Snowflake environment.

The application architecture reports:

data_egress           NONE
external_connections  NONE
pii_collection        NONE
telemetry             DISABLED

Application audit history and cube data remain within the customer’s Snowflake environment.

See Compliance and Privacy and Data Storage & Boundaries.

Does Casabase Software have access to my cube data?

Installing Casabase Cube does not give Casabase Software or other third parties access to customer data.

The application runs within the customer’s Snowflake account.

Access to customer-owned Snowflake objects must be explicitly granted to the Native App, and Casabase Cube does not automatically receive access to arbitrary objects in the customer’s account.

See Data Storage & Boundaries and Roles and Privileges.

Are scheduled query results protected by dynamic cube security when someone reads the materialized table?

Not automatically.

Security is evaluated when the scheduled Saved Query executes.

The resulting materialized table is a Snowflake table containing the output generated for the execution context.

Subsequent readers of that table are governed by the Snowflake privileges on the materialized table rather than by a fresh Casabase Cube security evaluation.

Conceptually:

Scheduled Query
       │
       ▼
Apply Execution Security
       │
       ▼
Materialize Result
       │
       ▼
Snowflake Table
       │
       ▼
Snowflake Table Grants
Control Subsequent Access

Do not use one materialized result table to serve audiences that require different dynamic security scopes unless the table’s Snowflake access model is designed accordingly.

Where should I start with security and governance?

Start with:

• Security Model
• Roles and Privileges
• Access Control
• Data Classification
• Compliance and Privacy
• Audit Log
• Operational Tasks