Prenez soin de vos bénéficiaires, nous veillons sur votre plateforme

Un ralentissement progressif des tentatives de connexion infructueuses. Les échecs répétés déclenchent des délais croissants avant de nouvelles tentatives, afin de freiner les essais de mots de passe.

Une limitation des essais de codes de double authentification. Les essais de codes TOTP sont limités séparément pour freiner les tentatives répétées après la saisie du mot de passe.

Un encadrement des demandes de récupération pour limiter les e-mails abusifs. Le nombre de demandes de récupération est encadré pour réduire les envois répétés vers la boîte e-mail d'un utilisateur.

Une limitation des e-mails de vérification demandés par un même compte. Les demandes d'ajout d'adresses e-mail sont limitées par compte pour réduire les envois de vérification abusifs.

Des compteurs de tentatives partagés entre les serveurs. Les serveurs s'appuient sur des compteurs communs pour appliquer les délais. En cas d'indisponibilité de ce service, la limitation peut être temporairement levée.

Une réponse de récupération qui ne confirme pas l'existence d'un compte. Le parcours renvoie la même réponse qu'une adresse soit connue ou non, pour éviter de révéler directement l'existence du compte.

Les sessions ouvertes consultables depuis son espace personnel. Retrouvez les sessions associées à votre compte dans votre espace personnel.

Le navigateur, l'appareil et les dates de connexion pour repérer une session inhabituelle. Consultez le type d'appareil, le navigateur et les dates associées pour reconnaître vos connexions.

L'adresse IP et une localisation indicative pour mieux identifier ses connexions. L'adresse IP et, lorsqu'elle est disponible, une localisation approximative complètent les informations de session.

La possibilité de révoquer une autre session de son compte. Révoquez une session que vous ne reconnaissez pas. Son renouvellement est bloqué ; un jeton d'accès déjà délivré peut rester valide jusqu'à expiration.

Un historique des sessions récemment terminées. Consultez les sessions expirées ou révoquées pour garder des repères sur vos accès récents.

La suppression des appareils de notification associés lors d'une révocation, par défaut. La révocation retire par défaut les appareils de notification rattachés à la session concernée.

Des jetons d'accès signés et limités dans le temps. Les jetons sont vérifiés avant d'être acceptés et comportent une expiration pour limiter leur durée d'utilisation.

Une vérification du compte et de la session lors du renouvellement de l'accès. Le renouvellement vérifie notamment que le compte est actif et que la session n'a pas été révoquée.

Un cookie de renouvellement inaccessible aux scripts de la page. L'attribut HttpOnly empêche les scripts de la page de lire directement le cookie utilisé pour renouveler la session.

Un cookie de renouvellement réservé à HTTPS. L'attribut Secure limite la transmission de ce cookie aux connexions HTTPS sur la plateforme en production.

Un cookie limité au même site pour réduire les risques de requêtes intersites. L'attribut SameSite=Strict restreint l'envoi du cookie dans les requêtes provenant d'un autre site.

Des autorisations vérifiées côté serveur, pas seulement dans l'interface. Les opérations protégées passent par des contrôles d'autorisation sur le serveur, indépendamment des boutons affichés.

Des rôles distincts pour les bénéficiaires et les administrateurs. Les actions d'administration sont distinguées des usages ordinaires pour réserver la gestion aux personnes habilitées.

Des droits de gestion limités aux rubriques confiées à chaque responsable. Confiez la gestion de rubriques à des responsables sans leur attribuer l'administration complète de la plateforme.

Des gestionnaires de groupes avec un périmètre défini. Les responsables désignés interviennent sur les groupes qui leur sont confiés et sur leurs membres.

Des contrôles d'accès aux pages et rubriques selon leurs audiences. Les contrôles des pages et rubriques tiennent compte de leur rattachement à un segment ou à un groupe.

Des périodes de publication pour encadrer la visibilité des pages. Définissez les dates de visibilité des pages pour organiser leur mise à disposition.

Des périodes d'ouverture pour encadrer les réponses aux formulaires. Fixez une période de participation pour encadrer la collecte des réponses.

Des conversations accessibles à leurs participants. L'accès aux conversations est contrôlé selon la participation de l'utilisateur à l'échange.

Des résultats de formulaires réservés aux personnes habilitées. Les résultats détaillés sont accessibles aux administrateurs et aux gestionnaires habilités du formulaire.

Des exports soumis aux autorisations du module concerné. La préparation d'un export est contrôlée selon les droits nécessaires pour accéder aux données du module.

Une validation préalable des commentaires et annonces lorsqu'elle est activée. Selon vos réglages, les contributions concernées passent par une validation avant leur publication.

Des outils de modération pour retirer les contributions indésirables. Les personnes habilitées peuvent retirer les commentaires ou les annonces qui ne respectent pas le cadre fixé.

Des documents d'information et des acceptations enregistrées. Présentez les documents actifs aux utilisateurs et conservez les acceptations recueillies pour suivre votre démarche d'information.

Un cloisonnement des données entre CSE au niveau de la base de données. Des politiques PostgreSQL (RLS) limitent l'accès aux lignes des tables concernées selon le CSE associé à la requête.

Une cohérence vérifiée entre la plateforme demandée et le jeton de connexion. Une requête est refusée si la plateforme indiquée ne correspond pas à celle du jeton d'accès.

Une infrastructure dédiée possible pour isoler davantage votre CSE. Selon l'offre retenue, votre CSE peut bénéficier d'une infrastructure dédiée plutôt que d'une partition partagée.

Une base de données sans accès public direct. La base de données est placée dans le réseau privé et n'est pas configurée pour être accessible directement depuis Internet.

Des serveurs applicatifs en réseau privé, sans adresse IP publique. Les tâches applicatives s'exécutent dans des sous-réseaux privés, derrière les points d'entrée prévus pour le service.

Des règles réseau limitant les accès à la base de données. Les groupes de sécurité encadrent les connexions autorisées vers le port de la base de données.

Un accès privé à l'origine de l'API sur les partitions équipées. Les partitions configurées avec une origine VPC utilisent un accès privé entre CloudFront et le point d'entrée de l'API.

Des communications chiffrées entre CloudFront et l'origine de l'API. Les connexions entre CloudFront et le point d'entrée de l'API utilisent HTTPS.

Des connexions chiffrées à la base avec vérification du certificat. Les connexions à PostgreSQL utilisent TLS et vérifient le certificat du serveur avant d'échanger des données.

Une authentification IAM de l'application auprès de la base de données. L'application utilise des jetons d'authentification IAM pour se connecter à la base plutôt qu'un mot de passe applicatif permanent.

Un rôle de base de données applicatif distinct des opérations d'administration. Le rôle utilisé pour les requêtes courantes est distinct des accès nécessaires aux opérations d'administration de la base.

Des secrets techniques conservés dans un gestionnaire dédié. Les secrets de l'infrastructure sont fournis aux services via AWS Secrets Manager.

Des permissions techniques séparées selon le rôle de chaque service. Les services disposent de rôles et de permissions adaptés à leurs tâches, notamment pour l'application et les sauvegardes.

Un accès au stockage S3 depuis le réseau privé via un point d'accès réseau dédié. Un endpoint S3 permet aux services du réseau privé d'accéder au stockage sans passer par la sortie Internet habituelle.

Des liens signés pour accéder aux fichiers et aux images. Les URL de diffusion comportent une signature et une expiration. Elles restent utilisables par leur détenteur pendant leur durée de validité.

Une navigation redirigée vers HTTPS. Les requêtes HTTP vers la plateforme sont redirigées vers une connexion chiffrée HTTPS.

Une politique HSTS pour maintenir la navigation en HTTPS. Le navigateur reçoit une politique qui lui demande de privilégier HTTPS pour les visites suivantes.

Une protection contre l'intégration du site dans une page tierce. L'en-tête X-Frame-Options refuse l'affichage du site dans une frame pour réduire les risques de détournement de clics.

Une protection contre l'interprétation trompeuse du type des fichiers. L'en-tête nosniff demande au navigateur de respecter le type de contenu déclaré plutôt que de le deviner.

Des informations de provenance limitées lors des visites vers d'autres sites. La politique de provenance réduit les informations transmises dans l'en-tête Referer lors d'une navigation vers un autre site.

Un filtrage du contenu riche avant son affichage. Le rendu des textes enrichis filtre les structures et attributs autorisés avant de produire le contenu affiché.

Des protocoles de liens filtrés dans les textes enrichis. Les liens des textes enrichis sont limités aux protocoles prévus, comme HTTPS, mailto ou tel.

Des espaces de stockage de fichiers non ouverts au public. Le stockage des fichiers bloque l'accès public direct ; leur diffusion passe par les mécanismes prévus par la plateforme.

Des fichiers stockés avec chiffrement côté serveur. Les fichiers conservés dans S3 bénéficient du chiffrement côté serveur configuré pour leur espace de stockage.

Des dépôts de fichiers autorisés par une signature et une taille imposée. Les autorisations de dépôt ciblent un emplacement précis et imposent la taille déclarée du fichier.

Des documents servis en téléchargement pour limiter l'exécution de contenus actifs. Les fichiers du parcours de téléchargement sont servis en pièces jointes afin de limiter leur interprétation comme une page active.

Un accès au service de transformation d'images authentifié par AWS. L'origine utilisée pour transformer les images exige une authentification AWS, avec des requêtes signées depuis CloudFront.

Des réponses API exclues du cache partagé de CloudFront. Le comportement CloudFront de l'API désactive la mise en cache pour ne pas conserver ses réponses dans le cache partagé.

Des sauvegardes automatiques de la base conservées trente-cinq jours. La configuration RDS prévoit une fenêtre de sauvegarde de trente-cinq jours pour la base de données.

Une protection contre la suppression accidentelle de la base. La protection RDS contre la suppression ajoute une étape explicite avant de pouvoir supprimer l'instance.

Des versions précédentes des fichiers conservées pendant quatre-vingt-dix jours. Le versionnement S3 conserve les anciennes versions des fichiers, avec une règle d'expiration à quatre-vingt-dix jours.

Une sauvegarde d'archive hebdomadaire de la base et des fichiers. Une tâche planifiée prépare chaque semaine une archive des données de la base et des fichiers de chaque partition.

Des archives chiffrées avant leur transfert vers le stockage de sauvegarde. Les archives sont chiffrées avant d'être envoyées vers leur stockage central.

Un espace central de sauvegarde privé, chiffré et accessible uniquement en HTTPS. Le stockage central bloque l'accès public, chiffre les objets côté serveur et refuse les transferts sans HTTPS.

Une durée de conservation de trois cent soixante-cinq jours configurée pour les archives. Une règle de cycle de vie prévoit l'expiration des archives après trois cent soixante-cinq jours, sans constituer un stockage immuable.

Un versionnement du stockage central de sauvegarde. Le bucket central conserve des versions d'objets pour ne pas se limiter à leur dernier état.

Un rôle de sauvegarde limité à la lecture des données sources. L'extraction utilise des accès en lecture seule pour récupérer les données sans les modifier.

Un processus d'envoi sans droit de lire ni de supprimer les archives déjà stockées. Le rôle qui dépose les archives dans le stockage central ne dispose pas de droits pour lire ou supprimer celles déjà présentes.

Une réplication mensuelle hors AWS, sous réserve de sa configuration opérationnelle. Une copie mensuelle vers OVH est prévue pour diversifier le stockage.

Des alertes en cas d'échec ou de retard des sauvegardes. Des alertes signalent les échecs des tâches et les archives dont la fraîcheur ne correspond plus aux seuils attendus.

Une restauration de la base à un instant précis grâce au PITR. Le PITR (Point-in-Time Recovery) permet aux équipes LiveCSE de restaurer la base à un instant choisi dans la fenêtre de récupération disponible. Une restauration depuis une sauvegarde reste également possible.

Un mode lecture seule pour protéger les données pendant une restauration. La procédure suspend les écritures pendant la restauration et conserve ce mode en cas d'échec nécessitant une intervention.

La base précédente conservée pour permettre un retour arrière après restauration. L'ancienne instance est conservée après la bascule afin de permettre un retour arrière avant sa suppression par les équipes.

Une vérification des droits de lecture avant de sauvegarder les tables cloisonnées. Le processus vérifie les politiques de lecture nécessaires pour éviter d'omettre les données des tables protégées par RLS.

Un contrôle de lisibilité des sauvegardes de base avant leur archivage. Le dump est contrôlé par une lecture avec pg_restore avant archivage. Ce contrôle ne remplace pas un exercice complet de restauration.

Un contrôle de taille des archives répliquées hors site. La copie hors site compare la taille du fichier obtenu à celle de l'archive source pour détecter une copie incomplète.

Un nettoyage des fichiers temporaires en clair après un archivage réussi. Une fois l'archivage terminé avec succès, le processus supprime les fichiers temporaires de préparation non chiffrés.

Une surveillance externe du parcours jusqu'à la base de données. Une sonde externe vérifie un parcours HTTPS jusqu'au backend et à la base sur un domaine représentatif de chaque partition.

Des alertes techniques en cas d'indisponibilité détectée. Les contrôles de disponibilité peuvent déclencher une alerte vers les équipes en cas d'échec.

Une surveillance de l'espace disque et des connexions à la base. Des indicateurs et seuils d'alerte aident les équipes à repérer les tensions sur la capacité et les connexions.

Des alertes sur l'accumulation des traitements en attente. La surveillance des files aide à détecter les traitements qui s'accumulent et nécessitent une intervention.

Des traces techniques pour faciliter l'analyse des incidents. Les services produisent des traces d'exploitation pour aider les équipes à comprendre les dysfonctionnements.

Un suivi des erreurs applicatives pour faciliter leur diagnostic. Les erreurs internes sont remontées dans un outil de suivi afin de faciliter leur analyse.

Des vérifications de santé des services applicatifs. Des contrôles de santé permettent à l'infrastructure de vérifier la disponibilité des tâches applicatives.

Un retour arrière automatique prévu en cas d'échec d'un déploiement. Le mécanisme de déploiement prévoit un retour à la version précédente si le nouveau déploiement échoue.

Des limites de durée des requêtes et transactions pour réduire les blocages. Des délais maximaux encadrent les requêtes et les transactions inactives pour éviter qu'elles occupent les ressources indéfiniment.

Des e-mails envoyés depuis un domaine identifié à votre CSE. Vos messages sont envoyés depuis un domaine personnalisé associé à votre plateforme, pour aider les bénéficiaires à reconnaître les communications de leur CSE.

Une signature DKIM pour authentifier les e-mails envoyés. Les e-mails envoyés sont signés pour permettre aux destinataires de vérifier leur origine et leur intégrité.

Une configuration SPF pour déclarer les serveurs d'envoi autorisés. Le domaine d'envoi publie les informations SPF indiquant les services autorisés à envoyer des e-mails pour lui.

Des rapports DMARC pour surveiller l'utilisation du domaine d'envoi. La configuration DMARC demande des rapports sur les envois utilisant le domaine.

Des équipes sensibilisées aux enjeux de sécurité. Nous sensibilisons nos équipes aux risques et aux bonnes pratiques pour faire de la sécurité un réflexe dans leur travail quotidien.

Des analyses de vulnérabilités et évaluations de sécurité périodiques, assistées par IA. Nous nous appuyons sur les modèles d'IA les plus récents pour mener régulièrement des analyses de vulnérabilités et des évaluations de sécurité.

Un suivi des recommandations de l'OWASP et de l'ANSSI. Nous suivons les recommandations de l'OWASP (Open Worldwide Application Security Project) et de l'ANSSI (Agence nationale de la sécurité des systèmes d'information) pour faire évoluer nos pratiques de développement et d'exploitation.