Excel partneri SQL Serverisse ilma domeeni usalduseta
Exceli ühendus vajab aktsepteeritud identiteeti, valideeritud TLS-i ja ühte võrguteed. Ainult esimene hõlmab domeeni usaldust; ülejäänu asub mujal.
Exceli töövihik, mis avab tabeli teise organisatsiooni SQL Serveris, vajab kolme asja, mida tavaliselt käsitletakse ühena: identiteeti, mille server aktsepteerib, transporti, mida klient valideerib, ja võrguteed, mille mõlemad pooled lubavad. Domeeni usaldus on üks viis esimese rahuldamiseks ja kõige laiem. TLS rahuldab teise ega ütle esimese kohta midagi. Tee rahuldab kolmanda ega kaitse iseenesest midagi.
Nende kolme eraldamine muudab tabeli väikeseks, ülevaatatavaks taotluseks administratiivse suhte asemel.
Kolm otsust, mida küsimus varjab
Identiteet on see, kelleks andmebaas teid peab: Windowsi konto usaldusväärsest domeenist, SQL-sisselogimine oma parooliga või sertifikaadipõhine identiteet. Transport on see, kas seanss on krüpteeritud ja kas klient kontrollib serveri sertifikaadiahelat. Tee on see, kuidas paketid jõuavad kuulajani, milleks võib olla VPN, privaatne ühendus või avalik lõpp-punkt tulemüürireeglitega. Igaüks elab eri kohas ja igaüks võib iseseisvalt ebaõnnestuda.
Metsa usaldus vastab esimesele laialt ja on organisatsioonidevaheline suhe, mitte ühe töövihiku säte. See ei krüpteeri ka midagi, mis üllatab neid, kes eeldasid, et usaldus oli turvakontroll.
Identiteet ilma metsa usalduseta
Sihipäraselt loodud konto sihtkeskkonnas võib teenindada kitsamat nõuet ilma igasuguse usalduseta, eeldusel et kliendi töövoog saab seda kasutada. SQL-autentimine on teine tavaline vastus, kui poliitika seda lubab: sisselogimine kannab oma volituste elutsüklit ega liitu domeenidega ega too kaasa Windowsi integreeritud autentimist. Sertifikaadi- või loendipõhine identiteet on uuemal platvormil kolmas võimalus. Mida iganes valite, andke ainult need andmebaasiõigused, mida töövihik tegelikult vajab.
Eelistage pühendatud kontot kellegi isiklikule sisselogimisele. Tabelis jagatud volitus on tugiprobleem, mis ootab juhtumist, ja nimega konto teeb tühistamise võimalikuks, kui projekt lõpeb.
Krüpteerimine jah, aga kas usaldada sertifikaati?
ODBC Driver 18 puhul nõuab Encrypt=Yes;TrustServerCertificate=No krüpteeritud seanssi, mille sertifikaati tõesti kontrollitakse. Ühendusstring peab siis nimetama serveri, mida sertifikaat katab, ja klient peab usaldama selle ahelat. Driver 18 kasutab vaikimisi ka krüpteerimist, erinevalt varasematest versioonidest, seega vana ühendusstring võib nüüd TLS-i läbi rääkida seda ütlemata. Selgesõnalised sätted teevad kavatsetud poliitika masinate vahel nähtavaks, mis loeb siis, kui mitmed inimesed sama töövihikut hooldavad.
TrustServerCertificate=Yes krüpteerib ja jätab valideerimise vahele, mis ei ole samaväärne parandus nime lahknevuse või mitteusaldusväärse ahela jaoks. See eemaldab signaali, mis oleks teile öelnud, et klient jõudis vale lõpp-punkti, seega parandage sertifikaat või nimi.
Serveripoolne jõustamine on eraldi kontroll. Kui krüpteerimine peab kehtima iga kliendi jaoks, seadistage ja kontrollige serveri sunnitud krüpteerimise sätet, sest üks koostööaldis ühendusstring ei jõusta midagi.
Võrgutee ei ole kaitse
VPN-i kaudu saavutatav privaatne kuulaja vähendab avatust ja VPN peab selle toimimiseks kandma õigeid siht- ja tagasitee marsruute. Töötav tunnel ei kõrvalda autentimise ega sertifikaadi valideerimise vajadust ning TLS ei piira, millised kaugsüsteemid võivad ühendust proovida. Need on kolm eraldi tähelepanekut: TLS-i kätlus, VPN-i sisselogimine ja volitatud päring. Ainult kolmas tõestab, et töövihik luges andmeid, mida tal oli lubatud lugeda.
Seiske vastu lühiühendusele vastata usaldusküsimusele andmebaasi internetti paljastades. Kitsas vastus on tavaliselt pühendatud konto, valideeritud krüpteerimine ja üks heakskiidetud tee, selles järjekorras.
Kontrollige tavapärase Exceli töövooga: aktsepteeritud identiteet, tegelikud õigused ja läbiräägitud krüpteerimine, igaüks serveri enda seansi vaate kaudu.