Show Table of Contents
4.10. ポリシーベースの複号を使用して暗号化ボリュームの自動アンロックの設定
ポリシーベースの複号 (PBD)は、ユーザーパスワード、TPM (Trusted Platform Module) デバイス、システムに接続する PKCS#11 デバイス (たとえばスマートカード) のようなさまざま方法を使用して、もしくはネットワークサーバーを活用して、物理マシンおよび仮想マシンでハードドライブの暗号化 root ボリュームおよびセカンダリーボリュームをアンロックできる一連のテクノロジーです。
テクノロジーとして PBD を使用すると、さまざまな方法で同じボリュームのロックを解除する機能を作成するポリシーに、さまざまなアンロック方法を組み合わせることができます。Red Hat Enterprise Linux における PBD の現在の実装は、Clevis フレームワークと、ピンと呼ばれるプラグインから構成されます。各ピンは、個別のアンロック機能を提供します。現在唯一利用できる 2 つのピンは、TPM またなネットワークサーバーでボリュームをアンロックできます。
NBDE (Network Bound Disc Encryption) は、特定のネットワークサーバーに暗号化ボリュームをバインドできるようにする PBD テクノロジーのサブカテゴリーです。NBDE の現在の実装には、Tang サーバーと、Tang サーバー用の Clevis ピンが含まれます。
4.10.1. NBDE (Network-Bound Disk Encryption)
NBDE (Network-Bound Disk Encryption) を使用すると、システムを再起動する際にパスワードを手動で入力せずに、物理マシンおよび仮想マシンのハードドライブの root ボリュームを暗号化できるようになります
Red Hat Enterprise Linux 7 では、NBDE は、以下のコンポーネントおよびテクノロジーにより実装されます。
図4.2 Clevis および Tang を使用する NBDE (Network-Bound Disk Encryption)
Tang は、ネットワークのプレゼンスにデータをバインドするためのものです。セキュリティーが保護された特定のネットワークにシステムをバインドする際に利用可能なデータを含めるようにします。Tang はステートレスで、TLS または認証は必要ありません。サーバーが暗号鍵をすべて保存し、これまでに使用されている各鍵に関する知識を有しているエスクローベースのソリューションとは異なり、Tang はクライアントの鍵と相互作用することはないため、クライアントから識別情報を得ることはありません。
Clevis は、自動化された復号用のプラグイン可能なフレームワークです。NBDE では、Clevis は、LUKS ボリュームの自動アンロックを提供します。clevis パッケージは、クライアントで使用される機能を提供します。
Clevis ピン は、Clevis フレームワークへのプラグインです。このようなピンの 1 つは、NBDE サーバー (Tang) との相互作用を実装するプラグインです。
Clevis および Tang は一般的なクライアントおよびサーバーの機能で、ネットワークがバインドされた暗号化を提供します。Clevis および Tang は、Red Hat Enterprise Linux 7 で NBDE を実現するために、LUKS と組み合わせて、root および非 root のストレージボリュームの暗号化および複号に使用されています。
クライアントおよびサーバーのコンポーネントはともに José ライブラリーを使用して、暗号化および複号の操作を実行します。
NBDE のプロビジョニングを開始すると、Tang サーバーの Clevis ピンは、Tang サーバーの、アドバタイズされている非対称鍵の一覧を取得します。もしくは、鍵は非対称であるため、Tang の公開鍵の一覧を帯域外に配布して、クライアントが Tang サーバーにアクセスしなくても動作できるようにできます。このモードは オフラインプロビジョニング と呼ばれます。
Tang 用のClevis ピンは、公開鍵のいずれかを使用して、固有で、暗号論的に強力な暗号鍵を生成します。この鍵を使用してデータを暗号化すると、この鍵は破棄されます。Clevis クライアントは、使いやすい場所でこのプロビジョニング操作で生成した状態を保存する必要があります。データを暗号化するこのプロセスは プロビジョニング手順 です。NBDE のプロビジョニング状態 は、luksmeta パッケージを使用する LUKS ヘッダーに保存されます。
クライアントがそのデータにアクセスする準備ができると、プロビジョニング手順で生成したメタデータをロードし、暗号鍵を戻すために応答します。このプロセスは 復元手順 です。
NBDE では、Clevis は、ピンを使用して LUKS ボリュームをバインドしているため、自動的にロックが解除されます。バインドプロセスが正常に終了すると、提供されている Dracut アンロックを使用してディスクをアンロックできます。
4.10.2. 暗号化クライアント (Clevis) のインストール
Clevis のプラグイン可能なフレームワークとピンを、暗号化したボリューム (クライアント) を使用するマシンにインストールするには、
root で以下のコマンドを実行します。
~]# yum install clevis
データを複号するには、
clevis decrypt コマンドを実行して、暗号文 (JWE) を提供します。
~]$ clevis decrypt < JWE > PLAINTEXT
詳細は、組み込みの CLI ヘルプを参照してください。
~]$clevisUsage: clevis COMMAND [OPTIONS] clevis decrypt Decrypts using the policy defined at encryption time clevis encrypt http Encrypts using a REST HTTP escrow server policy clevis encrypt sss Encrypts using a Shamir's Secret Sharing policy clevis encrypt tang Encrypts using a Tang binding server policy clevis encrypt tpm2 Encrypts using a TPM2.0 chip binding policy ~]$clevis decryptUsage: clevis decrypt < JWE > PLAINTEXT Decrypts using the policy defined at encryption time ~]$clevis encrypt tangUsage: clevis encrypt tang CONFIG < PLAINTEXT > JWE Encrypts using a Tang binding server policy This command uses the following configuration properties: url: <string> The base URL of the Tang server (REQUIRED) thp: <string> The thumbprint of a trusted signing key adv: <string> A filename containing a trusted advertisement adv: <object> A trusted advertisement (raw JSON) Obtaining the thumbprint of a trusted signing key is easy. If you have access to the Tang server's database directory, simply do: $ jose jwk thp -i $DBDIR/$SIG.jwk Alternatively, if you have certainty that your network connection is not compromised (not likely), you can download the advertisement yourself using: $ curl -f $URL/adv > adv.jws
4.10.3. Tang サーバーのデプロイメント
tang パッケージおよびその依存関係をインストールするには、
root で以下のコマンドを実行します。
~]# yum install tang
systemd を使用して
tangd サービスを有効にして起動します。
~]# systemctl enable tangd.socket --now
Created symlink from /etc/systemd/system/multi-user.target.wants/tangd.socket to /usr/lib/systemd/system/tangd.socket.tangd は、systemd ソケットアクティベーションメカニズムを使用しているため、最初に接続するとすぐにサーバーが起動します。最初の起動時に、新しい一組の暗号鍵が自動的に生成されます。
手動による鍵生成などの暗号化操作を実行するには、
jose ユーティリティーを使用します。詳細は、jose -h コマンドを実行するか、man ページの jose(1) を参照してください。
例4.4 Tang 鍵の変更
鍵を定期的に変更することが重要です。鍵を変更するのに適した間隔は、アプリケーション、鍵サイズ、および組織のポリシーによって異なります。一般的な推奨事項は 「Cryptographic Key Length Recommendation」 ページを参照してください。
鍵を変更するには、鍵データベースディレクトリー (通常は
/var/db/tang) に新しい鍵を生成するところから始めます。たとえば、以下のコマンドを使用して、新しい署名を作成し、鍵を交換します。
~]#DB=/var/db/tang~]#jose jwk gen -i '{"alg":"ES512"}' -o $DB/new_sig.jwk~]#jose jwk gen -i '{"alg":"ECMR"}' -o $DB/new_exc.jwk
アドバタイズメントから見えなくなるように、古い鍵の名前の先頭に
. を付けます。以下の例のファイル名は、鍵データベースディレクトリーに実在する固有のファイル名とは異なります。
~]#mv $DB/old_sig.jwk $DB/.old_sig.jwk~]#mv $DB/old_exc.jwk $DB/.old_exc.jwk
Tang は、直ちにすべての変更を適用します。再起動は必要ありません。
この時点で、新しいクライアントバインディングは新しい鍵を選択し、以前のクライアントは古い鍵を使用し続けます。すべてのクライアントが新しい鍵を使用することを確認すると、古い鍵を削除できます。
警告
クライアントが使用している最中に古い鍵を削除すると、データが失われる場合があります。
Tang は、通信にポート 80 を使用します。このポートは、Web サーバーにも広く使用されています。Tang のポート番号を変更するには、標準の
systemd メカニズムを使用して tangd.socket ユニットファイルを上書きします。詳細は『Red Hat Enterprise Linux 7 システム管理者のガイド』の 「systemd のユニットファイルの作成および変更」 を参照してください。
4.10.3.1. 高可用性システムのデプロイメント
Tang は、高可用性デプロイメント構築する方法を 2 つ提供します。
- クライアントの冗長性 (推奨)クライアントは、複数の Tang サーバーにバインドする機能を使用して設定する必要があります。この手順では、各 Tang サーバーには独自の鍵があり、クライアントは、このサーバーのサブセットに接続することで複号できるようになります。Clevis では、以前からこのワークフローを
sssプラグインによりサポートしています。この設定の詳細は、以下の man ページを参照してください。tang(8)の高可用性 (High Availability) セクションclevis(1)のシャミアの秘密共有 (Shamir's Secret Sharing) セクションclevis-encrypt-sss(1)
Red Hat では、高可用性デプロイメントにこの方法を使用することを推奨します。 - 鍵共有冗長性のために、Tang のインスタンスは複数デプロイできます。2 つ目以降のインスタンスを設定するには、tang パッケージをインストールし、SHH で
rsyncを使用して、重要なディレクトリーを新しいホストにコピーします。鍵を共有すると、重大な不正アクセスのリスクを増やし、別の自動化インフラストラクチャーが必要となるため、Red Hat はこの方法を推奨しません。
4.10.4. Tang を使用する NBDE システムへの暗号化クライアントのデプロイメント
前提条件
- Clevis フレームワークがインストールされている。「暗号化クライアント (Clevis) のインストール」 を参照してください。
- Tang サーバーが利用可能である。「Tang サーバーのデプロイメント」 を参照してください。
手順
Clevis 暗号化クライアントを Tang サーバーにバインドするには、
clevis encrypt tang サブコマンドを使用します。
~]$ clevis encrypt tang '{"url":"http://tang.srv"}' < PLAINTEXT > JWE
The advertisement contains the following signing keys:
_OsIk0T-E2l6qjfdDiwVmidoZjA
Do you wish to trust these keys? [ynYN] y
前の例の http://tang.srv URL を、tang がインストールされているサーバーの URL にぢます。JWE 出力ファイルには、暗号化した暗号文が含まれます。この暗号文は、PLAINTEXT 入力ファイルから読み込まれます。
データを複号するには、
clevis decrypt コマンドを実行して、暗号文 (JWE) を提供します。
~]$ clevis decrypt < JWE > PLAINTEXT
詳細は、man ページの
clevis-encrypt-tang(1) か、組み込みの CLI ヘルプを参照してください。
~]$clevisUsage: clevis COMMAND [OPTIONS] clevis decrypt Decrypts using the policy defined at encryption time clevis encrypt http Encrypts using a REST HTTP escrow server policy clevis encrypt sss Encrypts using a Shamir's Secret Sharing policy clevis encrypt tang Encrypts using a Tang binding server policy clevis encrypt tang Encrypts using a Tang binding server policy clevis luks bind Binds a LUKSv1 device using the specified policy clevis luks unlock Unlocks a LUKSv1 volume ~]$clevis decryptUsage: clevis decrypt < JWE > PLAINTEXT Decrypts using the policy defined at encryption time ~]$clevis encrypt tangUsage: clevis encrypt tang CONFIG < PLAINTEXT > JWE Encrypts using a Tang binding server policy This command uses the following configuration properties: url: <string> The base URL of the Tang server (REQUIRED) thp: <string> The thumbprint of a trusted signing key adv: <string> A filename containing a trusted advertisement adv: <object> A trusted advertisement (raw JSON) Obtaining the thumbprint of a trusted signing key is easy. If you have access to the Tang server's database directory, simply do: $ jose jwk thp -i $DBDIR/$SIG.jwk Alternatively, if you have certainty that your network connection is not compromised (not likely), you can download the advertisement yourself using: $ curl -f $URL/adv > adv.jws
4.10.5. TPM 2.0 ポリシーを使用した暗号化クライアントのデプロイメント
64 ビットの Intel または 64 ビットの AMD アーキテクチャーを使用するシステムは、Trusted Platform Module 2.0 (TPM 2.0) チップを使用して暗号化するクライアントをデプロイするために、JSON 設定オブジェクトフォーマットの引数のみが使用されている
clevis encrypt tpm2 サブコマンドを使用します。
~]$ clevis encrypt tpm2 '{}' < PLAINTEXT > JWE
別の階層、ハッシュ、および鍵アルゴリズムを選択するには、以下のように、設定プロパティーを指定します。
~]$ clevis encrypt tpm2 '{"hash":"sha1","key":"rsa"}' < PLAINTEXT > JWE
データを復号するには、暗号文 (JWE) を提供します。
~]$ clevis decrypt < JWE > PLAINTEXT
ピンは、PCR (Platform Configuration Registers) 状態へのデータのシーリングもサポートします。このように、PCP ハッシュ値が、シーリング時に使用したポリシーと一致する場合にのみ、データのシーリングを解除できます。
たとえば、SHA1 バンクに対して、インデックス 0 および 1 の PCR にデータをシールするには、以下を行います。
~]$ clevis encrypt tpm2 '{"pcr_bank":"sha1","pcr_ids":"0,1"}' < PLAINTEXT > JWE
詳細と、可能な設定プロパティーの一覧は、man ページ
clevis-encrypt-tpm2(1) を参照してください。
4.10.6. root ボリュームの手動登録の設定
既存の LUKS 暗号化 root ボリュームを自動的にアンロックするには、clevis-luks サブパッケージをインストールし、
clevis luks bind コマンドを使用して Tang サーバーにボリュームをバインドします。
~]# yum install clevis-luks~]# clevis luks bind -d /dev/sda tang '{"url":"http://tang.srv"}'
The advertisement contains the following signing keys:
_OsIk0T-E2l6qjfdDiwVmidoZjA
Do you wish to trust these keys? [ynYN] y
You are about to initialize a LUKS device for metadata storage.
Attempting to initialize it may result in data loss if data was
already written into the LUKS header gap in a different format.
A backup is advised before initialization is performed.
Do you wish to initialize /dev/sda? [yn] y
Enter existing LUKS password:
このコマンドは、以下の 4 つの手順を実行します。
- LUKS マスター鍵と同じエントロピーを使用して、新しい鍵を作成します。
- Clevis で新しい鍵を暗号化します。
- LUKSMeta を使用して LUKS ヘッダーに Clevis JWE オブジェクトを保存します。
- LUKS を使用するために新しい鍵を有効にします。
このディスクは、既存のパスワードと Clevis ポリシーを使用してアンロックできるようになりました。詳細は、man ページの
clevis-luks-bind(1) を参照してください。
注記
バインド手順では、少なくとも 1 つの空き LUKS パスワードスロットがあることが前提となっています。
clevis luks bind コマンドは、そのスロットを 1 つ取ります。
Clevis JWE オブジェクトが LUKS ヘッダーに適切に配置されていることを確認するには、
luksmeta show コマンドを使用します。
~]# luksmeta show -d /dev/sda
0 active empty
1 active cb6e8904-81ff-40da-a84a-07ab9ab5715e
2 inactive empty
3 inactive empty
4 inactive empty
5 inactive empty
6 inactive empty
7 inactive empty
システムの起動プロセスの初期段階でディスクバインディングを処理するようにするには、インストール済みのシステムで以下のコマンドを実行します。
~]#yum install clevis-dracut~]#dracut -f
重要
(DHCP を使用しない) 静的な IP 設定を持つクライアントに NBDE を使用するには、以下のように、手動でネットワーク設定を dracut ツールに渡します。
~]# dracut -f --kernel-cmdline "ip=192.0.2.10 netmask=255.255.255.0 gateway=192.0.2.1 nameserver=192.0.2.45"
もしくは、以下のように、静的ネットワーク情報を使用して
/etc/dracut.conf.d/ ディレクトリーに .conf ファイルを作成します。
~]# cat /etc/dracut.conf.d/static_ip.conf
kernel_cmdline="ip= 10.0.0.103 netmask=255.255.252.0 gateway=10.0.0.1 nameserver=10.0.0.1"
初期 RAM ディスクイメージを再生成します。
~]# dracut -f
詳細は man ページの
dracut.cmdline(7) を参照してください。
4.10.7. キックスタートを使用した自動登録の設定
Clevis は、登録プロセスを完全に自動化するために、キックスタートと統合できます。
- root パーティションが、一時的なパスワードを使用して、LUKS 暗号化を有効にしているディスクを分割するように、キックスタートに指示します。パスワードは、登録プロセスに使用するための一時的なものです。
part /boot --fstype="xfs" --ondisk=vda --size=256 part / --fstype="xfs" --ondisk=vda --grow --encrypted --passphrase=temppass
- 関連する Clevis パッケージを
%packagesセクションに追加して、インストールします。%packages clevis-dracut %end
clevis luks bindを呼び出して、%postセクションのバインディングを実行します。その後、一時パスワードを削除します。%post clevis luks bind -f -k- -d /dev/vda2 \ tang '{"url":"http://tang.srv","thp":"_OsIk0T-E2l6qjfdDiwVmidoZjA"}' \ <<< "temppass" cryptsetup luksRemoveKey /dev/vda2 - <<< "temppass" %end上記の例では、Tang サーバーをバインディング設定の一部として Tang サーバーで信頼するサムプリントを指定して、バインディングを完全に非対話にできます。Tang サーバーの代わりに TPM 2.0 ポリシーを使用する場合は、類似の手順を使用できます。
キックスタートインストールの詳細は 『Red Hat Enterprise Linux 7 インストールガイド』 を参照してください。Linux の LUKS (Unified Key Setup-on-disk-format) の詳細は 「LUKS のディスク暗号化の使用」 を参照してください。
4.10.8. リムーバブルストレージデバイスの自動アンロックの設定
USB ドライブなど、LUKS で暗号化したリムーバブルストレージデバイスを自動的にアンロックするには、clevis-udisks2 パッケージをインストールします。
~]# yum install clevis-udisks2
システムを再起動し、「root ボリュームの手動登録の設定」 の説明通りに、
clevis luks bind コマンドを使用したバインディング手順を実行します。以下に例を示します。
~]# clevis luks bind -d /dev/sdb1 tang '{"url":"http://tang.srv"}'
LUKS で暗号化したリムーバブルデバイスは、GNOME デスクトップセッションで自動的にアンロックできるようになりました。Clevis ポリシーにバインドするデバイスは、
clevis luks unlock コマンドでアンロックできます。
~]# clevis luks unlock -d /dev/sdb1
Tang サーバーの代わりに TPM 2.0 ポリシーを使用する場合は、類似の手順を使用できます。
4.10.9. 起動時に非 root ボリュームの自動アンロックの設定
LUKS 暗号化した非 root ボリュームをアンロックするのに NBDE を使用するには、以下の手順を実行します。
- clevis-systemd パッケージをインストールします。
~]#
yum install clevis-systemd - Clevis のアンロックサービスを有効にします。
~]#
systemctl enable clevis-luks-askpass.pathCreated symlink from /etc/systemd/system/remote-fs.target.wants/clevis-luks-askpass.path to /usr/lib/systemd/system/clevis-luks-askpass.path. - 「root ボリュームの手動登録の設定」 の説明通りに
clevis luks bindコマンドを使用してバインド手順を実行します。 - システムの起動時に暗号化したブロックデバイスを設定するには、
_netdevオプションに相当する行を/etc/crypttab設定ファイルに追加します。詳細は man ページのcrypttab(5)を参照してください。 /etc/fstabファイルでアクセス可能なファイルシステムの一覧にボリュームを追加します。また、この設定ファイルで_netdevオプションを使用します。詳細は man ページのfstab(5)を参照してください。
4.10.10. NBDE ネットワークで仮想マシンのデプロイメント
clevis luks bind コマンドは、LUKS マスターキーを変更しません。これは、仮想マシンまたはクラウド環境で使用するためにLUKS で暗号化したイメージを作成する場合に、このイメージを実行するすべてのインスタンスがマスター鍵を共有することを意味します。これはセキュリティーに関して大きな問題があるため、常に回避する必要があります。
これは、Clevis の制限ではなく、LUKS の設計原理です。クラウドに暗号化された root ボリュームが必要な場合は、クラウドの Red Hat Enterprise Linux の各インスタンスに対してインストールプロセスを実行できるようにする (通常はキックスタートを使用) 必要があります。このイメージは、LUKS マスターキーを共有しなければ共有できません。
仮想化環境に自動アンロックをデプロイする場合は、キックスタートファイルを使用して lorax、virt-install などのシステムを使用すること (「キックスタートを使用した自動登録の設定」 を参照)、または暗号化した各仮想マシンに固有のマスター鍵があるようにする自動プロビジョニングツールを使用することを Red Hat は強く推奨します。
4.10.11. NBDE を使用してクラウド環境に自動的に登録可能な VM イメージの構築
自動登録が可能な、暗号化されたイメージをクラウド環境にデプロイすると、特有の課題が発生する可能性があります。その他の仮想化環境と同様、LUKS マスターキーを共有しないように、1 つのイメージから起動するインスタンスの数を減らすことが推奨されます。
したがって、ベストプラクティスは、どのパブリックリポジトリーでも共有されず、限られた数のインスタンスをデプロイするための基盤を提供する、カスタマイズされたイメージを作成することです。作成するインスタンスの正確な数は、デプロイメントのセキュリティポリシーによって定義され、LUKS マスターキーの攻撃ベクトルに関連するリスク許容度に基づいて決定する必要があります。
LUKS に対応する自動デプロイメントを構築するには、Lorax、virt-install などのシステムとキックスタートファイルを一緒に使用し、イメージ構築プロセス中にマスターキーの一意性を確保する必要があります。
クラウド環境では、ここで検討する 2 つの Tang サーバーデプロイメントオプションが利用できます。まず、クラウド環境そのものに Tang サーバーをデプロイできます。もしくは、2 つのインフラストラクチャー間で VPN リンクを使用した独立したインフラストラクチャーで、クラウドの外に Tang サーバーをデプロイできます。
クラウドに Tang をネイティブにデプロイすると、簡単にデプロイできます。ただし、別のシステムの暗号文のデータ永続化層でインフラストラクチャーを共有します。Tang サーバーの秘密鍵および Clevis メタデータは、同じ物理ディスクに保存できる場合があります。この物理ディスクでは、暗号文データへのいかなる不正アクセスが可能になります。
重要
このため、Red Hat は、データを保存する場所と、Tang が実行しているシステムの間に物理的な分離を維持することを強く推奨します。クラウドと Tang サーバーを分離することで、Tang サーバーの秘密鍵が、Clevis メタデータと誤って結合することがないようにします。また、これは、クラウドインフラストラクチャーが危険にさらされている場合に、Tang サーバーのローカル制御を提供します。
4.10.12. その他のリソース
詳細は、以下の man ページを参照してください。
tang(8)clevis(1)jose(1)clevis-luks-unlockers(1)tang-nagios(1)
Where did the comment section go?
Red Hat's documentation publication system recently went through an upgrade to enable speedier, more mobile-friendly content. We decided to re-evaluate our commenting platform to ensure that it meets your expectations and serves as an optimal feedback mechanism. During this redesign, we invite your input on providing feedback on Red Hat documentation via the discussion platform.