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)から変更可能なので、インストール時のポリシー選択ミスが原因でセンサーを再インストールする必要はありません。 

f:id:kncyd13:20210601235630p:plain

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

ポリシーの設定項目

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

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

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

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

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

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

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

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

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

f:id:kncyd13:20210601235905p:plain
参考:Endpoint Standard: Reputation Priority - Carbon Black Community

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

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

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

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

さいごに

今回は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のリンクへ飛びます。

f:id:kncyd13:20201215220637p:plain

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

f:id:kncyd13:20201215220825p:plain

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

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

f:id:kncyd13:20201215220946p:plain

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

f:id:kncyd13:20201215221057p:plain

この図は、管理者が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)をインストールする必要があります。インストーラーは管理コンソール上で入手可能です。

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

f:id:kncyd13:20201215221312p:plain

サポートされているインストール対象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でインストールした様子です。

f:id:kncyd13:20201215222157p:plain

  • コマンドプロンプトは管理者として実行
  • [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によって保護されている状態となりました。

f:id:kncyd13:20201215230139p:plain

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

f:id:kncyd13:20201215231100p:plain

さいごに

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

NSX-T Edge のポイント

2020年に入り、VMware NSX-Tがこれまで以上に注目されています。また、それには様々な理由があると感じています。主だった要因としては、VMC on AWSに代表されるVMware Cloudに採用されていること、VCFに含まれていること、vSphere 7 with Kubernetesに必須のインフラであること、更改時期を迎えているVDI環境のインターネット分離に必要なこと、などが挙げられるのではないでしょうか。

そして、注目度が高まるにつれ、NSX-Tのキャッチアップを始める方が増えていると感じます。NSX-TはNSX-vを知っていたとしても難しく感じます。なので、少しでも理解が深まるようなポイントを取り上げて解説していきます。今回はNSX-T Edgeです。

私は仕事でVMware製品を拡販していますが、本ブログは所属会社に一切関係ありませんのでご了承ください。ただのエンジニアとして情報をアウトプットし、その結果、誰かの助けになれば嬉しいなというモチベーションで書いてます。

また、本ブログはNSX-T 3.0時点の情報で書かれています。アーキテクチャコンポーネント、単語などの解説は含まれていないため、VMware Docs等で補完していただければと思います。

VMware NSX-T Data Center のドキュメント

 Edge はあくまでリソース

Edgeは仮想マシンとしてvSphere環境にデプロイするか、物理サーバにインストールします。今回は、仮想マシンを想定します。Edgeは関連するサービスを提供するためにCPU、メモリ、ストレージといったリソースが必要なため、仮想ハードウェアでこれらを提供します。あくまでリソースなので、環境の規模や使用するサービスに応じてサイジングが必要となります。

EdgeサイズはSmall、Medium、Large、Extra Largeから選択します。サイジングの目安としては以下のイメージです。

  • Small:ラボやPoc
  • Medium:ハイパーバイザー64台以下の本番環境
  • Large:ハイパーバイザー64台以上の本番環境、または、ロードバランサを使用する場合
  • Extra Large:ロードバランサの負荷が高くリソースがLargeで足りない場合、または、URLフィルタリングやL7ファイアウォールといったアドバンスサービスを使用する場合

リソース要件やサイジングの公式ドキュメントは以下リンク先を参照してご確認ください。

NSX Edge 仮想マシンのシステム要件

実際にTier-0ゲートウェイなどをEdgeにホストする場合、Edgeではなく、Edge Clusterを選択します。Edge Clusterは複数台のEdgeを束ねたオブジェクトです。仮に、Edgeが1台だけであったとしても、Edge Clusterには追加する必要があります。

f:id:kncyd13:20200830221311p:plain

Edgeは物理ネットワークとの接続点

例えば、NSX-Tで自由にオーバーレイネットワークを構築しても、物理ネットワークとの接続点がなければインターネットを含む物理環境とアクセスできません。EdgeはvNICを仮想スイッチに接続することでオーバーレイネットワークと物理ネットワークを繋げます。Edgeには計4つのvNICがあり、それぞれEdge内部のインターフェイスとリンクしています。

詳細については以下リンク先を参照ください。

NSX Edge のネットワーク設定

eth0は管理ネットワークで固定ですが、あとはEdgeが属するトランスポートゾーンで変わります。仮に、Edgeがオーバーレイトランスポートゾーンに属する場合、fp-eth0はOverlay N-VDSにリンクされます。EdgeがVLANトランスポートゾーンに属する場合、fp-eth1はVLAN N-VDSのアップリンクセグメントにリンクされます。そして、冗長構成を目的に、Edgeが物理ネットワークと2つの接続点を持つ場合、fp-eth2もVLAN N-VDSのアップリンクセグメントにリンクされます。冗長化が目的のため、fp-eth1とfp-eth2は異なるVLANに設定します。

f:id:kncyd13:20200830233537p:plain

続いて、2台のEdgeが追加されたEdge Clusterに、Tier-0ゲートウェイをホストした構成のアップリンク接続について考えてみます。Tier-0ゲートウェイの作成では対象となるEdge ClusterとHAモードを選択します。HAモードはActive-Standby、または、Active-Activeを選択でき、それぞれ使用できる機能が異なります。例えば、Active-StandbyならゲートウェイファイアウォールやNATのようなステートフルサービスが使用できる、といった具合です。Active-Standbyで設定した場合、Tier-0ゲートウェイはEdge01とEdge02にそれぞれホストされ、障害発生時にはフェイルオーバーします。

f:id:kncyd13:20200830233600p:plain

Edge TEPの注意点

NSX-Tでオーバーレイネットワークを使用する場合、仮想マシンやコンテナが実行されているホストトランスポートノード(ESXiやKVM)と同じオーバーレイトランスポートゾーンにEdgeを追加する必要があります。これは、物理ネットワークへの接続点を持つEdgeへ、ホストトランスポートノードから通信が到達するために、Geneveカプセル化プロトコルのトンネルエンドポイント(以下TEP)をEdgeに作成する必要があるためです。しかし、Edge TEPのIPアドレスを設定する際には、Edgeのデプロイ場所に依存する問題に注意が必要です。

NSX-Tでは3つのクラスタデザインが紹介されています。検証や学習目的でNSX-T環境を構築する際には、多くの場合、小規模DCデザインのシングルクラスタ構成が採用されるかと思います。

f:id:kncyd13:20200830235815p:plain

シングルクラスタの場合、ホストの台数は少なく、高確率でホストトランスポートノード上にEdgeトランスポートノードをデプロイする構成となります。また、IPアドレスプールもホストトランスポートノードとEdgeトランスポートノードでわざわざ分けるようなことはせず、TEP用と一括りにするかと思います。このような構成で、EdgeのTEPとリンクされているvNICをNSX-Tが管理するVDS 7.0やN-VDSに接続すると、Edge TEPが他のTEPとトンネルを張れない問題が発生します。

f:id:kncyd13:20200831011713p:plain

この問題には3つの回避策があります。1つ目は、中規模DCデザインのようにコンピュートクラスタとEdgeクラスタを分け、ホストトランスポートノード上にEdgeトランスポートノードをデプロイする構成を避けること。2つ目は、ホストTEPとEdge TEPで使用するIPアドレスプールを分け、ホストTEPとEdge TEPを別VLANにすること。3つ目は、Edge TEPがリンクされているfp-eth0を、NSX-Tで管理していない仮想スイッチに接続することです。

偶然にもこの問題は、検証や学習環境の構築時に条件を満たしやすいです。ホスト間はトンネルが張れているにもかかわらず、Edgeとはトンネルが張れない場合、この問題を疑うのが、解決への近道となるかもしれません。

また、この構成に関連するKBも出ています。

VMware Knowledge Base (70745)

KBはEdge TEPがリンクされたvNICを、トランクのポートグループや論理スイッチに接続しないでくださいという内容です。

今回取り上げた問題は設定次第で解決できるものでしたが、このようなトラブルを未然に回避するためにも、コンピュートクラスタとEdgeクラスタは分けた方が良さそうです。

 さいごに

今回はNSX-T Edgeについて、ドキュメントだけではイメージしづらい内容や、私が検証環境を構築した際に直面した問題を取り上げてみました。正直、Edge上でホストするサービスの方がより抽象的で理解するのが難しいと思うので、今後の投稿でゆっくりと紐解いていこうと思います。