Linux：LUKSおよび複数のハードドライブ

RAID-1システムで暗号化されたデバイス（LUKS上のLVM）にDebian Linuxシステム（amd64）がインストールされており、データ（LUKSとおそらくLVM）を配置するディスクが4以上のRAID-6があります。

基本的な考え方は、システム暗号化パーティションのロックを解除し（ローカルでの起動時またはsshを介して）、RAID-6暗号化パーティションのキーファイルを/ etc / crypttabに格納することだと思います。セキュリティ上のリスクはありますか？つまり、誰かがローカル/リモートでシステムに入ることができて、「ルート化」（SSHなど）に対して脆弱なサーバー上で実行されているサービスがたくさんあるとしたら、それはかなり役に立ちません。代替策はありますか（SSHを介してパーティションのロックを解除する以外に、たとえばデータパーティションがマウントされる前でもバックアップ操作が開始されるため問題になることがあります）。

別のマシンでは、バックアップにLUKS + greyhole（RAID-6なし）の複数のディスクを使用します。同じパスワードを10回入力して10個のディスクのロックを解除するのは本当に大変です...

— user51166
ソース

誰かがシステムに侵入してrootになる可能性がある場合、暗号化されたパーティションのキーを取得する必要はありません。ルートから保護する意味はありません（TPMなどの特別なハードウェアがないか、仮想マシンで実行することは不可能です）。

— Gilles「SO-悪をやめなさい」

すみません？rootであっても、LUKSパーティションのロックを解除するためにキーファイル/パスフレーズを指定する必要があります。誰かがrootになった場合、私の暗号化されたデータへのフルアクセス権があるということです。残念ながら、暗号化されたパーティションがいったんマウントされると、暗号化されているかどうかに関係なく、それは単純に真実です。その場合、仮想マシンの利点は何でしょうか？では、なぜ暗号化が役立つのでしょうか。SSHや類似のサービスを介したrootへのアクセスを拒否する唯一の解決策はありますか？しかし、それでもハッカーが通常のユーザーとしてシステムに侵入した場合、通常、彼はすべてのファイルへの読み取りアクセス権を持っていますよね？

— user51166

正確には、誰かがあなたのシステムのルートである場合、彼らはすべてにアクセスできます。VMは、VM内のすべてにアクセスできることを意味します。暗号化の唯一の用途は、誰かがハードウェアを盗んだ場合です。

— Gilles 'SO-悪をやめなさい'

そうですね...その場合、データを保存するためのほとんど安全な方法は、すべてのネットワークから切断され、建物に統合された暗号化されたコンピュータにあると主張できます。それでも、誰もがキーボードを持ち、システムを再起動せずにデータを盗む可能性があります。バックアップサーバーになるため、必要なのはLANアクセスだけなので、システムをインターネットから分離することもできます。次に、VPNを使用した場合、またはLANマシンの1つが感染した場合、バックアップマシンも公開されます。これらの問題を解決するにはどうしますか？

— user51166 2012

unix.stackexchange.com/a/110102/50601を

— Tim Abell

回答:

で使用する/lib/cryptsetup/scripts/decrypt_derivedと、crypttabあるディスクのキーを別のディスクに自動的に使用できます。

このdecrypt_derived スクリプトは、Debianのcryptsetupパッケージの一部です。

sda6cryptからsda5にキーを追加する小さな例：

/lib/cryptsetup/scripts/decrypt_derived sda6crypt > /path/to/mykeyfile
cryptsetup luksAddKey /dev/sda5 /path/to/mykeyfile
ls -la /dev/disk/by-uuid/ | grep sda5
echo "sda5crypt UUID=<uuid> sda6crypt luks,keyscript=/lib/cryptsetup/scripts/decrypt_derived" >> /etc/crypttab
shred -u /path/to/mykeyfile # remove the keyfile

現在、ファイルを実際に削除することは非常に難しいので、/ path / to / mykeyfileが暗号化されたドライブ上にあることを確認してください（sda6crypt私の例では良い解決策です）。

一般に、ユーザー空間のファイルシステム暗号化を使用するなどして、セキュリティレイヤーを追加できますencfs。

— ジョフェル
ソース

そうすれば、キーファイルをディスクに保存する必要がなくなります。それはいいね。しかし、それは問題の価値があると思いますか（つまり、暗号化されたルートデバイスにキーファイルを保存することは「十分に安全」です）？疑問があるので意見を伺っています。提案をありがとう。

— user51166

のソリューションにdecrypt_derivedは、キーファイルがないという唯一の利点があります。誰かがrootアクセスを取得できる場合、通常はとにかく失われます。侵入者にとって、キーファイルの読み取りは、スクリプトを実行するよりも少し簡単です。セキュリティを強化するには、TOMOYO Linux、AppAmor、SMACK、SELinux、grsecurityなどを使用してシステムを強化できますが、これには追加の作業が必要です。そして、それが価値があるかどうかの質問がより重要です。キーが由来/保存されている場所でドライブがクラッシュした場合のために、キーのバックアップまたは別のキーを忘れないでください。

— jofel

私はgrsecurityまたは同様のソフトウェアも使用することを計画していました（最初ではありませんが、時間があるときにそれを保護します）。可能であればパスワードのみを使用し、キーファイルは使用しないことを考えています。まあパスワードはRAMに保存されるので、それについても議論できると思います。

— user51166

ファイルシステム全体を上書きすることを除けば、どこにでもキーファイルを削除するための良い方法はありません（おそらく、ディスクが故障した場合でもそうではありません）。ジャーナリングファイルシステムは、事態を著しく悪化させることはありません。

— Gilles「SO-悪をやめる」

@ギレス私は安全なファイル削除の専門家ではないので、私の回答を編集しました。暗号化されたドライブにキーファイルを保存することをお勧めします。

— jofel

jofelsの回答に基づいて、これは同じ例ですが、キーをファイルに保存する必要はありません。キーは名前付きパイプで渡され、ディスクには何も格納されません。

/lib/cryptsetup/scripts/decrypt_derivedcrypttabでを使用して、あるディスクのキーを別のディスクに自動的に使用できます。このdecrypt_derivedスクリプトは、Debianのcryptsetupパッケージの一部です。

sda6cryptからsda5にキーを追加するように変更された例：

mkfifo fifo
/lib/cryptsetup/scripts/decrypt_derived sda6crypt > fifo &
cryptsetup luksAddKey /dev/sda5 fifo
rm fifo

ls -la /dev/disk/by-uuid/ | grep sda5
echo "sda5crypt UUID=<uuid> sda6crypt luks,initramfs,keyscript=/lib/cryptsetup/scripts/decrypt_derived" >> /etc/crypttab

このkeyscriptオプションcrypttabは、Debianのオリジナルのcryptsetupツールで処理された場合にのみ機能し、systemdの再実装では現在サポートされていません。システムがsystemd（ほとんどのシステム）を使用している場合、initramfssystemdが起動する前に、cryptsetupツールによってinitrdで処理を強制的に実行するオプションが必要です。

— JanKanis
ソース