實體主機備份磁碟區的 LUKS2 金鑰輪替與唯讀還原演練

備份檔案已寫入磁碟，接收帳戶也已完成隔離，但退役磁碟或離線副本中的資料是否仍能被直接讀取，則是另一道安全邊界。磁碟區加密適合保護尚未解鎖的資料，不能取代線上存取控制；金鑰輪替適合撤銷舊密碼，卻無法補救已經外洩的資料。本文使用獨立的檔案容器演練 LUKS2 換鑰與還原，不會操作現有資料磁碟。

一、先界定加密保護的對象

OnuCloud 實體主機標準配備兩顆 1TB NVMe，各自直接連接，沒有硬體 RAID。磁碟區加密、磁碟備援與異地備份解決的是不同問題：加密限制離線讀取，後兩者則分別因應裝置故障與提供獨立副本。將兩顆磁碟都加密，不會自動產生可還原的備份。

以下以 Ubuntu Server 24.04 LTS 為例，需要管理員權限、cryptsetup、e2fsprogs，以及約 256 MiB 的實際可用空間。請先透過發行版套件安裝所需工具，再進入專用的管理員 shell；後續命令都在同一個 shell 中執行，避免變數遺失。

已解鎖的磁碟區，仍可由具備相應權限的程序讀取。磁碟區加密無法防止管理員權限遭到濫用，也不能讓正在寫入的資料庫副本自動具備應用程式一致性。

正式導入前，應明確訂定由誰保管密碼、誰能讀取標頭備份，以及人員異動時如何撤銷存取權限。不要將密碼寫入命令參數、指令碼或工單內文。

二、建立不碰真實磁碟的演練磁碟區

mktemp 會建立獨立的工作目錄，所有格式化操作都只針對其中的新檔案。執行前，請確認映射名稱 backup-drill 尚未使用；若已存在，應停止並查明原因，不要關閉不明的映射。範例採用互動式密碼輸入，初始密碼存放在槽位 0。

umask 077
work=$(mktemp -d /var/tmp/luks-drill.XXXXXX)
image="$work/backup.img"
mountpoint="$work/mnt"
mkdir "$mountpoint"
truncate -s 256M "$image"
cryptsetup luksFormat --type luks2 --key-slot 0 "$image"
cryptsetup open "$image" backup-drill
mkfs.ext4 /dev/mapper/backup-drill
mount /dev/mapper/backup-drill "$mountpoint"
printf 'backup-recovery-check\n' > "$mountpoint/probe.txt"
(
  cd "$mountpoint"
  sha256sum probe.txt
) > "$work/expected.sha256"
sync
umount "$mountpoint"
cryptsetup close backup-drill

每一條命令成功後，才能執行下一條。尤其不能在解鎖失敗後繼續格式化，也不能將檔案路徑換成未經確認的 NVMe 裝置名稱。稀疏檔案的標示大小不等於實際占用空間；演練期間仍須確認存放檔案的檔案系統有足夠空間。

校驗清單儲存在容器外，方便還原時獨立比對。正式環境中的清單也必須有可信來源；若資料與清單可同時遭到竄改，單憑雜湊值相符，並不能證明來源可信。

三、先驗證新槽位，再撤銷舊密碼

先執行 cryptsetup luksDump "$image"，確認類型為 LUKS2、槽位 0 已啟用，且槽位 1 尚未使用。實際磁碟區的槽位配置可能不同，不能直接套用編號。以下新增密碼時，先輸入舊密碼完成授權，再依提示設定新密碼。

cryptsetup luksAddKey --key-slot 1 "$image"
cryptsetup open --test-passphrase --key-slot 1 "$image"
cryptsetup luksDump "$image"

第二條命令請輸入新密碼，結束碼為 0 才算驗證成功。--test-passphrase 只測試能否解鎖，不會建立映射，因此不會影響檔案系統的掛載狀態。新增槽位不等於更換磁碟區金鑰，也不代表所有資料都已重新加密。

確認新密碼已由獲授權人員妥善保存後，再刪除槽位 0。演練中，刪除時使用保留的新密碼授權：

cryptsetup luksKillSlot "$image" 0
cryptsetup open --test-passphrase "$image"

最後一條命令先輸入舊密碼，預期應失敗；接著重新執行並輸入新密碼，預期應成功。不要用自動重試掩蓋失敗，也不要只看槽位清單就宣告輪替完成。驗收紀錄應包含槽位變化與兩次測試結果，但不包含密碼本身。

四、標頭備份也是敏感的存取材料

LUKS 標頭儲存了解鎖所需的關鍵中繼資料。當資料區仍在、但標頭損毀時，標頭備份可能是還原所必需的材料；它不是資料副本，更不能與唯一的資料磁碟區一起遺失。輪替成功後，匯出目前的標頭：

cryptsetup luksHeaderBackup "$image" \
  --header-backup-file "$work/header-current.bin"
chmod 600 "$work/header-current.bin"
cryptsetup luksDump "$image" > "$work/luks-layout.txt"

目錄與檔案權限只提供本機的存取限制。正式的標頭副本應存放於受控的獨立保管位置，記錄對應磁碟區、輪替批次與獲授權人員，並與資料副本建立明確的對應關係。不要將標頭檔案當成一般診斷附件傳送。

歷史版本尤其需要妥善處理：舊標頭可能保留已撤銷的槽位，還原舊標頭可能讓舊密碼重新生效。因此，刪除目前磁碟區上的舊槽位，不代表所有歷史材料中的存取能力都已撤銷。若威脅涉及磁碟區金鑰外洩，單純更換密碼並不足夠，應另行規劃重新加密或遷移。

五、唯讀還原必須驗證到檔案內容

演練磁碟區已正常卸載，可以重新建立唯讀映射，再以 ext4 的唯讀模式掛載，且不重播日誌。這兩層限制分別約束區塊裝置與檔案系統的行為。

cryptsetup open --readonly --key-slot 1 "$image" backup-drill
mount -t ext4 -o ro,noload /dev/mapper/backup-drill "$mountpoint"
findmnt -no SOURCE,FSTYPE,OPTIONS "$mountpoint"
(
  cd "$mountpoint"
  sha256sum -c "$work/expected.sha256"
)
touch "$mountpoint/should-not-exist"

輸入新密碼後，掛載選項應包含 ro，校驗應成功，最後的寫入應失敗。若寫入成功，應立即停止驗收並檢查實際掛載目標，不能將其視為無關的異常。noload 不適合用來掩蓋檔案系統未正常卸載的狀態；遇到未正常卸載的副本，應先保全原件，再於工作副本上評估修復。

完成後，依序卸載目錄並關閉映射。確認沒有殘留的掛載與映射，再處理演練目錄；正式環境的材料則依既定保管規則管理，不要混入暫存資料的清理作業。

最終紀錄應能回答四個問題：新密碼能否獨立解鎖、舊密碼是否已失效、標頭副本是否受到控管，以及還原出的檔案是否與可信清單一致。四項都通過，才算完成一次可供複查的換鑰與還原演練。

常見問題