Plan d'assurance sécurité
Plan d’Assurance Sécurité (PAS)
Objet du document
Ce document a pour but de préciser les engagements de sécurité pris par Dashdoc dans le cadre de ses prestations concernant la Plateforme.
Enjeux et Objectifs
Dashdoc prend toutes mesures de sécurité, notamment techniques, matérielles et organisationnelles de protection appropriées afin d’assurer la confidentialité, la conservation et l’intégrité des données traitées.
Un Plan d’Assurance Sécurité est mis en oeuvre afin de prendre en compte les principaux risques identifiés :
→ Risque d’indisponibilité des informations et des systèmes les traitant
→ Risque de divulgation, ou perte de confidentialité, accidentelle ou volontaire des informations fournies par nos clients
→ Risque d’altération, ou perte d’intégrité, qui pourrait amener à une perte d’information pour nos clients.
Les objectifs de mise en oeuvre du Plan d’Assurance Sécurité (ci-après “PAS”) sont :
→ D’améliorer et formaliser la gestion de la sécurité de la plateforme fournie par Dashdoc
→ S’assurer du respect par Dashdoc de ses obligations légales concernant la gestion des données personnelles (RGPD)
→ Sensibiliser les collaborateurs de Dashdoc à notre politique de sécurité
Organisation de la sécurité de l’information
3.1 RESPONSABILITÉ ET RÔLES
L’organisation de la sécurité de l’information est sous la responsabilité de M. Corentin Smith, CTO de Dashdoc.
3.2 PROCÉDURE D’ÉVOLUTION DU PAS
Dans le cadre de la mise en place du Plan d’Assurance Sécurité, une procédure de revue annuelle de celui-ci est instaurée.
Sécurité des ressources humaines
4.1 GESTION DES ARRIVÉES / DÉPARTS
Les collaborateurs qui rejoignent Dashdoc doivent suivre un processus interne, appelé processus d’Onboarding. Durant ce processus, ils sont sensibilisés aux problématiques de sécurité et d’intégrité des données.
Un processus interne assurant la gestion des départs d’un collaborateur permet de s’assurer de la fermeture de ses comptes d’accès aux différentes ressources auxquelles il avait droit.
4.2 SENSIBILISATION ET FORMATION À LA SSI
Tous les employés et membres du personnel ayant accès aux systèmes informatiques de l'organisation doivent adhérer à la politique interne de sécurité des mots de passe.
5. Sécurité logique
5.1 ACCÈS AUX RESSOURCES / CHIFFREMENT
Par défaut, l’accès à l’application est systématiquement forcé en HTTPS.
L’accès à l’application est protégé par un mot de passe qui peut être défini par l’utilisateur ou par l’administrateur. Une fois ce mot de passe défini, il est impossible pour une personne tierce de connaître ce mot de passe en soumettant une requête à notre base de données, car l’ensemble des mots de passe sont cryptés de façon irréversible en BCRYPT 10 rounds.
En cas de détection d’attaque, tous les clients concernés sont avertis sous 24h.
5.2 APIS
Dashdoc vous fournit un ensemble d’APIs vous permettant notamment la synchronisation de vos utilisateurs avec votre annuaire, la gestion des groupes pour ces utilisateurs, ou encore l’export des statistiques d’apprentissage relatives aux parcours.
Une description complète de notre API est disponible sur notre portail développeur : https://developer.dashdoc.eu/
L’authentification aux APIs s’effectue à l’aide d’une clef unique appelée clé API.
5.3 POLITIQUE DE GESTION DES MOTS DE PASSE SUR LA PLATEFORME
Les règles suivantes sont appliquées aux mots de passe :
Le mot de passe ne peut pas trop ressembler à vos autres informations personnelles.
Le mot de passe doit contenir au minimum 6 caractères.
Le mot de passe ne peut pas être un mot de passe couramment utilisé.
Le mot de passe ne peut pas être entièrement numérique.
Vous pouvez également utiliser votre propre politique de gestion des mots de passe en utilisant notre possibilité de connexion par SSO.
5.5 GESTION DES HABILITATIONS (CLIENT)
La plateforme distingue plusieurs rôles et plusieurs niveaux de permission, instaurant une sécurité logique supplémentaire. L’attribution des différents rôles aux utilisateurs s’effectue sous la responsabilité du client. La liste des rôles et permissions est consultable à tout moment sur la plateforme.
ADMINISTRATEUR : a accès à toutes les fonctionnalités, y compris le paiement et les paramètres.
UTILISATEUR : peut créer et modifier des documents, inviter des conducteurs, mais n'a pas accès aux paramètres.
LECTURE SEULE : a accès aux transports et à l'annuaire mais ne peut pas modifier ni créer de transports.
5.6 GESTION DES SESSIONS INACTIVES
Une fois authentifié, la durée de validité de la session d’un utilisateur sur son navigateur internet est de 7 jours.
5.7 TRAÇABILITÉ DES ACCÈS LOGIQUES
Chaque connexion à la plateforme est enregistrée dans notre système de logs, et est consultable par nos équipes. Ces logs sont conservés au minimum 90 jours.
5.8 GESTION DES DROITS D’ACCÈS (Dashdoc)
Nous nous assurons que vos données ne sont pas consultées par quiconque n’y ayant pas légitimement accès.
Le fonctionnement de nos services nécessite cependant que certains employés aient accès aux systèmes qui stockent et traitent les données client. Par exemple, pour pouvoir diagnostiquer un problème que vous rencontrez, nous pouvons nous trouver dans l’obligation d’accéder à vos données.
L’ensemble de nos collaborateurs est tenu de se conformer à nos règles de sécurité et notre société traite ces problèmes avec la plus grande attention : seules les personnes de l’équipe support et opérations sont autorisées à accéder aux données clients, et tous les accès sont tracés et auditables. Les membres de l’équipe technique et produit peuvent être amenés à utiliser des données clients à des fins de résolutions de problèmes utilisateurs ou d’amélioration de fonctionnalités.
5.9 POLITIQUE INTERNE DE SÉCURITÉ DE MOT DE PASSE
1. Synthèse
Tous les employés et membres du personnel ayant accès aux systèmes informatiques de l'organisation doivent adhérer à la politique définie ci-dessous afin d’assurer la sécurité du réseau, protéger l'intégrité des données et protéger les systèmes informatiques.
2. Objet
L'objet de cette politique est de protéger les ressources de l'organisation sur le réseau en requérant des mots de passe sécurisés ainsi que la protection de ces mots de passe, et en fixant un délai court entre les modifications des mots de passe.
3. Portée
Cette politique s'applique à tout membre du personnel possédant une forme de compte informatique sur le réseau de l'organisation requérant un mot de passe, incluant sans s'y limiter un compte de domaine et un compte e-mail.
4. Protection de mot de passe
→ N'écrivez jamais un mot de passe
→ N'envoyez jamais un mot de passe par e-mail
→ N'incluez jamais un mot de passe dans un document stocké non-crypté
→ Ne communiquez jamais votre mot de passe à qui que ce soit
→ Ne divulguez jamais votre mot de passe au téléphone
→ Ne donnez jamais d'indications concernant le format de votre mot de passe
→ Ne divulguez jamais et ne donnez jamais d'indications concernant votre mot de passe sur un forum sur Internet
→ N'utilisez jamais votre mot de passe d'entreprise ou de réseau sur un compte sur Internet qui n'est pas doté d'une connexion sécurisée, dont l'adresse dans le navigateur Web commence par https:// plutôt que par http://
→ Si vous avez la moindre raison de penser que votre mot de passe a été compromis, signalez-le à votre unité de sécurité informatique
→ Si quelqu'un vous demande votre mot de passe, renvoyez cette personne vers votre unité de sécurité informatique
→ Assurez-vous de ne pas être observé lorsque vous tapez votre mot de passe
5. APPLICATION
Étant donné que la sécurité des mots de passe est essentielle à la sécurité de l'organisation et de tous, les employés qui n'adhèrent pas à cette politique sont passibles de mesures disciplinaires, jusqu'au et incluant le licenciement.
6. AUTRES CONSIDÉRATIONS
Des écrans de veille protégés par mot de passe doivent être activés et doivent protéger les ordinateurs au bout de 5 minutes d'inactivité de la part des utilisateurs. Les ordinateurs ne doivent pas être laissés sans surveillance si l'utilisateur a une session ouverte et qu'aucun écran de veille protégé par mot de passe n'est activé. Les utilisateurs doivent prendre l'habitude de ne pas laisser leurs ordinateurs déverrouillés.
Les mots de passe d'administrateur doivent faire l'objet d'un degré de protection particulièrement élevé. Les comptes d'administrateur doivent bénéficier de l'accès minimum nécessaire pour remplir leurs fonctions. Les comptes d'administrateur ne doivent pas être partagés.
7. UTILISATION D'UN GESTIONNAIRE DE MOTS DE PASSE
L'utilisation d'un gestionnaire de mots de passe, Dashlane dans notre cas, facilite les points cités précédemment.
Qu'apporte-t-il ?
→ Il n'y a qu'un seul mot de passe-maître à mémoriser.
→ Il permet de partager l'accès à un compte de manière sécurisée, sans communiquer le mot de passe.
→ Il permet de générer des mots de passe sécurisés.
→ Chiffrement 256-bit AES, avec itérations PBKDF2 systématiquement répétées.
→ Toutes les données sensibles sont chiffrées et déchiffrées localement avant la synchronisation avec Dashlane. La clé ne quitte jamais l'appareil, et n'est jamais transmise à Dashlane. Nos données ne sont accessibles à personne d'autres que nous.
5.10 REVUE INTERNE DES DROITS D’ACCÈS
En sus de nos procédures de gestion des arrivées / départs / mobilité interne, une revue des droits d’accès est effectuée périodiquement, au minimum une fois par an.
6. Sécurité physique
6.1 Infrastructure
L'infrastructure principale de Dashdoc est hébergée au sein des centres de données de notre partenaire Google Cloud. Un autre prestataire, Scaleway, héberge notre infrastructure de sauvegarde. Google Cloud et Scaleway fournissent tous deux le plus haut niveau de sécurité afin de garantir la disponibilité, l'intégrité et la confidentialité des données hébergées.
6.2 Locaux de Dashdoc
Locaux de Dashdoc – Paris 9ème, France
→ Contrôle d’accès aux locaux par digicode et badge RFID
Locaux de Dashdoc – Nantes, France
→ Contrôle d’accès aux locaux par badge RFID
→ Dispositif de vidéo-surveillance
→ Dispositif d'alarme anti-intrusion
6.3 Traçabilité des accès physiques
La sécurité et la traçabilité des accès physique à nos serveurs de production est assurée par notre hébergeur Google Cloud :
“Google conçoit et construit ses propres centres de données qui intègrent plusieurs niveaux de protection de sécurité physique. L'accès à ces centres de données est limité à seulement quelques employés Google. Nous utilisons plusieurs niveaux de sécurité physique pour protéger nos centres de données et mettons en œuvre des technologies telles que l'identification biométrique, la détection de métaux, les caméras, les barrières de sécurité pour véhicules et les systèmes de détection d'intrusion à laser. En outre, Google héberge des serveurs dans des centres de données tiers où nous nous assurons que des mesures de sécurité physique contrôlées par Google s'ajoutent aux niveaux de sécurité fournis par l'opérateur du centre de données. Par exemple, dans de tels sites, nous pouvons utiliser des systèmes d'identification biométrique, des caméras et des détecteurs de métaux indépendants.”
Source : Google Infrastructure Security Design Overview
7. Sécurité de vos données
7.1 CLASSIFICATION DES DONNÉES / RGPD
Dashdoc garantit que les données personnelles sont isolées dans une collection unique de nos bases de données, et que toutes les autres données métier (contenus de formation, statistiques de formation, groupes, parcours...) utilisent un identifiant aléatoire pour référencer chaque utilisateur, assurant ainsi une pseudonymisation des données personnelles conforme à la réglementation RGPD.
7.2 LOCALISATION GÉOGRAPHIQUE DES DONNÉES
Notre infrastructure est hébergée au sein des centres de données de Google Cloud dans la zone “Europe-West 1”, située à Bruxelles en Belgique.
Nos sauvegardes de données sont localisées au sein des centres de données de Scaleway dans la zone “FR-Paris” située à Paris, France.
7.3 CLOISONNEMENT DES DONNÉES
La plateforme Dashdoc est un produit SaaS de type multi-tenant : chaque client ne voit que ses données. La base de données est partagée entre les clients, mais cloisonnée logiquement par client. Nous mettons en place une politique stricte de tests automatisés et de revue de code afin de garantir que chaque client puisse accéder uniquement à ses données.
8. Sécurité de l’exploitation des SI / Continuité de service
8.1 PLAN DE CONTINUITÉ DE SERVICE
Dashdoc s’engage sur les niveaux de service suivant pour ses clients :
→ Taux de disponibilité de la plateforme de 99%
→ Temps d’intervention de 2 heures après découverte d’un incident bloquant (erreurs serveur)
→ Temps de résolution de 12 heures d’un incident bloquant (erreurs serveur)
→ Support accessible par email ou téléphone de 8:00 à 19:00 heure de Paris, du lundi au vendredi
→ RPO (Recovery Point Objective) de 24 heures.
8.2 SAUVEGARDE DES DONNÉES
Des sauvegardes logiques (version du service et données clients) sont effectuées quotidiennement à distance sur l’infrastructure de sauvegarde Scaleway.
Ceci garantit un RPO de 24h maximum.
Des sauvegardes physiques sont effectuées chaque jour sur un serveur dédié dans un deuxième datacenter. Les seuls lieux de stockage physique sont nos serveurs Google Cloud ainsi que nos serveurs Scaleway.
8.3 REDONDANCE
Les serveurs sont répliqués, les centres de données sont alimentés par deux arrivées électriques indépendantes l’une de l’autre et sont également équipés d’onduleurs.
Des groupes électrogènes d’une autonomie de 48 heures permettent de pallier une éventuelle panne du réseau de fourniture d’électricité. Plusieurs boucles de sécurisation ont ainsi été mises en place, afin d’éliminer tout risque d'indisponibilité.
Cette multiplicité des liens permet également à vos données d'emprunter le chemin le plus court et donc d'afficher des temps de latence minimums. Les serveurs sont par ailleurs équipés d’une double alimentation et d’une double carte réseau : l'infrastructure est ainsi redondée de bout en bout.
8.4 GESTION DES CORRECTIFS DE SÉCURITÉ
Les systèmes d’exploitation et logiciels que nous utilisons font l’objet d’un support valide de la part de leur éditeur, ou d’une communauté active (dans le cadre de logiciel libre) et seuls les services et applications nécessaires sont installés sur nos serveurs, de façon à réduire la surface d’attaque. De plus, les mises à jour majeures ainsi que les mises à jour de sécurité sont systématiquement déployées.
8.5 LUTTE CONTRE LES CODES MALVEILLANTS
Nous nous assurons que l’ensemble des machines composant notre plate-forme est protégé par un système de prévention des logiciels malveillants (antivirus, etc.) correctement maintenu à jour.
9. Gestion des incidents / Disaster recovery plan
9.1 DISASTER RECOVERY PLAN
Le DRP est activé en cas de désastre impactant l'intégrité des données :
→ faille logique majeure
→ destruction physique des infrastructures d'hébergement
Dans un tel cas, le client est prévenu instantanément et la procédure de reprise commence.
L’infrastructure de secours est hébergée chez notre fournisseur Google Cloud dans une autre zone physique. Elle prend le relais et redémarre sur la dernière version des données sauvegardées. Comme mentionné précédemment, les sauvegardes complètes (version du service et données du client) s'effectuent automatiquement une fois par jour sur le cluster de secours et à distance, les données ne sortant jamais physiquement de leur lieu de stockage.
Ceci garantit un RPO (Recovery Point Objective) maximum de 24 heures.
La durée du DRP est de 12 heures maximum. Et dans le cas d’un changement de centre de données obligeant à changer les IP des entrées DNS, les caches des DNS à travers le monde mettent 24h maximum à se mettre à jour.
Ceci garantit un RTO (Recovery Time Objective) de moins de 24 heures.
9.2 RÉCUPÉRATION MANUELLE SUITE À UNE ERREUR CLIENT
Concernant la capacité de Dashdoc à restaurer des données suite à une mauvaise manipulation d'un utilisateur, les dispositions suivantes s’appliquent.
Les données qui peuvent être perdues sont de 3 types :
→ Données de transport
→ Données utilisateur
→ Logs et statistiques
En cas de perte de données due à une mauvaise utilisation du client, impactant les données de transport, l’équipe R&D de Dashdoc étudie la profondeur de la perte et la charge de travail. Si les données peuvent être restaurées, l’équipe propose une prestation facturée sur la base de 800 euros par jour-homme de travail. En cas de perte de données due à une mauvaise utilisation du client, impactant les 2 autres types de données, Dashdoc ne garantit pas la restauration de celles-ci.
10. Sécurité réseau
10.1 CHIFFREMENT DES FLUX RÉSEAUX
Les échanges entre les postes utilisateurs et nos applications sont entièrement chiffrés depuis votre navigateur jusqu’à nos serveurs avec l’utilisation du protocole HTTPS / TLS 1.3.
10.2 ACCÈS À DISTANCE AUX SERVEURS DE PRODUCTION
L’accès à nos serveurs de production est effectué via le protocole SSH, et est donc sécurisé par un système de clés publiques/clés privées.
Un mécanisme de protection anti brute force est de plus déployer afin de bloquer les IP qui tenteraient de se connecter sans y être autorisé.
10.3 ACCÈS AU RÉSEAU INTERNE DASHDOC
Seuls les collaborateurs Dashdoc ont accès au réseau interne. Le réseau Wifi est protégé par chiffrement WPA2.
10.4 PRÉVENTION CONTRE LES ATTAQUES EXTERNES
Prévention contre les attaques par déni de service (DDOS)
Une attaque DDoS vise à rendre un site indisponible, en surchargeant la bande passante du serveur ou en accaparant ses ressources jusqu'à épuisement. Les cas rencontrés concernent généralement des attaques de niveau 7, le plus élevé, basées sur des requêtes exécutées en nombre visant à saturer le système.
Garantir la sécurité en ligne de ses clients est une des préoccupations majeures pour Dashdoc.
Pour contrer ces attaques, nous faisons appel à Cloudflare.
La solution de protection anti-DDoS de Cloudflare sécurise les sites web, les applications et les réseaux entiers, tout en s'assurant que le trafic légitime n'est pas compromis.
Doté d'une capacité de 67 Tbps, le réseau de Cloudflare bloque en moyenne 70 milliards de menaces par jour, dont certaines des plus importantes attaques DDoS de l'histoire.
Firewall et filtrage de ports
Les firewalls installés sur les serveurs de Dashdoc permettent une sécurité accrue au niveau de la protection des flux. Seuls les ports indispensables au fonctionnement de la plateforme et à son administration sont autorisés.
10.6 TRAÇABILITÉ DES ACCÈS RÉSEAU
Toutes les requêtes HTTP entrantes sont enregistrées dans des fichiers de logs. Ces logs sont conservés au minimum 90 jours.
Toute connexion directe à nos serveurs de production (connexion SSH) est de plus enregistrée dans un système de log. Les informations enregistrées (heure de connexion, IP et clé publique SSH) permettent de remonter jusqu’à la personne qui s’est connectée.
11. Sécurité des développements / Architecture
11.1 ARCHITECTURE
Dashdoc propose un logiciel de type SaaS (Software as a Service, Logiciel en tant que Service). Le modèle SaaS part du principe que le logiciel est installé sur des serveurs plutôt que sur la machine de l'utilisateur.
Notre architecture se découpe en trois couches (voir schéma) :
→ L'interface, en Javascript, qui s'exécute chez le client (mobile ou web). Elle contient quelques workflows et des logiques métier. Cet élément passe naturellement à l’échelle : chaque client le recevant dès qu'il se connecte au site, et l'exécutant lui-même. Pour obtenir les données à afficher, et envoyer de nouvelles données à la plate-forme, cette partie fait des requêtes HTTP à une API REST.
→ L’API REST, exposée par un serveur Python. Cette API est découpée en blocs élémentaires.
→ Les serveurs Python font ensuite des requêtes à une base de données PostgreSQL pour lire et stocker les données. Cette base de données est hébergée sur le service Google Cloud SQL et peut être passée à l’échelle automatiquement en fonction de l’utilisation constatée des ressources CPU et mémoire, ainsi que de l’espace de stockage.
11.2 RÈGLES DE DÉVELOPPEMENT
Nos règles de développement suivent les principes du “Security by design” tels que définit par l’OWASP (https://www.owasp.org/index.php/Security_by_Design_Principles)
Nos équipes de développement sont régulièrement sensibilisées aux problématiques de sécurité.
De plus, une revue de chaque ligne de code produite est systématiquement réalisée au sein de l’équipe de développement. Cette procédure de revue permet de s’assurer que tous les développements réalisés sont en accord avec notre politique de sécurité.
11.3 GESTION DES ÉVOLUTIONS
Nous déployons de nouvelles versions de l’application serveur plusieurs fois par jour selon les principes de la Continuous Delivery. Une batterie de tests automatisés ainsi que des tests manuels sur un environnement de pré-production nous permettent de détecter les anomalies avant déploiement.
11.4 VEILLE ET GESTION DES VULNÉRABILITÉS TECHNIQUES
Une revue de dépendance périodique est en place pour détecter les librairies externes obsolètes, susceptibles de vulnérabilité aux attaques.
12. Conformité
12.1 RGPD
Vous trouverez l’ensemble de nos engagement concernant notre politique sur la confidentialité de vos données ainsi que sur la RGPD sur notre site public : https://www.dashdoc.eu/fr/politique-de-confidentialite
12.2 CERTIFICATIONS
Notre prestataire hébergeur Google Cloud possède les certifications suivantes :
ISO/IEC 27001
ISO/IEC 27017
ISO/IEC 27018
ISO/IEC 27701
PCI DSS
SOC 1
SOC 2
SOC 3
Cloud Computing Compliance Controls Catalog (C5)
CSA STAR
Code de conduite Cloud pour l'Union européenne
OSPAR