VCF Automation All Apps Orgs ：ネットワークモデルを知るための情報集

この記事は vExpert Advent Calendar 2025 の3日目の記事です。

adventar.org

はじめに

これから、VCF 9.0以降のリリースでVCF Automation(以下、VCFA)のOrganization for All Applications(以下、All Apps 組織)を構築する方が増えると見込んでいます。

その際にVCF 9.0、NSX、Supervisor、VCFAの知見があったとしても、理解しづらいことがあると危惧しています。

今回は実際に構築を行った際に役に立った情報の中で、特にVCFA 9.0の組織作成におけるネットワークモデルの情報についてまとめました。

ぜひ活用ください。

VCFA All Apps 組織 全体像の把握

プロバイダ管理

VCF 9.0からVCFAにはプロバイダ管理機能が追加されました。

プロバイダ管理では2種類の組織(Organization)を作成して管理します。

• Organization for All Applications (All Apps 組織)
  VCF 9.0から登場した、利用が推奨されているマルチテナントモデル
• Organization for VM Applications (VM Apps 組織)
  VCF 9.0未満からある、Aria Automationユーザー向け既存環境継続モデル

つまり、これから始める場合は「All Apps 組織」を作成することになります。

プロバイダ管理の詳細については以下のドキュメントをご確認ください。
プロバイダ管理

All Apps 組織

All Apps 組織を作成するには、「NSX VPC」と「Supervisor」の構成が必要となります。

これはVCFAの自動化機能でネットワークやネームスペースなどの自動作成ができる必要があるためです。

NSX VPC を使用する スーパーバイザー ネットワーク

VCF 9.0でVCFフリートやVCFインスタンスのマネジメントドメインの構築が完了したら、ワークロードドメインの作成中にオプションとしてSupervisorを有効にする、またはワークロードドメイン作成後にvSphere ClientからSupervisorを有効にします。

ワークロードドメインの作成中にオプションとしてSupervisorの有効化をしたほうが、自然な流れで「Default Project」「Default Transit Gateway」「Default VPC」を使用する形で構成できるため、後述する設計の推奨事項に関連しておすすめです。

なお、Supervisorをデプロイする際に始めやすいのは、管理ゾーンを「単一ゾーン」、ロードバランサをNSX LBで構成することです。Aviがある場合はロードバランサを「Avi」で構成することで将来のリスクを回避できます。

このようにNSX VPCとSupervisorを構成したら、VCFAのUIから組織を作成することができるようになります。

NSX VPCとSupervisorの構築方法については以下のドキュメントをご確認ください。
NSX VPC ネットワークを使用して スーパーバイザー をデプロイする

構築方法を確認する際には、まずワークフローから確認するのが混乱しないためおすすめです。
スーパーバイザー の NSX VPC ワークフロー

急に出てきたVPCってそもそも何？という方は、ぜひ@m-enoさんのブログを参照ください。
NSX 9(VCF 9)のVPC①： NSX 4.xとの違いについて #NSX-T - Qiita

中央集中型ゲートウェイ

NSX VPCを使用するSupervisorを構築する場合は「中央集中型ゲートウェイ」で構成する必要があります。

中央集中型ゲートウェイには「NSX Edge」が必須となります。

NSX EdgeはNSX LBを使用する場合、「Largeサイズ以上」でデプロイする必要があります。

ステートフルサービスの提供が必要であるためTier-0 ゲートウェイ高可用性(HA)モードは「アクティブ/スタンバイ」にします。

中央集中型ゲートウェイの構築方法については以下のドキュメントをご確認ください。
中央集中型ゲートウェイの構成

実際に構築した際にFailedしたのは、TEPの疎通性がなかったりBGPのピアがはれなかったりといった物理ネットワーク関連のエラーでしたので、やはりスムーズなVCF(NSX)構築のキモは安定したNSX用の物理ネットワークを準備することであると、また実感することになりました。

設計の要件と推奨事項

ネットワーク消費モデル

All Apps 組織の構築を目的とした場合、ネットワーク消費モデル(Network Consumption Model)は「VCF Automation All Apps Orgsモデル」となります。
Broadcom TechDocs: VCF 9.0 - ネットワークモデル

このモデルではVCF Automation UI/APIを介してVPCを管理します。

VCF 9.0ではVPCをNSX UI/APIやvSphere Clientからも管理できますが、このモデルを選択した場合はVCFAからVPCを管理し、NSXからは管理しません。

このモデルでは同じワークロードドメインに異なるネットワーク消費モデルを混在させることは推奨されていません。

そのため、この設計の推奨事項を考慮すると、異なるネットワーク消費モデルにあたる「VPCネットワーク仮想化モデル」、「NSXセグメントネットワーク仮想化モデル」、「VLANネットワークモデル」を使用する場合にはワークロードドメインを分けて構築し、あくまでAll Apps 組織を構築するワークロードドメインはVCFAでのみVPCを管理したほうがよいです。

ワークロードネットワーク詳細設計

All Apps 組織でサポートされているのは「フルサービスモデルを備えたVPC」のみなので、以下のドキュメントに記載されている設計の要件や推奨事項を考慮すればよいです。
VPC およびフル サービスのワークロード ネットワーク モデル

ゲートウェイのデプロイオプションについては、「マルチテナントの使用パターン」が6つあるので、あらかじめどのパターンに該当するかを確認したうえで、該当するデプロイオプションの設計要件と推奨事項を確認することになります。
マルチテナントの使用パターン

まとめ

今回はネットワークモデルを理解するための助けとなるであろう情報をまとめてみました。

そんなことはいいからこれらを満たしている環境を触らせてくれという方は、ぜひVMware HOLの製品フィルタでVMware Cloud Foundation Automationを選択して表示されたラボを開始してみてください(例えば、HOL-2601-21-VCF-Lでよいです)。

もう動いてます。

VCF の計画に Planning and Preparation Workbook を頼ってみる

この投稿は、vExperts Advent Calendar 2024 の 6日目です。

VMware Cloud Foundation（以下、VCF）は、主要なITインフラのハードウェアを抽象化し、包括的なプライベートクラウドプラットフォームを実現することができます。SDDC Managerからの統合管理によって設計を標準化し、導入や運用のプロセスを簡素化できるのが魅力です。

一方で、VCFの導入には十分な計画と事前準備が必要な側面があります。
本ブログでは、VCFの計画を助けてくれるPlanning and Preparation Workbookを紹介します。

---

1. 入手方法

VCFの計画にPlanning and Preparation Workbookを使用します。
Planning and Preparation Workbookは以下より入手します。
VMware Cloud Foundation Documentation

Planning and Preparation Workbook をクリックしてダウンロード

---

2. 入力

Planning and Preparation Workbookを開きます。

英語のExcelファイルです

まずは、"Deployment Options" シートで希望するオプションを選択します。

今回は、VCF Operationsを使用する計画を立てます。
この場合、"Intelligent Operations Management for VMware Cloud Foundation" を選択することで、Management DomainやVI Domainだけでなく、VCF Operationsをデプロイするよう想定されます。

"Exclude" のセルを選択するとプルダウンが表示されます

"Intelligent Operations Management for VMware Cloud Foundation" を選択すると、選択した項目の可否と、できない場合には何が原因であるかが表示されます。

赤色でハイライトされている場合、解消すべき項目が残っていることを示しています

不足しているものを "Deployment Options" シートで探すと、他の項目として存在することが分かります。対象がまだ計画に含まれていない場合（Exclude）は計画に含めます（Include）。 

不足している項目が連続している場合もあります

不足した項目の原因を解消すると、"Final Results" の列が ”Included” となります。

緑色でハイライトされている場合、対象の項目が計画に含まれたことを示しています

最初に選択した "Intelligent Operations Management for VMware Cloud Foundation" を確認してみると、まだ項目が不足しているようです。

VMware Validated Solution（VVS）は前提となる項目数が多いです

先ほどと同様に不足する項目の原因を解消します。

項目によっては、デプロイされる仮想アプライアンス数に影響するものがあります

VCF環境が標準アーキテクチャなのか、それとも統合アーキテクチャなのかを決めます。今回は、標準アーキテクチャを選択し、VI DomainのSSOドメインはManagement Domainに参加させる想定にします。

依存関係にある項目が自動選択された場合、手動で他の選択肢に変更することも可能です
例：調達予定のストレージデバイス的にvSAN ESAからvSAN OSAに変更するなど

以上で希望するオプションの選択は完了です。

done.

---

3. 出力

Planning and Preparetion Workbookのシートを移動して、"Management Domain Sizing" を表示します。

"Management Domain Sizing" では、"Deployment Options" で選択した項目に基づき、Management Domainにデプロイが想定される仮想アプライアンスの種類、ノード数、リソースなどが一目で分かります。
対象の仮想アプライアンスがManagement Domain、VI Domain、VVSのどのデプロイに要求されているかといった内訳も確認できます。

実際にはvSAN Ready Nodesな時点で満たせている場合が多い

サイジング内容を調整したい場合には "Management Domain Sizing Inputs" シートで修正が可能です。

他にも、VCFの事前準備に必要なネットワークを確認できます。
例えば、シンプルにManagement DomainやVI Domainをデプロイする場合、必ずしもNSX Edgeを展開する必要はありません。しかし、今回のようにVCF Operationsを使用する場合にはNSX Edgeの展開が必要であるため、NSX Edgeが使用するVLANを用意する必要があります。

ネットワーク名がパラメータシートと一致しているため、そのまま流用できて便利です

このように、VCFの計画段階で、想定している構成を具体的な形にできるのがPlanning and Preparation Workbookの利点です。

---

まとめ

VCFはまだ「サイロを統合した製品」というより、「管理されたサイロを実現するための製品」に近いと思います。プラットフォームや簡単という言葉を目にしても、含まれる機能（製品）を漏れなく知らないと始められないといった実情もあるかと思います。

Planning and Preparation Workbookは部分的に分からない製品があろうとも机上で形が作れるので、ステップとして優れていると思います。また、個別には理解していても、SDDC Managerで統合管理する場合のお作法はまだ把握していない場合も時短になります。

信頼に値するかと評価し始めるより、まずは叩きとして使ってみようとするのが、付き合い始め方としてよさそうです。

vSphere 管理者に優しい Carbon Black Cloud Workload

この投稿は、vExperts Advent Calendar 2023 の7日目です。

adventar.org

今回は、vSphere管理者にとってCarbon Black Cloud Workloadの何が良いのかを説明してみます。「なぜ Carbon Black Cloud "Workload" なのか？」に答える要点を抑えることができたのではないかと思います。

vSphere環境のリスク管理と向き合う

Carbon Black Cloud WorkloadはvSphere環境における「リスク管理」に活用できます。

リスクは脅威と脆弱性と資産の3要素で構成されています。脅威は組織によってコントロールできないため、脆弱性と資産の2要素がリスクをコントロールできる要素となります。また、資産はビジネスの核であることが多く、セキュリティ要件のみで可用性を制限するのは困難です。実質的には脆弱性のみがリスクをコントロールできる要素であるといえます。

そのため、多くの組織ではできる限り脆弱性をつぶし、安全に資産を保有するため、リスク管理を徹底するコンプライアンス型のアプローチが採用されています。あるべきセキュリティレベルと現時点でのセキュリティレベルを比較し、そのギャップを解消する方法です。具体的には、NIST Cyber Security Frameworkなどのセキュリティガイドラインが、あるべきセキュリティレベルの基準として参照されます。

vSphere環境においてもリスクは潜在しています。リスクが顕在化するのを回避・低減するには、資産である仮想マシンと内在する脆弱性を特定することが重要です。組織のセキュリティレベルは最も低い箇所に依存するため、vSphere環境のリスク管理を徹底することが、組織のセキュリティレベル向上に貢献するわけです。

しかし、リスク管理を徹底するには課題もあります。例えば、資産の棚卸や脆弱性の調査・分析には膨大な管理コストがかかり、限られたセキュリティリソース（ヒト、モノ、カネ、時間など）で対応するには、手を付けられる領域が制限されてしまいます。社外への持ち出しが想定されるPCより外部公開されていないサーバーが後回しにされる傾向にあるのは、このような背景も影響していることでしょう。

Carbon Black Cloud Workloadでできること

Carbon Black Cloud Workloadは、vSphere環境のリスク管理をvSphere管理者が実施する上で非常に有用なツールです。これがすべてではないですが、例えば、以下の項目がCarbon Black Cloud Workloadによって実現されます。

• vSphereインベントリの仮想マシンの可視化
• CBCセンサーのインストールステータスの確認
• CBCセンサーが未インストールな仮想マシンの可視化
• CBCセンサーをGUIからワンクリックインストール
• CBCセンサーをGUIからワンクリックアップデート
• CBCセンサーがインストールされた仮想マシンのクローンをサポート
• リスク評価ダッシュボードの表示（脆弱性管理）
• 脆弱性アセスメント
• 脆弱性の詳細情報の表示
• 脆弱性の修正情報へのリンクの提供
• 脆弱性が発見された仮想マシンのリスト表示
• 削除された仮想マシンをCBCコンソールから自動登録解除

そして、これらの項目がすべてvSphere Clientから操作できる点が優秀です。構成としては、vSphere環境へCarbon Black Cloud Workloadアプライアンスの展開と連携を完了することで、vCenter ServerでCarbon Black Cloud Workload Plug-inを表示できるようになります。

このように、Carbon Black Cloud WorkloadはvSphere環境の資産と脆弱性を特定することができ、保護対象の漏れに気づけたり、ライフサイクル管理を改善できたり、脆弱性修正の優先度を示してくれたり、といったリスク管理の遂行を容易にしてくれるツールとなっています。

管理者と環境に適した選択

ここまで、vSphere環境においてもリスク管理は重要であること、管理コストやセキュリティリソースには課題があること、Carbon Black Cloud Workloadでできることを説明しました。

vSphere管理者にとってCarbon Black Cloud Workloadには、やらなきゃいけないリスク管理を低い管理コストとリソースで実行できる良さがあります。サーバー環境のセキュリティ対策には、NGAVやEDRなどがよく検討されるかと思いますが、個人的にはリスク管理の徹底を優先した方が組織のセキュリティレベル向上に効果的であると考えます。そして、vSphere環境においてvSphere管理者がリスク管理を行う場合は、Carbon Black Cloud Workloadを活用するのが効率的であると思います。

Carbon Black Cloud - NGAVとEDRの違い

この投稿は、vExperts Advent Calendar 2021の12日目です。

adventar.org

Carbon Black Cloudについて説明していると、「NGAVとEDRって何が違うの」という質問を多く受けます。特にCarbon Black Cloudの場合、Carbon Black Cloud "Endpoint"でもCarbon Black Cloud "Workload"でもNGAVとEDRは同一エディションで提供されます。そのため、NGAVとEDRは常にどちらも使える状態であり、実際製品をさわってみるとこの設定値はNGAVに影響するのか、このアラートはEDRによるものなのか、と混乱するわけです。NGAVのみを安価に提供するCarbon Black Cloud Preventionも登場しており、これ以上混乱しないためにも、一度立ち止まってCarbon Black Cloudの基礎をおさらいしてみようと思います。

エンドポイントセキュリティのおさらい

昨今はどのセキュリティベンダーも「エンドポイントセキュリティ」というキーワードを使用しています。VMwareビジネスに携わる方だとエンドポイントと聞くとWorkspace OneのイメージがあるのでクライアントPCやスマートデバイス、タブレットを思い浮かべる方が多いかもしれませんが、セキュリティ領域においてはサーバーもエンドポイントに含まれます。このようなエンドポイントを保護することを目的としたセキュリティソフトウェアの総称として普及しているのがEPP(Endpoint Protection Platform)であり、わかりやすい機能としてはAV(Antivirus)が挙げられます。

AVはあらかじめマルウェアの特徴を登録したデータベースをセキュリティソフトウェア内に持ち、この情報と検査対象のファイルを逐一比較するパターンマッチ方式が用いられています。これは登録されているものを確実に防げるメリットはありますが、登録されていないものは防げないデメリットがありました。そこで、データベースへの登録有無を問わずマルウェアを防ぎたいというニーズへ応えるように登場したのがNGAV(Next Generation Antivirus)です。

NGAVはマルウェア特有の動作を手がかりにマルウェアを検知する機能であり、従来のAVで使われたパターンマッチング方式とは異なり、振る舞い検知やAI・機械学習といった技術を用いてマルウェアと疑わしいものを検知・ブロックします。正直、NGAVについては絶対にこうあるべしと決まった姿があるわけではないので、セキュリティベンダーによってNGAVの技術や検知レベルは異なります、ユーザーからするとブラックボックス化していることも少なくありません。しかし、AVでは防げなかった亜種などの未知のマルウェアを防げるよう進化しているため、ほとんどの企業で導入されています。

EPP製品ではマルウェア対策を目的としたAVやNGAVといった機能のほかに、不正アクセス対策を目的としたFWやIPS/IDS、悪意あるURLからの保護を目的としたWebフィルタリングなどが実装されていることがあります。これは特定の脅威に対応する防御機能を実装することでエンドポイントのセキュリティ強度を高める目的があり、どんな機能がEPP製品に内包されているかはセキュリティベンダーにより異なります。しかし、どれだけ強力なEPP製品であってもマルウェア感染を100%防ぐことはできません。

よく複数のセキュリティソフトウェア製品を横並びにしてマルウェアの検知率を比較している光景を見ますが、検知率が99.5%だろうが99.9%だろうが100%でなければ誤差でしかありません。既知のマルウェアをお手本に作成したマルウェアをどれだけNGAVに検知させたところで、世界のトップハッカー組織が作成する全く未知のマルウェアには感染することでしょう。

マルウェア感染を100%防ぐことができないのであれば、マルウェア感染後の被害をどう食い止めるかが課題となり、そこで登場したのがEDR(Endpoint Detection and Response)です。EDRとは、エンドポイントの動作を記録・監視し、サイバー攻撃を発見次第すぐに対処することを目的としたセキュリティソフトウェア総称です。EPP製品はマルウェア感染を防ぐことを目的に、さまざまな脅威を「点」で捉え防御機能を提供していました。それに対してEDR製品は攻撃者による一連のサイバー攻撃を「線」で捉え脅威を検知し適切な対処を行うための機能を提供します。サイバー攻撃を検知・対処した後も、被害の原因調査や今後のセキュリティ対策へ分析結果を反映させることが可能です。基本的にEDR製品は検知後の調査、分析、復旧といった対処は人力で行うため、EPP製品に比べると導入後の運用が重要となります。

EDRの説明をするとEPPを代替できるかと聞かれることが多いですが、答えとしてはどちらも必要です。EDRは検知件数が増加すると対処に必要な工数が増加するため、そもそもEPPで防げるものは防ぐすべきです。そういった意味ではEPPとEDRは補完関係にあるといえます。実際、EPPベンダーの多くはEDRを提供し始めており、EDRベンダーの製品にはNGAV機能が必ずと言っていいほど含まれています。

MITRE社によるATT&CK Frameworkの公開で攻撃者の攻撃手法や戦術に対する理解が広まる中、エンドポイントのイベントログを収集することでサイバー攻撃の脅威をリアルタイムで検知し対処することが可能なEDRには注目が集まっています。また、国内においては2022年4月に全面施行される改正個人情報保護法に対応するため、法人におけるサイバー攻撃被害の説明責任能力が問われており、サイバー攻撃被害の可視化ができるEDRの需要が高まっています。

Carbon Black CloudのNGAV

Carbon Black CloudのNGAVはアプリケーションの振る舞いを検知して防御する仕組みとなっています。EPP製品に実装されているNGAVとの違いは、EPP製品が"マルウェア"のデータベースを利用しているのに対し、Carbon Black Cloudは"レピュテーション"のデータベースを利用している点にあります。レピュテーションとはアプリケーションの信頼度を11段階で評価したものであり、全てのアプリケーションには特定のレピュテーションが付与されます。レピュテーションの付与はCarbon Black Sensorをエンドポイントへインストールしたタイミングでバックグラウンドスキャンで実行されます。Carbon Black Cloudではポリシーと呼ばれる設定によって、「どんなレピュテーションが付与されたアプリケーションが、どんな振る舞いをしたときに、どんなアクションを実行するか」を定義することで、条件を満たす攻撃が発生した際にその攻撃を防ぐことが可能です。

フルクラウドモデルのCarbon Black Cloudはクラウドのデータベースを参照する"クラウドレピュテーション"を利用することが基本となる製品ですが、エンドポイントがオフライン状態であったとしても動作するローカルのデータベースとして"ローカルレピュテーション"を提供しています。ローカルレピュテーションはローカルスキャンと呼ばれる設定を有効化することで利用可能です。ローカルスキャンを有効化したエンドポイントではローカルにシグネチャをダウンロードし、そのシグネチャを参照することでアプリケーションにレピュテーションを付与します。

クラウドレピュテーションは不明なアプリケーションを検出した際にレピュテーションを取得するためクラウドへの軽微な通信が発生します、一方、ローカルレピュテーションはローカルにシグネチャをダウンロードしてスキャンを実行するため、クラウドレピュテーションに比べOSに負荷がかかります。これはあくまでもレピュテーションの取得を行うだけなので、ファイルをデータベースと逐一比較するパターンマッチ方式に比べれば負荷は小さいです。

Carbon Black CloudのNGAV以外の防御機能

Carbon Black CloudにはNGAV以外にDynamic Rule Engineという防御機能があります。NGAVはレピュテーションをベースとしたアプリケーションの振る舞い検知とその防御を提供する機能で、ユーザーがポリシーを設定することで利用可能なものでした。Dynamic Rule EngineはVMware社のTAU(Threat Analysis Unit)と呼ばれる脅威分析チームが配信する検知・防御ルールで、どんなポリシーを設定していたとしても自動的に適用される防御機能となっています。Dynamic Rule Engineはランサムウェアや認証情報窃取といった脅威に対するルールの配信や、PowerShell、Wscript等を用いた攻撃を防ぐ機能で、AMSI(Antimalware Scan Interface)もサポートしています。

このようにCarbon Black Cloudではユーザーによって設定するNGAV以外にも、セキュリティのプロ集団が提供するDynamic Rule Engineを防御機能として利用でき、また、ランサムウェア対策においてはCanaryファイルと呼ばれるおとりファイルを用いた攻撃の検知なども可能となっています。

Carbon Black CloudのEDR

Carbon Black CloudのEDRはエンドポイントのプロセスのイベントログをクラウドに収集し分析されます。分析によって脅威が検出された場合にはアラートが発報され、管理者はアラートの内容を確認して必要な対処を行います。基本的にEDRは検知するまでは自動ですが、その後の調査や対処は人力で行うことになります。Carbon Black Cloudではこの対処を行う際に便利な様々な機能をGUIコンソールから実行することが可能となっています。例えば、初動対応としてのエンドポイントの隔離や、脅威に該当するアプリケーションの削除、Live Responseによるリモートアクセスとコマンドの実行などが可能です。

より具体的なログの調査方法、アラートの分析方法、各種対処の実行方法などはまた別の機会に説明しようと思いますが、今回はCarbon Black Cloudには2種類のEDRがあることに触れておきたいと思います。

Carbon Black Cloudは購入するエディションによってBehavioral EDRまたはEnterprise EDRを利用できます。Behavioral EDR(旧製品名：CB Defense)とEnterprise EDR(旧製品名：CB ThreatHunter)は元々異なる製品として提供されていた背景もあり、収集するログ量に違いがあります。実際に通信量を計測してみると、Behavioral EDRが5〜10MB/Day、Enterprise EDRが20〜30MB/Dayとなっています(数値はあくまで目安です)。Carbon Black Cloudでよく受ける質問にこれらEDRの違いは何かと聞かれることが多いのですが、シンプルにログ量が異なっており、GUIでも異なる調査画面でログを確認可能です。このことからも分かるとおり、Carbon Black Cloudの製品提案でよく聞くプロセスの全ログ取得というのは実はEnterprise EDRを指していることになります。

このような情報を知ると、ログ量に違いがあるのであれば当然Enterprise EDRが優れておりBehavioral EDRでは不足していると評価しがちですが、実際はBehavioral EDRのログ量でも検知には十分であることが多いです。ログ量の違いは検知よりも調査や分析に影響する要因であるため、セキュリティアナリストが調査し分析するには魅力的かもしれませんが、人ではなくクラウドによる分析結果をもとに対処を行う運用なのであれば膨大なログはかえって煩雑なものとなってしまいます。そのため、実際にどのように運用するかを考えた上で必要十分なエディションを選択することが望ましいです。

さいごに

今回はNGAVやEDRに注目してCarbon Black Cloudの基礎をおさらいしてみました。

個人的にセキュリティ製品は「わかった気になるけど、実はわかっていない」ということが多いなと感じています。実際に受ける質問も基礎的な内容が多いです。新しく先進的なものに目が行くのはエンジニアの性ですが、実はわかっていないまま迷子になってしまわないよう本投稿をご活用いただければ幸いです。

Carbon Black Cloudの脆弱性管理について考える

2021年10月時点で、Carbon Black Cloud EndpointのAdvancedエディション以上と、Carbon Black Cloud Workloadの全てのエディションではNGAVやEDRに並び脆弱性管理(Vulnerability Management)という機能が使えます。

ただ、脆弱性管理と言われても具体的に何ができるのか、すぐにはわからない方もいるのではないかと思います。少なくとも、私はvSphereなどの仮想化テクノロジーに関わる仕事をしておりましたが、セキュリティに詳しいわけではありませんでした。なので、脆弱性と聞いても、メーカーから通知される製品の脆弱性情報を確認し、管理している環境に影響があるかを調査し、問題があれば推奨されるバージョンへのアップグレードやセキュリティパッチを当てるという対処をしていた程度です。Google検索すると脆弱性"管理"以外にも脆弱性"評価"、脆弱性"診断"(セキュリティ診断)、といった似たような単語も出てきてわかりづらかったので調べたことをまとめ、Carbon Black Cloudで何ができるのかを紐解いてみたいと思います。

そもそも脆弱性とは？

"脆弱性とは、コンピュータに存在する情報セキュリティ上の欠陥をいう" そうです。様々な機関やセキュリティベンダーが「脆弱性とは？」について解説してくれているため詳細な定義についてはそちらを参照いただければと思いますが、OS、ミドルウェア、アプリケーション、ネットワークなど、さまざまなプログラムの不具合や設計上のミスが原因となって発生した情報セキュリティ上の欠陥を指しています。誰にとっての脆弱性なのかというと、攻撃に悪用可能な脆くて弱い部分と受け取れますので、攻撃者にとっての脆弱性なわけです。

脆弱性"管理"とは？

脆弱性管理とGoogle検索すると2009年に発売されたPark Foreman著書のVulnerabulity Managementという本がよく参照されており、その中で、"脆弱性管理は、ソフトウェアの脆弱性を「識別、分類、優先順位付け、修正、および軽減する循環的な慣行」のこと" としています。

「脆弱性」は個人や組織によらないコンピュータ自体に内在する弱点のことでしたが、「脆弱性管理」は個人というよりは組織におけるコンピュータセキュリティやネットワークセキュリティに不可欠な要素であることがわかります。脆弱性管理は、脆弱性に対する、より具体的な管理方法(識別、分類、優先順位付け、修正、および軽減)について言及しています。

また、脆弱性管理の特徴としては、組織における脆弱性を"継続的"に管理することを目的としたツールを導入することが多いです。

脆弱性"評価"や脆弱性"診断"との違いは？

脆弱性評価や脆弱性診断も組織における脆弱性の管理方法について取り扱っている点においては脆弱性管理と近いものがあります。しかし、多くの場合、脆弱性評価や脆弱性診断には特定の開始日と終了日があります。つまり、これらは期間が決まっているプロジェクトであり、その特性からもサービス化がしやすいため、単発または定期的な契約で外注しやすいものになっています。この点においては、組織の脆弱性を"継続的"に管理することを目的とした脆弱性管理とは対照的と言えます。脆弱性診断では最終的には脆弱性レポートの納品、脆弱性評価では既知の脆弱性の特定や分析に加え、侵入テスト(ぺネトレーションテスト)による検証までを含むことが一般的なようです。当然、サービス提供者やセキュリティベンダーによってその内容は異なるため、必ずしもこのようになっているというわけではありませんが、大まかな違いを知る上では参考になるのではないでしょうか。

このように期間が決まっている脆弱性評価や脆弱性診断では脆弱性管理にはない考慮すべきセキュリティ上の問題があります。それは脆弱性評価や脆弱性診断の結果が厳密にいうと最新の情報ではないことです。細かい話だと思われるかもしれませんが、そもそも脆弱性とは攻撃者に悪用される可能性がある欠陥であったはずです。そのためには、攻撃者が不正アクセスやサイバーセキュリティ侵害に悪用する前にセキュリティの脆弱性を特定し、修正することが重要です。脆弱性管理は、組織のセキュリティの脆弱性を長期的に管理することを目的とした継続的なプロセスであるため、脆弱性への本来あるべき対応を実現しやすいのではないかと思います。内製化せずに外注できる点はコストカットできるメリットがあるかもしれませんが、この点においては、組織として実現すべきセキュリティの強度を考慮した選択が求められます。

Carbon Black Cloudの脆弱性管理は何ができる？

Carbon Black Cloudは脆弱性管理以外にもNGAVやEDRといったセキュリティ機能を提供するフルクラウドモデルのセキュリティ製品です。Carbon Black Sensorと呼ばれるソフトウェアをサポート対象のOSにインストールすることでコンピュータ上の様々な情報を取得します。そのため、インストール直後から脆弱性情報を取得することができ、24時間おきに情報は自動更新されます(手動による即時更新も可能)。

取得した情報はクラウドに集約され、CVSSやKennna Securityの脆弱性データベースと照らし合わせ、脆弱性の識別、分類、優先順位付けなどを行い、それぞれの脆弱性に対する対処方法のリソース(例：該当するセキュリティパッチを提供するベンダーサイトへのリンクなど)と共に分析結果を管理者に提示します。管理者は結果をGUIから確認し、提示された対処方法に沿って対応を行うことでコンピュータの脆弱性に対処することが可能です。

このようにCarbon Black Cloudは脆弱性管理で求められる機能を提供することが可能なツールであり、24時間おきに自動更新される情報をもとに組織の脆弱性を"継続的"に管理することが可能です。

Carbon Black Cloudは、エンドポイントを対象としたCarbon Black Cloud Endpoint(以下、CBCE)と、vSphere環境に特化したCarbon Black Cloud Workload(以下、CBCW)のいずれの製品においても、上記した脆弱性管理機能は利用可能で、サポート対象のOSも共通しています。

参考：Carbon Black Cloud Sensor Support

仮想化ユーザーに嬉しいポイントとして、CBCWではvCenter Serverと連携することでvSphere Clientからセンサーのインストールや脆弱性情報を確認することが可能です。これにより、インフラエンジニアとセキュリティエンジニアが異なる組織であったとしても、インフラエンジニアが仮想マシンのデプロイプロセスのなかでコンピュータの脆弱性を排除することが可能です。

さいごに

今回はそもそも脆弱性管理とは何かというところからCarbon Black Cloudの脆弱性管理についてまとめてみました。

脆弱性管理においては継続性に加えて網羅的なインベントリが重要視されるのではないかと思います。Carbon Black Cloudは幅広いクライアントOSやサーバーOSをサポートしておりますが、組織においてはスマートデバイスやネットワーク機器なども利用され、それらにも脆弱性はあります。ITインフラ全体でセキュリティの脆弱性を管理するには、単一のツールでは限界があるため、Carbon Black Cloudのインベントリに含めることができない資産をどのように管理するか、製品領域が多岐に渡るVMwareだからこその連携ソリューションが増えてくることを個人的には期待しています。

VMware Carbon Black Cloud のポリシー

今回はCarbon Black Cloud(以下、CBC)のポリシーについて掘り下げていきます。

VMware Carbon Black Cloud Endpoint Standard以上、あるいはVMware Carbon Black Cloud Workload Advanced以上のライセンスを購入していれば、NGAVとBehavior EDRの機能が含まれています。NGAVによりエンドポイント(クライアントデバイス、サーバー、VDIなど)を保護する場合は「ポリシー」を設定します。

CBCでは「ポリシー」を使用して、エンドポイント上でのアプリケーションの動作方法に関するルールの定義および優先度設定を行うことができます。Carbon Blackセンサーをインストールしたエンドポイントには必ず1つのポリシーを設定します。ポリシーの設定はインストールオプションによって指定することが可能ですが、インストール後にCabon Black Console(GUI)から変更可能なので、インストール時のポリシー選択ミスが原因でセンサーを再インストールする必要はありません。 

CBCは初期状態で「Monitored」「Standard」「Advanced」という3種類のプリセットポリシーが用意されており、これらをそのまま使用することも、コピーしてカスタムポリシーを作成することも可能です。作成したポリシーは複数のエンドポイントに設定できるため、エンドポイントを属性別にグループピングし、そのグループに適したカスタムポリシーを作成して管理することをおすすめします。これは従業員が使用するクライアントデバイスと、Webサービスなどを提供するようなサーバーでは適用すべきルールが異なるためです。また、VMware Horizonを使用したVDI環境には通常のクライアントデバイスとは異なる推奨設定があるため、VDIについても個別のポリシーを作成した方が良いです。

ポリシーの設定項目

ポリシーの設定は「一般」「防止」「ローカルスキャン」「センサー」の4項目に分かれています。

「一般」はポリシー名などを設定できます、他の項目に比べると特筆すべきことはありません。

「防止」はエンドポイント上でセンサーがプロセスの動作を制御する方法を定義する項目です。
「許可」は監視やブロックルールから除外するためのルールです。主にCBC以外のアンチウイルスソフトと共存させる場合やアプリケーション競合が発生した際に監視対象から除外する際に使用します。
「ブロックおよび隔離」はプロセスやアプリケーションの振る舞いを制御するルールです。これは特に重要なポイントとなるので、詳細については後述します。
「USBデバイスのブロック」は未認証なUSBデバイスへのアクセスをブロックするルールです。
「アップロード」は指定したパスからのアップロードの可否を制御するルールです。

「ローカルスキャン」はWindows OSでのシグネチャを用いたファイルのスキャンを制御する項目です。基本的にクラウドベースのアーキテクチャであるCBCは、センサーがエンドポイントの全ログを取得しクラウドへ転送、スキャンはクラウド側で実行します。しかし、ローカルスキャンはエンドポイントがオフラインであっても動作するため、セキュリティ強度を高めたい場合に有効化します。ローカルスキャンを有効化したエンドポイントはローカルのCPUとメモリを消費してスキャンを実行するため、無効化した場合と比較してローカルリソースの消費が増加します。ローカルスキャンで用いられるシグネチャはクラウド側で実行されるスキャンとは中身が異なるため、後述するクラウドの「レピュテーション」とは異なる点にご注意ください。

「センサー」はCarbon Blackセンサーの運用に関連する設定を制御する項目です。業務上、質問されることの多い設定にフォーカスして解説します。

「バックグラウンドスキャンを実行」についてはセンサーの初回インストール時に全ファイルのスキャンを実行するか否かと、その速度を設定できます。スキャン中はエンドポイントのCPU、メモリ、ディスクIOなどが増加するため、複数日かかるが比較的負荷が低い「標準」か、最短処理だが比較的負荷が高い「高速」を選択します。
「Windows セキュリティセンターの使用」はWindowsセキュリティセンターで、CBCをアンチウイルスソフトとして認識させる場合に有効化します。
「次の期間、非アクティブ状態の VDI センサーの登録を自動に取り消します」はインスタントクローンのように非永続的なVDIプールに対して有効化することをおすすめします。これは自動削除されたVDIの登録情報がCBCに残ってしまうことを避けるための設定です。
「センサーのアンインストールにコードが必要」はエンドポイント側でセンサーを自由にアンインストールすることを避けるための設定です。有効化すると、CBC上で確認できるアンインストールコードを入力しないと、エンドポイント側で自由にセンサーのアンインストールを実行できません。
「Live Responseを有効化」は遠隔から管理者がリモートアクセスしてエンドポイントの対処を必要とする場合に有効化します。

「ブロックおよび隔離」ルールと「レピュテーション」

 「ブロックおよび隔離」ルールは「プロセス」「操作の試行」「アクション」の3要素を組み合わせて作成します。そのため、特定のプロセスやアプリケーションが、どのような振る舞いをした時に、どのようなアクションを実行すべきかを決める必要があります。そして、そのためにはCBCの根幹である「レピュテーション」を理解する必要があります。

「レピュテーション」は直訳すると評判という意味になりますが、CBCにおける「レピュテーション」はアプリケーションの信頼性を示しています。CBCでは11種類のレピュテーションとその優先度が定義されており、エンドポイント上で実行された全てのアプリケーションは11段階のいずれかのレピュテーションが付与されることになります。

参考：Endpoint Standard: Reputation Priority - Carbon Black Community

単一のアプリケーションに対して複数のレピュテーションが付与された場合、優先度の数字が小さいものが適用されます。例えば、CBCでNot Listed/Adaptive Whiteが付与されたアプリケーションであっても、企業のセキュリティ管理者が対象のアプリケーションを手動でハッシュ登録すれば、Company AllowedまたはCompany Bannedを優先して適用することが可能です。
このように、「CBCはアプリケーションにレピュテーションを付与する」ということを理解したところで、改めて「ブロックおよび隔離」ルールを見てみましょう。

「プロセス」の列に注目してください。各項目がレピュテーションの内容と合致しています。これは、CBCはレピュテーションに対してブロックルールを設定するということを示しています。例外的に「パスにあるアプリケーション」は悪用されやすいアプリケーションを直接パス指定して設定します。

「操作の試行」と「アクション」はチェックボックスを選択して設定します。企業によってエンドポイントの動作環境やアプリケーションは異なるため、ここまで説明したような柔軟なルール設定が可能であることは大きなメリットとなります。

導入初期からセキュリティ強度を確保するために厳密なルールを設定することもできますが、その場合、過検知や誤検知により業務の弊害となる可能性が考えられます。そのため、導入後にセキュリティ強度を上げることにハードルが無い組織文化であれば、センサーインストール直後はエンドポイントを監視するにとどめ、段階的にセキュリティ強度を上げる方法がおすすめです。

さいごに

今回はCBCのポリシーについてお伝えしました。ポリシーで設定できる具体的な内容を画面イメージと合わせてご確認いただけたのではないでしょうか。

また、レピュテーションについてもお伝えしました。CBCは、従来のEPP製品のようなブラックリスト方式の製品ではなく、アプリケーションのレピュテーションベースの製品でることをご理解いただけたのではないかと思います。一般的にNGAVといえばマルウェアのハッシュに加え亜種も機械学習によって検知できるイメージですが、EDRベンダーのCBCはレピュテーションを活用して検知するため、防御する目的は同じであってもアプローチが異なります。
個人的には、攻撃が高度化し、日々変動し続ける現代社会において、「ブラックリストのビッグデータ」より「アプリケーションの信頼性のビッグデータ」の方が価値が高く思えますが、市場がこれをどのように評価するかは注目していきたいです。

VMware Carbon Black Cloud はじめの手引き

本記事はvExperts Advent Calender 2020の15日目です。

はじめに

EDRを触ったこともない仮想化エンジニアが、VMware Carbon Black Cloud(以下CBC)を触る機会に恵まれたので、学んだことを順次共有していければと考えています。今回は、はじめの手引きということでCBCの構築についてお伝えします。CBCはクラウド製品のため、他のVMware製品に比べて触れる機会が少ないのが現状かと思います。VMware Handson Labにもカタログは存在しますがシミュレーターのようでしたので、可能な限り実機のスクショを交えてお伝えしていければと思います。

なお、私は仕事でVMware製品を拡販していますが、本ブログは所属会社に一切関係ありませんのでご了承ください。

Carbon Black Cloudへのログイン

はじめに、CBCは管理コンソールへログインしないと何も始まりません。CBCを購入するとVMwareから以下のようなメールが届くので、オレンジ色のConfirm my AccountをクリックしてCBCのリンクへ飛びます。

初回はアカウントのパスワード設定がありますが、設定が終わると以下のログイン画面へ遷移し、ログインできます。

新しいユーザーを追加する場合は、メールアドレスの入力とロールの選択が必須です。管理コンソールでユーザーを作成すると指定されたメールアドレスへアクティベートメールが送信されるので、先ほどと同じようにパスワード設定することでログインできます。

設定＞ユーザー＞ユーザーを追加

CBCのログインURLとユーザーアカウントについて補足します。たまたま複数のCBC環境を見る機会があったのですが、以下のような関係が見られました。

この図は、管理者が3つの異なるCBC環境(図中ではテナントとしています)へログインしていることを表現しています。まず、URLの数に注目してください。テナントは3つにもかかわらず、URLは2つです。この事実から、CBCは単一のURLで提供されているサービスではないことがわかります。テナントAとBは同一のURLなので、購入時点で複数のURLから1つ割り当てられるものと思われます。次に、ユーザーアカウントに注目してください。テナントAへはユーザーAでログインし、テナントBへはユーザーBでログインしています。テナントAとBはURLが同一であるため、ユーザーを分けることでログイン先のテナントを指定しているわけです。この状態で、テナントBへユーザーAを登録すると、テナントBへログインしたくてもテナントAへログインしてしまいます。基本的に複数のCBC環境を購入することは考えられませんが、PoCと本番とで異なる環境を使用する場合などにURLが同じだとユーザーの重複が問題となる可能性があります。なお、Gmailなどのエイリアス機能を使用すればログインユーザー名が変わることとなるため、この問題は回避できます。

Carbon Black Sensorのインストール

CBCでは管理対象にCarbon Black Sensor(以下CB Sensor)をインストールする必要があります。インストーラーは管理コンソール上で入手可能です。

インベントリ＞エンドポイント＞センサーオプション＞センサーキットをダウンロード

サポートされているインストール対象OSのリストについては以下のURLを参照ください。Carbon Black Communityのアカウント作成が必要となります。

https://community.carbonblack.com/t5/Documentation-Downloads/Carbon-Black-Cloud-sensor-support/ta-p/66274

VMware HorizonのVDI環境にインストールする場合は、以下の互換性情報にご注意ください。マスターイメージへのCB Sensorインストール方法も書いてあります。

https://kb.vmware.com/s/article/79180

CB Sensorのインストール方法は2つあります。Attended Install(GUI)とUnattended Install(CLI)です。Attended Installは招待メールによるインストール方法で、正直、あまり使われないと思います。Unattended Installは配布ツールなどを用いたインストール方法で、コマンドによるオプションをつけることができます。以下はUnattended Installでインストールした様子です。

• コマンドプロンプトは管理者として実行
• [sc query cbdefense] でCB Sensorの状態を確認、STATEがRUNNINGであればインストール完了
• [msiexec]で始まっている部分がインストールコマンド
• 今回実行したオプションの意味
  [/q] サイレントインストール
  [/i] インストールファイルのディレクトリ指定、ダウンロードしたセンサーキットのパスが続きます
  [/L] 詳細インストールログの出力指定
  [COMPANY_CODE] 登録先CBC環境(テナント)の指定
  [GROUP_NAME] インストール時のポリシーの指定
  [CLI_USERS] 管理用コマンドの有効化
  [CURL_CRL_CHECK] CRLチェック、0で無効化

以上でCB Sensorのインストールは完了です。これでデバイスはCarbon Blackによって保護されている状態となりました。

CB Sensorをインストールする端末には必ずポリシーを適用する必要があります。今回は事前に「test-policy」というポリシーを作成した上で、[GROUP_NAME]オプションで指定していますが、何も指定しない場合には、予め用意されている「Standard」が適用されます。

さいごに

今回はCBCへのログインとCB Sensorのインストールについてお伝えしました。CBCは他のVMware製品に比べて、非常に少ないステップで構築できることが分かります。今回は説明できていませんが、CBCにおいてポリシーは非常に重要な要素です。防御ルール、ローカルスキャンの有効化、シグネチャの更新、他のAV製品のバイパスなど様々な設定をポリシーで行うこととなるため、次回はポリシーについて深掘りしていこうと思います。