Tài khoản xác thực Windows và tài khoản dịch vụ mạng dưới dạng db_owner

Question

Có một số sản phẩm thương mại ngoài đó cung cấp cho bạn trình cài đặt dựa trên windows để định cấu hình ứng dụng của bạn và DB Server DB. Thông thường nó sẽ hỏi nếu bạn muốn kết nối với DB với xác thực Windows hoặc SQL Server. Hầu hết trong số họ thực hiện một đề nghị để sử dụng Windows Auth và sau đó cấu hình DB của bạn với tài khoản dịch vụ mạng được gán cho vai trò cơ sở dữ liệu db_owner. Tôi hiểu rằng Windows Authentication là an toàn hơn vì bạn không phải lưu trữ thông tin xác thực trong web.config và gửi chúng qua dây khi xác thực đến SQL Server, nhưng đó là cấu hình an toàn cho môi trường sản xuất, nơi tài khoản Dịch vụ mạng một db_owner? Bất kỳ rủi ro cụ thể nào chúng ta nên biết?

---

Cảm ơn StingyJack,

tôi nghe những gì bạn đang nói, Họ sẽ phải đăng nhập vào DB như một người sử dụng dịch vụ mạng đầu tiên mặc dù. Có cách nào dễ dàng để làm điều đó không?

Điều tôi thực sự cố gắng tìm ra là liệu có bất kỳ rủi ro vốn có nào liên quan đến thực tế là tài khoản Dịch vụ mạng mặc định được gán vai trò db_owner.

Answer 1

Có, ứng dụng (và bất kỳ người dùng nào của nó) có khả năng thực thi bất cứ điều gì mà dbo có thể thực thi đối với cơ sở dữ liệu. DROP TABLE, SELECT * FROM PASSWORDS, vv

Nếu bạn thiết lập các biện pháp phòng ngừa chống lại SQL Injection và đã viết ứng dụng của bạn với bảo mật lớp ứng dụng thích hợp, thì điều này sử dụng Windows Auth với dbo có lẽ sẽ ổn.

Nếu bạn đang làm việc với dữ liệu rất nhạy cảm, không tin tưởng ứng dụng (chưa) hoặc muốn an toàn nhất có thể, thì bạn sẽ phải thực hiện bảo mật ở lớp cơ sở dữ liệu.

Ví dụ: người dùng x có quyền truy cập vào các dạng xem bảng a và b và chế độ xem c và người dùng y chỉ có quyền truy cập để xem c. Ứng dụng của bạn sẽ phải kết nối với tư cách người dùng thích hợp để truy cập đúng đối tượng.

Answer 2

Đăng nhập vào DB dưới dạng dịch vụ mạng (tên miền \ máy $) sẽ rất khó (tôi không biết nhưng có thể có một số lỗi h33) trừ khi bạn là dịch vụ trên hộp web.

Không có mật khẩu, nó không tương tác và có quyền rất hạn chế (trừ khi "hệ thống cục bộ").

Vấn đề chính là tấn công SQL injection. Những điều này áp dụng cho bất kỳ kết nối nào tới máy chủ db.

Nguy cơ thêm trong việc có db_owner là DROP TABLE, ngay cả các cuộc tấn công kiểu DROP DATABASE. Nếu không có db_owner, nó vẫn nguy hiểm, ví dụ như "SELECT * FROM usertable WHERE 1 = 1" tấn công.

Thật không may, bạn không có sự lựa chọn với các ứng dụng bên thứ 3 hoặc thương mại để sử dụng được lưu trữ procs, ít nhất là cho phép, vv

Bạn có thể để giảm quyền sau khi cài đặt mặc dù.

Answer 3

Sử dụng dịch vụ MẠNG như một db_owner có lẽ là OK cho nhiều môi trường.

Nếu bạn muốn có mức độ bảo mật cao hơn, chỉ cần tạo Tài khoản Windows riêng, cấp cho nó quyền truy cập tối thiểu cần trong SQL Server, sau đó thay đổi ứng dụng để chạy trong ngữ cảnh của tài khoản mới này.

Các rủi ro cụ thể sẽ là:

• Một kém bằng văn bản ứng dụng chạy dưới bối cảnh NETWORK SERVICE có thể cho phép truy cập trái phép vào tất cả các dữ liệu khác mà MẠNG DỊCH VỤ có quyền truy cập vào. Bạn giảm thiểu rủi ro này bằng cách tạo tài khoản riêng cho tất cả các ứng dụng.
• db_owner có khả năng truy cập nhiều hơn ứng dụng thực sự cần, có nghĩa là nhiều khả năng lạm dụng/khai thác nếu bạn bị xâm phạm. Bạn có thể giảm bớt điều này một chút bằng cách chọn các đặc quyền thông thường để cấp. Mang nó quá xa và bạn sẽ có lợi nhuận giảm dần và nhức đầu hỗ trợ nhiều hơn, mặc dù.