Excel k SQL Serveru partnera bez doménové důvěryhodnosti

Sešit Excelu, který otevírá tabulku na SQL Serveru jiné organizace, potřebuje tři věci, o nichž se obvykle mluví jako o jedné: identitu, kterou server přijme, přenos, který klient ověří, a síťovou cestu, kterou obě strany povolí. Doménová důvěryhodnost je jeden způsob, jak splnit první, a nejširší. TLS splňuje druhé a o prvním neříká nic. Cesta splňuje třetí a sama o sobě nic nechrání.

Oddělení těchto tří věcí mění tabulku v malý, přezkoumatelný požadavek místo administrativního vztahu.

Tři rozhodnutí, která otázka skrývá

Identita je to, kým si databáze myslí, že jste: účet Windows z důvěryhodné domény, přihlášení SQL s vlastním heslem nebo identita založená na certifikátu. Přenos je to, zda je relace šifrovaná a zda klient kontroluje řetězec certifikátů serveru. Cesta je to, jak pakety dorazí k naslouchajícímu konci, což může být VPN, soukromé propojení nebo veřejný koncový bod s pravidly firewallu. Každé žije jinde a každé může selhat samo.

Důvěryhodnost doménového lesa odpovídá na první široce a je vztahem mezi organizacemi, nikoli nastavením pro jeden sešit. Také nic nešifruje, což překvapí ty, kdo předpokládali, že důvěryhodnost je bezpečnostní kontrola.

Identita bez důvěryhodnosti lesa

Záměrně zřízený účet v cílovém prostředí může obsloužit užší požadavek bez jakékoli důvěry, pokud jej pracovní postup klienta dokáže použít. Ověřování SQL je druhá běžná odpověď, když to politika dovoluje: přihlášení nese vlastní životní cyklus přihlašovacích údajů a nepřipojuje se k doménám ani nevytváří integrované ověřování Windows. Identita založená na certifikátu nebo tokenu je třetí možnost na novějších platformách. Ať zvolíte kteroukoli, udělte jen databázová oprávnění, která sešit skutečně potřebuje.

Dejte přednost vyhrazenému účtu před něčím osobním přihlášením. Sdílené přihlašovací údaje v tabulce jsou problém podpory, který čeká na příležitost, a pojmenovaný účet umožňuje odvolání, až projekt skončí.

Šifrovat ano, ale věřit certifikátu?

S ODBC Driver 18 Encrypt=Yes;TrustServerCertificate=No žádá šifrovanou relaci, jejíž certifikát se skutečně kontroluje. Připojovací řetězec pak musí uvést server, který certifikát pokrývá, a klient musí důvěřovat jeho řetězci. Driver 18 také ve výchozím nastavení šifruje, na rozdíl od starších verzí, takže starý připojovací řetězec může nyní vyjednat TLS, aniž by to říkal. Explicitní nastavení činí zamýšlenou politiku viditelnou napříč stroji, což je důležité, když stejný sešit udržuje několik lidí.

TrustServerCertificate=Yes šifruje a přeskakuje ověření, což není rovnocenná oprava nesouladu názvu nebo nedůvěryhodného řetězce. Odstraňuje signál, který by vám řekl, že klient dosáhl nesprávného koncového bodu, takže opravte certifikát nebo název.

Vynucení na straně serveru je samostatná kontrola. Pokud má šifrování platit pro každého klienta, nakonfigurujte a ověřte nastavení vynuceného šifrování serveru, protože jeden vstřícný připojovací řetězec nic nevynutí.

Síťová cesta není ochrana

Soukromý naslouchající koncový bod dostupný přes VPN snižuje vystavení a VPN musí přenášet správné trasy cíle i návratu, aby to fungovalo. Fungující tunel neodstraňuje potřebu ověřování ani ověření certifikátu a TLS neomezuje, které vzdálené systémy se mohou pokusit o připojení. Jsou to tři samostatná pozorování: TLS handshake, přihlášení VPN a autorizovaný dotaz. Jen třetí dokazuje, že sešit přečetl data, která směl číst.

Proto se vzepřete zkratce odpovídat na otázku důvěryhodnosti vystavením databáze internetu. Úzká odpověď obvykle je vyhrazený účet, ověřené šifrování a jedna schválená cesta, v tomto pořadí.

Ověřte to běžným postupem v Excelu: přijatou identitu, skutečná oprávnění a vyjednané šifrování, každé přes vlastní pohled relace serveru.