Data Storage and Encryption with BYOK, BYOKMS and BYOKV for Archive

    NOTE: Currently BYOKMS is only available with AWS KMS.

    General

    For Own customers without BYOK, BYOKMS, BYOKV enabled, their archived data is stored within Own’s own S3 Bucket or Azure storage account. For S3, each tenant has their own entity within the bucket, separated from other entities. For Azure, each organization has their own container within the storage account, separated from other containers. These are encrypted with Own's encrypted key. Connected by an ETL pipeline is an instance of Elasticsearch. The ETL pipeline ensures that all changes made within the S3 bucket/Azure storage account are updated in Elasticsearch and vice versa. Within Elasticsearch, each client has their own cluster, connected to their entity in the S3 bucket/Azure storage container. This Elasticsearch instance is also encrypted with Own’s key.

    Bring Your Own Key

    Bring Your Own Key (BYOK) for Archive allows customers to create their own encryption keys to add an additional layer of security to their data. Once BYOK is enabled and an encryption key is activated and added to an Archive service, their data is moved to a dedicated bucket/storage account encrypted at rest with the key. Once the bucket is created, a dedicated Elasticsearch instance is created. For S3 customers, this Elasticsearch instance is encrypted with the customer key. For Azure customers, this instance is encrypted by an Elasticsearch Cloud key. An ETL pipeline is created to update data from the new bucket/account to the new Elasticsearch instance. Once the data is copied over, the original client entity in the Own S3 bucket/Azure storage account and original client cluster in the Own Elasticsearch instance are both deleted. Once completed, the customer’s data is officially only accessible with their own encryption key.

    During the encryption process Archive jobs are disabled in order to allow the transfer of data to complete successfully without the new data being lost or duplicated in the process. Any searches in Archive are limited to data archived before the encryption began.

    Key Rotation

    Customers can later archive their key and replace it with another encryption key. When a new encryption key is provided, the client S3 bucket/Azure storage account is redirected to the new encryption key.

    For S3 customers, a new Elasticsearch is created and encrypted with the new key. The ETL pipeline is connected to the new Elasticsearch instance and updates the data in the instance. Once the data is copied over, the original Elasticsearch instance is deleted.

    For customers using BYOK, once they upload their wrapped encryption key to Own, the S3 bucket/Azure storage account is redirected to the new key and, for S3 customers, the new Elasticsearch instance is created.

    For customers using BYOKMS or BYOKV, rotating their key automatically redirects their S3 bucket/Azure storage account. Once they confirm the rotation in Archive Console, the new Elasticsearch is created.

    Any searches in Archive are limited to data archived before the key rotation began.

    Key Revocation

    Active encryption keys can also be revoked, resulting in immediate inaccessibility to the underlying data.

    Removing the BYOK Service

    If a customer chooses to remove BYOK, then their data will be transferred back to the Own S3 bucket/Azure storage account and Elasticsearch instances. A new entity/container is created in the Own S3 bucket/storage account and the data from the client dedicated bucket/storage account is copied there. An Elasticsearch cluster dedicated to the client is created and an ETL pipeline connecting it to the client entity/container is used to transfer data from the entity to the cluster. Once the procedure is completed, the initial bucket/storage account and Elasticsearch instance are deleted.

    During the encryption removal process Archive jobs are disabled in order to allow the transfer of data to complete successfully without the new data being lost or duplicated in the process. Any searches in Archive are limited to data archived before the encryption began.

    BYOK vs. BYOKMS vs. BYOKV

    Bring Your Own Key

    With Bring Your Own Key (BYOK) the customer provides us with their encryption key for use encrypting their own data.

    The customer is provided with our Public Key which is used to wrap the customer’s encryption key before uploading it to our platform. This allows the customer to provide us their key without exposing it.

    Rotating their key requires repeating the process of wrapping the key and uploading it through the application.

    To generate and wrap an encryption key, see:

    Bring Your Own Key Management Service

    With Bring Your Own Key Management Service (BYOKMS) the customer manages their keys within their own key management service, only providing us with an alias to encrypt their data. This alias allows us to create a bucket encrypted with the key without sending us the actual key, providing access to it, or exposing it. 

    The customer can rotate the key in their own KMS, but until the rotation is confirmed in Archive Console, the Archive service is paused and warning messages are raised in both Archive and Archive Console, prompting the user to confirm the rotation.

    WARNING: We cannot be responsible for weak keys, keys generated on a compromised machine, or keys moved through insecure media - all of which weaken the security of the stored data.

    Bring Your Own Key Vault

    With Bring Your Own Key Vault (BYOKV) the customer manages their keys within their own Azure Key Vault. By installing the Own Enterprise application in their Azure account and assigning their key a role assignment to the application, Own can create a storage account encrypted with the key without sending the actual key to Own, providing access to it, or exposing it.

    « Previous ArticleNext Article »