Apa praktik keamanan yang baik untuk menyimpan basis data penting pada laptop pengembang?

33

Kami memiliki beberapa pemberian:

Pengembang membutuhkan replika database produksi pada mesin mereka.
Pengembang memiliki kata sandi untuk basis data tersebut di file App.config.
Kami tidak ingin data dalam basis data tersebut dikompromikan.

Beberapa solusi yang disarankan dan kelemahannya:

Enkripsi cakram penuh. Ini menyelesaikan semua masalah, tetapi menurunkan kinerja laptop, dan kami adalah pemula, jadi tidak punya uang untuk tenaga kuda.
Membuat VM dengan hard disk terenkripsi, dan menyimpan database di atasnya. Ini berfungsi dengan baik, tetapi tidak banyak membantu, karena ada kata sandi di Web.Config.
Solusi nomor 2 + mengharuskan pengembang untuk mengetik kata sandi basis data setiap kali ia menjalankan apa pun. Ini menyelesaikan semua masalah, tetapi sangat rumit untuk pengembang yang terkadang menjalankan aplikasi beberapa kali dalam satu menit. Kami juga memiliki beberapa aplikasi yang terhubung ke database yang sama, dan penerapan layar kata sandi harus berbeda di masing-masing.

Jadi, pertanyaan saya adalah, apakah ada solusi umum untuk masalah seperti itu, atau ada saran tentang bagaimana membuat solusi di atas bisa diterapkan?

database security

— Svarog
sumber

26

Apakah Anda benar-benar mengukur dampak kinerja dari enkripsi disk penuh. Saya telah menggunakannya pada laptop yang cukup lama dan tidak mengenali penurunan kinerja yang signifikan. Sistem operasi modern cukup baik dalam caching dan disk lambat pula. Dampak terburuk mungkin pada masa pakai baterai Anda.

— 5gon12eder

69

Sejujurnya, ini kedengarannya bukan pendekatan yang tepat. 1) Mengapa pengembang perlu database produksi di mesin mereka? Apakah tidak ada cara untuk membuat data dummy untuk dev db? 2) Mengapa kata sandi disimpan dalam teks biasa dalam file konfigurasi? Anda mencoba menempatkan bandaid pada proses yang cacat, tampaknya. Mungkin Anda dapat merevisi apa yang sebenarnya hidup di mesin dev serta bagaimana kata sandi disimpan untuk database.

— Thomas Stringer

2

Ada alasan bagi pengembang untuk membutuhkan basis data produksi. Karena alasan historis, pekerjaan mereka terlalu digabungkan dengan data langsung. Saya tahu ini adalah ide yang buruk, dan jika kami tidak menemukan solusi yang baik, kami akan pindah ke data dummy. Untuk saat ini saya mencoba mencari solusi yang bagus tanpa itu.

— Svarog

6

Tidak ada pengguna MacBook Pro yang dapat memberi tahu Anda dari kecepatan mesin apakah enkripsi disk penuh dihidupkan atau dimatikan pada drive SSD. Tidak ada perbedaan. Tidak ada yang bisa Anda perhatikan. Mungkin yang bisa Anda ukur, tetapi tidak ada yang terlihat.

— gnasher729

5

Saya komentar kedua @ gnasher729. Setelah menggunakan enkripsi disk penuh selama bertahun-tahun di lingkungan yang diatur (keuangan dan perawatan kesehatan), itu tidak harus menguras kinerja. Banyak orang memunculkan poin valid lainnya, tetapi dalam lingkungan HIPAA sulit untuk memiliki kebijakan yang masuk akal tanpa enkripsi disk lengkap, bahkan jika database tidak ditempatkan pada notebook. Email dan fragmen data lainnya sering berakhir di sana. Tukar file .... dll. Enkripsi Disk Penuh tidak memadai, tetapi biasanya diperlukan.

— joshp

100

Anda bukan hanya tidak ingin salinan database produksi, tetapi juga mungkin ilegal. Misalnya, di AS, Anda tidak dapat memindahkan data produksi keluar dari lingkungan produksi jika berisi informasi yang diatur seperti data kesehatan pribadi, data keuangan, atau bahkan data yang dapat digunakan dalam pencurian identitas. Jika Anda melakukannya, Anda dapat didenda, kehilangan kepatuhan Anda dan karenanya harus diaudit lebih agresif, atau bahkan disebutkan namanya dalam gugatan.

Jika Anda membutuhkan data skala produksi untuk pengujian, Anda memiliki beberapa opsi:

Hasilkan semua data dummy. Ini lebih sulit daripada kedengarannya. Sangatlah sulit dan padat karya untuk menghasilkan data imajiner yang masuk akal.
Anonimkan data produksi Anda. Ini mungkin lebih mudah, tetapi lanjutkan dengan hati-hati.

Untuk opsi # 2

Dalam lingkungan produksi, admin database resmi membuat salinan data produksi.
Masih dalam lingkungan produksi, admin resmi yang sama menjalankan rutin yang menganonimkan semua data sensitif. Jika ragu, anonimkan.
Hanya dengan demikian data dipindahkan ke lingkungan lain.

— Corbin March
sumber

31

dan kata sandi untuk salinan basis data tidak boleh sama dengan yang untuk versi produksi .....

— Lightness Races with Monica

3

"Misalnya, di AS, Anda tidak dapat memindahkan data produksi dari lingkungan produksi jika mengandung informasi yang diatur" Apa? Apakah Anda punya sumber untuk ini? Tidak bisakah Anda, misalnya, menggunakan cadangan dari basis data produksi sebagai data untuk lingkungan pementasan, atau sebagai pengujian dbs pada mesin pengembang?

— pengasuh

12

@nanny Tidak jika Anda menggunakan data yang diatur. Misalnya, saya sudah bekerja di bawah peraturan HIPAA. HIPAA menyatakan "Entitas yang dilindungi juga harus menerapkan kebijakan dan prosedur minimum semestinya yang masuk akal yang membatasi seberapa banyak informasi kesehatan yang dilindungi digunakan, diungkapkan, dan diminta untuk tujuan tertentu." Kebijakan minimum yang diperlukan terbuka untuk beberapa interpretasi. Penasihat hukum kami menyarankan interpretasi ketat yang menyimpan data sensitif yang terkandung di mana pengembang tidak dapat mengaksesnya. (Apakah benar-benar perlu bagi mereka untuk melakukan pekerjaan mereka?) Hati-hati yang sama berlaku untuk kepatuhan keuangan seperti PCI.

— Corbin Maret

4

@nanny Ambil ini sebagai desas-desus dari non-pengacara, tetapi seperti yang saya pahami, aturannya sangat bervariasi di setiap negara. Penasihat hukum tempat saya bekerja selalu keliru dengan pertimbangan hati-hati. Sebenarnya, para devs tidak memerlukan SSN yang sebenarnya untuk melakukan tugas mereka, jadi penasihat menyarankan agar SSN itu hidup di lingkungan yang terlindung di mana devs tidak bisa mengaksesnya. Jangan dengarkan aku. Seorang pengacara melihat keluar untuk Anda kepentingan jangka panjang akan menjadi sumber daya terbaik.

— Corbin Maret

5

Sebenarnya, bukan ilegal untuk tidak peduli dengan PPI, kecuali jika Anda sedang melakukan pekerjaan pemerintah, maka Judul 32 ikut bermain ... tapi itu adalah paparan tanggung jawab perdata yang serius. namun ini bukan jawaban yang bagus. terbalik.

— dwoz

9

Bisakah Anda setidaknya memberi pengembang VM di pusat data Anda bahwa mereka dapat RD untuk pekerjaan ini? Meskipun mereka benar-benar harus bekerja dari data non-produksi, ini akan lebih aman sampai Anda bisa sampai di sana karena data tidak akan disimpan pada laptop yang mudah dicuri.

— Brian Knoblauch
sumber

ini berbunyi lebih seperti komentar, lihat How to Answer

— gnat

5

@gnat, jawaban ini mungkin pendek tetapi merupakan alternatif yang disarankan sangat bagus.

Jangan menjadi pedant, @gnat ... ini jawaban yang bagus.

— dwoz

@ dan1111 Itulah masalahnya. Itu bukan jawaban. Itu alternatif. Itu membuatnya menjadi komentar, bukan jawaban.

— corsiKa

2

@corsiKa, jawaban yang menantang premis pertanyaan diperbolehkan dan seringkali merupakan jawaban yang sangat baik. Lihat masalah XY: meta.stackexchange.com/questions/66377/what-is-the-xy-problem . Dan jawaban yang lebih rinci mungkin lebih baik, tetapi ini masih merupakan jawaban.

8

Ubah cara kerja Anda jika memungkinkan.

Seperti yang orang lain tunjukkan:

Menggunakan data produksi untuk pengembangan bukanlah praktik yang baik.
Memiliki kata sandi yang disimpan dalam teks biasa bukan praktik yang baik.

Kedua hal ini membuat Anda menghadapi risiko yang signifikan dan harus diubah jika memungkinkan. Setidaknya Anda harus menilai dengan serius berapa biaya pembuatan perubahan ini. Jika ini adalah ketergantungan eksternal yang Anda tidak memiliki kekuatan untuk berubah, pertimbangkan untuk meningkatkan ini sebagai masalah bagi siapa pun yang memiliki kekuatan itu.

Namun, di dunia nyata, mungkin benar-benar tidak mungkin untuk mengubah ini. Dengan asumsi bahwa apa yang Anda lakukan adalah legal, Anda mungkin harus hidup dengan pengaturan ini (setidaknya untuk sementara).

Jika ini benar-benar diperlukan, Anda hanya perlu melakukan enkripsi disk penuh.

Mengingat risikonya, Anda perlu menggunakan opsi keamanan terbaik yang tersedia, dan ini dia. Jika ada hit kinerja, hidup dengannya. Ini adalah biaya bekerja dengan data sensitif.

Jika saya pelanggan Anda, saya tidak akan terkesan bahwa Anda memutuskan untuk tidak menggunakan opsi keamanan terbaik yang tersedia dengan data saya, karena itu membuat laptop Anda sedikit lebih lambat.

1

"Bukan solusi ideal" harus diubah untuk "ide yang benar-benar bodoh" IMO

— Darkhogg

@ Arkhogg, Anda benar itu harus lebih kuat. Diedit. Saya tidak akan pergi sejauh "benar-benar bodoh" tanpa mengetahui seberapa sensitif aplikasi tersebut. Secara praktis, risiko kompromi sangat, sangat rendah jika menggunakan enkripsi disk penuh, sehingga sangat mungkin menjadikan ini sebagai masalah keamanan.

Saya setuju dengan poin pertama, tetapi bukan yang kedua. Jika Anda tidak menyimpan kata sandi Anda di plaintext, di mana Anda menyimpannya (1) ciphertext atau (2) otak Anda. Jika (1) lalu di mana Anda menyimpan kata sandi untuk sandi (infinite loop terdeteksi). Jika (2), maka saya harap Anda suka bangun jam 2:00 untuk mengetik kata sandi untuk memulai kembali layanan.

— emory

1

Jawaban Corbin March cukup bagus, saya hanya akan menambahkan detail tambahan, bahwa Anda umumnya memiliki dua kelas data dalam basis data produksi Anda: metadata sistem / aplikasi; dan data pengguna klien / data transaksional. Yang terakhir ini TIDAK PERNAH digunakan dalam lingkungan pengembangan "sebagaimana adanya".

Sangat jarang memang bahwa Anda memerlukan informasi klien produksi aktual untuk melakukan pengembangan.

Namun, jika masalah yang dijelaskan OP di sini melibatkan data rahasia dagang atau data sistem yang sangat berpemilik yang tidak melibatkan data pelanggan, yang diperlukan oleh pengembang ... pendekatan keamanan harus melibatkan skema yang tidak memiliki kata sandi db disimpan dalam teks standar di suatu tempat. Perlu ada mekanisme untuk, misalnya, membuat ulang kata sandi harian, yang tidak disimpan di disk.

— dwoz
sumber

5

client user data/transactional data... should NEVER be used in a development environment "as is." - Ini kedengarannya tidak bisa saya lakukan. Masalah pemrograman terkait produksi yang berkaitan dengan data klien tertentu tidak akan dapat diselesaikan dalam pengaturan ini. Lebih lanjut, data langsung aktual sangat berguna dari sudut pandang pengujian. Upaya privatisasi atau anonimisasi harus difokuskan hanya pada data yang diatur secara khusus.

— Robert Harvey

@RobertHarvey, itu hanya tidak bisa dijalankan jika Anda tidak dapat mereproduksi masalah produksi di lingkungan pengembang. Saya pikir sepanjang karir saya (panjang) saya dapat mengandalkan beberapa jari berapa kali data uji sanitasi yang tepat tidak memadai untuk mereproduksi bug produksi. "Informasi Bisnis Proprietary" jauh melampaui jumlah SSN dan CC!

— dwoz

4

Tetapi jika Anda akan menempuh rute itu, Anda akan memiliki orang-orang TI yang tidak dapat melakukan pekerjaan mereka karena mereka tidak memiliki akses Administratif untuk semuanya. Saya akui itu menyebabkan potensi masalah Snowden, tetapi saya tidak melihat alternatif yang bisa diterapkan, selain untuk mempekerjakan orang yang bisa Anda percayai. Sarbanes Oxley dan HIPAA sangat spesifik tentang jenis data apa yang perlu diasingkan, dan itu tidak termasuk "semua data produksi," tidak dengan jalan panjang. Yang mengatakan, saya tidak percaya data produksi dalam bentuk apa pun harus ada di laptop jelajah.

— Robert Harvey

1

-1 untuk TIDAK PERNAH. Komentar Anda yang lebih bernuansa lebih baik daripada jawaban Anda; Anda harus mengeditnya.

1

@ dan1111 kita bisa setuju untuk tidak setuju kalau begitu. Data pelanggan "sebagaimana adanya" harus TIDAK PERNAH PERNAH PERNAH digunakan dalam sistem dev. Itu harus selalu disanitasi. Anda tidak percaya ini karena Anda belum pernah digigit oleh luwak gila ini ... dan itulah masalahnya, ketika itu terjadi. Tikus gila gila yang bermaksud mengambil darahmu. Ikuti saran saya, hindari luwak yang gila.

— dwoz

1

Anda tidak menyatakan basis data dan lingkungan mana.

Jika Anda dapat menggunakan keamanan terintegrasi maka database tidak dapat diakses tanpa login sebagai pengguna itu. Ya, jika data ada di hard disk, itu bisa diretas, tetapi ini adalah pertahanan tingkat pertama.

App.config membuat saya berpikir ini mungkin .NET. Masukkan config ke dalam thumb drive dan bacalah dari thumb drive. Jika drive tidak ada maka buatlah pengguna mengetikkan kata sandi.

Apakah ada cara untuk menyimpan kata sandi dalam memori saat pertama kali dimasukkan dan dibaca oleh semua. Sekali lagi Anda tidak menyatakan lingkungan. File yang Dipetakan Memori

Dengan beberapa TDE Anda dapat menyimpan kunci pada perangkat yang terpisah sehingga mereka hanya memasok kunci ketika basis data dimulai.

— paparazzo
sumber

0

Salah satu opsi yang mungkin adalah membuat salinan database dan menggosok salinan itu dengan skrip sehingga Anda berakhir dengan data yang berbeda dari apa yang sebenarnya dalam produksi. Anda tidak akan berakhir dengan data yang sama dengan produksi tetapi Anda akan memiliki skala yang sama.

— Jason Crosby
sumber

ini sepertinya hanya mengulangi poin yang dibuat dan dijelaskan dalam jawaban teratas sekitar seminggu yang lalu

— agas