Sécurité
Comment nous sécurisons ce que nous construisons et exploitons
Clés de sécurité matérielles, aucune connexion par mot de passe, disques chiffrés et sauvegardes immuables hors site. Quand votre activité repose sur des systèmes exploités par quelqu'un d'autre, vous êtes en droit de savoir exactement comment ils le sont, avec des précisions plutôt que des paroles rassurantes.
L'accès est verrouillé par du matériel
La plupart des compromissions commencent par un identifiant, pas par une faille. Nous avons donc supprimé l'identifiant comme voie d'entrée.
Des clés matérielles, pas des mots de passe
L'accès administrateur exige une clé de sécurité physique FIDO2. Il n'y a pas de mot de passe qu'un attaquant puisse hameçonner, acheter ou deviner pour entrer, car le second facteur est un objet qu'il faut tenir physiquement en main.
Aucune connexion par mot de passe sur les serveurs
L'authentification par mot de passe est désactivée sur les serveurs que nous exploitons, tout comme la connexion root directe. L'accès se fait par clé, attribué par ingénieur, ce qui permet de le révoquer une personne à la fois.
Les interfaces d'administration ne sont pas sur Internet
Les interfaces de gestion ne sont accessibles que via un VPN ou un serveur bastion. Il n'y a aucune page de connexion à découvrir sur Internet ouvert, et donc rien à attaquer par force brute.
Rien n'est partagé ni réutilisé
Chaque système possède ses propres identifiants, conservés dans un gestionnaire de mots de passe. Un identifiant exposé quelque part ne peut pas être rejoué chez un autre client, car il n'existe nulle part ailleurs.
Durci, puis maintenu ainsi
Un serveur ne se sécurise pas une fois pour toutes. Voici ce que nous continuons de faire aussi longtemps que nous l'exploitons pour vous.
Infrastructure européenne, serveurs dédiés
Nous hébergeons sur une infrastructure bare-metal que nous construisons et exploitons nous-mêmes dans l'Union européenne, et Odoo géré fonctionne sur un serveur dédié plutôt que sur un environnement partagé. Vos données ne quittent pas l'UE, et l'incident d'un client n'est pas le problème d'un autre.
Chiffré au repos
Les serveurs fonctionnent avec un chiffrement intégral du disque. Un disque retiré, remplacé ou mis au rebut n'est pas une copie lisible de votre entreprise.
Des mises à jour de sécurité qui n'attendent pas
Les correctifs de sécurité sont appliqués automatiquement sur les hôtes que nous gérons, en plus de la maintenance planifiée prévue dans votre contrat. C'est dans l'intervalle entre la publication d'une vulnérabilité et un système corrigé que surviennent la plupart des compromissions.
Pare-feu et blocage des attaques par force brute
Les pare-feu des hôtes limitent ce qui est joignable, et les échecs d'authentification répétés font bloquer la source automatiquement au lieu de la laisser essayer toute la nuit.
Journalisé de façon centralisée, avec alertes
Les journaux des systèmes que nous exploitons sont centralisés et supervisés, et les alertes parviennent à un ingénieur. La détection ne vaut rien si le signal atterrit dans un fichier que personne n'ouvre.
Votre domaine, difficile à usurper
Nous configurons SPF, DKIM et DMARC sur les domaines que nous gérons. Vos factures et confirmations de commande évitent les dossiers spam, et envoyer du courrier en votre nom devient nettement plus difficile pour tous les autres.
Des sauvegardes conçues pour survivre au pire jour
L'intérêt d'une sauvegarde n'est pas qu'elle existe. C'est qu'elle existe encore après l'incident, et qu'elle se restaure.
Chiffrées
Les données de sauvegarde sont chiffrées au repos : une copie de la sauvegarde n'est pas une copie de votre entreprise.
Hors site et géo-redondantes
Des copies sont conservées dans un second lieu physique. Un incendie, un vol ou une baie hors service emporte le serveur, pas le chemin de restauration.
Immuables
Les sauvegardes sont écrites sur un stockage en ajout seul. Un serveur compromis ne peut pas revenir en arrière pour supprimer ou chiffrer ses propres sauvegardes, ce qui est précisément la première chose que tente un rançongiciel.
Testées par restauration
Nous effectuons de vraies restaurations au lieu de supposer qu'elles fonctionneraient. Une sauvegarde non testée est une hypothèse, pas un plan de reprise.
Qui peut accéder à mes systèmes et à mes données ?
Les ingénieurs qui les exploitent, et personne d'autre. L'accès administrateur exige une clé de sécurité physique : un attaquant en possession d'un mot de passe volé n'a rien pour s'en servir. L'accès est attribué par ingénieur, révoqué individuellement, et prend fin avec la mission. Nous ne revendons ni ne partageons les données de nos clients, et nous ne les utilisons pas pour entraîner quoi que ce soit.
Que se passe-t-il si un serveur tombe en panne ou si des données sont perdues ?
Nous restaurons depuis la sauvegarde : une copie chiffrée, conservée dans un second lieu, écrite sur un stockage en ajout seul afin qu'un serveur compromis ne puisse pas entraîner ses propres sauvegardes dans sa chute. Nous testons ces restaurations au lieu de les supposer. Comme nous exploitons l'infrastructure nous-mêmes, il n'y a pas de file d'attente de support entre vous et la personne qui effectue la restauration, et les attentes en matière de reprise sont fixées par écrit dans votre contrat de service plutôt que promises dans l'abstrait.
Qu'est-ce qui empêche un rançongiciel de tout chiffrer, sauvegardes comprises ?
Le stockage de sauvegarde en ajout seul. Même un attaquant disposant du contrôle total d'un serveur ne peut pas réécrire ni supprimer l'historique des sauvegardes depuis ce serveur, or c'est l'étape dont dépend la plupart des rançongiciels pour faire du paiement la seule option. Combiné à des copies hors site et à des restaurations testées, la réponse honnête à un incident devient la reconstruction à partir d'un état sain plutôt que la négociation.
Mes données sont-elles couvertes par le RGPD ?
Oui. LEAD NODE est une société luxembourgeoise qui héberge dans l'UE : vos données restent sous juridiction européenne et il n'y a aucun transfert vers un pays tiers à justifier. Notre politique de confidentialité précise ce que nous traitons et pourquoi.
L'utilisation de logiciels open source rend-elle mes systèmes moins sûrs ?
Non. La sécurité vient de la façon dont un système est exploité : mis à jour, chiffré, sauvegardé, avec des accès contrôlés et une supervision. Ce que l'open source ajoute, c'est que les vulnérabilités sont divulguées publiquement et que les correctifs n'attendent pas le calendrier de publication d'un éditeur, et que tout ingénieur en qui vous avez confiance peut auditer le code.
Détenez-vous une certification de sécurité ?
Nous ne détenons pas actuellement de certification de sécurité formelle, et nous préférons le dire plutôt que de laisser entendre le contraire. Ce que nous proposons à la place est précis et vérifiable : authentification par clé matérielle, aucune connexion par mot de passe, disques chiffrés, sauvegardes immuables hors site que nous testons réellement, une infrastructure dans l'UE que nous exploitons nous-mêmes, et un contrat de service écrit qui en définit le périmètre. Si votre secteur exige des prestataires certifiés, dites-le nous tôt et nous vous dirons clairement si nous correspondons.
Vous avez trouvé une vulnérabilité ?
Si vous pensez avoir trouvé un problème de sécurité dans l'un de nos systèmes ou dans quelque chose que nous avons construit, dites-le nous avant d'en parler à quiconque. Envoyez-nous les détails : nous accuserons réception, enquêterons et vous tiendrons informé du correctif. Nous ne poursuivons pas les chercheurs qui signalent de bonne foi.
Auditable par conception
Les systèmes que nous exploitons reposent sur des logiciels open source : la façon dont vos données sont traitées peut être inspectée plutôt que prise sur parole.
Des questions sur la façon dont vos systèmes sont exploités ?
Posez-les aux ingénieurs qui les exploiteraient. Vous obtenez une réponse directe, y compris quand la réponse est non.