Excel al SQL Server de partnero sen domajna fido

Excel-labortabelo, kiu malfermas tabelon ĉe SQL Server de alia organizo, bezonas tri aferojn kutime diskutatajn kiel unu: identecon, kiun la servilo akceptas, transporton, kiun la kliento validigas, kaj retan vojon, kiun ambaŭ flankoj permesas. Domajna fido estas unu maniero kontentigi la unuan, kaj la plej larĝa. TLS kontentigas la duan kaj diras nenion pri la unua. La vojo kontentigas la trian kaj protektas nenion per si mem.

Disigi la tri igas la kalkultabelon malgranda, revidebla peto anstataŭ administra rilato.

Tri decidoj, kiujn la demando kaŝas

Identeco estas, kion la datumbazo kredas, ke vi estas: Windows-konto el fidinda domajno, SQL-saluto kun propra pasvorto, aŭ identeco bazita sur atestilo. Transporto estas, ĉu la seanco estas ĉifrita kaj ĉu la kliento kontrolas la atestilan ĉenon de la servilo. Vojo estas, kiel pakaĵoj atingas la aŭskultanton, kiu povas esti VPN, privata ligilo aŭ publika finpunkto kun fajromuraj reguloj. Ĉiu loĝas aliloke kaj ĉiu povas malsukcesi sole.

Arbara fido respondas la unuan larĝe kaj estas rilato inter organizoj, ne agordo por unu labortabelo. Ĝi ankaŭ ĉifras nenion, kio surprizas tiujn, kiuj supozis, ke la fido estis la sekureca kontrolo.

Identeco sen arbara fido

Intence providita konto en la cela medio povas servi pli mallarĝan postulon sen ajna fido, kondiĉe ke la laborfluo de la kliento povas uzi ĝin. SQL-aŭtentikigo estas la alia komuna respondo, kiam politiko permesas: la saluto portas sian propran vivciklon de akreditaĵoj kaj ne aliĝas al domajnoj nek produktas integritan Windows-aŭtentikigon. Atestila aŭ ĵetona identeco estas tria opcio sur pli novaj platformoj. Kion ajn vi elektos, donu nur la datumbazajn permesojn, kiujn la labortabelo vere bezonas.

Preferu dediĉitan konton anstataŭ ies personan saluton. Komunigita akreditaĵo en kalkultabelo estas subtena problemo atendanta okazi, kaj nomita konto ebligas revokon, kiam la projekto finiĝos.

Ĉifri jes, sed fidi la atestilon?

Kun ODBC Driver 18, Encrypt=Yes;TrustServerCertificate=No petas ĉifritan seancon, kies atestilo estas efektive kontrolata. La konekta ĉeno tiam devas nomi la servilon, kiun la atestilo kovras, kaj la kliento devas fidi ĝian ĉenon. Driver 18 ankaŭ defaŭlte ĉifras, malkiel pli fruaj versioj, do malnova konekta ĉeno nun povas intertrakti TLS sen diri tion. Eksplicitaj agordoj igas la celatan politikon videbla trans maŝinoj, kio gravas, kiam pluraj homoj prizorgas la saman labortabelon.

TrustServerCertificate=Yes ĉifras kaj preterlasas validigon, kio ne estas ekvivalenta riparo por nommiskongruo aŭ nefidinda ĉeno. Ĝi forigas la signalon, kiu dirus al vi, ke la kliento atingis la malĝustan finpunkton, do riparu la atestilon aŭ la nomon.

Devigo ĉe la servila flanko estas aparta kontrolo. Se ĉifrado devas validi por ĉiu kliento, agordu kaj kontrolu la devigan ĉifradon de la servilo, ĉar unu kunlabora konekta ĉeno devigas nenion.

La reta vojo ne estas la protekto

Privata aŭskultanto atingata tra VPN malpliigas ekspozicion, kaj la VPN devas porti la ĝustajn celajn kaj revenajn vojojn por ke tio funkciu. Funkcianta tunelo ne forigas la bezonon de aŭtentikigo aŭ atestila validigo, kaj TLS ne limigas, kiuj malproksimaj sistemoj povas provi konekton. Tiuj estas tri apartaj observoj: TLS-manpremo, VPN-saluto kaj rajtigita informpeto. Nur la tria pruvas, ke la labortabelo legis la datumojn, kiujn ĝi rajtis legi.

Rezistu do la fuŝsolvon respondi demando pri fido per elmeto de la datumbazo al la interreto. La mallarĝa respondo kutime estas dediĉita konto, validigita ĉifrado kaj unu aprobita vojo, en tiu ordo.

Kontrolu per la kutima Excel-laborfluo: la akceptitan identecon, la efektivajn permesojn kaj la intertraktitan ĉifradon, ĉiun tra la propra seanca vido de la servilo.