Excel prema partnerovom SQL Serveru bez domeinskog povjerenja

Excel radna knjiga koja otvara tabelu na SQL Serveru druge organizacije treba tri stvari o kojima se obično govori kao o jednoj: identitet koji server prihvata, transport koji klijent provjerava i mrežnu putanju koju obje strane dopuštaju. Domeinsko povjerenje jedan je način da se zadovolji prvo i najširi. TLS zadovoljava drugo i ne govori ništa o prvom. Putanja zadovoljava treće i sama po sebi ništa ne štiti.

Razdvajanje tih tri elemenata pretvara tabelu u mali zahtjev koji se može pregledati, umjesto administrativnog odnosa.

Tri odluke koje pitanje skriva

Identitet je ono što baza podataka misli da jeste: Windows račun iz pouzdane domene, SQL prijava sa vlastitom lozinkom ili identitet zasnovan na certifikatu. Transport je da li je sesija šifrirana i da li klijent provjerava lanac certifikata servera. Putanja je kako paketi stižu do listenera, a to može biti VPN, privatna veza ili javna krajnja tačka sa pravilima firewall-a. Svako živi na drugom mjestu i svako može pasti samo.

Povjerenje šume odgovara na prvo široko i predstavlja odnos između organizacija, a ne postavku za jednu radnu knjigu. Ono takođe ništa ne šifrira, što iznenađuje ljude koji su pretpostavili da je povjerenje sigurnosna kontrola.

Identitet bez povjerenja šume

Namjenski pripremljen račun u ciljnom okruženju može poslužiti užem zahtjevu bez ikakvog povjerenja, pod uslovom da ga klijentski tok rada može koristiti. SQL provjera identiteta drugi je uobičajen odgovor kada politika dopušta: prijava nosi vlastiti životni ciklus vjerodajnica, ne pridružuje se domenama i ne proizvodi integriranu Windows provjeru. Identitet zasnovan na certifikatu ili tokenu treća je opcija na novijim platformama. Šta god odabrali, dajte samo dozvole u bazi koje radna knjiga stvarno treba.

Preferirajte namjenski račun umjesto nečije lične prijave. Dijeljena vjerodajnica u tabeli je problem podrške koji čeka da se dogodi, a imenovani račun omogućava ukidanje kada projekt završi.

Šifriranje da, ali vjerovati certifikatu?

Uz ODBC Driver 18, Encrypt=Yes;TrustServerCertificate=No traži šifriranu sesiju čiji se certifikat zaista provjerava. Niz veze tada mora imenovati server koji certifikat pokriva, a klijent mora vjerovati njegovom lancu. Driver 18 takođe prema zadanim postavkama koristi šifriranje, za razliku od ranijih verzija, pa stari niz veze sada može pregovarati TLS bez da to kaže. Eksplicitne postavke čine namjeravanu politiku vidljivom na svim mašinama, što je važno kada nekoliko ljudi održava istu radnu knjigu.

TrustServerCertificate=Yes šifrira i preskače provjeru, što nije ekvivalentan popravak za nesklad imena ili nepouzdan lanac. On uklanja signal koji bi vam rekao da je klijent stigao na pogrešnu krajnju tačku, pa popravite certifikat ili ime.

Nametanje na strani servera odvojena je kontrola. Ako šifriranje mora važiti za svakog klijenta, konfigurirajte i provjerite postavku prisilnog šifriranja servera, jer jedan kooperativni niz veze ništa ne nameće.

Mrežna putanja nije zaštita

Privatni listener do kojeg se dolazi preko VPN-a smanjuje izloženost, a VPN mora nositi ispravne rute odredišta i povratka da bi to radilo. Tunel koji radi ne uklanja potrebu za provjerom identiteta ili provjerom certifikata, a TLS ne ograničava koji udaljeni sistemi mogu pokušati vezu. To su tri odvojena zapažanja: TLS rukovanje, VPN prijava i autorizirani upit. Samo treće dokazuje da je radna knjiga pročitala podatke koje joj je dopušteno čitati.

Zato se oduprite prečici da na pitanje povjerenja odgovorite izlaganjem baze internetu. Uski odgovor obično je namjenski račun, provjereno šifriranje i jedna odobrena putanja, tim redom.

Provjerite uobičajenim Excel tokom rada: prihvaćeni identitet, stvarne dozvole i pregovarano šifriranje, svako kroz vlastiti prikaz sesije servera.