Qui peut accéder à vos données clients ?

Dans beaucoup de logiciels, c’est à l’endroit où l’écran est construit qu’on décide qui a le droit de voir quoi. Cela fonctionne tant que chaque écran le fait correctement. Qu’une seule page oublie le contrôle, et les données d’une autre entreprise s’y affichent — et vous ne le remarquez que lorsque quelqu’un le signale.

Chez Nermio, cette frontière est posée une couche plus bas : dans la base de données. Chaque table contenant des données clients a des règles qui déterminent quelles lignes un compte connecté peut voir, et la base applique ces règles à CHAQUE requête, quel que soit l’écran ou la route qui la pose. Un bug dans l’application peut donc produire une erreur, mais pas les données d’une autre organisation. Les visiteurs sans compte n’ont aucun droit de lecture sur ces tables.

Au sein de votre propre organisation, c’est vous qui décidez ensuite. Il y a quatre rôles — propriétaire, manager, utilisateur et lecture seule — et qui est en « lecture seule » ne peut rien modifier par un détour non plus : c’est la même couche qui l’impose.

Un journal que personne ne peut retoucher

Nermio tient deux journaux. L’un consigne ce qui est fait dans votre environnement et par qui. L’autre consigne ce qui arrive aux comptes : tentatives de connexion, mise en place d’un second facteur, changement de mot de passe. Les deux sont séparés, pour qu’en cas d’incident vous puissiez lire l’un sans avoir à le repêcher dans l’autre.

Plus important est ce qu’on ne peut PAS en faire. Pour le journal d’activité, c’est une propriété de la table : modifier ou effacer une ligne, la base de données le refuse, même quand la demande vient de notre rôle d’administration le plus élevé. Pour le journal des comptes, cela repose aujourd’hui sur des droits et non sur la table elle-même — cette différence a sa place ici et pas dans une note de bas de page. Les deux disparaissent à l’échéance de leur durée de conservation : vingt-quatre mois pour le journal d’activité, six pour celui des comptes. Un journal que l’administrateur peut nettoyer entre-temps n’est pas un journal.

Nous ne regardons pas en silence

Il arrive que quelqu’un chez nous doive regarder dans votre environnement pour résoudre un problème. C’est possible, mais pas à votre insu et pas sans limite. Un collaborateur ouvre pour cela une session de support et doit indiquer un motif. Cette session a une fin — quinze, trente ou soixante minutes, jamais une fin ouverte — et se ferme automatiquement quand le temps est écoulé. Un collaborateur ne peut pas avoir deux sessions ouvertes en même temps, donc « j’étais resté connecté quelque part » n’existe pas.

Au démarrage, on choisit si la session peut seulement lire ou aussi modifier ; la consultation est la valeur par défaut. Supprimer pendant une session de support est toujours impossible, il n’existe aucune route pour cela, même avec le bon rôle. Et ce n’est pas une connexion sous votre identité : dans le journal, ce n’est pas votre nom qui apparaît mais celui du collaborateur, avec la session.

Et vous pouvez le relire. Le propriétaire d’une organisation a un droit de lecture sur son propre historique de support : quelles sessions ont eu lieu, avec quel motif, quand, et ce qui s’est passé dans son environnement pendant cette session. Ce n’est pas un supplément, c’est ce qui rend l’accès du support explicable.

La connexion

Nous ne conservons pas votre mot de passe. Il part chiffré vers Supabase Auth et n’est ensuite plus lisible, pas par nous, pas pendant une session de support. Un mot de passe oublié ne peut donc être que réinitialisé, pas retrouvé. Quelqu’un qui se fait passer pour vous et appelle pour qu’on lui lise son mot de passe ne l’obtient pas, parce que c’est impossible.

La connexion et le mot de passe oublié ont une limite : trop de tentatives en quelques minutes sont refusées. Ce compteur est dans la base de données et pas dans la mémoire d’un seul serveur, car avec plusieurs serveurs côte à côte un attaquant ne verrait en pratique presque aucune limite.

Après votre mot de passe vient toujours un code d’une application d’authentification, pour chaque compte : le vôtre, celui de vos collègues et celui de notre propre personnel. Le contrôle est par session, pas par compte. Non pas « ce compte a un jour activé la double authentification », mais « cette session est passée par là » — sinon un mot de passe volé suffirait quand même.

Vous pouvez enregistrer deux applications d’authentification : votre téléphone et une réserve, par exemple un gestionnaire de mots de passe sur votre ordinateur. C’est prévu pour le jour où un téléphone tombe à l’eau. Avec une réserve, vous vous connectez avec l’autre appareil et vous configurez vous-même un nouveau téléphone. Sans réserve, c’est impossible, et il faut alors nous le demander : nous seuls pouvons rouvrir un second facteur, pas l’administrateur de votre propre organisation. C’est un choix délibéré, car sinon la double authentification de toute une équipe ne vaut que ce que vaut la personne la moins attentive. Plus de deux est impossible, pour la raison inverse : chaque appareil supplémentaire est un endroit de plus d’où votre compte peut être ouvert.

Où se trouvent vos données

Sur une base de données Postgres chez Supabase, sur des serveurs à Francfort (eu-central-1), donc dans l’UE. Le trafic entre votre navigateur et Nermio passe par une connexion chiffrée.

Vos données restent les vôtres, et c’est vous qui les sortez : dans les Réglages, il y a un bouton d’export par type qui vous donne vos entreprises, contacts, affaires, tâches, votre historique et vos notes en CSV. C’est possible chaque jour où votre compte tourne, pas seulement au moment de partir, et tout le monde dans votre équipe peut le faire, même en lecture seule. Cela continue de fonctionner trente jours après que vous avez arrêté ; modifier n’est alors plus possible.

Ce que nous ne prétendons pas

Nermio est un produit jeune, et sur une page consacrée à la sécurité c’est une information pertinente. Nous n’avons pas d’attestation ISO 27001 ni SOC 2, pas de qualification SecNumCloud de l’ANSSI, et pas de rapport de test d’intrusion externe. Un logiciel qui affiche ce genre de logos sans les détenir, c’est le type d’affirmation qu’on ne vérifie qu’une fois que quelque chose a mal tourné.

Ce qui est écrit ici n’est donc pas un label mais une description de ce qui se trouve dans le code et dans la base de données. Si vous trouvez une faille, nous sommes preneurs via info@nermio.com avec « sécurité » en objet ; signaler est plus utile que se taire, et nous prenons un signalement au sérieux.