EC2 માટે ફક્ત-VPN નિયમ: જોડાયેલા દરેક સિક્યુરિટી ગ્રુપે સહમત થવું પડશે

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

નિયમ લખતા પહેલાં સેવા લખી લો

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

અનુવાદ અને રાઉટિંગ સામે આવે એટલે આ બે સરનામાં લોકો ધારે તેના કરતાં વધુ વાર અલગ પડે છે.

ત્રણ સ્રોત મોડેલ, ત્રણ અલગ નિયમો

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

જે કામ કરતું નથી તે VPN ગેટવેને સિક્યુરિટી ગ્રુપના સ્રોત તરીકે સંદર્ભિત કરવું છે. ગ્રુપ સંદર્ભ VPC અથવા પિયર્ડ નેટવર્કની અંદરના સ્થિતિસ્થાપક નેટવર્ક ઇન્ટરફેસ સાથે મેળ ખાય છે, અને પેકેટ ફોરવર્ડ કરતો ગેટવે તેમાંનો એક નથી.

દરેક જોડાયેલા ગ્રુપમાં સંઘ વાંચો

ઇન્સ્ટન્સ ખોલો, તેનું નેટવર્ક ઇન્ટરફેસ શોધો, અને તેની સાથે જોડાયેલા દરેક સિક્યુરિટી ગ્રુપની યાદી બનાવો. દરેક માટે, તમારા પ્રોટોકોલ અને પોર્ટને આવરી લેતા દરેક નિયમની તપાસ કરો, જેમાં પહોળી પોર્ટ શ્રેણીઓ અને બંને સરનામા પરિવારોનો સમાવેશ થાય છે. 0.0.0.0/0 તરફથી IPv4 નિયમ તમને ::/0 તપાસવાથી મુક્ત કરતું નથી, અને બધો ટ્રાફિક મંજૂર કરતો નિયમ પોર્ટનો પ્રશ્ન સંપૂર્ણપણે છુપાવે છે. આ ઇન્વેન્ટરી પછી જ તમે કહી શકો છો કે સેવા માટે અસરકારક પરવાનગી શું છે.

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

નેટવર્ક ACL અલગ, સ્ટેટલેસ નીતિ છે જેમાં ક્રમબદ્ધ મંજૂરી અને નકાર એન્ટ્રી હોય છે, અને તે ઇન્સ્ટન્સ પર નહીં પણ સબનેટ પર મૂલ્યાંકન પામે છે.

નકારની દીવાલથી જવાબ ન આપો

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

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

નવા સેશન સાથે પરીક્ષણ કરો અને અંદર આવવાનો રસ્તો રાખો

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

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