Excel do SQL Serverja partnerja brez zaupanja domene
Povezava Excel potrebuje sprejeto identiteto, preverjen TLS in eno omrežno pot. Samo prvo vključuje zaupanje domene; ostalo živi drugje.
Delovni zvezek Excel, ki odpre tabelo na SQL Serverju druge organizacije, potrebuje tri stvari, o katerih se običajno govori kot o eni: identiteto, ki jo strežnik sprejme, prenos, ki ga odjemalec preveri, in omrežno pot, ki jo dovolita obe strani. Zaupanje domene je eden od načinov za izpolnitev prvega in najširši. TLS izpolni drugega in o prvem ne pove nič. Pot izpolni tretjega in sama po sebi ničesar ne zaščiti.
Ločitev teh treh spremeni preglednico v majhno, pregledno zahtevo namesto v upravno razmerje.
Tri odločitve, ki jih vprašanje skriva
Identiteta je, kdo po mnenju zbirke podatkov ste: račun Windows iz zaupanja vredne domene, prijava SQL z lastnim geslom ali identiteta na podlagi potrdila. Prenos je, ali je seja šifrirana in ali odjemalec preverja verigo potrdil strežnika. Pot je, kako paketi dosežejo poslušalca, ki je lahko VPN, zasebna povezava ali javna končna točka s pravili požarnega zidu. Vsaka živi na drugem mestu in vsaka lahko spodleti sama.
Zaupanje gozda široko odgovori na prvo in je razmerje med organizacijami, ne nastavitev za en delovni zvezek. Prav tako ničesar ne šifrira, kar preseneti tiste, ki so mislili, da je zaupanje varnostni nadzor.
Identiteta brez zaupanja gozda
Namenoma pripravljen račun v ciljnem okolju lahko služi ožji zahtevi brez kakršnega koli zaupanja, če ga delovni tok odjemalca lahko uporabi. Preverjanje SQL je drug običajen odgovor, ko politika to dovoljuje: prijava nosi svoj življenjski cikel poverilnic in se ne pridruži domenam ter ne ustvari integriranega preverjanja Windows. Identiteta na podlagi potrdila ali žetona je tretja možnost na novejših platformah. Karkoli izberete, podelite le dovoljenja zbirke podatkov, ki jih delovni zvezek resnično potrebuje.
Raje imejte namenski račun kot nečijo osebno prijavo. Skupne poverilnice v preglednici so težava podpore, ki čaka, da se zgodi, poimenovani račun pa omogoči preklic, ko se projekt konča.
Šifriranje da, a zaupati potrdilu?
Z ODBC Driver 18 Encrypt=Yes;TrustServerCertificate=No zahteva šifrirano sejo, katere potrdilo se dejansko preveri. Povezovalni niz mora nato navesti strežnik, ki ga potrdilo pokriva, odjemalec pa mora zaupati njegovi verigi. Driver 18 tudi privzeto šifrira, za razliko od starejših različic, zato se stari povezovalni niz lahko zdaj pogaja za TLS, ne da bi to povedal. Izrecne nastavitve naredijo predvideno politiko vidno na vseh strojih, kar je pomembno, ko isto preglednico vzdržuje več ljudi.
TrustServerCertificate=Yes šifrira in preskoči preverjanje, kar ni enakovredno popravilo za neujemanje imena ali nezaupanja vredno verigo. Odstrani signal, ki bi vam povedal, da je odjemalec dosegel napačno končno točko, zato popravite potrdilo ali ime.
Vsiljevanje na strani strežnika je ločen nadzor. Če mora šifriranje veljati za vsakega odjemalca, nastavite in preverite nastavitev prisilnega šifriranja strežnika, saj en popustljiv povezovalni niz ničesar ne vsili.
Omrežna pot ni zaščita
Zasebni poslušalec, dosegljiv prek VPN, zmanjša izpostavljenost, in VPN mora prenašati prave ciljne in povratne poti, da to deluje. Delujoč tunel ne odpravi potrebe po preverjanju identitete ali preverjanju potrdila, TLS pa ne omejuje, kateri oddaljeni sistemi lahko poskusijo povezavo. To so tri ločena opažanja: rokovanje TLS, prijava VPN in pooblaščena poizvedba. Samo tretje dokaže, da je delovni zvezek prebral podatke, ki jih je smel brati.
Zato se uprite bližnjici, da na vprašanje zaupanja odgovorite z izpostavitvijo zbirke podatkov internetu. Ozek odgovor je običajno namenski račun, preverjeno šifriranje in ena odobrena pot, v tem vrstnem redu.
Preverite z običajnim delovnim tokom Excel: sprejeto identiteto, dejanska dovoljenja in izpogajano šifriranje, vsako prek pogleda seje samega strežnika.