Cách bảo vệ tệp nhật ký và dữ liệu chuẩn của máy chủ SQL nhạy cảm (HIPAA)


11

Tôi đang xử lý thông tin sức khỏe được bảo vệ bằng điện tử (ePHI hoặc PHI) và các quy định của HIPAA yêu cầu chỉ những người dùng được ủy quyền mới có thể truy cập ePHI. Mã hóa cấp cột có thể có giá trị đối với một số dữ liệu, nhưng tôi cần khả năng thực hiện như tìm kiếm trên một số trường PHI như tên.

Mã hóa dữ liệu trong suốt (TDE) là một tính năng của SQL Server 2008 để mã hóa các tệp nhật ký và cơ sở dữ liệu. Theo tôi hiểu, điều này ngăn người nào đó có quyền truy cập vào các tệp MDF, LDF hoặc sao lưu không thể làm bất cứ điều gì với các tệp vì chúng được mã hóa. TDE chỉ có trên phiên bản doanh nghiệp và nhà phát triển của SQL Server và doanh nghiệp bị cấm chi phí cho kịch bản cụ thể của tôi. Làm cách nào tôi có thể có được sự bảo vệ tương tự trên SQL Server Standard? Có cách nào để mã hóa cơ sở dữ liệu và các tập tin sao lưu (có công cụ của bên thứ ba) không? Hoặc cũng tốt như vậy, có cách nào để ngăn chặn các tệp được sử dụng nếu đĩa được gắn vào máy khác (linux hoặc windows) không?

Quản trị viên truy cập vào các tệp từ cùng một máy là tốt, nhưng tôi chỉ muốn ngăn chặn mọi sự cố nếu đĩa bị xóa và được nối với máy khác. Một số giải pháp cho việc này là gì?


4
BitLocker và Least Privilidge ACLs là đủ cho HIPPA (tại thời điểm viết bài này). Bạn có thể muốn các điều khiển nâng cao hơn, nhưng không yêu cầu mã hóa cấp độ tế bào nếu các điều khiển truy cập được cấu hình đúng. (Lời khuyên chung được đưa ra mà không có kiến ​​thức chi tiết về môi trường của bạn và không ngụ ý bồi thường). Trên một lưu ý nghiêm trọng hơn; nếu bạn không biết bảo mật SQL, vui lòng không phải là người duy nhất định cấu hình bảo mật ePHI, hãy nhờ ai đó thực sự biết công cụ của họ.
Chris S

@Chris s, Cảm ơn nhiều. Tôi đã nghe nói về BitLocker, nhưng không biết nó là gì. Bây giờ tôi làm và đó là những gì tôi đang tìm kiếm.
Quesi

Câu trả lời:


8

Gợi ý chung cho HIPAA là tuân theo Tiêu chuẩn bảo mật dữ liệu PCI (PCI-DSS), ngoại trừ mọi nơi họ nói "Thông tin chủ thẻ" hoặc "Thông tin tài khoản" mà bạn nói "PHI". Công ty của tôi (ngành chăm sóc sức khỏe, giao dịch với PHI) sử dụng PCI-DSS làm điểm khởi đầu chính của chúng tôi, cùng với một liều thuốc thông thường (ví dụ: đảm bảo dữ liệu STAYS được mã hóa (hoặc giới hạn trong các mạng an toàn) mọi lúc).

Một số loại mã hóa cấp cột hầu như luôn luôn là một ý tưởng tốt khi xử lý dữ liệu nhạy cảm và với chi phí tiềm năng của một vụ kiện, nó sẽ có nhiều điều cần xem xét.


Mặc dù tôi thích nhận xét về câu hỏi của mình để sử dụng BitLocker làm câu trả lời, anh ấy đã không đăng nó dưới dạng anwer vì vậy tôi đánh dấu câu hỏi của bạn vì bạn đã chỉ cho tôi một tài liệu tuyệt vời với nhiều thông tin hơn về chủ đề này. Mặc dù mã hóa ở mức cột sẽ là một ý tưởng tốt, nhưng nó không thực tế trong mọi trường hợp như khi bạn cần tìm kiếm trên đó.
Quesi

3

Bạn cần bảo vệ PHI sẽ yêu cầu bạn mã hóa dữ liệu trong bảng cơ sở dữ liệu. Mã hóa dữ liệu trong cấp độ cột nếu đặt cược tốt nhất của bạn. Tìm kiếm trên các lĩnh vực này sẽ tốn kém, nhưng đó là chi phí bảo mật cao.

Tôi nói về một loạt các tùy chọn mã hóa dữ liệu trong chương 2 của cuốn sách " Bảo mật máy chủ SQL " của tôi


Thậm chí có thể tìm kiếm trên các trường được mã hóa bằng truy vấn "thích" không?
Quesi

Chắc chắn, bạn phải giải mã toàn bộ cột, tìm kiếm nó sau đó trả về các hàng cần thiết.
mrdenny

giải mã toàn bộ cột. yike! Đó là những gì bạn có nghĩa là "đắt tiền".
Quesi

1
Đúng, an ninh không được thực hiện để làm cho cuộc sống dễ dàng. Bảo mật dữ liệu là xem xét đầu tiên, dễ dàng truy cập dữ liệu là thứ hai. Nếu có thể khi làm cho dữ liệu có thể tìm kiếm được, bạn có thể băm dữ liệu và lưu trữ hàm băm vì băm dễ tìm kiếm hơn dữ liệu được mã hóa. Mặc dù cả hai sẽ không hoạt động tốt để sử dụng THÍCH. Nếu bạn không mã hóa PHI và bạn có tỷ lệ cược được kiểm toán thì bạn sẽ không thực hiện kiểm toán.
mrdenny
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.