VMware Carbon Black Cloud Workloadへの移行理由
昨今のセキュリティにおいては、NGAV、EDR、NDR、XDRと様々な横文字が飛び交う時代になりましたが、どれだけ強固な防御製品をでも、全ての攻撃を100%防ぐことはできないとする考え方が広まっています。これは防御製品を入れたところで意味がないというわけではなく、どんな組織であっても大企業、中小企業、業種を問わず攻撃者による侵害を受ける可能性はあるため、侵入されてしまうことを前提にした侵入後の対策をすべきであるという考え方です。
もう、これからはゼロトラストの概念ですね。
当院もこれまでの仮想化基盤ではVDIに適した製品されていたDeep Security Virtual Appliance(以下、DSVA)を採用していました。DSVAはvSphere/NSX-Tと連携することでアンチウイルス機能をエージェントレス型で提供可能です。ハイパーバイザーの領域ですべてが完結するイメージですかね。DSVAの不正プログラム対策機能とNSX-TのDFW機能を連携することで実現する自動隔離は、不正プログラム対策イベントをトリガーにDFWのポリシーを変更することでVDIをネットワーク隔離することができます。これが気に入ってたんですけどね。
エージェントレス型の利点は本来OSで発生するウイルス検索やシグネチャ更新の負荷を仮想アプライアンスへオフロードできるため、OSのリソース不足によりパフォーマンスやレスポンスが低下することに最新の注意を払わなければならないVDIにおいて、パフォーマンスを損なわずに必要最低限のセキュリティ機能を実装できるため、結構愛用していたし、個人的には気に入ってましたが今年の５月EOLが決定しました。
これにより、vShere8での現状での最適解はVMware Carbon Black Cloud Workloadではないかと思い、EDRでの構築を決めたわけです。
EDRはエンドポイント上のイベントログを収集することで、攻撃全体像の可視化、被害範囲の調査、攻撃手法の分析することに長けていますので、これに併せてNSX-TもバージョンによってはCarbon Black Cloud Workloadからの指示でVDIに適用するポリシーに変更を加えることで隔離も可能になるのかなと考えています。
VMwareさん、カスタマイズしなくてもデフォルトで選択できる上記のポリシー作ってください(笑)
この辺りは、導入作業をしながら詳しく研究してみます。
今回も最後まで読んでいただき、ありがとうございました。
