Bagaimana cara mengelola server web Proteksi kunci privat SSL (kata sandi vs. tanpa kata sandi)?

Kami memiliki diskusi di grup keamanan perusahaan saya tentang apa yang lebih buruk dari opsi berikut untuk mengelola kunci pribadi SSL.

Server web membutuhkan akses ke kunci pribadi untuk operasi enkripsi. File ini harus dilindungi dari akses tidak sah. Pada saat yang sama, server harus mulai secara otomatis, tanpa campur tangan manusia (jika cukup aman).

Kami membahas tiga opsi:

1. Lindungi kunci dengan izin sistem file.

2. Gunakan kunci yang dilindungi kata sandi dan masukkan kunci secara manual di setiap restart.

3. Gunakan kunci yang dilindungi kata sandi dan simpan kunci di sistem file untuk secara otomatis memulai kembali.

Kekhawatiran kami adalah sebagai berikut:

1. Dengan opsi 1, restart otomatis tetapi kompromi dapat menyalin kunci privat dan, seperti tidak terlindungi, dapat digunakan untuk mendekripsi komunikasi atau menyamar sebagai server kami.

2. Opsi 2 tampaknya lebih aman tetapi perlu intervensi manusia dan sysadmin khawatir jika itu terjadi di luar jam kerja. Juga, kata sandi harus dibagikan dengan beberapa sysadmin dan Anda tahu rahasia bersama bukan lagi rahasia.

3. Opsi 3 memiliki yang terbaik dari kedua opsi sebelumnya tetapi jika seseorang memiliki akses ke kunci juga bisa memiliki akses ke kata sandi :(, jadi sepertinya tidak begitu aman sama sekali.

Bagaimana Anda mengelola keamanan kunci pribadi server Anda? Apakah ada opsi lain (lebih aman)?

Opsi 1 adalah saya pikir standar yang diterima.

Namun, jika Anda benar-benar menginginkan keamanan ekstra, mengapa Anda tidak memiliki server yang aman (tidak ada di DMZ Anda) yang diatur untuk memonitor server web Anda, dan jika apache turun, ia dapat secara otomatis login jarak jauh, dan restart apache , memasok frasa sandi.

Jadi frasa sandi disimpan di komputer, tetapi tidak sama dengan menjalankan apache, dan tidak di DMZ Anda. Anda mendapatkan keamanan tambahan menggunakan kata sandi, dan mempertahankan kemampuan untuk memulai kembali secara otomatis.

Jika seseorang memiliki akses yang cukup ke server untuk membaca kunci, maka kemungkinan besar mereka juga memiliki akses yang cukup untuk melampirkan debugger dan mendapatkan kunci dari memori.

Kecuali jika Anda benar-benar suka terbangun di tengah malam untuk mengetikkan kata sandi pilih opsi 1. Ketika Anda memiliki banyak server, Anda ingin memulai ulang secara otomatis pada kegagalan, dan opsi 2 tidak memungkinkan untuk itu.

Satu kemungkinan untuk keamanan yang lebih tinggi daripada 1. tetapi kurang waktu henti dari 2. adalah untuk membuat kunci pribadi dengan validitas pendek dan secara teratur mendaur ulangnya. Dengan begitu Anda dapat menyimpannya tanpa frasa sandi tetapi mengurangi celah keamanan.

Seperti yang Anda kenal, opsi 3. tidak memberikan keamanan tambahan apa pun di atas 1.

Kepraktisan menentukan bahwa dalam hampir semua situasi Anda akan berakhir menggunakan opsi (1). Perm file system adalah cara terbaik untuk masuk dalam sebagian besar skenario keamanan vs praktis.

Pada sistem * nix, Anda dapat membatasi kunci privat hanya untuk di-root, karena sebagian besar server web yang bagus (seperti apache) akan mulai sebagai root tetapi menurunkan versi privat mereka ke pengguna terbatas begitu mereka memiliki port istimewa yang mereka butuhkan (80, 443 dll) .

Seperti yang Anda sebutkan opsi (3) dari sudut pandang keamanan sama dengan opsi (1).