Haruskah saya mengenkripsi data dalam basis data?


16

Saya punya klien, untuk itu saya akan melakukan aplikasi Web tentang perawatan pasien, mengelola pasien, berkonsultasi, riwayat, kalender, semuanya tentang hal itu pada dasarnya.

Masalahnya adalah bahwa ini adalah data sensitif, riwayat pasien dan semacamnya.

Klien bersikeras mengenkripsi data di tingkat basis data, tapi saya pikir ini akan menurunkan kinerja aplikasi web. (Tapi mungkin aku tidak perlu khawatir tentang ini)

Saya sudah membaca undang-undang tentang perlindungan data pada masalah kesehatan (Portugal), tetapi tidak terlalu spesifik tentang ini (saya hanya menanyai mereka tentang hal ini, saya menunggu tanggapan mereka).

Saya sudah membaca tautan berikut , tetapi pertanyaan saya berbeda, haruskah saya mengenkripsi data dalam database, atau tidak.

Satu masalah yang saya perkirakan dalam mengenkripsi data, adalah bahwa saya akan membutuhkan kunci, ini bisa berupa kata sandi pengguna, tetapi kita semua tahu bagaimana kata sandi pengguna (12345 dll.), Dan menghasilkan kunci yang harus saya simpan itu di suatu tempat, ini berarti bahwa programmer, dba, apa pun bisa memiliki akses ke sana, ada pemikiran tentang ini?

Bahkan menambahkan garam acak ke kata sandi pengguna tidak akan menyelesaikan masalah karena saya selalu dapat mengaksesnya, dan karenanya mendekripsi data.


1
Saya lebih dari sisi klien dev, tapi saya curiga mengenkripsi segala sesuatu sebenarnya akan membuat data lebih sedikit, tidak lebih aman jika Anda menggunakan kunci yang sama.
Erik Reppen

4
Anda dapat meletakkan seluruh database pada volume terenkripsi dan menyebutnya sehari. Tentu membaca / menulis akan lebih lambat, tetapi Anda tetap memanfaatkan semua RDMS (atau apa pun yang Anda gunakan), sementara data pada disk dienkripsi
DXM

2
Itu juga berarti Anda tidak akan dapat melihat data di meja kerja mysql? Semua yang terbaik untuk debugging.
Manoj R

4
Kedokteran adalah industri yang sangat diatur. Para profesional yang bekerja di sana terbiasa meminta seseorang memberi tahu mereka aturannya. Pola pikir ini merambah ke proyek-proyek TI. Ini bukan masalah keamanan. Ini masalah budaya. Biaya berbisnis di bidang medis.
Reactgular

1
Sebuah rumah sakit di Inggris didenda lebih dari £ 300.000 karena disk drive tersesat berisi database yang tidak terenkripsi. Informasi kesehatan sangat sensitif.
MarkJ

Jawaban:


9

Saya pribadi akan memeriksa undang-undang ini. Jika data perlu dienkripsi, maka perlu dienkripsi.

Jika Anda tidak menerima panduan apa pun, saya akan bertujuan untuk melindungi tautan antara pasien, dan data mereka. Yaitu Anda kemungkinan besar memiliki PatientIDyang digunakan dalam tabel di seluruh database. PatientIDtidak mengidentifikasi pasien, hanya riwayat medis pasien dll ... Namun, untuk mengidentifikasi PatientIDsebagai Joe Bloggs yang tinggal di Rua de São Bernardo Lisbon, saya akan menyimpan ini dalam DB terpisah jika saya bisa. Gunakan TDE untuk detail pribadi pasien dan pertimbangkan untuk mengenkripsi itu di atas itu menggunakan kunci dalam aplikasi web Anda.

Sementara pencurian data medis itu tanpa sarana untuk mengidentifikasi pasien akan sangat memalukan, tidak mungkin ada yang lebih dari itu. Ada beberapa kompetisi online yang menggunakan data medis yang dianonimkan ini.

Dengan pemisahan data medis dari rincian pribadi pasien. Gunakan seperangkat peran yang kuat untuk membatasi staf hanya pada apa yang mereka butuhkan. Dengan pengecualian staf medis yang perlu berurusan dengan pasien secara langsung (perawat & dokter garis depan), tidak ada yang harus memiliki akses ke keduanya. Resepsionis hanya perlu rincian pribadi pasien, staf lab hanya perlu catatan medis dan PatientID, perawat bedah hanya kondisi medis saat ini dan nama depan.

Ketika Anda telah mengidentifikasi setiap rangkaian peran, bertujuan untuk tidak hanya mengimplementasikannya dalam aplikasi web Anda, tetapi juga dalam database serta lapisan keamanan tambahan.


1
IANAL, tetapi orang awam IMO tidak boleh "memeriksa hukum" ketika tanggung jawab yang mungkin besar. Mereka harus berkonsultasi dengan seorang pengacara.
kevin cline

saya pergi dengan pendekatan ini sebagai jawaban yang benar .. catatan medis yang tidak terkait dengan pasien atau dokter tidak ada artinya dan tidak dapat digunakan bahkan untuk analisis statistik karena tidak memiliki referensi atau membuktikan bahwa itu tidak dibuat-buat.
Zalaboza

13

Ya, Anda harus mengenkripsi basis data.

Enkripsi dasar untuk data yang disimpan ("data saat istirahat") adalah Prinsip Keamanan yang Diterima Secara Umum, dan mungkin diamanatkan oleh hukum jika negara Anda memiliki undang-undang yang melindungi informasi pribadi atau kesehatan.

Kami menggunakan SQL Server 2008, jadi kami menggunakan Microsoft TDE; mungkin ada beberapa solusi pihak ketiga untuk MySQL atau mungkin hanya pendekatan enkripsi volume umum (seperti TrueCrypt) akan bekerja (walaupun saya ingin memiliki sesuatu yang telah disertifikasi untuk digunakan dengan database).

Jika dilakukan dengan benar, hit kinerja harus kecil.

By the way, tautan yang Anda sebutkan (mengenai pemisahan informasi sensitif) adalah sesuatu yang harus Anda pertimbangkan di atas enkripsi basis data dasar.

EDIT: Enkripsi yang disebutkan di atas akan mengenkripsi volume. Jika seseorang mencuri hard drive, mereka akan menemukan data dienkripsi. Namun, jika seseorang menjalankan query pada database, mereka akan melihat data yang tidak terenkripsi (itu sebabnya saya menyebutkan pemisahan informasi, meskipun OP tidak ingin membahas hal ini).

Perhatikan bahwa rekomendasi ini dimaksudkan sebagai minimum yang harus Anda lakukan. Jika Anda menginginkan nasihat hukum, tentu saja Anda harus mencari di tempat lain. Jika Anda ingin diskusi yang lebih menyeluruh tentang penulisan kode aman, saya akan mulai dengan buku Menulis Kode Aman .


2
Saya tidak yakin apakah ini masalahnya. Pertanyaannya bukan tentang mengenkripsi database, tetapi tentang mengenkripsi data dalam database. Itu berarti data dalam kueri sql akan dienkripsi.
Manoj R

1
Hit kinerja harus kecil? Pencarian pada data akan menjadi PERLAHAN. Seluruh konsep pengindeksan tidak berfungsi saat data dienkripsi. Ini akan membutuhkan pemindaian seluruh tabel.
mike30

@ Mike Pendekatan di atas akan mengenkripsi volume dan tidak akan mempengaruhi pengindeksan dll.
jdigital

IMO Anda membutuhkan lebih banyak keahlian daripada yang bisa Anda dapatkan di sini. IANAL, tapi saya pikir klien Anda memiliki eksposur yang cukup tinggi jika data ini dikompromikan.
kevin cline

8

Sebelum memutuskan masalah keamanan seperti itu, Anda harus menilai model ancaman. Tanpa tahu apa yang Anda lawan, tindakan apa pun yang Anda ambil nampaknya kecil nilainya.

Sekarang, ada beberapa hal yang dapat Anda khawatirkan dalam konteks ini:

  • Penyerang mendapatkan akses fisik ke data Anda (misalnya, membobol pusat data, mencuri kaset cadangan, dll.)
  • Penyerang mendapatkan akses baca ke basis data mentah Anda
  • Penyerang merusak aplikasi Anda, misalnya melalui injeksi SQL, buffer overruns, dll.

Untuk skenario pertama, menyimpan basis data dan semua cadangan pada volume terenkripsi akan berfungsi, asalkan server tidak memiliki kepala - mencuri server atau kaset kemudian akan perlu memutus enkripsi tingkat disk.

Untuk skenario kedua, mengenkripsi data basis data memang membantu, tetapi hanya jika Anda tidak menyimpan kunci atau frasa sandi yang diperlukan di mana saja.

Dalam skenario ketiga, semuanya tergantung pada konteks di mana serangan itu terjadi: jika itu, misalnya, serangan XSS atau CSRF, maka penyerang dapat melakukan apa saja yang dapat dilakukan oleh pengguna yang sah, dan mengenkripsi data Anda tidak membantu sama sekali .

Dengan demikian, model ancaman Anda adalah penyerang yang memperoleh akses baca ke basis data mentah, baik dengan menemukan kredensial masuk dan mengelola untuk masuk ke server basis data dari luar, atau dengan mendapatkan akses root ke server basis data. Jalur tipikal adalah untuk pertama-tama mendapatkan akses shell di server web; dari sana, seorang penyerang kemudian dapat membaca kredensial akses dari file konfigurasi dan terhubung ke database.

Pertimbangan tambahan adalah tempat Anda menyimpan kunci dan frasa sandi, terutama jika Anda menggunakan platform dengan model eksekusi tanpa kewarganegaraan seperti PHP. Idealnya, Anda meminta pelanggan mengetikkan frasa sandi mereka saat diperlukan, dan menyimpannya hanya di memori, atau lebih baik lagi, melakukan dekripsi sisi klien (tetapi ini sering tidak layak). Pada platform tanpa kewarganegaraan, keadaan biasanya dilakukan dengan menggunakan sesi, memcache, basis data, atau file datar; tetapi semua ini jauh lebih rentan daripada menjaga negara dalam memori aplikasi web stateful sendiri. Menghindari ini adalah masalah ayam dan telur, karena jika Anda mengenkripsi keadaan sebelum bertahan, Anda hanya menciptakan rahasia lain yang harus Anda ingat dengan aman. Mengingat frasa sandi pada klien dan mengirimkannya bersama dengan setiap permintaan yang membutuhkannya mungkin merupakan solusi yang paling tidak mengerikan;


2
+1: tanpa model ancaman, Anda kemungkinan besar mengunci pintu depan tetapi membiarkan pintu belakang terbuka lebar.
kevin cline

8

Mengabaikan sejenak apa yang diminta klien, dan apa pun hukumnya ...

Tidak, Anda sebaiknya tidak mengenkripsi data. Jika Anda melakukannya, Anda tidak akan dapat dengan mudah mencarinya. Misalnya, bagaimana Anda mencari nama belakang like 'Smith%'jika setiap entri nama dienkripsi? Bagaimana Anda membuat grafik tekanan darah pasien dari waktu ke waktu jika Anda tidak bisa select .... from.... where patient_id = N?

Anda harus, tentu saja, memastikan server diamankan dengan benar, koneksi jaringan diamankan, dan bahwa antarmuka pengguna diamankan dengan benar (termasuk waktu tunggu sesi sehingga pengguna tidak dapat pergi meninggalkan akses ke siapa pun yang menggunakan komputer mereka). Anda juga mungkin ingin mengenkripsi cadangan basis data. Dan secara fisik mengamankan ruang server berada. Tapi saya tidak akan mengenkripsi data langsung.

Klarifikasi: Ini mengasumsikan apa yang ditanyakan OP sebenarnya mengenkripsi data dalam database. Bukan sistem file yang berada di basis data.


sepenuhnya setuju, namun HUKUM tidak :(
Zalaboza

1
Yah Anda bisa AES_DESCRYPT('') LIKE 'Smith%'meskipun sangat lambat. Atau Anda bisa mendapatkan intens dan membuat indeks terbalik dengan hash asin
foochow

1

Jika Anda mengembangkan aplikasi web dengan hati-hati menggunakan kerangka kerja MVC yang efektif seperti CakePHP. Zend atau Rails, maka Anda harus dapat mengaktifkan / menonaktifkan enkripsi di tingkat Modal data.

CakePHP misalnya memiliki beberapa contoh Perilaku untuk Modal yang mengenkripsi data. Membuat proses transparan kepada Pengontrol dan Tampilan.

Mengabaikan masalah tentang pengindeksan dan masalah basis data teknis lainnya saat melakukan ini. Seharusnya dimungkinkan untuk memiliki ini sebagai opsi yang dapat dikonfigurasi.

Selain itu, saya akan mengaktifkan enkripsi nanti atau hanya di server produksi. Data terenkripsi sulit untuk di-debug dan bekerja dengan saat mengembangkan, dan hanya dapat dilakukan pada kolom tertentu.


1

Ya, Anda harus mengenkripsi basis data.

Karena ini adalah informasi pribadi dan sensitif, saya yakin itu harus.

Dari kata sandi, Anda dapat memperoleh kunci enkripsi yang hanya disimpan untuk sesi ini. Dengan begitu, itu tidak disimpan di mana pun dan tidak seorang pun (termasuk DBA) dapat mengetahuinya karena tidak ada yang dapat mengetahui kata sandi tersebut. Siapa pun yang mencoba melihat DB secara langsung akan melihat omong kosong. Satu-satunya cara untuk merusak ini adalah melalui pembajakan sesi, tetapi saya berasumsi di sini bahwa sesi juga aman.


Orang-orang sangat sering lupa kata sandi mereka ... lalu apa?
curiousguy

-1

Saya bertanya pada diri sendiri mengapa klien meminta Anda untuk mengenkripsi DB? Jika dia meminta Anda untuk melindungi data saya akan setuju, tetapi dia sudah memiliki implementasi implisit dalam pikiran. Jadi selama dia tidak tahu persis apa yang dia bicarakan dia hanya melemparkan kata-kata pendek dari sudut pandang saya.

Saya juga merasa sangat tidak berguna untuk mengenkripsi DB, karena saya yakin bahwa setiap DBMS utama memperhitungkan keamanan secara tepat dan mungkin lebih baik dari yang Anda bisa. Untuk mengakses DB melalui DBMS, Anda perlu kredensial. Dalam kasus DB terenkripsi, Anda akan memerlukan kredensial itu juga, dan untuk mendekripsi data Anda akan membutuhkan kredensial yang sudah Anda miliki.

Mengikuti pola pikir ini, saya mengusulkan agar DBMS menangani keamanan, dan berupaya melindungi kredensial sepenuhnya dari input pengguna ke akses db, juga dapat menerapkan kata sandi yang kuat dan perubahan berkala.


... setiap DBMS utama mengambil keamanan ke akun ... kecuali ketika mereka tidak .
Jay Elston

Pertanyaan pertama yang harus saya tanyakan adalah bagaimana mereka melakukan itu dan bagaimana kerusakannya dapat dicegah dengan mengenkripsi db. Saya hanya memindai dengan cepat melalui artikel ini, tetapi mendapat kesan bahwa mereka memiliki kredensial.
sschrass

Tepat - Kredensial DB dapat dan memang dikompromikan. Tantangannya adalah untuk merancang sistem sehingga bahkan ketika pengguna yang tidak sah mendapatkan akses ke kredensial, mereka masih membutuhkan kunci enkripsi tambahan untuk dapat mengakses data sensitif. Untuk informasi kesehatan, ini bahkan lebih rumit. Tidak semua orang dengan akses ke kredensial DB harus dapat mengakses data sensitif. Misalnya DBA seharusnya tidak dapat membaca data pasien dalam teks yang jelas. Satu-satunya orang yang dapat membaca data ini adalah pasien dan penyedia layanan mereka.
Jay Elston
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.