SQL oor VPN: direkte kliënt of 'n interne werkstasie?

Spanne wil SSMS op hul skootrekenaars hê, en die vinnige oplossing is om die SQL-poort na die VPN-poel te publiseer. Die stadiger antwoord vra waar die kliëntproses moet loop, want direkte toegang en 'n interne werkstasie lewer verskillende bronadresse, eindpuntvertroue en datapaaie. Nie een is outomaties veilig nie, en VPN-lidmaatskap alleen besluit niks. Vergelyk die ontwerpe voordat daar 'n toelaatreël bestaan.

Twee paaie, twee bronadresse

Met direkte toegang dra die skootrekenaar die kliëntkonfigurasie en maak self die databasisverbinding oop. Met 'n afgeleë werkstasie maak die skootrekenaar 'n lessenaarsessie oop, en die werkstasie maak die SQL-verbinding vanaf sy eie adres. Die databasis sien dus die VPN-poel of 'n vertaalde poort in die eerste ontwerp, en die werkstasie se adres in die tweede. Daardie verskil bepaal watter firewallreël en watter SQL-regte werklik geld.

Die skootrekenaar beheer steeds die afgeleë sessie, dus is 'n werkstasie nie 'n plaasvervanger vir gebruikerverifikasie of sessiebeleid nie.

Kyk wat die databasis werklik sien

Die bronadres is iets om te meet eerder as om uit 'n diagram af te lei. Lees dit aan die bedienerkant van 'n lewendige verbinding.

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"

Die verbindingstoets bewys dat die luisteraar TCP van daardie netwerk aanvaar, terwyl die navraag bewys watter aanmelding en databasis die sessie bereik het. Om die adres te sien wat die bediener aangeteken het, vra sys.dm_exec_connections vir die huidige sessie, wat die kliëntadres na enige vertaling teruggee. As daardie waarde 'n poort is eerder as die skootrekenaar, kan 'n reël per gebruiker-gasheer nie op die databasis masjien werk nie. Skryf die waargenome waarde langs die gekose ontwerp, want herverbindings en poelveranderinge skuif dit.

Maak die luisteraar oop en niks meer nie

Maak net die diens oop wat die ontplooiing nodig het. Die bekende 1433 is die verstekinstansie se poort eerder as 'n universele konstante.

Get-NetTCPConnection -State Listen -LocalPort 1433

Benoemde instansies luister dikwels op 'n dinamiese poort, met SQL Server Browser wat ontdekking op UDP 1434 beantwoord, en daardie afhanklikheid is 'n aparte blootstelling om te regverdig. Om 'n vaste poort vir die instansie vas te pen, verwyder die behoefte aan Browser en maak firewallreëls stabiel. Hou die enkripsie- en sertifikaatkontroles wat die kliënt reeds doen, eerder as om hulle af te skakel om 'n toets te laat slaag. Gee dan databasisrolle vir die werklading eerder as om die hele VPN-groep by 'n bedienerrol te voeg.

Bewys die toegelate pad en die geweierde een

Maak 'n nuwe sessie oop as 'n gewone goedgekeurde gebruiker, en bevestig die bedieneridentiteit, die databasis en die vereiste bewerking. Bevestig dan die uitsluiting: 'n bron of rekening buite die beleid moet dieselfde toets faal. Vir die werkstasie-ontwerp, verifieer dat die skootrekenaar nie die grens kan omseil deur die databasis direk te bereik nie. Vir direkte toegang, verifieer dat die roete en bronreël na 'n herverbinding nog geld.

Teken aan waar die kliënt geloop het, watter bron die databasis waargeneem het en watter reël dit toegelaat het. Dit is die bewyse wat die volgende hersiening sal vra.