Sécurité

Protection de vos données

• Chiffré en transit et au repos. TLS 1.2+ partout ; stockage chiffré au niveau de la plateforme.
• Isolation des espaces de travail. Chaque enregistrement porte un identifiant d’espace de travail et chaque requête y est restreinte, y compris les points d’accès qui agissent sur un seul enregistrement – un identifiant deviné depuis un compte ne peut donc pas atteindre les données d’un autre.
• Gestion des mots de passe. Les mots de passe sont hachés avec scrypt aux paramètres recommandés par l’OWASP – N=131072, r=8, p=1 – chacun avec son propre sel aléatoire, et ne sont jamais stockés ni journalisés sous une forme récupérable. La vérification se fait en temps constant, nous exigeons au moins 10 caractères et refusons les mots de passe présents dans les fuites de données connues. scrypt est gourmand en mémoire : chaque tentative exige 128 Mo de mémoire en plus du temps, ce qui rend l’attaque coûteuse avec les cartes graphiques qui rendent le cassage ordinaire de mots de passe bon marché. Les comptes créés sous notre ancien schéma sont mis à niveau automatiquement à la connexion suivante de leur titulaire.
• Votre compte n’existe pas tant que vous n’avez pas prouvé que l’adresse est la vôtre. Créer un compte enregistre une inscription en attente et vous envoie un lien par e‑mail ; le compte, l’espace de travail et la session ne sont créés que lorsque vous cliquez dessus. Cela supprime toute une classe d’attaques au lieu de s’en défendre – personne ne peut ouvrir un compte sur votre adresse e‑mail, y définir un mot de passe et attendre que vous vous inscriviez pour le reprendre.
• Les tentatives de connexion automatisées sont mises à l’épreuve. La connexion, la création de compte, la réinitialisation du mot de passe et le formulaire de contact sont protégés par un défi anti-robots respectueux de la vie privée ainsi que par des limites de fréquence, de sorte que dérouler une liste de mots de passe fuités coûte plus qu’il ne rapporte. Les limites portent sur le compte visé autant que sur l’adresse d’où vient la tentative, car un attaquant disposant d’un lot d’adresses déjoue une limite par adresse en changeant simplement d’adresse – et les échecs répétés sur un même compte sont ralentis progressivement plutôt que bloqués, pendant quelques minutes, jamais de façon permanente. La réinitialisation du mot de passe est comptée séparément de la connexion : quelqu’un qui épuiserait délibérément vos tentatives de connexion ne peut pas fermer en même temps la voie par laquelle vous reviendriez.
• Authentification à deux facteurs. Trois options : les clés d’accès (Face ID, Touch ID, Windows Hello ou une clé matérielle), une application d’authentification, ou un code envoyé par e‑mail. Les clés d’accès sont les plus solides et les seules résistantes à l’hameçonnage, parce que la signature est liée à closerev.com. Les codes par e‑mail sont les plus faibles – qui accède à votre boîte de réception accède au code – et nous le disons là où vous les activez. Des codes de récupération à usage unique couvrent la perte d’un appareil. Dès qu’un facteur est actif, il s’applique à toutes les façons d’entrer dans le compte, y compris « Se connecter avec Google » : un second chemin de connexion n’est pas un moyen de le contourner. Un propriétaire d’espace de travail peut aussi imposer l’authentification à deux facteurs à tous les membres, pour que personne n’atteigne ses données avec un simple mot de passe. Ajouter une méthode exige d’en avoir déjà une, et nous vous envoyons un e‑mail à chaque ajout. Sinon, quelqu’un qui aurait mis la main sur un appareil où votre session était ouverte pourrait ajouter sa propre application d’authentification et conserver l’accès même après un changement de votre mot de passe. L’alerte part vers votre adresse plutôt que vers l’écran de la personne qui l’a fait, et elle contient un lien qui déconnecte tous les appareils, le sien compris. Les méthodes peuvent être ajoutées, mais pas retirées. Sinon, quelqu’un qui aurait mis la main sur un appareil où votre session était ouverte retirerait les méthodes qu’il n’a pas et garderait celle qu’il a – laissant votre compte protégé précisément par ce qu’il a volé. Appareil perdu ? Changez votre mot de passe, ce qui déconnecte immédiatement toutes les autres sessions, puis contactez-nous : nous vérifions votre identité et retirons la méthode, et cette réinitialisation est consignée dans le journal décrit plus bas, dont toute altération se voit.
• Les actions les plus sensibles redemandent une preuve. Fermer votre compte, changer votre mot de passe, tout exporter ou modifier un paramètre de sécurité à l’échelle de l’espace de travail exige de prouver que c’est toujours vous – le code de votre application d’authentification si vous en avez une, votre mot de passe sinon. Un cookie de session dit que quelqu’un s’est connecté ; il ne dit pas que la personne au clavier est toujours vous, et pour ces quelques actions, cette différence est toute la question. Pour la plupart d’entre elles, la preuve vaut 30 minutes, de sorte qu’une série de tâches d’administration ne demande qu’une fois. Activer ou désactiver une exigence à l’échelle de l’espace de travail – authentification à deux facteurs, authentification unique – demande à chaque fois, dans les deux sens : un réglage qui abaisse ce qu’il faut pour atteindre vos données ne doit jamais reposer sur une preuve donnée pour autre chose.
• Authentification unique. Les espaces de travail Enterprise et Agency peuvent imposer à tous de se connecter via leur propre fournisseur d’identité, en OpenID Connect. Un domaine doit être prouvé dans le DNS avant de pouvoir servir : personne ne peut configurer l’authentification unique pour un domaine qu’il ne contrôle pas. Une fois imposée, les mots de passe et la connexion Google cessent de fonctionner pour ce domaine – à une exception délibérée près, le propriétaire de l’espace de travail, afin qu’un fournisseur mal configuré ne puisse pas priver une entreprise de ses propres données. Les sessions ainsi créées durent une semaine plutôt qu’un mois, parce que l’authentification unique ne révoque pas d’elle-même l’accès quand quelqu’un s’en va. Le secret client que vous nous confiez est chiffré avant d’être stocké.
• Sessions. Des jetons opaques et à durée limitée, dans des cookies httpOnly, Secure et SameSite portant le préfixe __Host-, qui empêche tout autre site d’un domaine voisin d’écrire un cookie que nos serveurs liraient comme le vôtre. Ils sont révocables côté serveur, et changer votre mot de passe invalide immédiatement toutes les autres sessions. Les requêtes qui modifient quelque chose doivent provenir de CloseRev lui-même ; un formulaire hébergé sur le site de quelqu’un d’autre et envoyé vers le nôtre est refusé avant d’atteindre vos données. Les jetons de session ne sont stockés que sous forme d’empreinte, si bien qu’une copie de notre base de données ne permettrait de se connecter à la place de personne. Une session prend fin après 30 jours, ou après 7 jours sans utilisation. Et quand votre compte se connecte depuis un navigateur que nous n’avons jamais vu, nous vous envoyons un e‑mail – avec un lien qui déconnecte tous les appareils si ce n’était pas vous.
• Liens par e‑mail. Les liens de vérification et de réinitialisation sont à usage unique et expirent, et nous ne stockons qu’une empreinte SHA-256 de chaque jeton – une fuite de la base de données ne donnerait aucun lien fonctionnel. L’usage unique est imposé par la base de données en une seule opération : deux clics arrivant au même instant ne peuvent pas réussir tous les deux.
• Paiements. Les données de carte vont directement à Stripe et n’atteignent jamais nos serveurs, ce qui nous maintient hors du périmètre du traitement des données de carte.
• Journal d’audit. Les imports, les correspondances, les décisions de revue, les exports et les suppressions sont enregistrés par espace de travail. Séparément, chaque fois que quelqu’un chez CloseRev ouvre une console interne capable de voir votre compte, c’est aussi enregistré – qui, ce qui a été consulté, et quand. Nous conservons ce journal pendant 24 mois, soit la plus longue durée pendant laquelle une formule conserve vos données : la question « quelqu’un a-t-il regardé ceci ? » reste ainsi posable tant que les données elles-mêmes existent. Ces entrées sont chaînées : chacune est scellée par une empreinte qui couvre l’entrée précédente, et la base de données refuse de modifier ou de resceller une entrée scellée. Retirer ou modifier une entrée après coup brise la chaîne à cet endroit, et une vérification nocturne signale où. Une copie du dernier sceau de la chaîne est aussi écrite chaque nuit dans un dépôt tenu sous des identifiants distincts, pour que le journal et sa propre trace ne puissent pas être réécrits ensemble.
• Suppression réelle. Supprimer un import retire ses enregistrements, ses résultats de rapprochement et le fichier d’origine du stockage – pas seulement un indicateur sur une ligne.
• Les exports s’ouvrent sans risque. Un tableur traite une cellule qui commence par =, +, - ou @ comme une formule à exécuter : une valeur glissée par quelqu’un dans un CSV que vous avez importé pourrait donc devenir une commande sur la machine de la personne qui ouvre votre export. Nous neutralisons ces cellules d’une manière qui résiste à l’enregistrement et à la réouverture du fichier, et nous laissons intacts les nombres ordinaires et les montants négatifs.

Minimisation des données

Le rapprochement a besoin d’un numéro de téléphone ou d’une adresse e‑mail, et d’un montant. Vous choisissez les colonnes à associer, et nous préférons que vous en importiez moins. Les données relevant des catégories particulières sont totalement exclues – voir la Politique d’utilisation acceptable.

Ce qui reste à faire

Nous préférons le dire clairement plutôt que de laisser une page de confiance suggérer plus que la vérité :

• Pas de certification SOC 2 ni ISO 27001. Nous sommes un produit jeune et n’avons pas encore passé d’audit.
• Pas de résidence des données au choix du client. La région de stockage est actuellement celle par défaut de la plateforme.

Si l’un de ces points bloque votre processus d’achat, dites-le-nous – cela nous aide à savoir par lequel commencer.

Qui, chez CloseRev, peut voir vos données

• Personne, en fonctionnement normal. Le produit est en libre-service et le support n’a pas besoin de lire vos enregistrements. Il n’y a pas de fonction « se connecter en tant que ce client » ni d’usurpation d’identité, délibérément – dès qu’elle existe, elle devient le chemin le plus court vers les données de tous les clients.
• La console interne ne peut pas du tout lire vos enregistrements importés. Elle affiche les informations de compte et de facturation et le décompte de ce que vous avez traité. Elle n’a aucun accès aux enregistrements de ventes ou de leads eux-mêmes.
• Les lectures sont journalisées, pas seulement les écritures. Tout ce qu’un administrateur consulte est enregistré avec qui, quoi, quand et depuis où. Si vous demandez un jour qui, chez CloseRev, a regardé votre compte, la réponse viendra d’un registre et non de la mémoire de quelqu’un.
• L’accès passe par une authentification unique (SSO) à plusieurs facteurs. La console est placée derrière Cloudflare Access et vérifie en plus l’identité authentifiée contre une liste d’autorisation, de sorte qu’il n’existe aucun mot de passe de notre côté qu’un hameçonnage pourrait y faire entrer.

Nos tests avant livraison

Deux vérifications s’exécutent sur le code à chaque modification, parce que raisonner sur l’isolation n’est pas la même chose que la vérifier :

• Chaque requête qui touche aux données clients est recensée et relue. Une vérification extrait chaque requête et conserve une référence validée, si bien qu’une requête nouvelle ou réécrite qui n’est pas limitée à un espace de travail doit être examinée au lieu de passer inaperçue.
• L’isolation est testée en HTTP réel, pas déduite par raisonnement. Trois espaces de travail distincts sont créés dans une copie fidèle de notre environnement d’exécution, et chaque point d’accès qui accepte un identifiant se voit demander les données d’un autre espace de travail – par le même code que le site exécute, avec la même base de données, le même stockage et les mêmes sessions. Un test qui ne peut pas échouer ne vaut rien : chacun s’exécute donc à côté d’un contrôle prouvant que le propriétaire légitime obtient toujours ses données.
• Les pages sont mesurées dans un navigateur, pas jugées à l’œil – chaque page, en clair et en sombre, aux largeurs d’ordinateur et de téléphone, pour les débordements, les coupures et le contraste.
• Les modifications de la base de données sont appliquées par un outil qui tient un registre, qui refuse d’appliquer quoi que ce soit deux fois, dans le désordre, ou quand l’historique enregistré et le code ne concordent plus.

Une revue de sécurité écrite couvrant l’isolation entre clients, l’authentification, les imports, la facturation, les jetons publics et le cycle de vie des données est une condition de la disponibilité générale. Elle a été menée à plusieurs reprises, la dernière fois en deux passes dédiées avant le lancement, contre la configuration de paiement réelle et dans une copie fidèle de l’environnement d’exécution où nous déployons. Les deux rapports consignent ce qui n’a pas été prouvé aussi clairement que ce qui l’a été.

Sauvegardes et suppression

• Vous fixez la durée de conservation par espace de travail, dans la limite de ce que votre formule conserve. Chaque nuit, une tâche supprime les imports qui la dépassent – les enregistrements, les résultats de rapprochement et les CSV d’origine dans le stockage objet – et consigne ce qu’elle a fait dans le journal d’activité de votre espace de travail.
• Supprimer, c’est supprimer. Retirer un import supprime ses enregistrements et ses fichiers. Fermer votre compte supprime le compte et, si vous en êtes propriétaire, l’espace de travail et tous les fichiers qui lui appartiennent. Les factures ne sont conservées que là où la loi fiscale l’exige.
• Les sauvegardes sont celles de la plateforme, avec, pour la base de données, une restauration à un instant donné couvrant les 30 jours écoulés. Elles servent à nous remettre d’une défaillance de notre côté, pas de seconde copie que vous pourriez interroger.
• Une restauration ne peut pas annuler discrètement une suppression. C’est le seul endroit où « supprimer, c’est supprimer » exigeait plus qu’une simple suppression : revenir en arrière dans la base de données pour corriger une panne sans rapport ferait sinon réapparaître tout ce qui a été supprimé depuis, sans que personne le sache. Chaque suppression est donc consignée – ce qui a été retiré, pour quel espace de travail, quand et pourquoi, sans aucune des données elles-mêmes – et rejouer ces enregistrements est une étape de notre procédure de restauration plutôt qu’une chose à ne pas oublier. Les fichiers importés ne sont pas du tout concernés par ce retour en arrière : une fois supprimé du stockage objet, un fichier a disparu.

En cas de problème

• Violations de données personnelles : nous informons les clients concernés dans les meilleurs délais, et au plus tard 72 heures après en avoir pris connaissance, avec ce que nous savons et ce que nous faisons. Cet engagement est contractuel – il figure dans le DPA, pas seulement ici.
• Incidents touchant l’intégrité des données ou leur accès : nous envoyons un e‑mail aux propriétaires d’espaces de travail plutôt que d’attendre que quelqu’un consulte une page, et un autre à la résolution. L’état de chaque composant est publié sur notre page d’état, qui mesure au lieu d’être mise à jour à la main.

Pourquoi cette page est si précise

Nommer l’algorithme et ses paramètres de coût est un choix délibéré, et c’est ce que demandent les normes de sécurité, pas une liberté que nous nous accordons. Un système doit rester sûr quand tout, sauf les clés, est public – ce principe est plus vieux que le secteur, et c’est pourquoi le NIST publie ses normes cryptographiques ouvertement au lieu de les décrire vaguement. Une conception qui ne tient que tant que personne ne sait comment elle fonctionne n’est pas une conception qui tient.

Ce que vous ne trouverez pas ici, c’est ce qui est réellement secret : pas de versions logicielles ni de niveaux de correctifs, pas de noms d’hôtes internes ni de schéma réseau, pas de matériel de clés, et pas de seuils qu’un attaquant pourrait calibrer – combien de tentatives déclenchent un blocage, ou combien de temps dure une limite. Les chiffres de cette page sont des engagements que nous prenons envers vous, pas des réglages à viser.

Si vous nous évaluez et qu’un point n’est pas assez précis pour répondre à votre question, demandez. Nous préférons l’écrire plutôt que vous laisser deviner.

Signaler une vulnérabilité

E‑mail security@closerev.com, ou consultez la version lisible par machine à l’adresse /.well-known/security.txt. Nous accusons réception sous 2 jours ouvrés, vous disons si nous avons reproduit le problème sous 10 jours ouvrés, et vous tenons au courant jusqu’à sa résolution. Nous demandons 90 jours avant toute divulgation publique, moins si le correctif est livré plus tôt.

N’accédez pas à des données qui ne sont pas les vôtres, ne les modifiez pas et ne les conservez pas ; ne lancez pas de scans automatisés qui dégradent le service pour les clients ; et ne pratiquez pas d’ingénierie sociale envers notre équipe ou nos prestataires. Dans ces limites, nous n’engagerons aucune poursuite contre les chercheurs agissant de bonne foi, et nous vous créditerons si vous le souhaitez.

Voir aussi

Politique de confidentialité · Accord de traitement des données · Sous-traitants