Existe-t-il des avantages / inconvénients (le cas échéant) dans l'exécution de luksFormat sur un lecteur brut (sdx) par rapport à une partition (sdx1)?
J'ai mis en place quelques lecteurs chiffrés par LUKS et j'ai remarqué que je créais le disque chiffré directement sur le lecteur 'raw' (?), C'est-à-dire./dev/sdb, alors que de nombreux exemples via Google montrent qu'il a été créé sur/dev/sdb1
Exemple utilisant/dev/sdb:
# cryptsetup luksFormat /dev/sdb
# cryptsetup luksOpen /dev/sdb lvm_backup
..et ensuite avec la création de groupes de volumes et de volumes logiques comme suit:
# vgcreate vg_backup /dev/mapper/lvm_backup
# lvcreate -l +100%FREE lvm_backup -n backup
# mkfs.ext4 /dev/mapper/vg_backup-backup
et enfin monter les disques.
Cela me laisse avec un lsblk qui ressemble à ceci:
sdb 8:16 0 2.7T 0 disk
lvm_backup (dm-3) 252:3 0 2.7T 0 crypt
vg_backup-backup (dm-5) 252:5 0 2T 0 lvm /backup
En revanche, les autres sorties de lsblk ressemblent à:
sdb 8:16 0 2.7T 0 disk
sdb1 #:# 0 2.7T 0 part
lvm_backup (dm-3) 252:3 0 2.7T 0 crypt
vg_backup-backup (dm-5) 252:5 0 2T 0 lvm /backup
Quels sont les avantages/inconvénients de travailler directement sur le disque (/ dev/sdb) par rapport à la création d’une partition (/ dev/sdb1) en premier?
Je suppose que ceci est probablement lié à: https://serverfault.com/questions/338937/differences-between-dev-sda-and-dev-sda1
Désormais, je pense que si vous utilisez l’ensemble du périphérique (/dev/sdb) et que votre en-tête LUKS se trouve au début du lecteur, et si un autre outil ou système d’exploitation "décide" que votre disque n’est pas formaté sans MBR ou GPT, s'il devait écraser votre en-tête LUKS, ce serait mauvais . Si vous utilisiez une partition pour LUKS, au moins un nouveau MBR ou GPT ne serait pas aussi dévastateur.
Vous devez toujours sauvegarder l’en-tête de LUKS , comme l’indique également la page de manuel cryptsetup.
Et voici ce que = FAQ // cryptsetup sur l'utilisation de "2.2 LUKS sur des partitions ou sur des disques bruts?" (c'est long, mais je vais simplement le coller , mentionne que RAID et LVM peuvent grandement compliquer les choses, vous voudrez peut-être repenser en utilisant LVM au-dessus de LUKS):
C'est une question compliquée, rendue d'autant plus importante par la disponibilité des systèmes RAID et LVM. Je vais essayer de donner quelques scénarios et de discuter des avantages et des inconvénients. Notez que je dis LUKS pour plus de simplicité, mais vous pouvez également faire tout ce qui est décrit avec dm-crypt. Notez également que votre scénario spécifique peut être si spécial que la plupart ou même toutes les choses que je dis ci-dessous ne s'appliquent pas.
Sachez que si vous ajoutez LVM au mixage, les choses peuvent devenir très compliquées. Même chose avec RAID mais moins. En particulier, la récupération de données peut devenir extrêmement difficile. Ne le faites que si vous avez une très bonne raison et que vous vous rappelez toujours que KISS est ce qui distingue un ingénieur d’un amateur. Bien sûr, si vous avez vraiment besoin de la complexité supplémentaire, KISS est satisfait. Mais soyez très sûr car il y a un prix à payer pour cela. En ingénierie, la complexité est toujours l'ennemi et doit être combattue sans pitié, le cas échéant.
Envisagez également d’utiliser RAID au lieu de LVM, car au moins avec l’ancien format de superbloc 0.90, le superbloc RAID est à la place (fin du disque) où le risque d’endommager de manière permanente l’en-tête de LUKS est moindre et vous pouvez alors assembler votre tableau de le contrôleur RAID (c.-à-d. le noyau), comme il se doit. Utilisez le type de partition 0xfd pour cela. Je recommande de rester à l'écart des formats superblocs 1.0, 1.1 et 1.2 sauf si vous en avez vraiment besoin. Sachez que vous perdez la détection automatique avec eux et que vous devez recourir à un script d’espace utilisateur pour le faire.
Scénarios:
(1) Partition chiffrée: créez une partition à votre guise, et mettez LUKS dessus et un système de fichiers dans le conteneur LUKS. Cela vous permet d'isoler des zones de données ayant des tâches différentes, comme le fait le partitionnement ordinaire. Vous pouvez avoir des données confidentielles, des données non confidentielles, des données pour certaines applications spécifiques, le répertoire utilisateur, le répertoire racine, etc. Les avantages sont la simplicité: mappage 1: 1 entre les partitions et les systèmes de fichiers, fonctionnalité de sécurité claire et possibilité de séparer les données. dans différents conteneurs indépendants (!).
Notez que vous ne pouvez pas faire cela pour une racine cryptée, qui nécessite un initrd. D'autre part, un initrd est à peu près aussi vulnérable qu'un attaquant compétent qu'une racine non chiffrée, il n'y a donc aucun avantage en termes de sécurité à le faire de cette façon. Un attaquant qui veut compromettre votre système ne fera que compromettre l'initrd ou le noyau lui-même. La meilleure solution consiste à s'assurer que la partition racine ne stocke aucune donnée critique et ne la déplace pas vers des partitions chiffrées supplémentaires. Si vous craignez vraiment que votre partition racine ne soit sabotée par une personne ayant un accès physique (cela ne serait toutefois pas étrange, par exemple, sabotez votre BIOS, votre clavier, etc.), protégez-la d'une autre manière. Le PC n'est tout simplement pas configuré pour une chaîne de démarrage vraiment sécurisée (quoi que certaines personnes puissent prétendre).
(2) Périphérique de bloc brut entièrement chiffré: pour cela, placez LUKS sur le périphérique brut (par exemple,/dev/sdb) et placez un système de fichiers dans le conteneur LUKS, sans aucun partitionnement. Ceci est très approprié pour des choses telles que les disques USB externes utilisés pour les sauvegardes ou le stockage de données hors connexion.
(3) RAID crypté: créez votre RAID à partir de partitions et/ou de périphériques complets. Placez LUKS sur le périphérique RAID, s'il s'agissait d'un périphérique en mode bloc ordinaire. Les applications sont identiques à celles décrites ci-dessus, mais vous obtenez une redondance. (Remarque: beaucoup de gens semblent ne pas en être conscients: vous pouvez utiliser RAID1 avec un nombre arbitraire de composants sous Linux.) Voir aussi le point 2.8.
(4) Maintenant, certaines personnes recommandent de faire le cryptage sous la couche RAID. Cela pose plusieurs problèmes graves. La première est que le débogage soudain des problèmes RAID devient beaucoup plus difficile. Vous ne pouvez plus faire d'assemblage RAID automatique. Vous devez synchroniser les clés de chiffrement des composants ou les gérer en quelque sorte. Le seul avantage possible est que les choses tournent un peu plus vite à mesure que le nombre de processeurs encryptés augmente, mais si la vitesse est prioritaire sur la sécurité et la simplicité, vous le faites de toute façon de manière erronée. Un bon moyen d’atténuer un problème de vitesse consiste à obtenir un processeur prenant en charge le matériel AES.