Cách tách dữ liệu nhạy cảm trong cơ sở dữ liệu (MySql)

Tôi cần thiết kế một cơ sở dữ liệu sẽ chứa thông tin về bệnh cá nhân của người dùng.

Điều gì có thể là cách tiếp cận để thực hiện các cột trong bảng của DB: mã hóa thông tin, tách dữ liệu trong hai khác biệt DB, một cho dữ liệu nhạy cảm và một cho dữ liệu không nhạy cảm hoặc cả hai hoặc một cách tiếp cận khác?

Bạn có thể mã hóa dữ liệu bằng một khóa được lưu trữ trong ứng dụng web của mình để dữ liệu được ghi / đọc từ db ở dạng được mã hóa. Tuy nhiên, bất kỳ ai có quyền truy cập vào mã sẽ có quyền truy cập vào khóa và với khóa đó là dữ liệu không được mã hóa. Điều này giải quyết yêu cầu

dba không thể xem thông tin về bệnh của người sử dụng cơ sở dữ liệu.

Theo như sử dụng để phân tách cơ sở dữ liệu tôi không nghĩ rằng đó là cần thiết. Bạn đang lưu trữ dữ liệu được mã hóa và sử dụng quyền của cơ sở dữ liệu bởi người dùng, bảng (nếu điều đó thậm chí cần thiết) sẽ là quá đủ. Tôi nghĩ rằng DB thêm vào một lớp phức tạp mà không cần nhiều thứ khác. Trừ khi nó ở một vị trí khác, thì nó có thể có một cải tiến NHỎ từ một hệ thống cơ sở dữ liệu duy nhất.

Câu trả lời của Ominus giải quyết câu hỏi đầu tiên của bạn. Câu trả lời cho câu hỏi thứ hai có thể yêu cầu thêm chi tiết về ứng dụng của bạn.

Một cách tiếp cận khác với bảo mật thậm chí còn lớn hơn nếu bệnh nhân phải truy cập cơ sở dữ liệu có thể có một cơ sở dữ liệu riêng cho mỗi người dùng. Trong phương pháp này, bạn có thể sử dụng một khung cung cấp chức năng nhiều cơ sở dữ liệu cho nhiều bên thuê. Tuy nhiên, vấn đề là nếu bạn có người dùng ứng dụng riêng biệt và người dùng cơ sở dữ liệu riêng biệt, việc đồng bộ hóa những người dùng này sẽ vô cùng khó khăn. Tôi đoán rằng bệnh nhân không cần phải truy cập cơ sở dữ liệu của bạn mặc dù. Nếu họ cần, có thể an toàn nhất để có khóa cho mỗi người dùng.

Ngoài các yêu cầu về pháp lý hoặc hợp đồng, một số lý do khác mà tôi có thể nghĩ đến để có cơ sở dữ liệu riêng biệt là: nhận thức của khách hàng về bảo mật tăng lên khiến việc bán hàng trở nên dễ dàng hơn, lo lắng về việc mã hóa bị phá vỡ và lo lắng về (các) khóa bị xâm phạm.

Về phần câu trả lời của Briddmus, trong đó anh ta nói rằng "bạn cần mã hóa nhiều hơn chỉ là thông tin y tế": điều này chỉ đúng nếu mọi người trong cơ sở dữ liệu có tình trạng y tế. (Tôi đoán đây là trường hợp).

Lưu ý: các phần của câu trả lời này sẽ phù hợp hơn với tư cách là nhận xét nhưng tôi chưa có đủ đại diện để đăng nhận xét tại đây.

Đối với loại ứng dụng này, bạn cần suy nghĩ về việc ai sẽ được phép truy cập dữ liệu. Với thông tin y tế, tôi nghĩ rằng nó có thể bị hạn chế đối với người dùng đã nhập và bất kỳ ai mà họ cho phép xem.

Để ngăn DBA xem dữ liệu, bạn sẽ phải mã hóa nó bằng mã mà DBA không có quyền truy cập.

Bạn cũng cần mã hóa thông tin theo cách mà lập trình viên ứng dụng không thể truy cập được. Không có điểm nào trong việc mã hóa thông tin từ DBA nếu lập trình viên có thể đăng nhập như bất kỳ người dùng nào.

Bạn cũng không muốn mã hóa tất cả dữ liệu với cùng một mã. Phần mềm có thể có lỗi hiển thị thông tin của người dùng này. Vì vậy, có lẽ tốt nhất là mã hóa từng dữ liệu người dùng bằng một mã cụ thể cho người dùng đó.

Điều quan trọng cần lưu ý là bạn cần mã hóa nhiều hơn là thông tin y tế; với tư cách là người dùng cuối, tôi sẽ không muốn DBA của bạn biết rằng tôi có tình trạng y tế, chứ đừng nói đến đó là gì. Vì vậy, bạn cũng cần mã hóa mọi thông tin nhận dạng cá nhân về người dùng. Điều này bao gồm những thứ như:

• Tên
• ngày sinh
• địa chỉ email
• tình dục
• Địa chỉ