SQL VPN:n yli: suora asiakas vai sisäinen työasema?

Tiimit haluavat SSMS:n kannettaviinsa, ja nopea ratkaisu on julkaista SQL-portti VPN-pooliin. Hitaampi vastaus kysyy, missä asiakasprosessin pitäisi ajaa, koska suora pääsy ja sisäinen työasema tuottavat erilaiset lähdeosoitteet, päätepisteen luottamuksen ja datapolut. Kumpikaan ei ole automaattisesti turvallinen, eikä pelkkä VPN-jäsenyys ratkaise mitään. Vertaa suunnitelmia ennen kuin sallintasääntö on olemassa.

Kaksi polkua, kaksi lähdeosoitetta

Suorassa pääsyssä kannettava kantaa asiakasasetukset ja avaa tietokantayhteyden itse. Etätyöasemassa kannettava avaa työpöytäistunnon, ja työasema tekee SQL-yhteyden omasta osoitteestaan. Tietokanta näkee siis ensimmäisessä suunnitelmassa VPN-poolin tai käännetyt yhdyskäytävän ja toisessa työaseman osoitteen. Tämä ero ratkaisee, mitä palomuurisääntöä ja mitä SQL-käyttöoikeutta todella sovelletaan.

Kannettava hallitsee yhä etäistuntoa, joten työasema ei korvaa käyttäjän todennusta tai istuntokäytäntöä.

Tarkista, mitä tietokanta todella näkee

Lähdeosoite on mitattava asia, ei kaaviosta pääteltävä. Lue se aktiivisen yhteyden palvelinpuolelta.

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"

Yhteystesti osoittaa, että kuuntelija hyväksyy TCP:n kyseisestä verkosta, kun taas kysely osoittaa, mihin kirjautumiseen ja tietokantaan istunto pääsi. Nähdäksesi palvelimen tallentaman osoitteen kysy sys.dm_exec_connections nykyiselle istunnolle; se palauttaa asiakkaan osoitteen minkä tahansa käännöksen jälkeen. Jos arvo on yhdyskäytävä eikä kannettava, käyttäjäkohtainen host-sääntö ei voi toimia tietokantakoneella. Kirjoita havaittu arvo valitun suunnitelman viereen, koska uudelleenyhdistämiset ja poolin muutokset siirtävät sitä.

Avaa kuuntelija eikä mitään ylimääräistä

Avaa vain se palvelu, jonka käyttöönotto tarvitsee. Tuttu 1433 on oletusinstanssin portti, ei yleinen vakio.

Get-NetTCPConnection -State Listen -LocalPort 1433

Nimetyt instanssit kuuntelevat usein dynaamisella portilla, ja SQL Server Browser vastaa löytämiseen UDP 1434:llä, ja tämä riippuvuus on erillinen altistus, joka on perusteltava. Kiinteän portin sitominen instanssiin poistaa Browserin tarpeen ja tekee palomuurisäännöistä vakaita. Säilytä salauksen ja varmenteiden tarkistukset, jotka asiakas jo tekee, sen sijaan että kytkisit ne pois testin läpäisemiseksi. Myönnä sitten tietokantaroolit työkuormalle sen sijaan, että lisäisit koko VPN-ryhmän palvelinrooliin.

Todista sallittu polku ja kielletty polku

Avaa uusi istunto tavallisena hyväksyttynä käyttäjänä ja vahvista palvelimen identiteetti, tietokanta ja vaadittu toiminto. Vahvista sitten poissulkeminen: käytännön ulkopuolisen lähteen tai tilin on epäonnistuttava samassa testissä. Työasemasuunnitelmassa varmista, ettei kannettava voi ohittaa rajaa pääsemällä tietokantaan suoraan. Suorassa pääsyssä varmista, että reitti ja lähdesääntö pitävät yhä uudelleenyhdistämisen jälkeen.

Kirjaa, missä asiakas ajoi, minkä lähteen tietokanta havaitsi ja mikä sääntö sen salli. Se on todiste, jota seuraava katsaus pyytää.