SQL cez VPN: priamy klient alebo interná pracovná stanica?

Tímy chcú SSMS na svojich notebookoch a rýchlym riešením je publikovať SQL port do VPN poolu. Pomalšia odpoveď sa pýta, kde má bežať klientsky proces, pretože priamy prístup a interná pracovná stanica vytvárajú rôzne zdrojové adresy, dôveru koncového bodu a cesty údajov. Ani jedno nie je automaticky bezpečné a samotné členstvo vo VPN nerozhoduje nič. Porovnajte návrhy skôr, než existuje pravidlo povolenia.

Dve cesty, dve zdrojové adresy

Pri priamom prístupe nesie notebook klientsku konfiguráciu a sám otvára pripojenie k databáze. Pri vzdialenej pracovnej stanici notebook otvára reláciu pracovnej plochy a pracovná stanica nadväzuje SQL spojenie zo svojej vlastnej adresy. Databáza preto v prvom návrhu vidí VPN pool alebo preloženú bránu a v druhom adresu pracovnej stanice. Tento rozdiel rozhoduje, ktoré pravidlo firewallu a ktoré SQL oprávnenie naozaj platia.

Notebook stále riadi vzdialenú reláciu, takže pracovná stanica nenahrádza overovanie používateľa ani zásady relácie.

Overte, čo databáza skutočne vidí

Zdrojová adresa sa má merať, nie odvodzovať z diagramu. Prečítajte ju na strane servera živého pripojenia.

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"

Test konektivity dokazuje, že listener prijíma TCP z tejto siete, zatiaľ čo dotaz dokazuje, ku ktorému prihláseniu a ktorej databáze relácia došla. Ak chcete vidieť adresu, ktorú server zaznamenal, opýtajte sa sys.dm_exec_connections pre aktuálnu reláciu, čo vráti adresu klienta po každom preklade. Ak je touto hodnotou brána a nie notebook, pravidlo hostiteľa pre jednotlivého používateľa nemôže na stroji s databázou fungovať. Zapíšte pozorovanú hodnotu vedľa zvoleného návrhu, pretože opätovné pripojenia a zmeny poolu ju posúvajú.

Otvorte listener a nič viac

Otvorte len službu, ktorú nasadenie potrebuje. Známy 1433 je port predvolenej inštancie, nie univerzálna konštanta.

Get-NetTCPConnection -State Listen -LocalPort 1433

Pomenované inštancie často počúvajú na dynamickom porte, SQL Server Browser odpovedá na zisťovanie cez UDP 1434 a táto závislosť je samostatné vystavenie, ktoré treba odôvodniť. Pripnutie pevného portu k inštancii odstraňuje potrebu Browsera a stabilizuje pravidlá firewallu. Zachovajte kontroly šifrovania a certifikátov, ktoré klient už vykonáva, namiesto ich vypnutia, aby test prešiel. Potom pridelte databázové roly pre záťaž, namiesto pridania celej VPN skupiny do serverovej roly.

Dokážte povolenú cestu aj tú zamietnutú

Otvorte novú reláciu ako bežný schválený používateľ a potvrďte identitu servera, databázu a požadovanú operáciu. Potom potvrďte vylúčenie: zdroj alebo účet mimo zásad musí v rovnakom teste zlyhať. Pri návrhu s pracovnou stanicou overte, že notebook nemôže obísť hranicu priamym dosiahnutím databázy. Pri priamom prístupe overte, že trasa a zdrojové pravidlo po opätovnom pripojení stále platia.

Zaznamenajte, kde klient bežal, aký zdroj databáza pozorovala a ktoré pravidlo to povolilo. To sú dôkazy, ktoré si vyžiada nasledujúca revízia.