Sécurité du SaaS et conformité au RGPD

Entr'ouvert s’engage à mettre en œuvre les mesures de sécurité visant apporter une protection suffisante des données à caractère personnel. Ces mesures portent à la fois sur les données à caractère personnel confiées et sur les mesures générales de sécurité du système.

Les mesures de protection sur les données à caractère personnel

Les mesures mises en œuvre par Entr'ouvert sont adaptées à la sécurité des données confiées.

Sécurité des données

Nous respectons le principe de base de la protection des données qu'est la proportionnalité des mesures préventives - l'envergure de ces mesures étant directement liée à la criticité des données à caractère personnel collectées et traitées dans l'environnement Publik.

Notre moteur de base de données est le SGBDR (système de gestion de bases de données relationnelles) PostgreSQL, outil libre, reconnu pour sa robustesse et sa sécurité.

Nos bases de données, comme le reste de l'infrastructure Publik, sont situées sur des machines physiques hébergées par notre sous-traitant OVH, et accessible seulement à l'aide du protocole SSH par clé RSA (pas d'authentification par mot de passe, jugée d'une sécurité trop faible) par les administrateurs d'Entr'ouvert.
L'ensemble de clés autorisées est maintenu de façon cohérente. Par exemple, lorsqu'un technicien quitte l'équipe, sa clé est désactivée.

Nos bases de données sont aussi sauvegardées toutes les nuits et ces sauvegardes sont stockées sur un site tiers.

Des sauvegardes quotidiennes sont conservées une semaine, et des sauvegardes mensuelles quatre mois. Les sauvegardes sont détruites au delà de ce délai.

Les mêmes critères de conservation sont appliqués à la sauvegarde des fichiers situés sur le système de fichier réseau NFS (Network File System).

Ces sauvegardes nous permettent entre autres de rétablir un état cohérent des bases de données en cas de compromission des données stockées.

Moyens de chiffrement employés pour les flux de données intégrés dans le traitement

Les communications se font en HTTPS (HTTP sur TLS).
Le certificat HTTPS est soit délivré par la collectivité, soit obtenu via une autorité de certification reconnue (LetsEncrypt, par exemple).

D'un point de vue applicatif, l'interface entre logiciels métiers externes et la fabrique de formulaire contenant les données des utilisateurs se fait à l'aide de requêtes nécessairement signées, réduisant les risques d'usurpation d'identité numérique de l'un de ces logiciels.

Les signatures, de type HMAC (Hashed Message Authentication Code), se basent sur la fonction de hachage SHA-256 (Secure Hash Algorithm, produisant des hachés de 256 bits de longueur), considérée cryptographiquement robuste selon les critères en vigueur de nos jours.

Procédures garantissant que des tiers ne puissent pas avoir accès aux données confiées

Outre les procédures de chiffrement décrites plus haut, nous développons nos applications à l'aide du framework Django.

Ce dernier propose des mécanismes de prévention des attaques usuelles sur le Web ; notamment la prévention contre injections SQL, les scripts inter-site (Cross site-scripting, XSS), le forgeage de requêtes inter-site (Cross-site request forgery, CSRF).

Enfin, la partie publique des clés SSH autorisées à accéder aux différents serveurs est centralisée dans notre dépôt utilisé par l'outil de gestion de configuration de serveur Puppet.
Le retrait d'une clé, par exemple lorsque quelqu'un se voit retirer ses accès aux serveurs, se fait de façon directe et est appliqué à l'ensemble de notre infrastructure.

L’anonymisation des données

L'anonymisation des données des utilisateurs est paramétrable dans Publik.

Les mécanismes d'anonymisation sont les suivants :

• anonymisation des données métiers et des données personnelles, par simple effacement des données contenues dans les champs.

• les métadonnées relatives aux demandes des usagers sont aussi anonymisées.
  Parmi ces métadonnées figurent le contexte de soumission de la demande, l'identifiant de l'usager associé à cette demande, ainsi que les rôles destinataires et les données de workflow. Une fois anonymisées, les demandes servent encore à des fins statistiques, elles sont injectées dans l'outil de business-intelligence (BiJoe).

D'une façon générale, le RGPD impose au minimum l'anonymisation (quand ce n'est pas la suppression) des données dès lors que leur conservation n'est plus utile au traitement auquel l'usager a consenti.

Les formations données par nos chefs de projets aux administrateurs fonctionnels, formations relatives à la construction des démarches en ligne avec Publik, tiennent compte de cette nécessité d'anonymiser les demandes contenant des données à caractère personnel.

Le cloisonnement des données

Le cloisonnement des données dans l'architecture Publik repose principalement sur les propriétés de multitenancy de notre moteur de base de donnée relationnelle PostgreSQL.

Le multitenancy (i.e. « multi-hôte ») permet à PostgreSQL d'assurer la séparation des données de plusieurs sites d'une même application.

Dans le cadre d'une installation Publik multi-collectivités, le système de contrôle d'accès basé sur les rôles (Role-Based Access Control, RBAC) permet de s'assurer que les données d'une collectivité restent cloisonnées à cette collectivité et aux rôles qui y sont liés (et donc qu'elles ne puissent pas être lues par un membre d'un autre collectivité de l'instance Publik, ce membre ne possédant pas les rôles adéquats).

Le contrôle des accès logiques

Le fournisseur et gestionnaire d'identités de Publik, Authentic, reprend et étend les mécanismes de contrôle d'accès du framework Django.

Ce fournisseur définit un ensemble de rôles techniques, pour sa gestion en interne, et un ensemble de rôles métiers, voués à être approvisionnés dans les autres briques du logiciels Publik.

Authentic assure aussi l'authentification des comptes usagers de Publik.

Il fournit un mécanisme d'authentification modulaire. Ainsi, l'usager s'identifie par login/mot de passe, ou bien, si Authentic est configuré pour, via un fournisseur d'identités tiers (lequel proposera alors indépendemment de Publik ses propres moyens d'authentification).

Le choix d'un mot passe pour l'authentification d'un usager doit respecter les contraintes suivantes : 8 caractères au minimum, dont au moins une lettre minuscule, un chiffre et une lettre majuscule.

La politique de complexité des mots de passe est paramétrable.
Il est aussi possible d'activer un temps d'attente exponentiel après chaque tentative d'authentification infructueuse.

Enfin, le support de l'authentification à plusieurs facteurs est en voie de développement dans notre fournisseur d'identités Authentic.

La politique de journalisation

Une fonction de journalisation des actions impliquant les logiciels métiers externes est mise en place directement dans la base de connecteurs Passerelle.

Par ailleurs, une application de journalisation pour le fournisseur d'identité est en cours de développement.

La politique d’archivage

La conservation des données des systèmes de fichiers réseau inclut l'ensemble des logs Web et applicatifs.

Ces données, bien évidemment à caractère personnel, et à valeur juridique potentielle, bénéficient de la même politique de conservation stricte des sauvegardes des données des serveurs de l'architecture Publik.

La politique de sécurisation des documents papiers

Nous ne proposons pas de service impliquant une gestion de documents au format papier.

La politique de minimalisation des données collectées

La réduction de la collecte des données à ce qui est strictement nécessaire pour mener à bien le traitement fait partie de notre activité d'accompagnement à la conception des démarches dans Publik.

Les formation à la conception de ces démarches ont pour objectif majeur la sensibilisation à la nécessité de minimaliser la collecte de données.

Les cookies

Les cookies utilisé par Publik ne nécessite aucune demande de consentement (ils ne servent pas au traçage des activités de l'utilisateur, mais seulement à des fins techniques d'authentification).

Plus d'informations ici : Cookies et traceurs

Les mesures générales de sécurité du système

La sécurisation de l'exploitation

L'architecture redondée propose une conteneurisation des applications formant l'environnement Publik. Ces applications sont présentes sur chacun des deux serveurs de notre SaaS.
La base de données est elle aussi redondée, sur les deux serveurs.

La charge des requêtes Web est répartie entre les deux nœuds du système redondé, et l'attribution à l'un ou l'autre des deux nœuds se fait en fonction de l'adresse IP du terminal de l'usager.

Cette répartition de charge est à la fois disponibles sur les plateformes de développement, de recettes et de production, et les spécifications matérielles de celles-ci sont adaptées à cette charge :

• Plateforme de développement :

  • Processeur : Intel Xeon E5-1660v3 - 8c/16t - 3GHz /3,5GHz

  • Mémoire vive : 128Go DDR4 ECC 2400 MHz

  • Disque : 1,2TB SSD NVMe

• Plateformes de recette et de production :

  • Processeur : Intel 2 x Xeon E5-2640v3 - 16c/32t - 2,6GHz /3,4GHz

  • Mémoire vive : 128Go DDR4 ECC 1866 MHz

  • Disque : 1,2TB SSD NVMe

Les principaux logiciels utilisés et maintenus à jour sont :

• le système d'exploitation Debian.

• la gestion de configuration des serveurs par Puppet.

• la réplication des données sur périphériques de bloc, par DRBD.

• la répartition de charge par HAProxy.

• le serveur Web nginx.

• l'interface uWSGI entre service Web et applications.

• le framework Web Django.

• nos propres applications formant l'environnement Publik.

Les mises à jour se font à l'aide du gestionnaire de paquets Debian, apt.

Un système de monitorage (Nagios) des serveurs permet de prévenir et détecter les différents pannes envisageables (serveur down ou saturation de l'espace mémoire RAM ou de l'un des disques notamment).

La limitation des accès physiques au matériel est assurée par notre hébergeur sous-traitant OVH, conformément à ses mesures prises pour le respect de la réglementation européenne en vigueur (https://www.ovh.com/fr/protection-donnees-personnelles/securite.xml).

La lutte contre les logiciels malveillants

Nos services sont déployés sur des machines constamment maintenues à jour (via les dépôts officiels Debian) et accessibles pour administration seulement en SSH (avec clé seulement, pas d'authentification par mot de passe acceptée), réduisant ainsi les risques d'attaque par force brute (attaquer par force brute un mot de passe d'une dizaine de caractère de longueur est très largement faisable, mais en faire de même pour la partie privée d'une clé RSA de 2048 ou 4096 octets de longueur est en pratique fantaisiste).

Nous utilisons strictement des logiciels libres reconnus pour leur rigueur dans la prise en compte des principes de sécurité, et notamment pour la rapidité de fourniture de correctifs logiciels en cas de faille nouvellement identifiée (Common Vulnerability Exposures ou CVE)

Par ailleurs, notre hébergeur OVH s'engage aussi à nous envoyer une alerte courriel dès lors qu'un de leurs outils de monitorage, installés sur nos serveurs, requiert une mise à jour de sécurité.

La gestion des postes de travail

Les mêmes critères de sécurité sont appliqués sur les postes de travail : machines à jour, exécutant des logiciels libres reconnus pour leur rigueur dans la prise en compte des principes de sécurité.

La protection des sites web

Nous utilisons une version de support à long-terme (LTS) de Django.

Les mesures de sécurité prescrites ici sont gérées par ce framework, qui fonctionne dans une version maintenue à jour sur notre SaaS.

Comme décrit plus haut dans ce document, ce framework inclut les mécanismes de sécurité adéquats pour faire face aux tentatives d'attaque usuelles sur le Web (injections SQL, session-hijacking, XSS, CSRF, etc.)

La sauvegarde des données

La haute-disponibilité des services Publik est assurée par la redondance de l'architecture publique sur notre plateforme SaaS, laquelle bénéficie d'un système de répartition de charge (HAProxy).

L'ensemble des services composant l'environnement Publik sont donc redondés, permettant la continuité en cas de panne (logicielle ou matérielle) d'un des services.
Outre les sauvegardes quotidiennes décrites plus haut, la conservation des transactions récentes sur la base de données permet le rejeu de ces transactions sur le serveur Postgres, assurant ainsi, en cas d'attaque ou d'incohérence des données, un rétablissement de la base à l'instant voulu.

Notre hébergeur OVH assure aussi l'intégrité et la disponibilité des services par diverses mesures telles que la redondance des liaisons réseau, leur propre système de backup et la mise en place de groupes électrogènes de secours assurant plusieurs dizaines d'heures d'autonomie pour leurs sites hébergeant leurs salles serveurs.

La maintenance

Tout ce qui est de l'ordre de la maintenance physique est assuré par notre hébergeur sous-traitant OVH. OVH assure une maintenance physique « au mieux », pour assurer une disponibilité des services 24/7.

Les mesures générales de sécurité du système

Notre hébergeur OVH dispose d'un mécanisme de détection et prévention des attaques par déni de service distribuées (DdoS).

Sur l'ensemble de notre serveur, toute opération jugée suspecte provoque l'envoi d'un mail d'alerte à l'administrateur du serveur. Une restriction des adresses IP à une ensemble d'adresses connues ou préalablement déclarées est en place pour l'accès en SSH aux machines.

Les mesures de sécurité physique

Les mesures de sécurité physiques sont prises par notre hébergeur OVH et sont détaillées sur leur documentation en ligne (https://www.ovh.com/fr/protection-donnees-personnelles/securite.xml).

La mise en place d’une traçabilité 

Les erreurs applicatives Django provoquent l'envoi d'un rapport d'erreur à l'adresse électronique de l'administrateur technique de l'application.

En interne, un recueil de fiches post-accident (« postmortem ») contenant les mesures correctrices prises est maintenu à jour en continu.

Les mesures de sécurisation des matériels

La sécurisation du matériel utilisé par les employés fait écho aux mesures prises en termes de cloisonnement et de traçabilité décrites plus haut.

Une clé SSH par poste et par employé est utilisée pour l'accès aux serveurs, permettant une gestion aisée des accès (octroi ou révocation des droits d'accès aux serveurs, notamment).

Par ailleurs, aucune donnée des usagers n'est stockée sur support amovible.

Notre hébergeur OVH s'engage aussi à maintenir une politique de sécurisation des accès physiques, telle que disponible dans leur documentation (cf https://www.ovh.com/fr/protection-donnees-personnelles/securite.xml → 16. Gestion des accès physiques des tiers → Engagements pris par OVH en sa qualité d'hébergeur).

Les mesures proposées visant à éloigner les risques

Les mesures de sécurité face à des risques physiques sont prises par notre hébergeur sous-traitant OVH. Des mesures matérielles telles que la redondance des alimentations électriques, des supports mémoires, des systèmes de refroidissement notamment, sont prises par OVH.

Par ailleurs, notre architecture redondée est répartie entre deux sites géographiques différents, permettant de répondre aux risques d'altération de données ou d'indisponibilité des services sur l'un des deux sites. Les sauvegardes se situent quant à elles sur un autre site géographique encore.

Les audits de sécurité