Déclaration de sécurité

La présente déclaration décrit les mesures techniques et organisationnelles qui protègent le service RavSolutions et les données qu'il contient. Elle est rédigée pour être vérifiable : elle nomme des mesures réellement mises en œuvre, et la section 15 indique tout aussi clairement ce dont nous ne disposons pas.

Elle ne constitue pas une garantie et ne crée aucun engagement de niveau de service ; les stipulations contractuelles figurent dans les Conditions générales. Lorsqu'une même mesure apparaît aussi dans l'information RGPD ou dans l'information sur la sous-traitance, elle doit y dire la même chose sur le fond.

Elle porte sur le service que nous exploitons. La sécurité des comptes, des appareils et des mots de passe au sein de l'espace de travail d'un abonné relève de celui-ci ; aucune mesure décrite ici ne protège un espace de travail dont les identifiants ont été partagés ou réutilisés ailleurs.

Le service se compose de trois interfaces – le site web, l'application et le portail client –, d'une seule API, d'une base de données PostgreSQL, d'une instance Redis et d'un stockage objet. Les interfaces n'atteignent l'API qu'en HTTPS.

Tout, à l'exception du stockage objet, s'exécute derrière un proxy inverse sur l'infrastructure de RackForest Zrt. en Hungary (EU). La base de données et Redis sont raccordées à un réseau interne uniquement et n'exposent aucun port : elles sont donc inaccessibles depuis Internet et seule l'API peut leur parler.

Les fichiers téléversés ne résident pas sur les serveurs applicatifs mais dans le stockage objet Cloudflare R2, configuré pour European Union. Le bucket est privé : aucun accès public, aucun domaine personnalisé en façade, et chaque fichier est servi via un lien signé par l'API.

Les secrets – identifiants de base de données, clés de signature, clés d'API des prestataires – sont fournis par l'environnement au moment du déploiement et ne sont jamais versés au dépôt de code source.

L'ensemble du trafic vers le site, l'application, le portail et l'API est servi en HTTPS. Les certificats sont émis et renouvelés automatiquement par Let's Encrypt et les requêtes HTTP en clair sont redirigées vers HTTPS.

Le proxy inverse envoie un en-tête HTTP Strict Transport Security d'une durée d'un an, sous-domaines inclus et avec préchargement, de sorte qu'un navigateur ayant déjà vu le site ne revient pas à une connexion non chiffrée.

Les réponses portent X-Content-Type-Options: nosniff, X-Frame-Options: SAMEORIGIN, une politique de référent strict-origin-when-cross-origin et une politique d'autorisations refusant la caméra, le microphone et la géolocalisation. Les en-têtes révélant le serveur et le cadriciel sont supprimés. L'API n'accepte de requêtes multi-origines que depuis les origines de l'application et du portail.

Le site web, l'application et le portail sont servis avec une Content Security Policy. Les scripts ne peuvent être chargés que depuis le service lui-même et, dans l'application, depuis Google Identity Services pour la connexion avec Google ; le site web et le portail n'autorisent aucun script tiers. L'intégration dans un cadre, les contenus de greffons et la réécriture de la base du document sont refusés, et l'API répond avec une politique qui n'autorise absolument rien.

Un mot de passe compte au moins huit caractères et comporte une majuscule, une minuscule et un chiffre. Les mots de passe ne sont conservés que sous forme d'empreinte cryptographique salée produite par le hacheur de mots de passe d'ASP.NET Core Identity, jamais sous une forme relisible : nous ne pouvons donc pas restituer un mot de passe oublié, seulement en faire définir un nouveau.

Après dix tentatives de connexion infructueuses, le compte est verrouillé pendant quinze minutes. Le décompte porte sur le compte et non sur l'appelant : une tentative répartie sur de nombreuses adresses est donc arrêtée alors même que chaque adresse reste sous la limite par appelant.

La connexion avec un compte Google est possible. Le jeton d'identité délivré par Google est vérifié auprès de Google avant la création de toute session, et nous ne recevons jamais le mot de passe Google.

L'inscription envoie un message de confirmation à l'adresse indiquée, laquelle est considérée comme confirmée dès l'utilisation du lien qu'il contient. Un mot de passe oublié se réinitialise par un lien à usage unique envoyé à l'adresse enregistrée ; une réinitialisation réussie lève également un verrouillage en cours, car c'est généralement lui qui l'a motivée.

Les jetons d'accès sont des JSON Web Tokens valables quinze minutes. Chaque requête est contrôlée quant à l'émetteur, au destinataire, à la signature et à l'expiration, sans aucune tolérance d'horloge.

Un jeton de rafraîchissement est constitué de soixante-quatre octets issus d'un générateur aléatoire cryptographique. La base de données n'en conserve que l'empreinte SHA-256 : le jeton lui-même ne peut donc pas être extrait d'une copie de la base.

Chaque rafraîchissement remplace le jeton : le précédent est révoqué et un nouveau est émis. Les jetons de rafraîchissement expirent au bout de trente jours et la déconnexion révoque le jeton immédiatement.

Un rafraîchissement est refusé si l'utilisateur a été désactivé ou l'espace de travail rendu inactif ; le retrait d'un accès prend donc effet au plus tard à l'expiration du jeton d'accès en cours.

Chaque utilisateur détient un rôle dans l'espace de travail et les points d'accès le vérifient. Les fonctions dépendant de la formule sont en outre protégées par leurs propres politiques d'autorisation : une fonction hors formule souscrite est refusée par l'API, et pas seulement masquée dans l'interface.

Les espaces de travail sont séparés au niveau des données : chaque enregistrement porte l'identifiant de l'espace auquel il appartient et chaque requête est cantonnée à l'espace de l'appelant. Un enregistrement d'un autre espace n'est pas masqué du résultat : il n'y entre jamais.

L'espace de travail est tiré d'une revendication du jeton d'accès signé et résolu côté serveur. Aucun identifiant d'espace transmis par le client n'est jugé digne de confiance, à quelque fin que ce soit.

Les connexions en temps réel utilisent la même authentification que le reste de l'API ; une connexion sans jeton valide est refusée, la taille des messages entrants est plafonnée et les informations d'erreur détaillées ne sont renvoyées qu'en environnement de développement.

Le client reçoit un lien contenant un jeton généré aléatoirement, rattaché à une seule intervention et assorti d'une date d'expiration. Le jeton ouvre cette intervention et rien d'autre dans l'espace de travail.

Avant l'affichage de l'intervention, le visiteur doit confirmer l'adresse électronique ou le numéro de téléphone enregistré pour ce client. Une confirmation réussie produit une preuve valable douze heures, signée en HMAC avec une clé dérivée du secret de signature du serveur mais cryptographiquement indépendante de celui-ci, et vérifiée en temps constant.

Les tentatives de confirmation sont limitées par appelant et délibérément pas par jeton : une limitation par jeton permettrait à quiconque d'exclure un client de sa propre intervention en épuisant simplement son quota.

Les téléversements sont restreints à une liste fixe de types de fichiers – JPEG, PNG, WebP, PDF, DOCX, XLSX et texte brut – et à une taille maximale dépendant de la formule souscrite. Les images sont ré-encodées côté serveur avant d'être stockées.

Les fichiers sont servis par des liens signés de courte durée produits par l'API. Le bucket étant lui-même privé, un lien expiré ou modifié ne donne strictement rien.

Le téléversement et le téléchargement ont des limites distinctes par appelant : un lien divulgué ou un client emballé ne peut donc pas consommer sans fin l'espace de stockage et la bande passante.

Les fichiers stockés sont chiffrés au repos par le prestataire de stockage.

L'API applique des limites de débit partitionnées par appelant – par espace de travail et utilisateur figurant dans le jeton lorsqu'il y en a un, par adresse du client sinon. Connexion, connexion Google, réinitialisation de mot de passe et confirmation du portail sont limitées à dix tentatives par minute ; l'inscription à cinq.

Les limiteurs lisent l'adresse réelle de l'appelant dans les en-têtes transmis par le proxy, seul celui-ci étant habilité à les définir. Sans cette configuration, chaque requête semblerait provenir du proxy et un quota unique serait partagé par tous : la protection se muerait en panne.

Le proxy inverse applique en amont de l'application une limite globale supplémentaire, de sorte que le trafic est plafonné avant même d'atteindre l'API.

Les données entrantes sont validées côté serveur avant d'atteindre la logique métier, et les erreurs sont renvoyées sous forme de messages structurés : ni trace d'exécution, ni message de base de données, ni chemin interne n'est transmis au client.

La base de données et Redis résident uniquement sur le réseau interne et n'acceptent de connexions que depuis l'API ; ni l'une ni l'autre n'est exposée à Internet.

Le stockage objet chiffre les fichiers au repos et le bucket n'est pas lisible publiquement.

Des sauvegardes sont réalisées régulièrement et leur restauration est testée. Les données effacées à la fin d'un abonnement disparaissent des sauvegardes à mesure que celles-ci expirent selon leur rotation habituelle ; jusque-là, elles ne sont utilisées à aucune autre fin.

L'application écrit des journaux serveur et tient, pour chaque espace de travail, un historique d'activité indiquant quel utilisateur a modifié quoi et quand. Cet historique est consultable par l'abonné dans l'application.

Les journaux serveur, applicatifs et de sécurité sont conservés 90 jours, sauf lorsqu'une entrée doit l'être plus longtemps pour une investigation de sécurité en cours.

Les journaux servent à exploiter le service et à instruire les incidents. Nous ne journalisons ni mots de passe, ni jetons de session, ni données de carte de paiement.

L'accès aux systèmes et aux données de production est limité aux personnes qui en ont besoin pour l'exploitation ou l'assistance, selon le principe du moindre privilège et sous une obligation de confidentialité qui survit à la fin de leur mission.

Les dépendances tierces sont figées à des versions précises et gérées de façon centralisée, une version se modifiant donc en un seul endroit ; nous appliquons les mises à jour de sécurité de la plateforme et de ses dépendances dès leur disponibilité.

Les évolutions du schéma de base de données sont appliquées sous forme de migrations versionnées au démarrage du service, de sorte que le schéma en production correspond toujours au code qui s'y exécute.

Les prestataires qui traitent des données pour notre compte – hébergement, stockage objet, acheminement des courriels, paiement et facturation – sont nommés, avec leur rôle et leur région, à la section 5 de l'information RGPD et à la section 8 de l'information sur la sous-traitance.

Un nouveau prestataire est annoncé au moins 30 jours avant le début du traitement, afin que l'abonné qui s'y oppose ait le temps d'agir.

Nous tenons un registre interne des violations de données à caractère personnel et suivons une procédure couvrant la détection, l'évaluation, l'endiguement et la notification.

Lorsqu'une violation est susceptible d'engendrer un risque pour les droits et libertés des personnes physiques, nous la notifions à l'autorité de contrôle compétente sans retard injustifié et, si possible, dans les 72 heures suivant la prise de connaissance (art. 33 du RGPD) ; en cas de risque élevé, nous en informons également les personnes concernées en termes clairs (art. 34 du RGPD).

Lorsque nous agissons en qualité de sous-traitant, nous informons l'abonné responsable du traitement sans retard injustifié après avoir eu connaissance de la violation et l'assistons dans ses propres obligations de notification.

Aucun service en ligne ne peut être rendu absolument sûr. Cette page décrit des mesures, non des garanties, et les Conditions générales ne comportent aucun engagement de disponibilité ni de niveau de service.

Nous ne détenons ni certification ISO/CEI 27001 ni rapport SOC 2, et le service n'a pas fait l'objet d'un test d'intrusion indépendant. Si cela venait à changer, c'est ici que ce serait indiqué.

L'authentification à deux facteurs pour les comptes utilisateurs n'est pas encore disponible. La sécurité du compte repose donc sur la robustesse du mot de passe, le verrouillage du compte et les limites décrites plus haut : d'où notre demande d'un mot de passe qui ne serve nulle part ailleurs.

Le service fonctionne dans une seule région, sans bascule interrégionale : si cette région tombe, le service reste indisponible jusqu'à son rétablissement. Nous le disons parce qu'une déclaration de sécurité qui n'énumère que des points forts ne permet de fonder aucune décision.

Si vous découvrez une vulnérabilité, écrivez à info@ravsolutions.eu en indiquant la description, les étapes permettant de la reproduire et l'adresse concernée. Nous accusons réception et vous indiquons comment nous entendons la traiter.

Merci de nous laisser une possibilité raisonnable de corriger le problème avant toute publication. Pendant vos tests, n'accédez pas à des données qui ne sont pas les vôtres, ne les modifiez pas et ne les supprimez pas, ne dégradez pas le service pour autrui et n'employez pas d'ingénierie sociale à l'encontre de nos collaborateurs ou de nos prestataires.

Nous n'exploitons pas de programme de primes aux bogues. Nous n'engagerons aucune action contre une personne qui signale de bonne foi et dans les limites ci-dessus.

Cette déclaration est tenue à jour avec le service. Le numéro de version et la date d'entrée en vigueur figurant en haut de la page indiquent le texte applicable ; les versions antérieures sont disponibles sur demande.

Lorsqu'une mesure décrite ici change, cette page change avec elle. Les questions sur son contenu peuvent être adressées à info@ravsolutions.eu.