【入門編】 Kubernetes APIサーバーの監査ログ(Audit Log)の設計とSIEM連携 – インフラ・ネットワーク & クラウドセキュリティ防御ガイド

こんにちは！インフラやセキュリティの世界へようこそ。
Kubernetes（K8s）って、コンテナをたくさん管理できて本当に便利ですよね。「なんだか魔法みたいな技術だな〜」とワクワクしながら触っている方も多いのではないでしょうか。

でも、このKubernetesの心臓部である「APIサーバー」――つまり、クラスター全体の司令塔に対して、誰が・いつ・どんな命令を出したのか、ちゃんと把握できていますか？

「えっ、ログなんてなんとなくファイルに出てるんじゃないの？」と思ったそこのあなた！
実は、初期設定のままのKubernetesは、家でたとえるなら「玄関の鍵は閉めたけれど、リビングの窓が開けっ放しで、しかも家の中の防犯カメラが止まっている状態」なんです。誰がこっそり侵入して、どの部屋を物色したのか、後から確認する術がないのはちょっと怖いですよね。

そこで今回は、Kubernetesの「防犯カメラ」にあたる監査ログ（Audit Log）の設計と、それを安全に監視するSIEM（Security Information and Event Management）連携について、身近な例えを交えながら一歩ずつ優しく紐解いていきましょう！

—

1. なぜKubernetesの監査ログが必要なの？（防犯カメラの例え）

想像してみてください。あなたが大切なお宝（機密データや顧客情報）を守るために、立派な一軒家（Kubernetesクラスター）を建てました。玄関には頑丈な鍵（認証・認可）をつけました。

しかし、もし悪意ある泥棒（攻撃者）が、何らかの方法でその鍵を突破して侵入してきたらどうなるでしょう？
玄関の鍵だけを信じきっていると、「誰かが勝手に入ってきて、金庫を開けようとした痕跡」に気づくのが遅れてしまいます。

ここで活躍するのが防犯カメラ（監査ログ）です。
防犯カメラがあれば、以下のような「誰が・いつ・何をしたか」の決定的な証拠がすべて記録されます。

「夜中の2時3日に、見知らぬ来訪者が裏口からこっそり入ってきた」
「リビングの引き出しをあけて、重要な書類を取り出そうとした」

Kubernetesの世界でも同じです。APIサーバーに対するすべてのリクエスト（誰が、どの資源を、どう操作したか）を記録し、不審な動きをいち早く察知するための仕組みが「監査ログ」なのです。

—

2. 監査ポリシー（Audit Policy）を設計する

防犯カメラを設置するとき、「家の前を通るすべての人の足音を24時間録画する」としたら、カメラの容量（ストレージ）がすぐにパンクしてしまいますよね。それと同じで、KubernetesのAPIサーバーのログも、何も考えずにすべて記録（全記録）すると、ログの量が膨大になりすぎて本当に必要な証拠が見つからなくなってしまいます。

そこで重要になるのが、「何をどこまで記録するか」を決める監査ポリシー（Audit Policy）です。

ログの出力レベル（4段階）

Kubernetesでは、記録の細かさを以下の4つのレベルから選びます。

1. None: 一切記録しない（不要なログはこれで省く）
2. Metadata: リクエストのメタ情報（誰が、いつ、どのAPIを叩いたか）だけを記録する。リクエストの中身（ボディ）は記録しない。
3. Request: メタ情報に加えて、リクエストの中身（作成しようとした設定など）も記録する。
4. RequestResponse: リクエストの中身も、サーバーからの返事（レスポンス）もすべて記録する（一番詳細）。

実践的な監査ポリシーの設定例

それでは、実際にAPIサーバーに食べさせる監査ポリシーのYAMLファイルを見てみましょう。実務でそのまま参考にできるよう、丁寧にコメントを入れています。

apiVersion: audit.k8s.io/v1
kind: Policy
rules:
  # 1. 頻繁に発生してセキュリティ上あまり重要ではない「死活確認（ヘルスチェック）」のログは無視（None）して容量を節約します
  - level: None
    nonResourceURLs:
      - "/healthz"
      - "/livez"
      - "/readyz"

  # 2. 機密情報の塊である「Secret（パスワードやAPIキーなど）」の中身がログに露出しないよう、メタ情報だけ（Metadata）に留めます
  - level: Metadata
    resources:
      - group: ""
        resources: ["secrets"]

  # 3. 権限管理（RBAC）に関連する重要な操作は、リクエストとレスポンスのすべて（RequestResponse）を記録して厳重に監視します
  - level: RequestResponse
    resources:
      - group: "rbac.authorization.k8s.io"
        resources: ["clusterrolebindings", "rolebindings"]

  # 4. 上記以外の一般的な操作（Podの作成や削除など）については、基本のメタ情報を記録します
  - level: Metadata
    resources:
      - group: ""
        resources: ["pods", "services", "deployments"]

このポリシーをAPIサーバーが読める場所に配置し、起動時オプションで指定することで、「どこを重点的に監視するか」をコントロールできるようになります。

—

3. ログの転送パイプラインとSIEM連携

さて、防犯カメラの映像（監査ログ）をAPIサーバーのローカル（サーバーの中）だけに保存しているのは、実はとても危険です。なぜなら、もしそのサーバー自体が乗っ取られたら、証拠の映像ごと改ざん・削除されてしまうからです。

そのため、記録したログはリアルタイムで別の安全な金庫（SIEM基盤など）に安全に転送（パイプライン構築）する必要があります。

全体の流れ

1. APIサーバー: 監査ポリシーに従ってログファイル（または標準出力）にログを出力する。
2. ログ転送エージェント（FluentbitやVectorなど）: サーバー上のログを拾い上げ、安全なネットワーク経由でSIEMへ飛ばす。
3. SIEM（Elasticsearch, Datadog, Splunkなど）: 届いたログを蓄積し、怪しい動きがないか監視（相関分析）する。

不正なAPIコールの検知例（相関分析）

SIEMにログが集まってきたら、次のような「怪しいシグナル」を自動検知できるようにルール（アラート）を設定します。

特権Podの勝手な作成: 通常のユーザーが、システムを乗っ取るための特別な権限（privileged: true）を持ったPodを作ろうとした瞬間をキャッチ！
連続する認証失敗: 外部からの不正アクセス（ブルートフォース攻撃）の兆候を検知。
深夜の人目につかない時間帯のロール変更: 権限（Role）を勝手に昇格させる不審なアクションを検知。

—

さいごに

いかがでしたでしょうか？
「Kubernetesの監査ログとSIEM連携」と聞くと、なんだかものすごく難しそうに聞こえますが、要するに「家の防犯カメラをどこに向けるべきか決めて（監査ポリシー）、映像を安全な警備会社（SIEM）にリアルタイムで送る仕組みを作る」ということです。

セキュリティ対策に「完璧」はありませんが、こうした地道な「見張りと記録」の仕組みを整えておくことで、万が一のインシデントが発生した際にも、迅速に原因を突き止めて被害を最小限に食い止めることができます。

一歩ずつ、確実に、安全なインフラストラクチャを作っていきましょう！それではまた次回の記事でお会いしましょう。