Documentation

/

White Papers

大規模監査ログの効率的な保存と管理(OVEN)

fabian

2025年1月23日

大規模監査ログの効率的な保存と管理(OVEN)

はじめに

監査ログ (Audit Log) は、システムのセキュリティ、透明性、そして規制遵守の観点で重要な役割を果たします。特に金融、医療、公共機関のように機密データを取り扱う分野では、監査ログの最低保存期間が 5年以上に設定されることが多く、保存および管理に対する要求がさらに重要となっています。例えば、大手金融機関では 1日に数百万件の監査ログが生成され、これを数年間保存するためにはテラバイト (TB) を超える膨大なストレージが必要です。このような大容量ログ管理の必要性は日増しに高まっています。

課題

従来のログ管理システムには以下のような課題があります。

1. 保存の課題

  • ログデータが継続的に増加する中で、データベースストレージの拡張が必要となり、高い運用コストや管理の複雑化を引き起こします。

2. 検索の課題

  • 大規模なログデータを迅速かつ効率的に検索することが難しく、分析や規制遵守に必要な情報の抽出が遅れる可能性があります。

3. 外部連携の非効率性

  • 大容量のログデータを効果的に分析するためには、外部の OLAP ストレージにデータを取り込むための ETL 作業が必要です。この追加作業は、開発コストや運用の負担を増加させる原因となっています。

ソリューション

QueryPie は、大容量監査ログを効果的に保存、検索、管理するために、以下の目標を設定しました。

1. 大容量ログを効率的に保存

  • S3 のようなオブジェクトストレージと連携し、ログデータを効率的に保存します。

2. 外部連携の効率向上

  • 外部 S3 に保存されたデータは、外部 OLAP との連携や検索が容易になる形式で保存します。

  • 外部 OLAP ストレージにデータを適切に取り込むため、データ形式は OLAP ストレージに最適化されています。

3. 必要最小限の機能提供

  • 監査ログの特性を考慮し、必要な機能のみを提供し、不必要な機能は排除します。

  • 監査ログは保存後に修正されず、明示的な削除も不要です。

  • 保存および検索機能のみを提供します。

  • 監査ログは時系列順で保存され、時間範囲内でのリスト検索機能のみを提供します。

詳細説明

Diary Overview

監査ログ管理に必要な機能のみを提供

監査ログは保存後に変更されず、明示的な削除も必要ありません。したがって、保存と検索機能のみを提供します。

  • 保存 (WRITE)

  • 監査ログは、速い書き込み性能を持つ HotStore に保存されます。

  • 保存されたログは一定期間経過後、ColdStore に時間単位でまとめて移動します。

  • 検索 (READ)

  • 監査ログを検索します。

  • 検索は、時間範囲内でリストに対する検索機能のみを提供します。

内部の保存空間に依存しない一貫した検索機能を外部に抽象化して提供します。

大容量ログを効率的に保存するため、BLOB ストレージと連携

ColdStore に移動されたログは、内部の Cabinet Blob ストレージに保存されます。

  • Cabinet は Blob ストレージとして、S3 などのオブジェクトストレージと連携してログデータを保存します。

  • Blob ストレージに保存された監査ログは、WORM(Write Once Read Many)特性を持っており、保存されたログデータは変更できず、検索のみが可能です。

検索および外部連携のためのデータ保存形式

監査ログでは、ロググループ名と保存された時系列時間情報が最も重要で、検索時には必須の情報となります。

  • 大容量のログデータを保存し、検索する際には、一般的に使用されるパスベースのパーティショニングを使用して、検索および外部連携を容易にします。

  • collection=${COLLECTION}/date=${DATE}{HOUR}.gz

  • ロググループ名

  • $\{COLLECTION\}

  • 時間

  • $\{DATE\}: ログが保存された日付

  • $\{HOUR\}: ログが保存された時間

  • collection test-log

  • 保存されたログ: 2024年1月1日 19:00:00 〜 2024年1月2日 01:00:00 (UTC)

Collection

Date

Hour

collection=test-log/

date=2024-01-02/

01.gz

collection=test-log/

date=2024-01-02/

02.gz

collection=test-log/

date=2024-01-01/

23.gz

collection=test-log/

date=2024-01-01/

22.gz

collection=test-log/

date=2024-01-01/

21.gz

collection=test-log/

date=2024-01-01/

20.gz

collection=test-log/

date=2024-01-01/

19.gz

上記のパスベースのパーティショニングは、外部 OLAP ストレージと連携してログデータを効率的に検索するための方法です。

  • 以下は、Athena を使用して S3 に保存された Diary ログを直接検索および分析する例です。

Athena連携およびクエリ例

  • Example: S3に保存されたDiaryログのAthena連携テーブル作成例

123456789101112131415161718192021222324252627282930
    CREATE EXTERNAL TABLE test_log (        `record_uuid` STRING,        `created_at` STRING,        `data` STRUCT<            msg: STRING,            time: STRING,            level: STRING,            request_id: STRING,            operation_id: STRING        >    )    PARTITIONED BY (        `date_created` STRING    )    ROW FORMAT SERDE &#39;org.openx.data.jsonserde.JsonSerDe&#39;    STORED AS INPUTFORMAT &#39;org.apache.hadoop.mapred.TextInputFormat&#39;        OUTPUTFORMAT &#39;org.apache.hadoop.hive.ql.io.HiveIgnoreKeyTextOutputFormat&#39;    LOCATION &#39;s3://${S3_BUCKET_ROOT_PATH}/collection=test-log/&#39;    TBLPROPERTIES (        &#39;classification&#39; = &#39;json&#39;,        &#39;compressionType&#39; = &#39;gzip&#39;,        &#39;projection.enabled&#39; = &#39;true&#39;,        &#39;projection.date_created.type&#39; = &#39;date&#39;,        &#39;projection.date_created.format&#39; = &#39;yyyy-MM-dd&#39;,        &#39;projection.date_created.interval&#39; = &#39;1&#39;,        &#39;projection.date_created.interval.unit&#39; = &#39;DAYS&#39;,        &#39;projection.date_created.range&#39; = &#39;2024-12-01, NOW&#39;,        &#39;storage.location.template&#39; = &#39;s3://${S3_BUCKET_ROOT_PATH}/collection=test-log/date=${date_created}/&#39;    ); 
  • 連携テーブル作成後、SQL を使用した照会および分析の例

12345
    SELECT date_created, data.level, count(*)    FROM test_log    GROUP BY date_created, data.level    ORDER BY date_created, data.level; 
result

内部照会パフォーマンスのためのブルームフィルター 照会時に時間範囲外のログデータをフィルタリングする機能が必要です。

  • ColdStore には 1時間単位で大量のログが Blob 形式で保存されているため、フィルタリング条件を満たさない Blob データを照会するのは性能的に非効率です。

  • 各時間単位の Blob に対してブルームフィルターを作成し、フィルタリング条件を満たさない Blob をスキップすることで、照会性能を向上させます。

  • ブルームフィルターは、確率的に False Positive が発生する可能性がありますが、False Negative は発生しないことが保証されています。

  • 上記の特性を利用して、確実に存在しない Blob はスキップし、存在すると誤検出された False Positive Blob は Blob が照会されるだけで、ロジック内で再度フィルタリングされます。

Bloom Filter

結論と期待される効果 QueryPie の新しい監査ログモジュール「OVEN」は、既存の監査ログの保存と管理に関する以下の2つの問題を解決するために設計されました。

  • 大容量ログ管理の効率性

  • 外部連携の効率性

監査ログ管理モジュール OVEN は、S3 のような大容量ストレージと連携し、保存および照会に関する機能を一貫したインターフェースで提供し、開発の利便性を高めます。さらに、外部連携を考慮した設計により、Athena や Hive などの OLAP ストレージと即座に連携でき、大規模なデータ分析作業を容易に処理できます。

QueryPie OVEN

従来の監査ログ保存管理に比べ、OVEN は以下の効果が期待できます。

  1. コスト削減

  • AWS S3 を活用した Blob ストレージで、大規模データを経済的に管理できます。

  1. 大規模監査ログの保存・照会機能開発の利便性

  • 監査ログの保存および照会に必要な機能のみを提供し、開発および運用の複雑さを削減できます。

  • 内部ログが保存される HotStore / ColdStore の種類は OVEN 内部で管理されており、ログを保存または照会する開発者はこれを意識する必要がありません。

  1. 拡張性と互換性

  • 標準化されたデータ構造により、Athena や Hive などのツールと即座に連携可能で、大規模データ分析作業を簡単に処理できます。

  • 外部連携を考慮した設計により、さまざまな分析および可視化ツールとの統合が柔軟に行えます。

今後 現在、S3 および S3 互換ストレージのうち MinIO を正式サポートしており、今後はさまざまな大容量ストレージとの連携についてテストおよびサポートを進めていく予定です。

S3-Compatible Storage Support

- AWS S3 (正式対応、テスト中)

- MinIO (正式対応)

- Google Cloud Storage (対応テスト中)

S3 非互換ストレージ対応(予定)

- Azure Blob Storage (予定)

- Ceph (予定)

- Swift (予定)

また、外部連携のための標準的なガイドや例を提供し、さまざまな分析・可視化ツールとの接続を容易にする予定です。

外部連携ガイドおよび例

1. Real-Time Data Visualization Integration:

効果的なリアルタイムデータ可視化連携のための Lambda を通じた OpenSearch 連携、Kibana 可視化例

2. Data Warehouse ETL Guide:

DataWarehouse ETL のための Athena/EMR(Spark) を活用したデータ分析パイプライン構築ガイド