Sécurité

Traduction de courtoisie. Seule la version italienne de ce document a une valeur juridique : en cas de divergence, le texte italien prévaut. Le droit italien s'applique en tout état de cause.

Notre approche

La sécurité d'une plateforme qui héberge les contenus et l'identité de marque de ses clients n'est pas une fonction que l'on ajoute à la fin : c'est une contrainte de conception.

Nous appliquons trois principes simples. Collecter le minimum, ne donner à chacun que les accès nécessaires à son travail, et rendre vérifiable ce qui se passe.

Les mesures décrites ici sont celles qu'exige l'article 32 du RGPD : adaptées au risque, non maximales dans l'absolu. Nous les révisons quand le produit change ou quand un incident nous apprend quelque chose.

Chiffrement en transit

Tout le trafic vers la plateforme et vers le site passe en HTTPS. Les connexions en clair sont redirigées vers la version chiffrée.

Les cookies techniques posés par le site portent l'attribut Secure, ils ne circulent donc jamais sur une connexion non chiffrée, et ceux de session portent aussi HttpOnly.

Les appels vers les fournisseurs connectés, des modèles de langage aux services de publication, passent par des canaux chiffrés et authentifiés.

Chiffrement au repos

Les données stockées, y compris les contenus, les matériaux chargés et les sauvegardes, sont chiffrées au repos par la plateforme ou par l'infrastructure qui les héberge.

Les brouillons d'inscription, qui peuvent contenir des données d'entreprise avant même l'existence du compte, sont chiffrés côté serveur et ne restent jamais dans le navigateur.

Les mots de passe ne sont conservés en clair sous aucune forme récupérable.

Gestion des secrets

Les clés des interfaces fournisseurs, les jetons des services connectés et les identifiants que le client configure pour publier sur son propre site sont des secrets, et nous les traitons comme tels.

• Ils sont chiffrés au repos avec un chiffrement authentifié.
• Ils n'apparaissent jamais dans les journaux, les messages d'erreur ou les réponses des interfaces.
• Une fois enregistrés, ils ne sont plus affichés dans l'interface : on peut seulement les remplacer.
• Ils ne sont accessibles qu'aux composants de l'application qui doivent les utiliser.

Contrôle des accès

Tout accès aux systèmes de production se fait sous une identité nominative. Il n'existe pas de comptes partagés entre plusieurs personnes.

Nous appliquons le moindre privilège : chacun reçoit les droits qu'exige son rôle, et rien de plus. Les droits sont revus quand le rôle change et révoqués quand la relation prend fin.

Nos équipes n'accèdent aux données d'un client que pour une assistance demandée, le diagnostic d'une panne ou une obligation légale, et cela laisse une trace.

Isolation entre clients

Chaque client travaille dans un espace séparé. Les contenus, matériaux, réglages et clés d'un client ne sont pas atteignables depuis un autre.

La séparation est appliquée au niveau des données et vérifiée à chaque requête : l'identifiant de l'espace de travail fait partie du contrôle d'autorisation, ce n'est pas un simple filtre d'interface.

Les contenus d'un client n'alimentent jamais ceux d'un autre et ne contribuent à aucun modèle partagé.

Sauvegardes et restauration

Nous réalisons des sauvegardes régulières des données de la plateforme, conservées chiffrées et séparées de l'environnement de production.

Les procédures de restauration sont documentées et testées : une sauvegarde jamais restaurée n'est pas une sauvegarde, c'est un espoir.

La conservation des sauvegardes suit la même logique de minimisation que les données : on garde ce qu'il faut pour restaurer, pas davantage.

Journaux et surveillance

Nous enregistrons les événements utiles à la sécurité et au diagnostic : authentifications, opérations sur les données, résultats des traitements, erreurs applicatives.

Les journaux servent à comprendre ce qui s'est passé, pas à profiler des personnes. Ils ne contiennent aucun secret ni, autant que techniquement évitable, de contenus sensibles du client.

Un système de surveillance des erreurs signale les anomalies en temps réel : un défaut est ainsi vu par nous avant de l'être par le client.

Gestion des incidents

Nous disposons d'une procédure documentée de gestion d'un incident de sécurité. En résumé.

1. Détection : l'anomalie provient de la surveillance, d'un signalement interne ou d'un signalement externe.
2. Confinement : la propagation est limitée immédiatement, quitte à dégrader temporairement une fonction.
3. Évaluation : on établit ce qui a été exposé, quels clients sont concernés et si des données personnelles sont en jeu.
4. Communication : les clients concernés sont informés et, le cas échéant, assistés dans les notifications légales.
5. Correction : la cause est corrigée et la correction est vérifiée.
6. Analyse : on écrit ce qui s'est passé et ce qui change pour que cela ne se reproduise pas.

Notification d'un incident

Si un incident touche des données personnelles traitées pour le compte d'un client, nous en informons ce client sans délai injustifié, comme l'exige l'article 33 paragraphe 2 du RGPD.

Le premier message part dès que l'incident est confirmé, même si le tableau n'est pas encore complet, et il est suivi de mises à jour au fil de l'analyse.

Le client, en sa qualité de responsable, reste tenu de notifier l'autorité de contrôle dans le délai fixé par l'article 33 du RGPD et, le cas échéant, d'informer les personnes concernées. Nous l'assistons avec les informations techniques nécessaires.

Obligations prévues par l'accord sur le traitement

Divulgation responsable

Si vous avez découvert une vulnérabilité, écrivez à info@flarseo.com avec "sécurité" en objet. Nous lisons et nous répondons.

• Décrivez le problème, la manière de le reproduire et l'impact que vous estimez.
• N'accédez pas à des données qui ne vous appartiennent pas, ne les modifiez pas et ne les supprimez pas.
• Ne publiez pas la vulnérabilité avant qu'elle soit corrigée ou que nous en ayons discuté ensemble.
• Évitez les tests qui dégradent le service pour les autres clients.

Nous n'engageons aucune action contre les personnes qui signalent de bonne foi en respectant ces conditions. Nous ne gérons pas de programme de récompenses : nous remercions et, si vous le souhaitez, nous vous citons.

Ce que nous ne déclarons pas

Nous préférons une page honnête à une page impressionnante.

• Nous ne revendiquons aucune certification que nous n'avons pas : aucune certification ISO, aucun rapport d'attestation d'un tiers.
• Nous ne présentons pas des tests d'intrusion périodiques réalisés par des tiers comme une pratique établie.
• Nous ne promettons pas l'absence de vulnérabilités : aucun système ne peut le promettre.

Si l'un de ces points change, cette page le dira avec une nouvelle version et une nouvelle date, pas avant.

Les mesures décrites ici sont celles en place à la date indiquée ci dessus. Les obligations contractuelles de sécurité sont celles de l'accord remis en annexe du contrat, en italien, lors de l'inscription.