Haruskah saya mengenkripsi data dalam basis data?

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.

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.

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 .

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;

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.

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.

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.

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.