チームでSSHキーを管理するためのベストプラクティスは何ですか？

私は、次の特徴を持つ開発者と管理者の小さなチーム（<10）で働いています。

• チームのほとんどのメンバーは1台以上のパーソナルコンピューターを持ち、そのほとんどはポータブルです。
• チームメンバーは、通常sudoを使用して10〜50台のサーバーにアクセスできます。

これは、ほとんどのスタートアップや中小規模の企業ITグループにとって非常に典型的なことだと思います。

このようなチームでSSHキーを管理するためのベストプラクティスは何ですか？

チーム全体で単一のキーを共有する必要がありますか？

各人が共有アカウント（各サーバーの「ubuntu」）に独自のキーを持っている必要がありますか？

個別のアカウント？

各チームメンバーは、ラップトップまたはデスクトップコンピューターごとに個別のキーを保持する必要がありますか？

私の会社では、LDAPを使用してすべてのマシンに一貫したアカウントのセットを作成し、構成管理ツール（この場合は現在cfengine）をauthorized_keys使用して、すべてのサーバーに各ユーザーのファイルを配布しています。キーファイル自体は（他のシステム構成情報とともに）gitリポジトリに保持されるため、キーがいつ出入りするかを確認できます。cfengine sudoersは、LDAPディレクトリのユーザーとグループを使用して、各ホストでrootとして何を実行するアクセス権を持つユーザーを制御するファイルも配布します。

本番サーバーではパスワード認証が完全に無効になっているため、SSHキー認証は必須です。ポリシーでは、ラップトップ/デスクトップ/その他に個別のキーを使用し、すべてのキーにパスフレーズを使用して、ラップトップの紛失/盗難の影響を軽減することを推奨しています。

また、実稼働ネットワーク上のホストにアクセスするために使用される要塞ホストがあり、そのネットワークの周りに非常に制限的なファイアウォールルールを設定できます。ほとんどのエンジニアには、これを透過的にするための特別なSSH設定があります。

Host prod-*.example.com
     User jsmith
     ForwardAgent yes
     ProxyCommand ssh -q bastion.example.com "nc %h %p"

このセットアップでは、新しいキーを追加したり古いキーを削除したりするのに多少の儀式が必要です。新しいキーを追加するには、それが監査証跡を残し、すべての人に見える操作であることが望ましいと主張します。ただし、オーバーヘッドが関係するため、古いキーが不要になった場合、人々は時々古いキーを削除することを怠り、従業員が会社を辞めたときをクリーンアップする以外、それを追跡する実際の方法はないと思います。また、完全に生産的になる前に新しいキーを生成し、それをすべてのホストにプッシュする必要があるため、新しいエンジニアをオンボーディングするときに追加の摩擦が発生します。

ただし、最大の利点は、ユーザーごとに個別のユーザー名を持つことです。これにより、必要に応じてよりきめ細かなアクセス制御を簡単に実行でき、監査ログに表示されるIDを各ユーザーに付与できます。 sysadminアクションに戻る運用上の問題。

このセットアップでは、「既知の」S​​SHキーが代替アクセスパスとして機能する可能性があるため、実稼働ホストに対してアクションを実行する自動システムを持つのは面倒です。これまでのところ、これらの自動システムのユーザーアカウントに、ジョブを実行するために必要な最小限のアクセスのみを許可し、悪意のあるユーザー（既に実稼働アクセスを持つエンジニアである必要があります）が同じアクションを実行できることを受け入れました。アプリケーションのキーを匿名で使用します。

個人的には、スタッフの各メンバーが基本的なユーザーアカウントを持っている専用のssh要塞マシンに1つのキーを持つというアイデアが好きです。そのユーザーアカウントには、使用する必要があるすべてのサーバーへのアクセスを許可する1つのsshキーがあります。（これらの他のサーバーもファイアウォールで保護する必要があるため、要塞マシンからのsshアクセスのみが有効になります。）

その後、日常の作業用のマシン、ラップトップ、タブレットなどで、1つのキーを複数のキーの間に持つかどうかを自分で選択できます。

そのネットワークのシステム管理者として、最低限のキー（devごとに1つ）があり、ネットワークを介したsshアクセス（要塞マシンを通るすべてのルート）とdevが複数のキーを必要とするか、または単にマシン間で共有しているものは、更新するマシンが1台しかないため、実際の問題ではありません。（bastions sshキーが危険にさらされない限り、ユーザーキーの1つよりもはるかに低いtbh）

40人の開発者から成るチームが120台までのリモートカスタマーサーバーにSSHキーアクセスを提供する必要がある状況がありました。

開発者が単一の「ジャンプホスト」を介して接続するように強制することで、アクセスを制御しました。そのホストから、秘密/公開キーを生成し、顧客サーバーにプッシュしました。開発者がラップトップからアクセスする必要がある場合は、ローカルシステムで同じキーペアを使用できます。

私は個人的にユーザーごとに行くとすぐに説明責任があり、制限をはるかに簡単に設定できます-他の人がどう思うかわかりませんか？

私が聞いたことがありますが、自分では使用しませんでしたが、各ユーザーがssh公開鍵設定とカスタマイズしたいドットファイル（.bashrc）を含むパッケージ（.deb、.rpmなど）を持つことです、.profile、.vimrcなど）。これは署名され、会社のリポジトリに保存されます。このパッケージは、ユーザーアカウントの作成を担当することも、アカウント（cfengine / puppetなど）またはLDAPなどの中央認証システムを作成する他の何かを補完することもできます。

これらのパッケージは、任意のメカニズム（cfengine / puppetなど、cronジョブ）を介してホストにインストールされます。1つのアプローチは、ユーザーごとのパッケージに依存するメタパッケージを持つことです。

ユーザーではなく公開キーを削除する場合は、ユーザーごとのパッケージが更新されます。ユーザーを削除する場合は、パッケージを削除します。

異種システムがあり、.rpmファイルと.debファイルの両方を維持する必要がある場合、エイリアンのようなツールがそれをいくらか簡単にするかもしれませんが、これは少し面倒です。

私が言うように、私はこれを自分でやったことがありません。このアプローチの利点は、中央のLDAPシステムとユーザーアカウントの中央管理を補完することです。ユーザーがパッケージを簡単に更新して、たとえば、そのファイルを管理せずに.vimrcファイルを含めることができます。ユーザーがアクセスできない可能性のあるパペットなどのツールによって。

より安全なルートを取り、各ユーザーに、おそらくデバイスごとに別々のキーを持たせる必要があります。

ユーザー間でキーを共有している場合-たとえ小さなチームであっても-キーを取り消すことは他のすべてのユーザーにとって不便です。

スタッフがすべてのデバイスに対して1つのキーを持つことを許可すると、そのデバイスで接続できるサーバーを選択できます。たとえば、モバイルラップトップは1台または2台のサーバーに制限できますが、オフィスのデスクトップはすべてのサーバーにアクセスできます。

数年前、Envy Labsは、開発チーム向けにこのような処理を行うKeymaster（クライアントGatekeeperと提携）と呼ばれるツールを作成しました。

このプロジェクトは過去2年間あまり愛されていませんでしたが、いじくり回すことができ、おそらく生き返らせることができるでしょうか？

リポジトリはgithubで入手できます：https : //github.com/envylabs/keymaster

アプローチは、NFS経由で/ home共有を使用してNISサーバーをセットアップすることです。これはサーバーのsudoと組み合わされ、ssh構成を介して各サーバーに必要なユーザーのみを許可します。

そうすれば、チームのすべてのメンバーが1人のユーザーとそのキーを使用してすべてのサーバーにアクセスできます。管理タスク用のsudoと1つのパスワード。

よろしく、

ラファエル