VMware Harden

vmware-harden

免責事項：コミュニティがメンテナンスするオープンソースプロジェクトです。VMware, Inc. または Broadcom Inc. とは提携、推奨、後援関係にありません。「VMware」、「vSphere」、「ESXi」、「NSX」は Broadcom の商標です。ソースコードは、MIT ライセンスに基づき github.com/vmware-skills/VMware-Harden で公開され、監査可能です。

English | 中文

AI ネイティブな VMware コンプライアンスおよびベースライン適用ツールです。vmware-* スキルファミリーの姉妹プロジェクトです。

• vSphere に対して読み取り専用：8 つすべての MCP ツールに [READ] マーカーが付いており、管理対象の VMware インフラストラクチャを変更することはありません。scan_target が書き込むのはローカルの Twin DB（独自に取得した観測結果のキャッシュ）のみです。設計上の読み取り専用を参照してください。

GA ファミリーのメンバー（v1.5.18 以降）

本番環境対応のコンプライアンスプラットフォームです。9 つの組み込みベースライン（CIS ESXi 8.0 + 9.0、vSphere SCG v8 + v9、vSphere 9 STIG 準拠、等保 2.0 三级、PCI-DSS 4.0、EU NIS2、BSI IT-Grundschutz）に99 個のルールを備え、ESXi と vCenter のビルドを対象とする VMSA 既知脆弱性チェック、マルチ vCenter Twin、ドリフト検出、LLM 修正アドバイザー、監査済みの 8 つのツールを備えた MCP サーバー、ウェブダッシュボード、および環境診断用の vmware-harden doctor を提供します。

クイックスタート

# The collectors extra is what makes `scan` work: harden reads inventory
# through vmware-aiops / vmware-storage / vmware-nsx-security, and `uv tool
# install` gives each tool its own environment — installing them separately
# puts them where harden cannot import them from.
uv tool install "vmware-harden[collectors]"

# Reporting on an existing twin DB needs no collectors:
#   uv tool install vmware-harden

# List built-in baselines
vmware-harden baseline list

# Run a scan
vmware-harden scan --target <vcenter-name> --baseline cis-vmware-esxi-8.0-subset

# Or use 等保 2.0 三级 (国内合规独家)
vmware-harden scan --target <vc> --baseline dengbao-2.0-level3-vmware

# View results
vmware-harden report
vmware-harden drift

# Generate remediation suggestions
export ANTHROPIC_API_KEY=...  # optional; falls back to mock without
vmware-harden advise --all-critical

# Web dashboard
vmware-harden web --port 8080  # → http://127.0.0.1:8080

結果の読み方：違反がないことだけでは判定できません

ルールが判定できるのは、実際に収集された構成情報だけです。収集には、独立した 2 つの失敗パターンがあります。属性をどのコレクターも生成しないルールは、そもそも実行されません。実行されるルールでも、特定のホストについて値が取得できず、N/A というセンチネル値が返された場合は、何も判定できません。ホストに到達できない場合、アカウントに必要な権限がない場合、ESXi のビルドに該当設定が存在しない場合などがこれにあたります。どちらも合格として報告されることはありません。

$ vmware-harden report
No violations among the checks that could be made.

16 of 20 rules could not be evaluated — no collector provides the data they
check, so their result is unknown, not compliant. 6 of 8 per-node checks could
not be made across 2 node(s): the rules ran, but the values they read were
missing on those nodes, so those nodes are unknown rather than compliant.
Not evaluated:
  cis-esxi-2.1.1   no collector writes host.ntp_enabled
  ...
Not judged on these nodes (data missing):
  cis-esxi-2.2.1   esx-02    esxi_build
  ...

--format json は {"violations": [...], "coverage": {...}} を返し、MCP ツールも同じ coverage ブロックを返します。そのため、エージェントは violations: 0 を見ただけで「準拠している」と結論づけることはできません。v1.9.0 より前は、未収集属性に関するルールは一致する行が 0 件となり、暗黙に合格として数えられていました。v1.10.0 より前は、ノード単位の場合も同様でした。RELEASE_NOTES.md を参照してください。

この 2 つのリストでは、必要な対応が異なります。1 つ目はコレクターの対応待ちで、2 つ目はそのノードへの到達性とスキャンアカウントの権限に関する対応待ちです。

オフライン／エアギャップ環境へのインストール（ソースから）

このプロジェクトは最新の PEP 517 ビルドシステム（hatchling）を使用するため、設計上 setup.py はありません。これは想定どおりであり、ファイルが欠落しているわけではありません。ソースをクローンした際に ERROR: File "setup.py" or "setup.cfg" not found ... editable mode currently requires a setuptools-based build が表示された場合、使用している pip は 21.3 より古く、setuptools 以外のバックエンドでは 編集可能（-e）インストールを実行できません。編集可能モードは開発上の利便性のためのもので、ツールの実行には不要です。次のいずれかを実行してください。

# From the source tree — a normal (non-editable) install builds a wheel:
pip install .              # NOT  pip install -e .

# ...or upgrade pip first, and editable works too:
pip install --upgrade pip && pip install -e .

完全なエアギャップ環境のホストにインストールする場合は、ネットワークに接続されたマシンで wheel をビルドしてからコピーしてください。インストール先ではネットワーク接続が不要になります。

# On a connected machine, collect this package + its dependencies as wheels:
pip wheel . -w dist        # → dist/*.whl   (or: uv build, for just this package)

# Copy dist/ to the air-gapped host, then install offline:
pip install --no-index --find-links dist vmware-harden

設計上の読み取り専用

vmware-harden は vSphere と NSX に対して読み取り専用です。8 つすべての MCP ツールに [READ] マーカーが付いており、管理対象の VMware インフラストラクチャを変更することはありません。scan_target が書き込むのは ローカルの Twin DB（~/.vmware-harden/twin.duckdb）のみです。これは管理対象インフラストラクチャではなく、 独自に取得した観測結果のキャッシュです。このスキルが修正を適用することはありません。修正は、 書き込み操作に承認ゲートと監査証跡を提供する vmware-pilot に委ねられます。

組み込みベースライン

ベースライン	ルール	適用対象	ソース
cis-vmware-esxi-8.0-subset	20	ホスト	CIS Benchmark v1.0
vsphere-scg-v8-subset	15	ホスト、VM	VMware vcf-security-and-compliance-guidelines
dengbao-2.0-level3-vmware	20	ホスト、VM、データストア、dfw_rule	GB/T 22239-2019 三级
pci-dss-4.0-vmware	10	ホスト、dfw_rule	PCI-DSS v4.0
eu-nis2-vmware	12	ホスト、dfw_rule	EU NIS2 Directive（Articles 21/23、Annex I）
bsi-itgs-basisabsicherung-vmware	10	ホスト	BSI IT-Grundschutz（OPS.1.1.4 + SYS.1.1）
cis-vmware-esxi-9.0-subset	20	ホスト	extends: により cis-vmware-esxi-8.0-subset を継承
vsphere-scg-v9-subset	15	ホスト、VM	extends: により vsphere-scg-v8-subset を継承
vmsa-advisories	3（カタログに登録されたアドバイザリごとに1つ）	ホスト、vcenter	オフラインの VMSA カタログ — 既知の脆弱性を参照
vsphere-stig-v9-subset ⚠️ 実験的	12	ホスト	vSphere 9 の STIG に準拠したホストの詳細設定（DoD/DISA STIG コンテンツ）— ESXi 8.0.3 でコレクターによる検証済み。9.x に対する実行はまだ行っていません

baseline list は10個のIDを返します。上記のルールを含むYAMLベースライン7個（合計99ルール）、独自のルールを持たず、v8の親からルールを解決するv9エイリアス2個、およびファイルから読み込むのではなくアドバイザリカタログから生成される vmsa-advisories です。

既知の脆弱性（VMSA）

vmsa-advisories は、パッケージに同梱されるVMware セキュリティアドバイザリのオフラインカタログ（vmware_harden/advisories/catalog.yaml。カタログの日付時点でソースと照合済み）に基づいて、各 ESXi ホストと vCenter 自体のバージョンおよびビルドを判定します。アドバイザリごとに 1 つのルールがあり、各ルールの説明には、その根拠となる等保 2.0 三级の統制（安全計算環境・侵入防止：既知の脆弱性を発見し、テスト後にパッチを適用する）が引用されています。

vmware-harden scan --target prod-vc --baseline vmsa-advisories
vmware-harden report                    # each affected component: its fix, and whether the CVE is in CISA KEV
vmware-harden report --format csv > vmsa.csv

判定	意味
affected	違反です。根拠には、修正されるリリースが記載されています。
fixed	同じ系列で、修正リリースと同じか、それより後のリリースです。
unknown	理由とともにノードごとに記載されます。理由には、ビルドを読み取れない、アドバイザリに記載されていない系列またはサポート終了済みの系列、ソース間で見解が一致しないブランチ、カタログにまだ含まれていない製品があります。合格を意味するものではありません。

問題がないという結果は、カタログの日付時点で既知の未解決アドバイザリがないことを意味し、「脆弱性がない」ことを意味するものではありません。カタログ作成後に公開されたアドバイザリは含まれていません。ビルドの比較は、同じ major.minor 系列内でのみ行われます（7.0 U3 のビルド番号は、8.0 GA のビルド番号より大きい場合があります）。

カタログの作成方法。 Broadcom のアドバイザリページはボット対策によりスクリプトで読み取れず、Broadcom は CSAF フィードも公開していません。各項目は、NVD CVE API（CVE、CVSS、脆弱なバージョン）、CISA KEV フィード（実環境で悪用済み）、Broadcom のビルド番号に関する KB 記事（修正済みビルド）をもとに作成され、各修正リリースはアドバイザリを引用する独立した情報源で確認されています。すべての修正は、builds.yaml にあるビルド KB のスナップショットと機械的に照合されています。最初のカタログ（2026-10-19）には、KEV に掲載された 3 件のアドバイザリが含まれています。VMSA-2025-0004（ESXi）、VMSA-2024-0019 および VMSA-2026-0006（vCenter。ESX 側はまだカタログに含まれておらず、unknown として報告されます）。

任意の更新。 vmware-harden advisories update は CISA KEV フィード（および --nvd を指定した場合は NVD スコア）を ~/.vmware-harden/advisories-cache.json にダウンロードし、カタログローダーがその内容を反映します。KEV フラグは追加のみ行われ、CVSS は値がない場合にのみ補完されます。修正済みビルドの情報は、決してキャッシュから取得されません。また、KEV に掲載されているものの、カタログ内のアドバイザリでカバーされていない ESXi/vCenter の CVE も一覧表示します。KEV の取得に失敗すると終了コード 1 で終了し、以前のキャッシュは変更されません。読み取れない NVD レコードは報告されますが、KEV の更新は妨げません。実行中の MCP サーバーは、次回の呼び出し時に新しいキャッシュを読み込みます。レポートには、KEV を最後に確認した日時が表示されます。vmware-harden advisories show は、カタログの日付と最後の更新日時を表示します。

VCF 9.0 / 9.1 との互換性

既存のベースライン（cis-vmware-esxi-8.0-subset、vsphere-scg-v8、dengbao-2.0-level3-vmware、pci-dss-4.0-vmware）は、VCF 9.0 / 9.1 クラスターを正常にスキャンできます。ほとんどのルールは、8.x から 9.x にかけて安定しているホストの詳細設定を対象としています。cis-vmware-esxi-9.0-subset と vsphere-scg-v9-subset は現在、v8 の親ベースラインを extends: で継承するエイリアスとして提供されています。ルールは同じで、スキャンとレポートに使用する ID が v9 名になっています。Broadcom が v9 ガイドを公開したら、9.x 固有のルールを追加します。

vsphere-stig-v9-subset は、STIG に準拠したルールを含むベースラインです。公式のオープンソース vSphere STIG コンテンツ（MITRE InSpec / Cinc Auditor）にマッピングされた、ホストの詳細設定に関する 12 個のコントロール（アカウントロックアウト、パスワードポリシー、DCUI アクセス、シェル／DCUI のタイムアウト、MOB、ゲスト BPDU、リモート syslog）を備えています。ステータス：実験的。 このベースラインのチェックでは、ホストコレクターが config.option の PropertyCollector パスを介して取得する ESXi ホストの詳細設定を読み取ります。このパスは、2026-08-13 に稼働中のスタンドアロン ESXi 8.0.3（ビルド 24280767）でエンドツーエンドの検証が完了しています。12 個すべての属性が値を取得し、ルールが想定する形式で値が返され（account_lock_failures=5、dcui_access='root'、password_quality_control='retry=3 min=disabled,disabled,disabled,7,7'、mob_enabled=False、syslog_remote_host=''）、スキャンでは実際の違反が 3 件検出されました。ただし、未検証の項目が残っており、これがステータスを実験的のままにしている理由です。このベースラインが実際に対象とする ESXi 9.x と、vCenter で管理される複数ホストのインベントリは未検証です。9.x での結果は権威あるものとして扱わないでください。v1.9.0 の判定不能メカニズムでは、取得失敗だけの場合をカバーできません。属性を宣言するコレクターが存在しない場合（語彙に対する静的チェックです）にのみルールを拒否しますが、これらの STIG 属性は宣言されているため、ルールは実行されます。実機で PropertyCollector パスが空の結果を返した場合、属性は単に存在しないことになり、ルールは再び 0 行に一致します。v1.10.0 ではこのケースを検出できます。このようなホストは合格ではなく、ノードごとのギャップ（coverage.undetermined_node_checks）として記録されるため、未検証のコレクターは、クリーンなレポートではなく、判定されていないホストとして表示されます。未検証のまま残るのは、パスが正しい値を返すかどうかです。これはどのカバレッジメカニズムでも判定できません。ベースラインの status フィールドは list_baselines と describe_stig_content_sync で表示されるため、スキャン時にこの注意事項を明示的に確認できます。これはコンテンツ同期であり、API ラッパーではありません。VCF Operations 9.1 Automated Configuration Compliance（ACC）/ Security Posture Management（SPM）は UI とスケジュールで制御され、公開されたコンプライアンス REST API はありません。継続的なフリート全体への適用と自動修復には、**VCF Operations SPM/ACC（UI）**を使用してください。vmware-harden は、API でスクリプト化でき、DuckDB に永続化し、複数のターゲットを対象とするポイントインタイムスキャナーです。references/stig-content-sync.mdを参照し、vmware-harden stig controls でカタログを確認してください。

Broadcom 公式リファレンス

• セキュリティ設定ガイド：https://core.vmware.com/security/ — vSphere SCG v8 / 今後の v9
• SDK：https://developer.broadcom.com/sdks — VCF Python SDK（REST 経由でホスト設定を取得するため）
• CIS ベンチマーク：https://www.cisecurity.org/cis-benchmarks/ — CIS VMware ESXi Benchmark v1.0（8.0 / 今後の 9.0）

カスタムベースライン

vmware-harden baseline validate ./my-strict.yaml
vmware-harden baseline import ./my-strict.yaml --name my-strict-cis
vmware-harden scan --target <vc> --baseline my-strict-cis

YAML は、組み込みのベースラインを継承するための extends: をサポートしています。skills/vmware-harden/references/cli-reference.md を参照してください。

MCP サーバー

vmware-harden mcp  # stdio MCP server (legacy alias: vmware-harden-mcp)

examples/mcp-configs/*.json のいずれかを使用して、MCP クライアントを設定してください。読み取り専用ツールは 8 個です：list_baselines、get_baseline_rules、list_stig_controls、describe_stig_content_sync、list_violations、get_remediation、list_drift_events、scan_target。

アーキテクチャ

• Estate Digital Twin — ~/.vmware-harden/twin.duckdb にある DuckDB の単一ファイルです。すべてのノード ID にターゲットプレフィックスを付けることで、複数ターゲットに安全に対応します。
• コレクター — 同階層の vmware-* スキルを遅延インポートします（プロセス起動のオーバーヘッドはありません）。すべてのスキャンは読み取り専用で、書き込みは vmware-pilot に委ねられます。
• ベースラインスキーマ — Pydantic v2 を使用し、厳格（extra="forbid"）に設定されています。extends: による継承と、ユーザーディレクトリによる上書きに対応します。
• ドリフト — 永続化を任意で指定できる、純粋な差分関数です。各スキャンの後に自動実行されます。
• アドバイザー — LLM 主導で Suggestion を生成します。プロンプトキャッシュ対応の Anthropic プロバイダーを使用し、テスト環境や API キーがない環境ではモックにフォールバックします。
• 監査 — すべての MCP ツールを、vmware-policy ファミリーの @vmware_tool でラップします。
• Web — FastAPI + Jinja2 + Tailwind/HTMX/ECharts CDN です。

ラボでのリグレッション

export VMWARE_HARDEN_LAB_TARGET=<your-vc>
pytest tests/eval/regression -v -m lab

ファミリー

• vmware-aiops — ホストインベントリ + 運用（harden の HostCollector が使用）
• vmware-monitor — 読み取り専用の対応製品
• vmware-storage — データストアインベントリ
• vmware-nsx-security — DFW インベントリ
• vmware-pilot — 修復を実行します（書き込みあり。harden の対象外）
• vmware-policy — @vmware_tool 監査デコレーター

受け入れ基準（v1.5.18 GA）

• 221 件のテストが成功
• Bandit：重大度を問わず問題 0 件
• すべての MCP ツール（8 件）を監査済み
• SKILL.md は 3000 語以下で、ファミリー規約に準拠
• 6 つの要素と Broadcom の免責事項を含む SECURITY.md
• 組み込みベースライン 9 件（7 つのルールを含むセットにわたる 99 ルール + v9 エイリアス 2 件）
• 環境診断用の vmware-harden doctor
• vmware-* ファミリーの GA メンバー（バージョンを 1.5.28 に統一）

参考資料

• ファミリーの CLAUDE.md：モノレポのルートにある CLAUDE.md

リモートアクセス（HTTPS）とツールの制限

デフォルトでは、vmware-harden mcp は stdio で 1 つのローカルクライアントと通信し、すべてのツールを提供します。2 つのオプションでこの動作を変更できます （vmware-policy ≥ 1.21.0）。

HTTPS で提供すると、ほかのマシン上のクライアントが接続できます。すべての呼び出し元にベアラートークンが必要です。

vmware-audit token create alice          # prints the token once; give it to alice
vmware-audit token list                  # names only
vmware-audit token revoke alice          # refused from its next request, no restart
vmware-harden mcp --transport https --host 0.0.0.0 --port 8443 \
    --cert /etc/vmware-mcp/server.pem --key /etc/vmware-mcp/server-key.pem \
    --public-name mcp.example.com

クライアントを接続します（Claude Code の例です。ストリーミング可能な HTTP とカスタムヘッダーをサポートする MCP クライアントであれば、どれでも使用できます）。

claude mcp add --transport http vmware-harden https://mcp.example.com:8443/mcp \
    --header "Authorization: Bearer $VMWARE_MCP_TOKEN"

{
  "mcpServers": {
    "vmware-harden": {
      "type": "http",
      "url": "https://mcp.example.com:8443/mcp",
      "headers": { "Authorization": "Bearer ${VMWARE_MCP_TOKEN}" }
    }
  }
}

• トークンがないとサーバーは起動せず、--public-name に含まれない Host／Origin 値を拒否します。また、バインド前に、認証されていないリクエストが 401 を返すことを確認します。クライアントがこれらの名前を信頼する証明書を使用してください。
• 同じマシン上の TLS 終端リバースプロキシの背後では、--transport http --host 127.0.0.1 --public-name mcp.example.com を使用し、Authorization ヘッダーを転送してください。
• 別のマシン上のロードバランサーまたはゲートウェイの背後では、--transport https のままにしてください（自己署名証明書でもかまいません）。ロードバランサーが Host として送信するホスト名を --public-name に指定し、Authorization を転送するようにしてください。 ヘルスプローブには、トークン不要で {"status": "ok"} のみを返す GET /healthz を使用できます （vmware-policy ≥ 1.23.0）。
• 各リクエストに traceparent または X-Request-ID を付けると、監査行に保存されます。 vmware-audit log --correlation-id ID を実行すると、1 つのプラットフォームリクエストに関連する呼び出しを検索できます。
• 監査ログには各呼び出し元が token:<name> として記録されます。異なるターゲットを指定した呼び出しは並列に実行され、ターゲットを指定しない呼び出しは一度に 1 つずつ実行されます。そのため、複数の人がサーバーを共有する場合はターゲットを指定してください。
• エンドポイントに接続できるすべてのユーザーが、このサーバーのアカウントで操作します。 トークンは呼び出し元を識別しますが、プラットフォーム上の権限を付与するものではありません。権限レベルごとにエンドポイントを 1 つ実行してください。
• 1 つのエンドポイントを複数の人やロールで共有する場合： vmware-audit roles enable を 1 回実行してから、各トークンにロールを割り当てます（vmware-audit token create NAME --role reader を実行するか、使用可能なツールとターゲットを指定するロールを roles.yaml に記述します。vmware-policy ≥ 1.24.0）。ロールは、このエンドポイントでトークンが呼び出せる対象を制限します。アカウントが持つ権限を超える権限は付与できません。ターゲットを制限するロールでは、scan_target のターゲットは vmware-aiops の設定に照らして確認されます。データストアコレクターと DFW コレクターは、同じ名前を vmware-storage と vmware-nsx-security の設定で検索するため、3 つすべてで同じシステムを指す名前を指定する必要があります。詳しくは、vmware-policy の README の「ネットワーク経由の呼び出し元に対するロール」を参照してください。

ツールの制限： このサーバーのツールはすべて読み取り専用であるため、--expose read を指定してもここでは何も変わりません。このオプションは書き込み可能なスキルのためにあります。最小権限は、サーバーが使用するアカウントによって決まります。

詳細：skills/vmware-harden/references/setup-guide.md（「HTTPS 経由での MCP の提供」、「提供するツールの制限」）。

ライセンス

MIT