VPC રિમોટ ઍક્સેસ સ્વીકારવા માટે નકાર પરીક્ષણો જરૂરી છે

રિમોટ ઍક્સેસનો સ્વીકાર એ અપેક્ષિત પરિણામોનું કોષ્ટક છે, કાર્યક્ષમ પૃષ્ઠનો સ્ક્રીનશૉટ નથી. દરેક જૂથ માટે લખો કે શું સફળ થવું જોઈએ અને શું નિષ્ફળ થવું જોઈએ, પછી નિયંત્રિત સમયગાળામાં સમર્પિત પરીક્ષણ ઓળખ સાથે બંને ચલાવો. નકાર એ એ ભાગ છે જે સીમા સાબિત કરે છે; સફળ લૉગિન ફક્ત એ સાબિત કરે છે કે ટનલ અસ્તિત્વમાં છે. આ બધું પહેલેથી પસંદ કરેલ VPN ઉત્પાદન સાથે કાર્ય કરે છે.

પરીક્ષણો માટે અલગ ખાતાં વાપરો અને તેમને એવી રીતે લેબલ કરો કે કોઈ પરીક્ષણ ઓળખને સાચા અપવાદ સાથે ભૂલ ન કરે.

સીમાને અપેક્ષિત પરિણામો તરીકે લખો

ઘટકોથી નહીં, ભૂમિકાઓથી શરૂ કરો: કોને કઈ સેવા જોઈએ, ક્યાંથી અને કઈ ઓળખ સાથે. એક ઉદાહરણરૂપ VPC લો: એક જૂથને HTTPS દ્વારા સ્ટેજિંગ જોઈએ, બીજા જૂથને પ્રોડક્શન ડેટાબેઝ જોઈએ, અને ત્રીજું નાનું જૂથ ગેટવેનું જ સંચાલન કરે છે. દરેક પંક્તિને અપેક્ષિત પરવાનગી અને અપેક્ષિત નકાર મળે છે, જેમાં પડોશી સેવા અને પડોશી ખાતું પણ સામેલ છે જે કાર્ય ન કરવું જોઈએ. એ કોષ્ટક જ સ્વીકાર માપદંડ છે, અને જે લોકો પરીક્ષણો ચલાવતા નથી તેઓ તેની સમીક્ષા કરી શકે છે.

ડેટાબેઝ લૉગિનનું પરીક્ષણ નેટવર્ક માર્ગથી અલગ કરો. પહોંચી શકાય તેવું TCP પોર્ટ મંજૂર ન કરાયેલા ડેટાબેઝ ખાતાને સફળ બનાવવું જોઈએ નહીં, અને VPN સભ્યપદે ક્લાઉડ IAM ભૂમિકા બનાવવી કે વહીવટી API ઍક્સેસ આપવો જોઈએ નહીં. આ ત્રણ સ્વતંત્ર નિયંત્રણો છે, અને તેઓ સ્વતંત્ર રીતે નિષ્ફળ જાય છે.

માર્ગ એ અધિકૃતિ નથી

માર્ગ એક પથ શક્ય બનાવે છે; તે પરવાનગી આપતું નથી. માર્ગ રોકી રાખવો એ ગંતવ્ય પર લાગુ કરાયેલા પ્રતિબંધનો નબળો વિકલ્પ છે, કારણ કે ક્લાઇન્ટ હંમેશા પોતાનો માર્ગ ઉમેરી શકે છે. સુરક્ષા જૂથ, ડેટાબેઝ અનુદાન અને એપ્લિકેશનની પોતાની અધિકૃતિ જ નિર્ણાયક નિયંત્રણો રહે છે. જ્યારે કોઈ પરીક્ષણ અણધારી રીતે સફળ થાય, ત્યારે પહેલા ગંતવ્યની નીતિ જુઓ, ક્લાઇન્ટ પાસે હોવું જોઈએ એવું તમે ધારેલું રાઉટિંગ કોષ્ટક નહીં.

એટલે જ નકાર પરીક્ષણો સર્વર બાજુને લક્ષ્ય બનાવે છે: તે પરિણામો ક્લાઇન્ટ સંપાદિત કરીને બદલી શકાતા નથી.

નિયંત્રણ ખરેખર કયો સ્રોત જુએ છે?

નિયંત્રણ જે સ્રોત સરનામું મૂલ્યાંકન કરે છે તે ગેટવે સ્થાપનાના આધારે છે. EC2 પર હોસ્ટ કરાયેલ ગેટવે રાઉટેડ પૂલ ફોરવર્ડ કરી શકે, તેને પોતાના સરનામામાં અનુવાદિત કરી શકે, અથવા NAT પછી અલગ સરનામું રજૂ કરી શકે; મેનેજ્ડ Client VPN સબનેટ સાથે જોડાય છે અને તેનું પોતાનું મૉડલ અનુસરે છે. સુરક્ષા જૂથો અને નેટવર્ક ACL તે પ્રક્રિયા પછી જે આવે તે જુએ છે. ખોટી સ્રોત ધારણા સામે નિયમની તપાસ કરવી એ સાચી દેખાતી અને ખોટો ટ્રાફિક સ્વીકારતી સીમા બનાવવાની સામાન્ય રીત છે.

દરેક પરિણામને સૌથી નાની ઉપયોગી ઘટના સાથે સહસંબંધિત કરો: ઓળખ અને સત્ર, સ્રોત, ક્રિયા, સમય અને નિર્ણય. CloudTrail API કૉલ, VPC ફ્લો રેકોર્ડ અને VPN સત્ર લૉગ જુદા જુદા પ્રશ્નોના જવાબ આપે છે, અને તેમાંથી કોઈ એકલું એપ્લિકેશન ઑડિટ નથી.

ઓળખ પાછી ખેંચો અને ફરી પરીક્ષણ કરો

પાછી ખેંચવાનું પણ એ જ કોષ્ટકમાં સામેલ કરો. પરીક્ષણ ઓળખ દૂર કરો, ખાતરી કરો કે નવું સત્ર નકારવામાં આવે છે, પછી અલગથી ખાતરી કરો કે હાલનાં સત્રો સાથે કેવી રીતે વ્યવહાર થાય છે, કારણ કે એ જુદા માલિકો સાથેના જુદા વર્તનો છે. ગેટવે ફરી ચાલુ થયા કે બદલાયા પછી શું થાય તે તપાસો, જેથી હાથે ઉમેરાયેલો અપવાદ ચૂપચાપ અદૃશ્ય ન થાય અથવા વધુ વિશાળ થઈને પાછો ન આવે. જે સીમા ફક્ત આગલા જમાવડા સુધી ટકે તે સીમા નથી.

આમાંથી કંઈ પણ પૅચિંગ, પુનઃપ્રાપ્તિ કે ઓળખપત્રોના જીવનચક્રના કામને બદલતું નથી. તે સાંકડું વચન માપી શકાય તેવું બનાવે છે: યોગ્ય લોકો યોગ્ય સેવાઓ સુધી પહોંચે છે, જ્યારે નજીકના માર્ગો, ખાતાં અને સંચાલન સપાટીઓ અનુદાનની બહાર રહે છે.

કોષ્ટક જમાવડા સાથે રાખો અને ગેટવે બદલાય ત્યારે ફરી ચલાવો. પરીક્ષણો સસ્તાં છે; તેમની પાછળની ધારણાઓ નથી.