VPC հեռակառավարվող հասանելիության ընդունումը պահանջում է մերժման թեստեր

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

Օգտագործեք առանձին հաշիվներ թեստերի համար և նշեք դրանք այնպես, որ ոչ ոք թեստային ինքնությունը չշփոթի իրական բացառության հետ։

Գրեք սահմանը որպես սպասվող արդյունքներ

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

Փորձարկեք տվյալների բազայի մուտքը ցանցային ուղուց առանձին։ Հասանելի TCP պորտը չպետք է հաջող դարձնի չհաստատված տվյալների բազայի հաշիվը, և VPN անդամակցությունը չպետք է ստեղծի ամպային IAM դեր կամ տրամադրի վարչական API հասանելիություն։ Սրանք երեք անկախ հսկիչներ են, և դրանք ձախողվում են անկախ։

Երթուղին թույլտվություն չէ

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

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

Ո՞ր աղբյուրն է իրականում տեսնում հսկիչը։

Աղբյուրի հասցեն, որը գնահատում է հսկիչը, կախված է դարպասի ճարտարապետությունից։ EC2-ում տեղակայված դարպասը կարող է փոխանցել երթուղավորված լողավազան, թարգմանել այն իր հասցեին կամ NAT-ից հետո ներկայացնել այլ հասցե՝ կառավարվող Client VPN-ը կապվում է ենթացանցի հետ և հետևում իր մոդելին։ Անվտանգության խմբերն ու ցանցային ACL-ները տեսնում են այն, ինչ գալիս է այդ մշակումից հետո։ Կանոնը սխալ աղբյուրի ենթադրությամբ ստուգելը սահման կառուցելու սովորական եղանակ է, որը ճիշտ է թվում և ընդունում է սխալ տրաֆիկ։

Համադրեք յուրաքանչյուր արդյունք ամենափոքր օգտակար իրադարձության հետ՝ ինքնություն և նստաշրջան, ռեսուրս, գործողություն, ժամանակ և որոշում։ CloudTrail-ի API կանչը, VPC հոսքի գրառումը և VPN նստաշրջանի մատյանը պատասխանում են տարբեր հարցերի, և դրանցից ոչ մեկը միայնակ հավելվածի աուդիտ չէ։

Հետ կանչեք ինքնությունը և նորից ստուգեք

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

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

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