Infrastructure security

Overview

Security is at the core of Strivacity’s culture: we’ve taken it upon ourselves to incorporate security best practices in our design and software development processes from day one. It’s woven into the fabric of our services, never treated as an afterthought.

In our mission to build security into Strivacity by design, we made the following infrastructure decisions:

Encryption at rest

Microservice volumes are encrypted with keys specific to each customer and user
For key management, we use our primary cloud provider, Amazon Web Services' (AWS) Key Management Service (KMS)
The (AWS) Key Management Service (KMS) uses a distributed fleet of FIPS 140-2 validated hardware security modules (HSMs).
We use 256-bit symmetric customer master keys (CMKs)
The encryption algorithm behind symmetric CMKs is known as SYMMETRIC_DEFAULT
The SYMMETRIC_DEFAULT algorithm is based on Advanced Encryption Standard (AES) in Galois Counter Mode (GCM):
- ciphertext generated by this algorithm supports additional authenticated data (AAD)
- GCM provides an additional integrity check on the ciphertext

📘
You can find further technical details in AWS's Key Management Service cryptographic details.

Customer Master Keys (CMKs)

Symmetric CMKs are used in the following places:

Persistent Volume Claim(PVC) / Disk encryption Stateful applications and those requiring data persistence between application outages. In all cases (at the time of this writing), we’re following the applications' documented recommendation for encryption. This applies to redis, influx, mongo.
etcd encryption (via kops) This is also disk encryption but is performed at a "lower" layer than the other disks. It's configured when provisioning the Kubernetes cluster, and cannot be changed. We follow the kops' best practices.
Kubernetes Secret encryption Kubernetes-backed secrets required by our applications are configured to be encrypted via Key Management Services, instead of the default base64 encoding.
Backups (snapshots and s3) Our backup solution, Velero, ensures our disk backups and also the backups of Kubernetes objects are encrypted. The Kubernetes objects are stored encrypted in AWS S3.

Encrypting databases

Similar to microservice volumes, we can encrypt our relational databases (RDS), whether serverless or not, with customer master keys (CMKs) specific to each customer.

Private Cloud

Using a dedicated cloud, or isolated Virtual Private Cloud (VPC), for a Strivacity production instance brings the probability of compromise to near zero if an attack on another installation occurs.

Encryption in transit

Traffic coming from external parties is only allowed in via TLS encrypted channels
Using AWS Server certificates, load balancers receive TLS encrypted requests coming from clients
Outbound traffic from production instances to external services is only allowed through TLS
For interservice communications, we use the Transport Layer Security (TLS, successor of SSL) protocol on top of our Service Mesh implementation

Our microservice architecture

If we were to put Strivacity under a microscope, we would notice that the product is an orchestration of numerous microservices – small virtual machines – working together, with each service responsible for a distinct task. The collaboration between these microservices is not very different from the way an actual orchestra works: each section comes together in its unique function to bring 🎶symphonies🎶 to life. In our case, the symphony to your brand's ears is the successful implementation of a secure, smooth, and efficient customer identity and access management solution.

Encryption in transit

📘
In short, encryption in transit is the concept of encrypting data before it's transmitted to a target service – a fellow microservice or an external service – and verifying the data upon arrival while authenticating endpoints. Each service partaking in this data exchange needs a certificate so the services know that they can trust each other with the encrypted data packages.

Microservices form a network of ‘mini computers’ inside your production instance where they communicate with each other. Although they each have their separate databases where they store data relating to their unique service only, they all come together to work in unison toward a common goal.

Should any malicious actor find their way into the production instance, microservices need to be protected by a reliable, encrypted channel in order to maintain uninterrupted communication and to protect sensitive data – especially customer data – from bad actors.

That’s where our pick of cryptographic solutions come in for taking care of encryption in transit: Service Mesh and Transport Layer Security (TLS).

Service Mesh

Circling back to our orchestra analogy, just as groups of musicians of various instruments need a conductor to keep them in sync, microservices also need a control mechanism to manage them.

Strivacity uses Service Mesh, a microservice paradigm that's (theoretically) in charge of setting the stage for a secure, continuous service-to-service communication inside your instance. Theoretically, because actually, it's one of Service Mesh's implementations that'll get the job done. This implementation will be responsible for controlling communication, routing traffic, and issuing certificates to microservices to fulfill the requirements of Transport Layer Security (TLS).

Transport Layer Security (TLS)

TLS, the successor of the deprecated Secure Socket Layer (SSL), is a protocol that sets the ground rules for interservice communications. The TLS protocol secures communication channels by encrypting data that travels between microservices or is dispatched from the production instance to an external service (a third-party product). It does this to protect sensitive data from potential eavesdroppers.

📘
Learn more about the basics of TLS cryptography.

✅
You can be certain that customer data is kept safe from unwanted eyes: we keep it hidden even from ourselves. No matter the environment where your production instance will run – our primary cloud provider, your private virtual infrastructure, or even physical machines – customer data never leaves the production environment.

Also, Strivacity only accepts packages coming from third-parties that have a trusted TLS certificate.

Encryption at rest

📘
In short, encryption at rest is the concept of protecting data stored on a disk. Your data used by microservices is diced up and stored in chunks. Each chunk of data is encrypted with an individual encryption key. In line with the integrity principle of information security, these encrypted data chunks cannot be tampered with when accessed. Someone would have to have the key to modify them. Access to encryption keys is also controlled through a key management service.

We’ve mentioned earlier that each microservice uses a separate database where they store data that are only relevant to them.

From our ‘mini computer' microservice’s perspective, these 'mini' databases are recognized as disks. These disks are located in the same cloud environment but are recognized as entirely separate spaces. The official term for these is ‘volumes’, but for simplicity’s sake, we’ll stick to ‘disk’ for now.

Disks are encrypted with keys specific to each production instance which means your brand's Strivacity instance operates 100% independently. For encryption, we use the customer master keys (CMKs) of our primary cloud provider, Amazon Web Services' (AWS) Key Management Service (KMS) with the SYMMETRIC_DEFAULT key spec.

SYMMETRIC_DEFAULT key specification

In Amazon Web Services' Key Management Services, a symmetric customer master key represents a 256-bit encryption key that never leaves AWS Key Management Services unencrypted. To use a symmetric customer master key, you must call AWS Key Management Services. Symmetric keys are used in symmetric encryption, where the same key is used for encryption and decryption.

The encryption algorithm for symmetric customer master keys is also known as SYMMETRIC_DEFAULT. Currently, this represents a symmetric algorithm based on Advanced Encryption Standard (AES) in Galois Counter Mode (GCM) with 256-bit keys, an industry standard for secure encryption. The ciphertext that this algorithm generates supports additional authenticated data (AAD), such as an encryption context, and Galois Counter Mode provides an additional integrity check on the ciphertext.

For technical details, see AWS Key Management Service Cryptographic Details.

📘
For more technical details you can turn to AWS's Key Management Service cryptographic details.