Excel către SQL Server-ul unui partener fără încredere de domeniu

Un registru de lucru Excel care deschide un tabel pe SQL Server-ul altei organizații are nevoie de trei lucruri discutate de obicei ca unul singur: o identitate pe care serverul o acceptă, un transport pe care clientul îl validează și o cale de rețea pe care ambele părți o permit. Încrederea de domeniu este o modalitate de a îndeplini primul, și cea mai largă. TLS îl îndeplinește pe al doilea și nu spune nimic despre primul. Calea îl îndeplinește pe al treilea și nu protejează nimic în sine.

Separarea celor trei transformă foaia de calcul într-o cerere mică și verificabilă în locul unei relații administrative.

Trei decizii pe care întrebarea le ascunde

Identitatea este cine crede baza de date că sunteți: un cont Windows dintr-un domeniu de încredere, o autentificare SQL cu propria parolă sau o identitate bazată pe certificat. Transportul este dacă sesiunea este criptată și dacă clientul verifică lanțul de certificate al serverului. Calea este modul în care pachetele ajung la ascultător, care poate fi un VPN, o legătură privată sau un punct final public cu reguli de firewall. Fiecare trăiește într-un loc diferit și fiecare poate eșua singur.

O încredere de pădure răspunde larg la prima și este o relație între organizații, nu o setare pentru un singur registru. De asemenea, nu criptează nimic, ceea ce îi surprinde pe cei care presupuneau că încrederea era controlul de securitate.

Identitate fără încredere de pădure

Un cont pregătit intenționat în mediul țintă poate acoperi o cerință mai îngustă fără nicio încredere, cu condiția ca fluxul de lucru al clientului să îl poată folosi. Autentificarea SQL este celălalt răspuns obișnuit când politica o permite: autentificarea poartă propriul ciclu de viață al acreditărilor și nu se alătură domeniilor și nu produce autentificare Windows integrată. Identitatea bazată pe certificat sau token este o a treia opțiune pe platformele mai noi. Orice ați alege, acordați doar permisiunile de bază de date de care registrul are cu adevărat nevoie.

Preferați un cont dedicat în locul autentificării personale a cuiva. O acreditare partajată într-o foaie de calcul este o problemă de suport care așteaptă să apară, iar un cont cu nume face posibilă revocarea la finalul proiectului.

Criptare da, dar să avem încredere în certificat?

Cu ODBC Driver 18, Encrypt=Yes;TrustServerCertificate=No cere o sesiune criptată al cărei certificat este într-adevăr verificat. Șirul de conexiune trebuie atunci să numească serverul acoperit de certificat, iar clientul trebuie să aibă încredere în lanțul acestuia. Driver 18 criptează și implicit, spre deosebire de versiunile anterioare, așa că un șir de conexiune vechi poate negocia acum TLS fără să spună acest lucru. Setările explicite fac politica dorită vizibilă pe toate mașinile, ceea ce contează când mai multe persoane întrețin același registru.

TrustServerCertificate=Yes criptează și omite validarea, ceea ce nu este o remediere echivalentă pentru o nepotrivire de nume sau un lanț neîncrezut. Elimină semnalul care v-ar fi spus că clientul a ajuns la punctul final greșit, așa că remediați certificatul sau numele.

Aplicarea pe partea serverului este un control separat. Dacă criptarea trebuie să se aplice fiecărui client, configurați și verificați setarea de criptare forțată a serverului, pentru că un singur șir de conexiune cooperant nu impune nimic.

Calea de rețea nu este protecția

Un ascultător privat accesat printr-un VPN reduce expunerea, iar VPN-ul trebuie să transporte rutele corecte de destinație și de retur pentru ca acest lucru să funcționeze. Un tunel funcțional nu elimină nevoia de autentificare sau de validare a certificatului, iar TLS nu restricționează ce sisteme la distanță pot încerca o conexiune. Sunt trei observații separate: un handshake TLS, o autentificare VPN și o interogare autorizată. Doar a treia demonstrează că registrul a citit datele pe care avea voie să le citească.

Așadar, împotriviți-vă scurtăturii de a răspunde la o întrebare despre încredere expunând baza de date pe internet. Răspunsul îngust este de obicei un cont dedicat, criptare validată și o singură cale aprobată, în această ordine.

Verificați cu fluxul obișnuit Excel: identitatea acceptată, permisiunile efective și criptarea negociată, fiecare prin vizualizarea de sesiune a serverului însuși.