ベストプラクティス：「ユーザーごとに1つのSSHキー」または「ホストごとに複数のSSHキー」
可能性のある重複：
キーペアを管理するための一般的な実用的な戦略は何ですか？
私は先週、sshキーへのどのアプローチがより「安全」であるかについての会話に参加しました。 「安全」を考えるとき、私たちは人間の行動（あらゆるセキュリティシステムの最も安全でない部分）を考慮に入れようとしたことに注意してください。
Ssh環境は主にUnix/Linuxマシンです（一部のPuTTYも）。 sshのユーザーは「人間のユーザー」と「自動化アカウント」であり、ファイルのコピーやリモートコマンドの実行にscp/sshを必要とするスケジュールされたタスク/スクリプトの実行に使用されます。
ユーザーのためのベストプラクティスを考え出すために、以下の推奨事項を検討しています。
「ユーザーごとに1つのsshキー」-ユーザーは単一のキーペアを生成し、ユーザーがログインを許可されているホスト上のユーザーのauthorized_keysファイルに公開キーをコピーする自動プロセスに公開キーを送信します。ユーザーは、sshクライアントとして使用するすべてのホストで同じパスフレーズで保護された秘密鍵を使用するように指示されます。このアプローチの結果、各ユーザーに対してone鍵ペアが1つ生成されます。
「複数の「クライアントごとのホスト」のsshキー」-ユーザーは、SSHクライアントごとにsshキーペアを生成する必要があります。ユーザーは公開鍵を自動化されたプロセスに送信し、自動化されたプロセスは、ユーザーがログインを許可されているホスト上のauthorized_keysファイルauthorized_keysファイルにキーをコピーします。このアプローチにより、「u x c」の鍵ペアが作成されます。ここで、「u」はユーザー数、「c」はクライアント数です。
私たちの議論では、各アプローチの利点と欠点に気づきました。例：「ユーザーごとに1つのsshキー」アプローチには、ユーザーの心に彼らの唯一のキーの重要性と、authorized_keyの監査でユーザーの1つのパブリックの存在を監査する機能の重要性を印象付けるという利点があります。ファイル。一方、「複数の「クライアント/ホストごと」のsshキー」アプローチには、authorized_keyファイルを監査して、ログインできるユーザーとクライアントマシンを特定できるという利点があります。これは、アクセスのタイプを理解するのに特に役立ちます。人間以外のアカウント（SSH/SCPを呼び出すスクリプトを実行）が持っています。
私はこのフォーラムで人々のためにうまくいったことを聞くことに非常に興味があります。前もって感謝します。
「ユーザーごとに1つのSSHキー」モデルを採用することをお勧めします。エンドユーザーにとって使いやすく、ユーザーに対して簡単に説明でき、セキュリティ要件を満たす可能性があります。
使いやすさが非常に重要です。セキュリティメカニズムを使用するのが難しい場合、人々はあなたのセキュリティメカニズムを回避する方法を見つけるでしょう。使いやすく、非常に優れたセキュリティメカニズムは、理論的には非常に安全な、使いにくいセキュリティメカニズムよりもはるかに優れています（実際には、使用するのが難しい場合は、おそらく安全ではありません。セキュリティメカニズムを回避して作業を完了させる方法を見つけたら、期待してください）。
「ユーザーごとにクライアントマシン用に1つのsshキーを使用する」ことは悪い考えだと思います。混乱のように聞こえます。率直に言って、それは、セキュリティに悪名を与え、人々がIT部門を憎むような方法で、ITが混乱しているように聞こえます。クライアントごとに個別のSSHキーを生成し、それらすべてを管理する必要があるということですか？明確ではない不定形のセキュリティの利点のすべて？うわっ！これをユーザーに販売するのは私が嫌いです。
このような決定は、「コンプライアンス予算」の観点から考えることをお勧めします。あなたの従業員は、彼らに課されたある量の迷惑なコンプライアンス義務（例えば、セキュリティ要件）に我慢します。ある程度まで、彼らはこれらの義務に従います。しかし、それが多すぎると、最終的には煩わしくなり、すべてのセキュリティ原則に違反していても、仕事を終わらせるために必要なことは何でもします。したがって、要求が多すぎたり、不便が多すぎたりすると、セキュリティの面で逆効果になる可能性があります。したがって、セキュリティ要件やセキュリティ関連の不便をユーザーに課す前に、十分に検討してください。委任を課すための予算が非常に限られていると想像してください。これは、限られた「コンプライアンス予算」を費やすのに最適なアイテムですか？
関連する注意点として、「ユーザーごとにクライアントマシンに1つのSSHキーを使用する」ことのメリットはかなり小さいと思います。デスクトップと比較して、ラップトップでログインできるアカウントをだれもそんなに気にする必要がある理由がわかりません。これは単なるマイクロマネージメントですか？誰も気にしない？どちらにせよ、私です。あなたが私を信頼しているなら、私が使用している私のマシンがどれであっても、あなたは私を信頼しますねこれが非常に大きな問題であり、それが原因でユーザーの生活がより困難になることは明らかではありません。
追伸あなたは人間以外の人が持つ特権の管理について何か述べています。私はそれが言及していることを完全には理解していませんでした。 SSH/SCPを呼び出すスクリプトについて言及しましたが、それらのスクリプトを呼び出すのは誰ですか？それが人であれば、おそらくその人が活動を承認しているでしょうね？それが人によって呼び出されない場合、それがどのように機能するかさえはっきりしていません（私の経験では、そのようなスクリプトはSSH秘密鍵にアクセスできません。なぜなら、彼らはあなたのパスフレーズを知らず、 SSH秘密鍵へのアクセスを可能にするすべてのssh-agentセッションに添付されます）。その発言で重要な何かが欠けているかどうかはわかりません。
多対多のアプローチでのユーザーエクスペリエンスは受け入れられるものだとは考えにくいです。どのpub/priv鍵ペアがどのシステムに対応しているかを覚えようとすることをめぐる混乱は、非常に煩雑に思えます。
1対多のキーアプローチの精神は、管理とユーザーエクスペリエンスの面で最も優れているようです。ユーザーとシステムの数が非常に少ない場合、管理作業はすぐに難しくなると思います。あなたは一元化されたアクセス管理ソリューションに向かっているので、どうして最後まで行かないのですか？ LDAPサーバーをセットアップし（AD/OpenLDAP/ このスレッドにはいくつかのアイデアがあります ）、ユーザーの役割を定義し、それらの役割に必要なサーバー/システムへのアクセス権を付与し、必要に応じてユーザーに役割を割り当てます。これにより、簡単な役割の変更で多くのシステムへのアクセスをプロビジョニング/プロビジョニング解除し、すべての監査ログを中央の場所に保管できます。
組織が数と複雑さを増すにつれて、ソリューションのスケーラビリティと実用性について真剣に考える価値のある素晴らしい質問です。