サーバの鍵は、家の合鍵と同じ — 「配らない・見せない・残さない」運用の作り方

会社のサーバには、鍵がある。家の玄関の鍵と同じで、持っている人だけが中に入れる。違うのは、1つの家に何十人も出入りし、鍵の持ち主が毎年入れ替わることだ。

当社は、この鍵を「配らない」運用に変えた。社員に配る鍵は物理のYubiKey（入社時に渡し、退職時に回収）。お客様から預かった鍵は、作業者の手元に置かず、必要なときだけ取りに行く。ここでは、その仕組みを家の鍵に置き換えて説明する。技術的な詳細は、エンジニア向けのコラムに書いた。

合鍵を配ると、何が困るのか

家の合鍵を10人に配ったとしよう。街に10本の合鍵が存在することになる。誰が持っているかの一覧を作り、退去のたびに返してもらい、なくしたら鍵穴ごと交換する。交換すれば、家中の鍵が新しくなる。

サーバの鍵も同じだ。配った数だけ、複製の可能性が増える。しかもデジタルの鍵は、返してもらったつもりでも、コピーが残っていないことを証明できない。ここが一番厄介な点だ。

だから当社は、社内のサーバについては鍵を配らない。物理の鍵（YubiKey）を1人1本にして、入社時に渡し、退職時に回収する。鍵の中に秘密の情報が入っていて、外に取り出せない。人が辞めれば、鍵ごと返ってくる。

自社の話はこれで片づく。難しいのは、お客様の家（サーバ）の鍵を預かるときだ。預かった鍵の置き場所は、大きく3つに分かれる。

どれも「複製できる場所に、鍵の形で置いてある」という点では同じだ。キーボックスを決めても、ポケットに入れないことは、ルールでは決められても、実際には保証できない。

そこで当社は、鍵そのものを持たない形にした。預かった鍵は AWS Secrets Manager という金庫にしまっておく。作業者は金庫の場所も暗証番号も知らない。専用のコマンドを1回打つと、裏で金庫から鍵が出てきてドアが開き、使い終わると鍵は戻る。

金庫を開けられるのは、社内の決められたネットワークに入っている端末だけ。そのネットワークに入るには、本人の認証と端末の登録が要る。外から金庫に触ることはできない。

どの鍵でどのドアを開けるかは、サーバー側の対応表が決める。作業者は住所（接続先）を指定するだけで、鍵を選ばない。鍵の名前も置き場所も、作業者には見えない。

ビルによっては正面から入れず、裏口の管理人室を通らないと目的の部屋に行けないことがある。サーバの世界では「多段SSH」と呼ばれていて、以前は「まず管理人室に入り、そこから目的の部屋へ」と2回操作していた。

いまは行き先を指定するだけで、裏口の鍵も自動で用意され、経路も組まれる。作業者は、建物の裏事情を意識しなくてよい。

鍵を持たせない運用の副産物として、記録が残る。誰が、いつ、どこに、どの鍵で入ったか。ドアを開ける直前に記録され、作業画面に受付番号が出る。

ビルの入退室記録と同じだ。問題が起きたときに「誰がいつ入ったか」を、記憶ではなく記録で説明できる。鍵の持ち出しと入室の記録が同じ場所にあるので、突き合わせも簡単になる。

良くなったこと。

変わらないこと（残る手間とリスク）。

鍵を配らないことは、鍵が漏れないことと同じではない。金庫の権限と記録が効いているかを、定期的に見続ける必要がある。

同じ形を作るかどうかを決める前に、次の3つに答えられるかを見てほしい。

どれか1つでも「できない」なら、鍵の置き場所を変える前に、台帳と手順を整える必要がある。道具を先に買っても、鍵の管理は良くならない。

当社は、この形を作った経験をもとに、鍵の管理と入室の記録を整える支援をしている。預かった鍵の置き場所の設計、誰がどのサーバに入れるかの整理、記録の残し方、そこへ移るまでの手順だ。

「合鍵をどう配るか」ではなく「合鍵を配らずに済ませられないか」。預かった鍵の扱いに悩んでいる方は、お問い合わせください。

技術的な仕組み（YubiKey・Secrets Manager・多段SSH・記録の取り方）は、エンジニア向けのコラム「SSHの鍵を作業者に渡さない」で詳しく書いています。

AWS「AWS Secrets Manager」— 秘密情報の保管・アクセス制御・取得履歴

本記事は2026年10月時点の当社の運用に基づいています。接続先・鍵の名前・対応表の中身など、構成の詳細は公開していません。