outputLinuxのLUKS暗号化設定｜ディスク全体を暗号化してデータ漏洩を防ぐ実践ガイド

サーバーのHDDやSSDが物理的に抜き取られたとき、あなたのデータは守られますか？

ファイアウォールやssh鍵認証を完璧に設定していても、ストレージを物理的に持ち出されてしまえば、暗号化なしではデータをそのまま読み取られてしまいます。盗難・廃棄時の情報漏洩リスクは、ネットワーク越しの攻撃と同じかそれ以上の深刻な問題です。

この記事では、Linuxのディスク暗号化標準「LUKS（Linux Unified Key Setup）」について、仕組みから実際の設定手順・運用上の注意点まで現場で使えるレベルで解説します。データセンターのサーバーだけでなく、ノートPCや社内検証環境にも応用できる内容です。

LUKSとは？ Linuxディスク暗号化の標準規格

LUKS（Linux Unified Key Setup）は、Linuxにおけるブロックデバイス（ディスクやパーティション）の暗号化標準仕様です。2004年に登場し、現在ではほぼすべてのLinuxディストリビューションのインストーラーに標準組み込みされています。

LUKSが「標準」として広く使われる理由は、次の3点に集約されます。

・互換性: Red Hat系・Debian系・Arch系を問わず、同じcryptsetupコマンドで操作できる
・複数キースロット: 最大8つ（LUKS2では32個）のパスフレーズ・鍵ファイルを登録でき、管理者交代時の鍵失効も安全に行える
・業界標準の暗号アルゴリズム: AES-XTS（推奨）など、NISTが認定する暗号方式を利用できる

LUKSで暗号化されたパーティションは、正しいパスフレーズや鍵ファイルなしには内容を読み取れません。ディスクを物理的に抜き取って別のマシンに接続しても、中のデータは暗号化されたバイト列にしか見えません。

LUKSの仕組みを理解する

LUKSはブロックデバイス全体を「コンテナ」として扱います。仕組みを順に追うと次のようになります。

1. ヘッダー領域にマスターキーを保存

LUKSデバイスの先頭にはヘッダーが書き込まれます。このヘッダーには「マスターキー」と呼ばれる暗号化の本体キーが、パスフレーズや鍵ファイルで暗号化された状態で格納されています。

ユーザーが入力したパスフレーズは、マスターキー自体ではなく「マスターキーを解錠するための鍵」として機能します。この設計のおかげで、パスフレーズを変更してもデータの再暗号化が不要になっています。

2. dm-cryptによる透過的な暗号化

マスターキーが解錠されると、Linuxカーネルの「dm-crypt（device mapper crypt）」が動作し、読み書きのたびにオンザフライで暗号化・復号を行います。ファイルシステム側からは通常のブロックデバイスとまったく区別なく使えます。

3. LUKS1とLUKS2の違い

新規構築の場合はLUKS2を選択するのが現在の標準です。cryptsetup 2.x以降ではデフォルトがLUKS2になっています。

cryptsetupのインストールと事前確認

ほとんどのディストリビューションでは標準でインストール済みですが、念のため確認します。

# バージョン確認（2.x以上が推奨）
cryptsetup --version

# インストールされていない場合
# RHEL/CentOS/AlmaLinux
sudo dnf install cryptsetup

# Ubuntu/Debian
sudo apt install cryptsetup

暗号化対象のデバイスを確認します。誤ったデバイスを指定するとデータが消えるため、必ず二重確認してください。

# ブロックデバイス一覧の確認
lsblk

# 特定デバイスの詳細（UUIDも確認できる）
blkid /dev/sdb

パーティションをLUKSで暗号化する手順

1. LUKSコンテナの初期化（フォーマット）

この操作でデバイス上の既存データはすべて失われます。事前にバックアップを取ってから実行してください。

# LUKS2形式でフォーマット（推奨）
# /dev/sdb1 を対象とする場合
sudo cryptsetup luksFormat --type luks2 /dev/sdb1

# 確認メッセージが出る。"YES"（大文字）と入力する必要がある
WARNING!
========
This will overwrite data on /dev/sdb1 irrevocably.

Are you sure? (Type 'yes' in capital letters): YES

# パスフレーズの入力（強力なもの。後述の管理方法を参照）
Enter passphrase for /dev/sdb1:
Verify passphrase:

暗号化アルゴリズムを明示的に指定したい場合は次のようにします。

# AES-XTS（256bit鍵）を明示指定（デフォルトと同等）
sudo cryptsetup luksFormat --type luks2 \
  --cipher aes-xts-plain64 \
  --key-size 256 \
  --hash sha256 \
  /dev/sdb1

2. LUKSコンテナを開く（マッピング）

暗号化したデバイスを使うには、まず「開く」操作が必要です。これにより `/dev/mapper/` 配下に仮想デバイスが作成されます。

# コンテナを開く（"mydata" は任意のマッピング名）
sudo cryptsetup luksOpen /dev/sdb1 mydata

# マッピング確認
ls -la /dev/mapper/mydata

3. ファイルシステムの作成とマウント

# ファイルシステムの作成（ext4の場合）
sudo mkfs.ext4 /dev/mapper/mydata

# マウントポイントを作成してマウント
sudo mkdir -p /mnt/secure
sudo mount /dev/mapper/mydata /mnt/secure

# 動作確認
df -h /mnt/secure

4. アンマウントとコンテナを閉じる

使い終わったら逆の手順で安全に閉じます。

# アンマウード
sudo umount /mnt/secure

# コンテナを閉じる（これでデータが守られる状態に戻る）
sudo cryptsetup luksClose mydata

起動時に自動マウントする設定（/etc/crypttab + fstab）

データパーティションをサーバー起動時に自動でマウントしたい場合は、`/etc/crypttab` と `/etc/fstab` に設定を追記します。

1. デバイスのUUIDを確認する

# LUKSデバイスのUUIDを取得
sudo cryptsetup luksUUID /dev/sdb1
# 例: 12a3b456-7890-cdef-1234-56789abcdef0

2. /etc/crypttab への追記

# /etc/crypttab の書式
# マッピング名  デバイス(UUID形式推奨)  鍵ファイル(なければnone)  オプション
mydata  UUID=12a3b456-7890-cdef-1234-56789abcdef0  none  luks

`none` を指定すると起動時にコンソールでパスフレーズを求めます。リモートサーバーで自動起動させたい場合は鍵ファイルを使う必要があります（後述）。

3. /etc/fstab への追記

# /etc/fstab への追記
# /dev/mapper/mydata が crypttab で生成されることを前提とする
/dev/mapper/mydata  /mnt/secure  ext4  defaults  0  2

キースロットの管理：パスフレーズの追加・削除

LUKSの大きな強みがキースロットの管理です。担当者交代時にも元のパスフレーズを変更せずに安全に鍵を失効させられます。

# 新しいパスフレーズ（鍵スロット）を追加する
sudo cryptsetup luksAddKey /dev/sdb1

# 現在のスロット利用状況を確認する
sudo cryptsetup luksDump /dev/sdb1

# 特定スロット番号（例: スロット1）のパスフレーズを削除する
sudo cryptsetup luksKillSlot /dev/sdb1 1

退職者のスロットだけを削除して他の管理者の鍵を残す、という運用ができるのがLUKSが企業環境で重宝される理由のひとつです。

ヘッダーバックアップ：LUKSで絶対に忘れてはいけない作業

LUKSヘッダーが壊れると、パスフレーズが正しくてもデータにアクセスできなくなります。これはLUKS運用で最も見落とされがちなリスクです。

# ヘッダーをバックアップする（暗号化した直後に必ず実施）
sudo cryptsetup luksHeaderBackup /dev/sdb1 \
  --header-backup-file /root/luks-header-backup-sdb1.img

# バックアップファイルのアクセス権を厳重に制限する
sudo chmod 400 /root/luks-header-backup-sdb1.img

# バックアップから復元する（ヘッダー破損時）
sudo cryptsetup luksHeaderRestore /dev/sdb1 \
  --header-backup-file /root/luks-header-backup-sdb1.img

バックアップファイル自体は暗号化されていません。別のメディア（USBメモリ等）に安全に保管してください。

中小企業でも今日からできること

「サーバーにLUKSを設定するのは難しそう」と感じる場合、まず取り組みやすい場所から始めましょう。

・ノートPC・持ち出しデバイス: Ubuntuのインストール時に「ディスクを暗号化する」にチェックを入れるだけでLUKSが自動設定される。物理盗難リスクが最も高いデバイスから優先する
・バックアップ用外付けHDD: 内部データがバックアップされているメディアを暗号化しないのは矛盾。cryptsetupで暗号化してから運用する
・仮想マシンのデータディスク: VMの追加ディスクをLUKSで暗号化しておくと、VMイメージが流出しても中身が読まれない
・個人情報・機密ファイル専用パーティション: システム全体の暗号化が難しい既存サーバーでも、個人情報を保存するパーティションだけをLUKSにする部分適用は現実的

よくある誤解と注意点

【誤解1】「暗号化するとパフォーマンスが大幅に落ちる」

現代のCPUにはAES-NI（ハードウェアAES演算命令）が搭載されており、ソフトウェアによる暗号化の性能劣化はほぼ無視できるレベルです。`cryptsetup benchmark` コマンドで自環境の速度を確認できます。

# 暗号化アルゴリズムの速度ベンチマーク
sudo cryptsetup benchmark

【誤解2】「LUKSで暗号化すれば完全に安全」

LUKSが守るのは「電源オフ状態（ディスクを抜き取られた場合）」のリスクです。サーバーが稼働中でコンテナが開いた状態では、OSへのログインやrootへの権限昇格に成功した攻撃者はデータを読み取れます。LUKSはあくまで物理盗難・廃棄時の漏洩防止策であり、ネットワーク越しの攻撃への対策は別途必要です。

【誤解3】「パスフレーズを変えるだけで十分」

パスフレーズを変更しても、古いパスフレーズを知っている人物が事前にヘッダーをバックアップしていた場合は古いパスフレーズでアクセスできてしまいます。退職者対応として完全な鍵失効が必要な場合は、マスターキーの再生成（つまりデータの再暗号化）が必要です。

【注意】パスフレーズを忘れるとデータは永久に失われる

LUKSの暗号化は正しく機能しているからこそ「パスフレーズを忘れた場合のリカバリーは原理的に不可能」です。パスフレーズは必ずパスワードマネージャーや金庫に保管してください。また前述のヘッダーバックアップも合わせて安全な場所に保管することが重要です。

【注意】リモートサーバーでの自動起動には追加対策が必要

`/etc/crypttab` で `none` を指定した場合、起動時にコンソールでパスフレーズを要求します。リモートサーバーでは再起動のたびに物理接触が必要になるため、実運用には鍵ファイルや「Clevis + Tang」などのリモート解錠の仕組みを組み合わせる必要があります。

本記事のまとめ

LUKSは難しい技術ではありません。cryptsetupコマンド数本で設定でき、運用中のパフォーマンス影響もほぼありません。ノートPCや外付けHDDへの導入から始めて、徐々にサーバーのデータパーティションへと展開していくのが現実的なアプローチです。

LinuxのファイルシステムやパーミッションについてはLinuxの基礎から学びたい方は、姉妹サイトLinuxMaster.JPでも実践的なコマンド操作を解説しています。