એક ક્લાઉડ સેવા માટે નેટિવ TLS, SSH ફોરવર્ડ અથવા VPN

પ્રશ્ન ભાગ્યે જ એ છે કે બે ક્લાઉડ મશીનો વચ્ચે કંઈક એન્ક્રિપ્ટ કરવું જોઈએ કે નહીં; પ્રશ્ન એ છે કે તમે કઈ ઇન્ટરફેસ એન્ક્રિપ્ટ કરો છો અને કોણ કોની ઓળખ ચકાસે છે. હું આ વાતચીત સેવાથી શરૂ કરું છું, નેટવર્ક ડાયાગ્રામથી નહીં, કારણ કે સેવા પહેલેથી જાણે છે કે તેને શું જોઈએ છે. ત્રણ સીમાઓ મોટાભાગના કિસ્સાઓ આવરી લે છે: એપ્લિકેશનનું પોતાનું TLS, SSH દ્વારા એક ફોરવર્ડ કરેલ TCP પોર્ટ, અને રાઉટેડ ઓવરલે જે દરેક સહભાગીને સરનામું આપે છે. તેમને શક્તિ પ્રમાણે નહીં, પરંતુ સમસ્યાનો કેટલો ભાગ આવરે છે તે પ્રમાણે ગોઠવવામાં આવે છે.

નેટવર્કથી નહીં, સેવાથી શરૂ કરો

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

8443 પોર્ટ પર પહેલેથી HTTPS આપતું એક નાનું આંતરિક API લો, api.internal.example માટે પ્રમાણપત્ર સાથે. હોસ્ટ પર ss -ltnp દર્શાવે છે કે તે શે સાથે બંધાય છે, અને openssl s_client -connect 127.0.0.1:8443 -verify_hostname api.internal.example દર્શાવે છે કે પ્રમાણપત્ર ક્લાયન્ટ ખરેખર વાપરશે તે નામ માટે માન્ય છે કે નહીં. જો બંને સ્વસ્થ હોય, તો સેવા પોતાનો પ્રવાહ સુરક્ષિત કરી શકે છે અને ફક્ત પહોંચ બાકી રહે છે. તે નેટવર્ક બનાવવા કરતાં ઘણી નાની સમસ્યા છે.

પગલું 1: શું સેવા પોતાને સુરક્ષિત કરે છે?

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

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

પગલું 2: શું એક TCP પોર્ટ જ આખી જરૂરિયાત છે?

જ્યારે જરૂરિયાત ખરેખર એક TCP પોર્ટ હોય, ત્યારે ફોરવર્ડ એ સૌથી નાની કામ કરતી વસ્તુ છે. SSH સ્થાનિક ફોરવર્ડ તે પોર્ટને પહેલેથી અસ્તિત્વમાં રહેલા પ્રમાણિત કનેક્શન દ્વારા લઈ જાય છે.

આકાર ssh -N -L 8443:127.0.0.1:8443 [email protected] છે, અને મહત્વની વિગત લક્ષ્ય સરનામું છે: 127.0.0.1 દૂરના બાજુ પર ઉકેલાય છે, તેથી સેવા સાથેનું કનેક્શન તમારા લેપટોપથી નહીં, બાસ્ટિયનથી ખૂલે છે. સ્થાનિક શ્રોતાને -L 127.0.0.1:8443:... તરીકે સાંકડી રીતે બાંધો જેથી તમે આકસ્મિક રીતે સેવાને તમારા પોતાના સ્થાનિક નેટવર્ક પર પ્રકાશિત ન કરો. સર્વર બાજુ, ક્લાયન્ટના સારા વર્તન પર વિશ્વાસ કરવાને બદલે એકાઉન્ટ શું ફોરવર્ડ કરી શકે તે મર્યાદિત કરો. PermitOpen, AllowTcpForwarding local અને GatewayPorts no ડિફોલ્ટ એ ત્રણ સેટિંગ્સ છે જે સામાન્ય રિલેને ચોક્કસ ચેનલમાં ફેરવે છે.

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

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

પગલું 3: શું રાઉટિંગ જ ખરી જરૂરિયાત છે?

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

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

ઓવરલે સહભાગીઓને સરનામું અને માર્ગ આપે છે, અને પછી ખરું કામ શરૂ થાય છે: ન ઓવરલેપ થતી શ્રેણીઓ, માર્ગ માલિકી, DNS, નોંધણી, રદ કરવું અને સાથી અદૃશ્ય થાય ત્યારે શું થાય. તેમાંથી કંઈ સરનામા સાથે આવતું નથી. ઓવરલેમાં સ્વીકૃત સાથી પણ ગંતવ્ય પરની દરેક ક્રિયા માટે આપમેળે અધિકૃત નથી, તેથી સેવા-સ્તરનું પ્રમાણીકરણ રહે છે.

પછી તમારી પાસે શું છે

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

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