Excel uz partnera SQL Server bez domēna uzticības

Excel darbgrāmatai, kas atver tabulu citas organizācijas SQL Server, vajadzīgas trīs lietas, par kurām parasti runā kā par vienu: identitāte, ko serveris pieņem, transports, ko klients validē, un tīkla ceļš, ko atļauj abas puses. Domēna uzticība ir viens veids, kā apmierināt pirmo, un visplašākais. TLS apmierina otro un neko nepasaka par pirmo. Ceļš apmierina trešo un pats par sevi neko neaizsargā.

Šo trīs atdalīšana pārvērš izklājlapu mazā, pārbaudāmā pieprasījumā, nevis administratīvās attiecībās.

Trīs lēmumi, ko jautājums slēpj

Identitāte ir tas, par ko datubāze uzskata jūs: Windows konts no uzticama domēna, SQL pieteikšanās ar savu paroli vai sertifikātā balstīta identitāte. Transports ir tas, vai sesija ir šifrēta un vai klients pārbauda servera sertifikātu ķēdi. Ceļš ir tas, kā paketes nonāk līdz klausītājam, kas var būt VPN, privāts savienojums vai publisks galapunkts ar ugunsmūra noteikumiem. Katrs dzīvo citā vietā, un katrs var neizdoties patstāvīgi.

Meža uzticība plaši atbild uz pirmo un ir attiecības starp organizācijām, nevis vienas darbgrāmatas iestatījums. Tā arī neko nešifrē, kas pārsteidz tos, kuri pieņēma, ka uzticība ir drošības kontrole.

Identitāte bez meža uzticības

Apzināti nodrošināts konts mērķa vidē var apmierināt šaurāku prasību bez jebkādas uzticības, ja vien klienta darbplūsma to var izmantot. SQL autentifikācija ir otra izplatītā atbilde, kad politika to atļauj: pieteikšanās nes savu akreditācijas datu dzīves ciklu un nepievienojas domēniem un neveido Windows integrēto autentifikāciju. Sertifikātā vai žetonā balstīta identitāte ir trešā iespēja jaunākās platformās. Ko vien izvēlaties, piešķiriet tikai tās datubāzes atļaujas, kas darbgrāmatai patiešām vajadzīgas.

Dodiet priekšroku īpašam kontam, nevis kāda personīgajai pieteikšanās. Kopīgi akreditācijas dati izklājlapā ir atbalsta problēma, kas gaida notikšanu, un nosaukts konts padara iespējamu atsaukšanu, kad projekts beidzas.

Šifrēt jā, bet uzticēties sertifikātam?

Ar ODBC Driver 18 Encrypt=Yes;TrustServerCertificate=No pieprasa šifrētu sesiju, kuras sertifikāts patiešām tiek pārbaudīts. Tad savienojuma virknei jānosauc serveris, ko sertifikāts aptver, un klientam jāuzticas tā ķēdei. Driver 18 arī pēc noklusējuma šifrē, atšķirībā no agrākām versijām, tāpēc veca savienojuma virkne tagad var vienoties par TLS, to nesakot. Skaidri iestatījumi padara paredzēto politiku redzamu visās mašīnās, kas ir svarīgi, ja vairāki cilvēki uztur vienu un to pašu darbgrāmatu.

TrustServerCertificate=Yes šifrē un izlaiž validāciju, kas nav līdzvērtīgs labojums nosaukuma neatbilstībai vai neuzticamai ķēdei. Tas noņem signālu, kas būtu pateicis, ka klients sasniedza nepareizo galapunktu, tāpēc labojiet sertifikātu vai nosaukumu.

Servera puses izpilde ir atsevišķa kontrole. Ja šifrēšanai jāattiecas uz katru klientu, konfigurējiet un pārbaudiet servera piespiedu šifrēšanas iestatījumu, jo viena sadarbspējīga savienojuma virkne neko neuzspiež.

Tīkla ceļš nav aizsardzība

Privāts klausītājs, kas sasniedzams caur VPN, samazina pakļautību, un, lai tas darbotos, VPN ir jāpārvadā pareizie galamērķa un atgriešanas maršruti. Darbojošs tunelis neatceļ autentifikācijas vai sertifikāta validācijas nepieciešamību, un TLS neierobežo, kuras attālinātās sistēmas var mēģināt savienojumu. Tie ir trīs atsevišķi novērojumi: TLS rokasspiediens, VPN pieteikšanās un autorizēts vaicājums. Tikai trešais pierāda, ka darbgrāmata lasīja datus, ko tai bija atļauts lasīt.

Tāpēc pretojieties tam, lai uz uzticības jautājumu atbildētu, atklājot datubāzi internetam. Šaurā atbilde parasti ir īpašs konts, validēta šifrēšana un viens apstiprināts ceļš, tieši tādā secībā.

Pārbaudiet ar parasto Excel darbplūsmu: pieņemto identitāti, faktiskās atļaujas un saskaņoto šifrēšanu, katru caur paša servera sesijas skatu.