Architecture

Microservices architecture

If we were to peel back the layers of Strivacity to its core, we would find multiple microservices-based applications operating closely together. While each component is responsible for a different business capability and can be allocated exclusive resources, all of them work together in an auto-scaling, self-healing, and consistent orchestration platform.

Benefits of our architecture

Failover zones for low and high environment

Our cloud-native architecture is designed for robustness, ensuring instance backup if cloud services are disrupted. Both development (low environment) and production (high environment) instances run concurrently in three failover or high-availability zones within the same AWS region. The production traffic is not affected by one failing zone since traffic is served in parallel from all three zones.

Handles traffic spikes

Native autoscaling takes care of horizontal and vertical scaling based on utilization metrics, taking into account resource constraints. Resource requests and limitations are defined beforehand to brace for incoming traffic or keep disruptions caused by scaling activities under control.

Customer data

Our container orchestration platform allows us to make design choices that best serve the highest security requirements for storing data and resource allocation. We take an isolation-first approach that provides data isolation on multiple levels:

• No shared infrastructure Different brands do not share the same resources*. Strivacity is using dedicated AWS resources for each brand and services are running on those dedicated resources.

🚧

Apart from the joint use of Amazon Web Services (AWS) which uses encryption every step of the way. You can find out more abour how we implemented encryption in our dedicated virtual privare cloud service at Infrastructure security.

• No shared databases Application instances do not share a single, centralized database. Each of them is designed to operate with a dedicated or isolated database. This approach ensures that customer data is not commingled, mitigating the impact of potential data breaches and enhancing performance.
• No shared networking Security within every Strivacity production instance is ensured by the segmentation of network traffic. All network communication is also encrypted using brand-specific encryption keys.

Available regions and data residency

Our underlying infrastructure allows us to implement data residency policies that can effectively meet your requirements. Your data can reside in any AWS region.

Strivacity can be deployed to any of the following regions/countries, globally:

Requesting additional regions

Additional Strivacity instances provide the following benefits:

1. Faster response times to your regionally hosted application.
2. Latency reduction between Strivacity and your regionally hosted applications.
3. Enforcement of data sovereignty (ensure that your customers' PII never leaves the country that your instance is deployed to).
4. Centralized management grouped to the regions of your choosing.

📘

If you require an additional region, please contact Strivacity customer success at [email protected].

Infrastructure security

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 Level 3 validated hardware security modules (HSMs).
• We use 256-bit symmetric customer master keys (CMKs).
• The encryption algorithm behind symmetric CMKs is known as AES-256-GCM.
• The AES-256-GCM 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:

• Data stored on disks
• State of the microservice architecture
• All secrets required for the operation of the application
• All backups

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 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 TLS protocol on top of our Service Mesh implementation.

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 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.

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.