Khi triển khai các ứng dụng web (.net) vào môi trường sản xuất, tốt hơn là sử dụng bảo mật tích hợp hay thậm chí có vấn đề gì không?
Dường như với tôi rằng nếu một hacker phá vỡ máy chủ web, điều đó sẽ không thực sự quan trọng vì họ có thể dễ dàng mạo danh máy.
Suy nghĩ?
Câu trả lời:
Tôi muốn nói rằng chỉ có hai lý do hợp lệ để sử dụng SQL auth:
Đối với kịch bản bạn đang đề xuất (máy chủ lưu trữ web bị xâm phạm hoàn toàn) không có gì có thể bảo vệ bạn. Tin tặc có thể làm trên máy chủ DB ở mức tối thiểu mọi thứ mà máy chủ web có thể làm . Và tôi muốn nói rằng phòng thủ theo chiều sâu có thể dạy bạn giảm thiểu tổn thất trong trường hợp đó: giảm quyền DB của tài khoản được sử dụng bởi máy chủ web của bạn xuống mức tối thiểu hoàn toàn bắt buộc và không còn gì nữa. Thứ hai, đảm bảo nếu máy chủ máy chủ web bị xâm phạm, nó không thể được sử dụng để nâng cao các đặc quyền cao hơn tài khoản máy chủ web (nghĩa là không có dịch vụ nào khác trên máy chủ WWW sử dụng thông tin đăng nhập có đặc quyền cao hơn trên DB so với tài khoản WWW). Đây là những nguyên tắc bảo mật cơ bản và không liên quan gì đến sơ đồ xác thực được sử dụng.
Trong khi sql auth so với windows auth không mang lại lợi thế rõ ràng trong kịch bản của bạn, có một số vấn đề khác cần xem xét:
Một lưu ý cuối cùng: giao thức TDS hiển thị mật khẩu auth sql dưới dạng văn bản rõ ràng trên lưu lượng, nhưng điều đó thường được giảm nhẹ bằng cách yêu cầu mã hóa SSL lưu lượng.
Vậy tại sao bạn vẫn thấy các máy chủ WWW auth vẫn lưu trữ mật khẩu rõ ràng trong web.config? Đó là những nhà phát triển / quản trị viên tồi , đừng là một trong số họ.
msdn.microsoft.com/en-us/l Library / aa378326 (VS85) .aspx
technet.microsoft.com/en-us/l Library / ms189067.aspx
Nếu bạn không sử dụng SSPI, bạn sẽ mã hóa tên người dùng và mật khẩu vào các tệp nguồn.
Nếu bạn đang mã hóa tên người dùng và mật khẩu vào các tệp nguồn, tất cả nhân viên của bạn đều có quyền truy cập vào nó.
Điều này là tương đối không an toàn. Một nhân viên cũ bất mãn có thể sử dụng thông tin độc hại. Một khách truy cập có thể thấy mã trên màn hình ở đâu đó. Hoặc mã nguồn có thể vô tình thoát ra ngoài tự nhiên.
Ưu điểm của SSPI là mật khẩu không bao giờ được lưu trữ ở bất cứ đâu rõ ràng.
Các câu trả lời khác cho đến nay vẫn tốt, nhưng tôi sẽ đưa ra một câu trả lời khác: quản lý.
Sớm hay muộn, có lẽ bạn sẽ kết thúc với nhiều Máy chủ SQL. Việc quản lý xác thực SQL giữa ứng dụng của bạn và nhiều Máy chủ SQL trở nên hơi khó khăn, đặc biệt là khi bạn gặp vấn đề về bảo mật. Nếu bạn thay đổi mật khẩu xác thực Windows một lần, nó sẽ thay đổi ngay lập tức trên tất cả các máy chủ của bạn. Nếu bạn cần xoay mật khẩu xác thực SQL của mình, điều đó sẽ đau đớn hơn - đến mức bạn hoàn toàn không thể làm điều đó. Đó là một rủi ro bảo mật.
Tôi không chắc chắn 100% ở đây, nhưng tôi nghĩ điểm chính là SQL auth không an toàn, vì vậy tốt hơn là sử dụng Windows auth. Tùy thuộc vào cách ứng dụng của bạn được thiết lập, bạn cũng có thể lưu trữ thông tin đăng nhập phù hợp ở dạng được mã hóa trên máy bằng Windows auth. Tôi không nghĩ điều đó thực sự khả thi với SQL auth. Bạn có thể che giấu nó, nhưng cuối cùng nó phải rõ ràng.
Ngoài ra, chỉ vì tin tặc có thể xâm nhập vào máy chủ không có nghĩa là trò chơi kết thúc. Một tin tặc có thể giành quyền kiểm soát một quy trình không được ưu tiên nhưng không làm gì khác trên máy chủ. Đó là lý do tại sao điều quan trọng không phải là chạy mọi thứ như quản trị viên hoặc hệ thống, mà thay vào đó là sử dụng các tài khoản dịch vụ đặc quyền tối thiểu.
Điều tốt nhất để làm là giới hạn những gì họ có thể làm Nếu / Khi họ đột nhập vào máy chủ web. Điều đó có nghĩa là chỉ cấp các quyền SQL cần thiết cho ứng dụng hoạt động. Việc cung cấp quyền DBO cho ứng dụng dễ dàng hơn nhiều, nhưng điều đó khiến DB dễ bị tổn thương hơn nhiều trong trường hợp tấn công thành công vào máy chủ web.
Tôi sẽ mở đầu tất cả những điều này bằng cách nói rằng tôi đang giả định rằng bạn đang nói về một máy chủ web nội bộ trên mạng riêng nội bộ.
Hãy bắt đầu với việc mạo danh máy. Nếu danh tính nhóm ứng dụng là Dịch vụ mạng và không có mạo danh trong ứng dụng .NET, thì có, ứng dụng web sẽ kết nối với Máy chủ SQL phụ trợ bằng tài khoản máy tính của máy. Và điều đó có nghĩa là bạn đã cấp quyền truy cập vào tài khoản máy nói trên. CRM của Microsoft hoạt động theo cách này.
Tuy nhiên, nếu bạn đã chỉ định một danh tính, tài khoản người dùng đó sẽ cần quyền truy cập vào Máy chủ SQL. Mặc dù bạn đúng rằng nếu kẻ tấn công xâm phạm máy chủ web thì chúng thực sự có quyền truy cập giống như tài khoản nhận dạng, sự thật của vấn đề là việc sử dụng đăng nhập SQL Server sẽ không thay đổi bất cứ điều gì ở đây. Khi tôi có quyền truy cập, tôi có thể sửa đổi ứng dụng web để làm những gì tôi muốn và nó sẽ, tối đa cho phép bảo mật của bạn trên SQL Server back-end.
Bây giờ là tại sao để sử dụng SSPI. Đầu tiên và quan trọng nhất, bạn không sử dụng đăng nhập dựa trên SQL Server. Điều đó có nghĩa là Active Directory là nguồn duy nhất để bảo mật. Điều đó có nghĩa là bạn có phương tiện kiểm toán bình thường để xác định quyền truy cập không hợp lệ. Thứ hai, điều đó có nghĩa là trừ khi có các ứng dụng khác yêu cầu, bạn có thể để máy chủ SQL của mình ở chế độ chỉ xác thực Windows. Điều đó có nghĩa là không cho phép đăng nhập SQL Server. Điều đó có nghĩa là bất kỳ cuộc tấn công chống lại sa đều dừng lại trước khi chúng bắt đầu. Và cuối cùng, nó làm cho sự phục hồi dễ dàng hơn. Nếu bạn sử dụng thông tin đăng nhập dựa trên SQL Server, bạn sẽ cần trích xuất thông tin đăng nhập bằng SID và mật khẩu được mã hóa. Nếu bạn đang sử dụng tài khoản người dùng dựa trên Windows làm "tài khoản dịch vụ", khi bạn truy cập SQL Server mới, bằng cách tạo thông tin đăng nhập,
Câu hỏi là "tốt hơn"? Điều này thật khó trả lời vì nó dựa vào bối cảnh, giá trị và ưu tiên của người hỏi.
Cá nhân, tôi thích SQL auth.
Điểm cuối cùng: bạn mã hóa lớp trình quản lý kết nối của mình để thử từng chuỗi kết nối, theo cách đó bạn có thể thay đổi mật khẩu trên cấu hình đầu tiên, đẩy thay đổi ra và nó sẽ chuyển sang kết nối thứ hai, sau đó bạn cập nhật mật khẩu trên MSQL và cái đầu tiên sẽ được sử dụng lại. Một thay đổi cấu hình cuối cùng là cần thiết để đặt mật khẩu thứ hai giống như mật khẩu thứ nhất, sẵn sàng cho lần tiếp theo.
Nếu người dùng sẽ không thao túng cơ sở dữ liệu trực tiếp (thông qua các công cụ máy khách khác như SQL Server Management Studio) thì tôi thường sẽ chỉ tạo một thông tin đăng nhập SQL duy nhất cho ứng dụng và cấp cho nó quyền truy cập cần thiết. Tại thời điểm đó, người dùng bị hạn chế trong những gì họ có thể làm theo sự cho phép của giao diện ứng dụng web.