Baru-baru ini, Microsoft merilis dua driver baru untuk SQL Server, peningkatan besar:
Driver ODBC 18 untuk SQL Server
Driver OLEDB 19 untuk SQL Server
Itu berita bagus! Namun, ada perubahan besar yang membutuhkan perhatian Anda. Secara khusus, mereka mengubah cara kerja pengaturan default untuk enkripsi. Di semua versi driver sebelumnya, defaultnya adalah tidak memerlukan enkripsi. Kami memiliki opsi untuk memaksa enkripsi dari sisi server atau memintanya dalam string koneksi di sisi klien. Jelas, untuk administrator server, biasanya lebih diinginkan untuk memaksa enkripsi dari server, sehingga tidak masalah jika beberapa aplikasi lama tidak memintanya tetapi akan dijamin untuk mengenkripsi komunikasinya dengan server.
Ada 2 kata kunci string koneksi dan pengaturan server yang memengaruhi perilaku pengemudi:
Dalam string koneksi dari sisi klien:
Encrypt:Menunjukkan apakah komunikasi harus dienkripsi.TrustServerCertificate:Menunjukkan apakah klien harus mempercayai sertifikat server tanpa memeriksa keaslian sertifikat.
Dalam pengaturan dari sisi server:
Force Encryption:Mengamanatkan bahwa setiap klien yang terhubung ke server untuk mengenkripsi komunikasi terlepas dari string koneksi klien.
Kombinasi dari 3 properti mempengaruhi bagaimana koneksi akan dibuat. Ada bagan praktis yang menyebutkannya, yang dapat ditemukan di sini..
Namun, skenario yang paling umum adalah bahwa kami memaksa enkripsi dari server dan tidak menentukan apa pun di string koneksi. Inilah versi yang diekstraksi dari versi sebelumnya dan perilaku versi baru:
Versi | Enkripsi | Server Tepercaya Sertifikat | Kekuatan Server Enkripsi | Hasil |
|---|---|---|---|---|
| ODBC 17 &sebelumnya OLEDB 18 &sebelumnya | Tidak | Tidak | Ya | Sertifikat server tidak dicentang. Data yang dikirim antara klien dan server dienkripsi. |
| ODBC 18 OLEDB 19 | Tidak | Tidak | Ya | Sertifikat server diperiksa. Data yang dikirim antara klien dan server dienkripsi. |
Saya pikir ini umumnya hal yang baik, terutama dengan database Azure SQL menjadi lebih umum, tetapi perubahan memeriksa sertifikat SQL Server memang memperkenalkan perubahan, terutama untuk server yang mungkin tidak memiliki sertifikat yang disiapkan. Secara default, ini akan menggunakan sertifikat yang ditandatangani sendiri, yang tidak seaman yang tepercaya. Untuk server yang membuat koneksi melalui internet, tindakan pencegahan ekstra sepadan dengan usaha.
Berikut perbandingan string koneksi ODBC untuk Microsoft Access dengan perubahan SQL Server antara versi sebelumnya dan versi sekarang:
ODBC 17 vs. ODBC 18
17:DRIVER=ODBC Driver 17 for SQL Server;SERVER= ;DATABASE= ;
18:DRIVER=ODBC Driver 18 for SQL Server;SERVER= ;DATABASE= ;
OLEDB 18 vs. OLEDB 19 koneksi string untuk Microsoft Access dengan SQL Server
18:Provider= ;Data Source= ;Initial Catalog= ;
19:Provider= ;Data Source= ;Initial Catalog=
Perhatikan bahwa di versi sebelumnya, Anda harus menentukan Encrypt=yes tapi ini sekarang tersirat dalam versi saat ini.
Oke, tapi saya memiliki server lokal tetapi tidak berfungsi dengan driver baru?
Karena perubahan dalam pengaturan, sekarang Anda mungkin melihat kesalahan ini:
Bergantung pada skenario dan persyaratan, berikut adalah kemungkinan resolusi:
- Pasang &konfigurasikan sertifikat tepercaya di server.
- Ubah string koneksi aplikasi untuk menyertakan
TrustServerCertificate=Yes. GUNAKAN DENGAN PERHATIAN - Ubah string koneksi aplikasi untuk menyertakan
Encrypt=Nodan nonaktifkanForce Encryptiondi server. TIDAK DIREKOMENDASIKAN - Jangan perbarui driver.
Langkah-langkah untuk menyelesaikan masalah dijelaskan secara rinci di bagian terkait.
Resolusi
Instal &konfigurasikan sertifikat tepercaya di server
Sangat penting untuk dicatat bahwa hanya karena Anda memiliki server yang memiliki sertifikat SSL yang valid dan dalam penggunaan aktif tidak berarti bahwa SQL Server menggunakan sertifikat yang sama. Selain itu, ternyata Manajer Konfigurasi SQL Server buruk dalam menangani sertifikat. Anda mungkin menemukan bahwa itu tidak akan mencantumkan sertifikat apa pun untuk Anda gunakan:
Versi singkatnya adalah SQL Server Configuration Manager terlalu membatasi sertifikat apa yang akan dicantumkan, yang bisa sangat membuat frustrasi terutama karena ini adalah masalah UI, bukan persyaratan sebenarnya oleh SQL Server itu sendiri. Untungnya, kami dapat menghindari batasan UI konyol ini dengan mengedit registri secara langsung. Ini sesuai dengan kunci registri:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\<name of your instance>\MSSQLServer\SuperSocketNetLib
Di dalam kunci itu, ada nilai Certificate yang mengharapkan cap jempol dari sertifikat.
Anda dapat secara manual menempelkan cap jempol dari sertifikat SSL yang akan digunakan, tetapi saya akan merekomendasikan menggunakan skrip untuk melakukan ini karena kami juga perlu memastikan bahwa akun server memiliki izin untuk mengakses sertifikat. Saya menggunakan artikel blog ini sebagai panduan untuk menyiapkan skrip PowerShell untuk memilih sertifikat dan memuatnya ke kunci registri SQL Server dan memulai kembali layanan. Bergantung pada siapa yang memberikan sertifikat SSL dan alur kerja Anda, Anda mungkin ingin mengintegrasikan ini ke dalam beberapa tugas terjadwal lainnya sehingga ketika sertifikat SSL diperbarui, kunci &izin registri akan diperbarui sesuai dengan itu.
Jika semuanya sudah diatur dengan benar, maka server Anda seharusnya dapat menggunakan driver baru tanpa modifikasi apa pun pada rangkaian koneksi aplikasi. Sebagai verifikasi tambahan, Anda dapat memeriksa log kesalahan SQL Server Anda dan mencari baris seperti ini:
<timestamp> spid11s The certificate [Cert Hash(sha1) "<certificate thumbprint>"] was successfully loaded for encryption.
Jika cap jempol cocok dengan yang ingin Anda gunakan, maka Anda tahu bahwa Anda telah memuatnya dengan benar dan dengan demikian rantai kepercayaan sekarang terbentuk.
Ubah string koneksi aplikasi untuk menyertakan TrustServerCertificate=Yes
Namun, jika server Anda tidak menghadap internet dan terlalu sulit untuk menyiapkan sertifikat SSL, mungkin dapat diterima untuk mengaktifkan TrustServerCertificate . Ini memerlukan perubahan dalam string koneksi aplikasi Anda. Ini memungkinkan aplikasi mengizinkan koneksi ke server tanpa memverifikasi sertifikat server. Jika Anda dapat mengontrol aplikasi Anda dengan percaya diri sehingga tidak akan keluar dari jaringan Anda, ini akan baik-baik saja. Ingatlah bahwa jika seseorang dapat memalsukan nama atau IP server di dalam jaringan, aplikasi klien akan terhubung secara membabi buta ke komputer itu. Untuk alasan itu, kami tidak dapat merekomendasikan ini jika ada internet yang terlibat dalam koneksi. Kami benar-benar lebih suka tidak mengambil risiko.
Ubah string koneksi aplikasi untuk menyertakan Encrypt=No dan nonaktifkan Force Encryption di server.
Ini untuk mereka yang suka melesat di internet dengan tanda neon raksasa “CURUK DATA SAYA! PELAJARI SAYA SEKARANG!” untuk setiap aktor jahat di luar sana. Ini erm, sebuah "pilihan". Satu-satunya hal yang dapat saya katakan tentang opsi ini adalah sangat buruk. Sangat buruk, saya lupa bagaimana melakukan ini. Anda sendirian, sobat.
Jangan perbarui driver.
Alternatif yang sedikit lebih baik dibandingkan dengan sebelumnya adalah dengan tidak memperbarui dan tetap menggunakan driver ODBC 17 dan OLEDB 18. Namun, ini paling banter merupakan tindakan sementara. Resolusi ini tidak memerlukan perubahan aplikasi tetapi ini hanya menunda perubahan yang tak terhindarkan. Anda dapat memanfaatkan waktu untuk menjelajahi jalur yang akan membawa Anda ke versi terbaru dan melindungi data Anda dengan benar.
Semoga membantu!
