記事

先週、あるDevOpsチームの話を聞いた。SSHクライアントを乗り換えたくても、稟議が通らない。理由は単純で、「認証情報とセッションログがどこのサーバーに保存されているか」を誰も即答できなかったからだ。 これはSaaS選定にありがちな盲点だ。UIやプラン価格は比較されるのに、インフラの物理的な所在地は後回しにされる。SSHのように鍵とパスワードそのものを扱うツールでは、この盲点がそのままセキュリティリスクになる。 技術的に見ると、問題は2つに分かれる。 1つ目は暗号化方式。保存時（at rest）と通信時（in transit）の両方でAES-GCMのような認証付き暗号を使っているか。多くのSSHクライアントは通信時の暗号化は標準対応でも、ローカルに保存する認証情報の暗号化が甘い。 2つ目はアクセス制御の粒度。チームで使う場合、「誰が」「どのサーバーに」「いつ」接続したかを役割ベースで制御できないと、退職者のアクセス権限が残り続けるといった事故につながる。 もう1つ、企業のセキュリティ担当者が必ず聞いてくる質問がある。「このツールの裏には、法的責任を負う会社があるのか」。オープンソースのコード単体は監査できても、サポートやセキュリティ更新の継続性を保証する主体がないと、稟議は止まる。 SecurSSHはRustで書いたクロスプラットフォームSSHクライアントで、上記の2点に対してAES-GCM暗号化とチームRBACを実装した。インフラはEU圏でホスティングし、GDPRに準拠している。運営主体も明確にしている。オープンソース的な透明性と、商用サポートの両立を狙った設計だ。 Freeプランで基本機能を試せる。SSH接続の管理で同じような壁にぶつかっている方がいたら、率直な感想を聞きたい。