પાસવર્ડનું રક્ષણ શા માટે કરવું, જો તેને છોડી શકાય?

જે સમસ્યાને આપણે સામાન્ય માની લીધી છે

લગભગ દરેક વેબ એપ્લિકેશનમાં એક વહીવટી પેનલ હોય છે. અને વહીવટી પેનલમાં સામાન્ય રીતે પ્રવેશનું સરનામું, પ્રમાણીકરણ ફોર્મ, લૉગિન અને પાસવર્ડ હોય છે.

આ રચનાની આપણને એટલી આદત પડી ગઈ છે કે આપણે લગભગ એ સવાલ પૂછવાનું જ બંધ કરી દીધું છે: શું બધું ખરેખર આ જ રીતે કામ કરવું જરૂરી છે?

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

પણ જ્યારે પ્રોજેક્ટ્સની સંખ્યા દસ, વીસ કે ત્રીસ થાય ત્યારે શું થાય?

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

એટલે દરેકને વહીવટી ઍક્સેસની વ્યવસ્થા જોઈએ.

લાંબા સમય સુધી હું એકદમ પરિચિત રીત અપનાવતો હતો: અલગ વહીવટી લૉગિન વિગતો, મજબૂત પાસવર્ડ્સ અને તેમને બ્રાઉઝરમાં સાચવી રાખવા.

એ કામ કરતું હતું.

પરંતુ એક સમયે મેં વિચાર્યું: મારે આટલા બધા વહીવટી પાસવર્ડ્સ શા માટે સાચવી રાખવા જોઈએ? મારે માત્ર સર્વર્સ જ નહીં, પણ તેમની ઍક્સેસ મેળવવાનાં સાધનોનું પણ રક્ષણ શા માટે કરવું જોઈએ?

અને શું આ જરૂરિયાતથી છૂટકારો મેળવી શકાય?

મારા મનમાં એક વિચાર આવ્યો, જે પછી મારા ઉકેલનો પાયો બન્યો:

કદાચ સતત ઉપલબ્ધ પ્રવેશદ્વારને નહીં, પરંતુ અસ્થાયી રૂપે ઍક્સેસ મેળવવાના અધિકારને સુરક્ષિત કરવો જોઈએ.

મજબૂત પાસવર્ડ મૂળ સમસ્યા હલ કરતો નથી

આધુનિક સાધનો ખૂબ ઊંચી એન્ટ્રોપી ધરાવતા પાસવર્ડ્સ બનાવવાની છૂટ આપે છે. યોગ્ય રીતે બનાવેલો લાંબો, રૅન્ડમ પાસવર્ડ સીધા બધા સંભવિત સંયોજનો અજમાવીને શોધવો લગભગ અશક્ય છે.

પરંતુ પાસવર્ડ ગમે તેટલો મજબૂત હોય, તેને ક્યાંક સાચવવો અને પછી તેનો ઉપયોગ કરવો જરૂરી છે.

પાસવર્ડ મેનેજર, હાર્ડવેર કી, મલ્ટી-ફૅક્ટર ઑથેન્ટિકેશન અને વધારાની મર્યાદાઓનો ઉપયોગ કરી શકાય. આ બધું ખરેખર સુરક્ષામાં વધારો કરે છે.

પરંતુ આર્કિટેક્ચરની મૂળ રચના તો રહે જ છે: એક નિશ્ચિત ઇન્ટરફેસ હોય છે, જેના દ્વારા વપરાશકર્તા પોતાની લૉગિન વિગતો આપે છે.

તેના પર વિનંતીઓ મોકલી શકાય છે. તેને સ્કૅન કરી શકાય છે. તે સ્વચાલિત હુમલાઓનું નિશાન બની શકે છે.

વહીવટી પેનલનું સરનામું છુપાવી શકાય, માનક પાથને લાંબી રૅન્ડમ અક્ષરશ્રેણીથી બદલી શકાય અથવા IP દ્વારા ઍક્સેસ મર્યાદિત કરી શકાય.

પરંતુ પછી એક નવો સવાલ ઊભો થાય છે: આ સરનામું ક્યાં સાચવવું અને તેનો ઉપયોગ કેવી રીતે કરવો?

અને સૌથી મહત્ત્વનું—વહીવટી ઍક્સેસની જરૂર માત્ર અમુક સમયે જ હોય, તો પ્રવેશનું કાયમી બિંદુ શા માટે જાળવી રાખવું?

મને એક એવો વિચાર આવ્યો, જે પછી મારા ઉકેલનો આધાર બન્યો:

કદાચ કાયમી પ્રવેશદ્વારનું રક્ષણ કરવાને બદલે, અસ્થાયી ઍક્સેસ મેળવવાના અધિકારનું રક્ષણ કરવું જોઈએ.

જો પ્રવેશ માટેનું પરિચિત પેજ જ ન હોય તો?

મેં મારા પ્રોજેક્ટ્સમાં વહીવટી પ્રમાણીકરણની પરંપરાગત પદ્ધતિ છોડી દેવાનો નિર્ણય લીધો.

માત્ર લૉગિન ફોર્મ છુપાવવાનું નહીં.

સરનામું બદલી નાખવાનું નહીં.

પાસવર્ડને વધુ જટિલ પાસવર્ડથી બદલવાનું નહીં.

પરંતુ પાસવર્ડ વડે સતત ઉપલબ્ધ પ્રવેશની જરૂરિયાત જ દૂર કરવાની.

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

પરંતુ તેમને ઍક્સેસ મેળવવાની રીત બદલાઈ છે.

હવે જોડાયેલા પ્રોજેક્ટ્સની વહીવટી પેનલમાં પ્રવેશવા માટે સાચવેલું લૉગિન અને પાસવર્ડ દાખલ કરવાની જરૂર નથી.

તેના બદલે, હું MeldID નામની મારી પોતાની ઓળખ અને ઍક્સેસ વ્યવસ્થાપન પ્રણાલીનો ઉપયોગ કરું છું.

વિચાર સરળ છે: વહીવટી ઍક્સેસ માત્ર ત્યારે જ આપવામાં આવે છે, જ્યારે તેની ખરેખર જરૂર હોય—ચોક્કસ વપરાશકર્તાને અને ચોક્કસ પ્રોજેક્ટ માટે.

અને માત્ર એકાઉન્ટ હોવાનો અર્થ એ નથી કે વહીવટી પેનલ ખોલવાનો અધિકાર પણ હોય.

આ અધિકાર અલગથી આપવો પડે છે.

જે ઍક્સેસ એક મિનિટ પહેલાં અસ્તિત્વમાં જ નહોતી

આ કદાચ આખા વિચારનો સૌથી રસપ્રદ ભાગ છે.

પરંપરાગત પદ્ધતિમાં ઍડમિન પાસે પ્રવેશ માટેનાં સાધનો હંમેશાં હોય છે. જ્યાં સુધી તે સાધનો માન્ય હોય ત્યાં સુધી તે આજે, કાલે કે એક મહિના પછી તેનો ઉપયોગ કરી શકે છે.

મેં આ સિદ્ધાંત બદલવાનો નિર્ણય લીધો.

કાયમી વહીવટી લૉગિન વિગતોને બદલે, પ્રવેશ શરૂ કરવાની અસ્થાયી તક આપવામાં આવે છે.

તે વિશ્વસનીય મોબાઇલ ઉપકરણ દ્વારા વિનંતી પર બનાવવામાં આવે છે, તેમાં ક્રિપ્ટોગ્રાફિક રીતે મજબૂત રૅન્ડમ ઘટક હોય છે અને તેની માન્યતા મર્યાદિત સમય માટે હોય છે.

પરંતુ આવી અસ્થાયી લિંક હોવાનો અર્થ એ નથી કે ઍક્સેસ મળી ગઈ.

આ એક મૂળભૂત બાબત છે.

ધારો કે કોઈક રીતે કોઈને લિંક મળી ગઈ. માત્ર સરનામાની ગુપ્તતા પર આધારિત સામાન્ય સિસ્ટમમાં આવો લીક ગંભીર સમસ્યા બની શકે.

મારી પદ્ધતિમાં લિંક માત્ર પુષ્ટિની પ્રક્રિયા શરૂ કરવાની મંજૂરી આપે છે.

આગળ વધવા માટે MeldIDના વિશ્વસનીય મોબાઇલ ઉપકરણ દ્વારા અલગથી મંજૂરી આપવી જરૂરી છે.

યોગ્ય પુષ્ટિ વિના વહીવટી સત્ર બનાવવામાં આવતું નથી.

એટલા માટે હું અસ્થાયી લિંકને પાસવર્ડના વિકલ્પ તરીકે નહીં, પરંતુ ઍક્સેસ આપવાની પ્રક્રિયાના એક તત્વ તરીકે જોઉં છું.

ક્યાં સંપર્ક કરવો તે જાણવું અને પ્રવેશવાનો અધિકાર હોવો—બંને તદ્દન અલગ બાબતો છે.

ફોન ઍક્સેસ વ્યવસ્થાપનનું સાધન બને છે

આ પદ્ધતિમાં મોબાઇલ ઉપકરણ સામાન્ય વન-ટાઇમ કોડ જનરેટર કરતાં ઘણી વધુ મહત્ત્વની ભૂમિકા ભજવે છે.

તેનો ઉપયોગ વહીવટી ઍક્સેસ સંબંધિત ક્રિયાઓની પુષ્ટિ કરવા માટે થાય છે.

જ્યારે હું વહીવટી પેનલ ખોલવા માગું છું, ત્યારે સિસ્ટમ MeldID દ્વારા પુષ્ટિ માગે છે.

મને વિશ્વસનીય ઉપકરણ પર સંબંધિત વિનંતી દેખાય છે અને હું ક્રિયાની પુષ્ટિ કરું છું.

અને સફળ ચકાસણી પછી જ સિસ્ટમ પ્રવેશની પ્રક્રિયા આગળ વધારવાની મંજૂરી આપે છે.

આ પુષ્ટિ ચોક્કસ ક્રિયા સાથે જોડાયેલી હોય છે, માત્ર ફોન અનલૉક થયો છે તેની સાથે નહીં.

મોબાઇલ બાયોમેટ્રિક્સ ઉપકરણ પર જ વપરાશકર્તાની ચકાસણી કરે છે, જ્યારે સર્વર બાજુ નોંધાયેલા ઉપકરણની ક્રિપ્ટોગ્રાફિક પુષ્ટિ ચકાસે છે.

આ રીતથી માત્ર પાસવર્ડ પર અથવા વપરાશકર્તાએ પ્રવેશની પુષ્ટિ કરી છે એવા દાવા પર આધાર રાખવો પડતો નથી.

અહીં બીજો એક ફાયદો પણ છે: વિશ્વસનીય ઉપકરણોનું સંચાલન કરી શકાય છે.

જો કોઈ ઉપકરણનો ઍક્સેસની પુષ્ટિ કરવા માટે ઉપયોગ ન કરવો હોય, તો તેનો વિશ્વસનીય દરજ્જો રદ કરી શકાય છે.

ત્યાર પછી તે સંબંધિત કામગીરી માટે પ્રમાણીકરણના માન્ય સાધન તરીકે કામ કરતું નથી.

એક સિસ્ટમ—અનેક સ્વતંત્ર પ્રોજેક્ટ્સ

જ્યારે મેં આ પદ્ધતિ વિકસાવવાનું શરૂ કર્યું, ત્યારે દરેક પ્રોજેક્ટની સ્વતંત્રતા જાળવવી મારા મુખ્ય હેતુઓમાંનો એક હતો.

હું બધી વહીવટી પેનલોને એક જ વિશાળ એપ્લિકેશનમાં ભેગી કરવા માગતો નહોતો.

DigiMeldની દરેક સેવા પોતાની લૉજિક, સેટિંગ્સ, વપરાશકર્તાઓ અને ડેટાનું સંચાલન કરતી રહેવી જોઈએ.

એટલે મેં બે કાર્યો અલગ પાડ્યાં.

MeldID ઓળખ અને વહીવટી ઍક્સેસની મંજૂરી આપવા માટે જવાબદાર છે.

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

આ રીતે ઍક્સેસ વ્યવસ્થાપનનું કેન્દ્રીય મોડેલ બન્યું, પણ એપ્લિકેશન્સને કેન્દ્રિત કરવાની જરૂર પડી નહીં.

વધુમાં, અધિકારો અલગથી આપવામાં આવે છે.

MeldID એકાઉન્ટ ધરાવતો હોવાના કારણે એક પ્રોજેક્ટનો ઍડમિન આપમેળે બીજા પ્રોજેક્ટ્સમાં પ્રવેશી શકતો નથી.

દરેક વહીવટી ક્ષેત્ર માટે મંજૂર વપરાશકર્તાઓનો પોતાનો સમૂહ નક્કી કરી શકાય છે.

સામાન્ય વપરાશકર્તાઓના અધિકારો અને વહીવટી સત્તાઓ પણ અલગ રાખવામાં આવે છે.

ડઝનબંધ સેવાઓ ધરાવતી ઇકોસિસ્ટમ માટે આ ખાસ ઉપયોગી સાબિત થયું.

કાયમી કરતાં અસ્થાયી ઍક્સેસ મને વધુ કેમ ગમે છે

આ સિસ્ટમમાં મેં જાણીજોઈને ઉમેરેલો બીજો એક સિદ્ધાંત છે.

વહીવટી ઍક્સેસ અનિશ્ચિત સમય સુધી ચાલુ ન રહેવી જોઈએ.

મંજૂરી મર્યાદિત સમય માટે માન્ય હોય છે અને વપરાશકર્તા બ્રાઉઝરમાં કામ ચાલુ રાખે છે કે નહીં તેનાથી સ્વતંત્ર રીતે સમાપ્ત થાય છે.

સમયમર્યાદા પૂરી થયા પછી કામ ચાલુ રાખવા માટે નવી પુષ્ટિ પ્રક્રિયા જરૂરી છે.

આથી એક વખત થયેલા પ્રમાણીકરણને કાયમી અધિકારમાં ફેરવાતું અટકાવી શકાય છે.

પરંતુ માત્ર સમયમર્યાદા પૂરતી નથી.

આપેલી ઍક્સેસને સમય પહેલાં સમાપ્ત કરવાની ક્ષમતા પણ મહત્ત્વની છે.

એટલા માટે MeldIDમાં વહીવટી મંજૂરીઓને કેન્દ્રીય રીતે રદ કરવાની વ્યવસ્થા છે.

મંજૂરી રદ થાય ત્યારે જોડાયેલા પ્રોજેક્ટ્સને તેની સૂચના મળે છે અને તેઓ સંબંધિત વહીવટી સત્રો અમાન્ય કરે છે.

આ રીતે વપરાશકર્તા સફળતાપૂર્વક પ્રવેશી જાય ત્યારે ઍક્સેસનું સંચાલન પૂરું થઈ જતું નથી.

મારા માટે સત્તાઓ આપવાની ક્ષમતા જેટલી જ તેમને પાછી ખેંચવાની ક્ષમતા પણ મહત્ત્વની છે.

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

રોજિંદા કામમાં શું બદલાયું?

સૌપ્રથમ, સાચવેલા વહીવટી પાસવર્ડ્સ પર સતત આધાર રાખવાની જરૂરિયાત દૂર થઈ.

હવે દરેક જોડાયેલી વહીવટી પેનલમાં પ્રવેશવા માટેની લૉગિન વિગતોનો સમૂહ બ્રાઉઝરમાં રાખવાની જરૂર નથી.

તેના બદલે, હું એક જ વ્યવસ્થા દ્વારા મંજૂરીઓનું સંચાલન કરું છું.

જરૂરી પ્રોજેક્ટ પસંદ કરું છું, ઍક્સેસની પુષ્ટિ કરું છું અને કામ કરું છું.

વહીવટી ઍક્સેસની જરૂર ન રહે ત્યારે તેને રદ કરી શકાય છે.

નવો પ્રોજેક્ટ ઉમેરાય ત્યારે વહીવટી પ્રમાણીકરણની આખી સિસ્ટમ ફરીથી બનાવવાની જરૂર ન પડે તે ખાસ અનુકૂળ છે.

તેને હાલના મોડેલ સાથે જોડીને જરૂરી મંજૂરીઓ નક્કી કરવી પૂરતી છે.

અલબત્ત, એનો અર્થ એ નથી કે સુરક્ષાનાં બધાં જોખમો અદૃશ્ય થઈ ગયાં છે.

અસ્થાયી મંજૂરીઓ, વિશ્વસનીય ઉપકરણો, સર્વર સત્રો અને કેન્દ્રીય ઇન્ફ્રાસ્ટ્રક્ચરને પણ સુરક્ષાની જરૂર છે.

પરંતુ હવે દરેક એપ્લિકેશન માટે વહીવટી પાસવર્ડ્સના સંચાલનની એક જ સમસ્યા અલગથી ઉકેલવાની જરૂર નથી.

અને એ જ મારા શરૂઆતના હેતુઓમાંનો એક હતો.

શું આવી ટેક્નોલોજીઓ પહેલેથી અસ્તિત્વમાં નથી?

અલબત્ત, અસ્તિત્વમાં છે.

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

આવી પદ્ધતિઓ Identity and Access Management, Privileged Access Management સિસ્ટમ્સ અને Zero Trustની વિભાવનાઓમાં જોવા મળે છે.

હું આ સિદ્ધાંતોની શોધ કરવાનો દાવો કરતો નથી.

મારું કામ કંઈક બીજું હતું.

મારે પોતાની એક સંકલિત સિસ્ટમ બનાવવી હતી, જે DigiMeld ઇન્ફ્રાસ્ટ્રક્ચરની ચોક્કસ સમસ્યાઓ ઉકેલે અને અનેક સ્વતંત્ર પ્રોજેક્ટ્સની વહીવટી ઍક્સેસનું સંચાલન કરવાની છૂટ આપે.

પરિણામે, મેં મારી જરૂરિયાતોને અનુરૂપ એક આર્કિટેક્ચરમાં જાણીતી અનેક પદ્ધતિઓને જોડ્યાં.

મારું માનવું છે કે એન્જિનિયરિંગના કામનું મૂલ્ય હંમેશાં સંપૂર્ણપણે નવી ટેક્નોલોજી શોધવામાં જ નથી હોતું.

ક્યારેક સમસ્યાને યોગ્ય રીતે વ્યાખ્યાયિત કરવામાં અને તેના માટે યોગ્ય ઉકેલ શોધવામાં જ તેનું મૂલ્ય હોય છે.

MeldID માત્ર વહીવટી પેનલો માટે નથી

અહીં એક અલગ સ્પષ્ટતા કરવી યોગ્ય રહેશે.

MeldID માત્ર મારા પોતાના વહીવટી ઍક્સેસ માટેનું સાધન બની રહે એ હેતુથી બનાવવામાં આવ્યું નહોતું.

તે વિકાસકર્તાઓને પોતાની એપ્લિકેશન્સમાં ઓળખ અને પ્રવેશની પુષ્ટિની પદ્ધતિઓ જોડવા માટે SDK પણ આપે છે.

અને આ SDK મફતમાં ઉપલબ્ધ છે.

ઉદાહરણ તરીકે, અન્ય કોઈ વિકાસકર્તા વપરાશકર્તાના પ્રમાણીકરણમાં વધારાના પુષ્ટિ-સ્તર તરીકે MeldIDનો ઉપયોગ કરી શકે છે.

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

વપરાશકર્તાના વિશ્વસનીય મોબાઇલ ઉપકરણ પર વિનંતી આવે છે, જ્યાં તે પ્રવેશના પ્રયાસને મંજૂર અથવા નકારી શકે છે.

લૉગિન વિગતો સાથે ચેડાં થાય ત્યારે આ રીત અનધિકૃત ઍક્સેસનું જોખમ ઘટાડે છે.

MeldIDની આ સૌ માટે ઉપલબ્ધ સુવિધા અને DigiMeld પ્રોજેક્ટ્સ માટે મેં બનાવેલા વહીવટી ઍક્સેસના મોડેલ વચ્ચેનો તફાવત સમજવો મહત્ત્વનો છે.

બંને વિશ્વાસ અને ક્રિયાની પુષ્ટિના સામાન્ય સિદ્ધાંતો વાપરે છે, પરંતુ તેમનાં હેતુઓ અલગ છે.

સુરક્ષા એટલે માત્ર અસ્તિત્વમાં રહેલી વસ્તુનું રક્ષણ નહીં

આ સિસ્ટમ પર કામ કરતાં મને પ્રમાણીકરણની પરિચિત પદ્ધતિઓને જુદી રીતે જોવાની ફરજ પડી.

ઘણી વાર આપણે ઐતિહાસિક કારણોસર અસ્તિત્વમાં રહેલી વસ્તુનું રક્ષણ કરવાનો પ્રયાસ કરીએ છીએ.

વધારાની ચકાસણીઓ, મર્યાદાઓ, વધુ પાસવર્ડ્સ અને સુરક્ષાનાં સ્તરો ઉમેરતા જઈએ છીએ.

ક્યારેક એ ખરેખર જરૂરી હોય છે.

પરંતુ ક્યારેક બીજો સવાલ પૂછવો વધુ ઉપયોગી હોય છે:

જે પદ્ધતિનું આપણે રક્ષણ કરીએ છીએ, તેનું હાલના સ્વરૂપમાં અસ્તિત્વમાં રહેવું ખરેખર જરૂરી છે?

મારા કિસ્સામાં જવાબ ના હતો.

મને સતત ઉપલબ્ધ વહીવટી પ્રવેશ ફોર્મની જરૂર નહોતી.

જ્યારે જરૂર પડે ત્યારે સુરક્ષિત રીતે વહીવટી સત્તાઓ મેળવવાની ક્ષમતા જરૂરી હતી.

આ બે અલગ કાર્યો છે.

પહેલાથી બીજા તરફના પરિવર્તને માત્ર ટેક્નિકલ આર્કિટેક્ચર જ નહીં, પ્રોજેક્ટ્સ સાથે રોજિંદા કામ કરવાની રીત પણ બદલી.

અંતિમ નિર્ણય નહીં, પસંદ કરેલી દિશા

આજે DigiMeld ઇકોસિસ્ટમના મોટા ભાગમાં આ આર્કિટેક્ચર કાર્યરત છે.

બાકીના પ્રોજેક્ટ્સને ધીમે ધીમે વહીવટી ઍક્સેસના નવા મોડેલ પર લાવવામાં આવી રહ્યા છે.

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

ઇન્ટરફેસના કેટલાક ભાગો અને સત્ર સંચાલનના નિયમો હજી બદલાઈ શકે છે.

પરંતુ મૂળ વિચાર નક્કી થઈ ગયો છે.

મારા પોતાના ડઝનબંધ પ્રોજેક્ટ્સનું સંચાલન કરવા માટે ડઝનબંધ વહીવટી પાસવર્ડ્સ સતત સાચવવા અને વાપરવા પડે એવા મોડેલ પર પાછા જવું મને નથી.

સાથે જ, હું મારા અમલને દરેક માટેનો સાર્વત્રિક ઉકેલ માનતો નથી.

અલગ-અલગ સંસ્થાઓની જરૂરિયાતો, ઇન્ફ્રાસ્ટ્રક્ચર, જોખમના મોડેલ અને વહીવટી પદ્ધતિઓ અલગ હોય છે.

DigiMeld ઇકોસિસ્ટમ માટે અનુકૂળ અને યોગ્ય હોય તે બીજા વિકાસકર્તા માટે શ્રેષ્ઠ હોય જ એવું નથી.

તેમ છતાં, સત્તાઓ અસ્થાયી ધોરણે આપવાનો સિદ્ધાંત ધ્યાન આપવા યોગ્ય છે.

નિષ્કર્ષને બદલે

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

અને ન તો એટલા માટે કે હું બીજી કોઈ સિસ્ટમને સંપૂર્ણપણે સુરક્ષિત ગણાવી રજૂ કરવા માગું છું.

સંપૂર્ણ સુરક્ષા અસ્તિત્વમાં નથી.

મને તો સવાલને જોવાની રીત જ રસપ્રદ લાગે છે.

કાયમી વહીવટી પ્રવેશદ્વારનું અનંત સુધી રક્ષણ કરવાને બદલે, તેના અસ્તિત્વની જરૂરિયાત પર ફરી વિચાર કરી શકાય.

ઘણા બધા પાસવર્ડ્સ સાચવવાને બદલે અસ્થાયી મંજૂરીઓ વાપરી શકાય.

પહેલી વાર પ્રમાણીકરણ થયા પછી આપમેળે વિશ્વાસ કરવાને બદલે, ચોક્કસ સત્તાઓ આપવાની પુષ્ટિ કરી શકાય.

સત્ર પૂરું થાય તેની રાહ જોવાને બદલે, ઍક્સેસને કેન્દ્રીય રીતે રદ કરવાની ક્ષમતા રાખી શકાય.

અને અંતે, દરેક પ્રોજેક્ટમાં પ્રવેશની અલગ પદ્ધતિ રાખવાને બદલે, એપ્લિકેશન્સની સ્વતંત્રતા જાળવીને વહીવટી ઍક્સેસનું એકીકૃત વ્યવસ્થાપન તંત્ર બનાવી શકાય.

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

તે માત્ર ભાર કાયમી લૉગિન વિગતોને સુરક્ષિત રાખવાથી હટાવીને સત્તાઓ નિયંત્રિત રીતે આપવા અને સમાપ્ત કરવા પર મૂકે છે.

કદાચ ક્યારેક હુમલા માટેની સપાટી ઘટાડવાનો સૌથી અસરકારક રસ્તો વધુ એક સુરક્ષા પદ્ધતિ ઉમેરવાનો નહીં, પરંતુ જે વિના સિસ્ટમ સારી રીતે કામ કરી શકે તે વસ્તુ છોડી દેવાનો હોય છે.

આ જ વિચારથી મારા માટે MeldID Admin Gatewayની વાર્તા શરૂ થઈ.