VPN-ի հետևում գտնվող SaaS-ի ադմինիստրատիվ տարածքը. ո՞ր հասցեին վստահել

Հանրային SaaS էջերը կարող են բաց մնալ բոլորի համար, մինչդեռ դրանց հետևում գտնվող ադմինիստրատիվ գործողությունները մերժում են VPN-ից դուրս գտնվող յուրաքանչյուրին։ Այդ հնարավորությունը տվող մեխանիզմը ոչ թաքնված ընտրացանկ է, ոչ առանձին մուտքի էջ. դա հարցումը հասցրած ցանցային ուղու ստուգումն է։ Եթե հասցեի ապացույցը սխալ լինի, ստուգումը կա՛մ կողպի իրական ադմինիստրատորներին դուրս, կա՛մ ներս թողնի ցանկացածին, ով կարող է վերնագիր մուտքագրել։ Սկսեք նրանից, ինչ ծագումն իրականում ստանում է։

Ինչ է ծագումն իրականում ստանում թունելից հետո

Երբ զննարկիչը հանրային կայքին հասնում է VPN-ով, որը նաև ինտերնետային երթևեկություն է տեղափոխում, դարպասը թարգմանում է կապը մինչև այն դուրս գալը։ SaaS-ը տեսնում է դարպասի հանրային ելքի հասցեն՝ սովորաբար մեկ հասցե կամ փոքր տիրույթ, և երբեք չի տեսնում նոութբուքի թունելի հասցեն։ Այդ պատճառով 10.90.0.42-ը թույլատրվածների ցանկում ընդգրկելը ձախողվում է, և այդ պատճառով ամբողջ RFC 1918-ը ընդգրկելը ձախողվում է ավելի բարձր ձայնով. երկրորդը ներս է թողնում ձեզ հասնել կարող ցանկացած մասնավոր ցանց։ Միակ հասցեն, որի վրա արժե պայման դնել, այն է, որը ձեր կազմակերպությունը փաստացի տիրապետում է ելքում։

curl -s https://ifconfig.me
dig +short admin.example.com

Բաժանված թունելավորումը լուռ կոտրում է այդ ենթադրությունը։ Եթե VPN-ը տեղափոխում է միայն մասնավոր գրասենյակային ուղիներ, հանրային ադմինիստրատիվ հոսթանվան ուղղված հարցումը դուրս է գալիս տեղական մատակարարի միջով, և ծագումը տեսնում է բնակելի հասցե։ Միացված VPN պատկերակը ոչինչ չի ապացուցում այս կոնկրետ նպատակակետի մասին, ուստի փորձարկեք նպատակակետը, ոչ թե թունելը։

Կանգ առեք և ուղղեք երթուղավորումը նախքան որևէ քաղաքականություն գրելը, եթե ելքի հասցեն տարբերվում է ըստ օգտագործողի։ Պայման, որը համապատասխանում է միայն որոշ ադմինիստրատորների, ավելի վատ է, քան պայմանի բացակայությունը, որովհետև այն թաքցնում է խնդիրը մինչև միջադեպ։

Վստահեք միայն այն պրոքսիին, որը վերագրում է հասցեն

Հանրային կայքերի մեծ մասը գտնվում է CDN-ի կամ հակադարձ պրոքսիի հետևում, ուստի ծագման սոկետի հասցեն պատկանում է այդ ճակատային շերտին, ոչ թե այցելուին։ Ճակատային շերտը սովորաբար փոխանցում է բնօրինակ հասցեն վերնագրում, և այդ վերնագիրը վերահսկվում է հարձակվողի կողմից, եթե ծագումը այն չի ընդունում միայն հայտնի պրոքսիներից։ Հստակ կարգավորեք վստահելի աղբյուրների ցանկը և ծագումը դարձրեք անհասանելի ցանկացած այլ տեղից։ Առանց այդ երկրորդ կեսի հարձակվողը շրջանցում է պրոքսին և վերնագիրն ուղարկում ուղղակիորեն։

set_real_ip_from 192.0.2.0/24;
real_ip_header X-Forwarded-For;
real_ip_recursive on;
curl -H 'X-Forwarded-For: 198.51.100.27' https://origin.example.com/admin

Նույն տրամաբանությունը վերաբերում է PROXY արձանագրությանը. այն վստահելի է միայն այն դեպքում, երբ լսողը կապված է ինտերֆեյսի, որին պրոքսին կարող է հասնել, և ուրիշ ոչինչ չի կարող։ Հասցեի համատեքստի բացակայությունը պետք է ձախողի պաշտպանված ստուգումը, այլ ոչ թե ընկնի լռելյայն թույլտվության։ Բացակայող վերնագիրը վստահելի ուղու ապացույց չէ։

Կցեք պայմանը յուրաքանչյուր պաշտպանված գործողությանը

Տեղադրեք ստուգումը լիազորման սահմանում, որով անցնում է յուրաքանչյուր պաշտպանված գործողություն, ոչ թե ընտրացանկը գծող էջում։ Երթուղային խմբերը, միջնորդ ծրագրակազմը կամ քաղաքականության շերտը բոլորը աշխատում են. ամեն մշակողի պատճենը չի աշխատում, որովհետև հաջորդ եռամսյակում ավելացված մշակողը այն չի ունենա։

user = requireAuthenticatedSession()
requirePermission(user, "admin")
requireVpnEgress(verifiedClientAddress(request))
performProtectedOperation(user, request)

Նույն սահմանը պետք է ծածկի JSON API-ն, արտահանումները, ստորագրված ներբեռնման URL-ները և WebSocket-ի ձեռքսեղմումը, քանի որ դրանցից ոչ մեկին պետք չէ, որ HTML էջը նախապես պահանջվի։ VPN-ի աշխատանքի ընթացքում ստեղծված ներբեռնման հղումը հետո նույնպես վավեր է մնում, եթե ներբեռնման վերջնակետը նորից չստուգի։ Երկարատև սեսիաներին նույնպես պետք է վերագնահատման կանոն, հակառակ դեպքում մեկ նույնականացված հարցում դառնում է մշտական բացառություն։ Լռելյայն մերժումը միակ կարգավորումն է, որը դիմանում է անձնակազմի փոփոխությանը։

Համօգտագործվող քեշերը ստուգման շուրջ շրջանցման մյուս ուղին են։ Քեշը, որն արդեն պահում է պաշտպանված պատասխան, կարող է այն մատուցել առանց ծագմանը դիմելու, ուստի ադմինիստրատիվ պատասխանները նշեք որպես մասնավոր և պահեք դրանք համօգտագործվող պահոցից դուրս։ Եթե քեշը պետք է մատուցի դրանք, մուտքի ստուգումը պետք է աշխատի մատուցումից առաջ, ինչը սովորաբար նշանակում է, որ այն ընդհանրապես չի կարող համօգտագործվող քեշ լինել։

Փորձարկեք հենց նոր փակած շրջանցումները

Մարզեք մատրիցը, ոչ թե երջանիկ ուղին. ադմինիստրատոր՝ VPN-ով, նույն ադմինիստրատորը՝ առանց դրա, ոչ ադմինիստրատոր՝ դրանով, և կեղծված հասցեի վերնագիր։ Ավելացրեք ուղղակի դեպի ծագում ուղղված հարցում և քեշավորված պատասխանով հարցում, որովհետև հենց այդ երկուսն են ամբողջությամբ շրջանցում ճակատային շերտը։

curl -sI https://admin.example.com/export.csv
curl -s -H 'X-Forwarded-For: 198.51.100.27' https://origin.example.com/admin
curl -s https://admin.example.com/api/me -o /dev/null -w '%{http_code}\n'

Յուրաքանչյուր հարցում պետք է վերադարձնի այն կարգավիճակը, որը խոստանում է քաղաքականությունը, և մատյանը պետք է գրանցի, թե որ հասցեի ապացույցն է օգտագործվել։ Առանձին ծածկեք IPv6-ը, որովհետև երկկույտ ծագումը կարող է տեսնել ձեր փորձարկածից տարբեր աղբյուրների ընտանիք։ Պահեք սովորական հաճախորդային գործողությունները աշխատունակ VPN-ից դուրս, հակառակ դեպքում փոփոխությունը կչեղարկվի, երբ հաճախորդն առաջին անգամ բողոքի։ Գրեք յուրաքանչյուր տողի սպասվող արդյունքը նախքան այն գործարկելը, որպեսզի անսպասելի անցումը տեսանելի լինի։

Ելքի հասցեն ապացուցում է թույլատրված ցանցային ուղի, ոչ թե մարդ և ոչ կառավարվող սարք։ Պահեք այն որպես մեկ պայման ինքնության հաստատման և թույլտվության կողքին, և ադմինիստրատիվ տարածքը մնում է նեղ՝ ամբողջ արտադրանքը միայն-VPN ծառայության չվերածելով։ Այդ բաժանումը հենց դիզայնն է, ոչ դրա սահմանափակումը։