Chiffrement et clés

Ce que fait le chiffrement

L'agent chiffre les données sur la machine, avant leur envoi. Les données sortent de la machine chiffrées, et elles arrivent chiffrées dans le stockage. Personne ne lit un dépôt sans sa clé.

Chaque endpoint a son propre dépôt, et chaque dépôt a sa propre clé. La clé d'un dépôt n'ouvre aucun autre dépôt.

Cette page dit où le chiffrement a lieu, qui garde les clés, et ce que cela veut dire pour vous.

Prérequis

• Aucun rôle. Cette page explique un comportement du produit. Elle ne demande aucune action dans le portail.
• Pour garder seul les clés : une instance de BaaStide installée chez vous.

Où les données sont chiffrées

1. La plateforme envoie un ordre de sauvegarde à l'agent. L'ordre porte la clé du dépôt de la machine, et un jeton d'accès au dépôt.
2. L'agent lit les fichiers sur la machine.
3. L'agent découpe les données en blocs, puis il chiffre chaque bloc avec la clé du dépôt. Le chiffrement utilise AES-256, avec un code d'authentification Poly1305.
4. L'agent envoie les blocs chiffrés au serveur BaaStide, en HTTPS.
5. Le serveur écrit les blocs dans le dépôt de la machine, tels qu'il les reçoit. Il ne les déchiffre pas pour les écrire.

Une restauration suit le chemin inverse. L'agent reçoit la clé, il télécharge les blocs, puis il les déchiffre sur la machine. Le code d'authentification de chaque bloc est vérifié : la lecture d'un bloc modifié échoue.

Le jeton d'accès au dépôt est court, et il expire. Il ne vaut que pour le dépôt de cette machine. Pour une restauration, ce jeton ne donne que la lecture : une restauration n'écrit jamais dans le dépôt.

Qui garde les clés

BaaStide existe sous deux formes : l'instance hébergée par BaaStide, et une instance installée chez vous. Cette section vaut pour les deux. Elle dit « la plateforme » pour le serveur de l'instance.

La plateforme crée la clé de chaque dépôt, et elle la garde dans sa base de données.

• La plateforme donne la clé à l'agent au début de chaque sauvegarde et de chaque restauration.
• L'agent garde la clé en mémoire seulement. Il ne l'écrit jamais sur le disque de la machine.
• La clé n'entre jamais dans une ligne de commande, dans une adresse, dans un fichier de la machine, ni dans le journal d'une tâche. Le journal d'une tâche remplace un secret par <redacted>.
• Le dépôt d'un tenant Microsoft 365 a aussi sa propre clé. La plateforme la crée, et elle la garde aussi.

La plateforme garde les clés parce qu'elle a besoin de lire les dépôts pour trois travaux :

1. Vérifier l'état d'un dépôt.
2. Retirer les anciens points de restauration, selon la rétention de la politique.
3. Préparer et suivre une restauration.

Pourquoi BaaStide n'est pas « zero-knowledge »

« Zero-knowledge » veut dire que le fournisseur ne peut pas lire vos données, parce qu'il n'a pas les clés. Ce n'est pas le cas de BaaStide.

Sur l'instance hébergée par BaaStide, la plateforme garde la clé de chaque dépôt. BaaStide peut donc lire les sauvegardes de vos clients.

BaaStide ne propose pas de mode où vous gardez seul les clés de cette instance. BaaStide ne chiffre pas non plus les clés avec un service de gestion de clés que vous contrôlez.

Signalez cette limite quand un contrat ou un régulateur demande que personne d'autre ne puisse lire les données. La réponse de BaaStide à cette demande est l'instance installée chez vous.

Garder seul les clés

Une instance de BaaStide installée chez vous garde les clés chez vous. La base de données, le stockage et les exports de clés sont à vous. BaaStide n'y a pas accès.

Cette instance vous rend aussi responsable des clés. Suivez ces étapes :

1. Choisissez l'instance installée chez vous, et non l'instance hébergée par BaaStide.
2. Protégez la base de données de l'instance. Elle contient les clés des dépôts.
3. Protégez les sauvegardes de cette base de données, au même niveau que la base elle-même.
4. Exportez une copie des clés hors du serveur. Choisissez une phrase secrète de 20 caractères ou plus pour cet export.
5. Gardez la phrase secrète loin du fichier d'export, par exemple dans un gestionnaire de mots de passe.
6. Gardez le fichier d'export loin du serveur de l'instance.
7. Refaites l'export après l'ajout de nouvelles machines. Un export porte les clés des dépôts qui existent à sa date.

Sans la base de données et sans cet export, les sauvegardes sont illisibles. Personne ne peut les ouvrir à votre place.

Les VM Hyper-V avec un TPM virtuel

Hyper-V chiffre l'état du TPM virtuel d'une VM avec le gardien de l'hôte. Sans ce gardien, un autre hôte n'ouvre pas ce TPM.

• L'agent écrit le gardien de l'hôte dans le point de restauration de la VM. Ce gardien est chiffré avec la clé du dépôt, comme les disques de la VM.
• L'agent n'écrit jamais le gardien en clair sur le disque de l'hôte.
• La plateforme reçoit seulement les empreintes des certificats du gardien. Elle ne reçoit jamais sa clé privée.

Une personne qui a le dépôt et sa clé ouvre donc le TPM des VM de cet hôte. C'est le même niveau d'accès que pour les disques des VM, qui sont déjà dans le dépôt. Voir Sauvegarder les VM d'un hôte Hyper-V.

Limites et précautions

• BaaStide n'est pas « zero-knowledge ». Sur l'instance hébergée par BaaStide, la plateforme peut lire les sauvegardes.
• Vous ne changez pas la clé d'un dépôt depuis le portail.
• Une image complète d'un volume BitLocker porte les données déchiffrées. L'agent les chiffre de nouveau avec la clé du dépôt avant leur envoi. Voir Image complète d'une machine Windows.
• La clé du dépôt n'est dans aucun fichier de la machine. L'agent la garde en mémoire seulement, pendant la tâche.
• Gardez les clés de récupération BitLocker de vos VM hors de l'hôte Hyper-V. Une restauration sur un autre hôte peut donner un TPM vide.
• Le chiffrement ne remplace pas les tests de restauration. Voir Tester ses restaurations.