Ինչու VPN կանոնը չի կարող կանգնեցնել մեկ ֆայլի վերբեռնումը
Ծառայության հասնելը և դրանից որ ֆայլեր են դուրս գալիս վերահսկելը երկու պահանջ են։ Կանոնը դրեք այնտեղ, որտեղ ֆայլը տեսանելի է՝ փոստ, հավելված կամ վերջնակետային գործակալ։
Մի փոքր թիմ հեռավոր մուտք է խնդրում իր աշխատանքային համակարգերին և նույն շնչով խնդրում, որ որոշ կցորդներ դադարեն լքել ընկերությունը։ Երկու խնդրանքներն էլ հնչում են որպես VPN-ի մեկ փոփոխություն։ Դրանք երկու պահանջ են՝ տարբեր կիրառման կետերով, և առաջինը բավարարող կանոնը ոչինչ չի անում երկրորդի համար։ Սկսեք գործողության և տվյալների անվանմամբ, ապա ընտրեք այն բաղադրիչը, որն իսկապես կարող է տեսնել դրանք։
Մեկ հարցում, երկու պահանջ
Առաջին պահանջը հասանելիության մասին է՝ որ օգտատերերն ու սարքերը կարող են կապ բացել որ ծառայության հետ։ Երկրորդը վերաբերում է այդ կապի գոյությունից հետո վարքագծին՝ որ փաստաթղթերը կարող են կցվել, տեղադրվել կամ վերբեռնվել։ Թունելը գործում է առաջինի վրա և ըստ նախագծման կույր է երկրորդի նկատմամբ։
IP մակարդակի վերահսկողությունը փոխանցում է փաթեթներ։ Այն չի վերլուծում բազմամաս վերբեռնում, չի ստուգում PDF և չի որոշում՝ արդյոք աղյուսակը պարունակում է հաշվի համարներ։ Դրանից դա ակնկալելը կոնֆիգուրացիայի սխալ չէ՝ դա կատեգորիայի սխալ է։
Արտադրանք փնտրելուց առաջ պահանջը բարձրաձայն ասեք այդ ձևով։ «Օգտատերերը կարող են հասնել ֆայլային պորտալին» և «օգտատերերը չեն կարող հաճախորդների ցանկերը վերբեռնել ֆայլային պորտալ» տարբեր նախադասություններ են, և միայն երկրորդն է նկարագրում բովանդակության քաղաքականություն։
Ընտրեք այն բաղադրիչը, որը տեսնում է ֆայլը
Կիրառումը պետք է տեղի ունենա այնտեղ, որտեղ ֆայլը ընթեռնելի է։ Փոստի համար դա սովորաբար փոստային հարթակն է կամ դարպասը, որն արդեն զբաղվում է կցորդներով և կարող է գնահատել դրանք առաքումից առաջ։ Հաստատված ծառայությանը զննարկչից վերբեռնումների համար հենց հավելվածը կարող է լինել միակ կողմը, որը տեսնում է բովանդակությունը։ Կառավարվող նոթբուքի համար, որը ֆայլերը պատճենում է շարժական կրիչների, վերջնակետային գործակալը տեսնում է գործողությունը։
| Where the file moves | Component that can see it |
|---|---|
| Email attachment | Mail gateway or mail platform policy |
| Upload to a web application | The application, or an inspection proxy that terminates TLS |
| Copy to USB or local folder | Endpoint agent on the device |
| Anything inside the tunnel | Nothing, unless one of the above is present |
Որոշ առևտրային հեռահար մուտքի փաթեթներ միավորում են վերջնակետային գործակալ, վեբ վերահսկողություն և տվյալների արտահոսքի կանխարգելման մոդուլ։ Այդ բաղադրիչները կարող են կիրառել բովանդակության քաղաքականություն, բայց ունակությունը պատկանում է մոդուլին, ոչ թունելավորմանը։ Կարդացեք, թե փաթեթն իրականում ինչ է ներառում, նախքան արդյունքը խոստանալը։
Համեմատության համար օգտակար մոդել է Microsoft-ի Purview-ի տվյալների արտահոսքի կանխարգելման ակնարկը ․ այն քաղաքականությունները նկարագրում է զգայուն տեղեկատվության տեսակներով, տեղերով և գործողություններով։ Այդ բառապաշարը բովանդակության և գործողությունների մասին է, ոչ IP նախածանցների։
TLS-ը վերապրում է թունելը, ուստի դա հաշվի առեք
Հավելվածի գաղտնագրումը համաձայնեցվում է հաճախորդի և ծառայության միջև, և VPN թունելը տեղափոխում է այդ բայթերը՝ չբացելով դրանք։ Ուստի ուղու վրա գտնվող դարպասը ինքնաբերաբար չի ստանում կցորդը դասակարգելու ունակություն, որքան էլ ուղու մասը նրան պատկանի։
Փոխադրման ընթացքում բովանդակությունը ստուգելու համար անհրաժեշտ է բաղադրիչ, որը վստահելի վկայականով ավարտում է TLS-ը, և դա լուրջ ճարտարապետական որոշում է՝ իր գաղտնիության և շահագործման հետևանքներով։ Դա VPN պրոֆիլի նշատուփ չէ։ Հաճախորդները պետք է վստահեն ստուգման վկայականին, վկայականները ամրացնող հավելվածները կկոտրվեն, և օպերատորը հնարավորություն է ստանում կարդալու երթևեկություն, որը նախկինում չէր կարող։ Սրանք են պատճառները, թե ինչու այս որոշումը պատկանում է անվտանգության պատասխանատուին, այլ ոչ թե թունելը վարողին։
Այդ պատճառով «կարո՞ղ է VPN-ը արգելափակել այս վերբեռնումը» հարցին ազնիվ պատասխանը սովորաբար ոչ է, որին հաջորդում է կոնկրետ այլընտրանք։ Այլընտրանքը կարող է լինել հավելվածի մակարդակի սահմանափակումներ, փոստային կանոն կամ վերջնակետային քաղաքականություն, և յուրաքանչյուրն ունի սեփականատեր, որը կարող է փոխել այն։
Գրեք ընդունման թեստը կանոնից առաջ
Բովանդակության կանոնին պետք է երկու օրինակ, ոչ մեկը՝ թույլատրված գործողություն, որը պետք է շարունակի աշխատել, և արգելված գործողություն, որը պետք է կանգնեցվի։ Փորձարկեք երկուսն էլ շրջանակում գտնվող հավելվածներից և սարքերից, որովհետև միայն մեկ զննարկչում աշխատող քաղաքականությունը այն քաղաքականությունը չէ, որ ինչ-որ մեկը խնդրել է։
curl -sS -o /dev/null -w '%{http_code}\n' -F '[email protected]' https://files.plant.example/upload
curl -sS -o /dev/null -w '%{http_code}\n' -F '[email protected]' https://files.plant.example/uploadԱռաջին հարցումը պետք է մերժվի այն բաղադրիչի կողմից, որը տիրապետում է կանոնին, իսկ երկրորդը պետք է հաջողվի։ Եթե երկուսն էլ հաջողվեն, վերահսկողությունը ուղու վրա չէ։ Եթե երկուսն էլ ձախողվեն, դուք կոտրել եք ծառայությունը՝ փոխարենը պաշտպանելու, ինչը թույլատրված օրինակով չգրված կանոնի ավելի սովորական արդյունքն է։
Նախապես որոշեք, թե ինչ է տեսնում օգտատերը, ով կարող է բացառություն տալ և որտեղ ադմինիստրատորը հետագայում հաստատում է որոշումը։ Առանց հաղորդագրության արգելափակված վերբեռնումը ստեղծում է աջակցության տոմս, իսկ կանոնը, որը ոչ ոք չի կարող ստուգել, ստեղծում է վեճ։ Երկուսն էլ հնարավոր է խուսափել մեկ նախադասությամբ փաստաթղթավորմամբ, որը գրվում է քաղաքականության ուժի մեջ մտնելուց առաջ։
Վերջապես, պահեք երկու պահանջները առանձին տոմսերում՝ առանձին սեփականատերերով։ Դրանք «VPN»-ի տակ միավորելը երաշխավորում է, որ ցանցային թիմից կպահանջվի լուծել բովանդակության խնդիր, և որ բովանդակության խնդիրը կհայտարարվի լուծված, երբ թունելը բարձրանա։