Data encryption is used to protect data during transmission and storage. As it enhances data security it is strongly recommended to be used, but since unencrypting and re-encrypting data impacts performance it is possible to elect to not use it if the data being processed does not contain sensitive information and the fastest possible processing is required. The impact on performance depends on the file type, key provider, and volume of data being processed.
Aperture Data Studio supports encrypting exported data files and decrypting imported data files as well as encrypting secrets such as credentials and batches of dataset data elected to be stored within the application, known as data-at-rest.
The supported encrypted file types are:
File encryption (previously referred to as encryption keys) is used for decrypting encrypted source files and encrypting exported files.
Additionally, Aperture Data Studio supports file encryption key management. File encryption keys can be assigned to specific users or roles through RBAC. Users with this capability are able to save, export, and import file encryption keys in a secured manner.
Aperture Data Studio supports password-based encryption for Advanced Encryption Standard (AES) encrypted files.
AES is a symmetric-key algorithm where the same key is used to encrypt and decrypt data.
There is an optional salt value to turn a password into a secret key. Salt is a random value that is used as an additional input to a one-way function that hashes a password.
Data Studio can load data from password-protected Excel (.XLS and .XLSX) files. The files can be protected using an encryption facility based on a specified password. In order to extract the original content from Excel files, the correct password has to be provided.
Aperture Data Studio supports public key encryptions for GNU Privacy Guard (GPG) encrypted files.
GPG is a key-based encryption method which utilizes two cryptographic keys; a public key to encrypt a file and a corresponding private key to decrypt it.
When generating a GPG key pair, a passphrase has to be specified. This is required by the private key; only an authorized user with knowledge of the passphrase can use the private key. This provides a two-layer protection against unauthorized access to the contents of the encrypted file.
Aperture Data Studio also supports GPG digital signatures to ensure file authenticity and integrity. By enabling Verify signature, you can confirm that a file has been signed by a trusted source. To perform this verification, provide the Signature verification public key of the signer. If it is left empty or when verification fails, the system will automatically attempt to extract the public key from the private key.
Aperture Data Studio supports public key encryption for Pretty Good Privacy (PGP) encrypted files.
PGP is a key-based encryption method which utilizes two cryptographic keys; a public key to encrypt a file and a corresponding private key to decrypt it.
When generating a PGP key pair, a passphrase has to be specified. This is required by the private key; only an authorized user with knowledge of the passphrase can use the private key. This provides a two-layer protection against unauthorized access to the contents of the encrypted file.
Aperture Data Studio also supports PGP digital signatures to ensure file authenticity and integrity. By enabling Verify signature, you can confirm that a file has been signed by a trusted source. To perform this verification, provide the Signature verification public key of the signer. If it is left empty or when verification fails, the system will automatically attempt to extract the public key from the private key.
To manage file encryption operations, ensure that:
To create a file encryption key:
To edit a file encryption key:
When importing or exporting any encrypted files, a valid file encryption key is required to ensure that the operation is permitted for the user.
File encryption keys can be pinned to a particular usage in Datasets or Workflows, so that the same file encryption key is used consistently.
When adding a Dataset from an encrypted file, you will need to select an existing file encryption key or enter a new file encryption key to be associated with the Dataset. The file encryption keys available for selection are only those that your user has permission to use.
Once set, this file encryption key will be used whenever the Dataset is refreshed by any user, even for those with no direct permission to access the file encryption key.
File encryption keys are available in different Spaces within the same Environment.
To upload a locally stored encrypted file:
When exporting records using the Export step in the Workflow designer, specify the file encryption key to be used to encrypt the output file. You can also set the required encryption type for the exported file.
Other users with access to the Space can also modify the file encryption key used in the Export step. Once the key has been set, it will be used whenever the Workflow is executed (or scheduled for execution), so will be also accessible to users with no direct permissions to access the file encryption key.
You can also export encrypted files to an external system in the same way. Find out how to export data to an External system.
Aperture Data Studio by default uses the industry standard SHA-256 hashing algorithm to encrypt data. This built-in encryption provider removes the need for an external key service. However if desired it is possible to use a third-party key provider to take advantage of centralized governance, separation of responsibilities and key rotation.
Encryption keys can be used to encrypt:
When creating a new encryption key, select the Type that matches the key management service and authentication method.
Currently available types include:
Built-in key provider managed by Aperture Data Studio. This is the lowest-friction option because it is always available within the product and does not depend on an external secrets or key management service.
Uses AWS Key Management Service (KMS).
Recommended for customers hosting on Amazon EC2, because it uses AWS instance metadata and avoids managing long-lived credentials.
Amazon Metadata uses temporary AWS credentials from the EC2 instance profile (IAM role), so no static access key or secret access key is required in Aperture Data Studio.
Ensure the IAM role attached to the EC2 instance is allowed to use the target customer managed key (CMK) in KMS, including required key actions such as kms:DescribeKey, kms:Encrypt, kms:Decrypt, kms:GenerateDataKey*, and kms:ReEncrypt*.
Uses AWS Key Management Service (KMS).
Amazon KMS requires an access key (or another equivalent AWS credential source) for Aperture Data Studio to assume the IAM role to authenticate and use the customer managed key in KMS.
Ensure the IAM policy allows use of the target KMS CMK, including the required key actions such as kms:DescribeKey, kms:Encrypt, kms:Decrypt, kms:GenerateDataKey*, and kms:ReEncrypt*.
Uses Azure Key Vault with a managed identity.
Recommended for customers hosting on Azure, as a managed identity is generally the more secure option compared to client secrets.
Azure Key Vault (Managed Identity) uses the Azure managed identity of the hosting resource, so no client secret/certificate is required in Aperture Data Studio.
Grant the managed identity permission to the target Key Vault and key, using either Key Vault access policies or Azure RBAC, with the required key operations for encryption and decryption.
Uses Azure Key Vault with an application/client identity.
Azure Key Vault (Client ID) requires an Azure app registration (service principal), including the client ID and client secret/certificate used by Data Studio.
Grant that app registration permission to the target Key Vault and key, using either Key Vault access policies or Azure RBAC, with the required key operations for encryption and decryption.
Each key type has different connection and credential requirements. If connection details are invalid or permissions are missing, the key cannot be used for encryption operations.
When creating or editing a data-at-rest key, apply Use as encryption key for to control where that key can be selected.
For example, enabling Datasets allows the key to be used as the encryption key for new Dataset batches.
Datasets can be configured during dataset creation or on the Edit details page. Use the Encryption key for stored data dropdown to select any key that has Datasets enabled. Changing the encryption key for an existing dataset does not delete existing dataset batches.
When a dataset is updated to use a different encryption key, older existing batches keep their original encryption key. New batches will use the newly configured key.
This means a dataset can contain batches encrypted by different keys over time. This can be verified on the Show batches list screen.
An encryption key cannot be deleted while it is still assigned to an active usage (for example, repository secrets or dataset encryption).
To delete a key, first remove or replace all usages of the key, then delete it.
If a user adds back a match encryption key, retained dataset batches can be decrypted again.
For matching key recovery:
Key rotation behaviour differs between key providers.
AWS KMS automatically decrypts data encrypted with previous key materials while using the latest key material for new encryptions.
Azure Key Vault, however, pins a specific key version during encryption key creation in Aperture Data Studio, so it does not automatically select older key versions for decryption.
To rotate keys in Azure Key Vault, create a new encryption key configured to use the latest key version, then update the active dataset or repository-secret reference to point to the new key.
For any key provider, follow this general rotation approach: create the replacement key, update the active usages to the new key, validate that access and decryption work as expected, and only then retire the old key after all dependent data has been re-encrypted or is no longer required.
Only one data-at-rest encryption key can be active for repository secrets at a time, as the key will be used to encrypt all repository secrets.
If a different key is selected for repository secrets, Aperture Data Studio switches to that key and re-encrypts all repository secrets with the newly selected key.
