SQL VPN-ի միջոցով՝ ուղիղ հաճախորդ թե՞ ներքին աշխատանքային կայան։
VPN-ի նոութբուքից ուղիղ SQL-ը և կառավարվող աշխատանքային կայանում SSMS-ը վստահության տարբեր ուղիներ են։ Համեմատեք յուրաքանչյուրի ստեղծած աղբյուրի հասցեն և թույլտվությունները։
Թիմերը ցանկանում են SSMS ունենալ իրենց նոութբուքերում, և արագ լուծումը SQL պորտը VPN լողավազանում հրապարակելն է։ Ավելի դանդաղ պատասխանը հարցնում է, թե որտեղ պետք է աշխատի հաճախորդի գործընթացը, որովհետև ուղիղ մուտքը և ներքին աշխատանքային կայանը տալիս են տարբեր աղբյուրի հասցեներ, վերջնակետի վստահություն և տվյալների ուղիներ։ Դրանցից ոչ մեկն ինքնըստինքյան անվտանգ չէ, և միայն VPN անդամակցությունը ոչինչ չի որոշում։ Համեմատեք նախագծերը մինչև թույլտվության կանոնի գոյությունը։
Երկու ուղի, երկու աղբյուրի հասցե
Ուղիղ մուտքի դեպքում նոութբուքը կրում է հաճախորդի կարգավորումը և ինքն է բացում տվյալների բազայի միացումը։ Հեռավոր աշխատանքային կայանի դեպքում նոութբուքը բացում է աշխատասեղանի նստաշրջան, և աշխատանքային կայանը SQL միացումը կատարում է իր հասցեից։ Այդպիսով տվյալների բազան առաջին նախագծում տեսնում է VPN լողավազանը կամ թարգմանված դարպասը, իսկ երկրորդում՝ աշխատանքային կայանի հասցեն։ Այդ տարբերությունն է որոշում, թե որ firewall կանոնը և որ SQL թույլտվությունը իրականում գործում են։
Նոութբուքը դեռ վերահսկում է հեռավոր նստաշրջանը, ուստի աշխատանքային կայանը չի փոխարինում օգտատիրոջ նույնականացմանը կամ նստաշրջանի քաղաքականությանը։
Ստուգեք, թե տվյալների բազան ինչ է իրականում տեսնում
Աղբյուրի հասցեն չափվող բան է, ոչ թե սխեմայից ենթադրվող։ Կարդացեք այն ակտիվ միացման սերվերի կողմից։
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"Միացման թեստը ապացուցում է, որ լսողը ընդունում է TCP այդ ցանցից, իսկ հարցումը ապացուցում է, թե որ մուտքին և տվյալների բազային հասավ նստաշրջանը։ Սերվերի գրանցած հասցեն տեսնելու համար հարցում արեք sys.dm_exec_connections ընթացիկ նստաշրջանի համար, որը վերադարձնում է հաճախորդի հասցեն ցանկացած թարգմանությունից հետո։ Եթե այդ արժեքը դարպաս է, այլ ոչ նոութբուք, ապա մեկ օգտատիրոջ համար նախատեսված host կանոնը չի կարող աշխատել տվյալների բազայի մեքենայում։ Գրեք դիտարկված արժեքը ընտրված նախագծի կողքին, որովհետև վերամիացումները և լողավազանի փոփոխությունները տեղափոխում են այն։
Բացեք լսողը և ոչ ավելին
Բացեք միայն այն ծառայությունը, որն անհրաժեշտ է տեղակայմանը։ Ծանոթ 1433-ը լռելյայն օրինակի պորտն է, ոչ թե համընդհանուր հաստատուն։
Get-NetTCPConnection -State Listen -LocalPort 1433Անվանված օրինակները հաճախ լսում են դինամիկ պորտի վրա, SQL Server Browser-ը պատասխանում է հայտնաբերմանը UDP 1434-ով, և այդ կախվածությունը առանձին ենթարկվածություն է, որը պետք է հիմնավորվի։ Օրինակի համար ֆիքսված պորտ ամրագրելը վերացնում է Browser-ի կարիքը և կայունացնում firewall կանոնները։ Պահպանեք հաճախորդի արդեն կատարած գաղտնագրման և վկայագրի ստուգումները՝ փոխարենը չանջատելով դրանք թեստը անցնելու համար։ Այնուհետև տվեք տվյալների բազայի դերեր աշխատանքային բեռի համար՝ փոխարենը ամբողջ VPN խումբը սերվերի դերին ավելացնելու։
Ապացուցեք թույլատրված ուղին և մերժվածը
Բացեք նոր նստաշրջան որպես սովորական հաստատված օգտատեր և հաստատեք սերվերի ինքնությունը, տվյալների բազան և պահանջվող գործողությունը։ Այնուհետև հաստատեք բացառումը. քաղաքականությունից դուրս աղբյուրը կամ հաշիվը պետք է ձախողվի նույն թեստում։ Աշխատանքային կայանի նախագծի համար ստուգեք, որ նոութբուքը չի կարող շրջանցել սահմանը՝ ուղիղ հասնելով տվյալների բազային։ Ուղիղ մուտքի համար ստուգեք, որ երթուղին և աղբյուրի կանոնը դեռ գործում են վերամիացումից հետո։
Գրանցեք, թե որտեղ աշխատեց հաճախորդը, ինչ աղբյուր տեսավ տվյալների բազան և որ կանոնը թույլ տվեց։ Սա այն ապացույցն է, որը կպահանջի հաջորդ վերանայումը։