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

લોગિન સ્ક્રીનથી બહાર તરફ ચાલો

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

એ જ ભેદ એ પ્રશ્ન છે જેનો જવાબ આપવો યોગ્ય છે. સાઇટ VPN ત્યારે જ બિનજરૂરી છે જ્યારે તે બીજી ચાલની દરેક ચેનલ પાસે પોતાની આગમાં ઊભી રહી શકે એવી પ્રવેશ અને અધિકૃતિ નીતિ હોય.

એપ લોગિન ક્યારેય ન ઢાંકતી પાંચ ચેનલો

નીચેનું કોષ્ટક ઇન્વેન્ટરી નમૂનો છે, ડિપ્લોયમેન્ટ ચેકલિસ્ટ નથી. બીજી કોલમ તમારું પોતાનું પર્યાવરણ આજે ખરેખર જે લાગુ કરે છે તેનાથી ભરો.

ChannelAccess decision to identify
Application APIAccepted TLS peer, application identity, permitted operations
Operating-system administrationApproved entry path, administrative identity, host permissions
Database maintenanceDatabase identity, protected connection, authorized maintenance role
Backup and restoreService identity, allowed source, access to stored copies
Cloud control planeAccount and role permissions governing infrastructure changes

એક ઓળખ પ્રદાતા વહેંચવાથી આ અધિકૃતિઓ એક થતી નથી. API વિનંતી મોકલી શકતો વપરાશકર્તા એટલે VM ડિસ્ક બદલવા અથવા એપની ઓળખપત્રો વડે ડેટાબેઝ પુનઃસ્થાપિત કરવા અધિકૃત થતો નથી. NIST ઝીરો-ટ્રસ્ટ આર્કિટેક્ચર સારાંશ માં તદ્દન આ કારણસર સંસાધન પ્રમાણીકરણ અને અધિકૃતિને નેટવર્ક સ્થાનથી અલગ રાખે છે.

ટિકિટ વાંચી શકતો સપોર્ટ એન્જિનિયર એટલે તેની પાછળના હોસ્ટ પર કન્સોલ ખોલવા અધિકૃત થતો નથી.

માર્ગ ત્યારે જ વાસ્તવિક છે જ્યારે વિકલ્પ બંધ રહે

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

ડાયાગ્રામ નહીં, શ્રોતાઓ તપાસો. હોસ્ટ પર ss -ltnp વડે ખરેખર શું જોડાયેલું છે તેની યાદી બનાવો અને ખાતરી કરો કે વહીવટી પોર્ટ ખાનગી સરનામા પર છે. ક્લાઉડ કન્સોલમાં વર્કલોડ સબનેટ માટેના ઇનબાઉન્ડ નિયમો વાંચો અને કોઈપણ વહીવટી વસ્તુ પર 0.0.0.0/0 શોધો. પછી ખાનગી માર્ગની બહારથી કનેક્શન અજમાવો, કારણ કે એ પરીક્ષણ જ પ્રશ્નનો જવાબ આપે છે.

SSH પર એક જ વિશ્વ-ખુલ્લો નિયમ ટનલ ડિઝાઇનની દરેક દલીલ રદ કરે છે.

ડિઝાઇનની સરખામણી પહેલાં નકશો લખો

ઇન્વેન્ટરીની દરેક પંક્તિ માટે નોંધો: કોણ ઓળખ મંજૂર કરે છે, કોણ ઍક્સેસ નિયમો અપડેટ કરે છે, કોઈ જાય ત્યારે કોણ ઓળખપત્રો દૂર કરે છે, અને માર્ગ પોતે તૂટે ત્યારે કોણ પુનઃપ્રાપ્તિ સંભાળે છે. દરેક પંક્તિમાં ચાર નામ પૂરતા છે એ પંક્તિઓ ઉઘાડી પાડવા માટે જ્યાં જવાબ વહેંચાયેલું ખાતું અને ત્રણ વર્ષ જૂનું વિકિ પૃષ્ઠ છે.

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

ક્યાં સાઇટ VPN હજુ પણ પોતાનું સ્થાન કમાય છે

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

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

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

સંબંધિત લેખો