はじめに
こんにちは。
皆さんはAIエージェントを使っているだろうか?
人工知能 (AI) エージェントは、環境と対話し、データを収集し、そのデータを使用して自己決定タスクを実行して、事前に決められた目標を達成するためのソフトウェアプログラムです。目標は人間が設定しますが、その目標を達成するために実行する必要がある最適なアクションは AI エージェントが独自に選択します。
1
とあるように，AIエージェントはこれまでのAIとは異なり，AI自身が次のタスクを決定し，実行まで行うため，これまでとは異なる開発体験を味あわせてくれるであろう。
では，AIエージェントの生産性を上げるためには何をやるべきであろうか。
とはいえ、やっていくとわかるのだが、どんどんユーザー側の確認が緩くなっていく。人間側がボトルネックである自覚を持ってしまうと、そうなるまいとすぐに許可を与えたくなる。2
にあるように，なるべくAIエージェントに権限を移譲することが必要になってくる。
だが，企業でAIエージェントを導入しよとする場合，AIエージェントに好き勝手にコマンドを実行させたり，あらゆるリソースが参照可能な状態での導入は難しいと思われる。
この問題を解決するための1つのソリューションとしてコンテナ内でAIエージェントを実行させることが考えられ，本記事では，この際のセキュリティベストプラクティスについて検討する
前提
- VSCode + Dev Containerを使用する。
Dev Containerはコンテナ内でVSCodeを開くことができる機能である。
- VSCodeのExtensionsも.devcontainer.jsonに記載したものは自動インストールできる→開発環境の共通化
- マルチステージビルドが前提だが，Dockerfileを汚さずに.devcontaier.jsonに記載することでコンテナに開発用のツールやdotfiles(.bashrc等)をもっていける。
- タイトルにClineを入れたがClineに絞って記載はしない。
なぜコンテナを使うのか
- 環境を隔離することで想定外の動作が起きても影響範囲が最小になるから。おそらく，ローカルの全リソースに対してAIが許可なくコマンドを実行できる状態だと，社内のセキュリティ担当者からNGが出されると思う。
- VDIのようなリモート端末の画面を直接飛ばすでも上記は対策可能だが，ネットワークによる遅延があると開発者の生産性を著しく下げてしまうのでローカルで開発を行いたい。
- VM WareやVirtualboxでも別段問題ないのだが，別段GUIはいらないと思うので...
なぜ開発環境コンテナ化を上記で行うのか
- 開発環境をコンテナ化する上である程度枯れているから
-
GitHub Codespacesと相性が良く，クラウド移行時にそのままローカルの開発環境をワンタッチで再現できるから。Codespacesを使いたいケースは以下のイメージ
- AIエージェントと人間が同時に作業をするにはマシンリソースが足りない場合にAIエージェントにはCodespacesを使ってもらう
- 業務用端末でAIエージェントを動かす許可が降りない案件でも，クラウド上でローカルと同じ環境を再現してAIエージェントを動かせる
↑Codespaces作成時にdev_containerを選択するとVSCodeのExtensionsなども含めてローカルの開発環境をCodespaces上に簡単に持っていける。
GitHub Codespacesの場合はGitHubが管理しているため，既にGitHubを使用している企業であればセキュリティ担当者からの許可が下りやすいと思われる。
(既にGitHubにソースコードをおいているのであれば，GitHub Codespacesにソースコードを置くことが嫌がられにくいと予想)
AIエージェントをコンテナ内で実行する際のセキュリティ対策検討
コンテナセキュリティのガイドライン調査
そもそも，コンテナセキュリティにはどのような観点があるのだろうか。
NIST Special Publication 800-190をIPAが翻訳したものをベースにコンテナセキュリティの脅威をざっくり洗い出してみる
- イメージ自体のリスク
- イメージに脆弱性がある
- 悪意のあるイメージを使用してしまう
- イメージに秘密情報を埋め込んでしまう
- コンテナレジストリのリスク
- コンテナオーケストレータのリスク
- コンテナランタイムのリスク
- コンテナでホストしているアプリ自体のリスク
上記を踏まえてAIエージェントが意図しない動作をした場合の脅威のあるシナリオを考えてみる
- AIエージェントがコンテナ外のリソースに対して影響を及ぼす
- インターネット経由でのリソースの書き換え(勝手にデプロイするとか)
- ホストマシンのリソースの書き換え
- 自組織の管轄外のリソースへの攻撃コードの実行/負荷をかけてしまう
(業務用PCの管理方法のガイドラインを探してみたがあまり参考にならなそう)
NIST 800-53を確認を斜め読みしてみたがそんなに関係はなさそう。
具体的なアクションプランをまとめる
イメージ対策
目的: マルウェアなどが含まれたイメージを使用することでAIエージェントが想定外の動作をすることを防ぐため。
-
公式イメージを使うことをDocker Content Trust(DCT)で強制する。
export DOCKER_CONTENT_TRUST=1 # 公式イメージでない場合は拒否する docker pull youstin/nginx Using default tag: latest Error: remote trust data does not exist for docker.io/youstin/nginx: notary.docker.io does not have trust data for docker.io/youstin/nginx
コンテナがホストマシンのリソースにアクセスできないようにする
目的: AIエージェントの操作できるリソースの範囲をコンテナ内に限定するため
# 悪い例
docker run -v /:/mnt/ --privileged -it debian:bookworm "/bin/bash"
のように--privilegedをつけて実行することでホストマシンのリソースにアクセスすることが可能になってしまうので上記を使わない。
CVE-2024-21626のようにホストマシンのリソースに干渉できるCVEもあるのでDocker自体のアプデもしておいたほうが良い。
ネットワーク監視
目的: AIエージェントの動作を記録するため。
- subtraceを使えばコンテナ内の通信もキャプチャしておけば証跡を残せる
- リバースプロキシをローカルで立ててそこで通信を制御しても良さそう(社内ネットワーク経由の通信は監視/制限されているケースが多い気はするが，怒られたくないのであれば)。
コマンド履歴の監視
目的: AIエージェントの動作を記録するため。
- .bash_hisotyrや.zsh_historyをマウントしておくのが無難そう。
// ホストマシンの.bashrcをマウントする例
"mounts": [
"source=${localEnv:HOME}/.bash_history,target=/root/.bash_history,type=bind"
]
- AIエージェントの思考プロセスや出力を記録するのも良さそうだが，使うツールによって保存場所が変わりそうなのが微妙?
参考: 対策案を説明するときにインシデント対応のフレームワークを活用できそる
SANS 504を受けた受講した際にPICERLとそれを改良したDAIRというインシデントレスポンスのプロセスを思い出しので参考までに記載。
各フェーズでどのような施策を行うかをきちんと説明することで，セキュリティ担当者を安心させることができるのではないだろうか。
The incident response model DAIR - Dynamic Approach to Incident Response. It suggests thinking in terms of waypoints, outcomes, and activities. Waypoints are milestones in the incident response process, such as preparation, detection, verification, and triage. These milestones are not necessarily sequential, but rather occur in a cyclical, ongoing process.
(図は著作権に配慮して同様の画像をClaude 3.7 Sonnetを使い作成)
まとめ
- 企業でAIエージェントを活用するためにはセキュリティ対策が求められる
- キーポイントはAIエージェントが影響を与えられる範囲を限定すること→開発環境のコンテナ化が必要
- コンテナ化した環境からAIエージェントが悪さをしないように以下を実施する
- 変なイメージを使わない
-
--privillegeを使ってコンテナからホストマシンのリソースへアクセスできるようにしない - 何らかのネットワーク監視
- コマンドの記録
次回
AIエージェントが使いやすいDev Containerの作り方≒人間が使いやすいDev Containerを作れるようにDev Containerのベストプラクティスをまとめた。