Skip to content

Encryption & BYOK

All customer data is always encrypted, in transit, and at rest. We use an up-to-date TLS 1.x protocol for all control communications, including data transfer between Afi components, to ensure all traffic is encrypted. For data at rest, we use AES 256-bit, one of the most secure encryption protocols.

You can learn more about security and privacy by visiting the page: https://afi.ai/compliance

In addition to Afi-managed data encryption, customers can use their own encryption keys (BYOK) for data at rest. Afi supports all major Key Management System (KMS) providers including Google KMS, AWS KMS, and Azure KMS.

Bring-Your-Own-Key (BYOK) is the best-practice solution to strengthen cloud backup security by using customer-managed encryption keys to encrypt backup data. Cloud Security Alliance (CSA) and NIST recommend using the BYOK approach as a way to increase security for data and reduce risks while working with cloud providers.

Why your organization needs a Bring-Your-Own-Key backup?

Afi Backup BYOK capabilities can help you to solve the following problems:

  • Comply with regulatory or contractual requirements and internal security policies. Encryption key self-management can be required or recommended by your regulatory or contractual requirements, and the BYOK approach allows you to satisfy these requirements with minimal configuration on the user side.
  • Increase control over your data and mitigate the risks. BYOK approach allows customers to suspend or revoke Afi application access to backup data at any moment, giving you an additional level of control over your data and reducing security risks. Also, BYOK serves as a cryptographic data removal mechanism if you decide to terminate your account at any time for any reason.

How does Bring-Your-Own-Key encryption work with Afi?

Afi Backup provides an option to manage an encryption key on a user side using Google Cloud KMS (Key Management Service), Azure KMS or Amazon Web Services (AWS) KMS. When the BYOK feature is configured, the Afi Backup system will use the user's key to encrypt backup data, while the user maintains full control over the encryption key and can revoke access to backup data anytime.

Afi backup encryption key chain works the following way - a KMS key (either an Afi-managed one or a customer-managed one) is used to encrypt a tenant encryption key, referred to as a Secret and managed on the Service → Settings → Secret tab in the Afi portal. In turn, a tenant encryption key (Secret) is used to encrypt per-backup encryption keys that are used to encrypt low level data encryption keys for a specific backup. Such scheme allows to easily switch from an Afi-managed KMS key to a customer-managed KMS key or even between different customer-managed KMS keys as well as rotate a master KMS key regularly. When a master KMS key is replaced or rotated, the Afi service will use a previous master key or an older version of a rotated key to decrypt a tenant encryption key and re-encrypt it with a new master KMS key.

Info

Please note that if you delete a KMS key on Google side or a Secret on the Afi side before re-encrypting your backups with a new Secret, you will lose access to your backup data, and it will not be possible to recover it.

If you want to replace a KMS key, please follow the procedure below:

  • Create a new Secret on the Service → Settings → Secret tab in the Afi portal with your new KMS key.
  • Replace your old Secret with the newly created one in your backup SLA policies on the Service → Settings → SLA tab.
  • Make sure that all resources with a backup in your tenant are protected with backup SLA policies with the new Secret configured, including archived resources. If some resources in a tenant are not protected at the moment, but have a backup, you should protect them with a backup SLA policy as well.
  • Trigger a backup for all resources in a tenant and wait until the backups are completed. The Afi service will trigger backup jobs both for active and archived protected resources and re-encrypt their keys.

Once the backups are finished, their backup keychains will be fully re-encrypted with a new Secret and an old Secret as well as an old KMS key will no longer be needed. Due to sensitivity of this procedure, we advise to keep an old Secret and an old KMS key for several months before deletion to make sure that you don't loose access to your backup data accidentally. Please contact the Afi Support if you have deleted a Secret accidentally and want to recover it. When you switch from an Afi-managed encryption key to a customer-managed one, the default Afi-managed Secret will be kept by the service indefinitely.

You can disable all key versions or revoke Afi service account access to a key at any time to make all your backup data inaccessible by Afi application. Please note that disabling a key doesn't interrupt backup and recovery operations that started before the key was revoked.

All secrets and keys in an encryption keychain are stored in encrypted format on the Afi side and require either a corresponding Afi-managed or a customer-managed Google Cloud KMS master key to be re-encrypted. For performance reasons an encryption key associated with a Secret is cached in a service memory for several hours after it is re-encrypted for a backup job to be performed or when a backup is accessed on the user side, so if you want to test a KMS key revocation, you should wait for a few hours before access to the backups is fully revoked. After a cached key expires, the Afi service will no longer be able to decrypt it again with a revoked KMS key and the backup access will be completely disabled until the revoked KMS key is reactivated.