【入門編】 Kubernetes監査ログ(Audit Logs)の高度な分析と検知ルール – インシデントレスポンス & フォレンジック（DFIR）防御ガイド

こんにちは！セキュリティの世界へようこそ。
日々、システムの安全を守るために奮闘されている新人エンジニアの皆さん、そして開発の現場で「セキュリティってなんだか難しそうだな…」と感じている一般開発者の皆さん、お疲れ様です。

今回は、現代のインフラストラクチャの主役である「Kubernetes（K8s）」のセキュリティ、その中でも「監査ログ（Audit Logs）」を使った高度な分析と異常検知について、現場のリアルな視点を交えながら、一歩ずつ優しく紐解いていきたいと思います。

難しそうな用語が出てきても大丈夫です。身近な例えをたくさん使って解説しますので、コーヒーでも飲みながらリラックスして読んでいってくださいね。

—

1. 家の鍵と防犯カメラに例える「Kubernetes監査ログ」

まずは、Kubernetesがどんな仕組みなのか、そして今回注目する「監査ログ」がなぜそんなに重要なのかを、私たちの身近な「家」に例えて考えてみましょう。

Kubernetesは「シェアハウスの管理人」

Kubernetesは、たくさんのアプリ（コンテナ）を効率よく動かすための巨大なシステム、いわば「超高層シェアハウス」のようなものです。このシェアハウスには、たくさんの住人（開発者、外部サービス、自動化プログラム）が出入りしています。

そして、このシェアハウス全体の管理を取り仕切っているのが、「APIサーバー」という管理人さんです。住人が「部屋の電気をつけたい」「新しい家具を運び入れたい」といったお願いをするときは、必ずこの管理人さんを通すルールになっています。

監査ログ＝「管理人さんがこっそりつけている詳細な日誌」

管理人さんは、誰が、いつ、どこへ行って、どんなお願いをしたのかを、一言一句もらさずに専用のノートに書き留めています。これが「Kubernetes監査ログ」です。

もし泥棒がこのシェアハウスに忍び込み、合法的な鍵をどこからか手に入れて管理人室の金庫を開けようとしたとします。防犯カメラがない普通の部屋だったら気づきにくいですが、この「監査ログ」という詳細な日誌があれば、後から「深夜3時に、普段は絶対に入らない人が、金庫の鍵を開けようとした痕跡がある！」とバッチリ見つけることができるのです。

—

2. 攻撃者はどうやって侵入し、何を狙うのか？

現場のインシデントレスポンス（侵害調査）を実際にやっていると、攻撃者がKubernetes環境をどのように狙ってくるのか、その手口のトレンドが見えてきます。

彼らの主な目的は、「特権昇格（管理员権限の奪取）」です。
例えば、一般の住人が使える部屋の鍵（低い権限の認証トークン）を何らかの方法（脆弱性を突く、コードに書き込まれたパスワードの漏洩など）で盗み出したとします。そこから、管理人さんをも言いくルメルような嘘をついて、「この部屋だけでなく、ビル全体のマスターキーを私にください！」と要求するような不正なリクエストをAPIサーバーに送りつけるのです。

私たちが監視しなければならないのは、まさにこの「不自然な権限の要求」や「普段とは違う動き」なんですね。

—

3. 監査ログを有効化・設定してみよう

Kubernetesの標準状態では、せっかくの管理人さんの日誌（監査ログ）が記録されていなかったり、記録されてもすぐに消えてしまったりすることがあります。まずは、しっかりとログを残すための設定を行いましょう。

APIサーバーを起動する際の設定ファイル（通常は /etc/kubernetes/manifests/kube-apiserver.yaml など）に、以下のようなポリシーファイルを読み込ませる設定を追加します。

# APIサーバーの起動時オプションの例です
apiVersion: v1
kind: Pod
metadata:
  name: kube-apiserver
  namespace: kube-system
spec:
  containers:
  - name: kube-apiserver
    image: k8s.gcr.io/kube-apiserver:v1.28.0
    command:
    - kube-apiserver
    # 監査ログのポリシーファイルの場所を指定します
    - --audit-policy-file=/etc/kubernetes/audit-policy.yaml
    # 監査ログを出力するログファイルの保存先を指定します
    - --audit-log-path=/var/log/kubernetes/audit.log
    # ログを何日間保持するか
    - --audit-log-maxbackup=10
    # 1ファイルあたりの最大サイズ（MB）
    - --audit-log-maxsize=100

そして、どんなリクエストをどれくらい細かく記録するかを決めるのが「監査ポリシー（Audit Policy）」です。すべてを記録するとログの容量がパンクしてしまうため、重要なイベントに絞って記録するのが実務のコツです。

# 監査ポリシーファイルのサンプル (audit-policy.yaml)
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
  # 機密性の高いシークレット情報へのアクセスは、内容も含めて厳しく（RequestResponseレベルで）記録する
  - level: RequestResponse
    resources:
    - group: ""
      resources: ["secrets"]

  # 一般的なリクエストは、誰が何をしようとしたか（Metadataレベル）を記録する
  - level: Metadata
    resources:
    - group: ""
      resources: ["pods", "services", "deployments"]

  # ノイズになりやすい健全性チェック（ヘルスチェック）などのログは記録しない
  - level: None
    nonResourceURLs:
    - "/healthz"
    - "/livez"
    - "/readyz"

このように設定することで、管理人さんは「どの住民が」「どのシークレット（秘密情報）に触ったか」を正確にノートに書き残せるようになります。

—

4. SIEM連携による異常検知パターン

さて、日誌が溜まるようになったのは良いですが、毎日何万行ものログを人間の目でずっとチェックするのは不可能ですよね。そこで登場するのが、SIEM（Security Information and Event Management：ログを自動で分析してくれる賢いシステム）です。

現場で実際に使われている、「絶対に検知したい怪しい動き」のパターンを2つご紹介します。

パターンA: 突然の「クラスタ管理者（cluster-admin）」権限の付与

攻撃者が一般ユーザーの権限を乗っ取った後、最初に行うのが「自分を神様（すべての権限を持つ管理者）にする」という作業です。これをKubernetesの言葉では、ClusterRoleBinding や RoleBinding の作成・変更と呼びます。

SIEMで仕掛ける検知ルールのイメージ（クエリの例）：

-- SIEM（ElasticsearchやDatadogなど）で実行する検索クエリのイメージ
SELECT 
    user.username, 
    objectRef.resource, 
    verb, 
    responseStatus.code
FROM 
    kubernetes_audit_logs
WHERE 
    verb IN ('create', 'update', 'patch') -- 作成や更新のアクション
    AND objectRef.resource = 'clusterrolebindings' -- 管理者権限のバインディング操作
    AND responseStatus.code = 201 -- 成功した場合
    AND user.username NOT IN ('system:serviceaccount:kube-system:cluster-autoscaler', 'admin-ci-tool') -- 既知の正当な自動化ツールを除外

もし、普段見慣れない一般アカウント名が clusterrolebindings を作成し、それが成功していたら…？ これは一刻を争う緊急事態（インシデント発生）です！直ちに該当アカウントを無効化する調査に入りましょう。

パターンB: 隠し通路の作成（特権Podのデプロイ）

攻撃者は、Kubernetesのホスト（基盤となるサーバー）自体を乗っ取るために、あえて危険な設定（ホストのネットワークやストレージを直接触れる設定）を持った「特権コンテナ」をこっそり作ろうとします。

検知のポイントとなる設定値：
監査ログの中に、以下のキーワードが含まれていないかを監視します。

  • privileged: true （何でもできてしまう特権コンテナのフラグ）
  • hostNetwork: true （ホストのネットワーク空間に直接侵入する設定）
  • hostPID: true （ホストで動いている他のプロセスを覗き見できる設定）

これらが通常のアプリケーション開発の文脈から外れて突然デプロイされた場合、それは侵入者が自分たちの「隠し通路」を作っている動かぬ証拠になります。

—

5. まとめ：一歩ずつ、確実な防犯体制を築こう

今回は、Kubernetesの監査ログの仕組みと、現場のプロが実践している異常検知のアプローチについてお話ししました。

  • 監査ログは、APIサーバーという管理人さんが残してくれる詳細な日誌である。
  • すべてを記録するのではなく、監査ポリシーを使って重要なリクエスト（シークレットや権限変更）に絞って効率よく残す。
  • SIEMを活用して、不自然な権限昇格（clusterrolebindingsの作成）や危険な特権コンテナの作成を自動で検知できるようにする。

セキュリティ対策は、一度にすべてを完璧にやろうとすると息切れしてしまいます。「まずはログの出力設定を有効にしてみよう」「次は怪しい権限変更のアラートを作ってみよう」といったように、一歩ずつ着実に進めていくことが何よりも大切です。

皆さんのインフラ環境が、今日も安全で快適な場所であることを願っています。それでは、また次回の記事でお会いしましょう！

スポンサーリンク

コメント

タイトルとURLをコピーしました