Tôi có nên mã hóa dữ liệu trong cơ sở dữ liệu?


16

Tôi có một khách hàng, trong đó tôi sẽ làm một ứng dụng Web về chăm sóc bệnh nhân, quản lý bệnh nhân, tư vấn, lịch sử, lịch, tất cả mọi thứ về cơ bản.

Vấn đề là đây là dữ liệu nhạy cảm, lịch sử bệnh nhân và như vậy.

Máy khách khăng khăng mã hóa dữ liệu ở cấp cơ sở dữ liệu, nhưng tôi nghĩ rằng điều này sẽ làm giảm hiệu suất của ứng dụng web. (Nhưng có lẽ tôi không nên lo lắng về điều này)

Tôi đã đọc luật về bảo vệ dữ liệu về các vấn đề sức khỏe (Bồ Đào Nha), nhưng không cụ thể về vấn đề này (tôi chỉ hỏi họ về vấn đề này, tôi đang chờ phản hồi của họ).

Tôi đã đọc liên kết sau , nhưng câu hỏi của tôi thì khác, tôi có nên mã hóa dữ liệu trong cơ sở dữ liệu hay không.

Một vấn đề mà tôi thấy trước khi mã hóa dữ liệu, đó là tôi sẽ cần một khóa, đây có thể là mật khẩu người dùng, nhưng tất cả chúng ta đều biết mật khẩu người dùng như thế nào (12345, v.v.) và tạo khóa tôi sẽ phải lưu trữ Nó ở đâu đó, điều này có nghĩa là lập trình viên, dba, bất cứ điều gì có thể có quyền truy cập vào nó, bất kỳ suy nghĩ về điều này?

Ngay cả việc thêm một loại muối ngẫu nhiên vào mật khẩu người dùng cũng sẽ không giải quyết được vấn đề vì tôi luôn có thể truy cập nó và do đó giải mã dữ liệu.


1
Tôi là một nhà phát triển phía khách hàng, nhưng tôi nghi ngờ việc mã hóa mọi thứ thực sự sẽ làm cho dữ liệu ít hơn, không an toàn hơn nếu bạn sử dụng cùng một khóa.
Erik Reppen

4
bạn có thể đặt toàn bộ cơ sở dữ liệu trên một ổ đĩa được mã hóa và gọi nó là một ngày. Chắc chắn việc đọc / ghi sẽ chậm hơn, nhưng bạn giữ tất cả lợi thế của RDMS (hoặc bất cứ điều gì bạn đang sử dụng), trong khi dữ liệu trên đĩa được mã hóa
DXM

2
Điều đó cũng có nghĩa là bạn sẽ không thể nhìn thấy dữ liệu trong bàn làm việc của mysql? Tất cả tốt nhất để gỡ lỗi.
Manoj R

4
Y tế là một ngành công nghiệp quy định cao. Các chuyên gia làm việc ở đó được sử dụng để có ai đó nói cho họ biết các quy tắc là gì. Tư duy này lều để tràn vào các dự án CNTT. Nó không thực sự là một vấn đề bảo mật. Đó là một vấn đề văn hóa. Chi phí kinh doanh trong lĩnh vực y tế.
Phản ứng

1
Một bệnh viện ở Anh đã bị phạt hơn 300.000 bảng vì các ổ đĩa bị lạc hướng chứa cơ sở dữ liệu không được mã hóa. Thông tin sức khỏe rất nhạy cảm.
MarkJ

Câu trả lời:


9

Cá nhân tôi sẽ kiểm tra các luật về điều này. Nếu dữ liệu cần được mã hóa, thì nó cần được mã hóa.

Nếu bạn không nhận được bất kỳ hướng dẫn nào, tôi sẽ hướng đến việc bảo vệ liên kết giữa bệnh nhân và dữ liệu của họ. Tức là bạn rất có thể có một PatientIDcái được sử dụng trong các bảng trong toàn bộ cơ sở dữ liệu. PatientIDkhông xác định được bệnh nhân, chỉ có tiền sử bệnh án của bệnh nhân, v.v ... Tuy nhiên, để xác định được PatientIDJoe Bloggs sống tại Rua de São Bernardo Lisbon, tôi sẽ giữ điều này trong một DB riêng nếu tôi có thể. Sử dụng TDE cho các chi tiết cá nhân của bệnh nhân và xem xét mã hóa nó trên đầu trang bằng cách sử dụng các khóa trong ứng dụng web của bạn.

Trong khi việc đánh cắp dữ liệu y tế mà không có phương tiện để xác định bệnh nhân sẽ vô cùng xấu hổ, không chắc là có gì khác ngoài điều đó. Có những cuộc thi trực tuyến theo nghĩa đen sử dụng dữ liệu y tế ẩn danh này.

Với việc tách dữ liệu y tế khỏi các chi tiết cá nhân của bệnh nhân. Sử dụng một bộ vai trò mạnh mẽ để giới hạn nhân viên chỉ những gì họ cần. Ngoại trừ nhân viên y tế yêu cầu phải đối phó trực tiếp với bệnh nhân (y tá & bác sĩ tuyến đầu), không ai nên có quyền truy cập vào cả hai. Nhân viên tiếp tân chỉ cần thông tin cá nhân của Bệnh nhân, nhân viên phòng thí nghiệm chỉ cần hồ sơ y tế và PatientID, y tá phẫu thuật chỉ hiện tình trạng y tế và tên.

Khi bạn đã xác định từng nhóm vai trò, hãy nhắm đến việc không chỉ triển khai chúng trong ứng dụng web của bạn mà còn trong cơ sở dữ liệu cũng như một lớp bảo mật bổ sung.


1
IANAL, nhưng cư sĩ IMO không nên "kiểm tra luật pháp" khi trách nhiệm pháp lý có thể lớn. Họ nên tham khảo ý kiến ​​một luật sư.
kevin cline

Tôi đi theo cách tiếp cận này như một câu trả lời thực sự .. hồ sơ y tế không liên quan đến bệnh nhân cũng như bác sĩ là vô nghĩa và không thể sử dụng được ngay cả khi phân tích thống kê vì nó không có tài liệu tham khảo cũng không chứng minh rằng nó không được tạo ra.
Zalaboza

13

Có, bạn nên mã hóa cơ sở dữ liệu.

Mã hóa cơ bản cho dữ liệu được lưu trữ ("dữ liệu khi nghỉ ngơi") là Nguyên tắc bảo mật được chấp nhận chung và có thể được pháp luật bắt buộc nếu quốc gia của bạn có luật bảo vệ thông tin cá nhân hoặc sức khỏe.

Chúng tôi đang sử dụng SQL Server 2008, vì vậy chúng tôi sử dụng TDE của Microsoft; có thể có một số giải pháp của bên thứ ba cho MySQL hoặc có lẽ chỉ là cách tiếp cận mã hóa khối lượng chung (như TrueCrypt) sẽ hoạt động (mặc dù tôi muốn có một cái gì đó đã được chứng nhận để sử dụng với cơ sở dữ liệu).

Nếu được thực hiện đúng, hiệu suất nhấn phải nhỏ.

Nhân tiện, liên kết bạn đã đề cập (liên quan đến việc tách thông tin nhạy cảm) là điều mà bạn nên xem xét trên đầu mã hóa cơ sở dữ liệu cơ bản.

EDIT: Mã hóa được đề cập ở trên sẽ mã hóa âm lượng. Nếu ai đó đánh cắp ổ cứng, họ sẽ tìm thấy dữ liệu được mã hóa. Tuy nhiên, nếu ai đó chạy các truy vấn trên cơ sở dữ liệu, họ sẽ thấy dữ liệu không được mã hóa (đó là lý do tại sao tôi đề cập đến việc phân tách thông tin, mặc dù OP không muốn thảo luận về điều này).

Lưu ý rằng đề xuất này có nghĩa là tối thiểu mà bạn nên làm. Nếu bạn muốn tư vấn pháp lý, tất nhiên bạn sẽ cần phải tìm nơi khác. Nếu bạn muốn thảo luận kỹ hơn về việc viết mã bảo mật, tôi sẽ bắt đầu với cuốn sách Viết mã bảo mật .


2
Tôi không chắc chắn nếu đây là trường hợp. Câu hỏi không phải là về việc mã hóa cơ sở dữ liệu, mà là về việc mã hóa dữ liệu trong cơ sở dữ liệu. Điều đó có nghĩa là dữ liệu trong các truy vấn sql sẽ được mã hóa.
Manoj R

1
Các hit hiệu suất nên nhỏ? Tìm kiếm trên dữ liệu sẽ được SLOW. Toàn bộ khái niệm lập chỉ mục không hoạt động khi dữ liệu được mã hóa. Nó sẽ yêu cầu quét toàn bộ bảng.
mike30

@mike Cách tiếp cận ở trên sẽ mã hóa âm lượng và sẽ không ảnh hưởng đến việc lập chỉ mục, v.v.
jdigital

IMO bạn cần nhiều chuyên môn hơn bạn có thể nhận được ở đây. IANAL, nhưng tôi nghĩ rằng khách hàng của bạn có độ phơi sáng khá cao nếu dữ liệu này bị xâm phạm.
kevin cline

8

Trước khi quyết định các vấn đề bảo mật như vậy, bạn nên đánh giá mô hình mối đe dọa. Nếu không có ý tưởng về những gì bạn đang bảo vệ chống lại, bất kỳ biện pháp nào bạn thực hiện có thể sẽ không có giá trị.

Bây giờ, có một vài điều bạn có thể lo lắng trong bối cảnh này:

  • Kẻ tấn công giành quyền truy cập vật lý vào dữ liệu của bạn (ví dụ: đột nhập vào trung tâm dữ liệu, đánh cắp băng sao lưu, v.v.)
  • Kẻ tấn công giành quyền truy cập đọc vào cơ sở dữ liệu thô của bạn
  • Những kẻ tấn công xâm phạm ứng dụng của bạn, ví dụ như thông qua SQL, tràn bộ đệm, v.v.

Đối với kịch bản đầu tiên, việc lưu trữ cơ sở dữ liệu và tất cả các bản sao lưu trên các khối được mã hóa sẽ hoạt động, miễn là máy chủ không đầu - ăn cắp máy chủ hoặc các băng sau đó sẽ yêu cầu phá vỡ mã hóa cấp đĩa.

Đối với kịch bản thứ hai, mã hóa dữ liệu cơ sở dữ liệu sẽ giúp ích, nhưng chỉ khi bạn không lưu trữ các khóa hoặc cụm mật khẩu cần thiết ở bất cứ đâu.

Trong kịch bản thứ ba, mọi thứ phụ thuộc vào bối cảnh cuộc tấn công xảy ra: ví dụ, nếu đó là một cuộc tấn công XSS hoặc CSRF, thì kẻ tấn công có thể làm bất cứ điều gì người dùng hợp pháp có thể và mã hóa dữ liệu của bạn hoàn toàn không giúp ích gì .

Do đó, mô hình mối đe dọa của bạn là kẻ tấn công giành quyền truy cập đọc vào cơ sở dữ liệu thô, bằng cách tìm thông tin đăng nhập và quản lý để đăng nhập vào máy chủ cơ sở dữ liệu từ bên ngoài hoặc bằng cách truy cập root vào máy chủ cơ sở dữ liệu. Một đường dẫn điển hình là đầu tiên đạt được quyền truy cập shell trên máy chủ web; từ đó, kẻ tấn công có thể đọc thông tin đăng nhập từ tệp cấu hình và kết nối với cơ sở dữ liệu.

Một xem xét bổ sung là nơi bạn giữ các khóa và cụm mật khẩu, đặc biệt nếu bạn đang sử dụng một nền tảng với mô hình thực thi không trạng thái như PHP. Lý tưởng nhất là bạn có khách hàng nhập cụm mật khẩu của họ khi được yêu cầu và chỉ giữ nó trong bộ nhớ, hoặc thậm chí tốt hơn, thực hiện phía máy khách giải mã (nhưng điều này thường không khả thi). Trên nền tảng không trạng thái, trạng thái thường được mang theo bằng cách sử dụng phiên, memcache, cơ sở dữ liệu hoặc tệp phẳng; nhưng tất cả những thứ này dễ bị tổn thương hơn nhiều so với việc giữ trạng thái trong bộ nhớ riêng của ứng dụng web. Tránh đây là vấn đề trứng gà, bởi vì nếu bạn mã hóa trạng thái trước khi duy trì nó, bạn chỉ cần tạo một bí mật khác mà bạn phải nhớ một cách an toàn. Ghi nhớ cụm mật khẩu trên máy khách và gửi nó cùng với mỗi yêu cầu cần nó có thể là giải pháp ít kinh khủng nhất sau đó;


2
+1: không có mô hình mối đe dọa, rất có thể bạn sẽ khóa cửa trước nhưng để cửa sau mở rộng.
kevin cline

8

Bỏ qua một lúc những gì khách hàng đang yêu cầu, và bất kể luật pháp là gì ...

Không, có lẽ bạn không nên mã hóa dữ liệu. Nếu bạn làm như vậy, bạn sẽ không thể dễ dàng tìm kiếm nó. Ví dụ: bạn sẽ tìm kiếm họ như thế nào like 'Smith%'nếu mỗi mục nhập tên được mã hóa? Làm thế nào bạn có thể vẽ biểu đồ huyết áp của bệnh nhân theo thời gian nếu bạn không thể select .... from.... where patient_id = N?

Rõ ràng, bạn nên đảm bảo rằng máy chủ được bảo mật đúng cách, kết nối mạng được bảo mật và giao diện người dùng được bảo mật đúng cách (bao gồm cả thời gian chờ phiên để người dùng không thể rời khỏi quyền truy cập vào bất kỳ ai sử dụng máy tính của họ). Bạn cũng có thể muốn mã hóa sao lưu cơ sở dữ liệu. Và bảo mật về mặt vật lý cho phòng máy chủ được đặt. Nhưng tôi sẽ không mã hóa dữ liệu trực tiếp.

Làm rõ: Đây là giả định những gì OP đã hỏi về việc thực sự mã hóa dữ liệu trong cơ sở dữ liệu. Không phải hệ thống tập tin cơ sở dữ liệu cư trú trên.


hoàn toàn đồng ý, nhưng LUẬT không :(
Zalaboza

1
Vâng, bạn có thể AES_DESCRYPT('') LIKE 'Smith%'mặc dù rất chậm. Hoặc bạn có thể trở nên căng thẳng và tạo ra một chỉ số đảo ngược với băm muối
foochow

1

Nếu bạn phát triển ứng dụng web một cách cẩn thận bằng cách sử dụng khung MVC hiệu quả như CakePHP. Zend hoặc Rails, sau đó bạn sẽ có thể bật / tắt mã hóa ở cấp độ Modal dữ liệu.

Ví dụ như CakePHP có một vài ví dụ về Hành vi cho Modal mã hóa dữ liệu. Làm cho quá trình minh bạch cho Bộ điều khiển và Chế độ xem.

Bỏ qua các vấn đề về lập chỉ mục và các vấn đề cơ sở dữ liệu kỹ thuật khác khi làm điều này. Nó có thể có thể là một tùy chọn cấu hình.

Ngoài ra, tôi sẽ bật mã hóa vào một thời gian sau hoặc chỉ trên máy chủ sản xuất. Dữ liệu được mã hóa rất khó để gỡ lỗi và hoạt động trong khi phát triển và chỉ có thể được thực hiện trên các cột nhất định.


1

Có, bạn nên mã hóa cơ sở dữ liệu.

Vì đây là thông tin cá nhân và nhạy cảm, tôi chắc chắn tin rằng nó nên.

Từ mật khẩu, bạn có thể lấy được khóa mã hóa mà bạn chỉ lưu trữ cho phiên. Theo cách đó, nó không được lưu trữ ở bất cứ đâu và không ai (kể cả DBA) có thể biết nó vì không ai có thể biết mật khẩu. Bất cứ ai cố gắng xem DB trực tiếp sẽ nhìn vào vô nghĩa. Cách duy nhất để làm hỏng điều này là thông qua việc chiếm quyền điều khiển phiên nhưng tôi cho rằng ở đây các phiên cũng an toàn.


Mọi người rất hay quên mật khẩu của họ ... sau đó thì sao?
tò mò

-1

Tôi tự hỏi tại sao khách hàng yêu cầu bạn mã hóa DB? Nếu anh ta yêu cầu bạn bảo vệ dữ liệu tôi sẽ đồng ý, nhưng anh ta đã có sẵn một triển khai ngầm. Vì vậy, miễn là anh ta không biết chính xác những gì anh ta đang nói về anh ta chỉ đang ném buzzwords theo quan điểm của tôi.

Tôi cũng thấy rất vô dụng khi mã hóa DB, bởi vì tôi tin rằng theo nghĩa đen, mọi DBMS chính đều bảo mật một cách thích hợp và có thể tốt hơn bạn có thể. Để truy cập DB thông qua DBMS, bạn sẽ cần thông tin đăng nhập. Trong trường hợp DB được mã hóa, bạn sẽ cần những thông tin xác thực đó và để giải mã dữ liệu bạn sẽ cần những thông tin mà bạn dường như đã có.

Theo suy nghĩ này, tôi đề xuất để DBMS xử lý bảo mật và nỗ lực bảo vệ thông tin đăng nhập từ đầu vào của người dùng đến truy cập db, cũng có thể thực thi mật khẩu mạnh và thay đổi định kỳ.


... mọi DBMS chính đều có tài khoản securityinto ... trừ khi họ không làm như vậy .
Jay Elston

Câu hỏi đầu tiên tôi sẽ phải hỏi là làm thế nào họ làm điều đó và làm thế nào để ngăn chặn thiệt hại bằng cách mã hóa db. Tôi chỉ quét nhanh qua bài viết này, nhưng có ấn tượng rằng họ đang sở hữu thông tin đăng nhập.
sschrass

Chính xác - Thông tin DB có thể và bị xâm phạm. Thách thức là thiết kế hệ thống sao cho ngay cả khi người dùng trái phép có quyền truy cập vào thông tin đăng nhập, họ vẫn cần thêm khóa mã hóa để có thể truy cập dữ liệu nhạy cảm. Đối với thông tin sức khỏe, điều này thậm chí còn phức tạp hơn. Không phải tất cả mọi người có quyền truy cập vào thông tin đăng nhập DB đều có thể truy cập dữ liệu nhạy cảm. Ví dụ, DBA không thể đọc dữ liệu bệnh nhân bằng văn bản rõ ràng. Những người duy nhất có thể đọc được dữ liệu này là bệnh nhân và nhà cung cấp của họ.
Jay Elston
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.