Bagaimana tim Administrator Sistem membagikan kata sandi dengan aman?


83

Apa praktik terbaik untuk berbagi ratusan kata sandi di antara beberapa orang? Kata sandi ini melindungi data penting misi, dan tidak akan pernah terlihat di luar tim kecil.



11
Ratusan BTW adalah angka yang sangat meresahkan. Apa yang terjadi ketika salah satu anggota tim dipecat? Memperbarui ratusan kata sandi akan menyakitkan.
Zoredache

2
Diperbaiki pada "ratusan adalah angka yang sangat mengganggu" hal. Saya pikir Anda mungkin perlu membuat cadangan dan mempertimbangkan kembali bagaimana Anda mengelola seluruh masalah keamanan di tempat pertama daripada mencoba untuk menempelkan plester pada apa yang Anda miliki saat ini.
Maximus Minimus

Jawaban:


14

Saya mungkin akan menulis solusi berbasis web khusus yang dihosting di intranet perusahaan. (lihat http://lastpass.com untuk inspirasi, atau untuk menggunakannya. Berbagi kata sandi adalah salah satu fiturnya, meskipun mungkin tidak berfungsi untuk volume Anda.)

EDIT : Tentu, solusi terbaik, jangan bagikan. Menyimpan kata sandi teks dalam media apa pun berbahaya, terutama ketika tujuan menyimpannya adalah untuk membagikannya. Ada sejumlah solusi yang hampir tak terbatas, masing-masing membawa bahaya yang terkait. Mengapa tidak meletakkannya di disk image terenkripsi, bakar gambar itu ke CD tunggal, masukkan CD ke dalam brankas yang hanya bisa dibuka oleh satu penjaga bersenjata, dan beri wewenang kepada orang-orang yang menunjukkan ID foto untuk membukanya?

Intinya adalah kita tidak benar-benar tahu skenario Anda. Mengapa Anda berbagi ratusan kata sandi penting-misi? Apakah itu untuk intranet kantor belakang Anda, VPN, atau apakah itu kata sandi pelanggan yang Anda simpan dalam plaintext karena suatu alasan? Apakah semua orang yang Anda butuhkan untuk membaginya dalam instalasi yang sama? Apakah pemindahan fisik seperti CD terenkripsi atau tabel tercetak yang disimpan dalam brankas benar-benar berfungsi? Atau apakah sysadmin Anda tersebar di seluruh dunia, menjadikan sarana elektronik untuk membagikannya satu - satunya solusi?


50
IMO Membangun sistem keamanan / enkripsi Anda sendiri hampir tidak pernah merupakan pendekatan yang tepat untuk suatu masalah.
Zoredache

2
@Zoredache, Itu omong kosong. Padahal, saya pikir solusi berbasis web untuk hosting kata sandi itu bodoh - tapi dia memang msanford yang mengatakan intranet. Masih berisiko sekalipun. Sama untuk semua solusi jaringan lainnya.
d -_- b

2
@Zoredache, OP tidak membangun sistem enkripsi khusus, sepertinya yang dia butuhkan hanyalah database yang aman. @sims Saya tidak melihat ada yang salah dengan solusi berbasis web yang dirancang dengan baik. Jawaban yang dipilih menyatakan dengan tepat bahwa (berbasis web! = Http; berbasis web = disimpan online). Memang, begitu saya membaca pertanyaan ini untuk kedua kalinya, saya setuju bahwa model dasar berbagi ton kata sandi tampaknya tidak perlu, dan bahwa solusi yang lebih baik dapat dicapai. Tetapi OP belum memberikan informasi yang cukup bagi saya untuk membuat keputusan itu ...
msanford

2
> @Zoredache, itu omong kosong. <Um, Sims, Anda cukup banyak terbang di hadapan sebagian besar orang enkripsi langsung dari kelelawar. Merancang enkripsi itu sulit, membuatnya enkripsi yang berharga lebih sulit lagi. schneier.com/essay-037.html Kadang-kadang kejahatan yang lebih rendah - yang Anda tahu - adalah pilihan yang lebih baik, ketika dihadapkan dengan kejahatan yang tidak Anda ketahui (yaitu desain yang belum diuji, non-peer-review, mungkin memiliki bug, mungkin memiliki lubang keamanan, dll.)
Avery Payne

1
@Setiap - merancang sistem kriptografi sulit dan harus diserahkan kepada para ahli, ya. Menggunakan alat yang telah dicoba dan diuji, seperti GPG pada file teks bersama, atau Keepass (yang menggunakan implementasi .NET dari AES dan SHA-256) tidak merancang sistem Anda sendiri.
mfinni

38

Praktik terbaik adalah tidak membagikan kata sandi. Gunakan alat seperti sudo untuk memungkinkan pengguna mendapatkan akses yang mereka butuhkan dari akun mereka sendiri. Jika Anda memiliki beberapa pengguna, masing-masing harus memiliki akun sendiri di mana diperlukan. LDAP (Unix / Linux) dan Active Directory adalah solusi yang baik untuk memberikan akses ke beberapa server dari database umum.

Bila perlu memiliki salinan kata sandi tertulis, segel di dalam amplop yang ditandatangani dan diberi tanggal di seluruh meterai. Ubah kata sandi saat digunakan. Ketika kata sandi diubah, tutup dengan amplop baru.

Untuk kata sandi yang benar-benar perlu dibagikan, gunakan salah satu alat kata sandi seperti Keepass yang dapat memiliki database mereka di jaringan. Alat dengan klien untuk berbagai platform lebih baik. Pertimbangkan apakah Anda memerlukan lebih dari satu basis data. Ingat Anda harus benar-benar mempercayai semua orang yang memiliki akses ke data ini.


+1 untuk akun pengguna yang tidak berhak untuk admin dengan kemungkinan eskalasi hak istimewa, pada server * nix saya akan menggabungkannya dengan hanya menggunakan sertifikasi dsa / rsa untuk sshd. Jika Anda melakukan hal-hal dengan alat grafis di linux Anda juga bisa menggunakan konfigurasi policykit yang disesuaikan.
Aaron Tate

12
Ini. Mencabut akses untuk pengguna saat mereka menggunakan kredensial bersama adalah mimpi buruk mutlak. Sedapat mungkin, delegasikan akses melalui akun unik pengguna. Selalu ada beberapa situasi di mana kata sandi umum tidak dapat dihindari, tetapi 'ratusan' kata sandi bersama meneriakkan cacat desain kritis.
Chris Thorpe

4
Saya setuju dengan biasanya tidak berbagi kata sandi, tetapi ada banyak situasi di mana itu perlu seperti perangkat jaringan dengan satu login, situs vendor di mana semua sysadmin menggunakan login yang sama untuk memesan, dan SQL sa pengguna atau kata sandi admin lokal di mana perlu. Itulah mengapa saya pikir KeePass adalah yang terbaik untuk ini: ini bekerja pada banyak platform, memungkinkan keamanan yang baik, dan dengan mudah mengatur ratusan kata sandi.
Paul Kroon

2
Kami memiliki variasi dalam hal ini, di mana kami memiliki kata sandi root yang ditulis tetapi terkunci di brankas yang hanya dapat dibuka oleh tim sistem. Kata sandi root kami sendiri panjangnya 16 karakter dan dibuat sedemikian rupa sehingga mustahil untuk diingat. Ya, ada beberapa rasa tidak aman di sana, tetapi jika seseorang mendobrak brankas, saya kira kita memiliki masalah yang lebih besar.
Frenchie

2
Berikut ini adalah skenario penggunaan nyata untuk tim kami: berbagi kata sandi untuk aplikasi berbasis web di mana mereka tidak mendukung banyak login untuk satu akun. Jadi jika lebih dari satu orang dalam tim perlu dapat mengakses akun itu, perlu ada cara untuk membagikan kata sandi untuk akun itu.
Jordan Reiter

11

Kami telah menggunakan KeePass untuk tujuan yang tepat ini. Ini adalah program kecil yang hebat yang menyimpan semua kata sandi Anda dalam file database terenkripsi. Ada fitur keamanan tambahan seperti membutuhkan file kunci bersama dengan kata sandi utama untuk mengakses kata sandi. Ini memungkinkan untuk beberapa lapisan keamanan (pisahkan file kunci dan basis data), sambil tetap membuatnya nyaman bagi semua orang untuk bekerja dengan semua kata sandi yang berbeda. Misalnya, Anda dapat menjalankan aplikasi dan file kunci dari drive USB, tetapi simpan database di jaringan Anda di suatu tempat. Itu akan membutuhkan kredensial untuk berbagi jaringan, kata sandi utama, dan drive USB fisik dengan file kunci.


KeePass tampaknya mendukung banyak platform, kemenangan besar di mata saya (saya bekerja di lingkungan platform campuran). Fitur "tipe otomatis" juga terlihat berguna.
Avery Payne

2
Gagasan bodoh untuk menyimpan kata sandi di jaringan.
d -_- b

1
@Ims - lalu bagaimana Anda membagikannya? KeePass menggunakan file terenkripsi untuk toko. Ini hanya versi yang lebih dapat digunakan dari file teks terenkripsi GPG di server Unix yang dapat diakses semua orang.
mfinni

1
@Ims - Saya biasanya setuju dengan Anda, tetapi itu bisa menjadi situasi keamanan vs produktivitas. Saya tidak ingin meletakkan kata sandi root dari server di sesuatu seperti ini, tetapi kata sandi admin dari saklar Layer 2 yang hanya memiliki satu login adalah kandidat yang baik untuk ini. Ada saat ketika dibutuhkan lebih banyak pekerjaan melakukan hal-hal dengan cara yang lebih aman daripada yang harus dibersihkan setelah pelanggaran keamanan. Plus, di atas semua enkripsi, Anda akan memiliki keamanan AD / NTFS pada file, dan sedikit ketidakjelasan dengan meletakkan file (yang dapat dinamai apa saja) di lokasi acak.
Paul Kroon

Saya tidak memikirkan mesin Windows. Tapi ya, jika Anda hanya dapat memiliki satu pengguna untuk sakelar itu, maka saya rasa itu masuk akal. Kalau tidak seperti kata Bill, katakan tidak untuk kata sandi bersama, yang juga merupakan poin saya tentang kunci.
d -_- b

5

Apa praktik terbaik untuk berbagi ratusan kata sandi di antara beberapa orang?

Mudah, ini hadir dalam dua rasa:

  1. Anda tidak, polos dan sederhana. Jika Anda memilih untuk melakukan ini, Anda menunda otentikasi kata sandi ke otoritas tepercaya eksternal dan mengontrol otentikasi dari sana.

  2. Anda melakukannya, tetapi dalam melakukannya, Anda memiliki kontrol akses eksternal yang memiliki kata sandi atau token keamanan yang tidak dicatat di dalam sistem yang Anda gunakan (yaitu catatan kata sandi dilindungi oleh kata sandi lain yang memiliki ketersediaan terbatas). Ada banyak masalah dengan ini.

Kata sandi ini melindungi data penting misi, dan tidak akan pernah terlihat di luar tim kecil.

Anda harus secara serius mempertimbangkan layanan otentikasi aman yang terintegrasi dengan layanan direktori untuk mengatasi masalah ini. Kombinasi DS / AS menciptakan "otoritas" tepercaya yang dapat bertindak sebagai penengah untuk semua pengguna dan perangkat Anda. Akun pengguna dapat diabstraksikan jauh dari kata sandi aktual yang digunakan dalam otentikasi, membuatnya mudah untuk "memutuskan" kata sandi dari kebijakan akses. Kontrol kata sandi adalah dengan menonaktifkan akun pengguna; jadi jika admin pergi, Anda cukup mematikan akun mereka, dan akses mereka hilang (karena kata sandi orang itu hanya memberikan akses berdasarkan validitas DS / AS yang mengonfirmasi akun itu valid).

Ini hanya akan berfungsi ketika Anda berada di lingkungan yang memungkinkan perangkat / program Anda untuk mengecilkan permintaan otentikasi mereka ke sumber eksternal, jadi itu mungkin bukan solusi untuk Anda . Jika Anda memiliki persentase signifikan dari perangkat / program yang dapat mengakomodasi otentikasi eksternal, maka saya akan melanjutkan dan melakukan ini, jika hanya untuk mengkonsolidasikan beberapa ratus kata sandi ke daftar yang dapat dikelola, katakanlah, selusin. Jika Anda memutuskan untuk menempuh rute ini, ada beberapa solusi yang sudah tidak berlaku, terkenal dan telah teruji untuk hal ini.

  • Direktori Aktif. Mungkin yang paling terkenal dari grup, memberi Anda Kerberos sebagai opsi otentikasi, dan menyediakan LDAP untuk DS dasar.
  • Samba / Winbind. Anggap ini sebagai "Active Directory Light", Anda tidak mendapatkan semua fitur AD melainkan model yang lebih tua berdasarkan NT4 (pikirkan hash LANMAN). Ini akan digantikan dengan integrasi AD Samba 4 dan mungkin akan "hilang".
  • Layanan Direktori Novell. Saya tidak cukup tahu tentang hal ini untuk merekomendasikannya, tetapi saya tahu itu masih ada. Banyak entitas pemerintah masih menjalankan NDS, jadi jika Anda melakukan pekerjaan di "sektor" itu akan menarik bagi Anda. Novell baru-baru ini mem-porting NDS untuk dijalankan sebagai layanan Linux, tetapi saya tidak tahu apakah itu masih merupakan produk yang aktif (sekitar 2005).
  • LDAP + Kerberos. Ini pada dasarnya adalah "direktori home" Active Directory, minus semua "fitur bagus". Namun, mereka juga dikenal komponen dengan basis kode yang stabil dan matang, jadi integrasi layanan ini biasanya merupakan tingkat "penyesuaian" yang diperlukan untuk membuat berbagai hal berfungsi.
  • SSH Keys + (masukkan program administrasi sistem di sini, mungkin boneka). Hanya berguna di mana Anda memiliki SSH di seluruh papan dan semua perangkat diakses dengan cara ini. Kunci dapat dibagikan dan dicabut sesuai kebutuhan, dan kata sandi menjadi "tidak relevan" ketika kunci SSH memberikan akses. Menggunakan sistem seperti boneka memungkinkan Anda untuk memperbarui ratusan mesin dengan mengeluarkan perintah secara massal untuk menambah / mencabut kunci SSH.
  • Beberapa kombinasi di atas.

Ada juga pertanyaan tentang seberapa banyak keamanan yang Anda butuhkan. Anda tidak menentukan apakah dengan "mission critical" yang Anda maksudkan bahwa hulu ledak nuklir dapat menghujani kota, atau jika "mission critical" berarti bahwa pengiriman Furbies terbaru tidak akan berhasil masuk ke kota. Akan sangat membantu jika ada sesuatu yang menggambarkan penilaian risiko / ancaman.


2

Beberapa hal:

  • Seperti yang orang lain katakan, ini adalah ide yang buruk. Gunakan LDAP, dll
  • Jika Anda berkomitmen untuk melakukan ini dengan alasan apa pun, setidaknya konsolidasi kata sandi. 100 kata sandi yang tidak dikelola berarti Anda tidak memperbarui kata sandi.
  • Simpan di atas kertas. Meminta staf untuk menandatangani kertas dengan tinta warna berbeda agar lebih mudah untuk menentukan apakah suatu lembar disalin.
  • Jika Anda menggunakan Unix, gunakan S / KEY untuk menghasilkan kata sandi satu kali. Simpan itu di tempat yang aman.

Anda juga harus melampaui langkah-langkah keamanan mekanis dengan memasukkan kata sandi kertas ke dalam brankas atau mengenkripsi kata sandi. Baca terus bagaimana organisasi dengan model keamanan yang matang mengamankan kunci dan kombinasi yang aman. Saya tidak merekomendasikan melakukan apa yang ingin Anda lakukan, tetapi jika Anda melakukannya:

  • Orang-orang yang akan menggunakan kata sandi tidak dapat mengontrol akses ke kata sandi. Sekelompok orang yang berbeda dalam rantai manajemen yang berbeda perlu mengontrol akses ke brankas, laci, dll. Jika Anda memiliki grup keuangan, mereka mungkin menjadi kandidat. Mungkin VP pemasaran, dll.
  • Harus ada log tertulis ketika brankas dibuka dan seseorang memiliki kata sandi.
  • Kata sandi harus diubah dalam waktu 24 jam setelah diperiksa.

Prosedur seperti ini menyakitkan di leher, tetapi akan berfungsi sebagai insentif bagi orang untuk mengadopsi praktik yang lebih waras. Jika Anda tidak melakukan sesuatu seperti yang saya jelaskan, jangan repot-repot melakukan gerakan mengunci kata sandi, karena bagaimanapun Anda akan dilanggar suatu hari nanti.


2

Saya tahu ini adalah pertanyaan lama tetapi saya baru saja menemukan solusi berbasis web opensource yang disebut Corporate Vault yang mungkin menarik bagi sebagian orang. Saya belum punya kesempatan untuk mencobanya.


1

kami menggunakan program yang disebut Kata Sandi Aman . itu bagus dan sangat aman, Anda dapat mengatur database pada drive jaringan dan memberikan semua orang yang membutuhkannya mengakses dan kata sandi ke brankas itu sendiri, yang kemudian menyimpan semua nama pengguna dan kata sandi yang dienkripsi dengan aman.


1

https://pypi.python.org/pypi/django-pstore/ menggunakan enkripsi GPG per pengguna untuk kata sandi bersama (dan data lain yang mungkin ingin Anda bagikan). Server tidak pernah tahu tentang kata sandi apa pun, hanya menyimpan data yang dienkripsi. Semua orang menggunakan kunci pribadi mereka untuk mendekripsi rahasia bersama.

Sistem ini mencakup manajemen hak: tidak semua orang mendapat akses penuh.



0

SPB Wallet adalah yang baik yang kami gunakan untuk menggunakan PW safe by ghost tetapi SPB wallet memungkinkan Anda menyinkronkan ke jaringan berbagi dan juga menyinkronkan ke iphone Anda jika Anda mendapatkan aplikasi. Ini juga memiliki penghasil kata sandi bawaan dan Anda dapat membuatnya dari kata sandi sederhana hingga kata sandi yang sangat kompleks. Anda juga dapat menyalin kata sandi saat kata sandi masih bertanda bintang sehingga jika seseorang melihat Anda dapat menyalin dan menempelnya tanpa ada yang melihat kata sandi. Aplikasi PC otomatis terkunci setelah tidak ada aktivitas untuk jangka waktu tertentu.


0

Opsi lain adalah Azure Key Vault yang menyimpan rahasia Anda dengan aman dan memungkinkan Anda untuk mengizinkan akses kepada mereka secara terprogram, dengan mudah memutar kata sandi Anda, dll. Tidak ada UI yang bagus untuk itu, tetapi jika Anda baik-baik saja dengan akses baris perintah, ini bagus.


0

Praktik terbaik kami adalah membagikan kata sandi sesedikit mungkin.

Karena itu kami misalnya: - menggunakan my.cnf di direktori home root untuk kata sandi ke database - gunakan kunci ssh untuk masuk ke server dan memiliki satu kata sandi root yang hanya diizinkan melalui konsol (jadi Anda harus memiliki akses fisik / bmc ke server ) - gunakan ldap sedapat mungkin (ssh, bmc, switch, redmine, ....)

Namun, ada beberapa situasi di mana kami tidak dapat menggunakan pendekatan ini (seperti kata sandi root). Kemudian kami menggunakan keepass pada penyimpanan bersama kami, tetapi kami menyimpan sedikitnya 10 kata sandi yang diperlukan.


-1

Pertanyaan yang sangat bagus Saya akan tertarik pada jawaban lain.

Inilah yang saya lakukan, tetapi pertama-tama saya sarankan menggunakan kunci yang dibagikan sebelumnya jika memungkinkan. Saya tidak tahu apakah ini mungkin dengan sistem Windows.

Karena jumlah kata sandi harus kecil (Anda menggunakan kunci jika memungkinkan), saya menggunakan file teks biasa yang dienkripsi dengan gpg pada sistem yang tidak memiliki NIC. Jadi (1) Anda memerlukan akses fisik dan (2) kata sandi.

diedit untuk kejelasan


Kunci? Seperti di, Tombol USB? Kunci fisik yang membuka kunci? Kunci Kartu Cerdas? Kunci GPG? Pass-frase kunci yang hanya ada di perangkat basah di kepala Anda? Kombinasi di atas?
Avery Payne

Kunci mobil! JK. Untuk memperjelas, maksud saya kunci ssh. Itulah sebabnya saya katakan itu tidak mungkin untuk menggunakan kunci yang dibagikan sebelumnya dengan windows.
d -_- b
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.