vSphere仮想化基盤にTPMって必要なの？
はじめに
TPMという部品をご存じでしょうか？
正式名称は Trusted Platform Moduleです。
おそらくですが多くの vSphere ユーザの方はこれまでその存在を深く考えたことがないのではないかとおもいます。
確かにこれまでは、vSphere 6.7 以前は TPM という存在をvSphere 側で意識することはありませんでしたし、6.7以降であってもvSphereとしてのコアの機能とは 縁の薄い部品だったと思います。
しかしながら、今後はユーザ側もある程度の TPM に関しての知識が要求されるかと思われます。主な理由は以下の２つです。
- Windows11で TPM が必須
- vSphere 8 で TPM 1.2 が非サポート
本投稿は、Windows11を実行する仮想マシンのデプロイや、vSphere 8 へのアップグレードというイベントに備えて、TPMがどういった機能を提供するものなのかを簡単にご説明することを目的としています。
Trusted Platform Module とは
Trusted Platform Moduleとは、端末認証を安全に行うために必要な機能が搭載されているICチップです。マザーボード上に搭載されています。具体的には以下の機能を持ちます。- RSA暗号の演算・鍵生成・格納- 乱数生成- ハッシュ演算・ハッシュ値保管など端末認証での利用を想定しているため、基本的にマザーボードに一度取り付けたら外すことは二度とありません。（例外もあります）そのため、マザーボードを交換する場合はTPMもセットで交換します。Windows 11 ではTPMが必須とされたことで、TPMという言葉を聞いたことがある、という方は多いかと思います。逆にいえばそれまでのWindowsにおいては必須とされていませんでしたし、物理サーバ側としてもオプションパーツとしての位置づけですので、上位のOSやアプリから要求されなければ必ずしも必要ではありません。vSphere環境においても、お客様が明示的にTPMを利用したいと希望されていないのであれば必須ではありません。（ただしTPMがないことで一部の vSphere のセキュリティ機能が利用不可、もしくは機能低下します）なお、TPMはあくまでもセキュリティ技術で必要となる機能を提供するのみであり、ただ取り付けておくだけでセキュリティが向上するわけではありません。OSやアプリ側でTPMを利用するセキュリティ機能がなければ意味がありません。
Trusted Platform Module の利用例：BitLocker
TPMは主に端末認証を目的としたセキュリティ技術で必要とされます。
TPMを利用した代表的なセキュリティ技術といえば、Windows OS の持つ BitLocker があります。
「BitLockerってDrive暗号化の技術でしょ？端末認証じゃないじゃん」
確かにBitlocker自体はDriveを暗号化することで紛失や盗難といったリスクを軽減する効果がありますが、
暗号化されたデータを誰でも復号できてしまっては意味がありません。
暗号化されたデータにアクセスできるのは復号キーを持つものだけです。
そしてその復号キーはマザーボード上のTPMの中のSealed Storage（暗号化された保存領域）に格納されているのです。
したがって、復号キーをもつTPMを搭載したマザーボードでしか BitLockerで暗号化されたDriveへのアクセスはできませんので、端末認証の機能があるといえます。
Trusted Platform Module の利用例：Intel TXT と ESXi構成の暗号化
vSphereでどのようにTPMが利用されるのかを紹介します。
ここまでの内容でTPMには端末認証を行うための機能を提供しているとご説明しました。
TPMを利用することで実現できる端末認証とは、単純にその端末を”所持している”という事実の確認だけにとどまりません。
その端末が正しい設定やFWで実行されているかどうか、という点も確認することができます。
もしFirmwareやOSを改ざんされて悪意のあるコードをが実行されてしまったら、Bitlockerで暗号化をしていても安全とは言えません。
また、そういった改ざんされたコードの実行を許可するような脆弱な設定を強制されてしまうような場合もあります。
vSphereで利用されるIntel TXTはTPMを利用することで、BIOS設定やFirmwareが改ざんされていないことを確認します。
TPMにはPCR（Platform Configuration Register）と呼ばれる保存領域があり、OS起動で必要となるコードやBIOS設定などがハッシュ化されたものが記録されます。
このハッシュ値を蓄積し、OS起動前の段階で既知の正しいハッシュ値と比較することで悪意あるコードや不正な設定を検知することができ、改ざんされたコードの実行を防ぐことができるという機能です。
ただしこれだけでは完ぺきではありません。悪意ある攻撃者がTPM自体を暗号化した場合は、ハッシュ値自体を改ざんできるため、改ざんされたコードの実行を許してしまいます（下図）。
上記の攻撃を防ぐためには、Sealed Storage の活用が必要だと述べられています。Sealed Storage は、BitLocker で出てきた復号キーを保管するための暗号化された保存領域です。上記の攻撃では、仮想的にTPMを作り出すことでTPMの動作を再現していますが、物理TPMに保存（暗号化）されている復号キーまでは再現できません。そのため、BitLockerのような機能があれば、Intel TXT を補完することができます。vSphereでBitLockerに相当する機能として、ESXi構成の暗号化があります。Securing the ESXi Configurationこの機能はBitLockerと同じように、ESXi の OS領域を暗号化し、復号キーをTPMのSealed Storageに保存することで正しい端末で実行されていることを保証します。このように、vSphere は TPM を活用する Intel TXT と ESXi 構成の暗号化の2つの機能によって安全に起動することができます。
SecureBoot との違い
安全に起動するだけなら、SecureBootでよいのではないか？ SecureBootと何が違うのか？という疑問もあると思います。
SecureBootは平たく説明すると実行されるソフトウェアを逐次検証し、信頼された安全なコードのみを実行する仕組みです。
確かに、TPMを利用したIntel TXTにおいても、実行されるコードを検証したりと、共通する部分はありました。
しかし両者の違いは明確に存在します。
TPMを利用した技術は基本的に端末認証をベースとしていますので、その根幹はハードウェア検証です。
一方でSecureBootは署名済みのコード検証をベースとしており、その目的はソフトウェアの検証です。
平たくいってしまえば、ソフトウェアの安全性を確認しているのがSecureBoot、
ソフトウェアが実行されるハードウェアを確認しているのが TPM を利用したセキュリティ技術と考えてもよいかもしれません。（かなり乱暴ですが）
カバーしている領域が異なりますので、両者を併用することが好ましいです。しかしながら、セキュリティ対策は常にそのリスクとコストの天秤で判断されなくてはなりませんので、もし運用管理負荷や知識不足などが理由でそういった機能の採用を見送っているユーザにおいても、SecureBootだけは有効化しておいた方が良いです。（今回のテーマはTPMですがこれだけは言っておきたい）
昨今ESXiを標的とした攻撃は増えており、つい最近もSecureBootが無効化されているESXiを狙った攻撃も報告されています。
https://kb.vmware.com/s/article/89619
SecureBootを採用しないリスクは大きく、またライセンス/ハードウェア/運用コストもかかりませんので是非積極的に採用いただきたい機能です。
TPMを利用しているその他の機能
・vCenterによるTPM検証（Host Attestation）
各TPMチップは固有のPrivate Keyとそれに対応するPublic Key/Certificateを持っています。
vCenterはESXiが起動されるたびに、ESXi経由でTPMを検証することで正しいハードウェアで実行されていることを確認しています。
・Key Persistence（暗号化キーの永続化）
vSphere環境における、仮想マシンの暗号化や、vSANデータストアの暗号化には 外部のKey Provider（KMS）が必要です。
ESXiはKMSから提供された暗号化キーを利用して仮想マシンやデータストアの暗号化を行いますので、Key Provider がいない状態では、暗号化キーを受け取ることができません。vSphere7U2未満のバージョンでは KeyProvider障害時にESXiが暗号化された仮想マシンを起動できなかったり、vSAN データストアにアクセスできなくなりましたが、vSphere 7U2以降では暗号化キーをTPMに保存することでKeyProvider不在時にも暗号化/復号を実施できるようになりました。（ただしデフォルトでは無効）
TPMのバージョンとvSphere 8 での対応
TPMは1.2と2.0（2.0 V3 含む）の2種類がありますが、冒頭で述べた通りvSphere 8 ではTPM2.0しかサポートしていません（ReleaseNote参照）。そのため、今後購入するサーバにTPMを含む場合は、TPM2.0（2.0 V3 含む）にしておく方が良いです。
VMware vSphere 8.0 Release Notes
https://docs.vmware.com/en/VMware-vSphere/8.0/rn/vmware-vsphere-80-release-notes/index.html
なお、既存で TPM 1.2 を利用している vSphere 7 までの環境であっても、vSphere 8 にアップグレードすることは可能です。ただし、vSphere 8 へのアップグレード後は TPM 1.2 を利用することはできません。
しかしながら、vSphere による TPM 利用はそもそも TPM2.0を想定しているものが多いです。そのため、Intel TXT が使えなくなるくらいの影響になると思われます。
TPM 1.2 で使える主な機能
- Intel TXT
TPM 2.0 で使える主な機能
- Intel TXT
- キーの永続化（Key Persistence）
- vCenterによるTPM検証（Host Attestation）
- ホスト構成の暗号化
- Trusted Authority / Trusted Key Provider
Windows11 をデプロイする場合について
Windows11 では TPM が必須となっています。これは仮想化環境でも同様です。したがって、仮想マシン上にWindows11をGuest OS としてインストールする場合は、vTPMを仮想ハードウェアに追加する必要があります。「まずい！ウチのサーバには TPM をインストールしてないから vTPM も利用できない！」と思われた方、ご安心ください。vTPM には 物理のTPMチップは不要です。そのことは以下の VMware Doc にも明記されています。A vTPM does not require a physical Trusted Platform Module (TPM) 2.0 chip to be present on the ESXi hostしかしながら、代わりにKey Provider が必要となりますのでその点はご留意ください。
TPM Version と利用状況の確認方法
最後に現在利用している TPM の Version と Intel TXT 利用状況の確認方法のサンプルを載せておきます。
vSphere Client から確認する方法
一つ目の方法は vSphere Clientから確認する方法です。この方法で TPM のバージョンと Intel TXT の利用状況を一望できます。
ただし、この確認方法は vSphere の バージョンに依存し、古いバージョンでは表示がありません。（下図サンプルでも Intel TXT 利用有無の列がない）
また、TPM を利用しているけれどもハードウェア側で無効化されている場合と、そもそも搭載されていない場合を区別することができません。
サーバ管理ツールや BIOS 画面を利用した方法
2つ目の方法は、サーバ側の管理ツールを利用する方法です。この方法はサーバベンダやモデルに大きく依存しますが、より確実に確認することが可能です。
管理ツールが搭載されていない場合でも BIOS 画面から確認できると思います。
以下は、Dell 社の PowerEdge に搭載される iDRAC 9 を利用した場合の確認方法です。
その他のベンダやモデルでの確認方法については、サーバベンダに問い合わせれば教えてくれるはずです。
ESXi のCLIを利用した方法
以下のコマンドでTPM有無とバージョンを確認できます。
[root@localhost:~] vsish -e get /hardware/tpm/present
1 ####0の場合はTPMなし。1の場合はTPMあり
[root@localhost:~] vsish -e get /hardware/tpm/version
2 #### 1の場合はTPM 1.2、2の場合はTPM 2.0
[root@localhost:~] esxcli hardware trustedboot getDrtm Enabled: true #### Intel TXT が有効な場合はtrue
Tpm Present: true #### TPMがある場合はtrue
[root@localhost:~] vmkload_mod -l |grep tpm
tpmdriver 2 120 #### TPMがない場合は出力なし
[root@localhost:~] zcat /var/log/boot.gz | grep -i -E "tpm
#### 出力は省略。Boot時のTPM関連情報を確認。
TPMを利用したホスト構成暗号化の確認（TPMあり）
# cd /tmp #### /tmpにしておかないとあとで解凍ファイルの削除ができない
# tar xvzf /bootbank/state.tgz
local.tgz.ve
encryption.info
# head encryption.info
.encoding = "UTF-8"
includeKeyCache = "FALSE"
mode = "TPM"
t.E4F0786E472D4ED08C68A79A61DC91C7 = "public=......................
TPMを利用したホスト構成暗号化の確認（TPMなし ※難読化のみ）
# cd /tmp #### /tmpにしておかないとあとで解凍ファイルの削除ができない
# tar xvzf /bootbank/state.tgz
local.tgz.ve
encryption.info
#head encryption.info
.encoding = "UTF-8"
includeKeyCache = "FALSE"
mode = "NONE"
ConfigEncData = "keyId=An1gzRk1TDqkjMlMjXbK0A%3d%3d:data1=DcB3M7XpR5SCCX89ybAGBw%3d%3d:data2=OjHEDZaoRbq7z/NHQTuJjQ%3d%3d:version=1"
リカバリキーの確認（TPMあり）
# esxcli system settings encryption recovery listRecovery ID Key--------------------------------------------------- ---{XXXXXXX-YYYY-ZZZZ-AAAA-123456789AB} 111111-222222-333333-444444-555555-666666-777777-888888-999999-AAAAAA-BBBBBB-CCCCCC-DDDDDD-EEEEEE-FFFFFF-111111
リカバリキーの確認（TPMなし ※暗号化はしていないため不要）
# esxcli system settings encryption recovery listError while communicating with daemon.
投稿は以上です。
今回の内容が日々の業務にお役に立てば幸いです。
コメント
コメントを投稿