Apa praktik terbaik untuk mengelola kunci SSH dalam tim?

Saya bekerja dengan tim kecil (<10) pengembang dan admin dengan karakteristik berikut:

• Sebagian besar anggota tim memiliki> 1 komputer pribadi, yang sebagian besar portabel
• Anggota tim memiliki akses ke 10-50 server, biasanya dengan sudo

Saya pikir ini cukup khas untuk kebanyakan startup dan kelompok IT perusahaan skala kecil hingga menengah.

Apa praktik terbaik untuk mengelola kunci SSH dalam tim seperti ini?

Haruskah Anda membagikan satu kunci untuk seluruh tim?

Haruskah setiap orang memiliki kunci sendiri di akun bersama ("ubuntu" di setiap server)?

Pisahkan akun?

Haruskah setiap anggota tim menyimpan kunci terpisah untuk masing-masing laptop atau komputer desktop mereka?

Di perusahaan saya, kami menggunakan LDAP untuk memiliki set akun yang konsisten di semua mesin dan kemudian menggunakan alat manajemen konfigurasi (dalam kasus kami saat ini adalah cfengine) untuk mendistribusikan authorized_keysfile untuk setiap pengguna di semua server. File-file kunci sendiri disimpan (bersama dengan informasi konfigurasi sistem lainnya) dalam repositori git sehingga kita dapat melihat kapan kunci datang dan pergi. cfengine juga mendistribusikan sudoersfile yang mengontrol siapa yang memiliki akses untuk menjalankan apa sebagai root pada setiap host, menggunakan pengguna dan grup dari direktori LDAP.

Otentikasi kata sandi sepenuhnya dinonaktifkan pada server produksi kami, jadi kunci kunci SSH adalah wajib. Kebijakan mendorong penggunaan kunci terpisah untuk setiap laptop / desktop / apa pun dan menggunakan frasa sandi pada semua tombol untuk mengurangi dampak laptop yang hilang / dicuri.

Kami juga memiliki host benteng yang digunakan untuk mengakses host di jaringan produksi, memungkinkan kami untuk memiliki aturan firewall yang sangat ketat di sekitar jaringan itu. Sebagian besar insinyur memiliki beberapa konfigurasi SSH khusus untuk menjadikan ini transparan:

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

Menambahkan kunci baru atau menghapus yang lama membutuhkan sedikit upacara dalam pengaturan ini. Saya berpendapat bahwa untuk menambahkan kunci baru itu diinginkan untuk menjadi operasi yang meninggalkan jejak audit dan terlihat oleh semua orang. Namun, karena overhead yang terlibat, saya pikir orang kadang-kadang lalai untuk menghapus kunci lama ketika tidak lagi diperlukan dan kami tidak memiliki cara nyata untuk melacak itu kecuali untuk membersihkan ketika seorang karyawan meninggalkan perusahaan. Ini juga menciptakan beberapa gesekan tambahan ketika menaiki insinyur baru, karena mereka perlu menghasilkan kunci baru dan mendorongnya ke semua host sebelum mereka benar-benar produktif.

Namun manfaat terbesar adalah memiliki nama pengguna yang terpisah untuk setiap pengguna, yang membuatnya lebih mudah untuk melakukan kontrol akses lebih rinci ketika kita membutuhkannya dan memberikan setiap pengguna sebuah identitas yang muncul di log audit, yang dapat sangat berguna ketika mencoba melacak suatu masalah produksi kembali ke tindakan sysadmin.

Dalam pengaturan ini merepotkan untuk memiliki sistem otomatis yang mengambil tindakan terhadap host produksi, karena kunci SSH "terkenal" mereka dapat berfungsi sebagai jalur akses alternatif. Sejauh ini kami baru saja membuat akun pengguna untuk sistem otomatis ini hanya memiliki akses minimal yang mereka butuhkan untuk melakukan pekerjaan mereka dan menerima bahwa pengguna jahat (yang harus sudah menjadi insinyur dengan akses produksi) juga dapat melakukan tindakan yang sama secara semi- menggunakan kunci aplikasi secara anonim.

Secara pribadi saya suka ide setiap anggota staf memiliki satu kunci pada mesin benteng ssh khusus di mana mereka memiliki akun pengguna dasar. Akun pengguna itu memiliki kunci 1 ssh yang memberikan akses ke semua server yang mereka butuhkan. (server lain ini juga harus di-firewalled sehingga hanya akses ssh dari mesin benteng yang diaktifkan)

Kemudian pada mesin kerja sehari-hari, laptop, tablet dll mereka dapat membuat pilihan mereka sendiri untuk memiliki satu kunci di antara mereka atau beberapa tombol.

Sebagai admin sistem pada jaringan itu, Anda memiliki jumlah kunci minimum untuk dijaga (satu per dev), dapat dengan mudah memonitor akses ssh melalui jaringan (karena semuanya merutekan melalui mesin benteng) dan jika dev menginginkan beberapa kunci atau hanya yang mereka bagikan di antara mesin-mesin mereka bukan masalah karena Anda hanya memiliki satu mesin untuk diperbarui. (kecuali kunci bastions ssh dikompromikan, ut tbh yang jauh lebih tidak mungkin daripada salah satu kunci pengguna)

Saya telah memiliki situasi di mana saya harus menyediakan akses kunci SSH untuk tim yang terdiri dari 40 pengembang untuk ~ 120 server pelanggan jarak jauh.

Saya mengontrol akses dengan memaksa para pengembang untuk terhubung melalui satu "host melompat". Dari host itu, saya membuat kunci privat / publik dan mendorongnya ke server pelanggan. Jika pengembang membutuhkan akses dari laptop, mereka dapat menggunakan keypair yang sama pada sistem lokal mereka.

Saya pribadi akan menggunakan per pengguna maka Anda langsung memiliki akuntabilitas dan menetapkan batasan jauh lebih mudah - Saya tidak tahu apa yang dipikirkan orang lain?

Salah satu pendekatan yang pernah saya dengar, tetapi tidak digunakan sendiri, adalah agar setiap pengguna memiliki paket (misalnya, .deb, .rpm) yang berisi konfigurasi kunci publik ssh mereka, serta setiap dotfile yang ingin mereka sesuaikan (.bashrc , .profile, .vimrc dll). Ini ditandatangani dan disimpan dalam repositori perusahaan. Paket ini juga dapat bertanggung jawab untuk membuat akun pengguna, atau dapat melengkapi sesuatu yang lain untuk membuat akun (cfengine / puppet dll) atau sistem autentikasi pusat seperti LDAP.

Paket-paket ini kemudian diinstal ke host melalui mekanisme apa pun yang Anda inginkan (cfengine / puppet etc, cron job). Salah satu pendekatan adalah memiliki metapackage yang memiliki ketergantungan pada paket per pengguna.

Jika Anda ingin menghapus kunci publik, tetapi bukan pengguna, maka paket per-pengguna diperbarui. Jika Anda ingin menghapus pengguna, Anda menghapus paket.

Jika Anda memiliki sistem yang heterogen dan harus mempertahankan file .rpm dan .deb, maka saya bisa melihat ini sedikit mengganggu, meskipun alat seperti alien mungkin membuat itu lebih mudah.

Seperti yang saya katakan, saya tidak melakukan ini sendiri. Manfaat dalam pendekatan ini bagi saya adalah bahwa ia melengkapi sistem LDAP pusat dan manajemen pusat akun pengguna, karena memungkinkan pengguna untuk dengan mudah memperbarui paketnya untuk menyertakan file .vimrc-nya, misalnya, tanpa harus memiliki file yang dikelola oleh alat-alat seperti boneka, yang mungkin tidak dapat diakses oleh pengguna.

Anda harus mengambil rute yang lebih aman, dan memaksa setiap pengguna untuk memiliki kunci yang terpisah, dan mungkin untuk setiap perangkat.

Jika Anda memiliki kunci yang dibagikan di antara pengguna --- bahkan jika Anda adalah tim kecil --- mencabut kunci adalah ketidaknyamanan bagi orang lain.

Jika Anda mengizinkan staf Anda untuk memiliki satu kunci untuk semua perangkat mereka, maka mereka dapat memilih dan memilih server mana yang dapat mereka hubungkan dengan perangkat itu. Misalnya, laptop seluler dapat dibatasi untuk satu atau dua server, tetapi desktop di kantor dapat memiliki akses ke semua server.

Beberapa tahun yang lalu Envy Labs menulis alat yang disebut Keymaster (bermitra dengan klien Gatekeeper) untuk menangani sesuatu seperti ini untuk tim pengembangan.

Proyek ini tidak memiliki banyak cinta selama dua tahun terakhir, tetapi kemungkinan sesuatu yang Anda dapat mengotak-atik, dan mungkin menghidupkan kembali?

Repo tersedia di github: https://github.com/envylabs/keymaster

Suatu pendekatan dapat mengatur server NIS dengan / home share melalui NFS. Yang dikombinasikan dengan sudo di server dan memungkinkan hanya pengguna yang Anda inginkan untuk setiap server melalui konfigurasi ssh.

Dengan begitu Anda setiap anggota tim hanya menggunakan satu pengguna dan kuncinya untuk mengakses semua server. Sudo dan satu kata sandi untuk tugas admin.

Salam,

Rafael