Excel till en partners SQL Server utan domänförtroende

En Excel-arbetsbok som öppnar en tabell på en annan organisations SQL Server behöver tre saker som oftast diskuteras som en: en identitet servern accepterar, en transport klienten validerar och en nätverksväg båda sidor tillåter. Domänförtroende är ett sätt att uppfylla det första, och det bredaste. TLS uppfyller det andra och säger ingenting om det första. Vägen uppfyller det tredje och skyddar ingenting i sig själv.

Att skilja de tre gör kalkylarket till en liten, granskningsbar begäran i stället för en administrativ relation.

Tre beslut som frågan döljer

Identitet är vem databasen tror att du är: ett Windows-konto från en betrodd domän, en SQL-inloggning med eget lösenord eller en certifikatbaserad identitet. Transport är om sessionen är krypterad och om klienten kontrollerar serverns certifikatkedja. Väg är hur paketen når lyssnaren, som kan vara en VPN, en privat länk eller en offentlig slutpunkt med brandväggsregler. Var och en bor på olika ställen och var och en kan misslyckas själv.

Ett skogsförtroende svarar brett på det första och är en relation mellan organisationer, inte en inställning för en arbetsbok. Det krypterar inte heller någonting, vilket överraskar dem som antog att förtroendet var säkerhetskontrollen.

Identitet utan skogsförtroende

Ett medvetet förberett konto i målmiljön kan täcka ett snävare krav utan något förtroende, förutsatt att klientens arbetsflöde kan använda det. SQL-autentisering är det andra vanliga svaret när policyn tillåter: inloggningen bär sin egen livscykel för autentiseringsuppgifter och går inte med i domäner eller skapar Windows-integrerad autentisering. Certifikat- eller tokenbaserad identitet är ett tredje alternativ på nyare plattformar. Vad du än väljer, ge bara de databasbehörigheter arbetsboken faktiskt behöver.

Föredra ett dedikerat konto framför någons personliga inloggning. En delad autentiseringsuppgift i ett kalkylark är ett supportproblem som väntar på att inträffa, och ett namngivet konto gör återkallande möjligt när projektet slutar.

Kryptera ja, men lita på certifikatet?

Med ODBC Driver 18 begär Encrypt=Yes;TrustServerCertificate=No en krypterad session vars certifikat faktiskt kontrolleras. Anslutningssträngen måste då namnge den server certifikatet täcker, och klienten måste lita på dess kedja. Driver 18 krypterar också som standard, till skillnad från tidigare versioner, så en gammal anslutningssträng kan nu förhandla TLS utan att säga det. Uttryckliga inställningar gör den avsedda policyn synlig på alla maskiner, vilket spelar roll när flera personer underhåller samma arbetsbok.

TrustServerCertificate=Yes krypterar och hoppar över validering, vilket inte är en likvärdig reparation för en namnavvikelse eller en icke betrodd kedja. Det tar bort signalen som skulle ha sagt att klienten nådde fel slutpunkt, så rätta certifikatet eller namnet i stället.

Tvingande på serversidan är en separat kontroll. Om kryptering ska gälla för varje klient, konfigurera och verifiera serverns inställning för påtvingad kryptering, för en medgörlig anslutningssträng tvingar fram ingenting.

Nätverksvägen är inte skyddet

En privat lyssnare som nås via en VPN minskar exponeringen, och VPN:en måste bära rätt destinations- och returvägar för att det ska fungera. En fungerande tunnel tar inte bort behovet av autentisering eller certifikatvalidering, och TLS begränsar inte vilka fjärrsystem som får försöka ansluta. Det är tre separata observationer: ett TLS-handskak, en VPN-inloggning och en auktoriserad fråga. Bara den tredje bevisar att arbetsboken läste de data den hade tillstånd att läsa.

Motstå därför genvägen att svara på en förtroendefråga genom att exponera databasen mot internet. Det snäva svaret är oftast ett dedikerat konto, validerad kryptering och en godkänd väg, i den ordningen.

Verifiera med det vanliga Excel-arbetsflödet: den accepterade identiteten, de effektiva behörigheterna och den förhandlade krypteringen, var och en kontrollerad via serverns egen sessionsvy.