はじめに
前回の記事では Claude Code から SSH を利用して IBM i を操作する方法を紹介しました。
<前回の記事>
実際に使ってみるとかなり便利で、
grep
cat
find
db2util
system
などを利用して調査や開発作業を進めてくれます。
ただし、そのまま本番環境で運用するのは少し怖いです。
そのため今回は Claude Code + SSH を少し安全に運用する方法を紹介してみます。
この記事は絶対的な安全を目指すものではありません。Claude Code の便利さを残しながら、事故を減らすことを目的にしています。
また、前回の記事のように Claude Code から SSH を利用して IBM i を操作している前提で記述しています。
まずは専用ユーザーを作る
これは必須かなと思います。
Claude Code 用のユーザーを作り
- *ALLOBJ
- *SECADM
などの特殊権限は付与しないようにしましょう。
また、ライブラリやファイルの権限も見直します。
Claude Code はシステムの調査で
- QSYS
- QSYS2
をよく参照します。
例えば、
- ライブラリ一覧
- ファイル定義
- テーブル定義
- カラム情報
などは頻繁に参照します。
そのため、QSYS や QSYS2 については多くの環境で一般ユーザーと同様に参照可能なまま運用しても良いかなと思います。
一方で、業務データについては必要なものだけに絞ります。
例えば、
- 受注管理ライブラリ
- 顧客管理ライブラリ
だけ参照可能にする。
人事や給与など関係ないライブラリは見せないようにします。
また、更新が必要な場合は本番ライブラリではなく専用の作業ライブラリを用意する方が良いでしょう。
IBM i の管理者であれば普段からやっていることだと思いますが、相手が Claude Code になったからといって特別な権限を与える必要はありません。
IFSも少しだけ気にする
前回の記事だと Claude Code は SSH 経由で PASE のコマンドを実行しています。
そのため、ライブラリ権限だけでなく IFS の権限も少し確認しておくと安心です。
Claude Code は /home、/tmp、/QOpenSys をよく利用します。
特に /QOpenSys は PASE のコマンド群が配置されているため、ここを閉じてしまうとほとんど動かなくなります。
個人的には、
- 必要な場所は残す
- 不要な場所だけ閉じる
くらいが現実的だと思います。
OpenSSHにはGuardを挟む仕組みがある
今回の記事の本題です。
OpenSSH の authorized_keys には
command=
という機能があります。
例えば、
command="/home/CLAUDEAI/bin/guard.sh"
を設定すると、
Claude Code が SSH 経由でコマンドを実行した際に、まず guard.sh が呼ばれます。
そして、実行しようとしたコマンドは
SSH_ORIGINAL_COMMAND
環境変数から取得できます。
つまり、
ssh ibmi "grep ERROR app.log"
※ibmiは.ssh/configに登録したSSHのエイリアスです
を実行した場合でも、
実際には
guard.sh
が最初に実行され、
grep ERROR app.log
という情報を環境変数SSH_ORIGINAL_COMMANDから取得できます。
簡単なGuardを書いてみる
例えば、
#!/usr/bin/bash
cmd="${SSH_ORIGINAL_COMMAND:-}"
echo "$(date '+%Y-%m-%d %H:%M:%S') : $cmd" >> /home/CLAUDEAI/guard.log
case "$cmd" in
*"rm -rf "*|\
*"find "*"-delete"*|\
*"find "*"-exec"*|\
*"DLTLIB "*|\
*"DLTOBJ "*|\
*"CLRPFM "*)
echo "Denied by guard"
exit 1
;;
esac
# 対話ログインの場合
if [ -z "$cmd" ]; then
exec /usr/bin/bash -l
fi
exec /usr/bin/bash -lc "$cmd"
※環境によっては bash のパスが /QOpenSys/pkgs/bin/bash の場合があります。
こんな感じです。
非常に単純ですが、
rm -rf
DLTLIB
DLTOBJ
CLRPFM
などの明らかに危険な操作を防げます。
またログも残せるため、
Claude Code が何を実行したのか
を後から確認することもできます。
実際にやってみる
まずはguard.shを/home/CLAUDEAI/binに配置し、
chmod +x /home/CLAUDEAI/bin/guard.sh
で実行権限を付与します。
次に CLAUDEAI ユーザーの .ssh/authorized_keys を変更します
command="/home/CLAUDEAI/bin/guard.sh",no-port-forwarding,no-X11-forwarding,no-agent-forwarding ssh-ed25519 AAAA...
command="/home... だけでno-port-forwarding,no-X11-forwarding,no-agent-forwardingはなくてもいいです。ここでは単にsshで使わない機能を指定しているだけです。
これで準備は完了したので、クライアントからコマンドを指定してsshを実行してみます
rm -rf のコマンド実行で Denied by guardが出力されていますね。成功です。
次に本命のClaude CodeでGuardを試してみます。
まずはClaude Codeのプロンプトで
TESTLIBを調査してください
をお願いしてみました。
ちゃんと調査できましたね。
続いてGuard対象の DLTLIB(ライブラリ削除)コマンドがちゃんとブロックされるか試すためにプロンプトに
TESTLIBは不要になったので削除してください
をお願いしてみました…結果は
実行がガードされました。やったね
あくまで簡易的
もちろん、これで完全に安全になるわけではありません。
シェルスクリプトだけでコマンドラインを厳密に解析するのは難しいですし、複雑なワンライナーやパイプラインを考慮し始めるとかなり大変になります。
もし本気で制御したい場合は、
- Python
- Node.js
などで SSH_ORIGINAL_COMMAND のコマンドラインを解析し、
- コマンド
- オプション
- 対象ファイル
単位で判定することもできます。
ただ、そこまでやると運用も複雑になるので、
今回の
- 専用ユーザー
- ライブラリ権限
- IFSの確認
- 簡単なGuard
くらいから運用していくのでも結構良いかなと思います。
まとめ
前回の記事では、とにかく Claude Code から IBM i を簡易的に触ることを優先したため、セキュリティはガバガバでした。
ただ IBM i はもともと
- ユーザー
- ライブラリ
- オブジェクト
- IFS
を細かく制御できる仕組みを持っていますし、OpenSSH で Guardを入れることで、AIエージェントが意図しないコマンドを実行する といった事故をある程度防ぐことができます。
最近は AI エージェント用のコンテナやサンドボックス環境を用意して利用する話もよく見かけます。
ただ IBM i の場合は、
- このライブラリだけ見せる
- このファイルだけ更新させる
- このユーザーには見せない
といった制御を比較的自然に行えます。
IBM i は Claude Code のような AI エージェントを利用する場合も、意外と相性の良いプラットフォームなのかなって思います
少なくとも今回試した範囲では、Linuxで権限を頑張って組むよりも考えやすく感じました。
AIエージェント時代になって、IBM i の権限制御の細かさが改めて活きてくるのかもしれませんね。
今回の記事には含めていませんが、Claude Code側でガードやルールを記述する仕組みもあります。ただすり抜けて実行する危険性もあるので、IBM i側でもガードしようというのが今回の目的です。
Claude Code の permissions や hooks なども併用するとより安全です