Security Architecture
The Bloomreach Engagement Application is provided through the Google Cloud Platform (GCP). We will explain below how we ensure the security and safety of your customer data.
Within Bloomreach Engagement we utilize several security layers to ensure the integrity of our application. These layers include the environment that Bloomreach Engagement functions within and the various offerings of our platform.
Security Overview
The following visualization illustrates the differences between the three instances. The upper portion details how data in transit is secured and encrypted before entering Bloomreach Engagement, while the lower part shows a high-level overview of Bloomreach Engagement architecture and security features for each instance.
Encryption
Whenever we store data there are several layers of encryption. By default, data is encrypted both at rest and in transit.
Encryption at rest protects your data from a system compromise or data exfiltration by encrypting data while stored. To encrypt data at rest, the Advanced Encryption Standard (AES) is used. Our encryption utilizes encryption keys, which are managed by Google (see Encryption at Rest in Google Cloud Platform).
Encryption in transit protects your data if communications are intercepted while data moves between your site and the cloud provider. This protection is achieved by encrypting the data before transmission, authenticating the endpoints, and decrypting and verifying the data on arrival. This level of security is achieved through Transport Layer Security (TLS) to encrypt data in transit. TLS acts as a tunnel to separate data from the outside environment, and the endpoints exchange encryption keys. GCP also encrypts and authenticates all our data in transit at one or more network layers, when data moves outside physical boundaries not controlled by or on behalf of Google. Furthermore, Data in transit inside a physical boundary controlled by or on behalf of Google is generally authenticated but not necessarily encrypted. Our encryption utilizes encryption keys, which are managed by Google (see Encryption in Transit in Google Cloud Platform).
When data are in transit via 3rd party (e.g. Mailgun, Sinch), they are protected and transferred via Hypertext Transfer Protocol Secure (HTTPS).
Strong Architecture
GCP runs in a multi-tenant, geographically distributed environment to support the availability of services. It is guaranteed by GCP that data is distributed amongst a shared infrastructure, designed to store extremely large amounts of data across many servers.
We also have built a highly-available, resilient, and strong architecture to ensure that our data is replicated in real-time, to multiple zones and data centers at any time. This provides high availability for our clients by dynamic load balancing across those sites.
Instances
Bloomreach Engagement offers three main types of instances: multi tenant, single tenant, and exclusive instances. These each contain different features and configurations of data layers which we will explain below. In each of these instances, data is separated and access management is enabled to ensure your security.
Multi Tenant instance
Our multi tenant instance is for SMEs who are not subject to the strictest regulation.
Within our multi tenant instance, users cannot access data from other clients, and data is separated on a frontend level. Resources are also shared on a backend level.
Multi tenant instances are encrypted at the level of GCP infrastructure and undergo periodic security scans and pen tests.
To access the account on the multi tenant instance, users must choose a strong password and may use two-factor authentication (2FA) to sign in. The accounts are further secured by a captcha to fence off bot attacks. The admin of the particular project can also specify in the Access management which users can see PII (personally identifiable information) of their customers. This distinction is on the frontend and backend.
The features included in our multi tenant instance are: |
---|
Password guardian |
Captcha |
Identity Access Management (IAM) |
DDoS protection |
Firewall |
Data Encryption (SSL/TLS and AES) |
Static IPs |
SSH Tunnel |
Single Sign-On |
The multi tenant instance is like a building with multiple offices, each with a security door. As all clients share a single Google Cloud Platform, but they all have different accounts each with a separate password, data segregation exists between the multiple instances.
Single Tenant Instance
Our single tenant instance is for multinational brands that require a higher level of data security and may face tougher data scrutiny.
Within our single tenant instance, data layers are logically separated on the backend. The computing resources reserved for the client are separated from other resources on the backend by namespace.
Single tenant instances are encrypted at the level of GCP infrastructure and undergo periodic security scans and pen tests.
To access the account on the single tenant instance, users must choose a strong password and may use two-factor authentication (2FA) to sign in. The accounts are further secured by a captcha to fence off bot attacks. The admin of the particular project can also specify in the Access management which users can see PII (personally identifiable information) of their customers. This distinction is on the frontend and backend.
Single tenant instance features include: |
---|
Password guardian |
Captcha |
Identity Access Management (IAM) |
DDoS protection |
Firewall |
Data Encryption (SSL/TLS and AES) |
Static IPs |
SSH Tunnel |
Additional security features available as add-ons: |
---|
Bloomreach Engagement SSO (SAML2) |
IP restriction (Cloud Armor) |
Virtual Private Network (VPN) |
Vulnerability scan report with access |
Audit log report access: IAM and Application |
Custom SSL |
Single tenant instances are like separate buildings of their own which only share electricity supply. Each instance is managed within a separate capacity while being powered by GCP.
Exclusive Instance
Our exclusive instance is designed for large companies that have strict regulatory obligations to meet, as they handle sensitive categories of data.
Exclusive instances are encrypted at the level of GCP infrastructure and undergo periodic security scans and pen tests.
To access the account, the Exclusive instance also supports Single SIgn-On (SSO) to meet security standards in this industry. The accounts are further secured by a captcha to fence off bot attacks. The admin of the particular project can also specify in the Access management which users can see PII (personally identifiable information) of their customers. This distinction is on the frontend and backend.
This platform includes complete segregation of logical layers and network separation through utilizing a different GCP project and backend computing resources dedicated to you Within the exclusive instance there is also the separation of access rights and permissions.
The Exclusive instance allows:
- the client to administer their logs, through streaming to their SIEM
- an ‘emergency break’ option, which gives the client the option to cut off Bloomreach Engagement from production
- switching on new Google services/network/access rights to the backend architecture
The exclusive instance includes the following features: |
---|
Password guardian |
Captcha |
Identity Access Management (IAM) |
DDoS protection |
Firewall |
Data Encryption (SSL/TLS and AES) |
Static IPs |
SSH Tunnel |
Additional security features available as add-ons: |
---|
Bloomreach Engagement SSO (SAML2) |
IP restriction (Cloud Armor) |
Virtual Private Network (VPN) |
Vulnerability scan report access |
Audit log report access: Infrastructure, IAM, and Application |
Custom SSL |
Separation layers | Multi tenant | Single tenant | Exclusive |
---|---|---|---|
Data layer | Your data is visible only in your accounts/projects | Your data is visible only in your accounts/projects | Your data is visible only in your accounts/projects |
Users layer | Users authorized only for your accounts/projects | Users authorized only for your accounts/projects | Users authorized only for your accounts/projects |
Frontend layer | Application settings, definitions, and campaigns visible only within your projects | Application settings, definitions, and campaigns visible only within your projects | Application settings, definitions, and campaigns visible only within your projects |
Backend layer | Shared network, shared databases, shared Kubernetes cluster | Logically separated network and all backend services, shared and dedicated databases, shared Kubernetes cluster | Network separated from scratch, dedicated databases, dedicated Kubernetes cluster |
Infrastructure administrator access | Shared administrator accesses | Shared administrator accesses | Administrator accesses established from scratch |
File Management in Asset Manager
Although our infrastructure is built on GCP, there is one exception: our File management used in the Asset manager. Thus, we do not guarantee the location of files and data stored in the Asset manager. As a result, storing anything sensitive in the Asset manager is not recommended.
Updated about 1 year ago