【テクニカル・上級編】Prometheusメトリクスの暗号署名と改ざん検知：セキュリティ監査をクリアするためのオブザーバビリティ完全性担保 – 運用監視・オブザーバビリティ活用バイブル

監視基盤の「真実性」を担保せよ：Prometheusメトリクスの改ざん防止と完全性設計

オブザーバビリティの世界において、メトリクスは「システムの真実」を映し出す鏡だ。しかし、もしその鏡が歪められていたらどうなるか？攻撃者がメトリクスを操作して障害の予兆を隠蔽したり、リソース使用量を偽装してコストを不正利用したりするシナリオは、もはや絵空事ではない。

SOC2やISO27001などの監査において、「監視データの完全性（Integrity）」は避けて通れない要件だ。本稿では、Prometheusという「性善説」に基づいたツールを、いかにして「ゼロトラストな監視基盤」へと昇華させるか、その極限のアーキテクチャを解剖する。

—

1. 監視データが「嘘」をつく時：改ざんのリスクと脅威モデル

Prometheusのデフォルトのアーキテクチャは、Pull型かつ認証なし（あるいは簡易認証）という、社内LAN内での運用を前提とした「脆弱な境界」の上に成り立っている。

中間者攻撃 (MITM): エクスポーターからPrometheusサーバーまでの通信を傍受・改ざんする。
サイドカーの汚染: Kubernetes環境で、同一Pod内の悪意あるコンテナが`localhost:metrics`を偽装する。
バックエンドの汚染: PrometheusのTSDBファイル自体を直接書き換え、過去の障害の痕跡を消去する。

これらを防ぐには、「誰が発信し、誰が受信したか」を暗号学的に証明する以外に道はない。

—

2. 実装の神髄：サイドカーによるHMAC署名と検証

Prometheus本体に大規模なパッチを当てるのは愚策だ。我々はサイドカーパターンを極め、透過的に署名を付与・検証する仕組みを構築する。

エクスポーター側の署名付与（Sidecar Proxy）

エクスポーターの手前にGoで書いた軽量なリバースプロキシを配置し、レスポンスボディに対してHMAC-SHA256署名を付与し、`X-Metrics-Signature`ヘッダーで送出する。

// 署名付与を行うサイドカーのコアロジック（抜粋）
func signMetrics(body []byte, secret []byte) string {
h := hmac.New(sha256.New, secret)
h.Write(body)
return hex.EncodeToString(h.Sum(nil))
}

// レスポンスをインターセプトし署名を付与するミドルウェア
func SignatureMiddleware(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r http.Request) {
recorder := &responseRecorder{ResponseWriter: w, body: new(bytes.Buffer)}
next.ServeHTTP(recorder, r)

signature := signMetrics(recorder.body.Bytes(), mySecret)
w.Header().Set(“X-Metrics-Signature”, signature)
w.Write(recorder.body.Bytes())
})
}

Prometheus側の検証：Remote Writeの活用

Prometheusのスクレイピング段階で検証を行うのはCPU負荷が高すぎる。推奨するのは、`Remote Write`のプロキシ層での検証だ。Prometheusは自身のTSDBに書き込む前に、`Remote Write`経由でセキュアな検証層（検証用プロキシ）を通過させる。ここで署名が一致しないパケットは即座に破棄し、セキュリティアラートを発報する。

—

3. コンプライアンスをクリアする監視基盤の硬化手法

SOC2の監査をパスするための鍵は、「設定の固定化」と「変更の監査証跡」にある。

A. 自動化されたセキュリティ・ベースライン (IaC)

手動での修正は論外だ。すべてのPrometheusの設定はGitで管理し、`promtool check config`および`promtool test rules`を通した後に、CI/CDでデプロイする。

Prometheus設定の硬化例
global:
scrape_interval: 15s
# 外部からの干渉を防ぐため、TLSを強制する
tls_config:
ca_file: /etc/prometheus/certs/ca.crt
cert_file: /etc/prometheus/certs/client.crt
key_file: /etc/prometheus/certs/client.key
server_name: metrics-internal.domain.com

B. 独自監視スクリプトによるTSDBの改ざん検知

Prometheusのデータディレクトリ（`data/`）に対し、定期的にファイルのハッシュ値を計算して外部の改ざん検知サービス（AWS KMS等で署名）に送信する仕組みを実装する。

!/bin/bash
TSDBの断片化を防ぎつつ、各ブロックの integrity をチェックする独自スクリプト
BLOCK_DIR=”/var/lib/prometheus/data”
for block in $(ls $BLOCK_DIR | grep -E ‘^[0-9A-Z]+$’); do
# ブロック内のmeta.jsonのハッシュを計算
sha256sum “$BLOCK_DIR/$block/meta.json” > “/tmp/integrity/$block.sha256”
done
これをS3のオブジェクトロックが有効なバケットへ転送する

—

4. アーキテクトの助言：パフォーマンスとセキュリティのトレードオフ

ここで強調しておきたいのは、「セキュリティを強化するほど、オブザーバビリティの解像度が下がる」という罠だ。

CPU消費: HMACの計算はコストが高い。高頻度スクレイピング（5s以下）環境では、検証をサンプリング（全リクエストの10%のみ検証）するハイブリッド戦略を検討せよ。
メモリ消費: サイドカープロキシを多数配置する場合、各コンテナのメモリ制限（cgroup）を慎重に設計すること。Goのランタイムが肥大化しないよう、`GOGC`チューニングは必須だ。

結びに代えて

真のエンジニアリングとは、枯れた技術を組み合わせ、そこに強固な信頼の連鎖を組み込むことにある。Prometheusを単なる「メトリクス収集ツール」と見るか、「監査可能な証跡の基盤」と見るか。その視点の差が、大規模システムの運用における「静かな夜」を約束する。

あなたが今設計しているその監視基盤は、誰が改ざんしても気づけるのか？その問いに対する答えを、今すぐコードに落とし込め。それがプロフェッショナルの矜持だ。