Access Control

This section outlines the permission and access control mechanisms in Tursio. These apply to both cloud and on-premises deployments.

Tenants. Each Tursio deployment is a dedicated single-tenant environment — completely isolated from other tenants with its own servers and namespace. Users must explicitly log in to each tenant separately, and no data or access can cross tenant boundaries. Tursio provides a landing page where users enter their account name to be redirected to their environment.

Connections. Tenants can connect to one or more databases. Each connection is identified by: (1) host name, (2) database name, and (3) username. Customers can connect to multiple databases, even across cloud and on-premises systems (e.g., SQL Server and Azure SQL), to query them all from a single place. Tursio supports SQL Server, Azure SQL, Fabric, Snowflake, Microsoft Excel, Cassandra, Databricks, and PostgreSQL, along with IP whitelisting.

RBACs. Database admins can apply their own RBAC on the usernames used to connect to the database — for example, sales_user can only see sales data while marketing_user can only see marketing data. Those native access controls are automatically carried forward in Tursio.

For example, the following T-SQL statements create a user tursio_user and assign it read permissions to database my_db:

USE my_db;
CREATE USER tursio_user WITH PASSWORD = password;
EXEC sp_addrolemember 'db_datareader', 'tursio_user';

Query Scope. Each database connection has a querying scope — the set of objects it can query. Customers can select which tables or views to include in the querying scope of each connection. Customers can also create custom views to expose only the relevant data for querying. For example, they can reduce or limit columns in a table, redact portions of the data (e.g., duplicates), pre-aggregate tables (e.g., transaction tables) to reduce load, and pre-join multiple tables to query across them with domain knowledge.

Users. Tenant owners can manage the users in their organization. All users must authenticate via Microsoft Entra ID or Google Login, depending on the organization's authentication setup, before accessing the Tursio portal. By default, only one person is assigned as tenant owner. To add more, contact Tursio.

Permissions. Tenant owners can assign users access to one or more database connections. Users can then query all objects in the querying scope of those connections. For example, Tom can have access to a sales connection with sales tables in the query scope, while Harry can have access to a marketing connection with marketing tables. Their CRO, Matt, can have access to both connections.

By creating connections tied to customer-defined user roles (RBAC) and assigning query scope to them, Tursio provides enterprise-grade access control for different scenarios.

FAQs

Can the access control in my database be reflected in Tursio?

You can create database user accounts with specific roles at your end — for example, sales_user to access only sales-related data, or hr_user to access only human resource data. When adding connections in Tursio, use the specific user with the appropriate role to limit access (e.g., a sales connection with sales_user). You can create different connections with different user roles and inherit their access control from your database.

Are users added to Entra automatically added to Tursio?

No. Access to infrastructure does not directly translate into access to data. Tursio requires tenant owners to add Entra users via their email addresses, and Tursio will authenticate them using Entra/OAuth. Tenant owners can further control which users can query which connections and the query tables available in each connection.

Can users be authenticated without network access?

Microsoft Entra and Google Login require network access to Microsoft or Google servers for authentication. Without network access, the tenant owner can still authenticate users via an access code, which is generated during setup and can be managed by the tenant owner.