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 ASSO and DATA container files and also to PLOG and backup copies.
Encryption is the process of converting plain data into cipher text which cannot be deciphered without access to the encryption or decryption key.
Decryption is the process of converting encrypted data back to its original form. Decryption of encrypted data requires the decryption key; without the decryption 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 bits and XTS-AES with a key length of 256 bits are supported.
When a database is created, the ASSO and DATA container files of an encrypted database are encrypted when the database is formatted. When the database is accessed, data in the ASSO and DATA container files is encrypted when written to disk, and decrypted on read access.
PLOG and backup copies of encryption enabled databases are written encrypted to disk. Further processing of encrypted PLOG and backup copies requires the key management system used to provide the appropriate keys.
The encryption settings and the key to encrypt and decrypt data (the encrypted data encryption key) are stored in the database’s ASSO container. This enables transparent access to the database for Adabas utilities and application programs.
The key to encrypt and decrypt the data encryption key (the key encryption key) is held in an external key management system. Adabas Encryption for Linux supports a local file-based key management system and AWS key management service.
Note:
Database encryption cannot be disabled.
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 uses two types of key management systems: a file-based management system on the local disk 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 (GCB), acquire the keys for each database. Adabas automatically creates a new KEK with a unique name within the KMS. The KMS API provides a function to create an encrypted DEK. Adabas stores the encrypted DEK along with the unique name of the corresponding KEK in the GCB. The GCB block is the only block in the database that is not encrypted.
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.
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.
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 should not already exist. For existing databases, these ADABCK control parameters ENCRYPTION and KMSTARGET will be rejected.
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. The data itself is not encrypted.
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