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

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.

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 Identity and Access Management (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 KMSAutomatic 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 CloudCustomer Managed Keys integration. Note that this is different than a completely new AWS Key and doing a Qlik CMK key provider change to that new key, which forces a complete re-encryption of the tenant. See Configuring tenant encryption.

• 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:

• Managing keys
• Authentication and access control
• Security

Transitioning from Single Region Key to Multi-Region Key

Customer Managed Keys supports Multi-Region Keys to support Disaster Recovery Processes. If you are currently using a Single Region Key, we recommend you create a Multi-Region Key to seamlessly use your tenant in a back-up region in case of an outage in your primary region.

For information on how to create a Multi-Region Key, see AWS KMS Multi-Region Key for Disaster Recovery (DR).

CMK limitations and considerations

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

• After you configure the tenant to use your own CMK, you can revert back to use Qlik Internal KMS encryption, or change the key to a different CMK.

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

• CMK supports only symmetric encryption keys.

• CMK has transitioned from Single Region Keys to Multi-Region Keys to support Disaster Recovery processes.

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