Excel til SQL Server hos ein partnar utan domenetillit

Ei Excel-arbeidsbok som opnar ei tabell på SQL Server-en til ein annan organisasjon, treng tre ting som vanlegvis blir drøfta som éin: ein identitet serveren godtek, ein transport klienten validerer, og ein nettverksveg begge sider tillèt. Domenetillit er éin måte å oppfylle det fyrste på, og den breiaste. TLS oppfyller det andre og seier ingenting om det fyrste. Vegen oppfyller det tredje og vernar ingenting i seg sjølv.

Å skilje dei tre gjer reknearket til ei lita, gjennomgåeleg førespurnad i staden for eit administrativt tilhøve.

Tre avgjerder spørsmålet skjuler

Identitet er kven databasen trur du er: ein Windows-konto frå eit klarert domene, ei SQL-innlogging med sitt eige passord, eller ein sertifikatbasert identitet. Transport er om økta er kryptert og om klienten kontrollerer sertifikatkjeda til serveren. Veg er korleis pakkane når lyttaren, som kan vere ein VPN, ei privat lenkje eller eit offentleg endepunkt med brannmurreglar. Kvar bur på ein annan stad, og kvar kan svikte åleine.

Ei skogtillit svarar breitt på det fyrste og er eit tilhøve mellom organisasjonar, ikkje ei innstilling for éi arbeidsbok. Ho krypterer heller ingenting, noko som overraskar dei som trudde tilliten var sikkerheitskontrollen.

Identitet utan skogtillit

Ein medvite lagd konto i målmgjevet kan dekkje eit trongare krav utan noka tillit, føresett at arbeidsflyten til klienten kan bruke han. SQL-autentisering er det andre vanlege svaret når policyen tillèt det: innlogginga ber sin eigen livssyklus for legitimasjon og blir ikkje med i domene eller lagar Windows-integrert autentisering. Sertifikat- eller tokenbasert identitet er eit tredje alternativ på nyare plattformer. Kva du enn vel, gje berre dei databasetillatingane arbeidsboka faktisk treng.

Føretrekk ein dedikert konto framfor nokon sin personlege innlogging. Ein delt legitimasjon i eit rekneark er eit støtteproblem som ventar på å skje, og ein namngjeven konto gjer tilbakekalling mogleg når prosjektet er over.

Kryptere ja, men stole på sertifikatet?

Med ODBC Driver 18 ber Encrypt=Yes;TrustServerCertificate=No om ei kryptert økt der sertifikatet faktisk blir kontrollert. Tilkoplingsstrengen må då nemne serveren sertifikatet dekkjer, og klienten må stole på kjeda. Driver 18 krypterer òg som standard, i motsetnad til tidlegare versjonar, så ein gammal tilkoplingsstreng kan no forhandle TLS utan å seie det. Eksplisitte innstillingar gjer den tiltenkte policyen synleg på tvers av maskiner, noko som tel når fleire personar vedlikeheld same arbeidsboka.

TrustServerCertificate=Yes krypterer og hoppar over validering, noko som ikkje er ei likeverdig reparasjon for eit namneavvik eller ei ikkje-klarert kjede. Det fjernar signalet som ville sagt deg at klienten nådde feil endepunkt, så rett sertifikatet eller namnet i staden.

Handheving på serversida er ein eigen kontroll. Viss kryptering skal gjelde for kvar klient, konfigurer og verifiser innstillinga for tvinga kryptering på serveren, for éin medgjerleg tilkoplingsstreng handhevar ingenting.

Nettverksvegen er ikkje vernet

Ein privat lyttar som ein når via ein VPN, reduserer eksponeringa, og VPN-en må bera dei rette destinasjons- og returrutene for at det skal verke. Ein fungerande tunnel fjernar ikkje behovet for autentisering eller sertifikatvalidering, og TLS avgrensar ikkje kva fjernsystem som kan freiste ei tilkopling. Det er tre separate observasjonar: eit TLS-handtrykk, ei VPN-innlogging og ei autorisert spørjing. Berre den tredje provar at arbeidsboka las dataa ho hadde lov til å lese.

Så motstå snarvegen med å svare på eit tillitsspørsmål ved å eksponere databasen for internett. Det tronge svaret er vanlegvis ein dedikert konto, validert kryptering og éin godkjend veg, i den rekkjefølgja.

Verifiser med den vanlege Excel-arbeidsflyten: den godtekne identiteten, dei effektive tillatingane og den forhandla krypteringa, kvar kontrollert gjennom øktvisinga til serveren sjølv.