Last updated: February 2, 2021
Security is very important to Back. This document describes our key internal security policies and how those translate into creating a secure platform that you can trust.
A big part of effective regulatory compliance and data security starts with the right management and governance structures. To that end, Back has implemented a data protection management system (DPMS) that specifies roles and responsibilities, as well as processes based on continuous improvement to ensure that data protection and security requirements are met. This also means that we perform periodic risk assessments to ensure that our security policies and practices are up to par.
All of our services are hosted in a highly secured data center in Frankfurt, Germany by Amazon Web Services (AWS). The data center in question is certified under ISO 27001, which includes physical access controls. Specific physical security measures in place in AWS data centers are described here: https://aws.amazon.com/compliance/data-center/controls/
In addition, we make sure that no unauthorized person has access to our offices by enforcing policies regarding documented key management, ensuring offices are securely locked after business hours, video surveillance of the premises, accompanying visitors and making sure cleaning and maintenance personnel is vetted and signs confidentiality agreements.
Protecting physical access to the hardware is important but making sure that no unauthorized access occurs to systems is every bit as important.
We manage user authorizations via a Role-Based Access Concept, which provides for regular periodic reviews of access rights. Connection to our infrastructure requires multiple levels of authentication: individual SSH key with a passphrase and valid AWS IAM credentials.
We enforce a Strict Secure Password Policy. All our employees are required to use our company password manager and generate complex and unique passwords for every service.
Everyone works on computers provided by the company, which have full-disk encryption enabled.
The number of administrators is reduced to the bare minimum. For us, this means that only the CTO and two senior engineers have access to production systems containing sensitive data.
All communications with Back services and websites are encrypted over TLS. We do this so no one can eavesdrop on communications between you and Back.
Also, any connection to production servers is encrypted. Our system data can only be changed via API calls, which are subject to state-of-the-art encryption and require authentication. Changes made by API calls are logged in the request history.
Third-party integrations are only allowed via APIs supporting encryption over TLS.
At Back we want to make sure no security vulnerabilities are introduced in our code. Without exception, every line of code pushed on production is reviewed by one or more engineers.
We also run static code analysis and keep our dependencies up to date to limit potential vulnerabilities.
If you believe you found a security vulnerability in our application or infrastructure, please refer to our Security Vulnerability Disclosure Policy.
There are multiple ways for our users to authenticate in our application:
Our AWS infrastructure is designed to segment our servers into different areas, separating our production environments from our testing and development environments using different security groups and private networks.
We use monitoring services to alert us on any anomalous or suspicious behaviour in our infrastructure. Incidents are dealt with in an internal incident management process. This allows us to ensure no stone is left unturned and the root cause of the incident is resolved. The process also describes how to escalate and communicate these incidents to the different parties involved.
Like many software, we use third-party libraries and open-source components. We make sure to stay on top of security updates for any third-party component to ensure no security issues come up. We have a process to analyze and treat vulnerabilities based on their criticality.
We understand that a vital part of offering a software as a service is not only ensuring that your data is safe but also available to you. To make sure this is never an issue for you, we are making a snapshot of our database every four hours which is replicated in multiple availability zones. Also, our services are replicated across several availability zones and behind a load balancer to maintain high availability.
If you have any further questions or comments, please feel free to contact us at email@example.com.