Có an toàn hơn không khi đi qua cơ sở dữ liệu thứ 3 để kết nối hai cơ sở dữ liệu bằng cùng một thông tin đăng nhập?

Chúng tôi có các thiết lập sau:

• Nhiều cơ sở dữ liệu sản xuất chứa dữ liệu riêng tư được sử dụng bởi phần mềm máy tính để bàn
• Cơ sở dữ liệu web cho một trang web công cộng cần một số dữ liệu từ cơ sở dữ liệu riêng tư
• Một cơ sở dữ liệu trung gian chứa một vài khung nhìn và các thủ tục được lưu trữ để lấy dữ liệu từ cơ sở dữ liệu riêng

Hiện tại trang web đăng nhập vào cơ sở dữ liệu web và cơ sở dữ liệu web kết nối với cơ sở dữ liệu trung gian để lấy dữ liệu hoặc thực hiện các quy trình được lưu trữ trên cơ sở dữ liệu sản xuất. Tất cả các cơ sở dữ liệu trên cùng một phiên bản SQL và toàn bộ quá trình sử dụng cùng một tài khoản người dùng.

Tài khoản người dùng có toàn quyền truy cập vào cơ sở dữ liệu web và cơ sở dữ liệu trung gian, nhưng chỉ có thể truy cập vào các chế độ xem cụ thể và các thủ tục được lưu trữ và cơ sở dữ liệu riêng tư

Điều này có thực sự an toàn hơn là chỉ làm cho cơ sở dữ liệu công cộng kết nối trực tiếp với những người riêng tư?

Có vẻ như cơ sở dữ liệu trung gian chỉ ở đó để làm phức tạp mọi thứ vì cùng một thông tin đăng nhập được sử dụng để truy cập dữ liệu trong tất cả các cơ sở dữ liệu và nó chỉ giới hạn ở các chế độ xem / SP cần trong cơ sở dữ liệu riêng. Tôi hy vọng loại bỏ nó.

Một điều nhảy ra ở đây:

Toàn bộ quá trình sử dụng cùng một bộ thông tin đăng nhập

Vấn đề

Vì vậy, userX giả định (cho dù một số meatsack sử dụng Excel hoặc IIS AppPool Identity) có thể thấy một số chế độ xem và mã. Việc các khung nhìn và mã này nằm trong cơ sở dữ liệu nào không quan trọng vì dù sao userX cũng được thiết lập trong 3 cơ sở dữ liệu.

Tuy nhiên, bạn mất quyền sở hữu chuỗi như thế này.

Hãy nói WebDB.dbo.SomeProccuộc gọi PrivateDB.dbo.SomeTable. UserX yêu cầu quyền trên cả hai đối tượng. Nếu điều này được OneDB.WebGUI.SomeProcsử dụng OneDB.dbo.SomeTablethì chỉ có OneDB.WebGUI.SomeProcquyền cần thiết. Quyền đối với các đối tượng được tham chiếu với cùng một chủ sở hữu không được kiểm tra.

Lưu ý: Tôi đã không nhìn quá sâu vào chuỗi sở hữu cơ sở dữ liệu chéo . Tôi chỉ biết đồng bằng cũ "sở hữu chaining" tốt

Bây giờ, theo nhận xét, bạn thực sự có 2 cơ sở dữ liệu có thể được kết hợp. Không phải 3 mà ban đầu được ngụ ý. Tuy nhiên, các trung gian và web có thể được kết hợp.

Các cơ sở dữ liệu "riêng tư" khác có thể được kết hợp, nhưng đó sẽ là một vấn đề riêng biệt. Xem liên kết dưới cùng để thảo luận đầy đủ hơn về "một cơ sở dữ liệu hoặc nhiều"

Dung dịch?

Nếu các cơ sở dữ liệu bổ sung chỉ là các thùng chứa mã, thì các lược đồ là một ý tưởng tốt hơn.

Điều này có vẻ như bạn đã sử dụng "Cơ sở dữ liệu" trong đó bạn nên sử dụng "Lược đồ" (theo nghĩa của Máy chủ SQL, không phải ý nghĩa của MySQL). Tôi có lược đồ WebGUI, lược đồ trợ giúp hoặc chung (để thay thế cơ sở dữ liệu trung gian) và lược đồ máy tính để bàn. Bằng cách này, bạn tách các quyền dựa trên máy khách và chỉ có một cơ sở dữ liệu

Với một cơ sở dữ liệu (ngoài "chuỗi sở hữu"), bạn cũng có thể bắt đầu xem xét các chế độ xem được lập chỉ mục, SCHEMABINDING (tôi luôn sử dụng nó) và không thể thực hiện được với các cơ sở dữ liệu riêng biệt

Để biết thêm về các lược đồ, xem những câu hỏi sau:

• Thiết kế lược đồ - thực hành tốt nhất?
• Sử dụng quá mức / sử dụng đúng các lược đồ?

Cuối cùng, không có lý do gì để có cơ sở dữ liệu riêng biệt dựa trên "tính toàn vẹn giao dịch không bắt buộc". Xem câu hỏi này để giải thích điều này: Tiêu chí quyết định khi nào nên sử dụng lược đồ không dbo so với Cơ sở dữ liệu mới

Câu trả lơi con phụ thuộc vao nhiêu thư. Nếu cơ sở dữ liệu riêng tư không được truy cập từ mạng LAN bên ngoài (hoặc chỉ thông qua VPN), lược đồ này sẽ thêm bảo mật vì ai đó sử dụng thông tin đăng nhập của WebSite sẽ chỉ có quyền truy cập hạn chế vào Máy chủ DB riêng đó (và sẽ có thêm một số công việc để nhận vào mạng nội bộ của bạn - thời gian có thể thuận tiện trong việc khám phá sự xâm nhập và đóng lỗ hổng).

Nếu không, tôi không nghĩ rằng nó bổ sung bất cứ điều gì ngoại trừ sự phức tạp.

CHỈNH SỬA:

Có vẻ như tôi đã đọc sai câu hỏi của bạn, vì vậy hãy xem bây giờ tôi đã hiểu đúng chưa: IntermDb là một cơ sở dữ liệu trống chỉ để kết nối với PrivateDB HOẶC đó là một DB có các khung nhìn / thủ tục của chính nó kết nối với PrivateDB để lấy dữ liệu ?

Trong trường hợp đầu tiên, WTF? Xé nó ra. Điều đó là vô ích, trừ khi ai đó muốn kiểm toán nó để truy cập hồ sơ vào PrivateDB theo cách lười biếng hơn (và làm cho các nhà phát triển WebApp làm việc chăm chỉ hơn). SQL Profiler có thể lọc bằng DB_ID ...

Trong trường hợp thứ hai, tôi duy trì câu trả lời trước đó của tôi.

EDIT: "Tôi vẫn không thấy cách này an toàn hơn so với việc kết nối trực tiếp db riêng với db công khai vì cả 3 cơ sở dữ liệu trên cùng một phiên bản SQL và thông tin đăng nhập được sử dụng cho cả 3 cơ sở dữ liệu là như nhau và chỉ có thể truy cập quan điểm cụ thể và các thủ tục được lưu trữ trong mọi cách riêng tư db ".

Có trung gian có nghĩa là kẻ xâm lược sẽ phải đào mã của bạn biết sự tồn tại của IntermDB - và nó phải đào mã của bạn trên đó để biết rằng có tồn tại PrivateDB.

Nếu bạn đặt PrivateDB trên một máy chủ khác bên trong LAN / WAN của tổ chức (nếu có thể), nó có thể cung cấp đủ thời gian để quản trị viên phát hiện và chặn nỗ lực xâm lược. Nếu bạn sử dụng từ đồng nghĩa, việc di chuyển này diễn ra suôn sẻ vì tất cả những gì bạn có là xây dựng lại chúng theo mã hiện có, đi đến đúng nơi.

Ngoài ra, bạn có được các lợi thế khác: vì tất cả các mã phải thông qua IntermDB để truy cập dữ liệu trong PrivateDB, không có nhà phát triển nào muốn thử bỏ qua nó - và nỗ lực đó có thể dễ dàng được phát hiện trên SQL Server Profiler như DB_ID của yêu cầu dữ liệu PrivateDb sẽ là WebAppDb.