Sécurité

Cette traduction est fournie à titre de commodité. La version anglaise fait foi.

Pour gérer vos domaines, votre DNS, vos serveurs et vos certificats en un seul endroit, InfraNest détient quelque chose de véritablement sensible : les identifiants d'API de vos bureaux d'enregistrement, de vos hébergeurs DNS et de vos fournisseurs cloud. Nous estimons que vous devez savoir exactement ce qu'il advient de ces identifiants avant de nous les confier — et non après.

Cette page est volontairement précise. Là où nous avons quelque chose de concret, nous décrivons son fonctionnement. Là où ce n'est pas le cas, nous le disons.

En résumé

• Les identifiants de chaque organisation sont chiffrés sous sa propre clé. La compromission de la clé d'un client n'ouvre celle d'aucun autre.
• Supprimez votre compte et, une fois la suppression devenue définitive à la fin de la période de corbeille, nous détruisons cette clé — ce qui rend vos secrets illisibles partout, y compris dans les sauvegardes.
• Nous ne stockons jamais une clé privée que nous n'avons pas générée.
• Connectez-vous avec une clé d'accès (passkey) — et sa suppression exige toujours que vous prouviez que c'est bien vous.
• Chaque modification est enregistrée dans un journal d'audit que vous pouvez consulter vous-même.
• Vos données résident en Allemagne, dans des centres de données certifiés ISO 27001, avec des sauvegardes délocalisées au sein de l'UE.
• Nous ne sommes pas certifiés ISO 27001 ni SOC 2. Voici ce que nous faisons à la place.

Vos identifiants de fournisseurs

Lorsque vous connectez un bureau d'enregistrement, un hébergeur DNS ou un compte cloud, les identifiants sont chiffrés dès leur arrivée et ne sont plus jamais affichés.

Chaque organisation reçoit sa propre clé de chiffrement. Vos secrets sont chiffrés avec une clé qui appartient à votre seule organisation, elle-même protégée par notre clé maître. C'est le point qui mérite d'être compris : cela signifie que le rayon d'impact d'une clé compromise se limite à un seul client, et non à tous. La plupart des plateformes chiffrent tout sous une clé unique et le décrivent de la même manière.

La suppression de votre compte détruit cette clé — lorsque la suppression devient définitive. Un compte supprimé se trouve d'abord dans une corbeille pendant une période de grâce, de sorte qu'une suppression accidentelle peut être annulée ; une fois cette fenêtre fermée et la suppression définitive, la clé est détruite. Après cela, vos secrets ne peuvent plus jamais être lus — ni par nous, ni à partir d'une sauvegarde ou d'une réplique réalisée pendant l'existence de votre compte. La suppression atteint réellement les copies que personne ne peut revenir modifier.

Les secrets ne sont affichés qu'une seule fois. Les jetons d'API, les secrets de signature de webhooks et les codes de récupération à deux facteurs sont affichés lors de leur création et ne sont plus jamais restitués — ni dans l'interface, ni via l'API.

Les secrets sont retirés de nos journaux de diagnostic. Lorsque InfraNest appelle un fournisseur pour votre compte, nous enregistrons la requête afin qu'un échec puisse être tracé. Tout ce qui ressemble à un secret est remplacé avant l'écriture de l'enregistrement — y compris les scripts de démarrage de serveur qui contiennent souvent des mots de passe de base de données et des identifiants de registre. Le masquage se fait de manière centralisée, de sorte qu'il ne peut pas être oublié à un endroit.

Vos comptes de fournisseurs restent les vôtres. Les bureaux d'enregistrement, hébergeurs DNS, fournisseurs cloud et canaux de discussion que vous connectez avec vos propres identifiants demeurent régis par votre accord avec eux. Vous pouvez révoquer notre accès à tout moment, de leur côté comme du nôtre.

Clés privées TLS

Notre règle, dans son intégralité :

Nous ne stockons jamais une clé privée que nous n'avons pas générée. Nous stockons les clés que nous avons émises, chiffrées, parce que personne d'autre ne les possède.

Votre inventaire de certificats ne contient que des métadonnées — empreinte, sujet, émetteur, noms, validité. Il n'y a pas de colonne pour la clé privée. Lorsqu'un certificat a été émis et est renouvelé par un fournisseur, nous récupérons auprès de lui l'ensemble déployable au moment où vous le demandez, nous vous le remettons, et nous n'en conservons rien.

Ne pas le stocker est à la fois plus sûr et plus correct : ces certificats sont renouvelés tous les 60 à 90 jours, de sorte qu'une clé stockée serait périmée dès le trimestre — et une clé privée périmée est pire qu'aucune, car elle s'installe proprement puis casse le TLS pour une raison que personne ne rattache à nous.

Les certificats que nous émettons constituent l'autre moitié de la règle. Nous générons la clé, l'autorité de certification ne la conserve pas, et sans la nôtre le certificat ne peut être ni livré ni renouvelé — nous la stockons donc, chiffrée sous la clé de votre organisation comme tous les autres secrets ci-dessus.

Votre compte

• Clés d'accès (passkeys). Connectez-vous avec Face ID, Touch ID ou une clé matérielle — aucun mot de passe à hameçonner. Vous pouvez utiliser une clé d'accès seule, ou comme second facteur après un mot de passe.
• Confirmation renforcée (step-up). La suppression d'une clé d'accès vous ré-authentifie toujours au préalable — vous prouvez que c'est bien vous. Votre organisation peut étendre cette même confirmation renforcée aux actions destructrices et sensibles depuis ses paramètres de Sécurité (elle est désactivée jusqu'à ce qu'un administrateur l'active).
• Authentification à deux facteurs (TOTP) avec n'importe quelle application d'authentification. Vos codes de récupération sont hachés, de sorte que même nous ne pouvons pas les lire, et ne vous sont montrés qu'une seule fois.
• Abandonner entièrement votre mot de passe n'est autorisé qu'une fois que vous disposez d'une solution de repli résistante à l'hameçonnage — une seconde clé d'accès, ou une 2FA confirmée avec ses codes de récupération. Nous ne vous laisserons pas conserver un mot de passe comme voie de retour faible, car cela rouvrirait la faille que les clés d'accès existent précisément pour refermer.
• Verrouillage du compte après plusieurs tentatives de connexion échouées, enregistré comme un événement de sécurité que vous pouvez consulter.
• Protection contre les bots lors de l'inscription et de la réinitialisation du mot de passe, et de manière adaptative lors de la connexion après des échecs répétés.
• Des sessions que vous pouvez voir et révoquer. Chaque session active indique son IP, son appareil et sa localisation approximative, de sorte qu'une session inhabituelle saute aux yeux. Les sessions inactives expirent d'elles-mêmes, et une nouvelle connexion depuis le même navigateur remplace l'ancienne session au lieu d'en empiler une autre.
• Des jetons d'API à portée limitée. Créez un jeton qui ne fait que lire, ou qui n'atteint qu'une partie d'InfraNest. Le sélecteur indique ce que chaque portée couvre réellement, car les portées sont délibérément plus larges que leurs libellés ne le laissent entendre. Deux choses qu'une portée ne restreint pas aujourd'hui : la recherche globale, et la création d'un autre jeton — considérez donc tout jeton que vous émettez comme capable d'en générer un à accès complet, et révoquez ce que vous cessez d'utiliser.

Qui peut voir vos données

Chaque requête est limitée à votre organisation, et les deux couches de notre système de permissions refusent par défaut : si une permission n'est pas explicitement accordée, la réponse est non. Les organisations peuvent définir leurs propres rôles à partir du même ensemble de permissions.

Notre accès de support est en lecture seule. Lorsqu'un membre de notre équipe doit consulter un compte pour aider à résoudre un problème, les écritures sont bloquées sur l'ensemble de l'API pendant toute la durée. Le support peut regarder. Le support ne peut pas toucher.

Chaque modification est enregistrée

Chaque action qui crée, modifie ou supprime quelque chose est écrite dans un journal d'audit que vous pouvez consulter vous-même, dans les paramètres de votre organisation — qui l'a fait, ce qui a changé, et quand. Les actions effectuées automatiquement pour votre compte sont également enregistrées, marquées comme des actions système.

Ce n'est pas une promesse que nous tenons par mémoire. Notre chaîne de compilation parcourt chaque point de terminaison qui modifie des données et fait échouer la publication si l'un d'eux n'enregistre pas dans le journal d'audit. La couverture est vérifiée par la machine, à chaque changement que nous livrons.

La durée de conservation dépend de votre offre — de 7 jours sur l'offre d'entrée jusqu'à 10 ans au sommet. Le chiffre pour chaque offre figure sur notre page tarifaire, qui est celle qui reste à jour. Vous pouvez exporter le journal à tout moment ; ainsi, si vous devez conserver un historique plus long que ce que votre offre retient, récupérez-le avant qu'il n'expire.

Où résident vos données

Votre compte, vos données et vos identifiants sont hébergés en Allemagne, à Nuremberg, sur une infrastructure Hetzner certifiée ISO/IEC 27001:2022 et BSI C5 Type 2. Notre base de données fonctionne sur son propre serveur, distinct de l'application.

Il ne s'agit pas seulement de l'endroit où les machines se trouvent. Nous détenons un accord de traitement des données au titre de l'article 28 signé avec Hetzner qui confine le traitement à l'UE et à l'EEE, et parce que nous hébergeons en Allemagne, aucun des sous-traitants qu'ils exploitent hors de l'UE ne touche vos données. Leurs centres de données séparent les données d'un client — et les sauvegardes d'un client — de celles d'un autre au niveau de la couche de virtualisation.

Ce que Hetzner ne fait pas, c'est chiffrer vos données à notre place. Leur accord le dit clairement : le chiffrement au repos, tant des données que des sauvegardes, incombe au client. Ce client, c'est nous, et le reste de cette page décrit comment nous le faisons. Il est bon de savoir qu'un certificat d'hébergement ne couvre jamais cette partie — ni le nôtre ni celui de quiconque.

Les sondes de supervision sont différentes, et c'est vous qui les choisissez. Les vérifications s'exécutent depuis des serveurs sondes situés dans les régions que vous sélectionnez — actuellement l'Europe, l'Asie et l'Amérique du Nord, d'autres s'ajoutant au fil du temps. Une sonde ne détient aucun identifiant de votre compte ni aucune clé de quoi que ce soit que vous avez connecté : elle exécute une image figée et versionnée, s'authentifie en sortie auprès de nous avec son propre jeton à portée limitée, et rapporte un résultat.

Ce qu'une sonde reçoit, en revanche, c'est la définition des vérifications qu'elle exécute — l'adresse à contrôler et les paramètres que vous avez configurés pour elle, y compris les en-têtes de requête personnalisés. Si vous définissez un en-tête d'autorisation sur une vérification, il est envoyé aux sondes des régions que vous avez choisies. Si vous préférez que cela ne quitte jamais l'UE, ne sélectionnez que des régions de l'UE.

Les sauvegardes quittent l'Allemagne, mais pas l'UE. La base de données est sauvegardée quotidiennement sur Backblaze B2 dans leur région UE (Amsterdam), et nous prenons un instantané de la base de données de production avant chaque migration. Vos identifiants de fournisseurs restent chiffrés sous la clé de votre organisation à l'intérieur de ces sauvegardes — une sauvegarde n'est pas un moyen de contourner quoi que ce soit de décrit ci-dessus.

Infrastructure et transport

• Tout transite par TLS. Le HTTPS est imposé avec HSTS, de sorte que les navigateurs ne peuvent pas revenir en arrière.
• Des en-têtes de navigateur renforcés sur l'application comme sur l'API — le détournement de clic, le reniflage MIME et les fuites de référent sont tous fermés, et l'accès à la caméra, au microphone, à la géolocalisation et à l'USB est purement et simplement désactivé.
• Des hôtes renforcés — mises à jour de sécurité automatiques, SSH restreint, pare-feu et dépendances épinglées.
• Des publications encadrées. La production n'est mise à jour qu'au travers d'une pull request revue et testée en CI. Nous prenons un instantané de la base de données avant chaque migration et vérifions la présence de notre clé de chiffrement avant tout déploiement.
• Nous empêchons nos propres serveurs d'être utilisés contre vous. Toute adresse que vous nous fournissez et que nous récupérons ensuite — une cible de supervision, un webhook — est contrôlée pour s'assurer qu'elle ne pointe pas vers des adresses internes ou des adresses de métadonnées cloud.

Nos fournisseurs, et ce pour quoi ils sont certifiés

Nous gardons cette liste courte à dessein. Il s'agit de certifications détenues par nos fournisseurs, couvrant leur propre infrastructure et leurs propres services — et non de certifications d'InfraNest.

L'hébergement s'effectue dans le cadre d'un accord de traitement des données au titre de l'article 28 signé avec Hetzner, le traitement étant contractuellement confiné à l'UE/EEE. Chaque fournisseur ci-dessus est lié par des clauses de protection des données conformes à l'article 28, et nous restons responsables envers vous de ce qu'ils font.

L'analyse d'audience est assurée par Umami, auto-hébergé sur notre propre infrastructure et sans cookie — aucune société d'analyse tierce ne reçoit vos données.

Deux autres ne reçoivent des données que si vous les activez : Telegram, si vous configurez un canal d'alerte Telegram (nous exploitons le bot, et Telegram est hors de l'UE), et Gravatar, si vous activez les images d'avatar — que nous récupérons côté serveur à partir d'un hachage de votre adresse e-mail, de sorte que Gravatar ne voit jamais votre navigateur ni votre IP.

La liste complète, y compris ce que chacun traite, figure dans notre accord de traitement des données et notre politique de confidentialité. Nous donnons un préavis de 30 jours avant d'ajouter ou de remplacer un sous-traitant.

Ce que nous ne prétendons pas

InfraNest n'est pas certifié ISO 27001 ni SOC 2. Nous sommes une petite entreprise indépendante, et ces audits représentent une entreprise considérable que nous n'avons pas encore menée à terme. Nous préférons vous le dire clairement plutôt que d'apposer sur cette page un badge de certification qui appartient à notre bailleur.

Ce que nous faisons à la place figure dans le reste de cette page : un chiffrement conçu pour qu'une seule brèche ne concerne qu'un seul client, une suppression qui atteint les sauvegardes, des clés privées que nous refusons de détenir, et une couverture d'audit qu'une machine vérifie à chaque publication. Nous vous encourageons à mettre cela en balance avec un certificat — et à nous poser des questions difficiles dans un cas comme dans l'autre.

Si votre processus d'achat nécessite de remplir un questionnaire de sécurité, envoyez-le-nous. Nous y répondons.

Signaler une vulnérabilité

Si vous avez trouvé un problème de sécurité, veuillez écrire à [email protected] plutôt que d'ouvrir un ticket public. Cette adresse est également publiée sur /.well-known/security.txt.

Nous nous engageons à :

• un accusé de réception sous 3 jours ouvrés
• une évaluation de tri et une cotation de gravité sous 7 jours ouvrés
• des mises à jour régulières pendant que nous corrigeons, et un crédit dans les notes de version si vous le souhaitez

Veuillez inclure les étapes pour reproduire le problème, et éviter d'accéder aux données d'autres clients pendant votre investigation.

À lire également

Politique de confidentialité · Accord de traitement des données · Conditions · Mentions légales · État du service

Toute question sur ce qui précède : [email protected]

Dernière révision : 30 août 2026.