Remise à zéro des disques SSD


18

Nous hébergeons des VPS pour les clients. Chaque VPS client reçoit un LVM LV sur un disque dur de broche standard. Si le client devait partir, nous mettons à zéro ce LV en veillant à ce que leurs données ne soient pas transmises à un autre client.

Nous envisageons d'utiliser des SSD pour notre activité d'hébergement. Étant donné que les SSD ont la technologie de «nivellement par usure», cela rend-il la mise à zéro inutile? Est-ce que cela rend cette idée SSD irréalisable, étant donné que nous ne pouvons pas permettre aux données des clients de fuir vers un autre client?

Réponses:


23

En supposant que ce que vous cherchez à empêcher, c'est que le prochain client lise le disque pour voir les données de l'ancien client, puis écrire tous les zéros fonctionnerait toujours. L'écriture de zéros dans le secteur 'n' signifie que lorsque le secteur 'n' est lu, il renverra tous les zéros. Maintenant, le fait est que les données réelles sous-jacentes peuvent toujours être sur les puces flash, mais comme vous ne pouvez pas faire une lecture normale pour y accéder, ce n'est pas un problème pour votre situation.

C'EST un problème si quelqu'un peut physiquement mettre la main sur le disque et le démonter (car il pourrait alors lire directement les puces flash), mais si le seul accès dont il dispose est le bus SATA, alors une écriture de tous les zéros dans son ensemble le disque fera très bien.


1
Exactement la réponse que je cherchais, et quand j'y ai pensé, je suis arrivé à la même conclusion :)
jtnire

2
J'imagine (mais je ne sais pas avec certitude, et cela dépendra certainement du chipset du contrôleur utilisé dans le SSD) que l'écriture d'un secteur de zéros sur un SSD ne toucherait même pas les puces flash réelles. Le contrôleur doit remarquer que ce sont tous des zéros et simplement marquer ce secteur comme "mis à zéro" (ou simplement le pointer sur un secteur qui contient tous les zéros). Écrire un secteur de zéros est une chose assez courante à faire, et dans un boîtier spécial, ce serait un moyen bon marché et facile de réduire l'usure du flash, donc je serais choqué si au moins Intel et Sandforce ne le faisaient pas.
kindall

20

Ne remplissez jamais un SSD à zéro. Au minimum, cela épuisera une partie de la durée de vie en écriture du SSD pour peu ou pas d'avantages. Dans le pire des cas, vous pourriez mettre le contrôleur du SSD dans un état de performances (temporairement) réduit .

De cette source :

L'écrasement répété du disque entier avec plusieurs répétitions peut détruire avec succès les données, mais en raison de la couche de traduction du micrologiciel (FTL), cela est considérablement plus compliqué et prend plus de temps que sur les disques durs traditionnels. Sur la base de leurs résultats, c'est une option peu attrayante

Votre meilleure option, l'effacement sécurisé via le cryptage complet du disque:

Quelques disques SSD modernes peuvent utiliser le chiffrement intégral du disque - des exemples sont les nouveaux disques 320 d'Intel et certains disques de la série Sandforce 2200. Ces disques peuvent être effacés en toute sécurité de manière simple et rapide, sans aucune usure du disque. Le lecteur utilise le cryptage AES pour toutes les données écrites, donc un effacement sécurisé signifie simplement supprimer l'ancienne clé AES et la remplacer par une nouvelle. Cela rend effectivement toutes les «anciennes» données du lecteur irrécupérables.

Cependant, l'effacement sécurisé d'Intel n'est pas facile à automatiser. AFAIK, cela doit être fait à partir de l'application graphique Windows d'Intel, il ne peut être exécuté que sur un lecteur non amorçable vide, etc. Voir page 21 et suivantes dans la documentation Intels.

Votre autre option, l'effacement sécurisé ATA:

Une autre option consiste à émettre une commande ATA Secure Erase via fx HDPARM sous Linux. Cela sera beaucoup plus facile à automatiser via des scripts.

Pourvu que le lecteur implémente ATA Secure Erase d'une «bonne» manière, il faut s'attendre à ce qu'il supprime au moins la «couche de traduction flash» (FTL). La table FTL contient le mappage entre les secteurs logiques (que le système d'exploitation «voit») et les pages physiques de NVRAM sur le lecteur lui-même. Avec cette table de mappage détruite, il devrait être très difficile - mais probablement pas impossible - de récupérer les données du lecteur.

Cependant, je ne connais aucune étude qui a montré que ATA Secure Erase est systématiquement et bien implémenté sur tous les lecteurs du fabricant, donc j'hésite à dire que cela fonctionnera toujours - vous devriez lire la documentation technique du fabricant.

Pour une seule partition:

En lisant les commentaires des autres réponses, il semble qu'OP ne souhaite effacer en toute sécurité que des partitions individuelles. Une bonne façon de le faire serait de créer uniquement des volumes chiffrés , fx en utilisant LUKS ou TrueCrypt . De cette façon, vous pouvez effacer le volume en toute sécurité en jetant la clé de chiffrement, comme le fait le schéma de chiffrement complet du disque sur le disque.

Conclusion:

Si vous voulez vraiment, vraiment savoir, alors lisez l'article lié au blog de Sophos et lisez les notes techniques des fabricants de disques concernant l'effacement sécurisé. Cependant, si vous voulez un «bon» effacement sécurisé, alors un SSD avec cryptage complet du disque et un essuyage sécurisé et le remplacement des clés de cryptage est probablement votre meilleur choix. Vous pouvez également utiliser le chiffrement au niveau du système d'exploitation et jeter la clé lorsque vous souhaitez que les données soient effacées en toute sécurité.


1
La prudence est bonne, mais je ne suis pas sûr que la citation d'un avis datant de 2 ans sur un bogue de contrôleur qui n'est apparu que dans des charges de travail fortement artificielles dans un SSD spécifique qui a depuis longtemps été corrigé devrait avoir beaucoup de poids.
Daniel Lawson

1
@Daniel Lawson: Juste point. :-) J'ai reformulé cette section et l'ai changée en une dégradation temporaire des performances - et changé le lien vers un examen du lecteur M4 / C400 de Crucial (un lecteur actuellement en cours d'expédition) qui présente des ralentissements majeurs après de lourdes opérations d'écriture.
Jesper M

6

Le nivellement de l'usure n'a rien à voir avec la réduction à zéro des données.

Vous mettez à zéro les données pour empêcher d'autres personnes / applications de lire ces données. Les SSD «usent» leurs données pour s'assurer qu'elles restent utilisables plus longtemps en raison des «dommages» causés par l'écriture aux SSD. De plus, les disques le font généralement lorsqu'ils ne sont pas occupés, dans les situations de serveur, les périodes de silence ne sont pas toujours disponibles, donc ce travail n'est souvent pas fait.

Faites-vous payer vos clients pour leurs opérations d'E / S? Sinon, qu'est-ce qui peut les empêcher de tuer leur partie d'un SSD en heures / jours en écrivant tout le temps? Les SSD sont un peu plus faciles à tuer que la plupart des gens ne le pensent , en particulier dans les environnements d'écriture lourds.


Je parlais du bit "ça rend la réduction à zéro inutile" Chris, ce sont deux choses différentes
Chopper3

1
if (time < 9am) chriss_try_again()
Chris S

haha - ne t'inquiète pas mec :)
Chopper3

Bien que vrai sur les données, moins vrai sur le meurtre. Les «Enterprise Flash Drives» ont une longévité et une taille plutôt meilleures que les SSD grand public, mais tout comme les disques durs d'entreprise, vous payez la prime pour les performances. Selon Seagate, leur ESD "Pulsar" a une durée de vie de 5 ans, ce qui équivaut à environ 6 pétaoctets d'écriture. anandtech.com/show/2739/2 - Sur Pulsar Drive virtualgeek.typepad.com/virtual_geek/2009/02/… - Sur EFD
Daniel B.

3
Je sais Daniel, j'achète beaucoup de SSD d'entreprise que j'ai mis dans un environnement de lecture à 99 +% mais quand nous les avons testés, nous avons toujours trouvé qu'il était étonnamment facile de les «tuer», par exemple, nous en avons mis deux HP en tant que paire en miroir en tant que le disque de journal pour une boîte Oracle 10 raisonnablement occupée et les choses ont commencé à mal tourner dans les 4 semaines. Maintenant, c'était il y a environ 10 mois, donc la version HP de ce lecteur Pulsar n'était pas rebadgée. 6PB équivaut à ~ 38MB / s sur 5 ans ou ~ 180MB / s sur une seule année - vous ne pouvez donc pas utiliser un Pulsar pour capturer un seul canal de vidéo HD sans le casser en moins d'un an.
Chopper3

3

Il vaut donc la peine de lire des articles comme celui- ci . Si quelqu'un a un accès physique au disque, la récupération d'informations est plus facile. Avez-vous envisagé de chiffrer les données sur le SSD et tout ce que vous avez à faire est d'oublier en toute sécurité la clé privée, ce qui devrait être un problème plus facile. Je peux voir le SSD être une grande victoire sur les vps en raison des performances d'accès aléatoire bien meilleures.


2

Vous ne voulez certainement pas utiliser les méthodes traditionnelles d'effacement des SSD, telles que l'utilisation ddde la remise à zéro des données, ou d'autres méthodes qui écrivent des données aléatoires sur le disque. Ces méthodes conviennent mieux aux disques basés sur des plateaux. Il est efficace pour effacer le SSD, mais il utilisera également inutilement une grande partie des opérations d'écriture limitées du SSD, réduisant ainsi la durée de vie prévue du SSD. Cela coûterait cher rapidement. Il peut également diminuer les performances du SSD au fil du temps.

Les SSD ont une méthode différente pour un effacement sécurisé. Je dirai que cela semble très lourd à faire, car vous avez généralement besoin d'un certain type de contrôleur SATA qui peut faire une émulation IDE, et la procédure peut être compliquée. Certains fabricants fournissent des outils pour sécuriser l'effacement de leurs propres SSD, mais vous pouvez également le faire avec hdparm sur Linux: https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase . Mais vous remarquerez dans ces instructions que vous devez vous assurer que le lecteur n'est pas "gelé" avant de pouvoir continuer. C'est l'une des étapes les plus difficiles car elle nécessite de trouver une carte mère et un contrôleur SATA qui vous permettront de «dégeler» le lecteur pendant le démarrage du système, ce qui implique généralement de le débrancher de son câble SATA, puis de le rebrancher.

Quoi qu'il en soit, ma recommandation est de faire vos recherches et de choisir un SSD qui est livré avec un utilitaire d'effacement sécurisé qui peut être utilisé sur un système qui vous convient.


L'utilisation de dd pour remettre à zéro le disque, tant que vous utilisez une taille de bloc suffisamment grande et non pas la valeur par défaut de 512 octets, n'utilisera pas beaucoup de cycles d'écriture / effacement. Il utilisera environ 1. Je dis environ parce que je concède que si l'alignement de votre système de fichiers est incorrect, vous pouvez finir par écrire deux fois dans le même bloc flash dans certains cas. L'utilisation dd bs=1Mentraînera une usure minimale.
Daniel Lawson

2

Bien qu'une réponse soit déjà acceptée, je pense que la commande blkdiscard /dev/sdXmérite encore d'être mentionnée ici.

Selon Arch Wiki: SSD , la blkdiscardcommande supprimera tous les blocs et toutes les données seront perdues. Il est recommandé d'utiliser avant "vous voulez vendre votre SSD".

Je ne sais pas comment fonctionne TRIM, donc je ne sais pas s'il y a une garantie que les données seront effacées. Mais je pense que c'est mieux que de ne rien faire.

BTW, je crains que cette commande ne fonctionne que sur un périphérique entier, pas pour une seule partition.

J'espère que cela t'aides. :)


blkdiscardsemble ne pas être sûr dans tous les cas, car TRIMelle-même n'est qu'une demande et tous les contrôleurs SSD ne la respectent pas. Vous pouvez en savoir plus ici et ici . Mais comme expliqué ici, le noyau Linux maintient une liste blanche des périphériques connus pour honorer TRIM.
n2

Donc, si hdparm -I /dev/theSSDcontient Deterministic read ZEROs after TRIM, blkdiscarddevrait être rapide et garanti que les zéros soient lus par la suite. Sinon, un effacement sécurisé semble être la meilleure solution. Cependant, étant donné que la question concerne la sécurité des clients, Secure Erase pourrait être la meilleure solution car il semble conçu pour de tels cas d'utilisation.
nh2

1

La meilleure façon d'effacer les données d'une image de machine virtuelle est d'utiliser la fonction TRIM. De nombreux systèmes d'exploitation plus récents prennent en charge cela. Presque tous les SSD actuels le prennent également en charge.

Et, ce qui rend cette option encore meilleure, c'est que tous les SAN prennent également en charge cette fonctionnalité sous son nom SCSI UNMAP . C'est une excellente commande pour les SAN qui implémentent un provisionnement clairsemé, ce qui est une excellente fonctionnalité pour les machines virtuelles, en particulier lorsqu'il est combiné avec la déduplication des blocs.

Lorsque la commande TRIM est transmise à un SSD, le micrologiciel marque immédiatement ces blocs comme pouvant être réutilisés. Certains SSD renvoient toujours des zéros pour les blocs TRIM . D'autres lecteurs renverront des données définies par l'implémentation (c'est-à-dire aléatoires).

Sur les systèmes d'exploitation qui prennent en charge TRIM, une simple suppression du fichier marquera les blocs pour TRIM. L'opération TRIM réelle peut se produire immédiatement ou elle peut être groupée pour être exécutée ultérieurement. Parfois, il existe des outils qui forceront le TRIM d'un fichier ou analyseront une partition pour tous les blocs inutilisés.

Les performances de TRIM sous Linux sont toujours inégales, donc si vous utilisez cela, vous voudrez étudier vos options. Sous Windows, cela semble assez solide.


Désolé mais cela n'a aucun sens. Pour autant que je sache, TRIM n'a rien à voir avec le provisionnement fin, il dit simplement à un SSD de ne pas déranger les secteurs d'usure qu'il ne sait pas avoir été supprimés par le système de fichiers, il ne le fait pas non plus très spécifiquement zéro bloc.
Chopper3

@ Chopper3: Vous ne pouvez pas voir que ATA TRIM et SCSI UNMAP sont la même commande? UNMAP est définitivement utilisé dans l'allocation dynamique. TRIM n'efface aucun bloc sur au moins certains disques SSD. Après TRIM, les données ont disparu : il n'y a pas de méthode prise en charge pour les récupérer, le lecteur peut également renvoyer des zéros et certains le font.
Zan Lynx

"le lecteur peut aussi bien retourner des zéros" et "les données sont irrécupérables" sont deux choses très différentes. Dans tous les cas, l'utilisateur ne veut pas du tout effacer le SSD, il ne veut tout simplement pas que le prochain client puisse obtenir les données de l'ancien client, ce qui n'est pas la même chose non plus.
Chris S

0

Vous avez besoin d'un "SSD Secure Erase Utility". Si vous utilisez quelque chose comme ddle niveau d'usure, vous risquez de vous déclencher et vous vous retrouverez avec des secteurs de réserve qui contiennent toujours d'anciennes données client. Un utilitaire d'effacement sécurisé effacera tous les secteurs de l'appareil (pas seulement ceux présentés comme un disque sur le système d'exploitation).

Certains de ces utilitaires sont spécifiques à un fabricant particulier, demandez leur recommandation au fabricant de votre ou vos disques, ils sauront mieux que nous.


Désolé, ce n'est pas ce que je recherche, car je ne cherche pas à effacer tout le disque. Je ne crains pas que les données des clients soient toujours disponibles sur le disque SDD physique - je ne veux tout simplement pas qu'un autre client puisse y accéder via une fuite de données sur leur LV.
jtnire

0

Je ne pense pas que l'écriture de 0 vous aidera à empêcher un autre client de lire le disque.

Dans les SSD, lorsque vous écrivez quelque chose, le processus est très différent d'un disque dur normal.

Imaginez la situation suivante: une cellule mémoire "vide" dans un lecteur SSD est entièrement remplie de 1. Lorsque vous y écrivez quelque chose, il écrit les 0 et laisse les 1 inchangés.

Après, lorsque vous souhaitez enregistrer quelque chose de différent, le contenu précédent et le nouveau sont comparés. Si le précédent peut devenir le nouveau en écrivant quelques 0, ok. Si ce n'est pas possible, une autre cellule mémoire est utilisée.

"clair": 11111111 1ère sauvegarde: 11011011

nouvelles données: 00110011 il n'y a aucun moyen de faire de 11011011 devenir 00110011 (notez qu'il serait nécessaire de passer de 0 à 1, et ce n'est pas possible de le faire dans les SSD). Ainsi, une autre cellule mémoire sera utilisée.

Lorsque vous ajustez un lecteur, vous réinitialisez toutes les cellules de mémoire inutilisées à 1. Ainsi, elles seront claires pour être réutilisées. Et les données enregistrées sont préservées.

Pour faire ce que vous voulez: effacez (supprimez) d'abord les fichiers. Les cellules mémoire de ces fichiers seront marquées comme libres. Faites ensuite un TRIM: toutes ces cellules de mémoire deviendront des 1, sans aucun signe de données.


0

Facile à répondre: utilisez Linux pour reformater la partition en EXT4, qui indique au SSD que tous les blocs sont prêts à être effacés, comme faire un découpage sur tous les secteurs d'une partition. L'effet secondaire est un petit nombre d'écritures (structures EXT4).

Oubliez ˋddˋ avec aléatoire, cela réduira beaucoup la durée de vie du SSD. Certains SSD sont intelligents et s'ils voient un secteur complet rempli de zéros qu'ils n'écrivent pas, ils le marquent pour l'effacement.

Comme vous ne pouvez pas connaître les internes sur les firmwares, votre meilleure option est de reformater la partition en ext4 (sans reformatage complet, juste rapide, seulement les structures) sur un noyau Linux moderne, il fera un découpage sur toute la partition avant de le formater.

Pour tous ceux qui parlent d'effacement sécurisé, c'est-à-dire pour un SSD entier à la fois, ce qui est demandé est juste une partition du SSD et SANS perdre le reste des informations stockées sur celui-ci (niveau de partition, pas niveau SSD).

Conclusion: reformatez en Ext4, puis si vous avez besoin d'un autre format, reformatez à nouveau sur un autre format.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.