Đây có phải là một thực hành tốt thiết lập các chuỗi kết nối trong một cấu hình web?

Gần đây tôi có một cuộc thảo luận với một số đồng nghiệp tại nơi làm việc của tôi vì họ nói rằng tốt hơn là nên có một kết nối chuỗi được mã hóa .DLL. Và tôi đã nói tại sao không sử dụng kết nối chuỗi được xác định trong mã hóa web.config? Nó giống nhau và tốt hơn bởi vì khung thực thể, ví dụ như tìm tên của kết nối trong cấu hình web của ứng dụng, Bây giờ tôi muốn biết từ điểm bảo mật tốt hơn hay thực tiễn tốt nhất là gì ??

Không có sự khác biệt đáng kể, ngoại trừ việc bạn sẽ phải thực sự xây dựng nhị phân nếu bạn muốn thay đổi cấu hình nếu bạn đặt nó trong một DLL, trong khi quản trị viên chỉ có thể sửa đổi cấu hình bằng các công cụ sẵn có được hiểu rõ nếu nó trong cấu hình. Đã có một cơ chế mã hóa chuỗi cấu hình và hướng dẫn bổ sung về MSDN . Các phiên bản hiện tại của Asp.Net có thể có các cơ chế thay thế, vì vậy hãy thực hiện một số nghiên cứu bổ sung trước khi cam kết tiếp cận.

Chỉ vì một cái gì đó đang ngồi trong một DLL, không làm cho nó an toàn hơn. Một trình soạn thảo văn bản cũng có thể mở các tệp nhị phân, các công cụ như Reflector có thể cung cấp giao diện đẹp hơn để điều hướng .Net DLL; một DLL sẽ không cung cấp bất kỳ mã hóa "thêm".

Nó không quan trọng nơi dữ liệu được mã hóa được lưu trữ, nó quan trọng như thế nào nó được mã hóa.

Các phần được mã hóa trong web.config thường được mã hóa bằng API Bảo vệ Dữ liệu , cực kỳ khó bẻ khóa mà không ảnh hưởng đến toàn bộ máy. Bạn cũng có thể sử dụng bộ chứa khóa RSA, tương tự (khó lấy chúng ra khỏi máy).

Nếu bạn muốn lưu trữ chuỗi được mã hóa trong DLL, thì tốt thôi, tôi đoán vậy, mặc dù nó không an toàn hơn một web.config được mã hóa (bất kỳ ai cũng có thể xem qua DLL đó bằng Reflector ) và rõ ràng là khó thay đổi hơn (bạn 'Cần phải biên dịch lại). Nhưng một lần nữa, điều quan trọng hơn nhiều là cách tạo ra chuỗi mã hóa đó; có lẽ bạn không sử dụng cùng một nhà cung cấp cho một web.config được mã hóa, vậy bạn đang sử dụng cái gì?

Một lược đồ mã hóa chỉ mạnh như khóa riêng hoặc bí mật chung. Nếu khóa đó là cũng được lưu trữ trong hội đồng của bạn, thì bạn cũng có thể không có mã hóa nào cả. Nếu nó được lưu trữ trong một số cơ sở dữ liệu bên ngoài, thì nó sẽ đặt ra câu hỏi làm thế nào chuỗi kết nối của cơ sở dữ liệu đó được bảo mật. Điều này thực sự chỉ có thể dẫn đến bảo mật yếu hơn nói chung.

Mặt khác, nếu bạn là nhà cung cấp dịch vụ và chuỗi kết nối được mã hóa với người dùng mật khẩu, thì đó sẽ là hơn an toàn hơn là sử dụng một chìa khóa máy tĩnh. Sau đó, một lần nữa, nếu bạn đang sử dụng mật khẩu người dùng để mã hóa, rất có thể bạn sẽ không thể mã hóa dữ liệu được mã hóa trong tổ hợp của mình, vì nó cần được tạo và lưu trữ để đáp ứng với hành động của người dùng (không phải nhà phát triển).

Thực sự tôi không thể nghĩ ra quá nhiều tình huống trong đó mã hóa cứng chuỗi kết nối (được mã hóa) trong DLL là an toàn hơn so với mã hóa phần web.config có liên quan. Tốt nhất là nó chỉ thêm sự bất tiện, tệ nhất là nó dựa vào một số bảo mật tùy chỉnh được viết một cách vụng về với những lỗ hổng. Tự mình làm và làm những gì Microsoft khuyến nghị - chỉ cần mã hóa web.config của bạn nếu có dữ liệu nhạy cảm trong đó.

Cách thực hành tốt nhất cho ASP.NET là đặt tất cả các cấu hình / cài đặt trong tệp web.config hoặc tệp app.config (đối với các loại dự án khác).

Về mã hóa và lý do để sử dụng nó trên chuỗi kết nối của bạn phải là một trường hợp rất đặc biệt. Bởi vì hầu hết các trường hợp lên tới 99% bạn không cần mã hóa chuỗi kết nối của mình. Các ứng dụng doanh nghiệp của Microsoft có chuỗi kết nối của họ được hiển thị trong tệp web.config / app.config. Tôi nghĩ rằng bạn đang quá phức tạp bảo mật.

Một điều nữa, mã hóa cứng chuỗi kết nối của bạn là thực hành tồi. Chẳng hạn, không đặt bất kỳ chuỗi kết nối nào (còn gọi là chuỗi kết nối) vào DLL hoặc .aspx / .ascx / .cshtml hoặc mã phía sau.