監査ログは「死体検分」ではない：Kubernetes APIサーバーを真の要塞に変えるアーキテクチャ
多くの組織において、Kubernetesの監査ログ（Audit Log）は単なるコンプライアンス要件のチェックリストと化している。だが、現場で死線を越えてきた我々にとって、監査ログとは「侵入者の思考を読み解くタイムライン」であり、攻撃者が特権昇格を試みる際の微細なノイズを拾い上げるための広帯域センサーだ。
単にログをSIEMに流し込むだけでは、現代の高度な脅威は検知できない。今回は、APIサーバーを要塞化し、攻撃者が「そこに存在すること」すら悟らせないための設計論を語る。
—
1. 監査ポリシーの設計：ノイズを削ぎ落とし、シグナルを研ぎ澄ます
デフォルトのポリシーをそのまま使うのは自殺行為だ。大量の get や list リクエストでSIEMのインデックスが溢れ、肝心な patch や exec の兆候が埋もれる。我々が定義すべきは、「攻撃者の動機」に直結するログレベルだ。
以下は、実戦で用いるべき高精度な policy.yaml のスニペットである。
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
# 機密性の高いリソースへの変更はすべて記録（Metadataでは不十分）
- level: RequestResponse
resources:
- group: ""
resources: ["secrets", "configmaps"]
# Pod内でのコマンド実行は、攻撃者の生存確認や横展開の証拠
- level: RequestResponse
verbs: ["create"]
resources:
- group: ""
resources: ["pods/exec", "pods/attach"]
# 権限昇格を試みるRBAC変更は、最優先の監視対象
- level: RequestResponse
resources:
- group: "rbac.authorization.k8s.io"
resources: ["clusterroles", "clusterrolebindings"]ポイントは、level: Metadata で満足せず、RequestResponse を適切に配置することだ。攻撃者は kubectl exec でシェルを取った後、直ちに環境変数をダンプする。その際のペイロードまで拾わなければ、何が盗まれたのかを事後に証明することは不可能だ。
—
2. ログパイプラインの深層：SIEMへの転送と「偽装」の排除
ログ転送パイプライン（Fluent Bit等）を構築する際、盲点となるのが「ログ改ざん」だ。攻撃者がコンテナエスケープに成功し、ノードの権限を奪取すれば、audit.log を削除・修正することは容易い。
これを防ぐためのアーキテクチャは以下の通りだ。
1. ホストからの即時吸い上げ: ログはPodではなく、Nodeのローカルパス（例: /var/log/kubernetes/audit/）へ出力し、ホスト側で動作するDaemonSetが即座に別ネットワークのSIEMへ転送する。
2. 不変性（Immutability）の担保: SIEM側で「ログの削除・更新を禁止」するWORM（Write Once, Read Many）ストレージへ直送する。
3. プロトコルレベルの保護: 転送には必ず mTLS を強制し、ログストリーム自体への中間者攻撃を無効化する。
—
3. SIEMでの相関分析：攻撃者の「足跡」を逆算する
単一のログイベントでアラートを出す時代は終わった。今求められるのは、断片的なイベントを線で結ぶ「行動検知」だ。
警戒すべき相関シナリオ
- 「List Secrets」後の「Get Pods」の頻発: 偵察活動の典型的パターン。
- 異常なUser-AgentからのAPIコール:
kubectl以外の不審なHTTPクライアント、あるいはプロンプトインジェクション経由で内部APIを叩く生成AIアプリケーションからの不正アクセス。 - 夜間帯のRBAC変更: 組織の運用サイクルに反する、深夜の
ClusterRole更新。
特に注意すべきは、最近の攻撃者が行う「プロンプトインジェクションを介したKubernetes APIの操作」だ。LLMアプリが ServiceAccount を保持している場合、攻撃者は自然言語を通じてAPIサーバーへの不正な命令を隠蔽しようとする。これに対抗するには、APIコールのリクエストボディ内の文字列を、LLMのプロンプトインジェクションのシグネチャと照合するガードレイルをSIEM層で構築する必要がある。
—
4. 未来への備え：耐量子とゼロトラスト
現在、我々が扱う暗号化通信は量子コンピュータの脅威に晒されつつある。APIサーバーの監査ログを長期保管する場合、将来的な「Store Now, Decrypt Later」攻撃（今盗んで後で解読する攻撃）を考慮しなければならない。
インフラレベルでは、TLS 1.3 の採用はもちろん、近いうちに Kyber 等の耐量子暗号アルゴリズム（PQC）をサポートしたエッジプロキシをAPIサーバーの前面に配置することが必須となるだろう。
—
結論：ログを「知性」へ昇華させるために
Kubernetesの要塞化とは、単にパッチを当てることではない。APIサーバーという心臓部が「誰に」「何を」語ったのかを常に監視し、そのログから攻撃者の次の手を予測することだ。
エンジニアの諸君、監査ログを「ログ出力設定」というタスクで終わらせるな。それは、君たちのインフラを守るための「最も鋭い武器」である。攻撃者が攻撃の痕跡を消そうとした瞬間、その消去作業自体がログとしてSIEMを叩く――そんな美しいディフェンスアーキテクチャを追求してほしい。
コメント