Guides → Secure

This guide summarizes the Incorta security model and optional security configurations. It also describes the common considerations for securing the Incorta Direct Data Platform.

Incorta Security

Each application and service that comprises the Incorta Direct Data Platform requires security configuration and administration. Security configuration and administration cover the following functional areas:

• Authentication, Authorization, and Access
• Audit Access
• Data Security

Authentication, Authorization, and Access Configuration

There are two ways for a user to access data stored in the Incorta Direct Data Platform:

1. Sign in to Incorta Analytics Service web application
2. Connect to the Incorta Analytics Service with the SQLi interface using the PostgreSQL protocol.

In both cases, Incorta will authenticate the user using a tenant name, username, and password. Authentication is tenant specific in Incorta, and as such, is a Tenant Configuration in the Cluster Management Console.

Authentication Types

Incorta supports various types of user authentication for a given tenant. To learn more, review the Configure Tenants guide.

Incorta supports various Authentication Types for the Incorta Analytics Services as a tenant configuration.

Incorta Authentication

Incorta authentication consists of a username and password. For a given tenant, a CMC administrator can configure the password policy for Incorta Authentication. This includes the following policy properties:

• Minimum Password Length
• Password Cannot Include Username
• Require Lower Case Letters
• Require Upper Case Letters
• Require Digits
• Require Special Characters

The 2022.10.0 release introduced two ways to enforce a password reset policy for Incorta native authenticated users:

• As a User Manager or a Super User, you can use the resetPasswords public API endpoint to instantly reset the password of all Incorta authenticated users.
• As the Cloud Admin user, you can enable password expiration so that each Incorta authenticated user will have to change the password at a scheduled cadence.

For more information, refer to Tools → Public API → resetPassword Endpoint and Guides → Configure Tenants → Security → Incorta Authentication.

SSO (Single Sign On)

The Incorta Analytics Service supports Security Assertion Markup Language Type 2 (SAML2) for Single Sign-On:

• Configure SSO
• OneLogin
• Microsoft Active Directory (ADFS)
• IBM CIS
• Okta
• Mobile SSO

LDAP (Lightweight Directory Access Protocol)

Incorta Analytics supports the Lightweight Directory Access Protocol (LDAP). You can also use SSO with LDAP.

To learn more, refer to Guides → Configure Tenants → Lightweight Directory Access Protocol.

Authorization and Access

Incorta’s security model is optimistic, meaning that Incorta enforces the least restrictive role permissions and access rights. The Incorta security model is based on two common approaches to enterprise security:

• Role Based Access Control (RBAC)
• Discretionary Access Control (DAC)

Role Based Access Control

Role Based Access Control (RBAC) enforces access to certain features and functionality within the Incorta Analytics Services. The Incorta Loader Services is not accessible. The Incorta Cluster Management console is a separate web interface, and allows for one single administrator user.

There is no direct way to assign a Role to a user, with two exceptions:

• All users inherit the User role
• A tenant administrator inherits the SuperRole role unless otherwise configured for the tenant

In Incorta, a user belongs to zero or more Groups, and a Group is assigned to zero or more Roles. Roles are immutable. You cannot create, edit, or delete a Role. Here are the available Roles in Incorta:

Discretionary Access Control (DAC)

With Discretionary Access Control (DAC), a user who owns an object -- schema, business schema, session variable, or dashboard -- is able to control the access to the object. In other words, the object owner defines the Access Control List (ACL) associated with the object. An ACL is a list of users and groups. For each user and group, the owner can set and revoke the access rights. Only the owner of an object can delete the object.

For an object in Incorta, there are three possible access rights:

• Can View: Has view (read) access
• Can Share: Has view (read) and share access
• Can Edit/Manage: Has view (read), share, and edit access

Example

Luke is the owner of a dashboard. Luke shares the dashboard with Jake, granting View access to Jake. Luke also gives Share access to the Analyst group and Edit access to Niki. Paul belongs to the Analyst group, and for that reason can both view and share the dashboard. Paul shares the dashboard to the Business group. Niki, who has Edit access to the dashboard, changes the access rights for the Business group, giving that group Edit access to the dashboard. Rachel belongs to the Business group and attempts to delete the dashboard. As Luke is the owner of the dashboard, Incorta prevents the deletion. Luke changes the access rights for the Analyst and Business groups from Edit to Share.

To learn more about best practice for DAC and RBAC in Incorta, please review Guides → Organize Content.

It is also possible to review object permission history in Incorta. Incorta captures access right assignments in the Incorta Metadata database. The Permissions Dashboard provides a view to permission grants and revocations for all objects in Incorta.

Audit Access

Incorta tracks all user activities for a given tenant in an Audit.csv file. User activities include when a user:

• Sign ins
• Creates, edits, shares, and deletes an object such as a dashboard
• Loads data for a schema or a table
• Downloads data for an insight in a dashboard
• Signs outs

Incorta writes a log of all user activities for a given tenant to an Audit.csv file. To learn more about Incorta’s Audit capabilities, please review SOX Compliance.

All update and delete actions performed by users against Incorta objects are also captured and stored in Incorta’s metadata database in the Action table. Incorta provides an Audit Action dashboard for tracking this history.

Data Security

As a Unified Data Analytics Platform, Incorta ingests data from external data sources and allows users to upload local files and folders. In this regard, Incorta mirrors and copies data from the specified source systems. Incorta users are unable to modify or edit data that Incorta ingests.

By default, Incorta encrypts sensitive data such as user passwords, data source passwords, data source security tokens, and data on disk using AES-128. For more information about AES encryption please review Advanced Encryption Standard (AES).

Incorta stores the secret key internally within application code. This key is not exposed and cannot be modified.

For data ingested into Incorta, there are several security considerations:

• Encryption of data source credentials
• Encryption of data at rest
• Encryption of defined table columns
• Row Level Security (RLS)

Encryption of data source credentials

A data source such as a MySQL database requires a username and password. Incorta encrypts the password that Incorta stores for the connection. When making a data source connection, Incorta decrypts the encrypted value.

Encryption of data at rest

Incorta ingests data from external data sources and allows users to upload local files and folders.

Local files and folders

A user may upload one or more files and one or more folders to Incorta. Incorta copies the files from the local machine and stores the files in the Tenants directory in Shared Storage.

Incorta does not encrypt uploaded local files and folders. Incorta does support using password protected MS Excel Files.

External Data Source

Some data source connectors natively encrypt ingested data. For example, an Apache Kafka data source automatically encrypts data that Incorta consumes from the specified Kafka topic. The encrypted data is in CSV format.

Other data source connectors that ingest data from an application or service may not encrypt data. Oracle Fusion, Google Drive, Box, and DropBox are examples of data source connectors that currently do not encrypt ingested data.

To find out more about encryption support for ingested data, please review Supported Data Source Connectors and connect with our support using the Contact Support form.

Encryption of defined table columns

Using the Table Editor for a table in a given schema, a schema developer can explicitly define an Incorta column for encryption.

Incorta suggests storing all sensitive data using the Column Encrypt property for a column in a table in a schema.

When loading data, Incorta encrypts these columns using 128-Bit AES encryption and stores the data in encrypted form on disk in Shared Storage. Shared Storage consists of Direct Data Mapping (DDM snapshot) files and Apache Parquet files. Only when reading the encrypted data does Incorta decrypt the data.

Row Level Security (RLS)

Using the Table Editor for a table in a given schema, a schema developer can implement a Runtime Security Filter. With a runtime security filter, it is possible to implement Row Level Security (RLS) with Incorta. Row level security typically determines which user or group of users has view access to one or more rows. To learn more about runtime security filters and their practical application for RLS, review the following documentation and community article:

• Runtime Security Filters
• Data Security using Session Variables

Additional Security Considerations

Incorta is a Java Virtual Machine (JVM) web application that ingests potentially sensitive data and stores data in-memory and in shared storage. As a Unified Data Analytics Platform that potentially stores sensitive data, there are several additional security concerns that Incorta endeavors to address. In general, these security concerns are:

• Injection attacks
• Materialized views and Apache Spark
• User impersonation
• User invitations

SQL Injection

There are several places where a user that inherits the Schema Manager role can specify a SQL statement.

To help prevent SQL injection, Incorta only accepts SELECT statements. A table that supports an incremental load uses a parameterized syntax. Incorta bounds the parameter value using a bound parameter in the Java Database Connection (JDBC) itself. Bound parameters in JDBC protect against SQL Injection.

As additional protection, Incorta always recommends that data source connectors specify user credentials with read only access to the source data.

Materialized Views and Apache Spark

In Incorta, a materialized view is a type of table in a schema that requires Apache Spark for data materialization and enrichment.

SparK SQL is a declarative language. Incorta only supports SELECT statements. However, because PySpark is Python for Apache Spark, there is the potential for direct command and reference injection within a materialized view using Python code. For example, in Python, a programmer can import the os library, and in doing so, view all the contents of a directory.

To limit this exposure, Incorta recommends the following:

• Assign the Schema Manager role sparingly to groups as this role allows users to create and edit schemas.
• Regularly analyze PySpark code within a materialized view

User Impersonation

A user that inherits the SuperRole has the ability to impersonate a user. An impersonated user receives an email notifying them of their impersonation. However, this requires SMTP configuration for the Incorta Cluster.

To limit the possibility of unwanted user impersonation, Incorta strongly encourages that security administrators limit the number of users that inherit the SuperRole as well as configure SMTP for the Incorta Cluster.

User Invitations

Starting with the 22.1.0 release, the Super User tenant administrator or a user with the SuperRole in an Incorta cloud cluster can invite external users to have access to the tenant via email. For each valid email address that you specify and does not exist in the cluster, an inactive user account is created and an invitation is sent. The invitation email contains a link that allows an external user to accept the invitation, create the account password, activate the user account, and access the shared tenant. The email address will be the display and login names of the invitee’s user account. Other user account settings, such as the language and calendar, will be the same as the inviter user.

While this feature is enabled by default for trial users, Incorta customers have this feature disabled by default. The Super User tenant administrator must enable it per tenant in the Cluster Management Console (CMC) → Tenant Configurations → Security.

For more information, refer to Security Manager → Manage Invitations.