SSD et /tmp

Lien Rag · 17-12-2016 19:42:21

Bonjour.
Comment installer Debian sur un PC avec un SSD et un second HDD (pas SSD) dans un caddy (en remplacement du lecteur DVD) pour être sûr qu'aucune information confidentielle ne sera jamais écrite dans le SSD (puisque celui-ci est ineffaçable)?
Je pense notamment à ma clé privée, ce genre de trucs... et notamment je ne sais pas quand ce qui est en RAM risque d'être écrit temporairement sur le disque, mais je veux m'assurer que quelquesoient les circonstances jamais au grand jamais les trucs importants ne seront écrites en clair sur le SSD puisque dans ce cas le temporaire est en fait permanent pour qui a les moyens de faire l'autopsie du SSD.

otyugh · 17-12-2016 19:52:06

Lien Rag a écrit :

Comment installer Debian sur un PC avec un SSD et un second HDD (pas SSD)

Exactement comme si c'était un second HDD.

Lien Rag a écrit :

pour être sûr qu'aucune information confidentielle ne sera jamais écrite dans le SSD (puisque celui-ci est ineffaçable)?

Non ce n'est pas ineffaçable.

Pour être assuré que des données soient irrécupérables, il faut juste passer tous les bits de données à quelque chose. Partant de là, il me semble qu'en théorie y a un truc résiduel et donc on peut vouloir passer plusieurs couches d'effaçage.... Franchement, je pense que c'est inutile, je ne sais pas quels outils il faudrait pour récuperer après ça, mais ça inclut probablement des dizaine de milliers d'euros et une récupération infime et incontrolable.

dd if=/dev/zero of=/dev/MONSSD

changera tous les bits de ton SSD à 0, tu peux le lancer autant de fois que ça t'amuses. Dès la premières fois, rien ne sera récuperable ensuite, donc fais gaffe à ce que tu cibles.

raleur · 17-12-2016 21:45:22

otyugh, si tu crois cela alors tu connais bien mal le fonctionnement interne d'un SSD qui est très différent d'un disque dur.

Contrairement à un disque dur, la correspondance entre un secteur logique et son emplacement physique de son contenu n'est pas fixe. Les nouvelles données ne sont jamais enregistrées au même endroit que les anciennes car cela serait trop lent (il faut d'abord effacer une cellule de mémoire flash avant de pouvoir à nouveau écrire dedans, ce qui est long) et provoquerait l'usure prématurée des cellules occupées par les secteurs plus fréquemment réécrits.

Au lieu de cela, le contrôleur du SSD écrit les nouvelles données dans un nouvel emplacement vierge et modifie la table de correspondance pour que le secteur logique pointe vers le nouvel emplacement. L'ancien emplacement est marqué comme invalide et pourra être effacé ultérieurement afin de pouvoir recevoir de nouvelles données d'un autre secteur logique. Tant que le bloc contenant les anciennes données n'est pas effacé, celles-ci persistent et peuvent être lues en accédant directement aux puces de mémoire flash, ce qui est nettement plus facile que de lire sur les plateaux d'un disque dur.

D'autre part, pour mettre en oeuvre certains mécanismes (nivellement de l'usure, remplacement des blocs défectueux, effacement anticipé), un SSD a une capacité de stockage physique supérieure à la capacité utilisable annoncée. La différence est appelée "overprovisioning". Typiquement, pour une capacité utilisable de 120 Go la capacité physique réelle est de 137 Go (128 Gio). Les 17 Go qui ne sont pas visibles sont soit vide, soit contiennent d'anciennes données. Si on rééécrit la totalité de l'espace visible du SSD, il restera potentiellement jusqu'à 17 Go d'anciennes données non accessibles via l'interface du SSD mais bien présentes dans la mémoire flash.

Par conséquent, contrairement à un disque dur, réécrire plusieurs fois le contenu d'un SSD a un intérêt : via le mécanisme de nivellement de l'usure qui favorise la réutilisation des blocs les moins souvent écrits, cela a des chances de forcer l'effacement de blocs qui n'avaient pas été effacés lors de la passe d'écriture précédente. Néanmoins on n'a aucune garantie que toutes les anciennes données seront effacées.

Il y a aussi le problème des blocs défectueux et mis à l'écart qui peuvent contenir d'anciennes données partiellement voire totalement lisibles, mais c'est commun aux disques durs et aux SSD.

Les disques durs et SSD ont des commandes d'"effacement sécurisé", mais va savoir ce que font exactement les firmwares des contrôleurs.

Lien Rag : contre quelles menaces veux-tu te protéger ?
Si tu ne veux pas que des données importantes soient écrites en clair, il y a une solution : le chiffrement.
Si l'effacement des données n'apporte pas assez de garanties, il y a une autre solution (plus chère et moins écolo) : la destruction physique.du support par incinération, broyage fin...

raleur · 17-12-2016 22:18:26

Autrement, pour répondre à la question initiale de ne pas enregistrer de données confidentielles sur le SSD sans chiffrer, tout dépend de ce que tu considères comme "information confidentielle".

Les données confidentielles des utilisateurs comme leurs clés privées sont contenues dans leur répertoire personnel sous /home (par exemple $HOME/.ssh pour les clés privées SSH), donc ces répertoires ne doivent pas être stockés sur le SSD.

Idem pour /var s'il peut contenir des données sensibles (logs, bases de données...).

/tmp peut être en tmpfs, sinon idem les deux autres.

Le swap peut être chiffré avec une clé temporaire générée à chaque démarrage (mais pas d'hibernation dans ce cas).

Le reste du système peut être sur le SSD mais certains fichiers dans /etc peuvent contenir des données que tu considères confidentielles : liste des utilisateurs dans /etc/passwd*, mots de passe hachés dans /etc/shadow*, clés privées du serveur SSH dans /etc/ssh/, clés privées SSL (serveur web HTTPS...) dans /etc/ssl. Attention aussi à ce qui est stocké dans /root.

otyugh · 17-12-2016 22:31:55

Amh.
Alors autant je connaissais ce dont tu parles, autant j'ai complètement oubliué que ce n'était pas que de la théorie. Mieux vaut que je sache que je dise des grosses conneries maintenant que toute ma vie. Merci pour le cours

Dernière modification par otyugh (17-12-2016 22:32:59)

Debian-facile

#1 17-12-2016 19:42:21

SSD et /tmp

#2 17-12-2016 19:52:06

Re : SSD et /tmp

#3 17-12-2016 21:45:22

Re : SSD et /tmp

#4 17-12-2016 22:18:26

Re : SSD et /tmp

#5 17-12-2016 22:31:55

Re : SSD et /tmp

Pied de page des forums