KDEでDebian 9.1を使用していて、ハードドライブを暗号化しています。 GRUB説明どおりにパスワードを追加するかどうか here かどうか疑問に思っています。
それは理にかなっていますか?ハードドライブは暗号化されているので、だれもがそれらを起動/アクセスできるようにすべきではありませんか?また、GRUBブートローダーが起動する前に、GRUBパスワードを入力する前でも、UEFI設定にアクセスできます。
ただし、 このページ は、「Preventing Access to the GRUB Console」も1つとしてリストしていますGRUBパスワードを設定する理由の1つです。セキュリティを追加するために、いくつかの変更や構成が必要になる場合がありますか?
代わりに、UEFI設定にパスワードのみを設定する必要がありますか?または私の場合、BIOSパスワードは完全に冗長ですか?
ブートシーケンスを保護するには、GRUBパスワードの追加が必要ですが、ブートシーケンス全体を保護する場合にのみブートシーケンスを保護することは意味があります。つまり、GRUBパスワードを有効にする場合は、UEFIパスワードも有効にする必要があり、逆も同様です。どちらか一方を設定しても意味がないので、質問の1つに答えるには、いいえ、それは冗長ではありません。
セキュアブートがある場合、ブートシーケンスの各コンポーネントは、次のブートコンポーネント用にロードされたイメージを暗号で検証する必要があります。つまり、UEFIは暗号化署名されたGRUBイメージ(UEFIセキュアブートを使用)をロードして検証し、GRUBは暗号化署名されたLinuxカーネル/ initrdをロードして検証します/ drivers。セキュアブートを使用してチェーン全体を検証した場合、残っている唯一の脆弱性は、攻撃者がマザーボード/ブートROMを交換した場合、これは物理的な攻撃であり、物理的なセキュリティ対策(ケーシングなど)を使用して遅延または困難にすることができます。 /ラックロック、セキュリティカメラ、セキュリティガード、不正開封防止ステッカー)。
/ bootの暗号化にはほとんど意味がありませんが、ブートハイジャックを防ぐために/ boot内のファイルに暗号で署名する正当な理由があります。 UEFIでのセキュアブートおよびGRUBは、暗号化された署名シーケンスなしでオペレーティングシステムを起動するソリューションの一部です。起動パスワードを追加することで、UEFI/GRUB設定に不正な変更を加えたり、署名されていないシステムを起動したりすることを防ぎますUEFIシェル/ GRUBシェルから。
ハードドライブ上のユーザーデータは暗号化(およびMACd)され、不正な読み取りを防止し、変更を検出します。後半部分とは、攻撃者がディスク全体をワイプしてそこに独自のものを書き込む可能性があることを意味しますが、単一のファイルなどを適切なものに置き換えることはできません。
/ bootも暗号化されている場合(「if」、多くの命令が/ bootを暗号化しないままにしているため)、何のために? Grub(これは既知のソフトウェアです)の読み取りを防ぐには?いいえ。悪意のある変更を防ぐには?たぶん、でも、私(攻撃者だとしましょう)が自分の悪意のあるブートローダーで「全体」のGrubパーティションを上書きする(または、独自のブートローダーで2番目のディスクを提供する)のを妨げるものはありません。自分のファイルはわかりませんが、/ bootパーティションの作成方法は知っています。 ...つまり、あなたは負けました。私のブートローダーは、電源を入れるとすぐにコンピューターを引き継ぎ、後でHDDキーをスパイすることができます。
GRUB構成コンソールについて、特定の状況ではパスワードなしでアクセスを防止することは意味があります。攻撃者はハードドライブにnotにアクセスできます。 ATMを考えてください。 (可能であれば、上記のように、パスワードも役に立たない。)
UEFI設定パスワードと同様:ハードウェア(メインボードの交換、チップのフラッシュなど)にアクセスできる場合、それはまったく役に立ちません。
結論として、何が欲しいですか?
ファイルが読み取られないように保護しますが、コンピューターが盗まれた場合、(たとえそれを取り戻したとしても)それを信頼することはできません。ディスクの暗号化を保持し、残りは無視してください。
コンピュータの盗難や改ざんから保護しますか?すべて使用して、放射線シールドなどを備えた金庫に入れてください。
他に何か?不可能な。