Vos données sont illisibles pour votre prestataire, et pour nous
Le chiffrement a lieu sur le poste, avec une clé qui ne transite jamais par le réseau. Ce n’est pas une option de configuration : c’est le fonctionnement par défaut.
« Et vous, vous pouvez lire nos données ? »
C’est la question qui arrive en rendez-vous, tôt ou tard. La réponse doit être vérifiable, pas rassurante.
Beaucoup de solutions chiffrent au repos, côté serveur : les données sont chiffrées sur le disque du serveur de sauvegarde. Cela protège contre le vol physique du disque. Cela ne protège pas si quelqu’un obtient un accès au serveur, puisque c’est le serveur qui détient la clé.
BeBackup chiffre à la source. Les données sont chiffrées sur la machine sauvegardée, avant de partir, avec une clé qui ne quitte jamais cette machine. Le serveur ne stocke que des blocs inintelligibles et l’empreinte de la clé — de quoi vérifier qu’un agent présente la bonne clé, jamais de quoi déchiffrer.
La chaîne, étape par étape
-
1
Sur le poste
Chaque bloc est compressé (LZO) puis chiffré en AES-256 par l’agent, avant toute émission. Les mots de passe des sources sont eux aussi chiffrés et liés à l’identifiant matériel du poste.
-
2
Sur le réseau
Transport TLS 1.3 entre l’agent et le serveur, sur OpenSSL 3.5, avec chiffrement AES des paquets. Ni le TLS ni le chiffrement des paquets ne peuvent être désactivés par configuration.
-
3
Sur le serveur
Les blocs arrivent déjà chiffrés et sont stockés tels quels. Le serveur ne détient que l’empreinte de la clé de données, pas la clé.
-
4
À la vérification
Chaque bloc porte ses empreintes, avant et après compression. Le serveur contrôle donc l’intégrité des données sans jamais pouvoir les déchiffrer.
La contrepartie, dite franchement
Un chiffrement dont la clé reste chez le client a une conséquence qu’il faut énoncer clairement : la clé est propre à chaque poste et elle est irremplaçable. Personne ne peut la régénérer, ni vous, ni nous.
C’est exactement ce qui rend la garantie de confidentialité crédible — et c’est aussi ce qui fait de la conservation sécurisée de la clé de récupération une tâche d’exploitation à part entière, à organiser avant le premier déploiement. Pour un prestataire qui gère un parc, c’est une procédure à écrire, pas une case à cocher.
Un prestataire peut également choisir d’imposer une clé côté serveur pour les postes qu’il administre, s’il préfère centraliser cette responsabilité plutôt que la laisser à chaque machine. Ce qu’un prestataire prend en charge
Un seul port à ouvrir
Le serveur écoute sur un port unique pour les agents, l’interface web et les certificats. L’aiguillage se fait par lecture du ClientHello (SNI et ALPN) : le serveur identifie la nature de la connexion avant de la router.
Pour l’administrateur réseau, cela se traduit par une règle de pare-feu au lieu de trois, et par une surface d’exposition réduite d’autant. Le mode maintenance verrouille par ailleurs l’accès sur le seul réseau local.
Certificats : émis, importés, renouvelés
- Autorité de certification interne : création de la CA et des certificats, génération de demandes CSR, import de certificats externes et régénération du certificat serveur — le tout depuis l’interface.
-
Let’s Encrypt automatique : émission depuis l’interface via ACME v2 (
tls-alpn-01ethttp-01), puis renouvellement automatique 30 jours avant expiration. Let’s Encrypt, Buypass et ZeroSSL sont proposés, et une autorité personnalisée peut être indiquée par URL. - Plancher TLS 1.2 pour les navigateurs, TLS 1.3 pour les agents.
Le certificat expiré un dimanche matin est un classique de l’exploitation. Ici, le renouvellement ne dépend ni d’une tâche planifiée à écrire, ni d’un rappel dans un agenda.
Contrôle des accès à la console
-
Double authentification TOTP
Compatible Google Authenticator et équivalents, avec QR code généré par le serveur.
-
Inscription des appareils
Une connexion depuis un appareil inconnu déclenche un code de validation et un courriel « nouvel appareil enregistré » précisant l’adresse IP et le navigateur. Chaque utilisateur gère ensuite ses appareils : renommer, supprimer, déconnecter tout.
-
Certificat client exigible
Un certificat peut être imposé par utilisateur web et pour les serveurs liés. La session est validée à la fois sur l’adresse IP et sur le certificat.
-
Validation de l’adresse e-mail
Par code envoyé, avec comptage des échecs de connexion et mot de passe salé par clé de session.
Faites auditer le modèle
Nous détaillons volontiers la chaîne de chiffrement avec votre RSSI ou votre auditeur, sur pièces.
Les autres pages de la rubrique Fonctionnalités
- Nouveautés de la v7 Microsoft 365, BeBackup Drive, agents macOS, Linux, Synology, Android et iPhone, SmartImage…
- Microsoft 365 Boîtes aux lettres, contacts, calendriers, OneDrive et SharePoint sauvegardés via Microsoft…
- Système et virtualisation SmartImage, image disque, VSS pour SQL Server et Hyper-V, VM VMware sauvegardées sans agent…
- Restauration et reprise Fichier, dossier, partition, disque entier, machine physique vers VM ESXi, démarrage sous…
- Pour les prestataires Console multi-clients, marque blanche, droits par technicien, quotas et tableau de bord temps…
- Vous êtes ici Sécurité et chiffrement
Contacter l’équipe BeBackup
Vous avez besoin de plus de renseignements sur notre solution de sauvegarde BeBackup ?