CentOSのDockerにコンテナマルウェア対策を導入してみる

 前の投稿では、コンテナ保護を可能にする追加機能の概要をお伝えしましたが、本投稿ではそこで作成したエージェントを、弊社環境の昔からあるCentOS7に入れてみようというものです。

このCentOS7環境は、製品のバージョンアップのたびに新しいエージェントを入れられ、アップデートされてきたなんでも屋古株の仮想マシンですが、今回も新しいコンテナ形式のエージェントなのでまずはここに導入してみます。

最終的な構成図:

最終的には単に「Dockerで動かしてみた」というだけではなく、エンドポイント、コンテナへの負荷を削減しつつ、大量のDockerプラットフォームへ導入しても、問題なくスケールアウトしていける構成の基本パターン、雛形となるものとなります。

1 前提事項:

  • CentOSマシンにDockerはインストール済(コマンド"yum -y install docker")
  • エージェントパッケージは作成済(前の投稿参照)

2 導入準備:
通常は管理コンソールでエージェントのパッケージを作成したら、各OSに合わせてインストーラー(exeなど)をダウンロードするのですが、今回はオンラインヘルプの「For Linux hosts」のスクリプトを利用して、クラウドの管理コンソールから直接導入します。

以下はヘルプにあるスクリプトを自社に合わせてカスタマイズしたものです。
変更する点は2つで、BSC_SERVERとBSC_COMPANYです。設定する値について上ヘルプにも説明がありますが、いったん管理コンソールからLinux向けインストーラーをダウンロードして、その中に含まれるinstaller.xmlを開き、その中にある値で置き換えてください。


3 インストール実行:
カスタマイズしたスクリプト「docker run ~」を実行するとエージェントがダウンロードされインストールされます。

インストールされたエージェントは、すぐにクラウド管理コンソールに接続を試みているはずです。管理コンソールでみてみましょう。

4 管理コンソールに表示:

来ました。コンテナアドオンライセンスを追加すると、NetworksインベントリにContainersが表示されるようになりますが、その中にコンテナホストが表示され、保護されているコンテナが表示されています。アイコンに小さくBというマークが付いているのは、コンテナでもあるエージェント自身ですね。Nameの「sad_brown」というのは「Docker ps」で表示されるNameと一致しています。


5 導入後のさらなる仮想環境への最適化:

ここまでで導入は完了です。この段階で出てくるのは「どのぐらい重たくなるの?」でしょうか。これに対して「軽いです」という答えだけでは仮想環境、クラウド環境では不十分です。なぜなら導入によって脅威DBやスキャンなど実際にリソースを消費、負荷となる処理が発生しているからです。

これに対するBitdefenderの答えはアップデートとスキャンは専用マシン(SVA)にまかせるというものです。これはローカルで通常1時間に1回行っていたアップデート(ダウンロード)とそのDB領域の消費。またアクセス時に発生するスキャン処理を、専用セキュリティサーバ(SVA)に委託し、エンドポイントとコンテナをそこから開放させます。

参考:サーバへマルウェア対策を導入したくない

今回コンテナ形式のエージェントも、ポリシーでSVAを指定されるとそこを利用するようになります。SVAは他のマシン、コンテナからのスキャン履歴をキャッシュしているので、すでに他から同じファイルでスキャン依頼があり結果が出ているのなら、スキャン処理をせずにその結果だけを返します。

SVAは各仮想プラットフォーム向けに仮想アプライアンスの形で用意されており、年間ライセンスでは追加コストなしで何台も導入可能です。この機能は10年近く提供、強化されてきている機能で、かなり前から仮想環境、プライベートクラウド環境への移行を進めてきたある企業では、SVAによるリソース消費削減効果を自社調査に基づき発表しています。
参考:[あの会社は今]仮想サーバ15,000台までビットディフェンダー導入を拡大


6 コンソールでSVA連携確認:

最後にポリシーで指定したSVAをちゃんと利用しているかは、Protectionタブの以下の項目で、実際に接続しているSVA(仮想アプライアンス)の情報をみることで確認できます。この環境では障害対策、レスポンス向上のため2台のSVAを稼働させていますが、2台目の方にスキャン処理を依頼しているようです。


コメント