Encryption and BYOK
The protection of client data on our SaaS platform is of principal importance to Fenergo as a SaaS vendor. We manage the performance, availability & security of the platform and adhere to strict best practices and guidelines to not only follow a secure development process but to meet the high watermark of data protection expected by our clients. On the topic of data encryption, how it is applied to data in the following states is important:
- Data in Transit: where data is traversing a public or private network.
- Data at Rest: where data is stored in persistent storage on a disk.
Encryption
Encryption of Data in Transit
Where communications between USER - to - APPLICATION or APPLICATION - to - APPLICATION (system to system) occurs, the best practice to is to secure that channel of communication. The most common strategy to encrypt web based traffic as it traverses computer networks (public or private) is to use HTTPS. HTTPS is an extension to the HTTP protocol where HTTP traffic is encrypted using Transport Layer Security(TLS). You can read more information on Wikipedia. This is achieved using certificate based public key cryptography and the Transport Layer acts as an encrypted tunnel, where all data in and out is encrypted. Any data intercepted between the points of communication is essentially meaningless to that third party with the exception of network routing meta data. Data can only be decrypted by the systems who established the channel. As illustrated in the diagram below, all points of interaction from the user through to the data stores are encrypted using HTTPS.
Encryption of Data at Rest
The encryption of Data at Rest is concerned with how data is protected when saved to persistent storage, usually after it has been processed. The options for how data can be stored and retrieved has moved on quite a bit from SQL style DBMS platforms. In a cloud native world, fenergo have selected best-fit technologies to meet the many use cases we encounter when offering a globally scaled multi-tenant SaaS platform. A huge benefit of working with Cloud Native Services is how closely integrated they are to one another, and we use AWS KMS and Secrets Manager as security layers on top of the data services employed throughout the platform. These services provide key creation, management and access control to our application components so they can efficiently interact with data stores but those underlying data stores are fully encrypted at all times.
Amazon KMS is used to create 256-bit AES-GCM symmetric encryption keys which are then used to encrypt all data at rest. Then Amazon Secrets manager is used to securely retrieve keys by authorized application components at run time to decrypt and interact with the data. This strategy means that keys are not stored in config files across the various locations of an application where data store access is required. As illustrated below, the event store and all other data stores have their data encrypted at rest on the platform. Clients can elect to Bring Their Own Key (BYOK) and retain deeper control of the data protection process.
Data encrypted under AES-256-GCM is protected now and in the future. Cryptographers consider this algorithm to be quantum resistant. Theoretical future, large-scale quantum computing attacks on ciphertexts created under 256-bit AES-GCM keys reduce the effective security of the key to 128 bits. But, this security level is sufficient to make brute force attacks on AWS KMS ciphertexts infeasible. Read More Here
BYOK (Bring Your Own Key)
Clients who wish to take ownership over the Encryption Key used to secure data at rest can choose to do so provided the decision is made BEFORE their production tenant is provisioned. This is fully supported by Fenergo and we only require permission to access the key in order to use it. This key must be created in AWS KMS and the client is responsible for the AWS Account under which the Key is created. The process for enabling BYOK for clients is achieved across two distinct phases.
- Phase 1: The client creates the key and shares the unique ARN (Amazon Resource Name) with Fenergo.
- Phase 2: Fenergo provision the clients production tenant with reference to the ARN and the client then enables access control so Fenergo can retrieve the key and use it on the production tenant.
Clients can request detailed documentation from the Fenergo Cloud Business Office which outlines the steps required to be taken across Phase 1 and 2. We only support BYOK for Amazon KMS and do not support keys created by clients own Key Generators or HSMs.
Clients cannot request to enable BYOK AFTER the production tenant has been provisioned. this MUST be done beforehand.
BYOK clients are required to manage their own AWS Account. There are many best practices and operational strategies which should be in place when clients take responsibility for production AWS assets and especially something as vital as an encryption key. If the key is removed, client data will be irretrievable by fenergo.