SQL per VPN: tiesioginis klientas ar vidinė darbo stotis?

Komandos nori SSMS savo nešiojamuosiuose kompiuteriuose, o greitas sprendimas – paskelbti SQL prievadą VPN telkinyje. Lėtesnis atsakymas klausia, kur turėtų veikti kliento procesas, nes tiesioginė prieiga ir vidinė darbo stotis sukuria skirtingus šaltinio adresus, galinio taško pasitikėjimą ir duomenų kelius. Nė vienas nėra automatiškai saugus, o vien VPN narystė nieko nenusprendžia. Palyginkite projektus prieš atsirandant leidimo taisyklei.

Du keliai, du šaltinio adresai

Tiesioginės prieigos atveju nešiojamasis kompiuteris neša kliento konfigūraciją ir pats atidaro duomenų bazės ryšį. Nuotolinėje darbo stotyje nešiojamasis kompiuteris atidaro darbalaukio sesiją, o darbo stotis užmezga SQL ryšį iš savo adreso. Todėl duomenų bazė pirmame projekte mato VPN telkinį arba išverstus vartus, o antrame – darbo stoties adresą. Šis skirtumas nusprendžia, kuri ugniasienės taisyklė ir kuris SQL leidimas iš tikrųjų taikomi.

Nešiojamasis kompiuteris vis dar valdo nuotolinę sesiją, todėl darbo stotis nepakeičia naudotojo autentifikavimo ar sesijos politikos.

Patikrinkite, ką duomenų bazė iš tikrųjų mato

Šaltinio adresas yra matuojamas, o ne išvedamas iš diagramos. Perskaitykite jį aktyvaus ryšio serverio pusėje.

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"

Ryšio testas įrodo, kad klausytojas priima TCP iš to tinklo, o užklausa įrodo, kurią prisijungimo paskyrą ir duomenų bazę pasiekė sesija. Norėdami pamatyti serverio užfiksuotą adresą, užklauskite sys.dm_exec_connections dabartinei sesijai; tai grąžina kliento adresą po bet kokio vertimo. Jei ši reikšmė yra vartai, o ne nešiojamasis kompiuteris, taisyklė, skirta vienam naudotojui, negali veikti duomenų bazės kompiuteryje. Užrašykite stebėtą reikšmę prie pasirinkto projekto, nes pakartotiniai prisijungimai ir telkinio pokyčiai ją perstumia.

Atidarykite klausytoją ir nieko daugiau

Atidarykite tik tą paslaugą, kurios reikia diegimui. Įprastas 1433 yra numatytosios instancijos prievadas, o ne universali konstanta.

Get-NetTCPConnection -State Listen -LocalPort 1433

Pavadintos instancijos dažnai klausosi dinaminio prievado, o SQL Server Browser atsako į aptikimą per UDP 1434, ir ši priklausomybė yra atskira ekspozicija, kurią reikia pagrįsti. Fiksuoto prievado priskyrimas instancijai pašalina Browser poreikį ir padaro ugniasienės taisykles stabilias. Išsaugokite šifravimo ir sertifikatų patikras, kurias klientas jau atlieka, o ne išjunkite jas, kad testas praeitų. Tada skirkite duomenų bazės roles darbo krūviui, o ne pridėkite visą VPN grupę prie serverio rolės.

Įrodykite leistiną kelią ir uždraustąjį

Atidarykite naują sesiją kaip eilinis patvirtintas naudotojas ir patvirtinkite serverio tapatybę, duomenų bazę ir reikiamą operaciją. Tada patvirtinkite išimtį: šaltinis arba paskyra, esanti už politikos ribų, turi nepraeiti to paties testo. Darbo stoties projektui patikrinkite, ar nešiojamasis kompiuteris negali apeiti ribos, pasiekdamas duomenų bazę tiesiogiai. Tiesioginei prieigai patikrinkite, ar maršrutas ir šaltinio taisyklė tebegalioja po pakartotinio prisijungimo.

Užrašykite, kur klientas veikė, kokį šaltinį duomenų bazė stebėjo ir kuri taisyklė tai leido. Tai įrodymai, kurių paprašys kitas vertinimas.