Bảo vệ cơ sở dữ liệu SQL Server 2008R2

Question

Chúng tôi sẽ phát triển một ứng dụng ASP.NET. Nó sẽ lưu trữ dữ liệu trong một cài đặt SQL Server 2008 R2. Hầu hết các dữ liệu là nhạy cảm, vì vậy an ninh là một mối quan tâm chính.
Chúng tôi sẽ lưu trữ điều này trong một môi trường được chia sẻ và đó là mục tiêu thiết kế để dữ liệu không thể đọc được trong trường hợp trộm cắp.

Tôi đang nghĩ về các thiết lập sau: Mã hóa toàn bộ cơ sở dữ liệu bằng TDE. Người dùng được tạo trong bảng người dùng SQL Server và chúng tôi xác thực rằng khi người dùng đăng nhập thông qua giao diện web.
Mục đích là nếu ai đó truy cập vào cơ sở dữ liệu, họ sẽ không thể sử dụng dữ liệu. Và không có chuỗi kết nối nào với thông tin đăng nhập của người dùng sẽ cần được lưu trữ trong tệp web.config.

Bạn có thấy bất kỳ bất lợi nào đối với phương pháp này không? Và nó sẽ dễ dàng như thế nào để xác thực với SQL Server như được mô tả?

Answer 1

Tôi không nghĩ rằng bạn nên sử dụng TDE trong môi trường chia sẻ.

Toàn bộ ý tưởng của nó là làm cho mã hóa/giải mã TRANSPARENT thành người dùng bên ngoài bằng cách sử dụng khóa chính mã hóa (hoặc khóa riêng của chứng chỉ) trên INTERNAL của bạn, được bảo vệ bởi bạn, máy chủ và ngăn khôi phục cơ sở dữ liệu đã mã hóa máy chủ khác không có khóa đó. Nhưng máy chủ lưu trữ được chia sẻ không phải là máy chủ của bạn, bạn không thể kiểm soát quyền truy cập vào nó hoặc thậm chí, thường xuyên hơn, thậm chí thay đổi hoặc viết thư mục hệ thống/tệp hoặc cơ sở dữ liệu. Bạn nên tham khảo về nó với con hoster của bạn.
Nhưng nếu một khách hàng được chia sẻ lưu trữ sẽ được cấp một ngoại lệ thì sẽ có một trường hợp khác, tương ứng với quyền truy cập vào các chức năng và khu vực bị hạn chế của hệ thống thông thường.

Dù sao, bất kỳ ai trong hệ thống quản trị mạng hoặc nhân viên vòng xuyến sẽ có quyền truy cập vào cơ sở dữ liệu của bạn hoàn toàn bằng khóa chính để khôi phục và đọc trên máy chủ khác.

Sau đó, TDE là tính năng của Phiên bản Enterprise của SQL Server và việc chia sẻ lưu trữ thường cung cấp Express Editions. Không có nhiều ý nghĩa trong việc chia sẻ Enterprise Ed. máy chủ

Cập nhật: @ Martin Wiboe,
Tôi không chắc chắn rằng tôi làm theo những gì bạn đang đi vào và những gì bạn đang hỏi về.

Các khóa mã hóa cơ sở dữ liệu được mã hóa với khóa chính của dịch vụ (và khóa thứ hai được bảo vệ bởi Windows DPAPI) nhưng không có điểm nào trong môi trường được chia nhỏ này vì dữ liệu trong bộ nhớ và trên dây không được mã hóa và khóa dịch vụ chính là một ví dụ (máy chủ).
Vì vậy, nên chia sẻ giữa tất cả người dùng trên lưu trữ được chia sẻ.
Bạn không thể "khóa"/"mở khóa" vì nó là mã hóa dữ liệu TRANSPARENT!
Lưu ý rằng nếu một trong các cơ sở dữ liệu là TDE-ed thì cơ sở dữ liệu hệ thống tempdb được mã hóa. Điều này không có ý nghĩa nhiều cho việc chia sẻ lưu trữ.

1)
Khóa được tạo bằng phần mềm có thể bị crack, chỉ là vấn đề tồn tại/mong muốn so với ngưỡng thời gian. Bảo mật thực có thể được đảm bảo chỉ bằng các khóa phần cứng được tạo và phần cứng được lưu trữ. Vì vậy, chia sẻ lưu trữ được xem xét
2)
Bạn có thể muốn xem xét từ bỏ mã hóa DBMS và mã hóa dữ liệu ở phía máy khách.
Mặc dù phương pháp này có nhược điểm là bạn không thể sử dụng SQL Server để tìm kiếm, tối ưu hóa truyền, xử lý, v.v. ở phía máy chủ. Sau đó, điểm trong DBMS như thế nào?

Cuối cùng, điều này tất cả các boils xuống đến một thực tế là không có nhiều ý nghĩa trong việc sử dụng chung máy chủ lưu trữ

Answer 2

Chúng tôi sẽ phát triển một ứng dụng ASP.NET . Nó sẽ lưu trữ dữ liệu trong một cài đặt SQL Server 2008 R2 . Hầu hết các dữ liệu đều nhạy cảm, vì vậy bảo mật là mối quan tâm chính. Chúng tôi sẽ là lưu trữ điều này trong một môi trường được chia sẻ, và đó là mục tiêu thiết kế mà dữ liệu sẽ không thể đọc được trong trường hợp trộm cắp.

Ok, tôi đã ngừng cười ở đây. Về cơ bản bạn cố gắng làm món bít tết bò chay.

Bảo mật EITHER là mối quan tâm chính của bạn, sau đó bạn không nên sử dụng kịch bản lưu trữ được chia sẻ nhưng phải chạy trong trung tâm dữ liệu được chứng nhận trong giá bị khóa không có quyền truy cập quản lý của máy. Trong trường hợp này, bạn sẽ sử dụng phiên bản SQL Server cao hơn và sử dụng mã hóa đĩa + hệ thống an toàn (chip TPM) để đảm bảo sau khi bị đánh cắp dữ liệu không đọc được trên đĩa. Điểm.

Hoặc bảo mật không phải là mối lo ngại của bạn, bạn có thể sử dụng nhà cung cấp dịch vụ lưu trữ dùng chung.

Bất cứ điều gì khác là hogwash. Mức độ "không, lướt ván không phải là tra tấn bởi vì nó không gây ra thiệt hại vật chất" loại tranh luận.

Vấn đề của bạn là: bạn có thể KHÔNG LÀM để dừng quyền truy cập vào dữ liệu. Vì ứng dụng của bạn phải có khả năng đọc dữ liệu không được mã hóa và do đó có quyền truy cập vào khóa được sử dụng mã hóa tp ... bất kỳ ai xâm nhập vào ứng dụng của bạn đều có quyền truy cập vào khóa (đó là lý do tại sao TPM rất đẹp - đây là phần cứng an toàn, không có cách nào để có quyền truy cập vào các phím).

Bạn có thể chơi xung quanh thực tế này, với tất cả các loại đối số vui nhộn, nhưng nếu dữ liệu bị đánh cắp, các đối số sẽ KHÔNG giữ trong bất kỳ cuộc thảo luận pháp lý nào. Và bạn sẽ nhìn xấu trên đầu trang này.

Người dùng được tạo ra trong SQL Server bảng người dùng, và chúng tôi xác thực so với khi người dùng đăng nhập thông qua giao diện web. Mục đích là rằng nếu ai đó truy cập vào cơ sở dữ liệu, họ sẽ không thể sử dụng dữ liệu. Và không có chuỗi kết nối nào với thông tin người dùng cần phải được lưu trữ trong tệp web.config.

Ok, vì vậy - tôi lấy cắp cơ sở dữ liệu. Tôi cũng ăn cắp cơ chế xác thực của bạn. Chính xác những gì bạn đạt được? Bên cạnh việc giết chết chức năng tìm kiếm của bạn? Khi tôi ahve cơ sở dữ liệu iH ave bảng người dùng và tôi bằng cách nào đó có thể xác thực là người dùng. Nếu tôi cũng ăn cắp các ứng dụng tôi có được prettym uch tất cả mọi thứ, ngay cả mã.

KHÔNG BAO GIỜ bạn có trường hợp đặc biệt mà bạn không có khóa ứng dụng (những thứ như LastPass không biết cách giải mã dữ liệu của bạn ở phía máy chủ). Môi trường lưu trữ được chia sẻ chỉ không có mức phần cứng phù hợp cho việc này.

Answer 3

Đây là mối quan tâm rõ ràng.Ứng dụng của bạn cần có khả năng đọc và hiểu dữ liệu. Do đó, nếu ai đó có thể gây rối với ứng dụng của bạn (ngửi thông tin liên lạc của nó, dịch ngược nó và vv), anh ta có thể truy cập cơ sở dữ liệu bằng cách sử dụng cùng một cách.
Ngay cả khi bạn sử dụng một số bộ nhớ ngoài cho dữ liệu chính (như API bảo vệ dữ liệu của Windows), bạn vẫn cần phải xác thực bộ nhớ này bằng cách nào đó. Do đó, nếu bất kỳ ai có thể kiểm soát cơ chế xác thực (ví dụ, tên miền Windows), có thể có cùng quyền truy cập. Về cơ bản, nếu một đối thủ có toàn quyền kiểm soát môi trường (và họ làm gì nếu bạn sử dụng một máy chủ chia sẻ và cố gắng bảo vệ dữ liệu của bạn từ nhân viên của họ), bạn không thể ngăn họ làm bất cứ điều gì họ muốn.

Dưới đây là một số tổng quan tốt về mã hóa trong SQL Server: Understanding Transparent Data Encryption (TDE), Encryption Hierarchy. Trong mọi trường hợp, bạn vẫn cần một cách để lưu trữ "khóa khởi động tối thượng" không thể tiếp cận được với đối thủ của bạn, nhưng stil có thể sử dụng khóa này trong ứng dụng của bạn.