SQL tra VPN: rekta kliento aŭ interna laborejo?

Teamoj volas SSMS sur siaj porteblaj komputiloj, kaj la rapida solvo estas publikigi la SQL-pordon al la VPN-poolo. La pli malrapida respondo demandas, kie la klienta procezo devus kuri, ĉar rekta aliro kaj interna laborejo produktas malsamajn fontajn adresojn, finpunktan fidon kaj datovojojn. Neniu el la du estas aŭtomate sekura, kaj VPN-membreco sola decidas nenion. Komparu la dezajnojn antaŭ ol ekzistas permesa regulo.

Du vojoj, du fontaj adresoj

Ĉe rekta aliro la portebla komputilo portas la klientan agordon kaj mem malfermas la datumbazan konekton. Ĉe fora laborejo la portebla komputilo malfermas labortablan seancon, kaj la laborejo faras la SQL-konekton el sia propra adreso. La datumbazo do vidas la VPN-poolon aŭ tradukitan pordegon en la unua dezajno, kaj la adreson de la laborejo en la dua. Tiu diferenco decidas, kiun fajroŝirmilan regulon kaj kiun SQL-permeson efektive apliki.

La portebla komputilo ankoraŭ regas la foran seancon, do laborejo ne anstataŭas uzantidentigon aŭ seanpolitikon.

Kontrolu, kion la datumbazo efektive vidas

La fonta adreso estas io mezurebla, ne deduktebla el diagramo. Legu ĝin el la servila flanko de aktiva konekto.

Test-NetConnection sql.example.com -Port 1433
sqlcmd -S tcp:sql.example.com,1433 -N -d appdb -Q "select SUSER_SNAME() as login_name, DB_NAME() as db"

La konekta testo pruvas, ke la aŭskultanto akceptas TCP el tiu reto, dum la demando pruvas, kiun saluton kaj datumbazon la seanco atingis. Por vidi la adreson, kiun la servilo registris, demandu sys.dm_exec_connections por la nuna seanco, kiu redonas la klientan adreson post iu ajn traduko. Se tiu valoro estas pordego anstataŭ la portebla komputilo, regulo de gastiganto por unu uzanto ne povas funkcii sur la datumbaza maŝino. Skribu la observitan valoron apud la elektita dezajno, ĉar rekonektoj kaj pool-ŝanĝoj movas ĝin.

Malfermu la aŭskultanton kaj nenion plian

Malfermu nur la servon, kiun la deplojo bezonas. La konata 1433 estas la pordo de la defaŭlta instanco, ne universala konstanto.

Get-NetTCPConnection -State Listen -LocalPort 1433

Nomitaj instancoj ofte aŭskultas sur dinamika pordo, kun SQL Server Browser respondanta al malkovro per UDP 1434, kaj tiu dependeco estas aparta elmontro, kiun oni devas pravigi. Fiksado de konstanta pordo por la instanco forigas la bezonon de Browser kaj stabiligas fajroŝirmilajn regulojn. Konservu la ĉifradajn kaj atestilajn kontrolojn, kiujn la kliento jam faras, anstataŭ malŝalti ilin por ke testo sukcesu. Poste donu datumbazajn rolojn por la laborŝarĝo anstataŭ aldoni la tutan VPN-grupon al servila rolo.

Pruvu la permesitan vojon kaj la rifuzitan

Malfermu novan seancon kiel ordinara aprobita uzanto, kaj konfirmu la servilan identecon, la datumbazon kaj la postulatan operacion. Poste konfirmu la ekskludon: fonto aŭ konto ekster la politiko devas malsukcesi en la sama testo. Por la laboreja dezajno, kontrolu, ke la portebla komputilo ne povas ĉirkaŭiri la limon per rekta atingado de la datumbazo. Por rekta aliro, kontrolu, ke la itinero kaj fonta regulo ankoraŭ validas post rekonekto.

Registru, kie la kliento kuris, kiun fonton la datumbazo observis kaj kiu regulo permesis ĝin. Tio estas la pruvaro, kiun la sekva revizio petos.