本文へスキップ
>_ITDITDセキュリティ対策プラットフォーム

技術別対策

#SSH#アクセス管理#最小権限#鍵管理

侵害され得る環境にroot鍵を渡さない：SSH鍵の最小権限

GPUクラウドのpodやCIランナーのような『一時的で侵害され得る環境』から本番サーバーへSSH鍵を登録していませんか。その鍵が流出すると本番にroot権限で入られます。鍵を最小権限にする考え方と、非rootユーザー＋command制限鍵で『できる操作を1つに絞る』作り方を、当サイトの運用視点で解説します。

公開日 2026-06-11 更新日 2026-06-11 7分で読める

対象：本番サーバーに、GPUクラウドのpodやCIランナー、使い捨てVMのような一時的な環境からSSHで接続している人。ここでは攻撃手順は扱わず、鍵を最小権限にして爆発半径を小さくすることだけを扱います。鍵の分離という土台は 最低限チェックリスト も参照。

当サイトの視点：一時環境は『信頼できない前提』で扱う

使い捨ての計算環境は、堅牢化が後回しになりがちで、侵害され得る場所です。そこに本番へのroot鍵を置くのは、玄関の合鍵を路上に置くようなもの。当サイトはホストごとに別の鍵を使い、用途を絞り、不要になった鍵は即外す運用にしています（→ 鍵を分けて爆発半径を最小化）。鍵は「便利な通行証」ではなく「漏れたら全部開く最重要資産」として扱うのが、結局いちばん安全です。

✗ 一時環境に root 鍵

一時環境が侵害 → その鍵で本番にroot → ファイル・秘密・他サービスまで全部届く。

○ command制限の非root鍵

同じ鍵が漏れても、できるのは指定した1コマンドだけ。シェルも転送も不可＝被害は1操作に閉じる。

鍵の『届く範囲』を最初から小さく設計する。漏れたときの被害が変わる。

なぜ一時環境のroot鍵が危ないのか

一時環境は「すぐ消すから」と堅牢化を省きがちで、攻撃者から見れば狙いやすい踏み台です。そこに本番のroot鍵があると、被害が一気に最大化します。

root→全部
鍵流出で本番が丸ごと奪われる
使い捨て
一時環境は堅牢化が後回し
使い回し
1鍵漏れで全ホスト露出
最小権限
操作を1つに絞れば被害も1つ

たとえば、計算用に一時的に立てたpodから本番へ作業するために、rootのauthorized_keysに鍵を登録したとします。便利ですが、そのpodが侵害されれば、攻撃者はその鍵で本番にroot権限で入れてしまう。実際、入口がRCEでもキー流出でも、最終的に「盗まれた鍵で本番が抜かれる」のは同じ構図です（関連：RCEから鍵が盗まれ不正課金された話）。

鍵を最小権限にする3ステップ

「便利だから全権を渡す」をやめ、「できることを最小に絞る」へ切り替えます。

1

一時環境のroot鍵を外す

使わなくなった鍵は、本番の ~/.ssh/authorized_keys から削除する。アイドルなら消しても無影響。まず『置きっぱなし』を無くす。
2

再び必要でもrootに戻さない

本番作業のために再登録するときは、rootではなく専用の非rootユーザーを作り、そのユーザーに鍵を登録する。万一漏れても、届く範囲がそのユーザーの権限までに限られる。
3

『できる操作を1つに絞った鍵』にする

authorized_keysの鍵行に command="..." と restrict を付ける。その鍵でログインできても、指定した1コマンドしか実行できず、ポート転送やシェルも禁止できる。流出しても被害をその1操作に閉じ込められる。
# 非rootユーザーの authorized_keys に「できる操作を1つに絞った鍵」を登録する例
# この鍵でログインしても、指定コマンド以外は実行できず、転送・PTYも無効
command="/usr/local/bin/deploy-pull",restrict ssh-ed25519 AAAA...rest-of-public-key deploy@ci

restrict は転送・エージェント転送・PTY・X11等をまとめて無効化し、command="..." は実行できる処理を1つに固定します。デプロイの取り込みだけ、特定スクリプトだけ、のように目的1つに絞った鍵を用途ごとに作るのが基本です。

やりがちな構成（危険）

  • 一時pod/CIから本番のrootに鍵を登録
  • 使い終わった鍵を消さずに放置
  • 1本の鍵を複数ホストで使い回し
  • 全権シェルが取れる鍵をばらまく

最小権限の構成

  • 本番へは非rootユーザーでのみ接続
  • 鍵はcommand="..." restrictで1操作に限定
  • ホスト/用途ごとに鍵を分離
  • 不要になった鍵は即authorized_keysから削除

『使い回し鍵＝最重要資産』として扱う

鍵を『便利な通行証』だと思うと、つい使い回し、消し忘れます。発想を逆にして、1つ漏れたら全部開く最重要資産として扱う。ホストごと・用途ごとに分け、一時環境には本番の鍵を置かず、置いたら使用後に必ず消す。これだけで「1本の漏えいが全体に波及する」最悪の連鎖を断てます。

当サイトはどうしているか

当サイトは、サーバーごとに専用の鍵を使い、鍵を使い回しません。デプロイは受け取り側を非rootの専用ユーザーにし、本番は「外へ取りに行かず、受け取るだけ」という一方向の構成にしています（→ 本番は受け取るだけ）。一時的な計算環境から本番へ常時の鍵を残すことはせず、必要時だけ最小権限で繋ぎます。理由はこの記事のとおりで、1か所の侵害が全体に波及しないように、鍵の届く範囲をあらかじめ小さく設計しておくためです。

次に読む

よくある質問

Qなぜ一時環境にroot鍵を置くと危険なのですか？
A

GPUクラウドのpodやCIランナーのような一時環境は、使い捨てゆえに堅牢化が後回しになりがちで、侵害され得ます。そこに本番サーバーへのroot鍵を置くと、その環境が侵害された瞬間に、鍵ごと本番のroot権限を奪われます。一時環境は『信頼できない前提』で扱い、本番へのroot鍵は置かないのが原則です。

Qそれでも一時環境から本番へ接続したい場合は？
A

rootに戻さず、専用の非rootユーザーを作り、そのユーザーに『できる操作を1つに限定した鍵』を登録します。authorized_keysで command="..." と restrict を付けると、その鍵でログインできても指定した1コマンドしか実行できません。流出しても被害をその1操作に閉じ込められます。

Q鍵管理でいちばん大事な原則は何ですか？
A

『使い回しの鍵＝最重要資産』と捉え、1つ漏れたら全部抜かれる構成にしないことです。ホストごと・用途ごとに鍵を分け、不要になった鍵はauthorized_keysから消す。これで1本の漏えいが全体に波及するのを防げます。