Remediați eroarea de criptare SQL Server - Soluție cu un singur clic

Aceeași soluție în interiorul unui șir de conexiune la aplicație

Dacă o aplicație eșuează în loc de SSMS, același comutator se află în șirul său de conexiune. Adăugați cele două setări în mod explicit - Encrypt=True activează canalul protejat, iar TrustServerCertificate=True este ortografia șirului de conexiune din caseta de selectare SSMS:

Server=SQL01;Database=AppDB;User Id=appuser;Password=YourPassword;Encrypt=True;TrustServerCertificate=True;

Utilizați propriul nume de server, baza de date și autentificare în locul valorilor exemplu. Compensația este exact aceeași cu caseta de selectare din Pasul 2, cu un pericol suplimentar: inclusă în configurația unei aplicații livrate, verificarea omisă se aplică fiecărui utilizator, în mod invizibil și permanent. Păstrați-l în configurațiile de dezvoltare și de punere în pas și, în producție, tratați-l ca timp împrumutat până când certificatul de server din Pasul 4 este în vigoare.

Soluția corectă - Oferiți serverului un certificat real

Reparația permanentă are loc o dată, pe server, iar apoi fiecare client se conectează strict, fără casetă de selectare și fără avertisment. Mai întâi, obțineți un certificat pentru numele DNS complet al serverului (de exemplu, sql01.company.local) de la autoritatea de certificare internă sau de la un CA public, cu utilizarea Autentificarea serverului. Importați-l, cu cheia sa privată, în depozitul de certificate Computer local de pe computerul SQL Server. Apoi faceți clic dreapta pe certificat, alegeți Toate sarcinile → Gestionați cheile private și acordați contului de serviciu SQL Server permisiunea Citire pe cheia privată. Deschideți SQL Server Configuration Manager, extindeți SQL Server Network Configuration, faceți clic dreapta pe Protocols for MSSQLSERVER, alegeți Properties și selectați certificatul din fila Certificat. În fila Flags, puteți seta, de asemenea, ForceEncryption la Da, astfel încât fiecare client trebuie să cripteze. Reporniți serviciul SQL Server - modificarea nu face nimic până când nu o faceți.

Verificați opțiunea Fix the Strict Way

O autentificare care reușește în liniște se dovedește mai puțin decât cred oamenii, deoarece unele combinații de setări se conectează fără protecție reală. Demonstrați ambele jumătăți. Mai întâi, reconectați-vă de la un client în modul strict: conectați-vă folosind numele DNS al serverului - numele din interiorul certificatului - setați criptarea la Obligatoriu și lăsați Certificat server de încredere nebifat. Conectarea ar trebui să reușească fără avertisment. Apoi, în aceeași sesiune, întrebați serverul dacă conexiunea este de fapt criptată, rulând această interogare în SSMS:

SELECT session_id, encrypt_option, auth_scheme FROM sys.dm_exec_connections WHERE session_id = @@SPID;

encrypt_option care arată TRUE este nota de promovare. FALSE cu o autentificare funcțională înseamnă că conexiunea a reușit prin eliminarea protecției și lucrarea nu este finalizată. Acest test de trecere este adevărata linie de sosire: orice client configurat corect, inclusiv versiunile viitoare SSMS, se conectează acum cu validare completă și fără setări speciale.