ABS supports encryption at rest for virtual volume data, ensuring that all data is encrypted when written to storage, including the cache and the persistent capacity tier, so that raw data cannot be directly read from the disk. The process of data encryption and decryption remains completely transparent to the client, with no need for any additional adaptation.
In implementation, ABS applies encryption at the virtual volume level. The system generates an independent Data Encryption Key (DEK) for each virtual volume. All data written to the virtual volume is encrypted using the DEK before being persisted, and decrypted with the corresponding DEK when read and returned to the client. Supported encryption algorithms include AES-256 and SM4, which complies with Chinese national cryptographic standards. Users can choose the algorithm according to their security policies and compliance requirements.
To ensure the security of keys, ABS manages them through a Key Management Service (KMS). ABS periodically retrieves the Key Encryption Key (KEK) from KMS and uses the KEK to encrypt each virtual volume's DEK, storing it in the ABS system. KEK is temporarily stored only in memory to support runtime encryption operations and is not persistently saved. ABS supports configurable periodic KEK rotation, which updates the KEK regularly and re-encrypts all DEKs in the system to reduce data risks caused by potential KEK exposure.
ABS supports two types of key management services: built-in KMS and third-party KMS. When enabling data-at-rest encryption, either option can be selected as the key management service, but both cannot be enabled simultaneously.
When using the built-in KMS, the system generates a Master Encryption Key (MEK), which is used to encrypt the KEKs of different encryption algorithms. The MEK is not stored in its complete form on a single node. Instead, it is split according to the cluster size and topology and stored in a distributed manner across multiple nodes. For clusters with 3 or 4 nodes, even if a single node is compromised, the complete MEK cannot be reconstructed. For clusters with 5 or more nodes, the MEK remains secure even if 2 nodes are compromised.
In third-party KMS mode, ABS manages master keys by integrating with an external KMS system. The system periodically retrieves the Key Encryption Key (KEK) from the external KMS and uses it to encrypt the DEK of each virtual volume before storing it. The KEK is only temporarily stored in ABS memory to support runtime encryption and decryption operations and is never persistently stored. The generation, storage, and rotation of the KEK are fully handled by the external KMS system. ABS supports configurable periodic KEK rotation, allowing the system to regularly re-encrypt stored DEKs using a new KEK to reduce security risks associated with long-term key usage.
If the third-party KMS becomes unavailable while the ABS system is still running, the system can continue providing I/O services for encrypted volumes using the cached KEK and can still create new encrypted volumes, although KEK rotation cannot be performed. If ABS is restarted and the KEK stored in memory is lost, existing encrypted volumes will temporarily be unable to perform I/O operations, and new encrypted volumes cannot be created. Non-encrypted volumes are not affected. Once connectivity to the third-party KMS is restored, the system will automatically resume normal operation.
To mitigate the impact of prolonged KMS unavailability on business continuity, ABS provides a DEK export and import mechanism for encrypted volumes. Users can export all virtual volume DEKs in the cluster as an external key file, encrypted with a user-specified password. If the KMS becomes unavailable and cannot be quickly restored, importing this key file allows the system to restore I/O access to existing encrypted volumes, although new encrypted volumes still cannot be created.
