Skip to main content Skip to complementary content

Tenant encryption

When a tenant is created, Qlik Cloud uses multiple layers of security to protect your data. By default, each tenant is separated from other tenants by a uniquely generated set of encryption keys that are managed by the Qlik encryption service to encrypt content in the tenant. Each tenant’s keys are separate from the keys that Qlik uses to secure service-to-service communication.

Qlik Cloud uses the following encryption standards:

  • In transit—TLS 1.2 encryption

  • At rest—AES-256-GCM encryption

  • Within the platform (after authentication with a designated IdP)—Signed JSON Web Tokens (JWTs) to ensure integrity, authenticity, and non-repudiation

Customer Managed Keys (CMK)

Some highly regulated industries, such as health care, must meet strict regulatory rules for security and compliance. Additionally, many commercial customers leverage data classification approaches for their market-sensitive data to determine if additional security techniques are required for specific data sets. These stricter security requirements might include the requirement to control the encryption keys that are used to encrypt and decrypt sensitive cloud data. Qlik Cloud allows you to use Customer Managed Keys to bring your own key (BYOK) as an encryption option to secure your tenant data at-rest within Qlik Cloud.

Encryption with CMK is applied at the tenant level. Tenant admins can configure tenant encryption to use a CMK. Qlik Cloud supports the following Key Management Service (KMS) providers:

  • Qlik Internal KMS (Default)

  • Amazon Web Services (AWS) KMS

Information noteQlik Forts, Qlik Sense Mobile SaaS, and Data Gateway - Direct Access do not support or use encryption with CMK. CMK supports encryption only at the tenant level for tenant data stored at rest. CMK is not used with the encryption of data in motion or with at-rest data on a mobile device, fort, or data gateway.
Information noteCMK is not available with Qlik Sense Business.

Customer Managed Keys and HIPAA

Qlik Cloud can host Personal Health Information (PHI) that is subject to the regulations in the US Health Insurance Portability and Accountability Act of 1996 (HIPAA) provided that customers use Customer Managed Keys and sign a HIPAA Business Associate Agreement (BAA). While Qlik Cloud can support customers through their HIPAA regulatory requirements, customers using Qlik Cloud are responsible for their own HIPAA compliance. Use of Customer Managed Keys is mandatory to put PHI into Qlik Cloud. For more information, see Trust and security at Qlik.

Overview of Qlik Cloud encryption architecture

The following diagram provides an overview of the Qlik Cloud encryption service that encrypts data in the tenant. If your tenant is configured for CMK using AWS KMS, each time a service in Qlik Cloud is required to encrypt or decrypt data, the encryption service calls AWS KMS and uses your AWS KMS key. Otherwise, by default, tenant data is encrypted using the datakeys generated with Qlik Internal KMS.

Qlik Cloud encryption architecture with CMK

Tenant encryption architecture with Bring your own key

Customer responsibilities with Customer Managed Keys

With CMK, customers have full control over their keys. The customer's organization is responsible to create, maintain, and manage all aspects of the key life cycle, including the following areas:

Key setup in AWS KMS

  • Creating an AWS account and using KMS.

  • Creating keys and establishing AWS KMS key management policies around IAM permissions and roles, and who can perform functions, such as creating, disabling, and deleting keys.

Key management in AWS KMS

Once you configure your tenant to use an AWS KMS key to encrypt data at rest, you are responsible for managing the key. It is important to protect your AWS KMS key from being accidentally deleted or disabled. Qlik recommends that you establish a process around these key management functions and others. As these are customer-controlled keys, Qlik Cloud cannot prevent you from disabling or deactivating your CMK.

  • Disabling an AWS KMS key. This action temporarily prevents Qlik Cloud from making API calls to AWS KMS for generating data keys (used for encryption) and decrypting operations. For example, a scheduled reload or task that runs in the background in Qlik Cloud and requires data encryption or decryption will fail while the key (or access to key) is disabled. Re-enabling the key re-establishes access to the tenant.

  • Deleting an AWS KMS key. This action will permanently disable the Qlik Cloud tenant. When you schedule a key for deletion, the tenant is immediately put into disabled mode. This prevents access to the keys and locks the tenant. AWS KMS has an extensive control process around deleting keys that you can customize to meet your needs. For example, you can set a wait period before the key is deleted and use alerts, and you can cancel the deletion during the wait period.

  • Rotating a key in AWS KMS. You can select the AWS KMS Automatic Key Rotation option when defining your key. This will generate new cryptographic material for the KMS key once per year. AWS KMS saves all previous versions of the cryptographic material so you can decrypt any data encrypted with that KMS key. AWS KMS does not delete any rotated key material until the KMS key is deleted. Since AWS KMS transparently decrypts with the appropriate key material, you can safely use a rotated KMS key, and it will not impact your Qlik Cloud Customer Managed Keys integration.

  • Auditing key usage—Consider using KMS key monitoring tools, such as AWS CloudTrail to monitor encryption operations.

  • Controlling key access—Secure the key policy to prevent unwanted access or changes.

  • Ensuring key availability—Maintain and ensure that the key is active. Prevent actions that could result in loss of access. Similar to other AWS services, tenant data will be unavailable if access to AWS KMS is interrupted. AWS KMS includes built-in resilience through regions and high availability zones to achieve redundancies in their infrastructure. For more information about AWS KMS security, see Resilience in AWS Key Management Service.

See the AWS KMS documentation for more information:

CMK limitations and considerations

The following section describes limitations and considerations with CMK in Qlik Cloud:

  • The tenant, whether a new or existing tenant, must be empty of any data when you configure tenant encryption to use CMK. You will receive an error during configuration if there is data in the tenant. However, you can set up your IdP prior to configuring encryption.
  • Once you configure the tenant to use your own CMK, you cannot revert back to use Qlik Internal KMS encryption.

  • Creating a new KMS key for use with a Qlik tenant that is configured for CMK is not supported in this release.

  • CMK supports only AWS KMS as an external key provider.

  • CMK supports only symmetric encryption keys.

  • CMK supports Single Region Keys.

  • Customer Managed Keys is not available with Qlik Forts, Qlik Mobile Client, Data Gateway - Direct Access, or Qlik Sense Business.