官公庁や金融機関など、高度なセキュリティが求められる環境において、VMware vSphere® などのセキュリティ設定を評価し、担保することはインフラ運用の重要な課題です。本記事では、米国防総省(DoD)の基準であるDISA STIG(Security Technical Implementation Guide)を活用した、VMware プロダクトのセキュリティ監査、自動化、結果の可視化手法について解説します。
1. DISA STIG とは? VMware との共同開発
STIGとは、米国防総省の情報システム局(DISA)が発行する、システムを安全に構成するための技術ガイドラインです。セキュリティ技術実装ガイド(STIG)は、国防情報システム局(DISA)が発行する構成標準であり、特定のソフトウェア製品が国防総省のセキュリティ要件を満たすためにどのように構成する必要があるかを規定しています。STIG は、構成すべき内容だけでなく、構成方法も定義しており、国防総省環境での使用が認められるためにシステムが満たすべき具体的な設定、値、検証手順などが含まれます。
STIG は、NIST SP 800-53 およびより広範な国防総省のセキュリティフレームワークから派生した一連のセキュリティ管理策を中心に構成されています。STIG 内の個々の要件は管理策(またはルール)と呼ばれ、各管理策には重大度評価(カテゴリI、II、III。それぞれ高、中、低の影響に対応)、セキュリティ設定の説明、準拠を確認する手順、および発見事項を是正する手順があります。

複数ベンダーが並ぶ DISA の STIG 管理サイト
DISAの公式サイト(DoD Cyber Exchange)には、OS、データベース、ネットワーク機器からクラウドインフラに至るまで、多数のベンダー製品向けの STIG がラインナップされています。Microsoft®、Red Hat、Cisco®、VMware など、各ベンダー製品のセキュリティ基準がここで一元管理されています。
VMware と DISA の共同開発と最終承認
vSphere や VMware Cloud Foundation® 9 (VCF 9) 向けの STIG は、VMware と DISA が連携して共同開発しています。VMware が製品のアーキテクチャや最新機能(VCF の新機能など)に基づいたベストプラクティスを提案し、DISA のセキュリティ要件とすり合わせを行い、最終的に DISA が承認・公開するというプロセスを経ています。これにより、実運用を考慮したセキュリティ要件を担保するガイドラインが策定されています。2026年3月には、Broadcom と DISA とでソフトウェア契約の合理化と統合を目的とした5年間で9億7,000万ドルの包括購入契約(BPA)を締結したことを発表し、本契約で STIG の構築と維持への投資が長期間戦略的に継続されることとなり、国防省傘下の連邦政府機関が VCF の実装を簡素化するための共通の設計図として機能することとなっています。
2. VMware が GitHub で公開している「STIG プロファイル」の位置付け
DISA からドキュメントとして STIG が公開される一方で、VMware は公式の GitHub リポジトリで監査用の STIG プロファイル(コード化されたルールセット)を管理・公開しています。
監査手法における位置付け
従来のセキュリティ監査は、PDF や スプレッドシートのチェックリストを用いて手動で設定を確認する作業が中心でした。しかし、GitHub で管理されている STIG プロファイルは、「機械可読な監査コード(Compliance as Code)」として利用できます。このプロファイルを利用することで、後述する自動化ツールが「システムが STIG の要件を満たしているか」を自動判定できるようになります。つまり、GitHub 上の STIG プロファイルは、自動化監査パイプラインの基準データとして機能します。
3. STIG 監査の自動化手法:3つのアプローチ
vSphere 8 を例にとって STIG 監査を自動化する手法として、代表的な3つのツールを紹介します。環境やチームのスキルセットに合わせて選択できます。
vSphere の監査では、vCenter/ESX/仮想マシン(VM) の3層に分けて実施します。各層の監査例(ルール)を以下に列挙することで、各層における監査観点の違いをここで捉えられるようにします。
- vCenter 層:vCenter 仮想アプライアンス自体への監査
認証およびアカウント管理、Secure Shell、シンボリックリンク・ハードリンク保護、カーネル・ネットワークハードニング、データベース層セキュリティ、Web インターフェース層セキュリティ、統合監査・整合性監視など - ESXi ホスト層:ハイパーバイザー自体への監査
仮想スイッチセキュリティ(BPDU Filter, Forged Transmits, MAC Changes, Promiscuous Mode 拒否設定)、Secure Shell、トラフィック分離、認証・アカウント設定、ロックダウンモード & サービス停止、TPM/Secure Boot、監査ログ & ファイアウォールなど
# ホスト自体への SSH アクセスによる監査は適切ではありません。その代わりに、ホストへの SSH は無効化されロックダウン状態とし、vCenter API から全ホストの監査を実施します。ロックダウンモードを有効化することで、ホストへの直接ログインを禁止し、すべての操作を vCenter Server 経由に強制します。これにより、vCenter の RBAC(役割ベースのアクセス制御)および一元化された監査ログが担保されます。 - 仮想マシン(VM)層:仮想マシンの仮想ハードウェアやコンソールアクセスへの監査クリップボード遮断、ディスク操作制限、Encrypted vMotion、不要デバイス(CD/DVDドライブ, Floppy, Serial, Parallel, PCI Passthrough, USBコントローラ/デバイス)の未接続・削除、コンソール接続制限など
より詳細なルールを確認される際には、VMware が GitHub で公開しているこちら(InSpec プロファイル)をご参照ください。
① CINC Auditor (Chef InSpec)
CINC Auditor (シンク オーディター)は、コンプライアンス監査ツール「Chef InSpec」のオープンソース版です。Chef InSpec とは、Chef 社(現Progress Software)」が開発しており、サーバーやクラウド、アプリケーションの設定が正しいか確認するオープンソースのテスト・監査フレームワークです。CINC は「CINC Is Not Chef」の再帰的頭字語で、Chef InSpec は非商用利用であれば無料であるため、CINC プロジェクトは Chef のポリシーを遵守しつつ商標を削除し、あらゆる用途で無料で利用できる代替ツールとして提供されています。CINC AuditorはChef InSpecと同じコードベースで構築されているとされてます。VMware が GitHub で公開している InSpec プロファイルをそのまま STIG 監査として実行できます。
# VMware 公式サイトでの Chef InSpec/CINC の操作解説はこちら
- 特徴: 監査に特化しており、レポート(JSON 形式等)の出力が柔軟で、設定の逸脱箇所を明確に把握
- 利用手順: CINC Auditor をインストールし、環境変数経由で対象の vCenter への接続情報をセットして実行
- コマンド例:
12345# GitHubのプロファイルをローカルにDLしてvCenterを監査し、結果をJSONで出力cinc-auditor exec C:\Inspec\Profiles\vmware-vcsa-8.0-stig-baseline \-t ssh://root@<vCenter-IP/FQDN> --password 'password' --show-progress \--reporter=cli json:C:\Inspec\Reports\vcsa-8.0.json
② PowerCLI
VMware 環境の管理で広く利用されている PowerShell モジュールです。
# VMware 公式サイトでの PowerCLI による STIG 監査の操作解説はこちら
- 特徴: VMware の運用担当者にとって馴染みがあり、既存の運用スクリプト(Windows 環境など)に組み込みやすい
- 利用手順: PowerCLI をインストールし、VMware コミュニティ(Github) で提供されている STIG 監査用の PowerShell スクリプトを実行
- コマンド例:
1234567# 資格情報オブジェクトを使用してセキュアに vCenter へ接続$cred = Get-CredentialConnect-VIServer -Server vcenter.local -Credential $cred# STIG監査スクリプトの実行(例)Invoke-vSphereSTIGAudit -Cluster "Prod-Cluster" -ReportType HTML
③ Ansible
構成管理ツールとして広く利用されている Ansible でも監査が可能です。
# VMware 公式サイトでの Ansible によるSTIG監査の操作解説はこちら
- 特徴: 監査(Check)だけでなく、設定の「修復(Remediation)」も同じツールで実施できる点が特徴
- 利用手順: VMware コミュニティ(Github)で提供されている STIG 監査用の Ansible Playbook を実行
- コマンド例:
123# 監査モード(Check mode)でPlaybookを実行し、変更はせずに設定状態を確認# 認証情報は Ansible Vault 等で暗号化してわたすansible-playbook -i inventory.ini vsphere_stig_audit.yml --check --diff --ask-vault-pass
4. 監査結果の変換(SAF CLI / HDF / CKL)
自動監査ツール(特にCINC Auditor)で出力された結果(JSON)は、そのままでは可視化ツールや監査機関のフォーマットに適合しない場合があります。そこで、MITRE 社が開発している SAF CLI (Security Automation Framework CLI) などのCLIツールを使用して、結果を扱いやすい形式に変換します。
- HDF (Heimdall Data Format): 様々なツールの監査結果を共通フォーマットに正規化した JSON データ
- CKL (STIG Checklist): DISA 公式ツールで読み込むための XML ベースのチェックリストファイル
変換コマンド例 (SAF CLIを使用):
|
1 2 3 4 5 6 |
# InSpecのJSON結果を HDF に変換 saf convert inspec2hdf -i audit_results.json -o results_hdf.json # HDF を公式の CKL 形式に変換 saf convert hdf2ckl -i results_hdf.json -o vsphere8_audit.ckl |
この変換処理を組み込むことで、自動監査ツールとコンプライアンス管理ツールのデータ連携が容易になります。
5. 監査結果の完全性担保(デジタル署名による改ざん防止)
自動監査によって生成された結果データ(JSON や CKL ファイル)はテキストフォーマットであるため、そのままでは悪意のある管理者や攻撃者によって事後的に内容(例えば、「Fail」を「Pass」に書き換える等)が改ざんされるリスクがあります。監査証跡としての信頼性(Non-repudiation)を証明するために、データの完全性担保は不可欠です。
- デジタル署名の付与: 監査結果を出力・変換した直後に、パイプライン内で直ちに GnuPG や OpenSSL 等を使用してデータにデジタル署名(Digital Signature)を付与します。これにより、「誰が(どのツールが)」「いつ」この結果を生成したかが暗号学的に証明されます。
12# 例: GnuPGを使用して監査結果ファイルに署名を付与するgpg --clearsign vsphere8_audit.ckl - WORM ストレージやログ基盤へのセキュアな保管: 署名済みのファイル、および生成されたファイルのハッシュ値(SHA-256等)を計算し、原本データとは別の安全な場所へ速やかに転送します。保存先としては、WORM(Write Once Read Many)対応のオブジェクトストレージや、改ざん防止機能を持つ SIEM などのセキュアなログ基盤が適切です。
- CI/CDパイプラインによる一貫性の保証: これらの一連のプロセス(監査の実行 → 結果の変換 → デジタル署名の付与 → セキュアな保管)を、GitLab CI などの自動化パイプラインに組み込みます。人手が一切介在しないプロセスを構築することで、監査結果の客観性と完全性が自動的に保証されるようになります。
6. 著名な可視化ツールと使い方
変換および署名が完了した監査結果データを可視化し、共有・管理するための3つのツールを紹介します。
① MITRE Heimdall
- 概要: MITRE 社が提供する、HDF データを可視化するための Web ダッシュボード
- 使い方:
- Heimdall の Web インターフェースを開く
- VCF や vSphere 環境の HDF ファイル(監査スキャン結果
results_hdf.json)、または 前述の手順で変換した.cklファイルを一括でアップロード - 全体のコンプライアンス遵守率(スコア)、重大度(High, Medium, Low)ごとの違反数がグラフで表示
- ドリルダウンして、特定のホストや設定項目の状態を確認でき、現場での日々の状況把握に活用
# VMware 公式サイトでの Heimdall の操作解説はこちら
② DISA STIG Viewer (DISA 公式ツール)
- 概要: DISA が公式に提供しているデスクトップアプリケーション
- 使い方:
- VCF や vSphere 環境の CKL ファイル(監査スキャン結果
results_hdf.json)を前述の手順で変換した.cklファイルをインポート - 自動監査で要件を満たした項目は「問題なし」として緑色で表示
- 逸脱した項目(Open)について、手動でコメントを追記したり、例外対応の理由(Waiver)を入力して保存
- 最終的な監査報告書のマスターデータとして使用
- VCF や vSphere 環境の CKL ファイル(監査スキャン結果
③ OpenRMF
- 概要: STIG 監査結果だけでなく、NIST RMF (Risk Management Framework) のプロセス全体を管理できるオープンソースの統合プラットフォーム
- 使い方:
- システムパッケージを作成し、システムを登録
- VCF や vSphere 環境の CKL ファイル(監査スキャン結果)を一括でアップロード
- リスクの全体像をダッシュボードで把握し、問題解決のためのタスクである POA&M (Plan of Action and Milestones) を生成
- チーム全体で是正状況をトラッキングし、継続的なコンプライアンス維持(Continuous Monitoring)管理に活用
# OpenRMF® Professional は、米国の Soteria Software社が開発・提供する、サイバーセキュリティのコンプライアンス(法令・基準への準拠)管理を自動化するためのウェブアプリケーションです。OpenRMF® Professional と OSS のOpenRMF(OpenRMF OSS)の主な違いは、機能の高度さ、サポート体制、および利用ライセンスにあります。OSS 版が基本的なチェックリスト管理やスキャンデータの取り込みを提供するのに対し、Professional 版は高度な自動化、eMASS 等との連携、およびエンタープライズ向けのサポートを提供されています。
まとめ
いかがだったでしょうか。VCF や vSphere などのインフラ環境において、STIG への準拠はシステムの安全性を高める有効な手段の一つです。
VMware と DISA が連携して作成したプロファイルを GitHub から取得し、CINC Auditor、PowerCLI、Ansible といったツールで自動監査を実行。出力されたデータを HDF や CKL に SAF CLI で変換し、STIG Viewer、Heimdall、OpenRMF で可視化・管理するアプローチが可能です。
また、出力された監査結果へのデジタル署名付与など、プロセス全体のセキュリティとデータの完全性を担保することが不可欠です。これらの一連の監査パイプライン(Compliance as Code)を構築することで、手作業による監査作業を効率化し、セキュアな VMware 環境の維持と確実なコンプライアンス証明に貢献します。
将来生じる脆弱性への対応がリアクティブであれば、こうしたセキュリティ設定を評価するハードニングはプロアクティブな対策です。こうした脆弱な要素を日々是正・維持管理することを通して、将来生じる脆弱性に対して本番運用で悪用の可能性を摘んでおくことにも非常に重要な対策です。また、こうしたハードニング項目の中には、ロギングなど証跡を分析するための項目も含まれ、将来実施する脅威ハンティングなどの活用にも寄与します。
本記事が皆様の日々の運用の一助になれば幸いです。今回もお読みいただき、ありがとうございました!
※ Microsoft、Windows、Windows Server は、米国 Microsoft Corporation の 米国およびその他の国における登録商標または商標です。 Windows の正式名称は、Microsoft Windows Operating System です。
※ OpenRMF® Professional は、米国の Soteria Software 社の登録商標です。