Sécurité

Comment NeverWiped protège vos sauvegardes, dit simplement. Aucune certification n’est revendiquée : nous décrivons ce que fait le système, et ce qu’il ne fait pas, limites connues comprises.

Chiffrement

• Les sauvegardes sont chiffrées sur votre serveur, avant de le quitter, par restic (open source) en AES-256 avec authentification Poly1305.
• La clé du dépôt est générée sur votre serveur, dans /etc/neverwiped/repo.key (root seulement), et ne nous est jamais envoyée. Une clé de récupération, affichée une fois à la création du dépôt, ouvre le même dépôt. Nous ne détenons ni l’une ni l’autre : nous gardons seulement un court code de contrôle, qui indique à quel serveur appartient une clé de récupération et n’ouvre rien.
• Votre serveur ne parle à la plateforme et au stockage qu’en TLS (HTTPS). Les disques du stockage sont en plus chiffrés au repos ; cela protège contre un disque perdu ou remplacé, pas contre quelqu’un présent sur le serveur de stockage en marche.
• Nous ne pouvons ni lire ni déchiffrer vos sauvegardes : les restaurations sont déchiffrées sur votre serveur, jamais sur les nôtres. Si vous perdez à la fois le serveur (avec son repo.key) et la clé de récupération, personne ne peut les lire.

Stockage en ajout seul

• Les sauvegardes sont stockées en France, un dépôt par serveur, chacun avec son identifiant limité à ce dépôt.
• Au quotidien, un serveur peut ajouter des sauvegardes et les relire, pas les supprimer ni les écraser.
• Le nettoyage des anciennes sauvegardes a lieu au plus une fois par semaine, juste après une sauvegarde, avec un identifiant distinct valable une heure et limité au dépôt de ce serveur. La plateforme délivre cet identifiant au plus une fois par serveur et par semaine.
• Vous pouvez suspendre le nettoyage d’un serveur (page du serveur › Conservation). Aucun identifiant capable de supprimer n’est alors délivré pour lui, et son espace ne fait que grandir. Détails : stockage, conservation et nettoyage.

Limites connues

• Root sur votre serveur. Quiconque est root sur votre serveur peut lire ses sauvegardes (avec repo.key), et peut utiliser les clés de ce serveur pour obtenir l’identifiant du nettoyage hebdomadaire et supprimer les sauvegardes de ce serveur. Il peut aussi ajouter de fausses sauvegardes : le nettoyage suivant les compte dans la conservation, et de vraies sauvegardes plus anciennes peuvent alors être supprimées. Suspendre le nettoyage ferme les deux. Vos autres serveurs ne sont pas touchés : chacun a ses propres clés et son propre dépôt.
• Notre plateforme. La plateforme peut supprimer le dépôt d’un serveur : c’est ainsi que fonctionne la suppression quand vous supprimez un serveur ou votre compte, ou après une résiliation ou un abonnement impayé (quand les sauvegardes sont supprimées). Elle transmet aussi la conservation qu’utilise chaque nettoyage. Quelqu’un qui prendrait le contrôle de notre plateforme pourrait donc supprimer des sauvegardes, mais toujours pas les lire.
• Un seul exemplaire. Vos sauvegardes sont stockées en un seul exemplaire, sur un serveur de stockage, sur des disques en RAID 6 : cela résiste à deux disques en panne, pas à la perte du serveur entier. Votre propre serveur garde les données d’origine.

Où sont les clés et les données

L’agent et l’installation

• Le script d’installation vérifie l’empreinte SHA-256 de l’agent avant de l’installer. L’empreinte vient de notre site, comme l’agent : elle détecte un téléchargement abîmé, pas une compromission de notre site.
• Les mises à jour de l’agent sont signées (Ed25519) et l’agent refuse une mise à jour dont la signature n’est pas valide. La clé de signature n’est pas sur la plateforme.
• L’agent télécharge restic (version 0.18.1) depuis les publications officielles de restic et vérifie son empreinte SHA-256, inscrite dans l’agent, avant de l’utiliser.
• L’agent est un binaire statique unique et tourne en root (il doit lire ce qu’il sauvegarde). En dehors de ce téléchargement de restic, il ne parle qu’à la plateforme et au stockage.
• Il ne restaure jamais par-dessus vos fichiers sans confirmation explicite (taper le mot demandé, ou --yes).

Sur la plateforme

• Seuls les administrateurs peuvent ouvrir l’administration, et il leur faut un second facteur. Chaque page consultée et chaque action dans l’administration sont inscrites dans un journal d’audit. L’administration ne donne aucun accès au contenu des sauvegardes.
• Vous pouvez protéger votre propre compte par un second facteur ou une clé d’accès (passkey). Supprimer un serveur ou retirer un membre de l’équipe redemande votre mot de passe.
• Des limites de débit protègent les connexions et l’API contre les tentatives répétées.
• La base de la plateforme est sauvegardée, chiffrée, sur un second site en Finlande.

Ce que nous ne revendiquons pas

Nous ne détenons aucune certification de sécurité et ne publions aucun chiffre de disponibilité. Si cela change, cette page le dira, certificat à l’appui.

Signaler une vulnérabilité

Écrivez à TODO_LEGAL(EMAIL_SECURITE), en français, en anglais ou en espagnol. Contact lisible par les machines : security.txt. Cette section est notre politique de divulgation.

Que nous envoyer

• Ce que vous avez trouvé et où : la page ou l’adresse, ou l’agent et la commande concernés.
• Les étapes pour reproduire, et ce qu’un attaquant pourrait en faire.
• Si vous souhaitez être remercié publiquement, et sous quel nom.

Ne mettez pas les données d’un autre client dans votre signalement. Si vous en avez vu, dites-nous de quoi il s’agissait, sans les copier.

Ce que nous faisons

• Nous accusons réception sous 3 jours ouvrés, et vous donnons une première évaluation sous 10 jours ouvrés.
• Nous vous tenons informé jusqu’à la correction, et vous prévenons quand elle est en ligne.
• Nous visons une correction des problèmes sérieux sous 30 jours. Si cela prend plus longtemps, nous vous disons pourquoi et jusqu’à quand.
• Si vous le souhaitez, nous vous remercions nommément sur cette page une fois la correction publiée. Nous ne versons pas de récompense : il n’y a pas de programme de bug bounty.

Publication

Laissez-nous un délai raisonnable pour corriger avant toute publication : nous proposons 90 jours à compter de votre signalement, ou moins une fois la correction en ligne et l’agent mis à jour par nos clients. Nous convenons de la date avec vous, et nous pouvons publier notre propre avis de sécurité.

Périmètre

• Inclus : ce site et l’espace client, le site de documentation, le script d’installation, l’agent, et le service de stockage auquel vos serveurs envoient leurs sauvegardes.
• Exclus : les services d’autres entreprises (notre hébergeur, notre prestataire de paiement, nos prestataires d’e-mail) : signalez-leur directement ; restic lui-même : signalez-le au projet restic ; les signalements qui ne listent que des en-têtes ou des réglages e-mail manquants, sans moyen de les exploiter.

Règles

• Testez uniquement avec votre propre compte et vos propres serveurs.
• N’accédez pas aux données ou sauvegardes d’autres clients, ne les modifiez pas et ne les supprimez pas. Si vous en atteignez, arrêtez-vous et prévenez-nous.
• Ne dégradez pas le service : pas de test de charge ou de déni de service, pas de spam, pas de scan automatique qui inonde le site.
• Pas d’ingénierie sociale envers notre équipe ou nos clients, pas de test physique.
• Gardez les détails pour vous jusqu’à la date convenue.

Dans ces limites, la recherche de bonne foi est bienvenue et nous n’engagerons pas de poursuites. TODO_LEGAL(formulation de la clause de recherche de bonne foi à valider)