it-swarm-id.com

Apa strategi pragmatis umum untuk mengelola pasangan kunci?

Saya memiliki sejumlah kecil workstation yang berbeda (ditambah perangkat klien seperti iPhone) yang saya gunakan untuk menghubungkan ke berbagai server menggunakan SSH.

Awalnya ketika saya belajar tentang PKI, saya membuat sepasang kunci tunggal di workstation saya, yang segera saya mulai gunakan dari mana-mana (artinya saya menyalinnya ke laptop saya, dll), dan menggunakannya untuk menghubungkan ke semua akun server saya.

Sejak itu, saya mengembangkan pendapat bahwa ini mirip dengan menggunakan kata sandi tunggal di mana-mana, dan saya mungkin perlu mencabut akses secara selektif, mis. jika salah satu workstation saya terganggu.

Pada dasarnya saya mencoba mengembangkan strategi pribadi untuk berurusan dengan pasangan kunci:

Apa cara yang tepat untuk berpikir tentang pasangan kunci secara aman untuk penggunaan umum, sementara tetap pragmatis untuk kegunaan? (mis. Saya pikir pasangan kunci sekali pakai untuk setiap titik koneksi juga tidak masuk akal.)

Apakah salah bagi pasangan kunci untuk mewakili identitas pribadi secara global dari semua titik akses ("me-everywhere-id_rsa") seperti yang saya lakukan di masa lalu, atau apakah pemikiran saya saat ini bahwa kombinasi pengguna-pengguna yang unik harus selalu diwakili oleh kunci sendiri ("me-on-my-personal-laptop-id_rsa") lebih tepat?

Apakah Anda menggunakan kembali kunci yang sama untuk menghubungkan ke semua server, atau dalam kondisi apa Anda mempertimbangkan mencetak kunci yang terpisah?

48
Andrew Vit

Saya suka memiliki satu kunci per bidang otentikasi. Jadi, untuk setiap mesin desktop atau server di tempat kerja (semua secara fisik aman dan di bawah kendali satu kelompok administrator), saya punya satu kunci pribadi. Saya menggunakan kunci pribadi yang sama pada PC rumah baru saya dengan PC rumah lama saya. Saya menggunakan tombol yang berbeda pada laptop dan perangkat seluler lainnya. Pendekatan ini memungkinkan manajemen risiko berbutir halus: Saya dapat mencabut kunci secara terpisah, dan membatasi kemungkinan akun saya untuk terlibat dalam infiltrasi yang meningkat dengan tidak mengotorisasi kunci tertentu pada mesin tertentu (saya tidak melakukan itu banyak, tapi itu pilihan. untuk paranoid).

Selama Anda tidak melakukan sesuatu yang rumit, menyalin kunci publik tidak terlalu sulit. Anda dapat menyimpan satu daftar besar kunci resmi dan menyinkronkannya di mana-mana; mendaftarkan perangkat berarti menambahkan satu item ke daftar itu dan mendorong perubahan. Ini bukan pekerjaan yang lebih daripada menarik kunci pribadi, jika Anda memiliki repositori data sentral di tempat pertama.

Perhatikan bahwa meskipun keuntungan yang paling jelas dari memiliki kunci privat yang terpisah adalah dapat mencabutnya secara terpisah, mereka juga memiliki manfaat ketersediaan: jika administrator sistem pada mesin A memutuskan untuk mencabut kunci dari mesin C yang sedang Anda gunakan, Anda mungkin masih dapat menemukan beberapa mesin B yang masih menerima kunci C dan yang kuncinya diterima oleh A. Ini sepertinya agak esoteris, tetapi ini terjadi sekali pada saya (setelah Debian menyadari mereka tidak menabur RNG mereka , saya senang tidak harus hanya bergantung pada kunci daftar hitam) sedangkan saya belum harus mencabut kunci dalam keadaan darurat.

Bahkan ada manfaat teoretis dalam menjaga pasangan kunci terpisah per pasangan mesin, karena memungkinkan pencabutan terpisah. Tetapi manfaatnya sangat kecil, dan manajemennya jauh lebih sulit (Anda tidak bisa lagi menyiarkan daftar otorisasi). Penyederhanaan manajemen kunci adalah keuntungan penting kriptografi kunci publik daripada rahasia bersama.

Anda sudah melihat poin utama: jika salah satu mesin Anda dikompromikan, kunci pribadi yang terkandung di mesin ini harus "dicabut": Anda harus mengonfigurasi semua server tempat Anda terhubung untuk menolak upaya otentikasi lebih lanjut menggunakan kunci itu (yaitu Anda menghapus kunci publik yang sesuai dari .ssh/authorized_keys dari server). Ada teknik mitigasi, yang terdiri dari pengamanan kunci pribadi dengan kata sandi (atau frasa sandi). Ini ada harganya, yaitu Anda harus mengetikkan kata sandi ( ssh-agent bisa sangat berguna untuk itu); di sisi lain, ini untuk sementara waktu dapat mencegah penyerang mendapatkan kunci privat (ini tergantung pada jenis kompromi, tetapi jika itu adalah pencurian mesin lengkap - skenario yang masuk akal dengan perangkat seluler - maka kata sandi akan mencegah akses langsung ke kunci pribadi dan memberi Anda waktu untuk mengkonfigurasi ulang server).


Orang mungkin mencatat bahwa "PKI" berarti "Kunci Publik Infrastruktur " dan SSH belum sempurna dalam hal itu. Dalam PKI lengkap, sertifikat akan digunakan, dengan delegasi, dan sentralisasi pencabutan. Dengan sertifikat:

  • anda akan membuat satu pasangan kunci CA, disimpan dengan aman di suatu tempat;
  • untuk setiap mesin klien, Anda akan mendapatkan pasangan kunci baru, kunci publik sedang ditandatangani oleh CA;
  • server akan dikonfigurasikan untuk secara otomatis menerima sembarang kunci publik yang ditandatangani oleh CA (mereka akan mengetahui kunci publik CA, tetapi bukan kunci mesin klien individu);
  • cA akan memelihara dan secara teratur menerbitkan informasi pencabutan, yaitu daftar kunci publik yang tidak boleh lagi diterima walaupun kunci-kunci ini ditandatangani oleh CA (informasi pencabutan harus didorong ke server, atau menarik permintaan).

Hal yang hebat tentang sertifikat adalah bahwa Anda memusatkan keputusan, yang, secara praktis, berarti bahwa jika Anda terhubung ke 20 server dari mesin klien Anda, dan kemudian menambahkan mesin klien baru, Anda tidak perlu secara manual mendorong kunci publik baru ke semua 20 server.

OpenSSH , sejak versi 5.4 (dirilis 8 Maret 2010), memiliki beberapa dukungan untuk sertifikat; lihat bagian eponymous di halaman manual untuk ssh-keygen . Sertifikat OpenSSH memiliki format yang jauh lebih sederhana daripada sertifikat "biasa" X.509 (seperti yang digunakan dengan SSL). Penyederhanaan juga memiliki harga: tidak ada dukungan pencabutan terpusat. Sebaliknya, jika kunci pribadi dikompromikan, Anda masih harus memasukkan daftar hitam kunci publik yang sesuai pada semua server, dan daftar hitam itu, di OpenSSH, daftar putih (opsi AuthorizedPrincipalsFile dalam sshd_config) yang, biasanya, di bawah kendali root. Jadi pencabutan tidak berfungsi dengan baik dan Anda masih harus mengkonfigurasi hal-hal di setiap server secara manual setiap kali Anda membuat atau kehilangan kunci, ketidaknyamanan yang seharusnya dihapuskan oleh PKI.

Anda dapat masih membuat kunci terbatas waktu, karena sertifikat OpenSSH dapat menyematkan kunci terbatas waktu. Dalam hal ini, Anda akan memberikan kepada masing-masing mesin klien kunci yang baik untuk, katakanlah, satu minggu. Dengan kunci yang mati setelah seminggu, dan kunci publik CA diketahui oleh server, Anda memiliki kebaikan CA utama (tidak perlu Push apa pun di semua server ketika mesin baru ditambahkan ke kumpulan klien), dan jika pribadi dikompromikan, kerusakannya "terbatas", dengan anggapan Anda memiliki kata sandi kunci yang, mungkin, akan tahan selama satu minggu dari pemecahan (tetapi ini tidak akan berhasil jika kompromi tersebut merupakan pengambilalihan yang bermusuhan dengan pencatat kunci). Kunci waktu terbatas dapat menjadi membosankan dari waktu ke waktu, dan mereka menganggap bahwa semua server memiliki jam yang diatur dengan benar, yang tidak selalu diberikan (akan sangat disayangkan untuk dikunci dari server karena jam server tidak aktif, dan mengatur ulang jam membutuhkan akses SSH ke server ...).

Masalah tambahan dengan SSH adalah bahwa mudah untuk menambahkan kunci publik di setiap server. Ini berarti bahwa jika seorang penyerang kompromi kunci pribadi dan mendapatkan akses ke server sekali , ia dapat menambahkan kunci publiknya sendiri ke .ssh/authorized_keys di server itu, dan tidak ada jumlah pencabutan yang akan memperbaikinya. Pencabutan, pada dasarnya, adalah proses yang tidak sinkron. Oleh karena itu, ia tidak menerapkan kontrol kerusakan yang cukup ketat.


Mengingat kekurangan dukungan SSH untuk sertifikat, tidak ada skema yang masuk akal yang menghindari keharusan melakukan konfigurasi pada semua server dalam beberapa situasi. Jadi pada dasarnya Anda memiliki pilihan berikut, ketika Anda menambahkan mesin klien baru:

  1. Anda menyalin kunci pribadi dari mesin klien lain (itulah yang Anda lakukan sekarang). Ini tidak memerlukan konfigurasi tambahan di server.

  2. Anda membuat pasangan kunci baru untuk mesin itu. Anda harus Menekan kunci publik ke semua server.

Saat terjadi kompromi kunci, Anda harus terhubung ke semua server untuk menghapus kunci publik yang sesuai dari semua .ssh/authorized_keys. Ini tidak dapat dihindari (untuk menghindarinya, Anda harus menggunakan sertifikat, dan SSH tidak pandai sertifikat, lihat di atas). Kemudian, jika Anda menggunakan pilihan 1, maka Anda harus juga membuat pasangan kunci baru dan Tekan untuk semua mesin klien yang menggunakan salinan kunci pribadi yang disusupi.

Oleh karena itu, pilihan 1 memerlukan kerja konfigurasi yang lebih sedikit daripada pilihan 2 dalam kasus normal, tetapi hal-hal dibalik jika terjadi kompromi kunci. Karena kompromi biasanya merupakan peristiwa yang jarang, ini akan menguntungkan pilihan 1 (yang sudah Anda lakukan). Jadi saya sarankan Anda melindungi kunci pribadi Anda dengan kata sandi yang kuat, dan menyalinnya ke semua sistem klien Anda.

Catatan: di semua hal di atas, saya berasumsi bahwa Anda ingin terhubung ke daftar server dengan SSH, dan Anda ingin mengakses salah satu server dari salah satu mesin klien Anda. Anda mungkin ingin membatasi akses, seperti mengakses server yang diberikan hanya dari satu atau dua mesin klien tertentu. Ini dapat dilakukan dengan beberapa kunci klien, tetapi kompleksitas konfigurasi meningkat secara kuadratik.

22
Tom Leek

Pada dasarnya saya mencoba mengembangkan strategi pribadi untuk berurusan dengan pasangan kunci

Jika Anda terutama bertanggung jawab untuk server yang bersangkutan, maka saya sangat menyarankan Anda mempertimbangkan mencari alat manajemen konfigurasi seperti boneka/koki. Keduanya memiliki metode untuk mendistribusikan kunci SSH ke mesin Anda.

Alasan saya mulai menggunakan boneka adalah karena saya ingin cara yang baik untuk segera mencabut kunci pada server Linux ~ 60 saya ketika staf berubah.

Ketika Anda memiliki alat manajemen konfigurasi untuk mengelola kunci Anda, maka akan jauh lebih mudah untuk memiliki banyak pasangan kunci. Alih-alih secara manual harus mencabut kunci di setiap kotak, atau menambahkan kunci baru di setiap kotak, Anda cukup menambahkan kunci publik pada master konfigurasi, dan klien akan memperbarui daftar otorisasi dalam interval jajak pendapat apa pun yang Anda tetapkan untuk manajemen konfigurasi Anda alat.

Ini berarti bahwa Anda menaruh banyak kepercayaan pada Host manajemen konfigurasi Anda tidak dikompromikan. Karena biasanya melakukan tugas dengan hak akses root pada setiap mesin yang Anda konfigurasikan, Anda harus memastikannya terkunci rapat, dengan banyak audit. Jika penyerang berkompromi dengan master konfigurasi, maka itu bisa melakukan apa saja seperti menambahkan kunci baru, menambahkan akun baru, dll.

10
Zoredache

Saya menggunakan satu kunci per bidang dan per mesin. 4 remote diakses dari 2 workstation => 8 kunci pribadi. Jangan pernah menyalin kunci pribadi dari Host ke yang lain. Jika satu workstation terganggu, cabut semua kunci itu.

Karena membuat kunci dan mengonfigurasi SSH untuk menggunakannya cukup membosankan, saya menulis alat yang didedikasikan untuk mengelola kunci SSH saya untuk akses Github: github-keygen .

0
dolmen