10
Thực tiễn không tốt là sử dụng Integrated Security=True trên máy chủ sản xuất trong ASP.NET?Tôi có nên sử dụng 'Bảo mật tích hợp = True' trong môi trường sản xuất không?
A
Trả lời
8
Nope - tuyệt đối an toàn *
Tất cả các bạn đang làm là nói rằng bạn sẽ sử dụng các thông tin cần (thường là) người dùng Windows mà tiến trình đang chạy dưới để xác thực với SQL Server (như trái ngược để cung cấp tên người dùng và mật khẩu).
Trong thực tế nói chung, sử dụng bảo mật tích hợp được coi là an toàn hơn.
(*) Tất nhiên, điều này luôn tùy thuộc vào tình huống chính xác của bạn, nhưng trong trường hợp chung, điều đó có thể xảy ra.
+1
Hmm, bạn có cho rằng điều này có thể không nhất thiết phải đúng đối với máy chủ web không? Nếu nó bị xâm nhập, cửa hàng dbase cũng mở rộng. Giữ một mật khẩu an toàn trên một máy chủ không phải là khó khăn, có một khóa trên cửa phòng máy chủ. –
+2
@Hans trừ khi bạn đang nói đùa, đó là một lý lẽ tồi. Nếu máy chủ bị xâm phạm, kẻ tấn công cũng sẽ có quyền truy cập vào kết nối dựa trên sql u/p, vì vậy nó không tốt hơn tích hợp. Trong cả hai trường hợp, kẻ tấn công có thể dễ dàng nhận được từ vị trí đó để truy cập DB và số lượng họ có thể làm sẽ khác nhau tùy theo cấu hình cụ thể. Nếu bạn thực sự muốn bảo vệ chống lại kịch bản đó, bạn sẽ không có máy chủ web đánh trực tiếp DB. – eglasius
+0
@eglasius - không, không sử dụng mặt cười. Bạn làm việc từ giả định rằng kẻ tấn công sẽ sử dụng một kết nối hiện có. Đó là làm theo cách * cứng * nếu bảo mật tích hợp được bật. Anh ta chỉ có thể tạo ra kết nối của riêng mình, không cần phải cung cấp một tên người dùng khó đoán tên người dùng. –
1
Điều này có thể là một điều tốt hoặc một điều xấu tùy thuộc vào tài khoản mà IIS đang sử dụng để chạy ứng dụng web.
Trong mọi trường hợp, có một lợi thế riêng biệt là tên người dùng và mật khẩu SQL không xuất hiện trong chuỗi kết nối; luôn luôn là một điều tốt.
Tuy nhiên, bạn cần phải thiết lập cẩn thận môi trường sản xuất của mình. Tôi khuyên bạn nên tạo một tài khoản người dùng riêng biệt cho IIS để sử dụng để chạy ứng dụng web. Tài khoản người dùng đó có thể được cấu hình để chỉ truy cập vào các tài nguyên SQL theo yêu cầu của ứng dụng của bạn. Điều đó sẽ bảo vệ bạn khỏi các ứng dụng khác dễ bị xâm phạm trong trường hợp bảo mật của ứng dụng web của bạn bị xâm phạm.
Tôi đã nghe nói về các lập trình viên làm động tác nhào lộn, nơi một kết nối chuỗi SQL với id người dùng và mật khẩu được nạp tại thời gian chạy từ một nguồn tài nguyên được mã hóa :-)
+1
Acrobatics? Có được xây dựng trong hỗ trợ cho chuỗi kết nối SQL được mã hóa. Nó không phải là đặc biệt khó khăn. – Brian
+1
@Brian - tốt hơn hết là khóa các quyền của tài khoản SQL hơn là chỉ mã hóa chuỗi kết nối một mình. Tôi thích sử dụng các thủ tục được lưu trữ cho 100% truy cập SQL và chỉ cho phép thực thi quyền cho người dùng. Bằng cách đó ngay cả khi kẻ tấn công có mật khẩu, anh ta có thể làm nhiều hơn những gì ứng dụng có thể tự làm. Tuy nhiên, việc sử dụng cả quyền SQL và chuỗi kết nối được mã hóa sẽ là tùy chọn tốt nhất. – NightOwl888
+0
@ NightOwl888 - Tôi đồng ý rằng thực hiện nhiều biện pháp phòng ngừa là thực hành tốt. [Cách thực hiện: Các chuỗi kết nối an toàn khi sử dụng các điều khiển nguồn dữ liệu] (https://msdn.microsoft.com/en-us/library/ms178372.aspx) – myidealab
1
trả lời cho câu hỏi tiêu đề:
Bạn nên không chạm vào (ít sử dụng) bất cứ điều gì trong môi trường sản xuất trong khi bạn đang có những câu hỏi hoặc nghi ngờ như vậy!
trả lời cho câu hỏi của cơ thể:
SQL Server trong sản xuất không nên kích hoạt để xác thực SQL Server ở tất cả
Cập nhật:
Tôi ngạc nhiên khi thấy rằng tất cả các câu trả lời sử dụng xác suất "này phụ thuộc", "trong một số trường hợp "," nhiều hơn "khả năng.
Các vấn đề liên quan
- 1. Sử dụng máy chủ web tích hợp của Django trong môi trường sản xuất
- 2. Sử dụng node.js trong môi trường sản xuất
- 3. Máy chủ có được tích hợp Flask an toàn để sử dụng trong sản xuất không?
- 4. Sử dụng HSQLDB trong môi trường sản xuất
- 5. Chạy Tomcat trong môi trường sản xuất
- 6. Ứng dụng Rails không phân phối tài sản trong môi trường sản xuất
- 7. Môi trường sản xuất/phát triển SharePoint
- 8. Sản xuất Tomcat/môi trường dev
- 9. Gửi email SMTP qua Django trong môi trường sản xuất
- 10. Tôi có nên sử dụng JSAPI của Google trong mã sản xuất không?
- 11. Rails 3 http_basic_authenticate_with chỉ trong môi trường sản xuất?
- 12. Có rủi ro bảo mật khi chạy các ứng dụng web trong debug = "true" không?
- 13. Tôi có thể sử dụng XmlHttpRequest trên trang web trong môi trường Itunes LP không?
- 14. Phân biệt web.config giữa môi trường dev, dàn dựng và môi trường sản xuất
- 15. iPhone - Chuyển đổi giữa cài đặt môi trường địa phương và môi trường sản xuất
- 16. Có an toàn khi sử dụng các tùy chọn nút v8 trong môi trường sản xuất không?
- 17. Tôi nên đăng nhập vào ứng dụng sản xuất
- 18. Tệp composer.json của tôi trông như thế nào trong môi trường sản xuất?
- 19. Sự khác biệt giữa thông tin bảo mật liên tục và bảo mật tích hợp?
- 20. Rails môi trường sản xuất phá vỡ với chu kỳ
- 21. Nên raise_delivery_errors được đặt thành true trong ứng dụng Rails sản xuất?
- 22. Git với môi trường phát triển và sản xuất
- 23. Tôi có nên sử dụng "trường hợp lạc đà" hoặc dấu gạch dưới trong python không?
- 24. Bảo mật khi sử dụng GWT RPC
- 25. Sử dụng Maven cho nhiều môi trường triển khai (sản xuất/phát triển)
- 26. Có thể loại trừ plugin grails khỏi môi trường sản xuất không?
- 27. Lỗi trên môi trường "sản xuất" trên Symfony2
- 28. Bảo mật mùa xuân Đăng nhập một lần trong môi trường Windows
- 29. môi trường sản xuất - trang lỗi http 500 - không có stacktrace, vui lòng
- 30. Ruby: GC có thể :: Profiler.enable trong môi trường sản xuất gây ra vấn đề hiệu suất?
Đây có phải là chuỗi kết nối trong tệp cấu hình không? – slugster
có cho tệp cấu hình – user441365