Adabas Encryption for Linux provides functionality to protect data-at-rest from unauthorized access. With Adabas Encryption for Linux, data-at-rest refers to ASSO and DATA container files and also PLOG and backup copies. Access to the information in these containers is controlled by means of encryption.
A license for Adabas Encryption for Linux (AEL) is required.
In the context of Adabas Encryption for Linux, data-at-rest refers to the following containers and files:
ASSO
DATA
WORK
TEMP
PLOG
backup copies
Encryption is the process of converting plain data into cipher text which cannot be deciphered without access to the encryption key.
Decryption is the process of converting encrypted data back to its original form. Decryption of encrypted data requires the key. Without the key the original information cannot be recovered.
Adabas Encryption for Linux supports Advanced Encryption Standard (AES) in XTS mode, a symmetric-key algorithm, where the same key is used for both processes, encrypting and decrypting the data.
XTS-AES with a key length of 128 and 256 bits are supported.
When formatting a database, the corresponding containers are encrypted according to the given parameters. All blocks written to disk are encrypted as well. Keys for encryption are managed by ADABAS using the given Key Management System.
Note:
Encryption cannot be disabled for existing databases. Encryption can only be undone by
dumping and restoring a backup with the option ENCRYPTION=NO.
A key management system (KMS), also known as a cryptographic key management system (CKMS) or enterprise key management system (EKMS), is an integrated approach for generating, distributing, and managing cryptographic keys for devices and applications.
Adabas currently supports three types of key management systems: a file-based management system on the local disk, the Azure Key Management System, and the Key Management Service provided by Amazon.
This section describes how Adabas uses the KMS.
Adabas provides the ADATED library for the cryptographic functionality. The KMS function of ADATED uses plugin libraries, also provided by Adabas, for each supported key management system.
Adabas uses two types of encryption keys, the key encryption key (KEK) and the encrypted data encryption key (DEK). The KEK encrypts the DEK, which in turn encrypts the data in the database. The advantage of using two keys is that you can regularly change the key encryption key, so only the data encryption key is decrypted and newly encrypted. The data itself does not have to be decrypted and encrypted again.
Important:
If the KEK is lost or corrupted, the data in the database is
also lost regardless of which KMS is used.
To create a new encrypted database, acquire the keys for each database. Adabas automatically creates a new KEK with a unique name (KEKNAME) within the KMS. The KMS API provides a function to create an encrypted DEK. Adabas stores the encrypted DEK along with the unique KEKNAME of the corresponding KEK and other encryption related settings in the ASSO1 container file.
Select the target KMS by configuring the KMSTARGET parameter for the ADAFRM or ADABCK utility. The possible values are FILE (for a file-based KMS) and AWS (for the KMS provided by Amazon).
When a database starts, the KEK name and the encrypted DEK are read from the ASSO container in the GCB. Both items are passed to the KMS to decrypt the DEK, which is kept in-memory for the entire time the database is running. To decrypt/encrypt any other block from the Adabas containers, you must use the decrypted DEK.
Blocks from the containers are decrypted during the read operation and stored in the buffer pool decrypted. Modified blocks are encrypted during the write operation of a buffer flush and written encrypted back to disk.
The file-based key management system uses a local disk file to store the key encryption keys. Database operations are performed only with the KMS file.
Select the file-based KMS by configuring the KMSTARGET=FILE parameter for either the ADAFRM or ADABCK utility when creating a database. The selected KMS type is stored in the database.
The file to store the keys is specified by the ADAKMSFILE environment variable. You can specify a fully qualified path name or directory name. The default location is $ADADATADIR/etc and the default file name is adatedkmsfile.db.
The KMS file is stored encrypted in the file system. Nevertheless, access to it must be restricted with operating system features. File permissions must allow access only to the user/group that will run Adabas utilities.
 |
Warning: It is recommended to implement a dedicated backup strategy to have the file-based KMS available in case of a disaster recovery. Without the corresponding KEK, it is not possible to restore Adabas backup copies or use encrypted data. To avoid this effort and possible risks, cloud-based key management services should be preferred. |
Amazon Web Services (AWS) provides a built-in key management service which you can use when Adabas is on an AWS virtual machine. The AWS KMS allows for the creation and storage of the key encryption key. The encrypted DEK is passed to the AWS KMS for decryption.
Select the AWS KMS by configuring the KMSTARGET=AWS parameter for either the ADAFRM or ADABCK utility when creating a database. The selected KMS type is stored in the database.
Within AWS, you must configure your virtual machine to be able to access the AWS Key Management System. The Adabas AWS plugin uses a number of AWS APIs and KMS resources, which are managed through AWS Identity and Access Management (IAM). To use the APIs and access the specific KMS resources you must create an IAM role with a permission policy. The IAM role must be assigned to an EC2 instance (Amazon Elastic Compute Cloud) so that the EC2 instance can assume that role during its lifetime. The IAM role can be used for multiple EC2 instances.
For more information on how to create an IAM role and assign it to an EC2 instance, see the AWS Identity and Access Management and Amazon Elastic Compute Cloud documentation.
Azure provides a key management service for generating, storing, and accessing secrets, such as cryptographic keys. You can use this service when running Adabas in the Azure cloud. The cryptographic keys are stored and accessed in an Azure Key Vault. Adabas can use the Azure Key Management Service to store the keys used in an encrypted database.
To use the Azure Key Vault for Key Management purposes, specify KMSTARGET=Azure for either the ADAFRM or ADABCK utility when creating a database. The selected KMS type is stored in the database.
You must reference the key vault with the following environment variable.
export AZURE_KEY_VAULT=<key-vault-name>
To access the key vault, you must be an authenticated user with access rights. It is recommended to use a managed identity if Adabas is run on the Azure Cloud.
To create a managed identity:
Go to the Azure Portal and navigate to the virtual machine or container Adabas is running on.
Select Identity.
In the tab System assigned, set the Status to On. This creates a service principal that is tied to the resource.
To authenticate multiple resources, you can use a User assigned managed identity. If you require a different form of authentication, visit the Azure resources.
The created security principal needs to be given access to the Azure Key Vault resource. You can do this on the Azure Portal.
Navigate to the used Key Vault and select Access Policies.
Click Create.
From the Permissions, check Select all for Key Management Operations and Cryptographic Operations.
Choose the created managed identity for authentication with the Key Vault.
Create the access policy.
Note:
As the Key Vault holds the key encryption key of your database, the access rights to
this resource should be held to a minimum.
For more information about the Azure Key Vault, managed identities, or authentication with Azure, you can visit Microsoft Learn.
Encrypted databases are created with Adabas utilities ADAFRM and ADABCK.
ADAFRM
The control parameters ENCRYPTION and KMSTARGET specify the encryption algorithm and the key management system to be used. The formatted ASSO and DATA container files are encrypted according to the parameter values.
ADABCK RESTORE/OVERLAY
The control parameters ENCRYPTION and KMSTARGET specify the encryption algorithm and the key management system to be used. The formatted ASSO and DATA container files are encrypted according to the parameter values.
As the target database is created and containers are encrypted, it must not already exist. For existing databases, these ADABCK control parameters ENCRYPTION and KMSTARGET will be rejected. An existing database will always retain its encryption settings, even in the case of "no encryption".
The encryption settings include the encryption algorithm, the key management system and name of the key encryption key.
The ADAREP control parameter SUMMARY shows the encryption settings of an encrypted database.
The ADABCK control parameter SUMMARY shows the encryption settings of an Adabas backup copy of an encrypted database.
The Adabas backup copy of an encrypted database contains the encryption settings such as the encryption algorithm and key management system of the encrypted database. This data itself is not encrypted, while all database blocks within the backup copy are encrypted with the encryption settings of the database. The KMS containing the KEK of the database must be available to restore this backup.
To restore the Adabas backup copy of an encrypted database as a new database you can
omit the control parameter ENCRYPTION. The encryption settings are taken from the Adabas backup copy.
specify the control parameter ENCRYPTION. The encryption settings are taken from the parameter.
To restore an Adabas backup copy of an encrypted database as a new non-encrypted database, set the control parameter ENCRYPTION=NO.
To restore an Adabas backup copy to an existing database, whether encrypted or not encrypted, omit the control parameter ENCRYPTION. The data is restored according to the target database’s encryption settings.
Access to an encrypted database is transparent to Adabas utilities. The encryption information in the database’s ASSO container is interpreted and data is encrypted and decrypted accordingly. This implies that non-encrypted data that is loaded into an encrypted database is encrypted when it is written to the container files. And encrypted data is decrypted on read access.
Access to an encrypted database is transparent to the Adabas direct call interface. The encryption information in the database’s ASSO container is interpreted, and data are encrypted and decrypted accordingly. This implies that non-encrypted data that is stored in an encrypted database is encrypted when it is written to the container files. And encrypted data is decrypted on read access.
A license for Adabas Encryption for Linux (AEL) is required.
Adabas Encryption for Linux does not require any specific configuration.
Important:
If the Adabas file-based key management system is used,
all Adabas utilities require access to the file
$ADADATADIR/etc/adatedkmsfile.db. Otherwise an encrypted
database becomes unusable.
In order to create an encrypted database use either ADAFRM to format a new database, or ADABCK to restore or overlay an Adabas backup copy of a non-encrypted database.
ADAFRM ENCRYPTION=AES_256_XTS | AES_128_XTS
KMSTARGET=FILE (default) | AWS
The following example shows how to create an encrypted database with the encryption algorithm AES_256_XTS. The Adabas file-based key management system is used (default: KMSTARGET=FILE)
adafrm dbid=100 datasize=100 assosize=100 worksize=100 encryption=aes_256_xts
ADABCK ENCRYPTION=AES_256_XTS | AES_128_XTS
KMSTARGET=FILE (default) | AWS
The following example shows how to restore an encrypted database with the encryption algorithm AES_256_XTS from an non-encrypted Adabas backup copy. The Adabas file-based key management system is used (default: KMSTARGET=FILE). In this example, BCK001 is a backup copy of a non-encrypted database.
adabck dbid=100 restore=* encryption=aes_256_xts
The following example shows how to overlay an encrypted database with the encryption algorithm AES_128_XTS from an non-encrypted Adabas backup copy. The Adabas file-based key management system is used. In this example, BCK001 is a backup copy of a non-encrypted database.
adabck dbid=100 overlay=* encryption=aes_128_xts kmstarget=file
Note:
The control parameter ENCRYPTION is rejected if the
database to be created already exists.
ADAREP SUMMARY and ADABCK SUMMARY can be used to show the encryption settings of an encrypted database.
ADAREP SUMMARY
The following example shows the encryption settings of an encrypted database.
adarep dbid=100 summary
ADABCK SUMMARY
The following example shows the encryption settings of an encrypted database within a backup copy (BCK001).
adabck summary
Both reports show the current encryption algorithm, the key management system and the name of the key encryption key.
ADABCK, can be used to restore or overlay a non-encrypted database from the backup of an encrypted database.
ADABCK ENCRYPTION=NO
The following examples show how to restore or overlay a non-encrypted database from an Adabas backup copy of an encrypted database. In these examples, BCK001 is a backup copy of an encrypted database.
adabck dbid=100 overlay=* encryption=no
adabck dbid=100 restore=* encryption=no
Access to an encrypted database is transparent to the Adabas utilities and to the Adabas direct call interface. The data are encrypted on write access, and decrypted on read access, according to the databases’s encryption settings.
The following examples show that Adabas utility calls work transparently for both encrypted and non-encrypted databases. If necessary, non-encrypted data are encrypted during import or load operations.
adaord dbid=100 import=(1-60)
adavfy dbid=100 file=* data index