web-dev-qa-db-ja.com

rawドライブ（sdx）とパーティション（sdx1）でluksFormatを実行することの利点/欠点（ある場合）はありますか？

いくつかのLUKS暗号化ドライブをセットアップしていて、「raw」（？）ドライブに暗号化ディスクを直接作成していることに気付きました。/dev/sdb、Google経由の多くの例では、/ dev/sdb1で作成されたものを示しています

/ dev/sdbを使用した例：

# cryptsetup luksFormat /dev/sdb
# cryptsetup luksOpen /dev/sdb lvm_backup

..そして、次のようにボリュームグループと論理ボリュームを作成します。

# vgcreate vg_backup /dev/mapper/lvm_backup
# lvcreate -l +100%FREE lvm_backup -n backup
# mkfs.ext4 /dev/mapper/vg_backup-backup

最後にドライブを取り付けます。

これにより、lsblkは次のようになります。

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

対照的に、他のlsblk出力は次のようになります。

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

最初にディスク（/ dev/sdb）を直接操作することと、最初にパーティション（/ dev/sdb1）を作成することの利点/欠点は何ですか？

私はこれがおそらく多少関連していると仮定しています： https://serverfault.com/questions/338937/differences-between-dev-sda-and-dev-sda1

partitioninghard-driveencryptionluks
5
Jonathan

率直に言って、デバイス全体（/dev/sdb）を使用し、LUKSヘッダーがドライブの先頭にあり、他のツールまたはOSがディスクがフォーマットされていないと「役に立つ」と判断した場合、 MBRまたはGPT（LUKSヘッダーを上書きする場合、bad） LUKSにパーティションを使用している場合、少なくとも新しいMBRまたはGPTはそれほど破壊的ではありません。

cryptsetupのmanページにもあるように、LUKSヘッダーは常にバックアップする必要があります。

これが cryptsetup FAQ がを使用することについて述べていることです。「2.2パーティションまたはrawディスクでLUKS？」（それは長いですが、貼り付けます、RAIDとLVMは事態を大幅に複雑化する可能性があると述べています。

これは複雑な質問であり、RAIDとLVMの可用性によってさらに大きくなりました。いくつかのシナリオを示し、利点と欠点について説明します。単純にするためにLUKSと言いますが、プレーンdm-cryptを使用して説明したすべてのことを実行できます。また、特定のシナリオは非常に特殊であるため、以下で言うことのほとんどまたはすべてが当てはまらない場合もあります。

LVMをミックスに追加すると、非常に複雑になる可能性があることに注意してください。 RAIDと同じですが、それほどではありません。特に、データの回復は非常に困難になる可能性があります。本当に正当な理由があり、常にKISSがエンジニアとアマチュアを区別するものであることを覚えている場合にのみそうしてください。もちろん、追加の複雑さが本当に必要な場合は、KISSが満たされます。ただし、その代価を支払う必要があるため、必ず確認してください。エンジニアリングでは、複雑さは常に敵であり、遭遇すると容赦なく戦う必要があります。

少なくとも古いスーパーブロックフォーマット0.90では、RAIDスーパーブロックはLUKSヘッダーを恒久的に損傷するリスクが最も小さい場所（ディスクの最後）にあり、アレイを組み立てることができるため、LVMの代わりにRAIDを使用することも検討してくださいRAIDコントローラー（つまりカーネル）、あるべきです。そのためには、パーティションタイプ0xfdを使用します。本当に必要な場合を除き、スーパーブロックフォーマット1.0、1.1、および1.2には近づかないことをお勧めします。あなたはそれらの自動検出を失い、それを行うにはいくつかのユーザースペーススクリプトにフォールバックする必要があることに注意してください。

シナリオ：

（1）暗号化されたパーティション：好みのパーティションを作成し、その上にLUKSを配置し、LUKSコンテナにファイルシステムを配置します。これにより、通常のパーティション分割と同様に、異なるタスクのデータ領域を分離できます。機密データ、非機密データ、特定のアプリケーション、ユーザーの家、ルートなどのデータを保持できます。パーティションとファイルシステムの間に1：1マッピングがあり、セキュリティ機能が明確で、データを分離できるため、利点はシンプルです別の独立した（！）コンテナに入れます。

暗号化されたルートに対してこれを行うことはできません。initrdが必要です。一方、initrdは、暗号化されていないルートと同じくらい有能な攻撃者に対して脆弱であるため、そのように実行してもセキュリティ上の利点はありません。システムを侵害しようとする攻撃者は、initrdまたはカーネル自体を侵害するだけです。これに対処するより良い方法は、ルートパーティションに重要なデータが保存されていないことを確認し、それを追加の暗号化パーティションに移動することです。もしあなたが本当に心配しているのであれば、あなたのルートパーティションが物理的なアクセスを持つ誰かによって妨害されるかもしれません（しかし、奇妙なことに、例えばBIOS、キーボードなどを妨害しません）、他の方法でそれを保護してください。 PCは本当に安全なブートチェーン用にセットアップされていないだけです（一部の人々が主張するものは何でも）。

（2）完全に暗号化されたrawブロックデバイス：このためには、LUKSをrawデバイス（たとえば、/ dev/sdb）に配置し、ファイルシステムをLUKSコンテナーに配置します。これは、バックアップやオフラインデータストレージに使用される外部USBディスクなどに非常に適しています。

（3）暗号化されたRAID：パーティションやフルデバイスからRAIDを作成します。 RAIDデバイスが通常のブロックデバイスである場合は、RAIDデバイスの上にLUKSを配置します。アプリケーションは上記とまったく同じですが、冗長性が得られます。 （多くの人が気づいていないように見えるので注意してください。Linuxでは、任意の数のコンポーネントでRAID1を実行できます。）項目2.8も参照してください。

（4）さて、一部の人々は、RAID層の下で暗号化を行うことを主張しています。それにはいくつかの深刻な問題があります。 1つは、RAIDの問題の突然のデバッグがはるかに困難になることです。自動RAIDアセンブリはもうできません。コンポーネントの暗号化キーを同期するか、何らかの方法で管理する必要があります。唯一の利点は、暗号化を行うCPUの数が増えると少し速くなる可能性があることですが、セキュリティとシンプルさよりも速度が優先される場合、とにかくこれは間違っています。速度の問題を軽減する良い方法は、ハードウェアAESを実行するCPUを入手することです。

4
Xen2050