പാസ്‌വേഡ് ഉപേക്ഷിക്കാമെങ്കിൽ അതിനെ സംരക്ഷിക്കുന്നതെന്തിന്?

നമ്മൾ സാധാരണമായി കരുതാൻ ശീലിച്ച പ്രശ്നം

മിക്കവാറും എല്ലാ വെബ് ആപ്ലിക്കേഷനുകൾക്കും ഒരു അഡ്മിനിസ്ട്രേറ്റീവ് പാനൽ ഉണ്ടാകും. സാധാരണയായി ആ പാനലിന് ഒരു ലോഗിൻ വിലാസവും, ഓതന്റിക്കേഷൻ ഫോമും, ഉപയോക്തൃനാമവും പാസ്‌വേഡും ഉണ്ടായിരിക്കും.

ഈ സംവിധാനത്തോട് നമ്മൾ അത്രയേറെ ശീലിച്ചിരിക്കുന്നു; എല്ലാം ഇങ്ങനെയായിരിക്കണമോ എന്ന് ചോദിക്കുന്നത് പോലും മിക്കവാറും നിർത്തിയിരിക്കുന്നു.

നിങ്ങൾക്ക് ഒരു വെബ്‌സൈറ്റ് മാത്രമുള്ളപ്പോൾ പ്രശ്നം കാര്യമായി തോന്നില്ല. ശക്തമായൊരു പാസ്‌വേഡ് സൃഷ്ടിക്കുക, ടു-ഫാക്ടർ ഓതന്റിക്കേഷൻ പ്രവർത്തനക്ഷമമാക്കുക, ലോഗിൻ ശ്രമങ്ങൾക്ക് പരിധി നിശ്ചയിക്കുക — പിന്നെ ജോലി തുടരാം.

എന്നാൽ പ്രോജക്റ്റുകളുടെ എണ്ണം പത്തോ ഇരുപതോ മുപ്പതോ ആകുമ്പോൾ എന്താണ് സംഭവിക്കുന്നത്?

എന്റെ കാര്യത്തിൽ, മുപ്പതിലധികം സ്വതന്ത്ര സോഫ്റ്റ്‌വെയർ പ്രോജക്റ്റുകളെ ഒരുമിപ്പിക്കുന്ന DigiMeld ഇക്കോസിസ്റ്റത്തെക്കുറിച്ചാണ് പറയുന്നത്. ഓരോന്നിനും അതിന്റേതായ ആർക്കിടെക്ചറും സെർവർ ലോജിക്കും അഡ്മിനിസ്ട്രേറ്റീവ് ഇന്റർഫേസുമുണ്ട്.

അതുകൊണ്ട്, ഓരോന്നിനും അഡ്മിനിസ്ട്രേറ്റീവ് ആക്‌സസ് സംവിധാനം ആവശ്യമാണ്.

വളരെക്കാലം ഞാൻ പതിവ് രീതിയാണ് പിന്തുടർന്നത്: പ്രത്യേകം അഡ്മിനിസ്ട്രേറ്റീവ് അക്കൗണ്ട് വിവരങ്ങൾ, ശക്തമായ പാസ്‌വേഡുകൾ, അവ ബ്രൗസറിൽ സൂക്ഷിക്കൽ.

അത് പ്രവർത്തിച്ചിരുന്നു.

എന്നാൽ ഒരു ഘട്ടത്തിൽ ഞാൻ ചിന്തിച്ചു: ഇത്രയധികം അഡ്മിനിസ്ട്രേറ്റീവ് പാസ്‌വേഡുകൾ ഞാൻ എന്തിനാണ് സൂക്ഷിക്കേണ്ടത്? സെർവറുകൾ മാത്രമല്ല, അവയിലേക്കുള്ള ആക്‌സസ് നേടാനുള്ള മാർഗങ്ങളും ഞാൻ എന്തിനാണ് സംരക്ഷിക്കേണ്ടിവരുന്നത്?

ഈ ആവശ്യം തന്നെ ഒഴിവാക്കാൻ കഴിയില്ലേ?

പിന്നീട് എന്റെ പരിഹാരത്തിന്റെ അടിസ്ഥാനമായിത്തീർന്ന ഒരു ചിന്തയിലേക്കാണ് ഞാൻ എത്തിയത്:

നിരന്തരം ലഭ്യമായ ലോഗിൻ വഴിയെ സംരക്ഷിക്കുന്നതിനുപകരം, താൽക്കാലികമായി ആക്‌സസ് നേടാനുള്ള അവകാശത്തെ സംരക്ഷിക്കുകയാണ് വേണ്ടതെങ്കിൽ?

പതിവ് ലോഗിൻ പേജ് തന്നെ ഇല്ലെങ്കിൽ എന്തുചെയ്യും?

എന്റെ പ്രോജക്റ്റുകളിലെ പരമ്പരാഗത അഡ്മിനിസ്ട്രേറ്റീവ് ഓതന്റിക്കേഷൻ മാതൃക ഉപേക്ഷിക്കാൻ ഞാൻ തീരുമാനിച്ചു.

ലോഗിൻ ഫോം ഒളിപ്പിക്കുക മാത്രമല്ല.

വിലാസം മാറ്റുക മാത്രമല്ല.

പാസ്‌വേഡിന് പകരം അതിലും ശക്തമായ മറ്റൊരു പാസ്‌വേഡ് ഉപയോഗിക്കുകയുമല്ല.

പകരം, എപ്പോഴും നിലനിൽക്കുന്ന പാസ്‌വേഡ് അധിഷ്ഠിത ലോഗിൻ എന്ന ആവശ്യം തന്നെ ഒഴിവാക്കുക.

തീർച്ചയായും, അഡ്മിനിസ്ട്രേറ്റീവ് ഇന്റർഫേസുകൾ അപ്രത്യക്ഷമായില്ല. ആപ്ലിക്കേഷനുകൾ കൈകാര്യം ചെയ്യാൻ അവ ഇപ്പോഴും ആവശ്യമാണ്.

അവയിലേക്ക് ആക്‌സസ് നേടുന്ന രീതിയാണ് മാറിയത്.

ഇപ്പോൾ, ബന്ധിപ്പിച്ച പ്രോജക്റ്റുകളുടെ അഡ്മിനിസ്ട്രേറ്റീവ് പാനലുകളിലേക്ക് ലോഗിൻ ചെയ്യാൻ സൂക്ഷിച്ചുവെച്ച ഉപയോക്തൃനാമവും പാസ്‌വേഡും നൽകേണ്ടതില്ല.

പകരം, 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-യുടെ കഥ ആരംഭിച്ചത്.