CloudOne変更監視に触れてみた~カスタムルール作成編~

記事タイトルとURLをコピーする

皆さんこんにちは。技術1課の北鶴です。
今回はCloudOne変更監視を環境に設定する機会があったので、カスタムルールの基礎から変更監視の設定方法まで一連のやり方についてご紹介します。

少し長くなるため、この記事ではCloudOne変更監視のカスタムルール作成までを紹介し、次回実際にサーバに変更監視設定を入れてみたいと思います。

CloudOne変更監視とは

変更監視イメージ図

そもそもCloudOneの一機能である変更監視とはどのようなものなのでしょうか。
Trend Microのドキュメントでは以下のように記載されています。

変更監視保護モジュールは、不審なアクティビティを示している可能性があるファイルや重要なシステム領域 (Windowsレジストリなど) への変更を検出します。検出では、現在の状況が、以前に記録されたベースラインの読み取り値と比較されます。Workload Security には、事前定義済みの 変更監視 ルールと新しい 変更監視 ルールが含まれています。

少し難しく書かれていますが、要するに対象のコンピュータのディレクトリ構成やファイルの内容に変更があった場合にその内容を検出してくれる機能となります。
これにより意図しないファイルの変更などが行われた際に、管理者にその内容を知らせることが可能となり業務への影響を軽減することが可能となります。
変更が加えられるとまずいファイルやディレクトリ群があるサーバに対して有効化するといい機能ですね。

マネージドルールとカスタムルール

変更監視の機能を有効化する際に、どのディレクトリやファイルを監視するかは変更監視ルールという単位で決定します。 それらのルールには大きく以下の2つに分かれています。

  • マネージドルール:Trend Microがあらかじめ提供しているルールであり、ルールごとに監視するファイルが決まっています。

  • カスタムルール:ユーザー自身で1から内容を作成したルールであり、監視したいファイルに合わせて独自に設定が可能となります。

基本的にはマネージドルールにて監視したい要件が満たせるのであれば、そちらを使うのが負荷としても少なく簡単に監視ができるようになります。
一方でマネージドルールでは監視範囲が広すぎて、運用時に必要以上に通知が来てしまうなどのデメリットも考えられるため、
自分たちの要件に絞ったカスタムルールを作成することで実際の監視業務は楽になるといえるでしょう。

変更監視ルールを設定する際の注意事項

変更監視を行うフォルダやファイルの量が増えるほど、監視時にかかるコンピュータの負荷は高くなります。
サーバによっては監視時に30-40%ほどCPU使用率が上昇することもあるので、監視したいファイルはできるだけ絞って必要以上にルールをアタッチしないことが推奨されます。

カスタムルールの作成方法

それではカスタムルールの作成方法についてご紹介します。
まずはCloudOneコンソールからポリシー画面に移動し、変更監視ルールの新規作成ボタンを押下します。

新規作成のウィザードの画面で、作成するルールの名前や説明(任意)を記載します。

実際に監視するファイルの設定はコンテンツタブに移動しましょう。

ファイル単位での記載

監視したものと監視除外としたいものがファイル単位で決まっている場合、一番簡単に設定できるのがファイル単位での設定方法になります。

  • 基本ディレクトリ:サーバ内で監視対象ディレクトリとしたい場所の絶対パスを記載します。画像ではvar/www/htmlを基準のディレクトリとし、配下のファイル、サブディレクトリはすべて監視対象としています。

  • ファイル名:監視したいファイルや除外したいファイルが明確に決まっている場合、ファイル単位で指定することも可能です。画像ではcloudone-testlogという名前のファイルは監視対象に含まない設定をしています。

こちらの設定内容は、難しいルールの記載方法もなく、視覚的にカスタムルールを作れるため要件を満たせる場合はお勧めとなります。

ディレクトリ単位での記載

一方でファイル単位ではなく、ディレクトリ単位で監視除外設定などより詳細にカスタムをしたい場合は、カスタム(XML)というXMLファイルの形式でルールを記載します。
今回は以下の条件で監視するファイルを指定します。その他のルールの記載方法(エンティティセット)についてはこちらをご参考ください。

  • 監視を実施するベースのディレクトリはvar/www/htmlとする

  • ベースディレクトリ配下のvar/www/html/test01var/www/html/swx/cloudone_testについては監視対象外のディレクトリとする

これらの条件をXMLファイル形式で記載すると以下のようになります。

<FileSet base="/var/www/html">
<include key="**"/>
<exclude key="/test01/**"/>
<exclude key="/swx/cloudone_test/**"/>
</FileSet>
  • <FileSet base="hogehoge"></FileSet>

    • 監視の基準としたいディレクトリを明示的に指定します。
  • <include key="hogehoge"/>

    • 監視するファイルを指定する許可リストになります。

    • 上記ケースのように基準のディレクトリ配下をすべて監視対象としたい場合は**/と記載します。

  • <exclude key="hogehoge"/>

    • 監視除外対象としたいファイルを指定するブロックリストになります。

    • 基準となるディレクトリ配下の中で、監視対象から外したいサブディレクトリやファイルがある場合に使用します。

監視するファイルの設定が完了したら「OK」を押下します。 画像のように変更監視ルールの一覧に作成したカスタムルールが存在していれば、作成は成功となります。

おわりに

ここまでで変更監視の概要と、カスタムルールの作成方法をご紹介しました。

変更監視を有効化する上で大切になってくるのが、監視するファイルを事前に定義しておくことです。
マネージドルールを手あり次第にアタッチしてしまうと、場合によってはコンピュータの負荷が上昇し業務に支障が出る恐れがあります。

マネージドルールとカスタムルールをうまく使い分けて、最低限の監視設定を行いたいですね。

次回は今回作成したカスタムルールを実際にコンピュータにアタッチし、変更監視の挙動を見ていきたいと思います。
それでは「変更監視設定編」でお会いしましょう。

北鶴 光紀(執筆記事の一覧)

Enterprise Cloud部 技術1課