ฉันควรเข้ารหัสข้อมูลในฐานข้อมูลหรือไม่

16

ฉันมีลูกค้าซึ่งฉันจะทำแอปพลิเคชันเว็บเกี่ยวกับการดูแลผู้ป่วยการจัดการผู้ป่วยให้คำปรึกษาประวัติปฏิทินทุกอย่างเกี่ยวกับเรื่องนั้น

ปัญหาคือว่านี่เป็นข้อมูลที่ละเอียดอ่อนประวัติผู้ป่วยและอื่น ๆ

ลูกค้ายืนยันในการเข้ารหัสข้อมูลในระดับฐานข้อมูล แต่ฉันคิดว่านี่จะทำให้ประสิทธิภาพของเว็บแอปลดลง (แต่บางทีฉันไม่ควรกังวลเกี่ยวกับเรื่องนี้)

ฉันได้อ่านกฎหมายเกี่ยวกับการปกป้องข้อมูลเกี่ยวกับปัญหาสุขภาพ (โปรตุเกส) แต่ไม่เฉพาะเจาะจงมากเกี่ยวกับเรื่องนี้ (ฉันเพิ่งถามพวกเขาเกี่ยวกับเรื่องนี้ฉันรอการตอบสนองของพวกเขา)

ฉันได้อ่านลิงค์ต่อไปนี้แล้วแล้ว แต่คำถามของฉันแตกต่างกันฉันควรเข้ารหัสข้อมูลในฐานข้อมูลหรือไม่

ปัญหาหนึ่งที่ฉันคาดการณ์ไว้ในการเข้ารหัสข้อมูลคือฉันต้องการรหัสนี่อาจเป็นรหัสผ่านของผู้ใช้ แต่เราทุกคนรู้ว่ารหัสผ่านของผู้ใช้เป็นอย่างไร (12345 ฯลฯ ) และการสร้างรหัสที่ฉันต้องเก็บ มันอยู่ที่ไหนสักแห่งซึ่งหมายความว่าโปรแกรมเมอร์ DBA สิ่งที่สามารถเข้าถึงได้ความคิดใด ๆ เกี่ยวกับเรื่องนี้?

การเพิ่มเกลือแบบสุ่มลงในรหัสผ่านผู้ใช้ก็ไม่ได้ช่วยแก้ปัญหาเพราะฉันสามารถเข้าถึงได้ตลอดเวลาและดังนั้นจึงถอดรหัสข้อมูล

php mysql encryption

— ติ้ว
แหล่งที่มา

1

ฉันเป็นนักพัฒนาด้านไคลเอนต์ แต่ฉันคิดว่าการเข้ารหัสทุกอย่างจะทำให้ข้อมูลน้อยลงและไม่ปลอดภัยมากขึ้นถ้าคุณใช้รหัสเดียวกัน

— Erik Reppen

4

คุณสามารถใส่ฐานข้อมูลทั้งหมดลงในวอลลุ่มเข้ารหัสและเรียกมันได้ทั้งวัน แน่นอนว่าการอ่าน / เขียนจะช้าลง แต่คุณจะได้รับประโยชน์ทั้งหมดจาก RDMS (หรืออะไรก็ตามที่คุณใช้) ในขณะที่ข้อมูลบนดิสก์อยู่ในการเข้ารหัส

— DXM

2

นั่นหมายความว่าคุณจะไม่สามารถดูข้อมูลใน mysql workbench ได้หรือไม่? สิ่งที่ดีที่สุดสำหรับการแก้ไขข้อบกพร่อง

— Manoj R

4

การแพทย์เป็นอุตสาหกรรมที่มีการควบคุมอย่างเข้มงวด ผู้เชี่ยวชาญที่ทำงานอยู่ที่นั่นใช้เพื่อให้มีคนบอกพวกเขาว่ากฎคืออะไร ความคิดนี้มีแนวโน้มที่จะกระจายไปสู่โครงการไอที มันไม่ใช่ปัญหาด้านความปลอดภัย มันเป็นปัญหาทางวัฒนธรรม ค่าใช้จ่ายในการทำธุรกิจด้านการแพทย์

— Reactgular

1

โรงพยาบาลในสหราชอาณาจักรถูกปรับมากกว่า 300,000 ปอนด์เนื่องจากดิสก์ไดรฟ์หลงทางที่มีฐานข้อมูลที่ไม่ได้เข้ารหัส ข้อมูลด้านสุขภาพนั้นอ่อนไหวมาก

— MarkJ

9

ส่วนตัวฉันจะตรวจสอบกฎหมายเกี่ยวกับเรื่องนี้ หากข้อมูลนั้นจำเป็นต้องได้รับการเข้ารหัสข้อมูลนั้นจะต้องได้รับการเข้ารหัส

หากคุณไม่ได้รับคำแนะนำใด ๆ ฉันก็จะพยายามปกป้องลิงก์ระหว่างผู้ป่วยและข้อมูลของพวกเขา เช่นคุณมักจะมีPatientIDที่ใช้ในตารางทั่วฐานข้อมูล PatientIDไม่ได้ระบุผู้ป่วยเพียงประวัติทางการแพทย์ของผู้ป่วย ฯลฯ ... อย่างไรก็ตามเพื่อระบุPatientIDว่า Joe Bloggs อาศัยอยู่ที่ Rua de São Bernardo Lisbon ฉันจะเก็บสิ่งนี้ไว้ในฐานข้อมูลแยกต่างหากถ้าฉันทำได้ ใช้ TDE สำหรับรายละเอียดส่วนบุคคลของผู้ป่วยและพิจารณาการเข้ารหัสที่ด้านบนของปุ่มนั้นโดยใช้คีย์ในเว็บแอปพลิเคชันของคุณ

ในขณะที่การขโมยข้อมูลทางการแพทย์ที่ไม่มีวิธีการระบุผู้ป่วยจะน่าอายอย่างยิ่งก็ไม่น่าจะเป็นอะไรที่นอกเหนือไปจากนั้น มีการแข่งขันออนไลน์อย่างแท้จริงที่ใช้ข้อมูลทางการแพทย์ที่ไม่ระบุชื่อ

ด้วยการแยกข้อมูลทางการแพทย์จากข้อมูลส่วนตัวของผู้ป่วย ใช้ชุดบทบาทที่แข็งแกร่งเพื่อ จำกัด พนักงานในสิ่งที่พวกเขาต้องการเท่านั้น ด้วยข้อยกเว้นของเจ้าหน้าที่ทางการแพทย์ที่ต้องการจัดการกับผู้ป่วยโดยตรง (พยาบาลแนวหน้าและแพทย์) ไม่ควรมีใครเข้าถึงทั้งคู่ พนักงานต้อนรับต้องการเพียงข้อมูลส่วนตัวของผู้ป่วยเจ้าหน้าที่ห้องปฏิบัติการต้องการเพียงบันทึกเวชระเบียนและ PatientID พยาบาลผ่าตัดเท่านั้นปัจจุบันเงื่อนไขทางการแพทย์และชื่อ

เมื่อคุณระบุแต่ละชุดของบทบาทให้มุ่งมั่นที่จะไม่เพียง แต่นำไปใช้กับบทบาทในเว็บแอปพลิเคชันของคุณ แต่ยังรวมถึงในฐานข้อมูลและการรักษาความปลอดภัยอีกชั้นหนึ่ง

— M Afifi
แหล่งที่มา

1

IANAL แต่คนธรรมดาของ IMO ไม่ควร "ตรวจสอบกฎหมาย" เมื่อความรับผิดที่อาจเกิดขึ้นมีมาก พวกเขาควรปรึกษาทนายความ

— วินไคลน์

ฉันไปด้วยวิธีนี้ในฐานะที่เป็นคำตอบที่แท้จริง .. เวชระเบียนที่ไม่เชื่อมโยงกับผู้ป่วยหรือแพทย์ไม่มีความหมายและใช้ไม่ได้แม้สำหรับการวิเคราะห์ทางสถิติเนื่องจากไม่มีการอ้างอิงหรือพิสูจน์ว่ามันไม่ได้สร้างขึ้น

— Zalaboza

13

ใช่คุณควรเข้ารหัสฐานข้อมูล

การเข้ารหัสพื้นฐานสำหรับข้อมูลที่จัดเก็บ ("ข้อมูลที่เหลือ") เป็นหลักการรักษาความปลอดภัยที่ได้รับการยอมรับโดยทั่วไปและอาจได้รับคำสั่งตามกฎหมายหากประเทศของคุณมีกฎหมายที่ปกป้องข้อมูลส่วนบุคคลหรือสุขภาพ

เรากำลังใช้ SQL Server 2008 ดังนั้นเราจึงใช้ TDE ของ Microsoft อาจมีโซลูชันบุคคลที่สามสำหรับ MySQL หรืออาจเป็นเพียงวิธีการเข้ารหัสโวลุ่มทั่วไป (เช่น TrueCrypt) จะทำงานได้ (แม้ว่าฉันต้องการมีบางสิ่งที่ได้รับการรับรองให้ใช้กับฐานข้อมูล)

หากทำอย่างถูกต้องประสิทธิภาพการทำงานควรน้อย

โดยวิธีการเชื่อมโยงที่คุณกล่าวถึง (เกี่ยวกับการแยกข้อมูลที่สำคัญ) เป็นสิ่งที่คุณควรพิจารณาด้านบนของการเข้ารหัสฐานข้อมูลพื้นฐาน

แก้ไข: การเข้ารหัสดังกล่าวข้างต้นจะเข้ารหัสระดับเสียง หากมีคนขโมยฮาร์ดไดรฟ์พวกเขาจะพบข้อมูลที่เข้ารหัส อย่างไรก็ตามหากมีใครบางคนที่จะเรียกใช้แบบสอบถามในฐานข้อมูลพวกเขาต้องการดูข้อมูลที่ไม่ได้เข้ารหัส (นั่นคือเหตุผลที่ฉันพูดถึงการแยกข้อมูลแม้ว่า OP ไม่ต้องการที่จะหารือเรื่องนี้)

โปรดทราบว่าคำแนะนำนี้มีความหมายว่าเป็นขั้นต่ำที่คุณควรทำ หากคุณต้องการคำแนะนำทางกฎหมายแน่นอนว่าคุณต้องหาที่อื่น หากคุณต้องการการอภิปรายอย่างละเอียดมากขึ้นในการเขียนรหัสรักษาความปลอดภัยฉันจะเริ่มต้นด้วยการอ่านหนังสือการเขียนรหัสรักษาความปลอดภัย

— jdigital
แหล่งที่มา

2

ฉันไม่แน่ใจว่าเป็นกรณีนี้หรือไม่ คำถามไม่ได้เกี่ยวกับการเข้ารหัสฐานข้อมูล แต่เป็นการเข้ารหัสข้อมูลในฐานข้อมูล นั่นหมายถึงข้อมูลในการสืบค้น sql จะถูกเข้ารหัส

— Manoj R

1

ผลการดำเนินงานที่ควรมีขนาดเล็ก? การค้นหาข้อมูลจะช้า แนวคิดทั้งหมดของการจัดทำดัชนีไม่ทำงานเมื่อมีการเข้ารหัสข้อมูล มันจะต้องสแกนแบบเต็มตาราง

— mike30

@ ไมค์วิธีการข้างต้นจะเข้ารหัสไดรฟ์และจะไม่ส่งผลกระทบต่อการจัดทำดัชนี ฯลฯ

— jdigital

IMO คุณต้องการความเชี่ยวชาญมากกว่าที่คุณจะมาที่นี่ IANAL แต่ฉันคิดว่าลูกค้าของคุณมีความเสี่ยงสูงหากข้อมูลนี้ถูกบุกรุก

— วินไคลน์

8

ก่อนตัดสินใจเรื่องความปลอดภัยคุณควรประเมินรูปแบบการคุกคาม หากไม่มีความคิดว่าคุณกำลังปกป้องอะไรมาตรการใด ๆ ที่คุณทำจะมีค่าน้อย

ตอนนี้มีบางสิ่งที่คุณอาจกังวลในบริบทนี้:

ผู้โจมตีเข้าถึงข้อมูลของคุณทางกายภาพ (เช่นบุกเข้าไปในดาต้าเซ็นเตอร์ขโมยเทปสำรองเป็นต้น)
ผู้โจมตีเข้าถึงการอ่านฐานข้อมูลดิบของคุณ
ผู้โจมตีใช้งานแอพพลิเคชั่นของคุณเช่นผ่านการฉีด SQL, บัฟเฟอร์โอเวอร์รันเป็นต้น

สำหรับสถานการณ์แรกการจัดเก็บฐานข้อมูลและการสำรองข้อมูลทั้งหมดในโวลุ่มที่เข้ารหัสควรใช้งานได้หากเซิร์ฟเวอร์ไม่มีส่วนหัว - การขโมยเซิร์ฟเวอร์หรือเทปจะต้องทำลายการเข้ารหัสระดับดิสก์

สำหรับสถานการณ์ที่สองการเข้ารหัสข้อมูลฐานข้อมูลจะช่วยได้ แต่ถ้าคุณไม่เก็บคีย์หรือวลีรหัสผ่านที่จำเป็นที่ใดก็ได้

ในสถานการณ์ที่สามทุกอย่างขึ้นอยู่กับบริบทที่การโจมตีเกิดขึ้น: ถ้าเป็นเช่นการโจมตี XSS หรือ CSRF ผู้โจมตีสามารถทำทุกอย่างที่ผู้ใช้ถูกต้องตามกฎหมายสามารถทำได้และการเข้ารหัสข้อมูลของคุณไม่ได้ช่วยอะไรเลย .

รูปแบบการคุกคามของคุณจึงเป็นผู้โจมตีที่สามารถเข้าถึงการอ่านฐานข้อมูลดิบโดยการค้นหาข้อมูลรับรองการเข้าสู่ระบบและการจัดการเพื่อเข้าสู่เซิร์ฟเวอร์ฐานข้อมูลจากภายนอกหรือโดยการเข้าถึงรูทไปยังเซิร์ฟเวอร์ฐานข้อมูล เส้นทางทั่วไปคือการได้รับการเข้าถึงเปลือกแรกบนเว็บเซิร์ฟเวอร์; จากนั้นผู้โจมตีสามารถอ่านข้อมูลรับรองการเข้าถึงจากไฟล์กำหนดค่าและเชื่อมต่อกับฐานข้อมูล

การพิจารณาเพิ่มเติมคือที่ที่คุณเก็บกุญแจและวลีรหัสผ่านไว้โดยเฉพาะหากคุณใช้แพลตฟอร์มที่มีรูปแบบการดำเนินการแบบไร้รัฐเช่น PHP เป็นการดีที่คุณมีลูกค้าพิมพ์ข้อความรหัสผ่านเมื่อต้องการและเก็บไว้ในหน่วยความจำหรือดีกว่าทำถอดรหัสลูกค้าฝั่ง (แต่นี้ไม่ได้มักจะเป็นไปได้) บนแพลตฟอร์มไร้สัญชาติสถานะมักจะถูกนำไปใช้โดยใช้เซสชัน memcache ฐานข้อมูลหรือไฟล์แฟล็ต แต่สิ่งเหล่านี้มีความเสี่ยงมากกว่าการรักษาสถานะไว้ในหน่วยความจำของโปรแกรมประยุกต์บนเว็บ การหลีกเลี่ยงปัญหานี้เป็นปัญหาไก่และไข่เพราะหากคุณเข้ารหัสสถานะก่อนที่จะยืนยันคุณจะสร้างความลับอีกอย่างที่คุณต้องจำไว้อย่างปลอดภัย การจดจำข้อความรหัสผ่านบนไคลเอนต์และส่งไปพร้อมกับคำขอแต่ละครั้งที่ต้องการอาจเป็นโซลูชันที่น่ากลัวน้อยที่สุด

— tdammers
แหล่งที่มา

2

+1: หากไม่มีโมเดลภัยคุกคามคุณน่าจะล็อกประตูหน้า แต่เปิดประตูด้านหลังให้กว้าง

— วินไคลน์

8

ไม่สนใจสิ่งที่ลูกค้าขอและสิ่งที่กฎหมายเป็น ...

ไม่คุณไม่ควรเข้ารหัสข้อมูล หากคุณคุณจะไม่สามารถค้นหาได้อย่างง่ายดาย ตัวอย่างเช่นคุณจะค้นหานามสกุลได้like 'Smith%'อย่างไรหากทุกชื่อมีการเข้ารหัส? คุณจะทำกราฟความดันโลหิตของผู้ป่วยเมื่อเวลาผ่านไป select .... from.... where patient_id = Nอย่างไร

คุณควรตรวจสอบให้แน่ใจว่าเซิร์ฟเวอร์นั้นปลอดภัยการเชื่อมต่อเครือข่ายมีความปลอดภัยและส่วนต่อประสานกับผู้ใช้นั้นปลอดภัย (รวมถึงการหมดเวลาเซสชันเพื่อให้ผู้ใช้ไม่สามารถออกจากการเข้าถึงใครก็ตามที่ใช้คอมพิวเตอร์) คุณอาจต้องการเข้ารหัสข้อมูลสำรองฐานข้อมูล และปลอดภัยทางร่างกายในห้องที่เซิร์ฟเวอร์ตั้งอยู่ แต่ฉันจะไม่เข้ารหัสข้อมูลสด

ชี้แจง:นี่คือสิ่งที่สมมติว่าสิ่งที่ OP ขอมาคือการเข้ารหัสข้อมูลในฐานข้อมูล ไม่ใช่ระบบไฟล์ที่ฐานข้อมูลอยู่

— GrandmasterB
แหล่งที่มา

เห็นด้วยโดยสิ้นเชิง แต่กฎหมายไม่ได้ :(

— Zalaboza

1

คุณทำได้AES_DESCRYPT('') LIKE 'Smith%'ช้ามากอย่างไม่น่าเชื่อ หรือคุณอาจจะเอาจริงเอาจังแล้วสร้างดัชนีฤwithษีที่มีแฮชเค็ม

— foochow

1

หากคุณพัฒนาเว็บแอพพลิเคชั่นอย่างระมัดระวังโดยใช้กรอบ MVC ที่มีประสิทธิภาพเช่น CakePHP Zend หรือ Rails จากนั้นคุณควรจะสามารถเปิด / ปิดการใช้งานการเข้ารหัสในระดับข้อมูล Modal

ตัวอย่าง CakePHP มีตัวอย่างพฤติกรรมของ Modal ที่เข้ารหัสข้อมูล ทำให้กระบวนการโปร่งใสต่อผู้ควบคุมและมุมมอง

ไม่สนใจปัญหาเกี่ยวกับการจัดทำดัชนีและปัญหาฐานข้อมูลทางเทคนิคอื่น ๆ เมื่อทำเช่นนี้ มันควรจะเป็นไปได้ที่จะมีสิ่งนี้เป็นตัวเลือกที่กำหนดค่าได้

นอกจากนี้ฉันจะเปิดการเข้ารหัสในภายหลังหรือบนเซิร์ฟเวอร์ที่ใช้งานจริงเท่านั้น ข้อมูลที่เข้ารหัสนั้นยากต่อการดีบักและทำงานขณะที่กำลังพัฒนาและสามารถทำได้ในบางคอลัมน์เท่านั้น

— Reactgular
แหล่งที่มา

1

ใช่คุณควรเข้ารหัสฐานข้อมูล

เนื่องจากนี่เป็นข้อมูลส่วนบุคคลและข้อมูลที่ละเอียดอ่อนฉันจึงเชื่ออย่างแน่นอน

จากรหัสผ่านคุณสามารถรับรหัสการเข้ารหัสซึ่งคุณเก็บไว้สำหรับเซสชันเท่านั้น ด้วยวิธีนี้จะไม่ถูกเก็บไว้ที่ใดและไม่มีใคร (รวมถึง DBA) สามารถรู้ได้เนื่องจากไม่มีใครสามารถรู้รหัสผ่านได้เช่นกัน ใครก็ตามที่พยายามดูฐานข้อมูลโดยตรงจะมองดูซึ่งพูดไม่ชัด วิธีเดียวที่จะทำให้เกิดความเสียหายได้คือการผ่านการแย่งชิงเซสชัน แต่ฉันคิดว่าที่นี่จะมีความปลอดภัยเช่นกัน

— dagnelies
แหล่งที่มา

ผู้คนมักลืมรหัสผ่าน ... แล้วอะไรนะ?

— curiousguy

-1

ฉันถามตัวเองว่าทำไมลูกค้าถึงขอให้คุณเข้ารหัสฐานข้อมูล ถ้าเขาจะขอให้คุณปกป้องข้อมูลที่ฉันจะเห็นด้วย แต่เขามีการใช้งานโดยปริยายในใจ ดังนั้นตราบใดที่เขาไม่ทราบว่าสิ่งที่เขากำลังพูดเกี่ยวกับเขาเป็นเพียงการโยน buzzwords จากมุมมองของฉัน

ฉันก็พบว่ามันไม่มีประโยชน์ที่จะเข้ารหัสฐานข้อมูลเพราะฉันเชื่อว่าทุกอย่างแท้จริง DBMS ที่สำคัญคำนึงถึงความปลอดภัยอย่างเหมาะสมและอาจดีกว่าที่คุณจะทำได้ เพื่อที่จะเข้าถึงฐานข้อมูลผ่าน DBMS คุณจะต้องมีข้อมูลประจำตัว ในกรณีของฐานข้อมูลที่เข้ารหัสคุณจะต้องใช้ข้อมูลรับรองเหล่านั้นเช่นกันและเพื่อถอดรหัสข้อมูลที่คุณต้องการข้อมูลรับรองเหล่านั้นที่คุณมีอยู่แล้ว

ฉันขอเสนอให้ DBMS จัดการเรื่องความปลอดภัยและพยายามปกป้องข้อมูลประจำตัวตั้งแต่การป้อนข้อมูลของผู้ใช้ไปจนถึงการเข้าถึง db นอกจากนี้ยังอาจบังคับใช้รหัสผ่านที่คาดเดายากและการเปลี่ยนแปลงเป็นระยะ

— sschrass
แหล่งที่มา

... ทุก DBMS ที่สำคัญใช้เวลาบัญชี securityinto ... ยกเว้นเมื่อพวกเขาไม่ได้

— Jay Elston

คำถามแรกที่ผมจะต้องถามคือวิธีการที่พวกเขาทำและวิธีการที่จะเกิดความเสียหายได้รับการป้องกันโดยการเข้ารหัสฐานข้อมูล ฉันเพิ่งสแกนอย่างรวดเร็วผ่านบทความนี้ แต่ได้รับความประทับใจว่าพวกเขาอยู่ในความครอบครองของข้อมูลประจำตัว

— sschrass

ตรง - ข้อมูลประจำตัวฐานข้อมูลสามารถและจะได้รับการประนีประนอม ความท้าทายคือการออกแบบระบบเพื่อให้ผู้ใช้ที่ไม่ได้รับอนุญาตสามารถเข้าถึงข้อมูลประจำตัวได้พวกเขายังต้องใช้คีย์การเข้ารหัสเพิ่มเติมเพื่อให้สามารถเข้าถึงข้อมูลที่สำคัญได้ สำหรับข้อมูลด้านสุขภาพนี่มันซับซ้อนกว่ามาก ไม่ใช่ทุกคนที่สามารถเข้าถึงข้อมูลประจำตัวของฐานข้อมูลควรจะสามารถเข้าถึงข้อมูลที่สำคัญได้ เช่น DBA ไม่ควรอ่านข้อมูลผู้ป่วยในรูปแบบข้อความที่ชัดเจน คนเท่านั้นที่ควรอ่านข้อมูลนี้ได้คือผู้ป่วยและผู้ให้บริการ

— Jay Elston