Data Security

This section explains general concepts of data security to consider when deploying Exasol.

Authentication methods

Users must be authenticated in order to access the database. Exasol supports the following authentication methods:

Authenticate by password

Database users can be authenticated using passwords. You can enable password authentication using CREATE USER when you create a new database user. To enable an existing user to authenticate using a password, use ALTER USER.

LDAP/AD

LDAP authentication can be used for EXAoperation as well as for authentication of database users. Configuring LDAP authentication includes the following steps:

  • Add the LDAP server URL to the database instance
  • Create the user according to the LDAP DN string

For more information about how to configure LDAP for EXAoperation, see Add Users.

For examples of how to set up synchronization of users between LDAP and Exasol, see this Exasol Knowledge Base article.

Kerberos SSO

Exasol supports single sign-on functionality using Kerberos, which allows users to authenticate to Exasol using their Kerberos credentials.

To use Kerberos based single sign-on in Exasol, a keytab file must be provided by your key distribution center (KDC) or by your Active Directory administrator for Windows. The keytab file contains the service principles for Exasol databases. The keytab file is uploaded using EXAoperation.

For more information, see Kerberos Single Sign-On.

For additional information about how to set up Kerberos authentication to Exasol, see also the following Exasol Knowledge Base articles:

OpenID

Database users can be authenticated using OpenID. You can create a database user authenticated by OpenID using CREATE USER or modify an existing user using ALTER USER. The database checks the OpenID parameters specified in the database and verifies the access token or refresh token for user authentication.

For more information, see Authentication using OpenID.

Multi-factor authentication (MFA)

MFA can be used together with other authentication methods if it is supported by the authentication provider. For more information, refer to the authentication provider’s documentation.

Access management

You can manage access to your Exasol database on several levels:

  • Database level: Exasol provides system privileges and object level privileges to define access to a database and its objects.

    For more information, see Privileges.

  • Row level: You can use this feature to protect table rows based on ownership (tenant protection) or user roles.

    For more information, see row-level-security-lua on GitHub.

  • Cluster level: Exasol separates the DBA role (a SYS user who has all rights within a database instance) from the role of a cluster administrator that manages a cluster using EXAoperation. You can create and manage users for such operational tasks from EXAoperation.

    For more information about how to create system administration users, see Access Management.

Auditing

Exasol allows auditing for sessions and for SQL command execution. Auditing does not require a transaction log or database schema modification, and therefore does not have any performance impact on the system. Auditing captures the following information:

  • All sessions, with information such as driver, client, host, and operating system user.
  • All executed SQL statements, with information such as CPU, network, and hard disk read/write operations.

For more information, see Auditing.

Data encryption

Exasol uses different data encryption algorithms to secure data when it transferred through the network (data in-motion) and when it is stored on a disk (data at-rest).

  • Data in-motion: The encryption when data is transferred through a network.

    Exasol uses TLS encryption for JDBC, ODBC, ADO.NET, CLI, and WebSockets. To enforce encryption on the database, use the parameter -forceProtocolEncryption=1. This parameter will force the connection to be encrypted for as long as encryption is supported.

    For information about how to upload a TLS certificate, see Upload TLS Certificate.

  • Data at-rest: The encryption when data is stored on a disk.

    Exasol uses AES-256, a LUKS enhanced version of cryptsetup, for OS and storage disk encryption. If a license server is encrypted, it needs a LUKS passphrase to be accessible after each boot. For a data node, the passphrase is stored in EXAoperation and the data node is automatically unlocked during the boot. To permanently delete data from a disk, the Linux tool shred is used (7 iterations and a final zero overwrite to hide shredding).

The encryption key is set when a node is created. To change the encryption key, you must reinstall the node. This means that all data on the node will be deleted.

Security in public clouds

Exasol provides enterprise-level security in the public clouds such as AWS, Azure, and GCP:

  • Exasol is always deployed in the user’s cloud account. This means that you always have full control over your data.
  • Exasol can be deployed using existing VPCs and subnets (and their respective counterparts in Azure/GCP) to cater to the customer security requirements or with new networking components.
  • Security groups (and their respective counterparts in Azure/GCP) only require minimum modification for ports. They can further be restricted to be only accessible from the customer’s company network.
  • Encryption in-motion and at-rest is enforced in all public clouds for data protection.
  • Support for Identity and Access Management (IAM)/ Azure Active Directory/ Google Cloud Identity and Access Management (IAM) is available to specify who has access to the resources.
  • You can configure if resources should be accessible through public IPs or not.
  • Exasol’s marketplace offerings always contain the latest security updates for CentOS and its kernel.

Third-party tools

Exasol provides integration with third-party tools for additional data security. For more information, see Data Protection.