6
4

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

【OSS】現場で使える軽量な脅威検知・監視基盤「kizashi」を個人開発してみた(設計・実装の全記録)

6
Posted at

はじめに

セキュリティ監視や脅威検知を現場レベルで運用しようとすると、商用製品のコストの高さや、既存オープンソースの導入・運用負荷の高さに直面することが多々あります。

そこで今回、「軽量・低負荷・Docker一発起動」 で本格的な監視・テレメトリ収集・ログ分析を行えるOSS 「kizashi」 を開発・公開しました。

  • GitHub リポジトリ: kizashi-labs/kizashi
  • 主な技術スタック: Go / Docker / 各種テレメトリ収集・監視エコシステム

kizashi 動作デモ

本記事では、kizashiの設計思想、アーキテクチャ、実装でこだわったポイントや直面した技術的トラブルについて全記録として共有します。


1. なぜ作ったのか(開発背景と課題意識)

直面していた現場のリアルな課題

インフラ構築やセキュリティ運用の現場において、以下のようなジレンマがありました。

  1. 商用ツールの導入ハードルの高さ
    • ライセンス費用が高額で、検証環境や小規模環境、PoCで気軽に試せない。
  2. 既存OSSの運用の重さ
    • 高機能な反面、依存ミドルウェアが多く、環境構築やリソース消費(メモリ・CPU)が重くなりがち。
  3. 「本当に必要な機能」へのアクセスの悪さ
    • プロセス監視、怪しい通信、ファイル改ざんの予兆(兆し)をクイックに捉えたいだけなのに、設定ファイルの記述量が膨大。

「最小限のリソースで、現場が求める必要十分な検知・テレメトリ収集をシンプルに実現したい」 という想いから、兆候・前兆を捉えるツールとして kizashi の開発をスタートしました。


2. 全体アーキテクチャと技術選定

kizashi は、エンドポイント側で動く軽量な収集エージェントと、データを集約・判定するバックエンド/パイプラインで構成されています。

技術スタックの選定理由

  • Agent / Core 言語: Go
    • シングルバイナリで配布可能で、ターゲット端末への依存関係(ランタイム等)をゼロにできる点。
    • 低フットプリントかつ並行処理(Goroutine)でOSテレメトリをノンブロッキングに取得可能。
  • オーケストレーション: Docker Compose
    • docker compose up -d だけで即座に検証・運用を始められる再現性を重視。

3. 実装・設計でこだわったポイント

① エンドポイントへの影響を極小化するバッファリング設計

エージェント側でOSのイベントやプロセス情報を監視する際、ホストのリソースを圧迫しては本末転倒です。
リングバッファとバッチ送信の仕組みを採用し、CPU使用率を極限まで抑えつつ、バースト的なログ発生時にもメイン処理をブロックしない設計にしました。

// 概念スニペット: ノンブロッキングなイベント収集ループ
func (a *Agent) StartTelemetryLoop(ctx context.Context) {
    ticker := time.NewTicker(a.interval)
    defer ticker.Stop()

    for {
        select {
        case <-ctx.Done():
            return
        case event := <-a.eventChan:
            a.buffer.Push(event)
            if a.buffer.IsFull() {
                go a.flushBuffer()
            }
        case <-ticker.C:
            go a.flushBuffer()
        }
    }
}

② 現場目線の検知ルールとアラート設計

単にログを垂れ流すのではなく、異常なプロセスツリーの派生や不審なコマンドライン引数を即座にスコアリング・正規化してアラートへ変換するパイプラインを組み込みました。


4. 開発中に直面した技術的トラブルと解決策

コンテナデプロイ時のパーミッションとホストアクセス

問題:
Dockerコンテナ側からホストマシンのメトリクスやログをマウントして監視する際、パーミッションエラー(Permission Denied)やUID/GIDの不整合によってテレメトリが取得できない事象が発生しました。

解決策:
最小権限の原則(Least Privilege)を保ちつつ、必要なLinux Capabilities(CAP_SYS_PTRACE や読み取り専用マウント)を明示的に指定。コンテナ起動時のエントリーポイントスクリプトで適切な所有権チェックを挟むことで、安全かつ確実なデータ収集を実現しました。


5. まとめと今後の展望

「現場で本当に使える手軽さ」を突き詰めて開発を進めてきました。

今後のロードマップ

  • マルチプラットフォーム(Linux / macOS / Windows)対応の強化
  • 脅威インテリジェンス(CVE/EPSS等)との自動突合パイプラインの統合
  • WebダッシュボードUIのブラッシュアップ

もし「面白い」「使ってみたい」と思っていただけたら、ぜひリポジトリの ⭐(Star) を押していただけると開発の大きな励みになります!

IssueやPull Request、機能要望などのフィードバックも大歓迎です。最後までお読みいただきありがとうございました!

6
4
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
6
4

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?