Un serveur en France, une base cloisonnée par application, des sauvegardes chiffrées déposées chez un second hébergeur français, et des audits de sécurité réguliers. Voici ce qui protège ce que vous me confiez.
L'hébergement, l'accès aux données, et ce qui se passe en cas d'incident
Une collectivité qui me confie l'état civil de ses administrés, un cabinet qui héberge des dossiers clients, une association qui gère ses adhérents : tous engagent leur responsabilité en choisissant un prestataire. La question de l'hébergement et des accès se pose avant la signature, et elle mérite mieux qu'un logo de cadenas.
Cette page décrit ce qui est réellement en place. Je n'y prétends pas que le risque est nul, cela n'existe pas. J'y explique ce qui est fait, et ce qui se passe si quelque chose casse.
En France, sur une infrastructure que j'administre directement
Vos applications tournent sur un serveur situé à Strasbourg, chez un hébergeur français. Aucune donnée n'est répliquée hors de France. Aucun service américain n'intervient dans la chaîne d'hébergement.
Chaque application dispose de sa propre base de données et de son propre compte d'accès. Une application ne peut pas lire les données d'une autre. Le cloisonnement est structurel, il ne repose pas sur une règle que j'aurais pu oublier d'écrire.
Les applications ne sont joignables que depuis le serveur lui-même. Rien n'écoute directement sur internet en dehors du site web. Tout le reste est fermé par défaut et n'accepte que ce qui est explicitement autorisé.
J'accède au serveur exclusivement par clé cryptographique. Les mots de passe d'administration n'existent pas sur cette machine, il n'y a donc rien à deviner.
Les connexions répétées, les recherches automatisées de failles et les sondages de robots sont détectés puis bannis automatiquement, sans que j'aie à intervenir.
Les correctifs de sécurité du système s'appliquent automatiquement, sans attendre une intervention manuelle qui pourrait tarder.
Ce qui est prévu, concrètement
Toutes les bases de données sont sauvegardées chaque nuit sur le serveur et conservées sur une période glissante.
Ces sauvegardes sont chiffrées puis envoyées chaque nuit vers un espace de stockage objet hébergé par Scaleway, en France. Deux hébergeurs distincts : un incident majeur chez l'un ne fait pas disparaître les données conservées chez l'autre.
Le serveur peut déposer ses sauvegardes, mais il ne peut ni les relire ni les effacer. Si le serveur était compromis, l'attaquant ne pourrait donc pas détruire les copies de secours. C'est exactement ce que cherchent à faire les rançongiciels.
Le chiffrement a lieu sur le serveur, avant l'envoi. L'hébergeur de destination ne détient que des fichiers illisibles, et la clé de déchiffrement n'est pas stockée avec eux.
Huit audits successifs, et un registre de ce qui a déjà été examiné
La sécurité d'un serveur demande un entretien régulier. Je mène donc des audits périodiques de l'infrastructure. Chacun donne lieu à un rapport, à un plan d'action et à un journal d'exécution des corrections.
Ces audits tiennent un registre des angles déjà examinés. Chaque nouvelle passe attaque le serveur sous un angle encore non couvert, au lieu de repasser indéfiniment sur les mêmes vérifications.
Je ne publie pas ces rapports. Décrire publiquement la configuration d'un serveur revient à rédiger la feuille de route de celui qui voudrait l'attaquer. Je les transmets en revanche à un client ou à un acheteur qui en fait la demande dans le cadre d'un projet.
Les mécanismes que je mets en place
Chaque type de donnée reçoit une durée de conservation fixée avec vous, et une purge automatique qui l'applique. Une donnée qui n'a plus de raison d'être n'attend pas qu'on pense à l'effacer.
Quand un utilisateur demande la suppression de son compte, les lignes en base disparaissent, mais aussi les documents qu'il a déposés et les fichiers générés à partir de ses données.
Sur les applications qui reçoivent des documents personnels, chaque pièce déposée est chiffrée individuellement. Les données de localisation contenues dans les photos sont retirées dès la réception.
Je ne collecte que ce dont l'application a besoin pour fonctionner. Un champ inutile reste une donnée à protéger, à conserver et à effacer, sans contrepartie.
Vos données ne sont ni vendues, ni louées, ni transmises à un partenaire commercial. Je vends des logiciels, pas de l'audience.
Vous êtes responsable du traitement, j'interviens comme sous-traitant. Cela implique un contrat qui précise ce que je fais de vos données, et mon obligation de vous alerter en cas d'incident.
Ce que j'applique sur ce site, et ce que j'installe chez mes clients
Vous n'avez pas vu de bandeau de cookies en arrivant sur ce site, et c'est volontaire.
Pas de Google Analytics, pas de régie publicitaire, pas de bouton de réseau social qui vous suit d'un site à l'autre. Aucun acteur tiers ne sait que vous êtes ici.
Je mesure la fréquentation à partir d'une empreinte technique. Votre adresse elle-même n'est jamais enregistrée dans mes bases.
Les mesures sont conservées quelques semaines puis effacées automatiquement. Elles me servent à savoir quelles pages sont utiles et lesquelles ne le sont pas.
Pour les applications que je livre, je vais plus loin. La mesure d'audience que j'installe repose sur une empreinte à sel tournant non conservé : l'identifiant qui distingue deux visiteurs change périodiquement et n'est stocké nulle part. Relier les visites d'une même personne dans la durée devient impossible, y compris pour moi.
Ce dispositif ne stocke ni adresse IP ni identifiant de navigateur, respecte le signal « ne pas me pister » du navigateur, et écarte les robots avant comptage. Mes clients mesurent ainsi leur fréquentation sans imposer un bandeau de consentement à leurs visiteurs.
Utile à savoir avant de me confier un projet
Marché public, données de santé, doctrine interne de sécurité : certains cadres imposent des contraintes précises. Dites-moi lesquelles, je vous dirai ce que je sais faire et ce que je ne sais pas faire.
M'écrire