MENU

BitLockerハードウェア暗号化SSDを維持したままシステムイメージを復元する方法｜Samsung 980 Pro・Macrium ReflectでeDriveを再現する実践ガイド

Windows11

「Samsung 980 Pro などの eDrive 対応 SSD に BitLocker を有効化したままシステムのフルバックアップを取り、障害時に復元してもハードウェア暗号化を維持できるのか？」――この問いは、性能とセキュリティを両立したい管理者にとって切実です。本記事は、設計上の制約を正しく理解しつつ、現実的に取り得る選択肢と手順、テスト方法、運用の落とし穴まで徹底的に解説します。

目次

前提と想定読者

  • 対象 OS：Windows 10 / Windows 11（TPM 2.0、UEFI、Secure Boot 前提）
  • 対象ストレージ：eDrive（準拠）/ TCG Opal 対応 NVMe/SATA SSD（例：Samsung 980 Pro）
  • バックアップ製品：Macrium Reflect（Rescue Media/WinPE を使用）
  • 目的：BitLocker のハードウェア暗号化（eDrive）状態を維持したままバックアップ＆リストアを行う
用語要点
ハードウェア暗号化（eDrive）暗号処理を SSD コントローラ側で実施。CPU 負荷が低く、SSD が対応＆Windows が許可した場合に有効化。
ソフトウェア暗号化OS（BitLocker）が XTS-AES などで暗号化。互換性と安全性を優先する標準的選択肢。
PSID リセットSSD 貼付ラベルに記載の PSID を用いて 完全初期化。eDrive 再プロビジョニングの前提となる。

なぜ復元後にソフトウェア暗号化へフォールバックするのか（設計の理解）

eDrive は「プロビジョニング時の未初期化ディスクを OS が検出し、ポリシー条件を満たしている場合にのみハードウェア暗号化として構成」されます。ここで重要なのは、いったんデータが乗ったドライブは “未初期化” ではないという点です。イメージ復元やクローンで展開先を上書きすると、Windows からは既使用ディスクとして扱われ、BitLocker の再有効化時にソフトウェア暗号化が選ばれる（あるいは自動的に切り替わる）ことが珍しくありません。

また、Windows 10 1903 以降 / Windows 11 では、既定ポリシーが安全側（ソフトウェア暗号化優先）に寄っており、eDrive を使うには 事前にグループポリシーでハードウェア暗号化を明示的に許可・強制する必要があります。

状況結果理由/背景
未初期化の新規 SSD にクリーンインストールeDrive 有効化の可能性が高いプロビジョニング要件を満たす。ポリシーが許可されていればハードウェア暗号化を選択。
既使用 SSD にイメージ復元（パーティション再作成）多くはソフトウェア暗号化展開先が既使用扱い。eDrive の前提が崩れる。
既存 eDrive を解除せず、Unlock 状態でパーティション内へ復元維持できる可能性ありベンダ実装・ツール挙動に依存。常に成功する保証はない。

結論サマリ（最短で理解）

視点内容
設計上の制限eDrive は未初期化ディスクでのプロビジョニングが大前提。既使用ディスクへ復元するとソフトウェア暗号化に落ちるのは仕様上自然。
唯一確実な再有効化PSID リセット → クリーンインストール → ポリシーでハードウェア暗号化を許可/強制 → BitLocker 有効化。
実践的回避例「Suspend せず、Unlock 状態でバックアップ/復元」で維持できた報告あり。ただし環境依存。
ポリシー注意既定はソフトウェア優先。OS/固定/リムーバブル各ポリシーでハードウェア暗号化を有効化し、フェイルオーバーを無効化。
安全性の観点ファーム脆弱性の歴史から、安全性重視ならソフトウェア暗号化を選ぶ判断も合理的。

ハードウェア暗号化（eDrive）を理解する

要件チェックリスト

  • UEFI モード & Secure Boot 有効
  • TPM 2.0 搭載・有効化（OS ドライブの自動ロック解除に必須）
  • SSD が eDrive/TCG Opal 準拠
  • Windows 側ポリシーでハードウェア暗号化を許可・強制
  • プロビジョニング時点で SSD が未初期化（PSID リセット直後など）
  • OS インストール先は GPT、インストーラでパーティション自動作成

確認コマンド（復元前後の判定）

manage-bde -status
# 出力例（ハードウェア暗号化の一例）
#   暗号化の方法: ハードウェア暗号化
#   保護: 有効
#   ロック解除方法: TPM, 数字の回復キー ...
PowerShell
Get-BitLockerVolume | Select-Object MountPoint, VolumeStatus, EncryptionMethod, LockStatus
# EncryptionMethod が HardwareEncryption / Hardware Encryption と判定できること

「Unlock 方式」で維持を狙う実践手順（成功は保証されないが有効な試行）

以下は、BitLocker を一切無効化/一時停止しない方針で、Unlock 状態のボリュームへパーティション単位で復元する手順です。目的は、暗号ボリューム自体を保持したまま中身（ファイルシステムの内容）だけを上書きすることにあります。環境によっては成功しないため、必ずテストベンチで検証し、業務本番に適用してください。

事前準備（バックアップ側）

  1. Windows を通常起動し、OS ドライブ（C:）が TPM により自動ロック解除された状態であることを確認。
  2. manage-bde -statusで「暗号化の方法: ハードウェア暗号化」を確認し、スクリーンショットやログで証跡化。
  3. Macrium Reflect でOS 必要パーティションのみを選択しイメージ化。BitLocker の “Suspend（保護の一時停止）” は使わない。
  4. Rescue Media（WinRE/WinPE）を作成し、ドライバ（NVMe/ストレージ/ネットワーク）とBitLocker サポートを含めて更新。
  5. 回復キー（.bek / 48 桁）をオフライン保管し、Rescue 環境から参照できる USB に保存。

復元手順（Rescue Media 起動後）

  1. Rescue Media でブートし、キーボードレイアウトを合わせる。
  2. コマンドプロンプトを開き、対象ボリュームのドライブレターを確認（WinPE は C: でない事がある）。
  3. 対象の展開先ボリュームを Unlockする。
    manage-bde -status manage-bde -unlock <ドライブレター:> -RecoveryPassword <48桁キー> # または manage-bde -unlock <ドライブレター:> -RecoveryKey E:\RecoveryKey\C.bek
  4. Macrium Reflect（Rescue）に戻り、ディスク全体ではなく該当パーティションを「既存パーティションに上書き」で復元する。
    • MBR/GPT の再初期化やレイアウト再作成は極力避ける。
    • 「既存パーティションを削除して新規作成」ではなく、現在の暗号ボリューム上に内容を展開する。
    • Rapid Delta Restore（RDR）はケースにより不可/可。失敗する場合は RDR を無効化して実行。
  5. 復元完了後に再起動。通常起動できたら、管理者権限で以下を実行： manage-bde -status Get-BitLockerVolume | fl MountPoint,EncryptionMethod EncryptionMethod がハードウェア暗号化のままであることを確認。

ポイント：

  • Unlock していない、またはパーティションを作り直した復元では、ほぼ確実にソフトウェア暗号化へ移行します。
  • ベンダ実装（SSD ファーム/BIOS/WinPE/バックアップ製品）に依存し、全環境で再現性はありません。
  • 成功しても、後日の大規模アップグレード（Feature Update）や BIOS 設定変更でソフトウェア化することがあります。定期監査が必要です。

確実な方法：PSID リセットからの再プロビジョニング

「絶対に eDrive を使い続けたい」要件では、PSID リセット → クリーンインストール → BitLocker（eDrive）再有効化が唯一確実です。

PSID リセットの概念

  • SSD ラベルに印字された PSID（英数字の長い文字列）を用い、ドライブ内部の暗号鍵とメタデータを完全消去します。
  • ベンダ提供ツールや Opal ユーティリティ（ブートメディア）で実行します。
  • 全データが消えるため、必ずバックアップを二重化してください。

再プロビジョニング〜OS 展開の順序

  1. BIOS/UEFI：UEFI モード、Secure Boot、TPM 2.0 を有効化。CSM は無効。
  2. PSID リセットで SSD を未初期化に戻す。
  3. Windows セットアップを開始し、インストール先ドライブの既存パーティションを全削除して未割り当てにする（PSID 済なら既に未割り当て）。
  4. OS インストール完了前/後に、グループポリシーでハードウェア暗号化を強制（詳細は後述）。
  5. OS 起動後に BitLocker を有効化。manage-bde -statusで「暗号化の方法: ハードウェア暗号化」であることを確認。

グループポリシー/レジストリ：ハードウェア暗号化の強制

Windows 10 1903/Windows 11 以降はソフトウェア暗号化が既定です。eDrive を使う場合は下記ポリシーを有効化し、ソフトウェアへのフェイルオーバーを無効にします。

ポリシー（ローカル グループポリシー エディター）

  • コンピューターの構成 > 管理用テンプレート > Windows コンポーネント > BitLocker ドライブ暗号化 > オペレーティング システムのドライブ
    「ハードウェア ベースの暗号化の使用を構成する」＝有効
    「ハードウェアが使用できない場合はソフトウェア暗号化を許可する」＝無効
  • 同様に「固定データ ドライブ」「リムーバブル データ ドライブ」でも必要に応じて設定。

レジストリ（構成管理/自動化向け）

PowerShell (管理者)
$Base = 'HKLM:\SOFTWARE\Policies\Microsoft\FVE'
New-Item -Path $Base -Force | Out-Null
New-ItemProperty -Path $Base -Name 'OSHardwareEncryption' -Value 1 -PropertyType DWord -Force | Out-Null
New-ItemProperty -Path $Base -Name 'OSAllowSoftwareEncryptionFailover' -Value 0 -PropertyType DWord -Force | Out-Null
New-ItemProperty -Path $Base -Name 'FDVHardwareEncryption' -Value 1 -PropertyType DWord -Force | Out-Null
New-ItemProperty -Path $Base -Name 'FDVAllowSoftwareEncryptionFailover' -Value 0 -PropertyType DWord -Force | Out-Null
New-ItemProperty -Path $Base -Name 'RDVHardwareEncryption' -Value 1 -PropertyType DWord -Force | Out-Null
New-ItemProperty -Path $Base -Name 'RDVAllowSoftwareEncryptionFailover' -Value 0 -PropertyType DWord -Force | Out-Null
gpupdate /force

適用後に新規プロビジョニング／有効化を行うことで eDrive が選ばれます。

Macrium Reflect ベストプラクティス（eDrive 運用）

  • Rescue Media を常に最新化：WinRE ベースでストレージ/ネットワーク/BitLocker コードパスを最新に。
  • OS 必須パーティションのみを撮る：EFI、MSR、C:、回復のセット。不要なデータ領域は別ボリュームで管理。
  • Suspend を使わない：Suspend/Disable は eDrive 前提を壊す可能性。
  • パーティション上書き復元：Unlock 済み暗号ボリュームへ内容だけを戻す方針。
  • RDR（Rapid Delta Restore）は状況次第。うまくいかない場合は無効にしてフル書き戻し。
  • 復元後の第一優先タスクは検証：manage-bde -statusで暗号方式を必ずチェック。

検証と監査（復元の成否を数分で見抜く）

即時確認コマンド

manage-bde -status
Get-BitLockerVolume | Select MountPoint, VolumeStatus, EncryptionMethod, LockStatus

EncryptionMethod が “ハードウェア暗号化”（表記は環境による）であることを記録。監査ログとして保存します。

イベントログ

  • イベント ビューアー > アプリケーションとサービス ログ > Microsoft > Windows > BitLocker-API/Management
  • 有効化/ロック解除/回復キー処理の成否を確認し、タイムスタンプを復元時刻と突き合わせる。

性能検証（任意）

ソフトウェア暗号化へ落ちていないか、負荷・スループット（CPU 使用率/IOPS）で違和感がないかを diskspd などで簡易測定。CPU 使用率が不自然に高い、ランダム小 IO で顕著に落ち込む場合はソフトウェア化を疑います。

よくある落とし穴と対処

落とし穴症状対処/回避
復元時にパーティションを削除・再作成eDrive が消えソフトウェア化Unlock 済み既存パーティションへ上書き。ディスク初期化や再レイアウトは避ける。
グループポリシー未設定既定でソフトウェア暗号化OS/固定/リムーバブルのハードウェア暗号化ポリシーを有効化し、フェイルオーバー無効。
BIOS/UEFI 設定変更Secure Boot/TPM 無効で自動解除不可UEFI, Secure Boot, TPM を適切に有効化。
ファームの互換性問題リカバリ後にロック/アンロック不可Rescue Media を更新。ドライバと BitLocker サポートを含める。別ポート/スロットで再試行。
回復キー未保管Unlock 不能で詰む.bek と 48 桁キーを二重保管し、Rescue Media から参照可能に。

企業展開の観点（Intune/MBAM/AD）

  • 鍵エスカロー（回復キーの保管）：Azure AD/MBAM/オンプレ AD に自動格納し、回復フローを標準化。
  • デバイス構成（MDM/Intune）：BitLocker ポリシーでハードウェア暗号化許可、ソフトウェアフェイルオーバー拒否、XTS 256 等の基準を統一。
  • 監査：復元直後の EncryptionMethod を収集する PowerShell をログオン スクリプトで実行、結果をSIEMへ送信。

ケース別フローチャート（テキスト版）

[Start] 既存 eDrive のシステムをバックアップした → 復元したい
  ├─ 復元先は同一 SSD？ はい
  │    ├─ 復元前に BitLocker を Disable/Suspend した？ はい → [失敗しやすい] eDrive 前提崩壊 → PSID リセット＋再構築を推奨
  │    └─ しない（Unlock のみ）？ はい
  │         ├─ WinPE で対象パーティションを manage-bde -unlock 済？ はい
  │         │     ├─ パーティション再作成せずに上書き復元？ はい → 起動後に EncryptionMethod を確認（維持できていれば成功）
  │         │     └─ いいえ → 再試行（再作成は不可）
  │         └─ いいえ → 回復キーで Unlock → 再実施
  └─ 別 SSD に移行？ はい → eDrive はドライブ固有 → 移行先での eDrive 前提を満たす必要あり
         ├─ 時間コストより確実性優先 → PSID リセット＋クリーンインストール＋データ復元（ファイル/ユーザープロファイル）
         └─ どうしてもイメージを持って行きたい → Unlock 方式をテストベンチで検証（成功は保証されない）

運用レシピ（コピペ用）

バックアップ時

  • OS 正常起動（TPM による自動 Unlock 状態）。
  • manage-bde -statusの結果を保存（スクリーンショット/テキスト）。
  • Macrium Reflect で OS パーティション群のイメージを取得（Suspend はしない）。
  • Rescue Media を更新、.bek/48 桁キーを USB へ。

復元時

  1. Rescue Media で起動 > コマンドプロンプト。
  2. manage-bde -status で対象ボリュームを確認、-unlock で解除。
  3. Reflect で既存パーティションに上書き復元（ディスク初期化/再レイアウトは避ける）。
  4. 起動後に manage-bde -status / Get-BitLockerVolume で暗号方式を確認・記録。

失敗時（ソフトウェア化した）

  • 要件が「絶対に eDrive」なら PSID リセット＋クリーンインストール。
  • 性能/安全性/保守性の観点でソフトウェア暗号化のまま運用を選ぶ現実解も検討。

安全性と性能のバランス

eDrive は CPU 負荷面で魅力的ですが、実装品質は SSD に依存し、ファームウェアの脆弱性が公表された歴史があります。最新ポリシーがソフトウェア優先に舵を切った背景を踏まえれば、安全性重視＝ソフトウェア暗号化も立派な選択です。要件が「最大性能」でなければ、復元の再現性と監査容易性を優先するアーキテクチャ設計も合理的です。

トラブルシューティング・コマンド集

# 状態確認
manage-bde -status

# プロテクタ確認

manage-bde -protectors -get C:

# 回復キーの追加（TPM 事故に備える）

manage-bde -protectors -add C: -RecoveryPassword

# 強制 Unlock（Rescue）

manage-bde -unlock C: -RecoveryPassword <48桁キー>

# BitLocker 再有効化（eDrive 前提が整っている場合のみ）

manage-bde -on C: -used -skiphardwaretest

# 解除（原則非推奨：eDrive 前提を壊す）

manage-bde -off C:

チェックリスト（導入/復元/監査）

フェーズ確認項目OK 条件
導入UEFI/Secure Boot/TPMすべて有効
導入ポリシー/レジストリハードウェア暗号化を強制、フェイルオーバー無効
導入ディスク状態PSID リセット済＝未初期化
導入有効化直後の状態manage-bde -status でハードウェア暗号化
復元Rescue Media最新/BitLocker サポート/ドライバ同梱
復元復元先ボリュームUnlock 状態でパーティション上書き
監査復元後直後EncryptionMethod がハードウェアのまま
監査イベントログBitLocker-API/Management にエラーなし

FAQ

Q. 別メーカーの SSD へ移行しても eDrive を維持できる？

A. 原則としてできません。eDrive はドライブ固有のプロビジョニングが必要です。移行先でも PSID リセット＋クリーンインストールで構成し直すのが確実です。

Q. イメージの「ディスク全体」復元と「パーティション」復元、どちらが良い？

A. eDrive 維持を狙うならパーティション上書きを推奨。ディスク全体復元は初期化/再レイアウトを伴い、eDrive 前提を崩す可能性が高いです。

Q. 復元後に EncryptionMethod が XTS-AES 128/256 と出る

A. ソフトウェア暗号化へ移行しています。要件次第でそのまま運用するか、PSID リセットからの再構築を検討してください。

Q. Macrium Reflect の RDR は使える？

A. Unlock 状態でのパーティション上書き復元で動作する場合もありますが、環境依存です。失敗時は RDR を無効化してフル復元に切り替えます。

Q. 回復キーを紛失した

A. Unlock 方式の復元は困難になります。企業環境では鍵のエスカローを必須運用にし、個人でも複数箇所で厳重保管してください。

まとめ：意思決定の指針

選択肢長所短所向いている状況
Unlock 方式の上書き復元ダウンタイム短縮、クリーンインストール不要の可能性成功は環境依存。再現性に欠ける検証環境があり、一定の失敗リスクを許容できる
PSID リセット＋クリーンインストール最も確実に eDrive を再構成工数が大きい。アプリ再展開が必要確実性最優先。標準構成を自動化できる
ソフトウェア暗号化で運用互換性と安全性が高く、復元の再現性も高いCPU 負荷が増える場合がある安全性/保守性を重視し、性能は二の次

あなたの要件（性能・安全性・再現性・運用コスト）に合わせ、上の三択を正直に評価してください。eDrive 維持の唯一確実な道は、PSID リセットからのやり直しであり、Unlock 方式は「試す価値はあるが賭け」だと捉えるのが健全です。最後に、どの選択でも、復元直後の EncryptionMethod を確認・記録する監査プロセスだけは必ず組み込んでください。

Windows11
Windows 11 BitLocker Macrium Reflect eDrive Samsung 980 Pro PSIDリセット ハードウェア暗号化

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次