AWS Client VPN-ի կանոնները պատկանում են ռեսուրսին, ոչ ենթացանցին

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

Ենթացանցի տեղը երթուղավորում է, ոչ լիազորում

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

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

Client VPN-ի միացման խումբը հենց այդ բռնակն է

Ենթացանցին միացված AWS Client VPN վերջնակետի համար փաստաթղթավորված կարգը կոնկրետ է։ Կիրառեք նախատեսված անվտանգության խումբը վերջնակետի թիրախ ցանցի միացումների վրա, ապա թույլատրեք պահանջվող թրաֆիկը ռեսուրսի անվտանգության խմբում՝ որպես աղբյուր օգտագործելով այդ Client VPN խումբը։

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

Այդ կանոնը ոչ մեկի նույնականացում չի անում։ Մուտքը առանձին վերահսկիչ է, և դեպի ռեսուրս տանող ուղին երրորդն է։ Երեքն էլ պետք է ճիշտ լինեն, մինչև հարցումը կհասնի։ Որը ձախողվի, դա է որոշում, թե որ ուղղումն է ճիշտ, և կանոնի փոփոխությունը ճիշտ պատասխան է միայն առաջինի համար։

Ինչը մեկ միացման խումբ չի կարող տարբերել

Նույն միացման խմբի հետևում գտնվող յուրաքանչյուր հաճախորդ ռեսուրսին հասնում է որպես նույն անվտանգության խմբի աղբյուր։ Տարբեր դերեր ունեցող երկու օգտատեր այդ շերտում անտարբերելի են, ինչպես էլ որ խումբը անվանված կամ պիտակավորված լինի։ Client VPN-ի արտաքին խմբերի լիազորումը սահմանափակում է հասանելիությունը ըստ նպատակակետի նախածանցի՝ գրացուցակի կամ SAML խմբի համար, ինչը կոպիտ է ռեսուրսի դերից և պետք է դիտարկվի որպես ցանցային սահման, ոչ որպես ինքնության համակարգ։

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

Խմբի վերանվանումը ինքնություն չի ստեղծում, և յուրաքանչյուր թիմի համար այն կրկնօրինակելը միայն բազմապատկում է ստուգվող միացումները։

Մի՛ պատճենեք այդ կանոնը ամեն VPN նախագծի մեջ

Ինքնակառավարվող EC2 VPN դարպասը, երթուղավորված ստուգիչ սարքը և կառավարվող Client VPN-ը երեք տարբեր փաթեթային ուղիներ են։ Պարզեք, թե որ աղբյուր հասցեն է իրականում հասնում ռեսուրսին, արդյոք մեջտեղում թարգմանություն է կատարվում, և ինչ հղման մեխանիզմներ է ծառայությունը աջակցում այդ ուղում։

Թրաֆիկը միջանկյալ սարքի միջով փոխանցելը չի պահպանում աղբյուրի անվտանգության խմբի հղումը այնպես, ինչպես դա անում է ուղիղ ինստանս-ինստանս թրաֆիկը։ AWS-ը փաստաթղթավորում է, որ նման նախագծերին կարող են անհրաժեշտ լինել համապատասխան մասնավոր աղբյուր հասցեներ կամ CIDR՝ խմբի հղման փոխարեն։ Կառավարվող Client VPN-ի ընթացակարգը ապացույց չէ, որ յուրաքանչյուր դարպասի կցված խումբն աշխատում է որպես ունիվերսալ ինքնության նշան փոխանցվող փաթեթների համար։

Ուղու վրա մեկ NAT ցատկը բավական է ենթադրությունը կոտրելու համար, և խափանումը նման է կանոնի, որը գոյություն ունի, բայց երբեք չի համապատասխանում։

Վերանայեք արդյունավետ սահմանը

Կարդացեք ռեսուրսին կցված յուրաքանչյուր անվտանգության խումբ, քանի որ թույլատրող կանոնները գումարվում են, և նեղ կանոնը չի չեղարկում ավելի լայնը մեկ այլ խմբում։ Այնուհետև ստուգեք ցանցային ACL-ը, հոսթի firewall-ը և հավելվածի սեփական լիազորումը, որոնք առանձին շերտեր են՝ առանձին սխալներով։

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

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