AWS Client VPN ના નિયમો સંસાધન પર હોય છે, સબનેટ પર નહીં

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

સબનેટનું સ્થાન રૂટિંગ છે, અધિકૃતિ નહીં

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

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

Client VPN સંલગ્નતા જૂથ એ હેન્ડલ છે

સબનેટ સાથે સંકળાયેલા AWS Client VPN endpoint માટે દસ્તાવેજીકૃત ગોઠવણી ચોક્કસ છે. ઇચ્છિત સુરક્ષા જૂથ endpoint ના લક્ષ્ય નેટવર્ક સંલગ્નતાઓ પર લાગુ કરો, પછી તે Client VPN જૂથને સ્રોત તરીકે વાપરીને સંસાધનના સુરક્ષા જૂથમાં જરૂરી ટ્રાફિકને મંજૂરી આપો.

ચોક્કસ રીતે, એપ્લિકેશન ઇન્સ્ટન્સનું જૂથ સંલગ્નતા જૂથમાંથી એપ્લિકેશન પોર્ટને મંજૂરી આપે છે, બીજું કંઈ નહીં. AWS ની સંસાધન-પ્રવેશ પ્રક્રિયા તે સંબંધ વર્ણવે છે, અને endpoint જે દરેક સબનેટ સાથે સંકળાય છે ત્યાં એ જ જૂથ નીતિ રાખવી યોગ્ય છે, કારણ કે અલગ જૂથ સાથેની જૂની સંલગ્નતા સીમાને ચુપચાપ પહોળી કરે છે.

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

એક સંલગ્નતા જૂથ શું અલગ કરી શકતું નથી

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

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

જૂથનું નામ બદલવાથી ઓળખ ઊભી થતી નથી, અને દરેક ટીમ માટે તેની નકલ કરવાથી ફક્ત ઓડિટ કરવાની સંલગ્નતાઓ વધે છે.

તે નિયમને દરેક VPN ડિઝાઇનમાં નકલ કરશો નહીં

સ્વ-સંચાલિત EC2 VPN ગેટવે, રૂટ કરેલું નિરીક્ષણ ઉપકરણ અને સંચાલિત Client VPN ત્રણ જુદા પેકેટ માર્ગો છે. નક્કી કરો કે કયું સ્રોત સરનામું ખરેખર સંસાધન સુધી પહોંચે છે, વચ્ચે અનુવાદ થાય છે કે નહીં, અને તે માર્ગ પર સેવા કઈ સંદર્ભ પદ્ધતિઓને ટેકો આપે છે.

મધ્યસ્થ ઉપકરણ દ્વારા ટ્રાફિક ફોરવર્ડ કરવો સીધા ઇન્સ્ટન્સ-થી-ઇન્સ્ટન્સ ટ્રાફિકની જેમ સ્રોત સુરક્ષા જૂથ સંદર્ભ જાળવતો નથી. AWS દસ્તાવેજ કરે છે કે આવી ડિઝાઇનને જૂથ સંદર્ભને બદલે યોગ્ય ખાનગી સ્રોત સરનામાં કે CIDR ની જરૂર પડી શકે. સંચાલિત Client VPN પ્રક્રિયા એ પુરાવો નથી કે દરેક ગેટવેનું જોડાયેલું જૂથ ફોરવર્ડ કરેલા પેકેટ માટે સાર્વત્રિક ઓળખ ટોકન તરીકે કામ કરે છે.

માર્ગ પર એક NAT હોપ પૂરતો છે ધારણા તોડવા માટે, અને નિષ્ફળતા એવા નિયમ જેવી દેખાય છે જે હાજર છે પણ કદી મેળ ખાતો નથી.

અસરકારક સીમાની સમીક્ષા કરો

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

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

કાર્યક્રમ: ચાર-ભાગની જરૂરિયાત લખો, જૂથને સંલગ્નતાઓ સાથે જોડો, સંસાધન નિયમને પોર્ટ સુધી મર્યાદિત કરો, એક મંજૂરી અને એક નકાર ચકાસો, અને પછી જ રૂટિંગ કારણોસર સબનેટ વિભાજિત કરવાનું વિચારો.