APIキーを誰が戻せるか：VPSの認証情報と引継ぎの台帳

運営・編集: VPS運用ノート編集部（編集方針）

DBを戻せても、必要な鍵を取り戻せなければ処理は再開しない。秘密の値そのものを一覧に貼る代わりに、保管場所、使うサービス、復旧できる人を台帳にする。

契約の名義と、操作する人を分ける

当サイトで引継ぎを考える時は、VPSに入れる人だけでなく、支払いとアカウント復旧の権限も確認する。下の表に書くのは識別名や保管先の参照で、パスワードやトークンの値ではない。

担当が一人に集中しているなら、その人が不在のときにアカウントを復旧する経路まで確認する。外注先の個人アカウントだけに依存する構成なら、委託終了時に何を引き継ぐかを先に契約で決める。

Compose secretsは、渡すサービスを限定する仕組み

Docker Composeのsecrets資料では、秘密を定義し、必要なサービスに明示的に渡す方法を説明している。コンテナからは/run/secrets内のファイルとして扱う。

これを一般のComposeで使っただけで、ホスト上の保存物まで暗号化されると説明しない。Swarmの秘密管理と同じ仕組みとして混同せず、元ファイルの権限と保存先も管理する。また_FILE形式の環境変数は対応イメージ側の慣習で、任意のアプリが自動で読める共通仕様ではない。資料確認日: 2026年9月14日。

環境変数を出力したログや、設定を展開した画面にも秘密が含まれる場合がある。相談用に共有する時は、必要なキー名とエラーの箇所だけを残し、値は取り除く。

n8nはDBと暗号化キーを一緒に考える

n8nの暗号化キー資料は、保存した認証情報を暗号化する鍵を説明している。初回生成される鍵の保管先や、自分で指定する方法を確認し、queue modeではworkerも同じ鍵を使う条件を読む。

鍵を失った状態でDBだけを復元する計画にはしない。鍵を変更すると既存の保存情報をどう扱うかも対象版の手順で確認する。この記事は鍵を無条件に交換する実行手順ではなく、何を退避・照合するかの整理である。

当サイトの復元実験ではダミー設定ファイルの一致を確認したが、n8nの実際の認証情報の復号は検証していない。ファイルが存在することと、アプリで使えることも別の確認になる。

委託終了・退職・漏えいのとき

利用者が離れる時は、その人の権限を失効させる対象を台帳からたどる。共有の鍵を使っていたなら、交換後にどのサービスの設定を変更し、どの処理が再開したかを照合する。

漏えいが疑われる場合は、保存場所を変えるだけでは既に渡った鍵を止められない。発行元の失効・再発行手順、アクセス記録、影響を受ける処理を確認し、組織の対応窓口へ引き継ぐ。秘密の値をこのサイトへ送る欄はない。

更新・交換の実施時間は保守の作業票で決める。管理画面やOSまで誰が扱うかは保守担当の境界へ。新しいVPSを契約する前にも、この台帳の所有者を決めておく。