Secure access to data in Sigma
Sigma supports different methods that you can use to secure and manage access to your data. Use them in different combinations to provide scalable and effective data security in Sigma.
The options that make the most sense for your organization depend on how you plan to use Sigma, and where you prefer to restrict access to data.
Restrict access to data in your data platform
If you want to manage access restrictions in your data platform, use one or more of the following options:
Enforce the role-based access control already defined in your data platform using OAuth or a dynamically assigned role.
Recommended when your data platform already has RBAC or row access policies you don’t want to duplicate in Sigma.
Isolate each customer in a separate Sigma organization, managed centrally by a parent organization.
Recommended for use cases where isolating data between tenants is critical.
Use role-based access control in your data platform
If your data platform already defines role-based access control (RBAC), you can enforce it from Sigma instead of duplicating the logic. Use one of the following methods to connect to your data platform to reuse the RBAC in your data platform:
Use OAuth
If you configure OAuth for a connection, Sigma authenticates each user to your data platform using their own identity, so any RBAC or row access policies enforced by your data platform apply automatically. Each user must have an account in the data platform and in Sigma for connection-level OAuth to enforce RBAC in the data platform.
Dynamically assign roles with a user attribute
If a connection uses key pair authentication, you can use a user attribute to specify the role that Sigma uses to query your data platform on behalf of the current user. By setting up dynamic assignment of roles, your data platform’s existing role-based security policies determine what data a given user can access. See Dynamically assign roles used by a connection.
Isolate data with Sigma Tenants
If you isolate each customer’s or business unit’s data in a separate organization using Sigma Tenants, you can ensure that unauthorized users can never access data that they do not have authorization to interact with.
If you do not need to fully separate users, connections, authentication, AI providers, and branding for each customer or business unit, you can also use version tags and source swapping to isolate the data queried within a single Sigma organization.
Restrict access to data in Sigma
If you plan to manage access to data directly in Sigma, grant the relevant data access and set up appropriate row-level and column-level security rules:
Control which users and teams can access a connection and the databases, schemas, and tables within it.
Recommended as a baseline for every connection. Applies at the connection, database, schema, or table level, not to individual rows or columns, and cannot be combined with OAuth-enforced RBAC.
Restrict specific rows or columns of data in a data model based on user identity, team membership, or a user attribute.
Recommended for granular access control enforced in Sigma.
Grant data access permissions
Data access permissions control which users and teams can access a connection and the databases, schemas, and tables within it. Access is additive, so permissions granted at a database or catalog level also apply to its schemas and objects. See Data access overview and Manage access to data and connections.
If you use OAuth to manage access to a connection, do not grant data access permissions.
Apply row-level and column-level security
Use RLS and CLS to restrict access to specific rows or columns of data in a data model based on user identity, team membership, or an assigned user attribute value:
- Row-level security (RLS) restricts specific rows of data.
- Column-level security (CLS) restricts or masks entire columns of data.