Excel til en partners SQL Server uten domenetillit

En Excel-arbeidsbok som åpner en tabell på en annen organisasjons SQL Server, trenger tre ting som vanligvis diskuteres som én: en identitet serveren godtar, en transport klienten validerer, og en nettverksvei begge sider tillater. Domenetillit er én måte å oppfylle det første på, og den bredeste. TLS oppfyller det andre og sier ingenting om det første. Veien oppfyller det tredje og beskytter ingenting i seg selv.

Å skille de tre gjør regnearket til en liten, gjennomgåelig forespørsel i stedet for et administrativt forhold.

Tre beslutninger spørsmålet skjuler

Identitet er hvem databasen tror du er: en Windows-konto fra et klarert domene, en SQL-innlogging med sitt eget passord, eller en sertifikatbasert identitet. Transport er om økten er kryptert og om klienten kontrollerer serverens sertifikatkjede. Vei er hvordan pakkene når lytteren, som kan være en VPN, en privat lenke eller et offentlig endepunkt med brannmurregler. Hver bor på et annet sted, og hver kan svikte alene.

En skogtillit svarer bredt på det første og er et forhold mellom organisasjoner, ikke en innstilling for én arbeidsbok. Den krypterer heller ingenting, noe som overrasker dem som antok at tilliten var sikkerhetskontrollen.

Identitet uten skogtillit

En bevisst tilrettelagt konto i målmiljøet kan dekke et snevrere krav uten noen tillit, forutsatt at klientens arbeidsflyt kan bruke den. SQL-autentisering er det andre vanlige svaret når policyen tillater det: innloggingen bærer sin egen livssyklus for legitimasjon og blir ikke med i domener eller produserer Windows-integrert autentisering. Sertifikat- eller tokenbasert identitet er et tredje alternativ på nyere plattformer. Uansett hva du velger, gi bare de databasetillatelsene arbeidsboken faktisk trenger.

Foretrekk en dedikert konto fremfor noens personlige innlogging. En delt legitimasjon i et regneark er et støtteproblem som venter på å skje, og en navngitt konto gjør tilbakekalling mulig når prosjektet er over.

Kryptere ja, men stole på sertifikatet?

Med ODBC Driver 18 ber Encrypt=Yes;TrustServerCertificate=No om en kryptert økt der sertifikatet faktisk kontrolleres. Tilkoblingsstrengen må da navngi serveren sertifikatet dekker, og klienten må stole på kjeden. Driver 18 krypterer også som standard, i motsetning til tidligere versjoner, så en gammel tilkoblingsstreng kan nå forhandle TLS uten å si det. Eksplisitte innstillinger gjør den tiltenkte policyen synlig på tvers av maskiner, noe som betyr noe når flere personer vedlikeholder samme arbeidsbok.

TrustServerCertificate=Yes krypterer og hopper over validering, noe som ikke er en likeverdig reparasjon for et navneavvik eller en ikke-klarert kjede. Det fjerner signalet som ville fortalt deg at klienten nådde feil endepunkt, så rett sertifikatet eller navnet i stedet.

Håndheving på serversiden er en egen kontroll. Hvis kryptering skal gjelde for hver klient, konfigurer og verifiser serverens innstilling for tvungen kryptering, for én medgjørlig tilkoblingsstreng håndhever ingenting.

Nettverksveien er ikke beskyttelsen

En privat lytter som nås via en VPN, reduserer eksponeringen, og VPN-en må bære de riktige destinasjons- og returrutene for at det skal virke. En fungerende tunnel fjerner ikke behovet for autentisering eller sertifikatvalidering, og TLS begrenser ikke hvilke fjernsystemer som kan forsøke en tilkobling. Det er tre separate observasjoner: et TLS-håndtrykk, en VPN-innlogging og en autorisert spørring. Bare den tredje beviser at arbeidsboken leste dataene den hadde lov til å lese.

Så motstå snarveien med å svare på et tillitsspørsmål ved å eksponere databasen for internett. Det smale svaret er vanligvis en dedikert konto, validert kryptering og én godkjent vei, i den rekkefølgen.

Verifiser med den vanlige Excel-arbeidsflyten: den aksepterte identiteten, de effektive tillatelsene og den forhandlede krypteringen, hver kontrollert gjennom serverens egen øktvisning.