検索
特集/連載

複雑なKubernetesクラスタは“手作業”では守れない? 「SLM」が導く解決策機密データを守るローカルAI

Kubernetesクラスタにおいて、過剰な権限などの設定ミスはデータ漏えいを引き起こす要因になるが、脅威を手作業で洗い出すことにも限界がある。外部にデータを渡さずに、AI技術で素早くリスクを評価する手法とは。

PC用表示 関連情報
Share
Tweet
LINE
Hatena

関連キーワード

人工知能 | セキュリティ対策 | 仮想化


 コンテナオーケストレーションツール「Kubernetes」で、複数サーバを連携させて1つのシステムとして機能させる「Kubernetesクラスタ」を活用する上では、その構成の複雑さがセキュリティ面での課題になっている。特に金融機関のような規制の厳しい業界では、開発中の製品やサービスがどのようなセキュリティリスクにさらされているかを特定して、事前に対策を打ち出す「脅威モデリング」をアプリケーションごとに実施しなければならない。しかし、手作業による従来のアプローチでは、システムの分析に2、3週間の時間を要していた。

 クラウドインフラは日々変化しており、手動の評価プロセスでは現状に追い付くことが難しい。そこで登場したのが、生成AIを活用した脅威モデリングの自動化という新たな仕組みだ。

 この仕組みは、軽量化されたAIモデル「SLM」(小規模言語モデル)と、外部のデータベースから関連情報を検索して回答精度を高める技術「RAG」(検索拡張生成)を組み合わせた手法だ。過去の脅威モデルやセキュリティ標準のデータをAIモデルに読み込ませることで、Kubernetesクラスタ内の脆弱性を自動的に洗い出してリスクスコアを弾き出す。これによって、評価作業をわずか1、2日に短縮できるという。

 機密性の高いシステム情報を外部のAIモデルに渡さず、SLMとRAGを組み合わせた脅威モデリングはどうすれば実現できるのか。具体的な導入事例と技術的な詳細を解説する。

数週間の作業をわずか1日に短縮したSLM×RAG

 2025年11月に開催されたセキュリティイベント「Open Source SecurityCon」において、カナダの金融機関であるRoyal Bank of Canada(RBC)のマキシム・コクレル氏が登壇し、取り組みの内容を語った。

 Kubernetesクラスタは、クラスタの制御を担う中核機能「APIサーバ」、各ノードでコンテナを管理する「Kubelet」、設定情報を保存する分散データベース「etcd」といった多様なコンポーネントで構成される。その上、マイクロサービス間の通信を制御するサービスメッシュや、認証キーを保護するシークレット管理ツールなどが絡み合っているため、攻撃対象領域は極めて広い。コクレル氏によれば、コンテナの特権昇格や過剰な権限設定などが主な侵入経路として狙われやすい。

 例えばetcdは、デフォルト状態では保存データが暗号化されない。攻撃者がノードへのアクセス権を得た場合、Kubernetesにおける最小のデプロイ単位である「Pod」を侵害する危険性も潜んでいる。管理対象のクラウドサービスと連携する際、自動実行用のIDである「サービスプリンシパル」に過剰な権限を持たせてしまうといった設定ミスも、重大なデータ漏えいを引き起こす要因だ。

 こうした脅威を網羅的に把握して適切な対策を講じるためには、体系的なフレームワークに基づいた定期的な評価が欠かせない。RBCではセキュリティレビューから始まり、実際のサイバー攻撃を模倣したペネトレーションテスト(侵入テスト)、スコアカード評価にまでの一連のガバナンス体制が整備されている。とはいえ、全てのクラウドサービスに対して、手作業で詳細な脅威モデリングを実施するのは非現実的だった。

 この課題を打破するためにコクレル氏が構築したのが、手元のPCで動作するオフラインのAIツールだ。外部と通信するLLM(大規模言語モデル)は情報漏えいのリスクがあるため、厳しい規制条件がある場所では利用が難しい。そこで、外部と通信を行わずに手元のPCで動作する「Phi-4」などのSLMを採用した。

 このAIツールの中核を担うのが、RAGを活用した知識の集約だ。社内の過去の脅威モデルや、システムを安全に構築するための基準「CIS Benchmarks」、サイバー攻撃の手法を体系化した「MITRE ATT&CK Matrix」といったドキュメントを分割し、オープンソースデータベース「ChromaDB」に格納。セキュリティ担当者がWebブラウザでシステムの構成情報を入力すると、SLMはベクトルデータベースから関連規定を検索し、精度の高い脅威モデルを提示する。

 この仕組みの独自性は、出力される結果の再利用性の高さにある。自然言語で脅威のリストを提示するだけではなく、プログラム間でデータをやりとりする際に扱いやすい「JSON」形式で出力できる点も大きな特徴だ。JSON形式であれば他のセキュリティ管理システムへの取り込みが容易になり、スコアカードの作成や評価プロセスへの連携がスムーズになる。

 SLMは、脅威を「なりすまし」「改ざん」など6つの性質に分類する「STRIDE」などの脅威モデルに基づき、各リスクの発生確率と影響度を数値化して優先順位を付与する。これによって、担当者のスキルレベルに依存しない、一貫性のある定量的なリスク評価が可能になった。

 コクレル氏は、セッション登壇時点では手動での入力と評価を支援する段階だが、将来的にはCI/CD(継続的インテグレーション/継続的デリバリー)パイプラインとの連携を視野に入れていると説明した。ワークフロー自動化ツールと組み合わせることで、クラウドインフラの設定変更が検出された瞬間に自動で差分を抽出し、再評価を実行するプロセスが想定されている。

 絶えず拡張を続けるシステムにおいて、自動化された継続的な脅威モデリングは、開発スピードを損なうことなく安全性を確立する有効な手段となる。高度なセキュリティを要求される条件下において、SLMとRAGを活用したアプローチは、新たな標準へと発展していく可能性を秘めている。

本稿は、Cloud Native Computing Foundation(CNCF)が2025年11月25日に公開した動画「Threat Modeling for Kubernetes: Enhancing Security Posture in Complex and Regulat... Maxime Coquerel」を基に作成しました。

Copyright © ITmedia, Inc. All Rights Reserved.
本記事は制作段階でChatGPT等の生成系AIサービスを利用していますが、文責は編集部に帰属します。

ページトップに戻る