セキュリティ監視基盤を内製することを想定した構築の方法論について述べる。既存製品・サービスを利用する場合はそれぞれの方法論に従うことになる。ただし、既存製品・サービスを選定する際のヒントとなる要素もある。
ログ収集
ログの取り出し
ログは様々な方法で出力されるため、各ツール、サービス、製品にあった方法での取り出しが必要になる。自社開発したプロダクトなどはログの出力形式・方法を自由に調整しやすいが、外部の製品・サービスから取り出す場合はその方法にあわせて実装する必要がある。
取り出し方法
- ログ出力用のAPIが提供されている
- APIで指定した時刻や件数を取得できる
- ログの到着遅延に注意する
- ログが生成されてからAPIで取得できるようになるまでの遅延が発生しうる
- サービスによっては遅延時間が保証されているので、それをもとにログの取得タイミングを考える
- なるべく遅延を短くするため、重複を前提にログを取得する戦略もありえる
- その場合、重複を排除するための方法も同時に検討する必要がある
- 定期実行の頻度、取得の時間幅
- ストリーミング形式でログが出力される
- プッシュ型の通信形式で送信する
- Syslog
- Fluentd
- Webhook
- その他独自形式
- ログの生成と同時に送出している場合が多く、遅延は最も小さくしやすい
- 一方で、障害が発生したときの対応が最も大変
- 送信処理が正しく実施されなかった場合の再送が面倒 or 虚空に消える可能性がある
- 送信確認とれるまでログを保持し続ける場合、送信側のバッファが溢れる恐れがある
- クラウドプラットフォームに直接ログが出力される
- 指定したリソースに直接接続してログを投入する
- オブジェクトストレージ：Google Cloud Storage、Amazon S3など
- データウェアハウス：BigQueryなど
- メッセージングサービス：Amazon Kinesis Data Streams、Pub/Sub など
- 静的なCredentialを利用する場合、セキュリティ的にはやや脆弱
- 影響範囲を切り分けるため、出力されるログごとになるべく異なるリソースを用意するのが良い
- サービス側が用意したリソースへ出力され、都度自組織側に転送する、というやり方もある（CrowdStrike Falcon Data Replicator）
取り出しにおける注意点
- エラーなど障害発生時のリトライを事前に考えておく
- 正常にログが取り出されているかのモニタリングも必要
ログの取り込み
ログ検索エンジン（およびデータストレージ）の選択
例として3つのパターンを紹介する
- Elasticsearch
- 入力したログに出現するフィールドや値をインデックス化し、高速にキーワード検索が可能
- スキーマを事前に定義しなくて良い
- ログの投入データ量に対してCPUパワーが必要になる
- 自前でインスタンスをたててインストールする or クラウドプラットフォームのマネージメントサービスを利用する
- BigQuery
- 投入したログに対してSQLでクエリができるGoogle Cloudのフルマネージドサービス
- スキーマは（実質的に）事前に定義する必要がある
- ストレージコストはクラウドストレージと同等程度に抑えることができる
- Amazon S3 + Amazon Athena
- S3に保存したデータをSQLのようにクエリができるようになるフルマネージドサービス
- スキーマを事前に定義しなくて良い
- ストレージコストはS3のみ
- ただし検索コストを最適化したい場合はParquetなどの列指向フォーマット（カラムナフォーマット）へ変換する必要がある
ログの変換
出力されたログをそのままログ検索エンジンに投入できるわけではなく、投入に適した形へ変換する必要がある。例えば以下のようなケースに対応する必要がある。