vSphere セキュリティ：Lockdown Mode、証明書管理、ESXi ホストのハードニング実践 – ITFROMZERO

Table of Contents

Management Plane：仮想化システムの「アキレス腱」

多くの人は、vCenter をインストールし、vMotion の設定がスムーズに完了すれば、枕を高くして眠れると考えがちです。しかし実際には、デフォルト設定のままの vSphere クラスターは、LockBit のようなランサムウェアにとって格好の餌食です。これらは .vmdk ファイルを直接標的にし、わずか数分でインフラ全体を暗号化します。管理プレーン（Management Plane）が乗っ取りられると、ハッカーは個々の仮想マシンを壊す必要すらなく、ホストレベルでストレージを完全に消去できてしまうのです。

私が運用している 8 台 of ESXi ホストクラスターでは、かつてオフィスの全 IP 範囲に対して SSH が「無制限に」開放されていた時期がありました。経理部門の PC が 1 台マルウェアに感染するだけで、攻撃者は即座にホストの root パスワードをブルートフォース攻撃で割り出すことができてしまいます。以下に紹介するのは、システムを「無防備」な状態から厳格なハードニング基準へと移行させるために、私が実際に適用したプロセスです。

セキュリティレベルの比較：デフォルト vs ハードニング済み

ダッシュボードに真っ赤な警告が出るまで待ってはいけません。システムの 2 つの状態の違いを見てみましょう。

デフォルトシステム： root でどこからでも SSH ログインが可能。ファイアウォールはサブネット全体に開放。証明書は自己署名（Self-signed）で、ブラウザには常に警告が表示され、なりすまし攻撃に脆弱です。
ハードニング済みシステム： SSH は無効化されるか、管理者用 IP（踏み台ホスト）のみに制限。Lockdown Mode を有効化し、制御権を vCenter に集約。すべての接続で正規の CA 証明書を使用し、100% 標準化されています。

セキュリティ強化レベルの検討

問題は「どこまで厳しくすべきか」ということです。やりすぎると、システム障害が発生した際にデータ救出のためのアクセスができず、自分自身が冷や汗をかくことになります。

機能	メリット	デメリット
Normal Lockdown Mode	vCenter と例外リスト（Exception List）のユーザーのみがホストを制御可能。	物理サーバーの DCUI（黄色と黒の画面）には引き続きアクセス可能。
Strict Lockdown Mode	究極のセキュリティ。DCUI も含めて完全にロック。	vCenter がダウンすると、ホストから完全に「締め出される」リスクがある。
Custom Certificates	セキュリティ警告が解消され、安全な暗号化通信を実現。	内部 CA の導入プロセスは、初心者にはやや複雑。

実務経験に基づく最適な選択

中規模のエンタープライズ環境では、私は常に Normal Lockdown Mode を優先します。これによりネットワーク経由のブルートフォース攻撃を阻止しつつ、vCenter に深刻なトラブルが発生した際でも、物理コンソール（iDRAC/iLO）を介した「逃げ道」を確保できるからです。

詳細な実装ガイド

1. CLI による ESXi ホストのハードニング

まずはファイアウォールの設定です。ネットワーク全体にポート 22 へのアクセスを許可してはいけません。管理用 PC の IP が 192.168.10.50 であると仮定して、以下のコマンドを実行します。

# 既存のルールの確認
esxcli network firewall ruleset list

# すべてのソースからの SSH アクセスをブロック
esxcli network firewall ruleset set --ruleset-id=ssh --allowed-all=false

# 管理者の IP のみを許可
esxcli network firewall ruleset allowedip add --ruleset-id=ssh --ip-address=192.168.10.50

# 変更の適用
esxcli network firewall ruleset set --ruleset-id=ssh --enabled=true

次に、**Managed Object Browser (MOB)** をすぐに無効化しましょう。デバッグには便利ですが、悪意のある者にシステム構成に関する機密情報を過剰に提供してしまいます。

# MOB が有効かどうかを確認
vim-cmd proxysvc/get_all_stats

# セキュリティのために MOB を無効化
# クイック操作：ホスト > 設定 > システムの詳細設定 > 「Config.HostAgent.plugins.solo.enableMob」を検索し、False に設定します。

2. vCenter での Lockdown Mode の設定

ホストを vCenter に追加したら、vCenter を唯一の管理ポイントにします. これにより、ログの追跡（監査ログ）が集中化され、より正確になります。

vSphere Client を開き、設定対象のホストを選択します。
「設定」 > 「システム」 > 「セキュリティプロファイル」に移動します。
「Lockdown Mode」セクションで「編集」を選択し、「Normal」に変更します。
注意： バックアップの中断を防ぐため、バックアップ用アカウント（Veeam のサービスアカウントなど）を「例外ユーザー（Exception Users）」に追加しておきます。

3. 証明書の置き換え：赤い警告の解消

ブラウザに表示される緑色の鍵アイコンは、単なる飾りではありません。中間者攻撃（Man-in-the-middle）ではなく、正しいサーバーに接続していることを保証するものです。VMware にはこれを簡素化する VMCA が組み込まれています。

内部 CA（Microsoft AD CS）を使用している場合は、vCenter に SSH でログインし、次の強力なツールを実行します。

/usr/lib/vmware-vmca/bin/certificate-manager

Option 1 を選択します。CSR の作成、CA サーバーへの署名依頼、そしてインポートという 3 つのステップを実行します。完了すると、管理画面全体に緑色の鍵アイコンが表示され、運用における絶対的な信頼性が確保されます。

運用における教訓

8 台のホストクラスターでの数々の「失敗」を経て、私は 3 つの黄金律を導き出しました。

KVM がない場合は Strict Lockdown を避ける： iDRAC/iLO や物理サーバーへのアクセス権がない場合は、絶対に Strict モードを有効にしないでください。わずかなネットワークエラーでも、制御権を完全に失う可能性があります。
NTP は証明書の心臓部： ホストと vCenter の時刻が 5 分以上ずれるだけで、すべての証明書が拒否されます。NTP が常に信頼できるソースと同期されていることを確認してください。
ログを外部に転送する： 常に Syslog を構成し、独立したサーバー（vRealize Log Insight など）にログを転送するようにします。万が一、ハッカーが証拠隠滅のためにホストのログを削除しても、調査用のコピーが残ります。

vSphere セキュリティはゴールではなく、継続的な管理のプロセスです。esxcli コマンドの実行や証明書の更新で困ったことがあれば、ぜひコメント欄で質問してください。すぐにサポートします。