Nedávno společnost Microsoft vydala dva nové ovladače pro SQL Server, což je hlavní upgrade:
Ovladač ODBC 18 pro SQL Server
Ovladač OLEDB 19 pro SQL Server
To je dobrá zpráva! Existuje však zásadní změna, která vyžaduje vaši pozornost. Konkrétně změnili způsob, jakým fungují výchozí nastavení pro šifrování. Ve všech předchozích verzích ovladačů bylo výchozí nastavení nevyžadovat šifrování. Měli jsme možnost vynutit šifrování ze strany serveru nebo o něj požádat v rámci připojovacího řetězce na straně klienta. Je zřejmé, že pro administrátora serveru bylo obvykle vhodnější vynutit šifrování ze serveru, aby nevadilo, kdyby si to nějaká stará aplikace nevyžádala, ale bylo zaručeno, že zašifruje svou komunikaci se serverem.
Existují 2 klíčová slova připojovacího řetězce a nastavení serveru, které ovlivňuje, jak se má ovladač chovat:
V rámci připojovacího řetězce ze strany klienta:
Encrypt:Označuje, zda má být komunikace šifrována.TrustServerCertificate:Označuje, zda má klient důvěřovat pouze certifikátu serveru bez kontroly pravosti certifikátu.
V rámci nastavení ze strany serveru:
Force Encryption:Nařizuje, aby každý klient připojující se k serveru šifroval komunikaci bez ohledu na připojovací řetězec klienta.
Kombinace těchto 3 vlastností ovlivňuje, jak bude spojení provedeno. Existuje praktická tabulka s jejich výčtem, kterou naleznete zde..
Nejběžnějším scénářem však je, že vynutíme šifrování ze serveru a v připojovacím řetězci neuvádíme nic jiného. Zde je extrahovaná verze předchozích verzí a chování nové verze:
Verze | Šifrovat | Důvěřovat certifikátu serveru | Server Force Šifrování | Výsledek |
|---|---|---|---|---|
| ODBC 17 a předchozí OLEDB 18 a předchozí | Ne | Ne | Ano | Certifikát serveru není zkontrolován. Data odesílaná mezi klientem a serverem jsou šifrována. |
| ODBC 18 OLEDB 19 | Ne | Ne | Ano | Certifikát serveru je zkontrolován. Data odesílaná mezi klientem a serverem jsou šifrována. |
Myslím, že je to obecně dobrá věc, zvláště když jsou databáze Azure SQL stále běžnější, ale změna kontroly certifikátu SQL Server přináší změnu, zejména pro servery, které nemusí mít nastavené certifikáty. Ve výchozím nastavení bude používat certifikát podepsaný svým držitelem, který není tak bezpečný jako ten, který je důvěryhodný. U serverů, kde jsou připojení navazována přes internet, stojí za to zvláštní opatření.
Zde je srovnání připojovacích řetězců ODBC pro Microsoft Access se změnami SQL Serveru mezi předchozí verzí a nyní aktuální verzí:
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= ;
Připojovací řetězce OLEDB 18 vs. OLEDB 19 pro Microsoft Access s SQL Server
18:Provider= ;Data Source= ;Initial Catalog= ;
19:Provider= ;Data Source= ;Initial Catalog=
Všimněte si, že v předchozích verzích jste museli zadat Encrypt=yes ale to je nyní implicitní v aktuálních verzích.
Dobře, ale mám místní server, ale ten nefunguje s novými ovladači?
Kvůli změně v nastavení se nyní může zobrazit tato chyba:
V závislosti na scénáři a požadavcích jsou zde možná řešení:
- Nainstalujte a nakonfigurujte důvěryhodný certifikát na serveru.
- Upravte připojovací řetězec aplikace tak, aby zahrnoval
TrustServerCertificate=Yes. POUŽÍVEJTE OPATRNĚ - Upravte připojovací řetězec aplikace tak, aby zahrnoval
Encrypt=Noa deaktivujteForce Encryptionna serveru. NEDOPORUČUJEME - Neaktualizujte ovladače.
Kroky k vyřešení problému jsou podrobně popsány v odpovídajících částech.
Rozlišení
Nainstalujte a nakonfigurujte důvěryhodný certifikát na serveru
Je velmi důležité si uvědomit, že to, že máte server, který má nastavený platný certifikát SSL a je aktivně používán, ve skutečnosti neznamená, že stejný certifikát používá i SQL Server. Navíc se ukazuje, že SQL Server Configuration Manager je hrozný při manipulaci s certifikáty. Možná zjistíte, že neuvádí žádné certifikáty, které byste mohli použít:
Krátká verze je, že SQL Server Configuration Manager je příliš omezující na to, jaké certifikáty vypíše, což může být docela frustrující, zejména proto, že se jedná o problém uživatelského rozhraní, nikoli skutečný požadavek samotného SQL Serveru. Naštěstí můžeme toto hloupé omezení uživatelského rozhraní obejít přímou úpravou registru. To odpovídá klíči registru:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\<name of your instance>\MSSQLServer\SuperSocketNetLib
V tomto klíči je hodnota Certificate který očekává otisk certifikátu.
Můžete ručně vložit otisk certifikátu SSL, který chcete použít, ale doporučoval bych k tomu použít skript, protože se také musíme ujistit, že účet serveru má oprávnění k přístupu k certifikátu. Tento článek blogu jsem použil jako průvodce nastavením skriptu PowerShell k výběru certifikátu a jeho načtení do klíče registru serveru SQL Server a restartování služby. V závislosti na tom, kdo poskytuje váš certifikát SSL a na pracovním postupu, to možná budete chtít začlenit do některých dalších naplánovaných úloh, aby se po obnovení certifikátu SSL odpovídajícím způsobem aktualizoval klíč registru a oprávnění.
Pokud je vše správně nastaveno, měl by být váš server schopen používat nové ovladače bez jakýchkoli úprav připojovacího řetězce aplikace. Jako další ověření můžete zkontrolovat protokol chyb serveru SQL Server a vyhledat řádek jako tento:
<timestamp> spid11s The certificate [Cert Hash(sha1) "<certificate thumbprint>"] was successfully loaded for encryption.
Pokud se otisk palce shoduje s otiskem, který chcete použít, pak víte, že jste jej načetli správně, a tak je nyní vytvořen řetězec důvěry.
Upravte připojovací řetězec aplikace tak, aby zahrnoval TrustServerCertificate=Yes
Pokud však váš server není otočen k internetu a nastavení certifikátu SSL je příliš bolestivé, může být přijatelné zapnout TrustServerCertificate . To vyžaduje změnu připojovacího řetězce vaší aplikace. To aplikaci umožňuje povolit připojení k serveru bez ověřování certifikátu serveru. Pokud jste schopni s jistotou ovládat svou aplikaci tak, aby se nedostala mimo vaši síť, mělo by to být v pořádku. Mějte na paměti, že pokud je někdo schopen podvrhnout jméno serveru nebo IP v síti, klientské aplikace se slepě připojí k tomuto počítači. Z tohoto důvodu to nemůžeme doporučit, pokud je do připojení zapojen internet. Opravdu raději nebudeme riskovat.
Upravte připojovací řetězec aplikace tak, aby zahrnoval Encrypt=No a deaktivujte Force Encryption na serveru.
To je pro ty, kteří mají rádi pruhování na internetu s obřím neonovým nápisem „STEAL MY DATA! HNED MĚ UNESTE!" všem špatným hercům. To je ehm, „možnost“. Jediná věc, kterou mohu o této možnosti říci, je, že je mimořádně špatná. Tak špatné, že jsem zapomněl, jak to udělat. Jsi na to sám, kamaráde.
Neaktualizujte ovladače.
O něco lepší alternativou ve srovnání s předchozím je jednoduše neaktualizovat a zůstat u ovladačů ODBC 17 a OLEDB 18. To je však v nejlepším případě provizorní opatření. Toto rozlišení nevyžaduje žádné změny aplikace, ale to v nejlepším případě pouze oddálí nevyhnutelné změny. Čas můžete využít k prozkoumání cest, které vás dostanou k nejnovější verzi a náležitě ochrání vaše data.
Doufám, že to pomůže!