ログ保管期間の課題
2023年8月現在、Cato クラウドのイベント (Events) ログは Cato 側で6か月間保存されており、その期間内であれば Cato Management Application (CMA) でログの内容を確認できます。また、Guide to Cato Data Lake Storage (EA) の記事にて、将来的には3か月間だけ無償で保存されるようになるものの、別途契約すれば6か月または1年間保存できるようになるとアナウンスされています。
しかし、ユーザ様企業によっては、監査やセキュリティインシデント対応などの目的で、ユーザやセキュリティ関連のログを1年を超えて保管する必要があり、ログの保管期間が課題になるという方も多いのではないでしょうか。
CMA の画面にはイベントログをエクスポートして手元に保存する機能が用意されていますが、ひと月当たり数億～数十億件のログが出力されることもあり、量が膨大でエクスポートするのは困難です。また、イベントログを取得する API もありますが、一度に取得できるログの件数の制限やその他原因により、全てのログを取得することもできません。
別の機能として、Cato クラウドにはイベントログを Amazon S3 に出力してくれる機能がありますので、これを使って課題を解決してみます。
機能概要
今回利用するのは Integrating Cato Events with AWS S3 に記載されている機能です。
この機能は、ユーザ自身で Amazon Web Services (AWS) の S3 Bucket をあらかじめ用意し、Cato に対して適切な権限を与えることで、あとは Cato が自動的にイベントログを S3 Bucket に出力し続けてくれるというものです。
ログの保管にかかる Amazon S3 の利用料金はユーザ側で負担する必要がありますが、ログの保管期間をコントロールできるようになりますし、任意のサービス・ソフトウェアを用いて分析できるようになるというメリットもあります。
イベントログの出力設定
イベントログを Amazon S3 に出力するための設定手順は Integrating Cato Events with AWS S3 に詳しく記載されていますので、その内容に従って設定を行いましょう。
AWS 環境の準備
まず、AWS 上では次のリソースを用意する必要があります。
- S3 Bucket (イベントログが格納される場所)
- IAM ポリシー (S3 Bucket の操作権限の定義)
- IAM ロール (IAM ポリシーで定義した権限を Cato に付与する設定)
S3 Bucket を作成するリージョンは任意に選択して良く、日本のユーザであれば東京または大阪リージョンを選択することが多いと思います。S3 上のログの分析を AWS 上で行うのであれば、費用の安い米国東部や米国西部リージョンを選択しても良いと思います。
CMA の設定
CMA の設定もドキュメントの手順に記載の通り、”Administration” – “API & Integrations” 画面の “Events Integration” タブで設定できます。
イベントログの出力先のフォルダ名や出力対象のイベントのフィルタ設定は、ひとまず空欄のままでも良いと思います。これについては後述の通り工夫の余地があります。
イベントログの出力結果の確認
ログ内容の確認
正しく設定ができていれば、数分後から Amazon S3 にイベントログが続々と出力されます。
また、S3 Select を用いればイベントログのファイルの中身を簡易的に確認できます。
S3 Select の入力設定では次のように指定してください。
- 形式 : JSON
- JSONコンテンツタイプ : 行
- 圧縮 : GZIP
上図では JSON 形式で全てのフィールドを表示していますが、特定のフィールドのみを CSV 形式で表示することもできます。
わかったこと
弊社の検証用の Cato アカウントで試した結果ですが、この機能について次のことがわかりました。
- 1分間に1,2回の頻度でイベントログのファイルが S3 Bucket に作成される
- ドキュメントでは60秒ごとまたはデータファイルが10MBを超えたらアップロードすると書かれているが、実際の頻度はそれより多い
- ファイルのストレージクラスは Standard
- ログファイルは GZIP 圧縮されている
- ログファイルの中身は、1つのイベントを1つのJSONとして表し、1行ごとに1つのJSONが記載されたテキストデータ
{"event_count":1,"internalId":"xxxxxxxxxx","event_type":"Security","event_sub_type":"Internet Firewall","time":1691628724649,...その他フィールド}
{"event_count":1,"internalId":"yyyyyyyyyy","event_type":"Security","event_sub_type":"Internet Firewall","time":1691628724649,...その他フィールド}
{"event_count":1,"internalId":"zzzzzzzzzz","event_type":"Security","event_sub_type":"Internet Firewall","time":1691628724649,...その他フィールド}
...
- ファイル名は “${UNIX秒}-${UUID}.log.gz” という形式
- 例 : 1691628848-9170c8f4-3088-4ee8-ba7c-a5abcb3e4613.log.gz
- UNIX秒の部分はそのファイルが生成された時刻で、S3 Bucket にアップロードされた時刻とほぼ一致する
- イベントが発生してから2,3分程度遅れで S3 Bucket にアップロードされる
- 実際にどの程度の時間遅れるかは仕様として記載されていないため、もっと遅れる可能性もある
- 複数のイベントが1つのイベントログ (event_count が1よりも大きな値) として記録されることもある
- CMA 上でこの機能を有効にしている期間のイベントのみ出力される
- この機能を設定する前や、無効にしている間のイベントのログは出力されない
また、イベント数の少ない検証用アカウントで試したため精度は低いですが、設定してから2週間ほど経過したあと、実際に出力されたログのデータ量は次のようになっていました。
- イベント行数 : 61,010 件
- ファイル数 : 28,415 個
- GZIP 圧縮済のファイルサイズの合計 : 16.23 MB
- GZIP 展開後のファイルサイズの合計 : 69.23 MB
なお、1つのファイルに記録されているイベントが少ないため GZIP の圧縮効率が低くなっておりますが、参考までに全イベントを1つのファイルにまとめて GZIP 圧縮すると 3.42 MB にまで減りました。
ログ分析における課題
ログを長期に保管しなければならないという課題をクリアできると、次はログを分析する必要が出てくるときに備えて目的のログを抽出する方法を考えないといけません。
ログファイルの形式は明確になっていますので、ログファイルを手元にダウンロードし、全ファイルを読み込んで目的のログを抽出するプログラムを書くという方法が挙げられます。しかし、ファイル数は比較的多く、全体のファイルサイズも大きくなりますので、ログのダウンロードやプログラムの実行部分で相当の時間がかかるものと思います。
別の方法として、Amazon Athena を利用して分析するという方法が挙げられます。Athena を利用すれば、ログを手元にダウンロードすることなく SQL とほぼ同じクエリを用いてログを分析できますし、分散処理によってクエリの実行時間の短縮も図られます。
稀にしかログの抽出を行わないのであればあまり気にしなくてもよいのですが、Athena でログを頻繁に分析して活用しようとすると次のような新たな課題も出てきます。
- 全期間の全てのファイルが S3 Bucket の1つのフォルダの下に保存されるため、クエリを実行するたびに全てのデータが読み込まれて時間と費用がかかる
- 1つ1つのファイルサイズが小さいため、Athena 内部の分散処理のオーバーヘッドが大きく、実行に時間がかかる
1つ目の課題については、CMA でイベントログの出力先のフォルダ名や出力対象のイベントのフィルタ設定を工夫することで、部分的に解決できます。例えば、イベントタイプごとに出力先のフォルダに変える、あるいは比較的ログの多いイベントサブタイプ (Internet Firewall や WAN Firewall など) だけ異なるフォルダにするといった工夫が考えられます。この場合、イベントタイプやイベントサブタイプが将来増える可能性を忘れずに考慮する必要もあります。
本格的に解決して効率よく分析できるようにするは、ログの分析でよく用いる検索キー (タイムスタンプ、イベントタイプ、イベントサブタイプ、サイト、ユーザIDなど) でパーティショニングしたり、複数のファイルを 128MB 以上 (Athena の推奨サイズ) にまとめたりするのが望ましいです。これについては AWS の利用に関する知識やログの分析ノウハウだけでは実現できず、多少なりともプログラムや分析システムの開発が必要になってくるため、分析の目的が明確になってからでも良いと思います。
まとめ
本記事では Cato クラウドのイベントログを Amazon S3 に自動的に出力する機能について検証し、課題について整理しました。
AWS を利用中のユーザ様であればすぐにでも利用できますので、まずはイベントログを保管するところから始めてみてはいかがでしょうか。そうしておけば、監査やセキュリティインシデント対応のために後から過去のログが必要になったとしても、ログを追跡できる状況を確保しておけます。
また、弊社が用意する AWS 環境でログを保管し、ユーザ様からの要求に応じてログを抽出してお渡しするといった対応ができるかもしれませんので、お気軽にご相談いただければと思います。
追記
ログの保管から抽出までを運用サービスとして提供する「ログ保管サービス」を提供開始しておりますので、気軽にお問い合わせください！
ログの保管から抽出までを運用サービスとして提供する「ログ保管サービス」を提供開始しておりますので、気軽にお問い合わせください！
