it-swarm-id.com

Standar untuk mengenkripsi kata sandi dalam file konfigurasi?

Tempat kerja saya memiliki standar bahwa kata sandi plaintext tidak diperbolehkan dalam file konfigurasi aplikasi. Ini cukup masuk akal di wajahnya, jika seseorang mendapatkan akses ke file konfigurasi, mereka tidak secara otomatis memiliki akses ke semua hak istimewa aplikasi itu. Dalam beberapa kasus mungkin dan jelas lebih disukai untuk memiliki akses yang terkait dengan login atau menghindari memiliki kata sandi, seperti di Windows Security untuk otentikasi SQL Server, atau mengkonfigurasinya di lokasi pihak ketiga, seperti konfigurasi JDBC di lingkungan J2EE , tapi ini tidak selalu memungkinkan.

  • Ketika saya harus memiliki kata sandi dalam file konfigurasi, tingkat enkripsi apa yang harus saya bawa?
  • Bagaimana Anda menangani fakta bahwa kunci enkripsi untuk kata sandi harus berupa kode atau disimpan dalam file konfigurasi yang lain?
  • Haruskah kunci enkripsi untuk kata sandi dapat dibaca manusia?
57
C. Ross

Jadi yang berikut ini agak terlalu panjang untuk komentar ...

Mungkin mundur selangkah dan membandingkan manfaat kontrol preventif dan detektif mungkin membantu. Kontrol pencegahan menyertakan enkripsi tetapi Anda juga bisa menyandikan kata sandi untuk membuatnya kurang jelas. Pendekatan ini dimaksudkan untuk melindungi kata sandi dari pembagian yang tidak disengaja (pengkodean b32 akan menghasilkan karakter yang kurang bermakna (b32 menghasilkan string yang lebih panjang daripada b64). Pendekatan semacam itu hanya meningkatkan kesulitan menghafal urutan angka acak serta metode yang seharusnya digunakan untuk mendekode string. Pengkodean Base32/64 adalah cara sederhana untuk melindungi kata sandi yang tidak memerlukan logika tambahan untuk dibangun/dipelihara.

Pendekatan lain untuk kontrol pencegahan kemungkinan akan menggunakan enkripsi. Ada banyak cara untuk melindungi kunci. Tanpa masuk ke rincian atau mengulangi apa yang D.W. sudah diposting, Anda dapat melapisi kontrol detektif untuk meningkatkan postur keamanan. Misalnya, Anda dapat mengaudit akses ke file yang berisi kunci. Anda dapat menghubungkan peristiwa (seperti memulai kembali server/layanan) dengan akses ke file kunci. Permintaan akses lain (berhasil atau tidak) ke file kunci dapat menunjukkan aktivitas abnormal.

Untuk sampai ke pertanyaan Anda, inilah pendapat saya:

jika Anda harus menyimpan kata sandi dalam file konfigurasi, saya akan merekomendasikan setidaknya meng-enkode kata sandi jika memungkinkan. Pengkodean kata sandi akan mengurangi kemungkinan bocornya jika seseorang melihat-lihat file, katakan dengan perwakilan penjual menonton dukungan. Mengenkripsi kata sandi jauh lebih aman, tetapi itu membutuhkan kompleksitas tambahan.

Bagaimana menangani fakta bahwa kunci harus dikodekan atau disimpan dalam file lain. Nah, memisahkan kunci enkripsi di file lain meningkatkan kesulitan bagi seseorang untuk melihat kunci. Misalnya, Anda dapat menggunakan kontrol akses untuk membatasi akses ke file kunci tetapi tetap mempertahankan ACL yang lebih terbuka untuk file konfigurasi. Demikian pula, Anda dapat menerapkan audit untuk akses ke file kunci, yang dapat Anda gunakan untuk menghubungkan kembali ke acara yang memerlukan penggunaan kunci. Pengodean keras kunci mungkin baik-baik saja jika Anda membatasi akses ke biner. Pengkodean kata sandi yang hati-hati dapat dengan mudah dideteksi dengan menjalankan "string" terhadap biner. Anda dapat menyandikan/mengenkripsi kata sandi hard coded (yaitu memerlukan fungsi terpisah (mungkin dengan audit) kapan harus mendekode kata sandi, tetapi itu meningkatkan kompleksitas untuk pengembang dan admin (yaitu bagaimana seseorang mengubah kunci tanpa membangun kembali/mengkompilasi ulang biner) ?).

Haruskah kunci enkripsi untuk kata sandi dapat dibaca manusia? Tergantung. Hanya ada sejumlah cara untuk melindungi kunci. Kunci enkripsi biasanya dilihat sebagai string alfanumerik yang sulit dikomit ke memori. Anda selalu dapat menyandikan/mengenkripsi kunci, tetapi metode seperti itu tidak menghalangi seseorang yang cukup pintar untuk mengambil screenshot. Namun, Anda dapat menggunakan "kunci" sederhana (lebih seperti kata sandi) sebagai input ke fungsi ekspansi kunci. Dalam hal itu, mungkin langkah-langkah tambahan seperti pengkodean menambahkan beberapa nilai tambahan relatif terhadap biaya kompleksitas.

Jika ada, pendekatan yang baik adalah menerapkan kontrol berlapis-lapis. Kontrol pencegahan lebih sulit sementara kontrol detektif umumnya lebih mudah diterapkan. Memisahkan file-file kunci dapat menyederhanakan arsitektur keseluruhan dan implementasi kontrol. Terlepas dari apakah kontrol pencegahan atau detektif digunakan, mengaktifkan beberapa fungsi audit adalah suatu keharusan bersama dengan tinjauan log audit. Dengan cara ini, jika hal yang mustahil terjadi (akses ke kunci), Anda dapat mengambil tindakan korektif.

25
bangdang

Jika Anda menjalankan server yang memerlukan kata sandi untuk akses ke beberapa layanan jarak jauh, maka tidak ada solusi yang baik. Menyimpan kata sandi dalam file konfigurasi yang disimpan di lokasi yang sesuai mungkin membuat yang terbaik dari serangkaian pilihan yang buruk.

Pilihannya adalah: minta pengguna memasukkan kata sandi saat boot (ini buruk, karena jika server Anda di-boot ulang, sekarang server tidak dapat dijangkau sampai seseorang dapat berjalan secara fisik ke server dan memasukkan kata sandi); hardcode kata sandi ke dalam kode sumber kode server (ini jauh lebih buruk daripada meletakkannya di file konfigurasi); atau menyimpan kata sandi dalam file konfigurasi (yang paling buruk dari semua opsi). Hal utama yang harus diperhatikan dengan file konfigurasi, adalah memastikan file tersebut disimpan di luar root web Anda dan bahwa izin file-nya dikunci dengan benar.

Mengenkripsi kata sandi yang disimpan dalam file konfigurasi tidak membantu, karena sekarang di mana Anda menyimpan kunci dekripsi? Anda baru saja memindahkan masalah. "Ini kura-kura sepanjang jalan" bukan jawaban yang bisa diterima.

Di Windows, opsi lain yang mungkin Anda lihat adalah menyimpan kata sandi di DPAPI. Ini sedikit membantu untuk aplikasi desktop, tetapi tidak terlalu berguna untuk server yang tidak dijaga.

Untuk lebih lanjut, baca pertanyaan-pertanyaan berikut di situs ini: Menyimpan kata sandi untuk menghindari interaksi pengguna , tempat menyimpan kunci untuk enkripsi , Bagaimana proyek sumber terbuka menangani artefak aman? , Bagaimana saya bisa mendekripsi data dengan Java, tanpa hard-coding kuncinya? , Kata sandi dalam file .php , Di mana Saya menyimpan kunci dengan aman untuk sistem tempat sumbernya terlihat? .

P.S. Pada prinsipnya, Anda bisa menggunakan TPM untuk menyimpan kata sandi - tetapi dalam praktiknya, ini membawa Anda ke masalah Ujung Pendarahan, sehingga mungkin tidak layak untuk kebanyakan orang.

37
D.W.

Simpan kata sandi dalam variabel lingkungan pengguna O/S (non-sesi), dan jalankan program sebagai pengguna itu.

Keuntungan:

  1. Anda tidak akan pernah secara tidak sengaja memeriksa kata sandi ke dalam kontrol sumber karena tidak ada file untuk check-in.

  2. Jika Anda mengacaukan izin file pada file konfigurasi Anda (yang tidak pernah terjadi kan?), Kata sandi Anda tidak terganggu

  3. Hanya dapat dibaca oleh pengguna atau root (sama seperti file konfigurasi, sama dengan kunci pribadi yang melindungi file yang dienkripsi)

  4. Jika Anda mengenkripsi file, bagaimana Anda mengamankan kunci Anda?

  5. Kosongkan utusan Anda sebelum memulai proses baru, karena mungkin akan dilewati

Satu keuntungan bagi HSM adalah bahwa sementara pengguna atau root dapat gunakan HSM untuk mendekripsi nilai, mereka tidak pernah bisa mendapatkan kunci di dalamnya.

5
Neil McGuigan

Penyimpanan kata sandi lokal adalah masalah panjang yang saya hadapi. karena enkripsi tidak tahan-peluru, tetapi dapat membantu, ada beberapa opsi lain:

  1. menyimpan kata sandi pada mesin lokal dalam file baru (yang akan lebih baik untuk dienkripsi juga) dan membatasi akses ke file
  2. simpan kata sandi di server lain, yang akan diautentikasi melalui OAUTH atau layanan otentikasi lainnya - lihat tahoe-lafs: https://tahoe-lafs.org/trac/tahoe- lafs
  3. menggunakan layanan lokal terenkripsi yang menyimpan kata sandi, dan mengaksesnya menggunakan Sertifikat
  4. beberapa organisasi menyimpan kata sandinya sebagai kunci registri atau dengan DPAPI - http://msdn.Microsoft.com/en-us/library/ms995355.aspx
  5. menggunakan OTP menggunakan layanan manajemen akun
  6. menggunakan server proxy untuk mengakses data rahasia dan membatasi akses ke proxy

.

dan untuk pertanyaan Anda:

Ketika saya harus memiliki kata sandi dalam file konfigurasi, tingkat enkripsi apa yang harus saya bawa?

anda tidak harus memiliki kata sandi dalam kode Anda, tetapi ini adalah cara termudah dan paling tidak aman.

Bagaimana Anda menangani fakta bahwa kunci enkripsi untuk kata sandi harus berupa kode atau disimpan dalam file konfigurasi yang lain?

menggunakan pembatasan akses dan memonitor file

Haruskah kunci enkripsi untuk kata sandi dapat dibaca manusia? jika yang Anda maksud adalah kata sandi yang kuat dan dapat dibaca manusia, tidak ada masalah sama sekali

4
Sergey Malych

2 sen saya di sini adalah, untuk keamanan yang sempurna, Anda ingin aplikasi dapat melakukan sesuatu (membaca kata sandi) yang tidak dapat dilakukan oleh penyerang pada mesin fisik dengan hak yang sama, yang tampaknya merupakan kontradiksi .

Paling-paling Anda bisa mengaburkan kata sandi dalam konfigurasi ( Base64 , kunci di suatu tempat di komputer, dll ...)

0
Nicolas C