Bot Tips 書籍・論文・web記事 環境構築・インフラ 開発ログ

🛠️開発記録#271(2025/8/6)「クリプトbotterのための実戦セキュリティ設計図――攻撃検知と開発スピードを両立させる15のチェックポイント」

こんにちは、よだかです。先日「経営層のためのサイバーセキュリティ実践入門」という本を読みました。
基本的には、組織で働く人向けにサイバーセキュリティについて具体的な対策を述べる内容でしたが、個人開発者としても参考になる部分がありました。

特に
「セキュリティに割くリソースの最適化(新たな技術スタックの学習と実装にどれだけの手間とお金を投下するべきか)」
「侵害検知＆原因追跡」
の2点は、個人開発者としても実装の優先度が高いと感じました。

本記事では、本書から得た知見をもとに個人開発者およびクリプトbotterの立場から実装すべきことをリスト化したので、それらを解説していきます。

具体的に取り組む方法とそれらの優先度も併せてまとめたので、同じようにクリプトbot開発を行っている方の参考にもなると思います。

はじめに──“開発優先”でも守りを捨てないために

仮想通貨の自動取引 bot を開発していると、機能追加とバックテストにすべての時間を突っ込みたくなるものです。実際、ボラティリティの高い市場では開発スピードがそのまま収益機会につながります。
しかし――取引所 API キーの流出やノード侵害で「一晩で口座が空っぽになった」という事例は枚挙にいとまがありません。攻撃を受けてから対策を考えていては遅いのです。

1. “やられたらログがない”——個人開発者の典型的な落とし穴

多くの個人ボッターが抱える最初の課題は、**「何が起きたか後追いできない」**という点です。

  • コンテナの標準出力だけに頼る
  • ローカルフォルダにテキストで棚積み
  • 重要ログがストリームで上書きされて消える

こうした状態では、侵害の有無さえ判別できません。原因不明＝対策不能となり、次の攻撃にも備えられない悪循環に陥ります。

2. セキュリティ対策は“全部入り”でなくていい

エンタープライズ向けの分厚いセキュリティフレームワークを、ソロ開発者がそのまま導入しようとすると開発時間が蒸発します。本記事では、そうしたボトルネックを避けるために

  1. 目的（守りたい資産）
  2. 手段（最小限のツール構成）
  3. 必須度（★1–5）

の三つで整理し、“守りとスピードのトレードオフ”を可視化しました。
★5 から順に導入すれば、短い工数で「ログが残らない」「侵害に気づけない」といった致命的な穴が塞がります。

3. “観測できなければ改善できない”——優先順の考え方

  • ★5：観測基盤とリアルタイム検知
    • Loki + Vector ですべての証跡を中央に
    • Falco/Tetragon でプロセス侵害を秒単位で検知
  • ★4：鍵と相関
    • Secrets を暗号化し流出リスクを封じ込め
    • Wazuh + Sigma で横断的な異常を自動発見
  • ★3 以下：サプライチェーン～復旧自動化
    • 依存ライブラリの CVE、イメージ署名、IaC スキャン
    • 余力や運用フェーズに応じて段階導入

この優先度は「攻撃を受けたら即破産」というクリプト市場特有のリスクと、ソロ開発の限られた人的リソースの双方を勘案して決めています。

4. 本記事で得られるもの

  • 15 項目チェックリストと★評価で、今の自分に欠けた要素がすぐわかる
  • 各項目を「目的」と「具体的な実装例」で短文化しているため、導入イメージが掴みやすい
  • 週末 PoC → 本番拡張という段階的な走り出し方のヒント

結論
セキュリティは“ゼロかイチか”ではなく、“必要十分を見極めて段階的に積む”もの。本記事をロードマップ代わりに、開発スピードを落とさず守りを強化していきましょう。

全体像：15 項目チェックリストを一望する

まずは “どこを守り、どこに時間を割くか” を一目で俯瞰できるように、15 項目を 目的と必須度だけに絞って 並べました。⭐️ が多いほど「クリプト資産が吹き飛ぶリスクに直結する部分」──開発前でも最優先で導入したい領域です。

#カテゴリ & 代表ツール例何を守る／実現する？必須度
1集中ログ基盤
Grafana Loki		すべての bot 挙動を後から完全再現⭐️⭐️⭐️⭐️⭐️
2ログ配送 & 冗長バッファ
Vector		ログ欠損ゼロで中央集約⭐️⭐️⭐️⭐️⭐️
3ランタイム IDS
Falco / Tetragon		実行中の侵害を秒単位で検知⭐️⭐️⭐️⭐️
4SIEM & 相関解析
Wazuh + Sigma		異常イベントを横串で関連付け⭐️⭐️⭐️
5Secrets／API キー管理
sops-age / Vault		鍵流出・権限過多を抑止⭐️⭐️⭐️⭐️
6サプライチェーン監査
Syft + Trivy		依存ライブラリの既知 CVE を排除⭐️⭐️⭐️
7イメージ署名
Sigstore cosign		改ざんコンテナの実行を拒否⭐️⭐️⭐️
8コンテナ / IaC スキャン
Trivy all-in-one		Dockerfile や Terraform の設定ミス撲滅⭐️⭐️
9K8s Admission Policy
Kyverno / Gatekeeper		危険マニフェストをクラスタ入口で遮断⭐️⭐️
10ネットワーク制御
Cilium NP, Tailscale		外部到達範囲を必要最小限に分割⭐️⭐️
11CI/CD パイプライン防御ビルド環境の乗っ取りを防止⭐️⭐️
12脅威インテリジェンス取込新しい攻撃手口を自動シグネチャ化⭐️⭐️
13フォレンジック & IR 自動化
TheHive		証拠保全と復旧タスクを省力化⭐️⭐️
14バックアップ / 版管理
restic + S3 Lock		ログ・DB を耐タンパで長期保持⭐️⭐️⭐️
15OS / ノードハードニング
Bottlerocket		ホスト層の攻撃面を最小化⭐️⭐️

表の読み方と優先順位の決め方

  • ⭐️5〜4 : “侵害を検知し、原因を追える” 基盤。ここが抜けると損失が即確定。
  • ⭐️3 : リスク低減＋再発防止。“やられた後” を想定した強化層。
  • ⭐️2〜1 : クラスタ規模拡大やチーム開発で効いてくる“厚み”の部分。後回し可。

ポイント
1 → 3 までを実装すれば 「攻撃 ≠ 即死」 の土台が完成します。残りは開発フェーズや予算に合わせて段階的に足していくイメージで進めましょう。

★5クラス：ログ集中と即時可視化が最優先

ここでは“攻撃を受けても資金が即死しない”ために欠かせない 観測＋検知レイヤー を深掘りします。まずはログを失わず、何が起きたかを秒単位で把握する──この 2 点に全リソースを振り向けても損はありません。

3-1. Loki × Vector で“後追い完全再現”

① なぜ Loki なのか

  • スケール＝お金の問題
    Loki は “ラベル索引だけ保持 / 本文は圧縮チャンクで S3” という設計。1 GB のログでも月数円レベルで長期保存できます。
  • クエリ速度
    v3 では Bloom filter が入り、大量チャンクをスキップできるため “1 年分でも数秒検索” が現実的。
  • Prometheus と同じラベル設計
    監視メトリクスとログを {bot="mmbot", env="prod"} で揃えると、Grafana の Explore で横断分析が一瞬で書ける。

② Vector を合わせる理由

  • Docker / K8s どちらでも sidecar 1 つで完結。
  • メモリバッファ + ディスクスプール を持ち、ネットワーク断でもログが欠けない。
  • TOML/YAML 1 ファイルで “source → transform → sink” を定義するだけなので、導入コストが極小。
# vector.toml（最小例）
[sources.docker]
  type = "docker_logs"

[transforms.json]
  inputs  = ["docker"]
  type    = "remap"
  source  = '''
  . |= parse_json!(string!(.message))
  '''

[sinks.loki]
  type  = "loki"
  inputs = ["json"]
  endpoint = "http://loki:3100"
  encoding.codec = "json"
  labels = {bot = "{{ .bot }}", level = "{{ .level }}", env = "prod"}

③ 立ち上げ手順（PoC レベル）

  1. docker-compose.yml に Loki + Grafana + Vector を追加
  2. Bot コンテナに環境変数で構造化 JSON ログを出す（structlog 推奨）
  3. Grafana → Explore タブ で
    {bot="mmbot"} |= "order_fail" | json | line_format "{{.trade_id}} {{.err}}"
    を打って “10 秒以内にエラーが可視化される” ことを確認
  4. S3 バケット設定 → loki.yaml の schema_config で chunk_store_config を S3 指定

ワンポイント：サイズ感の目安

  • 1 bot あたり 200 msg/s 程度なら Loki + Vector は CPU 1 core, メモリ 1 GB も使わず走ります。

3-2. Falco / Tetragon でランタイム侵害を刈り取る

① なぜ eBPF ベース IDS が必須か

  • Python ログだけでは docker exec -it bot bash のような直接侵害を検知できない。
  • 取引回数が多いほど 「誤操作や CI/CD のバグで権限が漏れる」 リスクが比例して上がる。
  • eBPF はカーネル空間でイベントを拾うため 遅延が μs オーダー。高頻度 bot でもレイテンシをほぼ増やさない。

② Falco と Tetragon、どちらを選ぶ？

特徴FalcoTetragon
ルール記法YAML（シンプル）Cilium CLI / Hubble UI
メタデータPod, Namespace 自動付与BPF マップで詳細追跡
使いやすさOSS 事例が豊富Cilium 環境と相性◎
お勧めシナリオDocker Compose / 単一 VPSK8s + Cilium CNI

まずは Falco で始め、将来 Cilium 導入時に Tetragon へスイッチするのが王道。

③ 最低限のルール例（Falco）

- rule: Unexpected Binary Execution in Container
  desc: Detect binaries executed outside allowed dirs
  condition: >
    container.name = "mmbot" and
    proc.name in (bash,sh,zsh) and
    not proc.cwd startswith "/app"
  output: >
    Falco alert: Unexpected shell {{proc.name}} in {{container.name}} (user=%user.name)
  priority: CRITICAL
  • 想定外のシェル が立ち上がった瞬間に Slack へ通知。
  • Vector で log sink を指定すれば Falco イベントも Loki へ集約 → 後追い解析が容易。

④ PoC 手順

  1. docker run --privileged -d --name=falco falcosecurity/falco:latest
  2. falco_rules.yaml を ConfigMap マウント or Local Volume で差し替え
  3. Bot コンテナに docker exec してみて Slack 通知が飛ぶかテスト
  4. アラートが確認できたら falco.yaml の program_output で Vector → Loki パスを追加

tips
Falco の偽陽性が多い場合は falcosidekick + UI でルールチューニングログを可視化すると調整が捗ります。

本章のまとめ

  1. Loki × Vector で「どんなエラーがいつ起きたか」を秒単位で後追いできる土台を構築。
  2. Falco / Tetragon で「誰かがコンテナを乗っ取った」「想定外のバイナリが走った」を即検知。
  3. これだけで “侵害に気付けない” と “ログが消えた” の二大リスク を同時に潰せます。

次章では★4クラスとして、Secrets 管理と Wazuh/Sigma を用いた“横串相関”の設計を解説します。

★4クラス：鍵管理と横串相関で被害拡大を防ぐ

4-1. Secrets を暗号化＋最小権限運用

▸ なぜ今すぐやるべきか

取引所 API キーが Git やコンテナイメージに平文で残っていると、リークした瞬間に残高ゼロが現実になります。しかもキー 1 本で「発注・出金・ポジション強制決済」まで出来てしまう取引所も少なくありません。

▸ 最小構成の実装例

ステップやることポイント
1SOPS+age で.env を暗号化sops -e --age <age-pubkey> .env > .env.enc でコミット。復号はコンテナ起動前に sops -d でパイプ。SOPS は YAML/ENV/JSON などを部分暗号化でき、履歴差分が読みやすい Techno TimGitHub
2KMS と連携して自動復号AWS KMS／GCP KMS キー ID を SOPS 設定に追加すると サーバ側で鍵管理。CI でも同じキーで復号できる。
3キー権限を最小化取引所 UI で「現物取引のみ」「出金禁止」「IP ホワイトリスト」などを ON。ロング／ショート両建て bot なら先物権限を完全に外す。
4月次ローテーションCI で “Rotate key” スクリプト → 新キーを SOPS 再暗号化 → 旧キー失効。age は鍵ペアが軽量なので自宅 PC でも管理が楽。
5検知ルール追加Wazuh で “未知の IP から API キー使用” を検知する Sigma ルールを後述の 4-2 に連携。

🔖 補足

  • Vault を使う場合は vault agent + sidecar でアプリ起動時に注入する方法が簡単。
  • パブリックレポジトリへ誤コミットしても .env.enc なので被害リスクを低減できる。

4-2. Wazuh × Sigma で“何が関連しているか”を自動で結ぶ

▸ 目的は「点のログを線にする」

Falco が「不審なシェル起動」を、Loki が「大量 CancelAllOrders」を吐いても、別々に眺めている限り“同一インシデント”と気付けません。
Wazuh 4.x は Filebeat-like エージェントであらゆるログを取り込み、Sigma ルール（業界共通 YAML シグネチャ）で関連付けることで「同一攻撃の連鎖」を一発でアラートへ昇華します。
Medium
GitHub

▸ 導入フロー（Docker Compose 例）

  • 1,Wazuh Manager + Filebeat ：Vector からの Loki ルールや Falco JSON を filebeat → Wazuh に送信。
wazuh:
  image: wazuh/wazuh:4.12.0
  ports: ["1514/udp", "1515/tcp", "55000/tcp"]
filebeat:
  image: wazuh/filebeat
  volumes:
    - ./filebeat.yml:/usr/share/filebeat/filebeat.yml

  • 2,Sigma ルール投入
    • sigma convert -t wazuh -o wazuh_rules.xml bybit_cancel_spam.yml
    • /var/ossec/etc/rules/local_rules.xml に配置して再ロード。
    • Chainsaw 経由で YAML 直接実行も可（サブ秒遅延） Medium
  • 3,相関ダッシュボード
    • Wazuh Kibana app で “MITRE ATT&CK → Exchange Abuse” のヒートマップを有効化。
    • 「Falco: exec into bot」＋「Sigma: cancel spam」＋「Loki: error spike」が同一タイムラインで表示される。

▸ 実戦 Sigma ルール例（抜粋）

title: Bybit CancelAllOrders Spam
logsource:
  product: application
  service: bybit
detection:
  selection:
    event.action: "cancelAll"
    network.ip:
      - "!10.0.0.0/8"   # 内部IP以外
  condition: selection | count(15) by 1m
tags:
  - attack.t1566
  - severity.high

ルールは YAML で書き、sigma convert -t wazuh で XML に変換して投入。変換不要で Chainsaw に食わせる方法もあるため、運用に合わせて２系統で回せる。Medium

▸ 運用ヒント

状況アクション
偽陽性が多いWazuh Kibana で “Mute” → Sigma YAML の閾値を count(30) に上げて即デプロイ。
新たな脅威が出たSigma HQ に PR が出たら CI で nightly pull → Wazuh へ自動同期。
Slack 通知を統一Filebeat の output と Wazuh rule の slack module を合わせ、1 スレッドにスレッド返信 でノイズ低減。

★4 レイヤーの成果物

  1. 秘密情報の流出経路を遮断（暗号化 + 最小権限 + ローテーション）。
  2. ログの“点”を自動で繋ぐ相関レイヤーが完成し、
  3. Falco / Loki のアラートを Wazuh で束ね、Slack へ1件通知──被害の横展開を阻止できます。

次章では ★3 クラスとして、ソフトウェア・サプライチェーンを守る Syft + Trivy + cosign 署名 の実装を解説します。

★3クラス：サプライチェーンと署名でコード汚染を防ぐ

ここからは「ビルド～デプロイの間にマルウェアが混入しないか？」を潰すフェーズです。依存ライブラリの脆弱性チェックと、イメージ改ざんのブロックを最小構成で回します。

5-1. Syft + Trivy で依存ライブラリの CVE 洗い出し

① “SBOM → スキャン” の 2 ステップが基本

  • 1,Syft で SBOM（Software Bill of Materials） を生成 
syft packages:catalog ghcr.io/your/mmbot:latest -o spdx-json > sbom.json

syft packages:catalog ghcr.io/your/mmbot:latest -o spdx-json > sbom.json SBOM には OS パッケージから Python/Rust の依存まで全リストが出力される GitHub

  • 2,Trivy で SBOM もしくはイメージを直接スキャン 
trivy sbom --exit-code 1 --severity HIGH,CRITICAL sbom.json
# 直接イメージ → trivy image ghcr.io/your/mmbot:latest

Trivy は CVE と IaC 設定ミスの両方を一括検出でき、CI で exit-code 1 にすると 脆弱性が残ったままのビルドを失敗させる
trivy.dev
GitHub

② CI への最小組み込み例（GitHub Actions）

jobs:
  sbom_scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Build image
        run: docker build -t ghcr.io/${{ github.repository }}:${{ github.sha }} .
      - name: Generate SBOM
        run: syft ghcr.io/${{ github.repository }}:${{ github.sha }} -o spdx-json > sbom.json
      - name: Trivy scan
        uses: aquasecurity/trivy-action@master
        with:
          scan-type: 'sbom'
          sbom-ref: 'sbom.json'
          severity: 'CRITICAL,HIGH'

ポイント

効果仕組み
開発者全員が同じ SBOM を確認SBOM をジョブ Artifact としてアップロード
ゼロデイ以外の既知 CVE を遮断Trivy exit-code により PR を自動でブロック
将来の再スキャンも簡単SBOM さえ残しておけば Trivy / Grype で後日再解析可能 jit.io

5-2. cosign 署名で “改ざんコンテナを起動させない”

① そもそも署名は何を守る？

  • 誰がビルドしたイメージか証明
  • デプロイ前にハッシュが一致するか検証 → CI からクラスタまで“同一ビット列”である保証
  • 万一レジストリが侵害されても 未署名 or 検証失敗イメージを弾ける
    Sigstore
    sse-secure-systems.github.io

② Keyless 署名 & 検証（Sigstore Fulcio / Rekor）

# 署名（OIDC フローが自動でブラウザ認証）
cosign sign ghcr.io/your/mmbot:latest

# 検証
cosign verify ghcr.io/your/mmbot:latest
  • OIDC (GitHub Actions, Google, Azure) を使う keyless モードなら秘密鍵管理が不要。
  • 署名は Rekor transparency log に公開されるため、後から改ざん検証も可能 Chainguard Academy。

③ デプロイ時に強制検証する 2 パターン

環境実装ポイント
KubernetesKyverno / Gatekeeper に
yaml<br>verifyImages: [ { image: "ghcr.io/your/*", mutateDigest: true } ]<br>
を設定し、未署名イメージの Admission を拒否。
Docker Compose / Nomad などcosign verify を entrypoint の前段で実行。失敗時はコンテナを即 exit。

④ CI に組み込む YAML（抜粋）

- name: Cosign sign
  run: cosign sign --yes ghcr.io/${{ github.repository }}:${{ github.sha }}
- name: Cosign verify (sanity check)
  run: cosign verify ghcr.io/${{ github.repository }}:${{ github.sha }}

よくある疑問

QA
「keyless は毎回ブラウザ認証？」GitHub Actions ランナーは OIDC トークンを自動取得するので対話不要。
「サイズ増えない？」署名はレイヤに入らずレジストリの manifest annotation に付与→イメージサイズは不変。
「CPU/Latency 影響？」検証は SHA256 計算＋Rekor API 呼び出し程度で、起動時に数 100 ms。常時稼働 bot では無視できる。

★3 レイヤーのゴール

得られる効果ツール
依存の既知 CVE を自動ブロックSyft + Trivy
ビルド後の改ざんを完全検知cosign 署名＋Admission Policy
CI → 本番まで“同一ビット列”保証cosign verify

これで 「脆弱ライブラリが混ざったままデプロイ」 と 「誰かにイメージを差し替えられる」 の 2 大リスクを最小コストで封じ込められます。
次章では ★2 クラスとして、Kubernetes Admission Policy とネットワーク分割で“外周を固める”ステップを解説します。

★2クラス：K8sポリシー・ネットワーク分割で外周を固める

Kubernetes で本番運用を始めると、「誰でもデプロイできる」「Pod から外部に何でも出られる」 という“ゆるさ”が一気にリスク化します。
★2 レイヤーでは 「クラスタ入口で止める / 外へ出さない」 の二本柱で“外周”を固めます。

6-1. Kyverno / Gatekeeper による Admission 制御

項目ポイント
目的危険なマニフェストを “apply した瞬間” にブロック
ツール選択- Kyverno：YAML ベース、学習コストが最小
- OPA Gatekeeper：Rego で細かい制御、既存 OPA 知見があれば◎
導入コストHelm 1 コマンドで入る。既存 Pod には影響なし（enforce にするまでは “観測モード”）

▸ 最低限押さえる 4 ルール（Kyverno例）

# ① root 権限禁止
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata: {name: require-nonroot}
spec:
  validationFailureAction: enforce
  rules:
    - name: run-as-non-root
      match: {resources: {kinds: ["Pod"]}}
      validate:
        message: "runAsNonRoot must be true"
        pattern: {spec: {securityContext: {runAsNonRoot: true}}}

# ② readOnlyRootFS
# ③ 禁止イメージレジストリ（:latest, docker.io/library）
# ④ cosign 署名検証（★3 で導入した verifyImages）

運用ヒント

  1. まずは audit モード（validationFailureAction: audit）で回し、偽陽性を潰してから enforce へ。
  2. policyReport を Vector → Loki に流せば “誰のマニフェストが弾かれたか” を時系列で確認 できる。

▸ PoC 手順（10 分）

  1. helm repo add kyverno https://kyverno.github.io/kyverno/
  2. helm install kyverno kyverno/kyverno -n kyverno --create-namespace
  3. 上記 YAML を kubectl apply -f
  4. 敢えて runAsUser: 0 Pod を apply → Error from server (Violation) を確認

6-2. Cilium NetworkPolicy & Tailscale でゼロトラスト化

項目ポイント
目的Pod-to-Pod / Pod-to-外部 を必要最小限に閉じる
ツール構成- Cilium：eBPF CNI。DNS / L7 aware の NetworkPolicy が書ける
- Tailscale：WireGuard Mesh VPN。固定 IP & ACL で運用端末だけアクセス許可
メリット- Cilium は Hubble UI でフロー可視化 → ポリシー設計が楽
- Tailscale は NAT 超えでも固定 IP を確保でき、“自宅 / ノマド先” でも同じ ACL で動く

▸ ① Cilium NetworkPolicy 最小例

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata: {name: mmbot-egress}
spec:
  endpointSelector:
    matchLabels:
      app: mmbot
  egress:
    - toEntities: [world]
      toPorts:
        - ports:
          - port: "443"
            protocol: TCP
          rules:
            http:
              - host: "api.bybit.com"
              - host: "*.slack.com"
  • mmbot からは Bybit API + Slack しか出られない
  • 他 Exchange を追加したいときは YAML 1 行足すだけ

▸ ② Tailscale ACL スニペット

{
  "ACLs": [
    {
      "Action": "accept",
      "Users": ["authed-user@example.com"],
      "Ports": ["mymesh-cluster:6443", "mymesh-monitor:3000"]
    }
  ]
}
  • kubectl / Grafana アクセスは自分の Tailscale IP だけ許可
  • VPS 側は tailscale up --advertise-tags=tag:k8s-node でタグ付与 → ACL で束ねる

▸ フロー可視化例（Hubble CLI）

hubble observe --from-pod mmbot --to-entity world --protocol HTTP
見えるもの使い方
GET api.bybit.com/v5/market/tickers 200“正常 API コール” をホワイトリスト確認
CONNECT 1.2.3.4:443 DROPPED“未知の IP 宛て通信” → Loki / Slack にアラート

外周対策の効果まとめ

  1. Kyverno / Gatekeeper が「危険マニフェスト＝クラスタ侵入前に拒否」。
  2. Cilium NP が「侵入後でも外部エクスフィルを遮断」。
  3. Tailscale が「運用者トラフィックもゼロトラストで固定化」。

これで “誰でも apply できる & Pod がどこへでも出られる” という Kubernetes の既定緩さを解消し、侵害後の被害半径を劇的に縮小 できます。
次章では ★1 クラスとして、フォレンジック自動化と OS ハードニングで“最後の壁”を作るステップを紹介します。

★1クラス：フォレンジック自動化と OS ハードニングの“最後の壁”

ここまでで「検知 → 相関 → 外周遮断」まで整備しました。
最後は 「侵害後に証拠を素早く押さえる」 と 「そもそもホストを改変させない」 という〝最終防壁〟を築きます。工数は小さい割に 復旧と再発防止の質 を大きく底上げできるので、余裕ができたら真っ先に取り入れましょう。

7-1. TheHive + Velociraptor で証拠保全を省力化

| 目的 | 侵害判定が出た瞬間に メモリ・ディスク・ログのスナップショット を自動採取し、
調査タスクをテンプレ化して漏れなく進める |
|------|-----------------------------------------------------------------------------------------------------------------------------------|

● コンポーネント概要

ツール役割
TheHiveインシデント管理。アラートを “Case” に変換し、タスクテンプレを自動発行
CortexTheHive から呼ばれる実行エンジン。Velociraptor など多数のアナライザを呼び出し
Velociraptorライブメモリ・ファイル・レジストリ（Windows）等をエージェントレスで収集

● シグナルから自動 Case 作成まで

Falco → (webhook) → TheHive Alert
            ↓
    TheHive transforms Alert → Case
            ↓
  Cortex action: VelociraptorCollect
            ↓
        Artifact zip to S3 + Case Task “分析”
  1. Falco / Wazuh アラート に Slack URL または Loki クエリを添付
  2. TheHive が case_template_id: bot-compromise で Case 発行
  3. Cortex から Velociraptor_Collect_Memory をキック
  4. 完了した zip パスを Case Task に添付 → 調査担当はリンククリックだけで証拠取得完了

● 最小 PoC 手順

docker compose up -d thehive cortex
thehive-cli template import bot-compromise.json
# Velociraptor server + endpoint に ssh で agentless collection
  • テンプレ例: “取得→解析→根本原因→再発防止” の 4 タスク
  • タスク進捗は Slack App “TheHive notifier” でスレッド更新すると漏れがなくなる

💡 Tips

  • 短時間 PoC なら Velociraptor の “collector” モード（スタンドアロン）で OK。
  • 取得対象の選定は 証拠腐敗の順（メモリ→揮発ログ→ディスク）で。Velociraptor は順番を定義できる。

7-2. Bottlerocket / Flatcar で不可変ホストを実現

| 目的 | コンテナ層を突破されても ホスト OS を書き換えられない ようにし、
再イメージで “秒” でクリーン復旧できる状態にする |
|------|----------------------------------------------------------------------------------------------|

● なぜ不可変 OS が効くのか

  • ルート FS が read-only → curl | bash 型の永続改変が不可能
  • OS 更新は イメージ単位 (“A/B パーティション”) なので、
    不整合が起きてもロールバック 1 reboot
  • システムコンポーネントはコンテナ化されており、脆弱性管理が一元化できる

● 選択肢比較

OS特徴使いどころ
BottlerocketAWS 発、k8s だけを動かす最小構成。EKS なら AMI 1 行で置き換え可AWS 運用なら最速
FlatcarCoreOS 後継。Ignition/Butane でクラウド非依存の宣言型設定マルチクラウド / BareMetal

● 導入の流れ（Flatcar 例）

  1. Ignition 設定 で SSH キー・Tailscale token・kubelet 起動オプションを書き込む
  2. PXE or Cloud-Init 相当で disk image をフラッシュ
  3. k8s ノードとして join
  4. “変更禁止” 領域は locksmithctl reboot-needed のトグルで管理 →
    セキュリティパッチ要求が出ても ノードローテーションだけで完結
butane < config.bu | jq . > ignition.json
coreos-installer install /dev/sda --ignition-file ignition.json

● 運用ポイント

テーマベストプラクティス
ログ永続化ノード再作成で消えないよう Loki Stack を外部 S3 + PVC に
ノードアップデートk8s PodDisruptionBudget=0 のワーカープールを作り“ローリング置き換え”
緊急時terraform taint module.node_pool → 再作成で感染ノードを即抹消

🔖 補足
Bottlerocket は /etc すら書き込み不可。設定変更は SSM API or settings.toml 再焼きのみ。ヒューマンエラーごと封じ込める 効果も大きい。

★1 レイヤーまで積み上げると…

侵害フェーズ対応スタック
検知Falco / Wazuh / Loki
遮断Kyverno / Cilium NP
証拠保全TheHive + Velociraptor
クリーン復旧不可変 OS イメージ再適用

これで 「やられても即日復旧し、原因を翌日までに追跡できる」 体制が整いました。
あとは運用フローに合わせ、タスク自動生成や Slack 通知を微調整して 日常開発に溶け込ませる だけです。

導入ステップ別ロードマップ：週末 PoC → 本番拡張

フェーズ目標主要タスク所要めやす
Step 0 – 事前準備必要最低限のリポジトリ整備- すべてのログを JSON 出力へ統一
- .env を sops-age で暗号化		2 h
Step 1 – 週末 PoC“見える化” の第一歩1. Vector → Loki → Grafana を docker-compose で立ち上げる
2. Bot コンテナ stdout/stderr を Loki に転送
3. Grafana Explore でエラー検索が秒で返ることを確認		1 day
Step 2 – 検知を載せるランタイム侵害の早期発見1. Falco（単独 VPS）または Tetragon（Cilium）をデプロイ
2. 代表ルール 3 本だけ設定（exec / write / unexpected net）
3. Slack Webhook 通知を確認		0.5 day
Step 3 – 鍵と相関を強化“漏れない・繋がる” に昇格1. Wazuh + Sigma を Loki 横に追加
2. “未知 IP から API キー使用” など 2 本のルールを投入
3. Wazuh → Slack で一つのスレッドに集約		1 day
Step 4 – CI/CD 安全化汚染の混入を防止1. GitHub Actions へ Syft + Trivy ジョブ追加
2. ビルド済イメージを cosign sign
3. cosign verify が失敗したらデプロイを中断		1 day
Step 5 – K8s 外周防御クラスタ入口と出口を制限1. Kyverno を audit モードで導入→偽陽性除去→enforce
2. Cilium NetworkPolicy で bot → Exchange API / Slack のみ許可		2–3 days
Step 6 – 最終防壁侵害後の復旧を自動化1. TheHive + Velociraptor Collector テンプレを組み込み
2. Flatcar/Bottlerocket AMI へノード置換（ローリングで）		1 week（並行可）

リソース感
ソロ開発でも 実働 2–3 週間 & 月 < ¥2,000 のインフラコストでフルレイヤーまで到達できます。先に★5→★4を固め、残りは週末ごとに一段ずつ積み増すのが現実的です。

まとめ：開発スピードを落とさず守りを厚くするために

  1. 観測できないものは守れない
     Loki + Vector で “いつでも全ログが掘れる” 状態を最速で作る。
  2. 検知は軽く、解析は後で
     Falco / Tetragon が秒単位でアラートを出し、重い相関は Wazuh に流す――この分業で bot レイテンシを犠牲にしない。
  3. 鍵・署名・ポリシーで入口を絞る
     Secrets を暗号化し、cosign 署名を必須に、Kyverno で危険マニフェストを弾く。攻撃面はここで劇的に縮まる。
  4. ネットワークと OS を“書けない・出られない”に
     Cilium NP と不可変 OS で侵害後の横展開を物理的にブロック。
  5. 証拠保全は自動生成タスクで
     TheHive + Velociraptor なら「アラート→Case→ダンプ取得」まで無人化でき、開発者は本来の bot 改良に専念できる。

結局のところ
“速く作りたい” と “安全でありたい” はトレードオフではありません。段階的に積める 15 のモジュールをロードマップ化しておけば、開発サイクルを止めずに守りを強化し続けられます。
bot が次のアップデートで新機能を獲得する頃、セキュリティも一段階レベルアップしている――そんな開発フローを、この設計図で実現してください。

-Bot, Tips, 書籍・論文・web記事, 環境構築・インフラ, 開発ログ