En Excel-projektmappe, der åbner en tabel på en anden organisations SQL Server, har brug for tre ting, som ofte drøftes som én: en identitet, serveren accepterer, en transport, klienten validerer, og en netværksvej, begge sider tillader. Domænetillid er én måde at opfylde det første på og den bredeste. TLS opfylder det andet og siger intet om det første. Vejen opfylder det tredje og beskytter intet i sig selv.

At adskille de tre gør regnearket til en lille, gennemgangsvenlig anmodning i stedet for et administrativt forhold.

Tre beslutninger spørgsmålet skjuler

Identitet er, hvem databasen tror, du er: en Windows-konto fra et betroet domæne, et SQL-login med sin egen adgangskode eller en certifikatbaseret identitet. Transport er, om sessionen er krypteret, og om klienten kontrollerer serverens certifikatkæde. Vej er, hvordan pakker når lytteren, som kan være en VPN, et privat link eller et offentligt endepunkt med firewallregler. Hver bor et forskelligt sted, og hver kan fejle alene.

En skovtillid besvarer det første bredt og er et forhold mellem organisationer snarere end en indstilling for én projektmappe. Den krypterer heller intet, hvilket overrasker dem, der antog, at tilliden var sikkerhedskontrollen.

Identitet uden skovtillid

En bevidst oprettet konto i målmiljøet kan dække et snævrere krav uden nogen tillid, forudsat at klientens arbejdsgang kan bruge den. SQL-godkendelse er det andet almindelige svar, når politikken tillader det: loginet bærer sin egen livscyklus for legitimationsoplysninger og tilslutter sig ikke domæner eller skaber Windows-integreret godkendelse. Certifikat- eller tokenbaseret identitet er en tredje mulighed på nyere platforme. Uanset hvad du vælger, skal du kun give de databaseadgangstilladelser, som projektmappen faktisk har brug for.

Foretræk en dedikeret konto frem for nogens personlige login. En delt legitimationsoplysning i et regneark er et supportproblem, der venter på at ske, og en navngivet konto gør tilbagekaldelse mulig, når projektet slutter.

Kryptering ja, men stol på certifikatet?

Med ODBC Driver 18 anmoder Encrypt=Yes;TrustServerCertificate=No om en krypteret session, hvis certifikat faktisk kontrolleres. Forbindelsesstrengen skal derefter navngive den server, certifikatet dækker, og klienten skal stole på dens kæde. Driver 18 bruger også kryptering som standard, i modsætning til tidligere versioner, så en gammel forbindelsesstreng kan nu forhandle TLS uden at sige det. Eksplicitte indstillinger gør den tilsigtede politik synlig på tværs af maskiner, hvilket betyder noget, når flere personer vedligeholder den samme projektmappe.

TrustServerCertificate=Yes krypterer og springer validering over, hvilket ikke er en tilsvarende reparation af et navnemismatch eller en ikke-betroet kæde. Det fjerner det signal, der ville have fortalt dig, at klienten nåede det forkerte endepunkt, så ret certifikatet eller navnet i stedet.

Håndhævelse på serversiden er en separat kontrol. Hvis kryptering skal gælde for hver klient, skal du konfigurere og verificere serverens indstilling for tvungen kryptering, for én medgørlig forbindelsesstreng håndhæver intet.

Netværksvejen er ikke beskyttelsen

En privat lytter, der nås via en VPN, reducerer eksponeringen, og VPN’en skal bære de rigtige destinations- og returruter, for at det virker. En fungerende tunnel fjerner ikke behovet for godkendelse eller certifikatvalidering, og TLS begrænser ikke, hvilke fjernsystemer der kan forsøge en forbindelse. Det er tre separate observationer: et TLS-håndtryk, et VPN-login og en autoriseret forespørgsel. Kun det tredje beviser, at projektmappen læste de data, den havde tilladelse til at læse.

Så modstå genvejen at besvare et tillidsspørgsmål ved at eksponere databasen for internettet. Det snævre svar er normalt en dedikeret konto, valideret kryptering og én godkendt vej, i den rækkefølge.

Bekræft med den almindelige Excel-arbejdsgang: den accepterede identitet, de effektive tilladelser og den forhandlede kryptering, hver kontrolleret via serverens egen sessionsvisning.

Relaterede artikler