Liste des mesures techniques et organisationnelles de protection des données
Mise-à-jour : 22/08/2025
Auteur(s) :
Ivan Maireaux ivan.maireaux@eventmaker.com
Sommaire
Ordinateurs des collaborateurs d’Eventmaker
Les applications d’Eventmaker sont hébergées sur l’Infrastructure as a Service (IaaS) Amazon Web Service. Eventmaker utilise la region eu-west-1 d‘AWS située en Irlande.
L’infrastructure est déployée en utilisant Terraform qui permet de faire de l’infrastructure as code. Cela nous permet de contrôler précisément les modifications et les configurations de notre infrastructure.
Le cluster applicatif est l’endroit où les applications sont exécutées. Ce cluster utilise Kubernetes un orchestrateur de conteneur. Tous nos processus sont isolés et déployés dans des conteneurs Linux Docker. Ces conteneurs sont orchestrés par Kubernetes. Kubernetes nous permet de standardiser nos déploiements, de pouvoir passer à l’échelle facilement et surtout d’être robuste aux pannes. Nous utilisons Kubernetes via le service AWS EKS.
Ce cluster applicatif est composé d'au moins 10 serveurs (ce nombre peut varier positivement en fonction de la charge). Les serveurs sont répartis dans les 3 zones disponibles de la région eu-west-1 : eu-west-1a, eu-west-1b et eu-west-1c. Distribuer nos serveurs sur 3 zones différentes nous permet d’assurer une disponibilité de service en cas d’incident majeur sur l’une des zones.
La mise à jour du cluster applicatif est standardisée et documentée et est faite régulièrement. Cela inclut Kubernetes, Docker ainsi que le système d’exploitation.
Le système d’exploitation utilisé est Amazon Linux 2.
Notre système de gestion de base de données MongoDB est géré par le service MongoDB Atlas. Ce service nous permet de déployer 3 serveurs qui forment un Replica Set. Le Replica Set nous permet d’être robuste aux pannes, d’assurer la continuité de service et de se mettre à l’abri d’une éventuelle perte de données.
MongoDB Atlas est en conformité avec un grand nombre de normes et de réglementations incluant la RGPD et la norme IS0 27001. Plus d’informations sur leur site web.
Les 3 serveurs sont situés dans le cloud AWS dans une zone différente (eu-west-1a, eu-west-1b et eu-west-1c). Les disques dur des serveurs sont chiffrés en utilisant l’Encryption at Rest fournie par AWS EC2.
Les clusters applicatif et de base de données sont chacun dans leur propre Virtual Private Cloud (VPC). Les VPC permettent d’isoler les différents serveurs sur leur propre réseau.
Les pare feu des serveurs sont mis en place via les Groupe de sécurités. Au sein de leur VPC les serveurs peuvent communiquer entre eux (trafic interne au cluster, sous réseau privé). Les connexions depuis l’extérieur sont finement contrôlées.
Les serveurs applicatifs autorisent uniquement le trafic provenant des Elastics Load Balancer (ELB) (le point d’entrée des connexions extérieures HTTP / HTTPS). Les connexions SSH sur le cluster applicatif ne sont pas possible sans passer par un bastion host.
Le VPC du cluster de base de données est appairé avec le VPC du cluster applicatif. Cela permet aux serveurs applicatifs de communiquer de manière totalement privée avec les serveurs de base de données.
Les serveurs de base de données autorisent les connexions des serveurs applicatifs sur les ports réservés à MongoDB et sur les adresses IP privées des serveurs applicatifs.
Les connexions directes aux serveurs applicatifs (type SSH) ne sont pas possibles.
Les applications Eventmaker sont des Twelve Factor Application. Les données stockées localement sont uniquement des données temporaires. Les applications ont aussi accès à des bases de données Redis pour stocker des données temporaires. Les bases Redis sont hébergées sur le cluster applicatif. Nous déployons une base Redis par application.
Nous stockons aussi certaines données sur AWS S3 (fichiers PDF générés, fichiers uploadés …).
Le reste des données sont stockées sur la base de données MongoDB.
Chaque application a sa propre base de données (MongoDB et Redis). L’accès à ces bases est authentifié par un mot de passe généré par un logiciel de génération de mots de passe fort.
Le cluster de base de données est sauvegardé régulièrement en suivant cette politique :
Les sauvegardes sont stockées sur AWS dans la région eu-west-1 (Irlande) et sont assurées par MongoDB Atlas.
Il est possible de stocker les données sensibles d’un compte Eventmaker dans une autre région que la région par défaut (AWS eu-west-1, Irlande).
Eventmaker maintient une autre région dans le datacenter d’OVH en France (Gravelines). Les comptes rattachés à cette région ont leur données sensibles stockées sur un replicas-set MongoDB auto-managé par OVH et dans un Object Storage OVH situé dans le même datacenter.
Dans cette région, les sauvegardes sont assurées par OVH et sont effectuées toutes les 24 heures (1h heure française) et ont une période de rétention de 14 jours.
Les disques durs du cluster MongoDB sont chiffrés au repos via OVH.
Quand un compte est rattaché à cette région, uniquement les données sensibles (données personnelles) sont stockées dans la région, le reste des données (configuration) continuent d’être stockées sur la région par défaut.
Les connexions aux applications d’Eventmaker se font au travers des Elastics Load Balancer (ELB). Les certificats HTTPS des domaines sont gérés via AWS Certificate Manager.
Nous sécurisons aussi les noms de domaines de nos utilisateur via des certificats Let’s Encrypt
Eventmaker développe ses applications Web avec le framework Ruby on Rails, framework réputé pour ses bonnes pratiques de développement et de sécurité.
Nous forçons les connexions HTTPS sur notre plateforme app.eventmaker.io ainsi que sur l’ensemble des sites web mis en place via le CMS Eventmaker.
Nous ne stockons aucun mot de passe dans nos bases de données, ils sont hashés via la fonction de hash bcrypt.
Nous utilisons Dependabot qui vérifie quotidiennement les failles de sécurité connues des librairies tierces qui sont utilisées dans la plateforme Eventmaker.io.
Afin d’assurer une surveillance des vulnérabilités et des erreurs de configuration en continue de nos applications, nous réalisons des tests de sécurité Tenable WAS et OWASP tous les trimestres sur nos applications. Des pentests sont également effectués mensuellement par Ambionics.
Nous sommes également ouverts à ce qu’un client fasse des tests (audit de code, test d’intrusions …) lui-même. Nous en avons eu 7 sur les 5 dernières années :
Ces audits ont conclu à un niveau de sécurité satisfaisant. Les points les plus “critiques” ont été corrigés depuis.
Nous exigeons de nos utilisateurs que leur mot de passe contienne au minimum 6 caractères et ait un niveau suffisamment élevé d’entropie (recommandation NIST). Le détail de l’algorithme pour calculer l’entropie est expliqué dans cet article. Cette pratique nous assure un bon niveau de sécurité des mots de passe utilisés sur la plateforme.
Pour les comptes administrateurs, la MFA est obligatoire.
Nous ne sommes pas convaincus par les politiques de mot de passe complexe demandant aux utilisateurs de le modifier tous les mois par exemple. Nous pensons que cela pousse les utilisateurs à ré-utiliser un mot de passe légèrement modifié à chaque fois, l’intérêt est donc selon nous relativement faible.
De plus, aucune de ces pratiques n’est utilisée par les banques en ligne par exemple, ou certains géants de la technologie comme Google ou Facebook.
Nous n’exigeons pas non plus l’utilisation de caractères spéciaux ou règles du même genre. Utiliser des mots de passe longs (comme des phrases) est beaucoup plus efficace qu’utiliser des mots de passe complexes mais courts. Forcer les utilisateurs à suivre certaines règles peut les inciter à noter leur mot de passe dans un endroit non sécurisé pour pouvoir s’en souvenir, ou bien d’ajouter A/ ou A! à la fin d’un mot de passe qui est utilisé ailleurs.
Nous permettons aux utilisateurs d’activer une authentification en 2 étapes qui permet d’ajouter une couche de sécurité supplémentaire en nécessitant un code pin lors de leur connexion à la plateforme. Le code pin est généré via un algorithme de Time-based One Time Password et peut être récupéré via une application tel que Google Authenticator ou Authy ou alors via SMS. Il est possible de consulter si l’authentification en 2 étapes a été activée ou non pour chaque collaborateur et donc de forcer l’utilisation de ce mode d’authentification au sein d’une organisation.
Les comptes Eventmaker sont verrouillés automatiquement au bout de 10 tentatives de connexions infructueuses.
Utilisation d’un SSO d’Entreprise
Eventmaker permet de configurer un SSO d’entreprise afin que les utilisateurs se connectent via le SSO de leur société. Le protocol supporté est SAMLv2.
Notre plateforme principale app.eventmaker.io force les connexions sécurisées (HTTPS).
Les accès à la plateforme sont sous la responsabilité des administrateurs des comptes. Nos clients ont chacun un compte (une organisation) dans lequel ils peuvent inviter des collaborateurs à travailler avec eux. Nous fournissons un outil de gestion de droits très poussé qui permet aux administrateurs de comptes de gérer les accès au backoffice de manière très fine.
Nous avons aussi mis en place un système de “traçage” qui nous permet de loguer les actions les plus significatives sur la plateforme.
Eventmaker fournit à ses employés des Macbooks. Tous les Macbooks disposent d’un disque dur chiffré via FileVault. Les systèmes d’exploitation sont régulièrement mis à jour et un mot de passe de connexion est obligatoire, avec un verrouillage de session automatique court. Les mises à jour sont faites à l’initiative du collaborateur. Nous avons un processus de contrôle régulier (tous les 3 mois ) des mise-à-jours de tous les ordinateurs individuels.
Les ordinateurs sont aussi équipés de Sentinel ONE EDR.
Eventmaker requiert de ses collaborateurs d’activer l’authentification à plusieurs étapes (MFA) sur les services sensibles tel que le service de messagerie électronique, ou l’accès à notre CRM ( Zoho CRM), ou encore notre comptabilité (Zoho Books).
Eventmaker.io - 20 rue des Aqueducs, 94250 Gentilly 512 747 676 R.C.S Paris - TVA : FR5127 4767600017 | p. |