Encryption

We try to use encryption everywhere we can.

Access to our application is restricted to the HTTPS protocol (any insecure request made to our HTTP endpoint is automatically redirected to HTTPS).

Our teams have access to our underlying infrastructure by connecting to these servers using SSH.

We continuously monitor and store applications logs to prevent and understand failures that might happen in our application.

These data should never contain user informations.

We specifically monitor internal access (from our employees) to our infrastructure and changes made to our databases.

Logs created by our application are kept between 15 and 30 days to allow us to detect bugs or errors.

We have multiple types of backups:

Access to these backups is heavily monitored and restricted to a subset of employees (developers/infrastructure teams).

Any access to our internal tools is done by using a unique account per user.

Where possible we enforce the use of a MFA device to further improve authentication security.

When we use or add a new service to our infrastructure we try to give it the least privileges it need to correctly function.

Most of our infrastructure is not visible from the internet (i.e. we mostly use private networks to minimize our exposition to the web). To access any internal servers our employee need to use a gateway. This gateway is restricted to a subset of our employees and access to this service is reviewed frequently to detect any intrusion and/or abuse.

We use AWS as our cloud provider for our underlying infrastructure and we use OVH as our domain registrar.

On AWS we segregate the different environment (tests, staging, production) using different networks (called VPC) that can only communicate between each other if explicitly configured for (called a peering).

We minimize the resources shared between environments and different environment should never communicate between each other.

When we deploy a new service (internal or customer facing) we try to minimize the attack surface it might expose. We allow access to the smallest subsets of ports and where possible keep access private from the internet.

By contract any 3rd party used for our infrastructure are required to request access before accessing any of our data or servers.

We created a peering between our environments and our database provider. Theoretically it could access our internal servers. In reality we always setup our firewalls to block access from our provider. Our environments can access the cluster it exposes (our databases) but the other way around is blocked.