SSHキーと証明書をチームと安全に共有する方法

「SSHキー、Slackで送って」—— 開発チームでよく聞く一言です。サーバーアクセスが急ぎで、新しいチームメンバーが環境構築を必要としていて、デプロイが目前なのにキーがない。

しかし、この一言が深刻なセキュリティインシデントの始まりになりかねません。

SSHキー共有が特に危険な理由

SSHキーは通常のパスワードとは異なります。サーバーへの完全なアクセス権を付与します。

比較項目	パスワード	SSHキー
権限範囲	特定のアカウント	サーバー全体
漏洩時の影響	そのアカウント	サーバー上の全データ
変更の容易さ	即座に変更可能	キー再生成+全サーバー更新が必要
二要素認証	対応可能	キー自体が認証

SSHキーが漏洩すると、サーバー上のすべてのファイル、データベース、コードにアクセスできます。パスワード漏洩とは次元の異なる問題です。

チームでSSHキーを共有すべき場面

現実的に共有が必要な場面は確かに存在します。

• 共有サーバーアクセス：チーム全員がアクセスするステージング/本番サーバー
• デプロイキー：CI/CDパイプラインで使用するキー
• SSL証明書：担当者変更時の証明書更新
• APIシークレット：サードパーティサービス連携の認証情報
• データベース接続情報：緊急障害対応時

危険な共有方法

1. Slack/Discord DM

チャット履歴はサーバーに永久保存されます。誰でも「ssh」「key」で検索すれば過去に共有されたキーを見つけられます。

2. メール

メールサーバーに永久保管され、転送一つで制御不能になります。

3. 共有Google Drive/Notion

細かいアクセス制御が難しく、同期によりローカルにコピーが残ります。

4. Gitリポジトリにコミット

最も危険な方法です。Git履歴に永久に残り、ファイルを削除しても履歴から復元できます。

安全な共有方法

方法1：LOCK.PUBシークレットメモ（一回限りの転送に最適）

1. LOCK.PUBでシークレットメモを作成
2. SSHキーまたは証明書の内容を貼り付け
3. 強力なパスワードを設定
4. 有効期限を最短に設定（1〜4時間）
5. リンクをSlackで、パスワードを電話で伝達
6. 受信者がキーをローカルに保存後、リンクは期限切れに

メリット：

• どのサーバーにもキーが平文で保存されない
• 期限切れ後はアクセス不可
• チャット履歴にキーの原文が残らない

方法2：シークレットマネージャー（大規模チーム向け）

HashiCorp Vault、AWS Secrets Manager、Google Secret Managerなど専門ツールを使用。

方法3：SSH認証局（長期的解決策）

共有キーの代わりにSSH CA（認証局）を運用し、各ユーザーに個別証明書を発行。

方法4：ユーザー別キー発行（最も推奨）

原則：共有キー < 個人別キー
共有キー漏洩 → チーム全体に影響
個人キー漏洩 → 該当ユーザーのみに影響

共有が避けられない場合のチェックリスト

転送前

• キーの権限範囲を最小限に設定したか？
• 読み取り専用キーで十分ではないか？
• IP制限を適用できるか？

転送時

• キーとパスワードを別のチャネルで送っているか？
• 有効期限を可能な限り短く設定したか？

転送後

• 受信者がキーを安全に保存したか確認
• 共有リンク/メモが期限切れになったか確認
• キー使用ログを監視

キーローテーションスケジュール

キータイプ	推奨ローテーション周期
本番サーバーキー	90日
デプロイキー	90日
SSL証明書	更新のたび
APIシークレット	90日
開発/ステージングキー	180日

DevOpsチームのセキュリティチェックリスト

• すべてのサーバーに個人別SSHキーを使用しているか？
• 共有キーがある場合、IP制限が設定されているか？
• 退職者のキーは即座に無効化されているか？
• キーローテーションスケジュールが確立されているか？
• SSHキーがGitリポジトリにコミットされたことがないか？
• チャット履歴にキーが平文で残っていないか？
• 秘密情報の転送に有効期限付きチャネルを使用しているか？

まとめ

SSHキーと証明書はサーバーセキュリティの要です。Slack DMやメールで送るのは、家の鍵を掲示板に貼り付けるようなものです。可能な限り個人別キーを発行し、共有が避けられない場合は最短の有効期限を設定したシークレットメモを活用しましょう。

今すぐシークレットメモを作成して、SSHキーを安全に転送しましょう。

シークレットメモを作成する