Chiffrement et clé de récupération

Comment ça marche

• L’agent utilise restic (version 0.18.1, open source) pour tout chiffrer sur votre serveur en AES-256 avant l’envoi. Seuls des blocs verrouillés arrivent au stockage.
• À l’installation, une clé de dépôt aléatoire est générée sur votre serveur et écrite dans /etc/neverwiped/repo.key (lisible par root seulement). Elle ne nous est jamais envoyée.
• Une seconde clé, la clé de récupération, est ajoutée au dépôt et vous est affichée une fois. Elle ouvre le même dépôt : vous pouvez encore lire vos sauvegardes si le serveur et son repo.key ont disparu.
• Tout circule en TLS (HTTPS). Les disques du stockage sont aussi chiffrés au repos ; cela protège contre un disque perdu, pas contre quelqu’un sur un serveur allumé.
• Les restaurations sont déchiffrées sur votre serveur, jamais chez nous.

Où se trouve chaque clé

Plusieurs serveurs

Chaque serveur installé reçoit ses propres clés. Rien n’est partagé entre deux serveurs de votre compte :

Une fuite sur un serveur (accès root, config.json copié) expose donc les sauvegardes de ce serveur, pas celles des autres. Désinstaller ou récupérer un serveur révoque ses clés seulement.

• Une seule clé d’API de compte pour plusieurs installations, c’est possible. Elle sert seulement à enregistrer des serveurs (et à récupérer un serveur perdu). Chaque serveur a ensuite sa propre clé d’agent : vous pouvez révoquer la clé de compte après. Votre formule fixe combien de serveurs comptent en même temps ; une installation au-delà est refusée, même si plusieurs démarrent au même moment.
• Étiquetez chaque clé de récupération. L’encadré de l’installation affiche le nom du serveur, son identifiant et un code de contrôle comme 4342-B317. Notez les trois à côté de la clé. Le même code figure sur la page du serveur dans votre espace client, rubrique « Clés de ce serveur », et dans neverwiped status. Le code n’ouvre rien ; il indique seulement à quel serveur appartient chaque clé.
• **neverwiped recover vérifie la clé avant de révoquer quoi que ce soit.** Si la clé saisie est celle d’un autre serveur, il dit lequel et s’arrête : le serveur choisi continue de fonctionner. Les serveurs installés avant le code de contrôle le reçoivent à leur prochaine sauvegarde ; d’ici là, la clé n’est vérifiée qu’après la ré-émission des accès.
• **Ne clonez jamais un serveur avec /etc/neverwiped dedans**, et ne copiez jamais ce dossier sur une autre machine. Deux machines partageraient les clés d’un serveur. L’agent le remarque (l’identifiant de machine de /etc/machine-id diffère) et refuse d’y sauvegarder. Sur la copie, lancez neverwiped uninstall --yes : il retire les clés copiées de cette machine seulement et ne prévient pas la plateforme, donc l’original garde ses clés. Réinstallez ensuite : la copie devient un nouveau serveur avec ses propres clés. Si c’est le même serveur et que seul son identifiant de machine a changé (système réinstallé avec /etc/neverwiped remis en place), lancez neverwiped install --same-server.

Bien garder la clé de récupération

• Rangez-la dans un gestionnaire de mots de passe le jour de l’installation, avec le nom du serveur dans l’entrée.
• Pas sur le serveur lui-même : s’il est perdu, la clé part avec lui.
• Ni dans un dépôt Git, ni dans un fichier de projet, ni dans une conversation avec un agent IA, ni dans un ticket.
• Une copie papier dans un endroit sûr convient.
• La clé n’est affichée qu’à la création du dépôt. Réinstaller sur le même serveur ne la réaffiche pas.

Clé de récupération perdue ?

Ce qui reste possible dépend d’une seule chose : **le serveur tourne-t-il encore, avec /etc/neverwiped/repo.key dessus ?**

**Ce que fait recovery-key new.** Elle se sert du repo.key de ce serveur pour ajouter une deuxième clé de récupération au dépôt, vérifie que la nouvelle clé ouvre les sauvegardes, puis l’affiche une fois, avec le nom du serveur et un nouveau code de contrôle. Seul le code de contrôle nous est envoyé. Votre espace client affiche alors le nouveau code, et le titulaire du compte reçoit un e-mail sur ce changement. L’ancien code reste enregistré lui aussi : neverwiped recover accepte encore l’ancienne clé si vous la retrouvez.

Ce qu’elle ne fait pas. Elle ne supprime pas l’ancienne clé. Le stockage n’accepte que des ajouts depuis votre serveur, et nous n’avons aucune clé : l’ancienne clé ouvre donc toujours ces sauvegardes. Pas de souci si vous l’avez seulement perdue (un tiroir, une entrée effacée du gestionnaire de mots de passe). Si quelqu’un d’autre a pu la voir, c’est une fuite, pas une perte : voir Si vous pensez qu’une clé a fuité.

Après une nouvelle clé :

1. Rangez-la dans votre gestionnaire de mots de passe, avec le nom du serveur et le nouveau code de contrôle.
2. Testez la copie notée : sudo neverwiped recovery-key check.
3. Ne jetez les copies de l’ancienne clé qu’après.

Ce que le support peut faire : vous aider à retrouver à quel serveur appartient un code de contrôle, et enregistrer le code d’une nouvelle clé si la plateforme l’a refusé (après dix remplacements). Le support ne peut ni ouvrir, ni déchiffrer, ni restaurer vos sauvegardes, et ne peut pas créer de clé de récupération à votre place. Des sauvegardes que vous ne pouvez plus lire prennent quand même de la place : supprimez ce serveur dans votre espace client (page du serveur) pour les effacer.

Ce que nous ne pouvons pas faire

Nous ne pouvons ni lire vos sauvegardes, ni les déchiffrer, ni les restaurer à votre place. Nous n’avons ni la clé du dépôt ni la clé de récupération, et aucune « clé maîtresse » n’existe.

Ce que la console du support montre de votre compte : votre adresse, la facturation, les serveurs (nom, version de l’agent, volume) et les exécutions de sauvegarde (dates, tailles, nombre de fichiers, résultat). Elle ne montre pas votre plan de sauvegarde, et les chemins de fichiers dans les messages d’erreur sont masqués. Elle ne peut pas créer d’identifiant de stockage. Chaque intervention du support demande un motif écrit et apparaît dans votre journal d’audit avec ce motif.

Donc, si vous perdez à la fois le serveur et la clé de récupération, vos sauvegardes sont illisibles, pour vous comme pour nous. Tant que le serveur tourne, rien ne change : l’agent continue d’utiliser repo.key. C’est le prix d’un chiffrement que nous ne pouvons pas ouvrir, et nous préférons le dire clairement.

Accès de l’équipe

Vous pouvez donner accès à votre compte à des collègues depuis votre espace client › Équipe. Chacun se connecte avec sa propre adresse et son propre mot de passe ; vous choisissez un rôle :

Aucun rôle ne donne accès au contenu de vos sauvegardes : la plateforme n’a jamais la clé de récupération. Un lien d’invitation est envoyé à une seule adresse, ne sert qu’une fois, pendant 7 jours, et seulement pour un compte à cette adresse confirmée. Le titulaire reçoit un e-mail à chaque arrivée.

Retirer quelqu’un coupe son accès dès sa page suivante et révoque les clés d’API de compte et les jetons d’API qu’il a créés. Les serveurs déjà installés continuent leurs sauvegardes : chacun a sa propre clé d’agent. Si cette personne avait un accès root à vos serveurs, changez aussi cet accès : nous ne le contrôlons pas.

Connexion : deux étapes et clés d’accès

Dans votre espace › Mon compte › Sécurité, vous pouvez protéger la connexion à ce site par une deuxième étape :

• Clé d’accès (passkey) ou clé de sécurité : elle utilise le verrouillage de votre appareil (empreinte, visage ou code) ou une clé USB/NFC. Elle ne fonctionne que sur ce site : un faux site ne peut pas la réutiliser. Vous pouvez aussi vous connecter avec la clé d’accès seule, sans mot de passe.
• Application d’authentification : un code à 6 chiffres d’une application comme Aegis, Google Authenticator, 1Password ou Bitwarden, demandé après le mot de passe. Chaque code ne sert qu’une fois.
• 10 codes de secours, affichés une seule fois à l’activation de la première méthode. Chacun remplace la deuxième étape une fois. Gardez-les ailleurs que sur votre téléphone.

Une fois activée, le mot de passe seul n’ouvre plus votre compte, même après une réinitialisation par e-mail. L’activation déconnecte vos autres sessions, et chaque changement vous est signalé par e-mail. Chaque membre d’une équipe active la sienne. Les comptes du back-office doivent en avoir une.

Cela protège l’accès au site uniquement. Cela ne change rien au chiffrement de vos sauvegardes : la clé de récupération de chaque serveur reste la seule clé de ses données.

Téléphone, clé et codes de secours perdus ? Écrivez au support depuis l’adresse du compte. Un e-mail seul ne suffit pas pour retirer la protection, car c’est exactement ce que demanderait quelqu’un qui a pris votre messagerie : nous vérifions d’abord votre identité, ce qui peut prendre quelques jours ouvrés. Vos sauvegardes continuent pendant ce temps.

Jetons d’API pour vos scripts

Dans votre espace client › Clés d’API › Jetons d’API, vous pouvez créer un jeton pour un script de supervision ou un tableau de bord. Il ouvre l’API publique, qui est en lecture seule :

GET /api/v1/token indique ce qu’est un jeton (droits, expiration). Envoyez-le en Authorization: Bearer nw_tok_….

• Un jeton ne peut rien modifier ni supprimer, ne peut pas enregistrer de serveur et ne sert pas à l’agent. Aucun jeton ne lit le contenu de vos sauvegardes : nous n’avons pas les clés.
• Vous choisissez ses droits, dans la limite de votre rôle dans l’équipe (seuls le titulaire et les administrateurs peuvent donner invoices:read et audit:read). Si votre rôle change ensuite, le jeton perd aussitôt ce que le nouveau rôle ne permet pas. Si vous quittez l’équipe ou en êtes retiré, vos jetons sont révoqués.
• Chaque jeton expire après 30, 90 ou 365 jours (90 par défaut). Il n’est affiché qu’une fois ; nous n’en gardons qu’une empreinte.
• La page Clés d’API montre, pour chaque jeton, quand et depuis quelle adresse il a servi pour la dernière fois et combien d’appels il a faits sur 30 jours. La création, la révocation et chaque appel refusé sont inscrits au journal du compte.
• Limite : 60 appels par minute et par jeton.

Journal d’audit

Le titulaire et les administrateurs ont une page Journal d’audit dans l’espace client. Elle montre qui a fait quoi sur le compte, quand et depuis quelle adresse :

• les connexions (mot de passe, deux étapes, clé d’accès), changements de mot de passe et réglages de double authentification du titulaire et de chaque membre, à partir du jour où il a rejoint l’équipe ;
• les invitations, arrivées, changements de rôle et retraits de l’équipe ;
• les clés et jetons d’API créés ou révoqués, et les appels d’API refusés faute de droit ;
• les serveurs supprimés et les changements de conservation, avec la personne qui les a faits ;
• les changements de formule, résiliations et reprises ;
• chaque intervention du support NeverWiped sur votre compte (consultation, déconnexion, réinitialisation de la double authentification, révocation des clés d’agent d’un serveur, remboursement), affichée « NeverWiped support » avec le motif donné ;
• chaque téléchargement du journal lui-même.

Les sauvegardes n’y sont pas : elles sont dans la page Historique et dans GET /api/v1/servers/{id}/runs.

Filtrez par dates et par catégorie, puis téléchargez en CSV (s’ouvre dans un tableur, UTF-8) ou en JSON. Un fichier couvre au plus 366 jours et 50 000 lignes. Les heures des fichiers sont en UTC. Les cellules qu’un tableur pourrait exécuter comme une formule commencent par une apostrophe.

Pour un outil de sécurité (SIEM), créez un jeton d’API avec audit:read et lisez GET /api/v1/audit?after=<id>&limit=500 : les événements arrivent du plus ancien au plus récent ; gardez next_after et renvoyez-le en after la fois suivante. Sans after, la lecture commence 30 jours en arrière (ou à since=<date ISO>).

Le journal contient les adresses e-mail et IP de vos membres : c’est pourquoi les techniciens et les membres en lecture seule ne le voient pas.

Si vous pensez qu’une clé a fuité

• **Clé de récupération ou repo.key :** qui la détient, avec l’identifiant de stockage, peut lire les sauvegardes de ce serveur. Changer la clé du dépôt n’est pas encore possible en ligne de commande : écrivez au support, et envisagez une réinstallation sur un nouveau dépôt (neverwiped uninstall --yes, puis neverwiped install crée un nouveau dépôt).
• Clé d’API de compte : révoquez-la dans votre espace client › Clés d’API. Les serveurs installés continuent.
• Jeton d’API : révoquez-le dans votre espace client › Clés d’API › Jetons d’API. Il ne pouvait que lire, jamais rien modifier.
• Identifiant de stockage (config.json) : il ne peut pas supprimer de sauvegardes, mais écrivez au support pour le faire réémettre.

Ce qu’un agent IA peut faire, ou non, avec ces identifiants : Pour les agents IA.