vSphere 管理者に優しい Carbon Black Cloud Workload
この投稿は、vExperts Advent Calendar 2023 の7日目です。
今回は、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日目です。
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のアカウント作成が必要となります。
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製品のバイパスなど様々な設定をポリシーで行うこととなるため、次回はポリシーについて深掘りしていこうと思います。
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ファイアウォールといったアドバンスサービスを使用する場合
リソース要件やサイジングの公式ドキュメントは以下リンク先を参照してご確認ください。
実際にTier-0ゲートウェイなどをEdgeにホストする場合、Edgeではなく、Edge Clusterを選択します。Edge Clusterは複数台のEdgeを束ねたオブジェクトです。仮に、Edgeが1台だけであったとしても、Edge Clusterには追加する必要があります。
Edgeは物理ネットワークとの接続点
例えば、NSX-Tで自由にオーバーレイネットワークを構築しても、物理ネットワークとの接続点がなければインターネットを含む物理環境とアクセスできません。EdgeはvNICを仮想スイッチに接続することでオーバーレイネットワークと物理ネットワークを繋げます。Edgeには計4つのvNICがあり、それぞれ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に設定します。
続いて、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にそれぞれホストされ、障害発生時にはフェイルオーバーします。
Edge TEPの注意点
NSX-Tでオーバーレイネットワークを使用する場合、仮想マシンやコンテナが実行されているホストトランスポートノード(ESXiやKVM)と同じオーバーレイトランスポートゾーンにEdgeを追加する必要があります。これは、物理ネットワークへの接続点を持つEdgeへ、ホストトランスポートノードから通信が到達するために、Geneveカプセル化プロトコルのトンネルエンドポイント(以下TEP)をEdgeに作成する必要があるためです。しかし、Edge TEPのIPアドレスを設定する際には、Edgeのデプロイ場所に依存する問題に注意が必要です。
NSX-Tでは３つのクラスタデザインが紹介されています。検証や学習目的でNSX-T環境を構築する際には、多くの場合、小規模DCデザインのシングルクラスタ構成が採用されるかと思います。
シングルクラスタの場合、ホストの台数は少なく、高確率でホストトランスポートノード上にEdgeトランスポートノードをデプロイする構成となります。また、IPアドレスプールもホストトランスポートノードとEdgeトランスポートノードでわざわざ分けるようなことはせず、TEP用と一括りにするかと思います。このような構成で、EdgeのTEPとリンクされているvNICをNSX-Tが管理するVDS 7.0やN-VDSに接続すると、Edge TEPが他のTEPとトンネルを張れない問題が発生します。
この問題には3つの回避策があります。１つ目は、中規模DCデザインのようにコンピュートクラスタとEdgeクラスタを分け、ホストトランスポートノード上にEdgeトランスポートノードをデプロイする構成を避けること。２つ目は、ホストTEPとEdge TEPで使用するIPアドレスプールを分け、ホストTEPとEdge TEPを別VLANにすること。3つ目は、Edge TEPがリンクされているfp-eth0を、NSX-Tで管理していない仮想スイッチに接続することです。
偶然にもこの問題は、検証や学習環境の構築時に条件を満たしやすいです。ホスト間はトンネルが張れているにもかかわらず、Edgeとはトンネルが張れない場合、この問題を疑うのが、解決への近道となるかもしれません。
また、この構成に関連するKBも出ています。
KBはEdge TEPがリンクされたvNICを、トランクのポートグループや論理スイッチに接続しないでくださいという内容です。
今回取り上げた問題は設定次第で解決できるものでしたが、このようなトラブルを未然に回避するためにも、コンピュートクラスタとEdgeクラスタは分けた方が良さそうです。
さいごに
今回はNSX-T Edgeについて、ドキュメントだけではイメージしづらい内容や、私が検証環境を構築した際に直面した問題を取り上げてみました。正直、Edge上でホストするサービスの方がより抽象的で理解するのが難しいと思うので、今後の投稿でゆっくりと紐解いていこうと思います。
