みなさんこんにちは。技術1課の北鶴です。
今回はCloudOneの一機能である変更監視を実際にサーバに導入してみて、検知の挙動まで一緒に見ていきたいと思います。
変更監視ってなにという方はこちらの記事をご覧になってから、本記事を読んでみてください。
事前準備
今回は変更監視に限定して設定を行っていくため、EC2へのAgentインストールおよび有効化についてはすでに実施済のコンピュータにて行います。
上記手順についてはこちらをご参考ください。
利用するEC2はAmazon Linux2となります。
また設定する変更監視ルールはこちらの記事で作成したカスタムルールCloudOne test Ruleを利用します。
おさらいとして、XMLファイルの内容とルールの概要を載せておきます。
<FileSet base="/var/www/html"> <include key="**"/> <exclude key="/test01/**"/> <exclude key="/swx/cloudone_test/**"/> </FileSet>
監視を実施するベースのディレクトリはvar/www/htmlとする
ベースディレクトリ配下のvar/www/html/test01とvar/www/html/swx/cloudone_testについては監視対象外のディレクトリとする
変更監視の有効化
Agent有効化時点のEC2は以下のようになっています。
現時点では有効化されている機能がないポリシーがアタッチされているだけとなります。
まずはEC2にアタッチしているポリシー側で変更監視の有効化とカスタムルールのアタッチを行います。
ポリシータブから該当のポリシーを選択し、変更監視のステータスを「オン」にして、
割り当て/割り当て解除ボタンからアタッチしたい変更監視ルールを選択します。
ベースラインの構築
続いては対象のコンピュータにてベースラインの構築を実施します。
ベースラインとは変更の検索結果の比較対象となる元の状態のことを指します。
このベースラインと変更監視の検索結果にずれが生じた場合、CloudOneは変更監視のアラートを上げるという仕組みになっています。
そのため意図的にEC2内部のファイルを変更したり、設定する変更監視ルールを変更した場合は、必ず1度ベースラインの構築を実施するようにしてください。
やり方は対象コンピュータの変更監視タブから、「ベースラインの再構築」をクリックするだけです。
「作成された最新の整合性ベースライン」が現在時刻に変わったら再構築は完了となります。
変更監視のテスト
ここまで完了したら、変更監視が正常に動作しているかテストしましょう。
テスト1
まずは監視対象ディレクトリと対象外のディレクトリ直下にそれぞれファイルを作成してみましょう。
/var/www/html直下と/var/www/html/test01にそれぞれcloudone_test.txtファイルを作成してみます。
作成後対象のEC2にて「変更の検索」をクリックして、完了後「変更監視イベント」を確認してみます。
想定通り、/var/www/html直下のファイル作成は検出され、/var/www/html/test01直下のファイルは検出されていません。
テスト2
次にサブディレクトリに対してファイルを作成して、検出されるかを見ていきます。
/var/www/html/swx直下と/var/www/html/test01/test02直下へ同様にcloudone_test.txtファイルを作成してみます。
こちらも想定通り/var/www/html/swxは監視対象のサブディレクトリのため検出され、/var/www/html/test01/test02は監視対象外ディレクトリ配下のため検出されていないことが確認できました。
このように想定した設計通りに変更監視が行われているか、運用前に必ず確認することをお勧めします。
予約タスクの設定
テストが完了したら最後に予約タスクの設定を行います。
変更監視を運用していく際に、検索を自動的に実行するにはこの予約タスクを設定して、あらかじめどれぐらいの頻度で実施するかを決定しておく必要があります。
管理タブから予約タスクの新規作成を選択します。
種類は「コンピュータの変更を検索」を選択し、検索を実行した頻度に合わせて単位を選択します。
今回は1日1回17:30に検索が実行されるように設定します。
実行時間になると、予約タスクが走り変更の検索結果がイベントとして出力されます。
参考として、20分毎など細かい単位で予約タスクを実行したい場合は、画像のように予約タスクを複数作成することで可能となります。
注意点として予約タスク実行時はコンピュータの負荷が高くなります。
頻繁に実行してしまうと業務への影響が発生する可能性があるため、 事前に少ない頻度で確認してから増やしていくことを推奨します。
CPU使用率の制限設定
先で説明したように、変更監視の検索にはコンピュータのCPUリソースを消費します。
コンピュータによっては30-40%程度上昇することも確認しているため、アプリケーションの稼働と合わせるとリソースが足りなくなってしまう瞬間がある可能性も十分考えられます。
そういったコンピュータにはCPU使用率制限を設定するすることで、使用率をコントロールすることが可能です。
これは検索実行時にCPUリソースが高い場合は、検索を一時停止して検索の実行時間をコントロールしてくれる機能となります。
設定の概要は以下となります。
高：一時停止せずにファイルを1つずつ検索します。
中：ファイルを検索してCPUリソースを節約するために一時停止します。
低：ファイルを検索する間隔がメディア設定よりも長い間隔で一時停止します。
具体的な設定は対象コンピュータの変更監視画面の「詳細」から可能となります。
おわりに
いかがでしたでしょうか。
ご紹介した手順に沿って設定いただければ、変更監視の基本的な設定はできるので自身の設定したい環境に読み替えて試してみてください。
注意点として、CloudOneの変更監視はあくまで変更を検知するだけで、未然に防ぐことはできません。
すでに別機能でCloudOneを導入しているコンピュータでは、セキュリティソフトウェアを一元化することもできるため、要件に合わせて有効化を検討してみてください。
参考
北鶴 光紀(執筆記事の一覧)
Enterprise Cloud部 技術1課
