| Quand | Quoi | Qui |
|---|---|---|
| 2026-06-26 18:17:24 +0200 | apply pre-commit-pandoc (#119175) | Thomas NOËL (tnoel@entrouvert.com) |
| 2026-06-23 16:36:34 +0200 | add lang in yaml/md | Thomas NOËL (tnoel@entrouvert.com) |
| 2026-06-23 16:23:39 +0200 | add plan-assurance-securite first draft | Thomas NOËL (tnoel@entrouvert.com) |
Le plan d’assurance sécurité précise les dispositions prises par Entr’ouvert, sur le périmètre de ses prestations, pour répondre aux clauses de sécurité.
Publik est une plate-forme libre et modulaire, destinée aux citoyens et aux services de l’administration publique pour simplifier leurs interactions.
La solution se compose de trois modules interconnectés :
Rappel des exigences en termes de sécurité de la plate-forme SaaS Publik :
Confidentialité des données: Les données traitées dans le cadre de la plateforme Publik contiennent des données Personnelles dépendant du RGPD. À ce titre Entr’ouvert met en place des technologies respectant les normes en vigueur et les bonnes pratiques en matière d’architectures et développements de systèmes informatiques sécurisés.
Intégrité des données: La plate-forme Publik met en relation des citoyens. De ce fait, la perte de données est problématique, on ne peut pas demander à ces citoyens de re-soumettre leurs demandes, car on ne sait pas qui a pu effectuer une démarche sur la plate-forme. C’est pour cela qu’Entr’ouvert privilégie l’intégrité des données et met en place plusieurs systèmes de sécurisation et de redondances de celles-ci.
Disponibilité des données: La plate-forme Publik possède une architecture redondée qui lui permet de faire face à plusieurs pannes matérielles ou logiciel. De plus celle-ci est configurée pour avoir assez de puissance pour pouvoir tourner avec la moitié de sa puissance nominale. Des tests de fonctionnement en mode dégradé et de bascule sont réalisés annuellement.
Entr’ouvert s’engage à mettre en œuvre les mesures de sécurité visant apporter une protection suffisante des données. 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.
Entr’ouvert s’engage au respect des standards de développement et de sécurité, pour des solutions opérationnelles et pleinement interopérables.
Entr’ouvert désignera un chef de projet technique (CPT) chargé de la mise en œuvre du plan et des incidents de sécurité. Un chef de projet fonctionnel (CPF) personne ressource auprès du conseil départemental et chargé de l’organisation des comités de suivi. Un comité de suivi de la sécurité sera organisé chaque année par le CPF sur demande de l’une ou l’autre des parties. CPF et CPT assisteront aux comités de suivi.
Des audits pourront être commandés par nos . Entr’ouvert s’engage à fournir les informations nécessaires en vue de leur réalisation optimale. Les interventions éventuelles d’Entr’ouvert seront facturées au prorata du temps passé.
Le suivi de chaque incident de sécurité est centralisé via l’outil de gestion de ticket d’Entrouvert, Redmine, à l’aide d’un ticket dans l’espace dédié au client et éventuellement de tickets techniques dans les projets de développement logiciel.
Entr’ouvert reconnaît être tenu à une obligation de conseil, de mise en garde et de recommandations en termes de sécurité et de mise à l’état de l’art. En particulier il s’engage à informer ses des risques d’une opération envisagée, des incidents éventuels ou potentiels, et de la mise en œuvre éventuelle d’actions correctives ou de prévention.
Entr’ouvert fournira la liste des administrateurs techniques habilités à se connecter aux machines. Entr’ouvert externalise la gestion des machines physiques, son sous-traitant est certifié ISO/CEI 27001. Les ressources liées au fonctionnement du service sont surveillées en continu.
Entr’ouvert forme ses travailleurs aux questions de sécurité et de confidentialités. Tous les travailleurs d’Entr’ouvert ont signé un avenant spécifique RGPD concernant le traitement des Données Personnelles
Entr’ouvert est responsable de la rédaction du PAS initial et de ses évolutions pour répondre aux clauses de sécurité du donneur d’ordres pendant toute la durée du contrat.
Une révision du Plan d’Assurance Sécurité pourra être réalisée en cas d’évolution du périmètre de l’opération, de l’environnement du S.I, ou des exigences de la maîtrise d’ouvrage, après accord de la maîtrise d’œuvre. Cette révision sera réalisée par le responsable sécurité désigné par Entr’ouvert sous forme de proposition de modification. Si cette modification est acceptée, le PAS est révisé, validé, puis diffusée à l’ensemble des acteurs pour application.
Le Plan d’Assurance Sécurité est applicable à l’ensemble des acteurs du projet.
Un acteur du projet qui n’est pas à même de remplir l’ensemble des clauses du PAS devra effectuer une demande de dérogation auprès d’Entr’ouvert.
Un acteur du projet qui identifie un non-respect du PAS dans ses procédures et mesures doit en référer immédiatement Entr’ouvert.
Pour chaque interface d’accès au système, (Interface Homme-Machine, interface entre applications) le titulaire doit fournir une documentation précisant :
Mécanismes d’authentification mis en œuvre (protocoles, algorithmes de hachage et de chiffrement utilisés).
Les mécanismes d’authentification supportés sont :
Les seuls rôles d’administration par défaut du fournisseur d’identités sont :
Gestionnaire des rôles,
Gestionnaire des collectivités (au sens unité organisationnelle — OU),
Gestionnaire des usagers,
Gestionnaire des services (i.e. des briques applicatives Publik)
Additionnellement, chaque rôle applicatif se voit attribuer un rôle d’administration pour usage en interne du fournisseur d’identités authentic2.
Les moyens d’authentification associés aux interfaces doivent être interopérables tant au niveau des applications des (par exemple navigateurs web, SSO Active Directory, authentification LDAP, …) que des systèmes d’exploitation.
Les raccordements à un Active Directory/Kerberos ou à un LDAP convenablement configurés sont supportés par Publik.
La gestion des habilitations se fait à l’aide des rôles dans Publik (Role-based access control — RBAC). Ceux-ci sont entièrement paramétrables.
Liste des dispositifs :
Dispositifs de contrôles :
Procédure de traçabilité
Les mots de passe doivent respecter l’état de l’art, par exemple la délibération n°2022-100 du 21 juillet 2022 portant adoption d’une recommandation relative aux mots de passe. A minima, ils devront comporter 12 caractères avec 3 types de caractères différents. La politique de choix des mots de passe est configurable dans Publik (longueur minimale, catégories de caractères à inclure). Par défaut, les mots de passe doivent contenir au moins 12 caractères, dont au moins une majuscule, une minuscule et un caractère spécial.
Chaque utilisateur doit posséder un identifiant dont il a la responsabilité. Cet identifiant est personnel et permet de garantir l’identité du porteur.
L’utilisation d’un même compte par plusieurs personnes n’est pas autorisée sauf si une contrainte le justifie.
Les comptes des usagers et des agents dans Publik sont nominatifs. Ils n’ont en aucun cas vocation à être partagés.
Pour la traçabilité, les informations suivantes sont enregistrées :
Entrée en session d’un utilisateur : date, heure, identifiant de l’utilisateur et du terminal, réussite ou échec de la tentative, les connexions et déconnexions des usagers sont logguées par le serveur Web, i.e. nginx.
Actions qui tentent d’exercer des droits d’accès à un objet soumis à l’administration des droits : date, heure, identité de l’utilisateur, nom de l’objet, type de la tentative d’accès, réussite ou échec de la tentative, la journalisation de l’ensemble des actions dans Publik est accessible. Par souci de lisibilité, un même type d’accès n’est enregistré qu’une fois par heure.
Création/suppression d’un objet soumis à l’administration des droits : date, heure, identifiant de l’utilisateur, nom de l’objet, type de l’action.
Actions d’utilisateurs autorisés affectant la sécurité de la cible : date, heure, identité de l’utilisateur, type de l’action, nom de l’objet sur lequel porte l’action.
Les traces sont conservées pendant la période légale relative aux données enregistrées ou, à défaut de valeur plus spécifique, pendant une période d’une année. Une fois cette période passée, si les logs doivent être conservés pour des raisons techniques ceux-ci sont anonymisés conformément aux recommandations de l’ANSSI.
Les évolutions fonctionnelles ou techniques ne doivent pas remettre en cause le respect des mesures de sécurité. Si un contournement provisoire nécessite la désactivation d’une fonctionnalité indispensable au système, Entr’ouvert s’engage à proposer des mesures permettant d’éviter l’exploitation de la vulnérabilité dans un délai inférieur à 15 jours.
Le traitement des alertes de sécurité mineures doit intervenir durant les périodes de maintenance hebdomadaires ou mensuelles dans un délai de 30 jours.
Les passages de correctifs doivent être précédés d’une sauvegarde spécifique du système et des données qu’il contient, ainsi que de tests sur un environnement de pré production.
Entr’ouvert fournit des notes de mise à jour systématiquement. Outre les apports fonctionnels, les notes de mise à jour contiennent notamment les correctifs de sécurité – https://doc-publik.entrouvert.com/notes-de-mises-a-jour/
En cas d’alerte donnée par les équipes d’Entr’ouvert, les opérations de mise en sécurité seront notifiées en amont, sur la liste courriel du projet.
Le support Entr’ouvert est disponible aux heures ouvrées (9h30-12h30 et 14h00-18h00) les jours ouvrés, joignable sur la plateforme de gestion de ticket.
Une procédure de gestion des incidents de sécurité est formalisée.
Tout incident de sécurité (anomalie, irrégularité, malveillance, fraude, vulnérabilités, vol de données, comportement anormal) sera signalé auprès de nos dans les meilleurs délais et au maximum dans les 12 heures.
Les canaux de communication des incidents sont:
Tout incident de sécurité détecté fera l’objet d’une analyse et une qualification sera réalisée sur les impacts potentiels en fonction de la criticité des ressources impactées, de l’étendue du périmètre, de la durée de l’incident. De façon plus générale, nous procédons à des post-mortems, détaillant l’origine de la panne et les corrections apportées. Ces post-mortems sont archivés et une communication est faite a tous les clients concernés en fin d’analyse.
La politique de protection comporte notamment les éléments suivants :
Cas des pare-feu applicatifs
Les pare-feux applicatifs sont utilisés pour sécuriser une application web ou accessible en réseau des vulnérabilités connues et non corrigés de l’applicatif.
Nous utilisons ce type de pare-feu dans une optique de surveillance et de détection rapide de vulnérabilités potentielles, afin de les corriger au plus vite. Nous mettons en place une procédure de « hotfix » en cas d’alerte de sécurité.
Nous utilisons également des pare-feu réseau et des mécanismes de blocage en cas de saturation du SaaS.
Entr’ouvert gère la sauvegarde de toutes ses installations, les sauvegardes sont quotidiennes (nocturnes) et conservées :
En plus des sauvegardes complètes à chaud des systèmes, un archivage des transactions des bases de données est réalisé, cela permet de rejouer les modifications de données et de récupérer des données à la minute. Les restaurations sont testées régulièrement. Entr’ouvert dispose d’une procédure de restauration simple, que ce soit une restauration partielle « sur site » ou totale sur une nouvelle instance.
Les sauvegardes sont situées sur un autre site géographique que le
site de production.
Tous les flux lors des opérations de sauvegarde sont chiffrés, les
disques stockant les sauvegardes ne le sont pas.
La gestion des supports est opérée par notre hébergeur OVH. Nous ne possédons pas les machines, mais les louons directement à OVH.
Entr’ouvert dispose de deux administrateurs systèmes et de techniciens, habilités à effectuer les opérations de maintenance.
Des comptes nominatifs seront utilisés pour toute opération de maintenance, garantissant ainsi l’imputabilité des actions réalisées sur les serveurs.
Seules les clés SSH des personnes habilitées à effectuer les opérations de maintenance sont déclarées comme autorisées sur les serveurs, empêchant de fait l’accès à une personne qui ne détient pas l’habilitation.
Il n’y aura pas nécessité d’ouvrir des accès à distance aux serveurs hébergeant Publik.
Un accès SSH nominatif et temporaire pour certains membres de l’équipe technique d’Entr’ouvert pourra être utile lors du développement de connecteurs.
Les usagers accèdent à la plateforme uniquement en HTTPS. Les connecteurs communiquent entre eux via HTTPS ; une connexion avec des annuaires LDAP est possible avec filtrage des adresses IP.
Les administrateurs accèdent aux machines via le protocole SSH, limité aux adresses IP d’Entr’ouvert. Le port SSH est restreint, il n’est accessible que pour les administrateurs et certaines IP identifiés.
Les autres ports réseau sont fermés.
Tous les flux sont chiffrés sont chiffrés par des protocoles fiables (SSL, SSH, Ip Sec) sauf les e-mails émis par la plateforme.
Les environnements de recette (nommée aussi test ou préproduction) sont identiques en terme de configuration et de logiciels avec l’environnement de production (avec néanmoins moins de ressources). Ils sont complètement isolés des environnements de production.
Les serveurs ne comportent que les logiciels nécessaires pour rendre le service et assurer la sécurité de ceux qui sont installés. Les services non nécessaires sont désinstallés ou désactivés s’ils ne peuvent pas l’être.
Il est possible d’installer un certificat conforme RGS. La fourniture de celui-ci est à la charge de .
L’infrastructure de l’hébergement mutualisée est composée de serveurs répartis sur les centres de données français d’OVH (Roubaix, Gravelines et Strasbourg) en accès et sauvegarde.
Nos services sont redondants et répliqués en continu afin d’assurer une disponibilité permanente.
Entr’ouvert effectue une revue de code systématique. Celle-ci s’appuie sur des outils d’analyse statique de code lancés automatiquement et sur une relecture par un·e pair·e développeur·se d’Entr’ouvert. L’intégralité du code qui compose l’application Publik est ainsi systématiquement relue avant validation.
Les tests automatisés sont été intégrés au processus (“Intégration continue”) pour s’assurer que le code est sécurisé avant la livraison. Les tests incluent aussi des analyses de code statiques pour détecter les vulnérabilités potentielles. Le serveur d’intégration d’Entr’ouvert est visible à l’adresse https://jenkins.entrouvert.org/
Les audits de sécurité sont effectués régulièrement par les clients d’Entr’ouvert sur la solution Publik. Les restitutions d’audits de sécurité peuvent donner lieu à la création de tickets dans le but d’apporter, lorsque nécessaire, des correctifs logiciels face aux éventuels problèmes identifiés.
Des audits de sécurité sont également menés sur la solution à l’initiative d’Entr’ouvert.
Nos développeurs et nos chefs de projets techniques sont au fait des dernières normes de sécurité et assure une veille sur les sujets de :
Les risques identifiés pour le service Publik sont :
DDOS (perte de disponibilité)
Défaçage du site (perte de réputation)
Injection de faux utilisateurs et de fausses demandes (perte d’intégrité des données)
Fuite de données utilisateurs (perte de confidentialité)
Nos mesures de sécurisation prennent en compte les risques ci-dessus.
Le terme RACI est l’acronyme de « Réalisateur , Approbateur, Consulté et Informé
| Action | Entr’ouvert | Hébergeur |
|---|---|---|
| Authentification et gestion des droits | C | R/A |
| Imputabilité, traçabilité | C | R/A - |
| Mises à jour, correctifs de sécurité | R/A | I - |
| Gestion des incidents de sécurité | R/A | I - |
| Protection contre les logiciels malveillants | R/A | I C |
| Sauvegardes et restaurations | R/A | - - |
| Supports de données et équipements sensibles | R/A | - R |
| Intervention des sociétés de maintenance ou de support | R/A | I R |
| Accès distants au système d’information de | I | R/A - |
| Architecture de sécurité | R/A | I C |
| Localisation des données | R/A | I C |
| Continuité d’activité | R/A | I R |
| Développement et sécurité | R/A | I - |
| Appréciations des Risques | R/A | I C |
Suivi des documents concernant la sécurité :
| Nature du document | Date de remise | Commentaire |
|---|---|---|
| Plan d’Assurance Sécurité | ||
| Comptes-rendus de réunion du comité de suivi | Une semaine après chaque réunion |