Trình điều khiển mới cho SQL Server… Những điều bạn cần biết

Gần đây, Microsoft đã phát hành hai trình điều khiển mới cho SQL Server, một bản nâng cấp lớn:

Trình điều khiển ODBC 18 cho SQL Server
Trình điều khiển OLEDB 19 cho SQL Server

Tin tốt đấy! Tuy nhiên, có một sự thay đổi lớn cần bạn chú ý. Cụ thể, họ đã thay đổi cách cài đặt mặc định hoạt động cho mã hóa. Trong tất cả các phiên bản trước của trình điều khiển, mặc định là không yêu cầu mã hóa. Chúng tôi có các tùy chọn buộc mã hóa từ phía máy chủ hoặc yêu cầu nó trong chuỗi kết nối ở phía máy khách. Rõ ràng, đối với quản trị viên máy chủ, việc buộc mã hóa từ máy chủ thường mong muốn hơn, để không thành vấn đề nếu một số ứng dụng cũ không yêu cầu nó nhưng sẽ được đảm bảo mã hóa giao tiếp của nó với máy chủ.

Có 2 từ khóa chuỗi kết nối và cài đặt máy chủ ảnh hưởng đến cách trình điều khiển hoạt động:

Trong chuỗi kết nối từ phía máy khách:

• Encrypt :Cho biết liệu giao tiếp có được mã hóa hay không.
• TrustServerCertificate :Cho biết liệu máy khách có nên chỉ tin tưởng vào chứng chỉ của máy chủ mà không cần kiểm tra tính xác thực của chứng chỉ hay không.

Trong cài đặt từ phía máy chủ:

• Force Encryption :Nhiệm vụ mà bất kỳ máy khách nào kết nối với máy chủ mã hóa thông tin liên lạc bất kể chuỗi kết nối của máy khách là gì.

Sự kết hợp của 3 thuộc tính ảnh hưởng đến cách kết nối sẽ được thực hiện. Có một biểu đồ tiện dụng liệt kê chúng, có thể tìm thấy ở đây ..

Tuy nhiên, trường hợp phổ biến nhất là chúng tôi buộc mã hóa từ máy chủ và không chỉ định bất kỳ điều gì khác trong chuỗi kết nối. Đây là phiên bản được trích xuất của cả phiên bản trước và hành vi của phiên bản mới:

Tôi nghĩ đây thường là một điều tốt, đặc biệt là khi cơ sở dữ liệu Azure SQL trở nên phổ biến hơn, nhưng việc thay đổi kiểm tra chứng chỉ SQL Server thực sự dẫn đến một sự thay đổi, đặc biệt là đối với các máy chủ có thể không có chứng chỉ được thiết lập. Theo mặc định, nó sẽ sử dụng chứng chỉ tự ký, không an toàn bằng chứng chỉ đáng tin cậy. Đối với những máy chủ có kết nối được thực hiện qua internet, cần phải nỗ lực hết sức cẩn thận.

Dưới đây là so sánh các chuỗi kết nối ODBC cho các thay đổi của Microsoft Access với SQL Server giữa phiên bản trước và phiên bản hiện tại:

ODBC 17 so với ODBC 18

17:DRIVER=ODBC Driver 17 for SQL Server;SERVER= ;DATABASE= ; Mã hóa =có;
18:DRIVER=ODBC Driver 18 for SQL Server;SERVER= ;DATABASE= ;

Chuỗi kết nối OLEDB 18 so với OLEDB 19 cho Microsoft Access với SQL Server

18:Provider= MSOLEDBSQL ;Data Source= ;Initial Catalog= ; Mã hóa =có;
19:Provider= MSOLEDBSQL19 ;Data Source= ;Initial Catalog=

Lưu ý rằng trong các phiên bản trước, bạn phải chỉ định Encrypt=yes nhưng điều này hiện không có trong các phiên bản hiện tại.

Được rồi, nhưng tôi có một máy chủ đặt tại chỗ nhưng nó không hoạt động với các trình điều khiển mới?

Do thay đổi trong cài đặt, bây giờ bạn có thể thấy lỗi này:

Tùy thuộc vào tình huống và yêu cầu, đây là các giải pháp khả thi:

• Cài đặt và định cấu hình chứng chỉ đáng tin cậy trên máy chủ.
• Sửa đổi chuỗi kết nối của ứng dụng để bao gồm TrustServerCertificate=Yes . SỬ DỤNG CÓ THẬN TRỌNG
• Sửa đổi chuỗi kết nối của ứng dụng để bao gồm Encrypt=No và tắt Force Encryption trên máy chủ. KHÔNG ĐƯỢC ĐỀ XUẤT
• Không cập nhật trình điều khiển.

Các bước giải quyết vấn đề được trình bày chi tiết trong các phần tương ứng.

Nghị quyết

Cài đặt và định cấu hình chứng chỉ đáng tin cậy trên máy chủ

Điều rất quan trọng cần lưu ý là chỉ vì bạn có một máy chủ được thiết lập chứng chỉ SSL hợp lệ và đang được sử dụng không thực sự có nghĩa là Máy chủ SQL đang sử dụng cùng một chứng chỉ. Hơn nữa, hóa ra là Trình quản lý cấu hình máy chủ SQL rất khó xử lý các chứng chỉ. Bạn có thể thấy rằng nó sẽ không liệt kê bất kỳ chứng chỉ nào để bạn sử dụng:

Phiên bản ngắn gọn là Trình quản lý cấu hình SQL Server hạn chế quá mức đối với những chứng chỉ mà nó sẽ liệt kê, điều này có thể khá khó chịu, đặc biệt vì đây là vấn đề về giao diện người dùng, không phải là yêu cầu thực sự của chính SQL Server. May mắn thay, chúng tôi có thể phá vỡ giới hạn giao diện người dùng ngớ ngẩn này bằng cách chỉnh sửa sổ đăng ký trực tiếp. Điều này tương ứng với khóa đăng ký:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\<name of your instance>\MSSQLServer\SuperSocketNetLib

Trong khóa đó, có một giá trị Certificate yêu cầu một dấu vết của chứng chỉ.

Bạn có thể dán thủ công dấu vân tay của chứng chỉ SSL sẽ được sử dụng nhưng tôi khuyên bạn nên sử dụng tập lệnh để thực hiện việc này vì chúng tôi cũng cần đảm bảo rằng tài khoản máy chủ có quyền truy cập chứng chỉ. Tôi đã sử dụng bài viết blog này làm hướng dẫn thiết lập tập lệnh PowerShell để chọn chứng chỉ và tải chứng chỉ đó vào khóa đăng ký của SQL Server và khởi động lại dịch vụ. Tùy thuộc vào người cung cấp chứng chỉ SSL của bạn và quy trình làm việc, bạn có thể muốn tích hợp điều này vào một số tác vụ đã lên lịch khác để khi chứng chỉ SSL được gia hạn, khóa đăng ký và quyền sẽ được cập nhật tương ứng.

Nếu mọi thứ được thiết lập chính xác, thì máy chủ của bạn sẽ có thể sử dụng trình điều khiển mới mà không cần bất kỳ sửa đổi nào đối với chuỗi kết nối của ứng dụng. Như một xác minh bổ sung, bạn có thể kiểm tra nhật ký lỗi của Máy chủ SQL của mình và tìm một dòng như sau:

<timestamp> spid11s The certificate [Cert Hash(sha1) "<certificate thumbprint>"] was successfully loaded for encryption.

Nếu dấu vân tay khớp với dấu vân tay mà bạn muốn sử dụng, thì bạn biết rằng mình đã tải chính xác và do đó, chuỗi tin cậy hiện đã được thiết lập.

Sửa đổi chuỗi kết nối của ứng dụng để bao gồm TrustServerCertificate=Yes

Tuy nhiên, nếu máy chủ của bạn không có Internet và quá khó để thiết lập chứng chỉ SSL, bạn có thể chấp nhận bật TrustServerCertificate . Điều này yêu cầu thay đổi trong chuỗi kết nối của ứng dụng của bạn. Điều này cho phép ứng dụng cho phép kết nối với máy chủ mà không cần xác minh chứng chỉ của máy chủ. Nếu bạn có thể tự tin kiểm soát ứng dụng của mình để nó không đi ra ngoài mạng của bạn, điều này sẽ ổn. Hãy nhớ rằng nếu ai đó có thể giả mạo tên hoặc IP của máy chủ trong mạng, các ứng dụng khách sẽ kết nối một cách mù quáng với máy tính đó. Vì lý do đó, chúng tôi không thể khuyến nghị điều này nếu có internet liên quan đến kết nối. Chúng tôi thực sự không muốn mạo hiểm.

Sửa đổi chuỗi kết nối của ứng dụng để bao gồm Encrypt=No và tắt Force Encryption trên máy chủ.

Điều này dành cho những người thích ghi lại trên Internet với một bảng hiệu neon khổng lồ “STEAL MY DATA! HIJACK TÔI NGAY BÂY GIỜ! ” cho mọi tác nhân xấu ngoài kia. Đây là một "lựa chọn". Điều duy nhất tôi có thể nói về tùy chọn này là nó cực kỳ tệ. Thật tệ, tôi đã quên cách làm điều này. Bạn đang ở một mình, bạn thân.

Không cập nhật trình điều khiển.

Một giải pháp thay thế tốt hơn một chút so với trước đây là chỉ cần không cập nhật và gắn bó với trình điều khiển ODBC 17 và OLEDB 18. Tuy nhiên, đây tốt nhất là một biện pháp chốt chặn. Độ phân giải này không yêu cầu thay đổi ứng dụng nhưng điều này chỉ trì hoãn tốt nhất những thay đổi không thể tránh khỏi. Bạn có thể tận dụng thời gian để khám phá các đường dẫn sẽ đưa bạn đến phiên bản mới nhất và bảo vệ dữ liệu của bạn đúng cách.

Hy vọng điều đó sẽ hữu ích!