SSHの鍵を作業者に渡さない — YubiKeyとSecrets Managerで作った鍵レス運用

当社ではここ数年でシステムの大半がKubernetesに移り、SSHを開く場面はかなり減りました。ログもメトリクスも手元で見られますし、サーバの変更はコードとパイプラインを通ります。それでも、SSHが完全に無くなったわけではありません。

当社が社外にSSHの運用を説明する機会は、ほとんどありませんでした。侵入の入り口として認証情報が狙われる出来事が続く中で、「預かった鍵をどう扱っているか」は、お客様が知りたい情報のひとつだと考えています。そこで、いま動いている仕組みを整理しました。

結論から書くと、自社のサーバに対して当社はパスワードも鍵ファイルも使いません。統合認証とYubiKeyで入ります。お客様から預かる鍵は作業者の手元に置かず、AWS Secrets Managerから都度取得し、SSHが終わったら消す。作業者は鍵そのものを見ません。

SSHは減ったが、ゼロではない

コンテナ化で減ったのは、サーバに入らないと分からない種類の作業です。アプリの状態はログとメトリクスで見えますし、設定の変更はGitに残ります。「入って確認する」必要性そのものが下がりました。

それでも残るものはあります。ネットワーク機器、移行が終わっていないホスト、コンテナの外で動いているミドルウェア、そして障害の初動でホスト側の状態を直接見たいときです。例外のまま放置すると、例外のほうが管理されなくなります。だから当社は、残ったSSHを「特別な作業」ではなく「手順として管理する対象」にしました。

なぜ鍵とパスワードをやめたか

鍵は、配るものにした瞬間から増えます。配布した先、保管場所、失効のタイミング、ローテーションの周期。どれも台帳と運用が要ります。退職した人の端末に鍵が残っていないことを、どの作業で証明するのかも決めにくい。

パスワードはもっと単純に危ない。使い回され、推測され、別の場所から漏れた文字列で試されます。鍵は推測できませんが、コピーはできます。そしてコピーされたことに、持ち主が気づけないことも多い。自社のサーバについては、この2つを配らない形にしました。物理のYubiKeyと統合認証です。

秘密鍵をYubiKeyに置く

YubiKeyを使ったSSH認証にはFIDO2・PIV・PGP・OTPの4通りがあります。当社が使っているのはFIDO2で、OpenSSH 8.2以降の ed25519-sk / ecdsa-sk に対応します。秘密鍵はYubiKeyの中で生成され、外に取り出せません。端末が侵害されても、鍵そのものは持ち出せない場所にあります。

入社時に物理のYubiKeyを1本渡し、統合認証のアカウントと結びつけます。退職時には回収します。鍵ファイルを配って回収する運用と違って、「手元に無いこと」を物理で示せます。端末を入れ替えても鍵はYubiKeyに残るので、新しいPCへ鍵を移す作業も要りません。

鍵のローテーションも、基本的には人が回す作業ではなくなりました。鍵はYubiKeyに紐づき、人が替わるタイミングで物理キーが替わる。台帳とスケジュールで守るのではなく、持ち物として管理する形です。

預かった鍵を作業者に見せない

自社のサーバは、これで片づきます。難しいのは、お客様の環境にSSHするための鍵を預かる場合です。運用を代行していれば、鍵を渡されるか、こちらで作って登録することになります。

よくある置き方は3つです。共有のサーバに置いて全員が使う。作業のたびに ~/.ssh に置く。各自のPCに置いたままにする。どれも、コピーできる場所に平文で置いているという点では同じです。

ルールで禁止することはできます。ですが、ディスクの上でコピーを止めることはできません。禁止したことと、起きていないことは別です。鍵がどこに何個あるかを正確に答えるのは、この形では難しくなります。

鍵を配らない、は自社でできた。預かった鍵で同じことをやるには、置き場所と渡し方を変えるしかなかった。

鍵はネットワークの中から

預かった秘密鍵は、AWS Secrets Managerに置いています。保管時の暗号化はKMS、取得できる範囲はIAM、APIの呼び出しはCloudTrailに残ります。鍵の実体をファイルサーバに置かず、取得の履歴が残る場所に寄せる、という整理です。

鍵を返すAPIは、当社のゼロトラスト型リモートアクセス基盤（社内ではZDRと呼んでいます）の中にだけ置いています。インターネットからは届きません。端末と利用者の認証を通った端末だけが、このAPIに到達できます。基盤に入れない人は、APIの存在にすら触れません。

対象のネットワークに到達できるかどうかも、この基盤側の権限で決まります。権限のない利用者は、鍵を取る以前に接続先へ届きません。基盤そのものの管理は、限られたエンジニアだけが行います。

鍵も多段もAPIが選ぶ

「この接続先にはこの鍵」という対応表も、サーバー側で管理しています。クライアントには置きません。作業者が使うのは rhems-ssh というコマンドだけで、鍵を自分で取り出す操作はありません。

rhems-ssh 10.1.1.3

対応表は接続先のパターン単位で持ち、個別の指定を優先します。案件が増えても、作業者の手元で設定が増えることはありません。~/.ssh/config を各人が育てる運用とも、ここで別れます。

多段SSHも、1コマンドです。踏み台を経由しないと届かない環境では、以前は ssh 10.1.1.2 で踏み台に入り、そこから ssh 10.1.2.3 と打つ2段階でした。いまは最終的な接続先を指定するだけで、踏み台の鍵も別に取得し、ProxyCommandで多段を組みます。

rhems-ssh 10.1.2.3

作業者が踏み台を意識する必要はありません。踏み台用の鍵もそのセッションのあいだだけ使い、記録には「どの踏み台を経由して、どこへ入ったか」が残ります。

取得した鍵は一時ファイルに書き出し、SSHの終了時に削除します。権限は0600です。作業者が鍵をコピーして持ち帰る経路を、手順として用意していない形になります。

減った作業と、増えた前提

この形にして減ったのは、鍵の配布・回収・ローテーション、~/.ssh/config の管理、案件ごとの接続手順書、退職時の鍵の棚卸しです。作業者から見ると、入社初日から同じコマンドで入れるようになりました。

一方で、前提は増えています。この基盤自体の運用（対応表の更新、APIの可用性、権限の棚卸し）と、ゼロトラスト基盤に入れられる端末であること。ここが止まれば、SSHも止まります。APIはEKS上で複数レプリカ動かし、手元の手順も残していますが、中心に置いた仕組みが落ちると作業が止まるという性質は引き受けています。

万能ではありません。ゼロトラスト基盤に入れた端末は、信頼の起点になります。その端末が乗っ取られれば、正規の手順で正規の操作ができてしまいます。だから端末の管理と多要素認証は、別に運用する必要があります。

鍵を持たないことは、鍵が漏れないことと同じではありません。サーバー側に置いた秘密鍵は、依然として守るべき対象です。Secrets Managerの権限設計と取得履歴が効いているかを、定期的に見続ける必要があります。

機器側の都合で鍵認証にできない対象、経路的に到達できない対象は、例外として残ります。例外をゼロにはできません。例外を一覧にして、期限を決めて見直すところまでを含めて運用だと考えています。

破れない手順と、残る記録

独自のコマンドにした一番の利点は、ログが揃うことです。接続の直前に、日時・利用者・接続先・実行したコマンドを送り、発行したIDを作業画面に表示します。多段のときも、記録するのは最終的な接続先です。

鍵の取得もAPI側に残ります。「鍵を取った記録」と「その鍵で入った記録」が同じ場所に集まるので、インシデントのときに「誰がいつどこへ入ったか」を、記憶ではなく記録から答えられます。

セキュリティと利便性は相反するとよく言われます。鍵を配らない、見せない、選ばせない。禁止事項を増やすのではなく手順から鍵を外した結果、作業はむしろ短くなりました。rhems-ssh <接続先> の1行です。

ルールは、破られても気づけないことがあります。手順は、破ろうとすると別の作業が必要になります。当社がやったのは、後者に寄せる作業でした。

鍵を持たせない。選ばせない。残さない。禁止ではなく、手順の側で成立させる。

RHEMS Japanが支援できること

当社は、この形を作った経験をもとに、鍵の管理と接続の運用を整理する支援をしています。鍵を置かない運用の設計、接続先と鍵の対応表の作り方、監査ログの残し方、そこへ移るまでの手順です。

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

参考

Yubico「Securing SSH with the YubiKey」— FIDO2・PIV・PGP・OTPの比較と導入手順

AWS「AWS Secrets Manager」— KMSによる暗号化、IAMによるアクセス制御、ローテーション、監査

OpenSSH 8.2 リリースノート — https://www.openssh.com/txt/release-8.2