チームでSSHキーを管理するためのベストプラクティスは何ですか？
私は以下の特徴を持つ開発者と管理者の小さなチーム（<10）と協力しています：
- チームのほとんどのメンバーは1台以上のパーソナルコンピューターを使用しており、そのほとんどはポータブルです
- チームメンバーは、通常Sudoを使用して10〜50台のサーバーにアクセスできます
これは、ほとんどの新興企業や中小規模の企業ITグループではかなり典型的だと思います。
このようなチームでSSHキーを管理するためのベストプラクティスは何ですか？
チーム全体で1つのキーを共有する必要がありますか？
各人が共有アカウント（すべてのサーバーで「ubuntu」）に独自のキーを持っている必要がありますか？
別のアカウント？
各チームメンバーは、ラップトップコンピューターまたはデスクトップコンピューターごとに個別のキーを保持する必要がありますか？
私の会社では、LDAPを使用してすべてのマシンに一貫したアカウントのセットを用意し、構成管理ツール（この場合は現在cfengine）を使用してauthorized_keysすべてのサーバーにわたる各ユーザーのファイル。キーファイル自体は（他のシステム構成情報とともに）gitリポジトリに保持されるため、キーの出入りを確認できます。 cfengineは、LDAPディレクトリのユーザーとグループを使用して、各ホストでrootとして何を実行するためのアクセス権を持つかを制御するsudoersファイルも配布します。
本番サーバーではパスワード認証が完全に無効になっているため、SSHキー認証が必須です。ポリシーでは、各ラップトップ/デスクトップ/何でも個別のキーを使用し、すべてのキーにパスフレーズを使用して、ノートパソコンの紛失/盗難の影響を減らすことを推奨しています。
また、本番ネットワークのホストにアクセスするために使用される要塞ホストもあり、そのネットワークの周りに非常に制限のあるファイアウォールルールを設定できます。ほとんどのエンジニアは、これを透過的にするためにいくつかの特別なSSH設定を持っています：
Host prod-*.example.com
User jsmith
ForwardAgent yes
ProxyCommand ssh -q bastion.example.com "nc %h %p"新しいキーを追加するか、古いキーを削除するには、このセットアップで少し儀式が必要です。新しいキーを追加するには、監査証跡を残してすべての人が見ることができる操作であることが望ましいと私は主張します。ただし、オーバーヘッドが含まれるため、古いキーが不要になったときに削除することを怠ることがあると思います。従業員が会社を辞めたときにクリーンアップする以外に、追跡するための実際の方法はありません。また、新しいエンジニアをオンボーディングするときに、新しいキーを生成し、完全に生産的になる前にすべてのホストにプッシュする必要があるため、さらに摩擦が生じます。
ただし、最大の利点は、ユーザーごとに個別のユーザー名を使用できることです。これにより、必要に応じてより詳細なアクセス制御を簡単に行うことができ、監査ログに表示されるIDが各ユーザーに提供されます。本番の問題はsysadminアクションに戻ります。
「既知の」SSHキーが代替アクセスパスとして機能できるため、このセットアップでは、本番ホストに対してアクションを実行する自動化システムを使用するのは面倒です。これまでのところ、これらの自動化システムのユーザーアカウントには、ジョブを実行するために必要な最小限のアクセスのみを与え、悪意のあるユーザー（実稼働用のアクセス権を持つエンジニアである必要があります）も同じアクションを半実行できることを受け入れましたアプリケーションのキーを匿名で使用します。
個人的には、スタッフの各メンバーが、基本的なユーザーアカウントを持つ専用のssh要塞マシンに1つのキーを持っているという考えが気に入っています。そのユーザーアカウントには、使用する必要があるすべてのサーバーへのアクセスを許可する1つのsshキーがあります。 （これらの他のサーバーもファイアウォールで保護する必要があるため、要塞マシンからのsshアクセスのみが有効になります）
次に、日常の作業機械、ラップトップ、タブレットなどで、1つのキーを使用するか、複数のキーを使用するかを自分で選択できます。
そのネットワークのシステム管理者は、管理するキーの最小数（開発者ごとに1つ）を持ち、ネットワークを介してsshアクセスを簡単に監視できます（すべてが要塞マシンを経由するため）。開発者が複数のキーを必要とする場合、または単に更新するマシンが1つしかないため、マシン間で共有している問題はありません。 （要塞のsshキーが危険にさらされない限り、utbbはユーザーのキーの1つよりもはるかに可能性が低いです）
40名の開発者のチームが最大120台のリモートカスタマーサーバーにSSHキーアクセスを提供する必要がある状況にありました。
開発者に単一の「ジャンプホスト」を介して接続するように強制することにより、アクセスを制御しました。そのホストから秘密/公開鍵を生成し、それらをお客様のサーバーにプッシュしました。開発者がラップトップからアクセスする必要がある場合、ローカルシステムで同じキーペアを使用できます。
私が聞いたが私自身は使用しなかった1つのアプローチは、各ユーザーがssh公開鍵設定とカスタマイズしたいドットファイル（.bashrc）を含むパッケージ（.deb、.rpmなど）を用意することです、.profile、.vimrcなど）。これは署名され、会社のリポジトリに保存されます。このパッケージは、ユーザーアカウントの作成を担当することも、アカウント（cfengine/puppetなど）またはLDAPのような中央認証システムの作成を補足することもできます。
これらのパッケージは、任意のメカニズム（cfengine/puppetなど、cronジョブ）を介してホストにインストールされます。 1つのアプローチは、ユーザーごとのパッケージに依存するメタパッケージを持つことです。
ユーザーではなく公開鍵を削除したい場合は、ユーザーごとのパッケージが更新されます。ユーザーを削除する場合は、パッケージを削除します。
異種システムがあり、.rpmファイルと.debファイルの両方を維持する必要がある場合、これは少し面倒ですが、alienのようなツールを使用すると多少簡単になる場合があります。
私が言うように、私はこれを自分でやったことはありません。このアプローチの私にとっての利点は、ユーザーが自分の.vimrcファイルを含めるようにパッケージを簡単に更新できるようになり、たとえば、そのファイルを管理する必要なく、中央LDAPシステムとユーザーアカウントの一元管理を補完することです。ユーザーがアクセスできないパペットなどのツール。
私は個人的にはユーザーごとに行くので、すぐに説明責任を持ち、制限をはるかに簡単に設定できます-他の人がどう思うかわかりませんか？
数年前、Envy Labsは、Keymaster（クライアントGatekeeperと提携）と呼ばれるツールを作成して、開発チーム向けにこのようなものを処理しました。
このプロジェクトはこの2年間あまり愛されていませんが、いじくり回して、おそらく生き返らせることができるものでしょうか。
リポジトリはgithubで利用できます： https://github.com/envylabs/keymaster
より安全な方法で、各ユーザーに、おそらくデバイスごとに個別のキーを強制する必要があります。
ユーザー間でキーを共有している場合（たとえ小さなチームであっても）、キーを取り消すことは他のすべての人にとって不便です。
スタッフがすべてのデバイスに対して1つのキーを持つことを許可すると、スタッフはそのデバイスに接続できるサーバーを選択できます。たとえば、モバイルラップトップは1つまたは2つのサーバーに制限できますが、オフィスのデスクトップはすべてのサーバーにアクセスできます。