ഞങ്ങൾ ഒരു റോൾ-ബേസ്ഡ് ആക്സസ് കൺട്രോൾ മോഡൽ നിർമ്മിക്കുകയാണ്. ഭാഗം ഒന്ന്, തയ്യാറെടുപ്പ്

ഞാൻ നിലവിൽ ഒരു സോഫ്‌റ്റ്‌വെയർ വെണ്ടർക്ക് വേണ്ടി പ്രവർത്തിക്കുന്നു, പ്രത്യേകമായി ആക്‌സസ് കൺട്രോൾ സൊല്യൂഷനുകൾ. എന്റെ "കഴിഞ്ഞ ജീവിതത്തിൽ നിന്നുള്ള" അനുഭവം ഉപഭോക്താവിന്റെ ഭാഗവുമായി ബന്ധപ്പെട്ടിരിക്കുന്നു - ഒരു വലിയ സാമ്പത്തിക സ്ഥാപനം. അക്കാലത്ത്, ഇൻഫർമേഷൻ സെക്യൂരിറ്റി ഡിപ്പാർട്ട്‌മെന്റിലെ ഞങ്ങളുടെ ആക്‌സസ് കൺട്രോൾ ഗ്രൂപ്പിന് IdM-ലെ മികച്ച കഴിവുകളെക്കുറിച്ച് അഭിമാനിക്കാൻ കഴിഞ്ഞില്ല. ഈ പ്രക്രിയയിൽ ഞങ്ങൾ ഒരുപാട് കാര്യങ്ങൾ പഠിച്ചു, കമ്പനിയിലെ വിവര സംവിധാനങ്ങളിൽ ഉപയോക്തൃ അവകാശങ്ങൾ കൈകാര്യം ചെയ്യുന്നതിനുള്ള ഒരു പ്രവർത്തന സംവിധാനം നിർമ്മിക്കുന്നതിന് ഞങ്ങൾക്ക് ധാരാളം ബമ്പുകൾ അടിക്കേണ്ടി വന്നു.

എന്റെ കഠിനാധ്വാനിയായ ഉപഭോക്തൃ അനുഭവത്തെ വെണ്ടർ അറിവും കഴിവുകളും സംയോജിപ്പിച്ചുകൊണ്ട്, ഘട്ടം ഘട്ടമായുള്ള നിർദ്ദേശങ്ങൾ നിങ്ങളുമായി പങ്കിടാൻ ഞാൻ ആഗ്രഹിക്കുന്നു: ഒരു വലിയ കമ്പനിയിൽ ഒരു റോൾ-ബേസ്ഡ് ആക്സസ് കൺട്രോൾ മോഡൽ എങ്ങനെ സൃഷ്ടിക്കാം, അതിന്റെ ഫലമായി ഇത് എന്ത് നൽകും . എന്റെ നിർദ്ദേശങ്ങൾ രണ്ട് ഭാഗങ്ങൾ ഉൾക്കൊള്ളുന്നു: ആദ്യത്തേത് മോഡൽ നിർമ്മിക്കാൻ തയ്യാറെടുക്കുന്നു, രണ്ടാമത്തേത് യഥാർത്ഥത്തിൽ നിർമ്മിക്കുന്നു. ആദ്യ ഭാഗം ഇതാ, തയ്യാറെടുപ്പ് ഭാഗം.

NB ഒരു റോൾ മോഡൽ നിർമ്മിക്കുന്നത്, നിർഭാഗ്യവശാൽ, ഒരു ഫലമല്ല, മറിച്ച് ഒരു പ്രക്രിയയാണ്. അല്ലെങ്കിൽ, കമ്പനിയിൽ ഒരു ആക്സസ് കൺട്രോൾ ഇക്കോസിസ്റ്റം സൃഷ്ടിക്കുന്ന പ്രക്രിയയുടെ ഒരു ഭാഗം പോലും. അതിനാൽ വളരെക്കാലം ഗെയിമിനായി തയ്യാറെടുക്കുക.

ആദ്യം, നമുക്ക് അത് നിർവചിക്കാം - റോൾ അടിസ്ഥാനമാക്കിയുള്ള ആക്സസ് നിയന്ത്രണം എന്താണ്? നിങ്ങൾക്ക് പതിനായിരക്കണക്കിന് ജീവനക്കാരുള്ള (എന്റിറ്റികൾ) ഒരു വലിയ ബാങ്ക് ഉണ്ടെന്ന് കരുതുക, അവരിൽ ഓരോരുത്തർക്കും നൂറുകണക്കിന് ആന്തരിക ബാങ്ക് വിവര സംവിധാനങ്ങളിലേക്ക് (വസ്തുക്കൾ) ഡസൻ കണക്കിന് ആക്സസ് അവകാശങ്ങളുണ്ട്. ഇപ്പോൾ ഒബ്‌ജക്റ്റുകളുടെ എണ്ണം സബ്‌ജക്‌റ്റുകളുടെ എണ്ണം കൊണ്ട് ഗുണിക്കുക - നിങ്ങൾ ആദ്യം നിർമ്മിക്കുകയും തുടർന്ന് നിയന്ത്രിക്കുകയും ചെയ്യേണ്ട ഏറ്റവും കുറഞ്ഞ കണക്ഷനുകളുടെ എണ്ണമാണിത്. ഇത് സ്വമേധയാ ചെയ്യാൻ ശരിക്കും സാധ്യമാണോ? തീർച്ചയായും അല്ല - ഈ പ്രശ്നം പരിഹരിക്കാൻ റോളുകൾ സൃഷ്ടിച്ചു.

ഒരു ഉപയോക്താവ് അല്ലെങ്കിൽ ഒരു കൂട്ടം ഉപയോക്താക്കൾ ചില ജോലികൾ നിർവഹിക്കുന്നതിന് ആവശ്യമായ അനുമതികളുടെ ഒരു കൂട്ടമാണ് റോൾ. ഓരോ ജീവനക്കാരനും ഒന്നോ അതിലധികമോ റോളുകൾ ഉണ്ടായിരിക്കാം, കൂടാതെ ഓരോ റോളിലും ആ റോളിനുള്ളിൽ ഉപയോക്താവിന് അനുവദനീയമായ ഒന്ന് മുതൽ നിരവധി അനുമതികൾ വരെ അടങ്ങിയിരിക്കാം. നിർദ്ദിഷ്ട സ്ഥാനങ്ങൾ, വകുപ്പുകൾ അല്ലെങ്കിൽ ജീവനക്കാരുടെ പ്രവർത്തനപരമായ ജോലികൾ എന്നിവയുമായി റോളുകൾ ബന്ധിപ്പിക്കാവുന്നതാണ്.

ഓരോ വിവര സിസ്റ്റത്തിലും വ്യക്തിഗത ജീവനക്കാരുടെ അംഗീകാരങ്ങളിൽ നിന്നാണ് റോളുകൾ സാധാരണയായി സൃഷ്ടിക്കുന്നത്. ഓരോ സിസ്റ്റത്തിന്റെയും റോളുകളിൽ നിന്നാണ് ആഗോള ബിസിനസ്സ് റോളുകൾ രൂപപ്പെടുന്നത്. ഉദാഹരണത്തിന്, "ക്രെഡിറ്റ് മാനേജർ" എന്ന ബിസിനസ്സ് റോളിൽ ബാങ്കിന്റെ കസ്റ്റമർ ഓഫീസിൽ ഉപയോഗിക്കുന്ന ഇൻഫർമേഷൻ സിസ്റ്റങ്ങളിൽ നിരവധി വ്യത്യസ്ത റോളുകൾ ഉൾപ്പെടുന്നു. ഉദാഹരണത്തിന്, പ്രധാന ഓട്ടോമേറ്റഡ് ബാങ്കിംഗ് സിസ്റ്റം, ക്യാഷ് മൊഡ്യൂൾ, ഇലക്ട്രോണിക് ഡോക്യുമെന്റ് മാനേജ്മെന്റ് സിസ്റ്റം, സർവീസ് മാനേജർ തുടങ്ങിയവ. ബിസിനസ്സ് റോളുകൾ, ഒരു ചട്ടം പോലെ, സംഘടനാ ഘടനയുമായി ബന്ധപ്പെട്ടിരിക്കുന്നു - മറ്റൊരു വിധത്തിൽ പറഞ്ഞാൽ, കമ്പനി ഡിവിഷനുകളുടെയും അവയിലെ സ്ഥാനങ്ങളുടെയും ഗണവുമായി. ഒരു ആഗോള റോൾ മാട്രിക്സ് രൂപപ്പെടുന്നത് ഇങ്ങനെയാണ് (ചുവടെയുള്ള പട്ടികയിൽ ഞാൻ ഒരു ഉദാഹരണം നൽകുന്നു).

ഒരു വാണിജ്യ ഘടനയിൽ ഓരോ സ്ഥാനത്തെയും ജീവനക്കാർക്ക് ആവശ്യമായ എല്ലാ അവകാശങ്ങളും നൽകിക്കൊണ്ട് 100% റോൾ മോഡൽ നിർമ്മിക്കുന്നത് അസാധ്യമാണ് എന്നത് ശ്രദ്ധിക്കേണ്ടതാണ്. അതെ, ഇത് ആവശ്യമില്ല. എല്ലാത്തിനുമുപരി, ഒരു റോൾ മോഡൽ സ്റ്റാറ്റിക് ആയിരിക്കാൻ കഴിയില്ല, കാരണം അത് നിരന്തരം മാറിക്കൊണ്ടിരിക്കുന്ന പരിസ്ഥിതിയെ ആശ്രയിച്ചിരിക്കുന്നു. കമ്പനിയുടെ ബിസിനസ്സ് പ്രവർത്തനങ്ങളിലെ മാറ്റങ്ങളിൽ നിന്ന്, അതനുസരിച്ച്, സംഘടനാ ഘടനയിലും പ്രവർത്തനത്തിലും വരുന്ന മാറ്റങ്ങളെ ബാധിക്കുന്നു. വിഭവങ്ങളുടെ പൂർണ്ണമായ വ്യവസ്ഥയുടെ അഭാവത്തിൽ നിന്നും, തൊഴിൽ വിവരണങ്ങൾ പാലിക്കാത്തതിൽ നിന്നും, സുരക്ഷയുടെ ചെലവിൽ ലാഭം നേടാനുള്ള ആഗ്രഹത്തിൽ നിന്നും മറ്റ് പല ഘടകങ്ങളിൽ നിന്നും. അതിനാൽ, ഒരു സ്ഥാനത്തേക്ക് നിയോഗിക്കുമ്പോൾ ആവശ്യമായ അടിസ്ഥാന അവകാശങ്ങൾക്കായി ഉപയോക്തൃ ആവശ്യങ്ങളുടെ 80% വരെ ഉൾക്കൊള്ളാൻ കഴിയുന്ന ഒരു റോൾ മോഡൽ നിർമ്മിക്കേണ്ടത് ആവശ്യമാണ്. ആവശ്യമെങ്കിൽ, ബാക്കിയുള്ള 20% പിന്നീട് പ്രത്യേക ആപ്ലിക്കേഷനുകളിൽ അവർക്ക് അഭ്യർത്ഥിക്കാം.

തീർച്ചയായും, നിങ്ങൾ ചോദിച്ചേക്കാം: "100% റോൾ മോഡലുകൾ ഇല്ലേ?" ശരി, എന്തുകൊണ്ട്, ഇത് സംഭവിക്കുന്നു, ഉദാഹരണത്തിന്, ലാഭേച്ഛയില്ലാത്ത ഘടനകളിൽ, പതിവ് മാറ്റങ്ങൾക്ക് വിധേയമല്ല - ചില ഗവേഷണ സ്ഥാപനത്തിൽ. അല്ലെങ്കിൽ ഉയർന്ന സുരക്ഷയുള്ള സൈനിക-വ്യാവസായിക കോംപ്ലക്സ് ഓർഗനൈസേഷനുകളിൽ, സുരക്ഷയാണ് ആദ്യം വരുന്നത്. ഇത് ഒരു വാണിജ്യ ഘടനയിലാണ് സംഭവിക്കുന്നത്, എന്നാൽ ഒരു പ്രത്യേക ഡിവിഷന്റെ ചട്ടക്കൂടിനുള്ളിൽ, അതിന്റെ പ്രവർത്തനം തികച്ചും സ്ഥിരവും പ്രവചിക്കാവുന്നതുമായ പ്രക്രിയയാണ്.

റോൾ അധിഷ്‌ഠിത മാനേജ്‌മെന്റിന്റെ പ്രധാന നേട്ടം അവകാശങ്ങൾ നൽകുന്നതിന്റെ ലഘൂകരണമാണ്, കാരണം വിവര സംവിധാനത്തിന്റെ ഉപയോക്താക്കളുടെ എണ്ണത്തേക്കാൾ റോളുകളുടെ എണ്ണം വളരെ കുറവാണ്. ഏത് വ്യവസായത്തിനും ഇത് ശരിയാണ്.

നമുക്ക് ഒരു റീട്ടെയിൽ കമ്പനി എടുക്കാം: ഇത് ആയിരക്കണക്കിന് വിൽപ്പനക്കാരെ നിയമിക്കുന്നു, പക്ഷേ അവർക്ക് സിസ്റ്റം N-ൽ ഒരേ അവകാശങ്ങളുണ്ട്, അവർക്ക് ഒരു റോൾ മാത്രമേ സൃഷ്ടിക്കൂ. ഒരു പുതിയ വിൽപ്പനക്കാരൻ കമ്പനിയിലേക്ക് വരുമ്പോൾ, ആവശ്യമായ എല്ലാ അധികാരികളും ഇതിനകം ഉള്ള സിസ്റ്റത്തിൽ ആവശ്യമായ പങ്ക് അയാൾക്ക് സ്വയമേവ നിയോഗിക്കപ്പെടുന്നു. കൂടാതെ, ഒറ്റ ക്ലിക്കിലൂടെ നിങ്ങൾക്ക് ആയിരക്കണക്കിന് വിൽപ്പനക്കാരുടെ അവകാശങ്ങൾ ഒരേസമയം മാറ്റാൻ കഴിയും, ഉദാഹരണത്തിന്, ഒരു റിപ്പോർട്ട് സൃഷ്ടിക്കുന്നതിനുള്ള ഒരു പുതിയ ഓപ്ഷൻ ചേർക്കുക. ഓരോ അക്കൗണ്ടിലേക്കും ഒരു പുതിയ അവകാശം ലിങ്ക് ചെയ്തുകൊണ്ട് ആയിരം പ്രവർത്തനങ്ങൾ ചെയ്യേണ്ടതില്ല - റോളിലേക്ക് ഈ ഓപ്ഷൻ ചേർക്കുക, അത് എല്ലാ വിൽപ്പനക്കാർക്കും ഒരേ സമയം ദൃശ്യമാകും.

റോൾ-ബേസ്ഡ് മാനേജ്മെന്റിന്റെ മറ്റൊരു നേട്ടം പൊരുത്തമില്ലാത്ത അംഗീകാരങ്ങൾ നൽകുന്നത് ഒഴിവാക്കലാണ്. അതായത്, സിസ്റ്റത്തിൽ ഒരു നിശ്ചിത പങ്ക് വഹിക്കുന്ന ഒരു ജീവനക്കാരന് ഒരേസമയം മറ്റൊരു പങ്ക് വഹിക്കാൻ കഴിയില്ല, അതിന്റെ അവകാശങ്ങൾ ആദ്യത്തേതിലെ അവകാശങ്ങളുമായി സംയോജിപ്പിക്കരുത്. ഒരു സാമ്പത്തിക ഇടപാടിന്റെ ഇൻപുട്ടിന്റെയും നിയന്ത്രണത്തിന്റെയും പ്രവർത്തനങ്ങൾ സംയോജിപ്പിക്കുന്നതിനുള്ള നിരോധനമാണ് ശ്രദ്ധേയമായ ഒരു ഉദാഹരണം.

റോൾ അധിഷ്‌ഠിത ആക്‌സസ് നിയന്ത്രണം എങ്ങനെ വന്നു എന്നതിൽ താൽപ്പര്യമുള്ള ആർക്കും കഴിയും
ചരിത്രത്തിലേക്ക് മുങ്ങുക
നമ്മൾ ചരിത്രത്തിലേക്ക് നോക്കുകയാണെങ്കിൽ, 70-ാം നൂറ്റാണ്ടിന്റെ XNUMX-കളിൽ ആക്സസ് കൺട്രോൾ രീതികളെക്കുറിച്ച് ഐടി സമൂഹം ആദ്യമായി ചിന്തിച്ചു. അക്കാലത്ത് ആപ്ലിക്കേഷനുകൾ വളരെ ലളിതമായിരുന്നുവെങ്കിലും, ഇപ്പോഴുള്ളതുപോലെ, അവയിലേക്കുള്ള ആക്സസ് സൗകര്യപ്രദമായി നിയന്ത്രിക്കാൻ എല്ലാവരും ആഗ്രഹിക്കുന്നു. ഉപയോക്തൃ അവകാശങ്ങൾ അനുവദിക്കുക, മാറ്റുക, നിയന്ത്രിക്കുക - ഓരോന്നിനും എന്തെല്ലാം ആക്‌സസ്സ് ഉണ്ടെന്ന് മനസ്സിലാക്കുന്നത് എളുപ്പമാക്കുന്നതിന്. എന്നാൽ അക്കാലത്ത് പൊതുവായ മാനദണ്ഡങ്ങളൊന്നും ഉണ്ടായിരുന്നില്ല, ആദ്യത്തെ ആക്സസ് നിയന്ത്രണ സംവിധാനങ്ങൾ വികസിപ്പിച്ചെടുക്കുകയായിരുന്നു, ഓരോ കമ്പനിയും സ്വന്തം ആശയങ്ങളും നിയമങ്ങളും അടിസ്ഥാനമാക്കിയുള്ളതാണ്.

നിരവധി വ്യത്യസ്ത ആക്സസ് കൺട്രോൾ മോഡലുകൾ ഇപ്പോൾ അറിയപ്പെടുന്നു, പക്ഷേ അവ ഉടനടി ദൃശ്യമായില്ല. ഈ പ്രദേശത്തിന്റെ വികസനത്തിന് കാര്യമായ സംഭാവന നൽകിയവരെക്കുറിച്ച് നമുക്ക് താമസിക്കാം.

ആദ്യത്തേതും ഒരുപക്ഷേ ഏറ്റവും ലളിതവുമായ മോഡൽ വിവേചനാധികാര (സെലക്ടീവ്) ആക്സസ് നിയന്ത്രണം (DAC - വിവേചനാധികാര ആക്സസ് നിയന്ത്രണം). ആക്സസ് പ്രോസസിലെ എല്ലാ പങ്കാളികളും അവകാശങ്ങൾ പങ്കിടുന്നതിനെ ഈ മാതൃക സൂചിപ്പിക്കുന്നു. ഓരോ ഉപയോക്താവിനും നിർദ്ദിഷ്ട വസ്തുക്കളിലേക്കോ പ്രവർത്തനങ്ങളിലേക്കോ പ്രവേശനമുണ്ട്. സാരാംശത്തിൽ, ഇവിടെ അവകാശങ്ങളുടെ വിഷയങ്ങളുടെ കൂട്ടം ഒബ്‌ജക്റ്റുകളുടെ കൂട്ടവുമായി പൊരുത്തപ്പെടുന്നു. ഈ മോഡൽ വളരെ അയവുള്ളതും പരിപാലിക്കാൻ വളരെ ബുദ്ധിമുട്ടുള്ളതുമാണെന്ന് കണ്ടെത്തി: ആക്സസ് ലിസ്റ്റുകൾ ഒടുവിൽ വലുതും നിയന്ത്രിക്കാൻ പ്രയാസവുമാണ്.

രണ്ടാമത്തെ മോഡൽ ആണ് നിർബന്ധിത ആക്സസ് നിയന്ത്രണം (MAC - നിർബന്ധിത ആക്സസ് നിയന്ത്രണം). ഈ മോഡൽ അനുസരിച്ച്, ഓരോ ഉപയോക്താവിനും ഒരു പ്രത്യേക തലത്തിലുള്ള ഡാറ്റാ രഹസ്യാത്മകതയിലേക്കുള്ള പ്രവേശനത്തിന് അനുസൃതമായി ഒരു വസ്തുവിലേക്ക് ആക്സസ് ലഭിക്കുന്നു. അതനുസരിച്ച്, വസ്തുക്കളെ അവയുടെ രഹസ്യാത്മകതയുടെ നിലവാരമനുസരിച്ച് തരംതിരിച്ചിരിക്കണം. ആദ്യത്തെ ഫ്ലെക്സിബിൾ മോഡലിൽ നിന്ന് വ്യത്യസ്തമായി, ഇത് നേരെമറിച്ച്, വളരെ കർശനവും നിയന്ത്രണവും ആയി മാറി. കമ്പനിക്ക് ധാരാളം വ്യത്യസ്ത വിവര ഉറവിടങ്ങൾ ഉള്ളപ്പോൾ അതിന്റെ ഉപയോഗം ന്യായീകരിക്കപ്പെടുന്നില്ല: വ്യത്യസ്ത ഉറവിടങ്ങളിലേക്കുള്ള ആക്‌സസ് വേർതിരിക്കുന്നതിന്, ഓവർലാപ്പ് ചെയ്യാത്ത നിരവധി വിഭാഗങ്ങൾ നിങ്ങൾ അവതരിപ്പിക്കേണ്ടതുണ്ട്.

ഈ രണ്ട് രീതികളുടെയും വ്യക്തമായ അപൂർണതകൾ കാരണം, ഐടി കമ്മ്യൂണിറ്റി വ്യത്യസ്ത തരം ഓർഗനൈസേഷണൽ ആക്സസ് കൺട്രോൾ പോളിസികളെ പിന്തുണയ്ക്കുന്നതിനായി കൂടുതൽ വഴക്കമുള്ളതും അതേ സമയം കൂടുതലോ കുറവോ സാർവത്രികവുമായ മോഡലുകൾ വികസിപ്പിക്കുന്നത് തുടർന്നു. എന്നിട്ട് അത് പ്രത്യക്ഷപ്പെട്ടു മൂന്നാമത്തെ റോൾ-ബേസ്ഡ് ആക്സസ് കൺട്രോൾ മോഡൽ! ഈ സമീപനം ഏറ്റവും പ്രതീക്ഷ നൽകുന്നതാണെന്ന് തെളിയിക്കപ്പെട്ടിട്ടുണ്ട്, കാരണം ഇതിന് ഉപയോക്താവിന്റെ ഐഡന്റിറ്റിയുടെ അംഗീകാരം മാത്രമല്ല, സിസ്റ്റങ്ങളിലെ അവന്റെ പ്രവർത്തന പ്രവർത്തനങ്ങളും ആവശ്യമാണ്.

1992-ൽ യുഎസ് നാഷണൽ ഇൻസ്റ്റിറ്റ്യൂട്ട് ഓഫ് സ്റ്റാൻഡേർഡ്സ് ആൻഡ് ടെക്നോളജിയിൽ നിന്നുള്ള അമേരിക്കൻ ശാസ്ത്രജ്ഞരായ ഡേവിഡ് ഫെറൈലോയും റിച്ചാർഡ് കുഹും ചേർന്നാണ് ആദ്യമായി വ്യക്തമായി വിവരിച്ച റോൾ മോഡൽ ഘടന നിർദ്ദേശിച്ചത്. അപ്പോൾ ഈ പദം ആദ്യം പ്രത്യക്ഷപ്പെട്ടു RBAC (റോൾ-ബേസ്ഡ് ആക്സസ് കൺട്രോൾ). ഈ പഠനങ്ങളും പ്രധാന ഘടകങ്ങളെക്കുറിച്ചുള്ള വിവരണങ്ങളും അവയുടെ ബന്ധങ്ങളും INCITS 359-2012 സ്റ്റാൻഡേർഡിന്റെ അടിസ്ഥാനം രൂപീകരിച്ചു, അത് ഇന്നും പ്രാബല്യത്തിൽ ഉണ്ട്, ഇത് ഇന്റർനാഷണൽ കമ്മിറ്റി ഓൺ ഇൻഫർമേഷൻ ടെക്നോളജി സ്റ്റാൻഡേർഡ്സ് (INCITS) അംഗീകരിച്ചു.

സ്റ്റാൻഡേർഡ് ഒരു റോളിനെ നിർവചിക്കുന്നത് "റോളിന് നിയുക്തമാക്കിയ ഉപയോക്താവിന് നൽകിയിട്ടുള്ള അധികാരവും ഉത്തരവാദിത്തവും സംബന്ധിച്ച് ചില അനുബന്ധ സെമാന്റിക്‌സുകളുള്ള ഒരു ഓർഗനൈസേഷന്റെ പശ്ചാത്തലത്തിലുള്ള ഒരു ജോലി പ്രവർത്തനം" എന്നാണ്. ആർ‌ബി‌എ‌സിയുടെ അടിസ്ഥാന ഘടകങ്ങൾ - ഉപയോക്താക്കൾ, സെഷനുകൾ, റോളുകൾ, അനുമതികൾ, ഓപ്പറേഷനുകൾ, ഒബ്‌ജക്റ്റുകൾ എന്നിവയും അവ തമ്മിലുള്ള ബന്ധങ്ങളും പരസ്പര ബന്ധങ്ങളും പ്രമാണം സ്ഥാപിക്കുന്നു.

ഒരു റോൾ മോഡൽ നിർമ്മിക്കുന്നതിന് ആവശ്യമായ ഏറ്റവും കുറഞ്ഞ ഘടനയാണ് സ്റ്റാൻഡേർഡ് നൽകുന്നത് - അവകാശങ്ങളെ റോളുകളായി സംയോജിപ്പിക്കുകയും തുടർന്ന് ഈ റോളുകൾ വഴി ഉപയോക്താക്കൾക്ക് പ്രവേശനം നൽകുകയും ചെയ്യുന്നു. വസ്തുക്കളിൽ നിന്നും പ്രവർത്തനങ്ങളിൽ നിന്നും റോളുകൾ രചിക്കുന്നതിനുള്ള സംവിധാനങ്ങൾ വിവരിച്ചിരിക്കുന്നു, റോളുകളുടെ ശ്രേണിയും അധികാരങ്ങളുടെ അനന്തരാവകാശവും വിവരിച്ചിരിക്കുന്നു. എല്ലാത്തിനുമുപരി, ഏത് കമ്പനിയിലും കമ്പനിയിലെ എല്ലാ ജീവനക്കാർക്കും ആവശ്യമായ അടിസ്ഥാന അധികാരങ്ങൾ സംയോജിപ്പിക്കുന്ന റോളുകൾ ഉണ്ട്. ഇത് ഇമെയിൽ, EDMS, കോർപ്പറേറ്റ് പോർട്ടൽ മുതലായവയിലേക്കുള്ള ആക്‌സസ് ആകാം. ഈ അനുമതികൾ "ജീവനക്കാരൻ" എന്ന് വിളിക്കുന്ന ഒരു പൊതു റോളിൽ ഉൾപ്പെടുത്താം, കൂടാതെ ഓരോ ഉയർന്ന തലത്തിലുള്ള റോളുകളിലും എല്ലാ അടിസ്ഥാന അവകാശങ്ങളും വീണ്ടും വീണ്ടും ലിസ്റ്റ് ചെയ്യേണ്ട ആവശ്യമില്ല. "തൊഴിലാളി" റോളിന്റെ അനന്തരാവകാശ സ്വഭാവം സൂചിപ്പിക്കാൻ ഇത് മതിയാകും.

പിന്നീട്, നിരന്തരം മാറിക്കൊണ്ടിരിക്കുന്ന പരിസ്ഥിതിയുമായി ബന്ധപ്പെട്ട പുതിയ ആക്സസ് ആട്രിബ്യൂട്ടുകൾക്കൊപ്പം സ്റ്റാൻഡേർഡ് അനുബന്ധമായി. സ്റ്റാറ്റിക്, ഡൈനാമിക് നിയന്ത്രണങ്ങൾ അവതരിപ്പിക്കാനുള്ള കഴിവ് ചേർത്തു. സ്റ്റാറ്റിക് റോളുകൾ സംയോജിപ്പിക്കുന്നതിനുള്ള അസാധ്യതയെ സൂചിപ്പിക്കുന്നു (മുകളിൽ സൂചിപ്പിച്ച പ്രവർത്തനങ്ങളുടെ അതേ ഇൻപുട്ടും നിയന്ത്രണവും). പാരാമീറ്ററുകൾ മാറ്റിക്കൊണ്ട് ഡൈനാമിക് നിയന്ത്രണങ്ങൾ നിർണ്ണയിക്കാനാകും, ഉദാഹരണത്തിന്, സമയം (ജോലി/ജോലി ചെയ്യാത്ത സമയം അല്ലെങ്കിൽ ദിവസങ്ങൾ), സ്ഥാനം (ഓഫീസ്/വീട്) മുതലായവ.

വെവ്വേറെ, അതിനെക്കുറിച്ച് പറയണം ആട്രിബ്യൂട്ട് അടിസ്ഥാനമാക്കിയുള്ള ആക്സസ് നിയന്ത്രണം (ABAC - ആട്രിബ്യൂട്ട് അടിസ്ഥാനമാക്കിയുള്ള ആക്സസ് നിയന്ത്രണം). ആട്രിബ്യൂട്ട് പങ്കിടൽ നിയമങ്ങൾ ഉപയോഗിച്ച് ആക്സസ് അനുവദിക്കുന്നതിനെ അടിസ്ഥാനമാക്കിയുള്ളതാണ് സമീപനം. ഈ മോഡൽ വെവ്വേറെ ഉപയോഗിക്കാം, പക്ഷേ മിക്കപ്പോഴും ഇത് ക്ലാസിക് റോൾ മോഡലിനെ സജീവമായി പൂർത്തീകരിക്കുന്നു: ഉപയോക്താക്കൾ, ഉറവിടങ്ങൾ, ഉപകരണങ്ങൾ എന്നിവയുടെ ആട്രിബ്യൂട്ടുകൾ, സമയം അല്ലെങ്കിൽ സ്ഥാനം എന്നിവ ഒരു പ്രത്യേക റോളിലേക്ക് ചേർക്കാൻ കഴിയും. കുറച്ച് റോളുകൾ ഉപയോഗിക്കാനും അധിക നിയന്ത്രണങ്ങൾ ഏർപ്പെടുത്താനും ആക്സസ് കഴിയുന്നത്ര ചെറുതാക്കാനും ഇത് നിങ്ങളെ അനുവദിക്കുന്നു, അതിനാൽ സുരക്ഷ മെച്ചപ്പെടുത്തുക.

ഉദാഹരണത്തിന്, ഒരു അക്കൗണ്ടന്റിന് ഒരു പ്രത്യേക പ്രദേശത്ത് ജോലി ചെയ്യുകയാണെങ്കിൽ അക്കൗണ്ടുകളിലേക്ക് പ്രവേശനം അനുവദിക്കാം. അപ്പോൾ സ്പെഷ്യലിസ്റ്റിന്റെ സ്ഥാനം ഒരു നിശ്ചിത റഫറൻസ് മൂല്യവുമായി താരതമ്യം ചെയ്യും. അല്ലെങ്കിൽ അനുവദനീയമായവയുടെ ലിസ്റ്റിൽ ഉൾപ്പെടുത്തിയിട്ടുള്ള ഉപകരണത്തിൽ നിന്ന് ഉപയോക്താവ് ലോഗിൻ ചെയ്‌താൽ മാത്രമേ നിങ്ങൾക്ക് അക്കൗണ്ടുകളിലേക്ക് ആക്‌സസ് നൽകാനാകൂ. ഒരു റോൾ മോഡലിന് നല്ലൊരു കൂട്ടിച്ചേർക്കൽ, എന്നാൽ പല നിയമങ്ങളും അനുമതികളുടെയും നിയന്ത്രണങ്ങളുടെയും പട്ടികകൾ സൃഷ്ടിക്കേണ്ടതിന്റെ ആവശ്യകത കാരണം അപൂർവ്വമായി മാത്രം ഉപയോഗിക്കുന്നു.

എന്റെ "കഴിഞ്ഞ ജീവിതത്തിൽ" നിന്ന് ABAC ഉപയോഗിക്കുന്നതിന്റെ ഒരു ഉദാഹരണം ഞാൻ നിങ്ങൾക്ക് നൽകാം. ഞങ്ങളുടെ ബാങ്കിന് നിരവധി ശാഖകൾ ഉണ്ടായിരുന്നു. ഈ ശാഖകളിലെ ക്ലയന്റ് ഓഫീസുകളിലെ ജീവനക്കാർ ഒരേ പ്രവർത്തനങ്ങൾ നടത്തി, പക്ഷേ അവരുടെ മേഖലയിലെ അക്കൗണ്ടുകൾ ഉപയോഗിച്ച് മാത്രം പ്രധാന സിസ്റ്റത്തിൽ പ്രവർത്തിക്കേണ്ടതുണ്ട്. ആദ്യം, ഞങ്ങൾ ഓരോ പ്രദേശത്തിനും വെവ്വേറെ റോളുകൾ സൃഷ്‌ടിക്കാൻ തുടങ്ങി - ആവർത്തിച്ചുള്ള പ്രവർത്തനക്ഷമതയുള്ള, എന്നാൽ വ്യത്യസ്‌ത അക്കൗണ്ടുകളിലേക്കുള്ള ആക്‌സസ് ഉള്ള അത്തരം നിരവധി റോളുകൾ ഉണ്ടായിരുന്നു! തുടർന്ന്, ഉപയോക്താവിനായി ഒരു ലൊക്കേഷൻ ആട്രിബ്യൂട്ട് ഉപയോഗിക്കുന്നതിലൂടെയും അവലോകനത്തിനായി ഒരു പ്രത്യേക അക്കൗണ്ടുകളുടെ പരിധിയുമായി അതിനെ ബന്ധപ്പെടുത്തുന്നതിലൂടെയും, സിസ്റ്റത്തിലെ റോളുകളുടെ എണ്ണം ഞങ്ങൾ ഗണ്യമായി കുറച്ചു. തൽഫലമായി, ഒരു ശാഖയ്ക്ക് മാത്രമേ റോളുകൾ അവശേഷിച്ചുള്ളൂ, അവ ബാങ്കിന്റെ മറ്റെല്ലാ പ്രാദേശിക ഡിവിഷനുകളിലെയും അനുബന്ധ സ്ഥാനങ്ങൾക്കായി പകർത്തി.

ഇപ്പോൾ നമുക്ക് ആവശ്യമായ തയ്യാറെടുപ്പ് ഘട്ടങ്ങളെക്കുറിച്ച് സംസാരിക്കാം, അതില്ലാതെ ഒരു വർക്കിംഗ് റോൾ മോഡൽ നിർമ്മിക്കുന്നത് അസാധ്യമാണ്.

ഘട്ടം 1. ഒരു പ്രവർത്തന മാതൃക സൃഷ്ടിക്കുക

ഒരു ഫങ്ഷണൽ മോഡൽ സൃഷ്ടിച്ചുകൊണ്ട് നിങ്ങൾ ആരംഭിക്കണം - ഓരോ വകുപ്പിന്റെയും ഓരോ സ്ഥാനത്തിന്റെയും പ്രവർത്തനക്ഷമത വിശദമായി വിവരിക്കുന്ന ഒരു ഉയർന്ന തലത്തിലുള്ള പ്രമാണം. ചട്ടം പോലെ, വിവിധ രേഖകളിൽ നിന്ന് വിവരങ്ങൾ അതിൽ പ്രവേശിക്കുന്നു: വ്യക്തിഗത യൂണിറ്റുകൾക്കുള്ള തൊഴിൽ വിവരണങ്ങളും നിയന്ത്രണങ്ങളും - വകുപ്പുകൾ, ഡിവിഷനുകൾ, വകുപ്പുകൾ. പ്രവർത്തന മാതൃക എല്ലാ താൽപ്പര്യമുള്ള വകുപ്പുകളുമായും (ബിസിനസ്, ആന്തരിക നിയന്ത്രണം, സുരക്ഷ) അംഗീകരിക്കുകയും കമ്പനിയുടെ മാനേജ്‌മെന്റ് അംഗീകരിക്കുകയും വേണം. ഈ പ്രമാണം എന്തിനുവേണ്ടിയാണ്? അതിനാൽ റോൾ മോഡലിന് അത് പരാമർശിക്കാൻ കഴിയും. ഉദാഹരണത്തിന്, ജീവനക്കാരുടെ നിലവിലുള്ള അവകാശങ്ങളെ അടിസ്ഥാനമാക്കി നിങ്ങൾ ഒരു റോൾ മോഡൽ നിർമ്മിക്കാൻ പോകുന്നു - സിസ്റ്റത്തിൽ നിന്ന് ഇറക്കി "ഒരു പൊതു വിഭാഗത്തിലേക്ക് ചുരുക്കി". തുടർന്ന്, സിസ്റ്റത്തിന്റെ ബിസിനസ്സ് ഉടമയുമായി സ്വീകരിച്ച റോളുകൾ അംഗീകരിക്കുമ്പോൾ, നിങ്ങൾക്ക് ഫംഗ്ഷണൽ മോഡലിലെ ഒരു നിർദ്ദിഷ്ട പോയിന്റ് പരാമർശിക്കാൻ കഴിയും, അതിന്റെ അടിസ്ഥാനത്തിൽ ഈ അല്ലെങ്കിൽ ആ അവകാശം റോളിൽ ഉൾപ്പെടുത്തിയിട്ടുണ്ട്.

ഘട്ടം 2. ഞങ്ങൾ ഐടി സംവിധാനങ്ങൾ ഓഡിറ്റ് ചെയ്യുകയും ഒരു മുൻഗണനാ പദ്ധതി തയ്യാറാക്കുകയും ചെയ്യുന്നു

രണ്ടാം ഘട്ടത്തിൽ, ഐടി സംവിധാനങ്ങളിലേക്കുള്ള ആക്‌സസ് എങ്ങനെയാണ് ക്രമീകരിച്ചിരിക്കുന്നതെന്ന് മനസിലാക്കാൻ നിങ്ങൾ ഒരു ഓഡിറ്റ് നടത്തണം. ഉദാഹരണത്തിന്, എന്റെ സാമ്പത്തിക കമ്പനി നൂറുകണക്കിന് വിവര സംവിധാനങ്ങൾ പ്രവർത്തിപ്പിച്ചു. എല്ലാ സിസ്റ്റങ്ങൾക്കും റോൾ അധിഷ്‌ഠിത മാനേജ്‌മെന്റിന്റെ ചില അടിസ്ഥാനങ്ങളുണ്ട്, മിക്കതിനും ചില റോളുകൾ ഉണ്ടായിരുന്നു, പക്ഷേ കൂടുതലും പേപ്പറിലോ സിസ്റ്റം ഡയറക്‌ടറിയിലോ - അവ കാലഹരണപ്പെട്ടതാണ്, യഥാർത്ഥ ഉപയോക്തൃ അഭ്യർത്ഥനകളെ അടിസ്ഥാനമാക്കി അവയിലേക്കുള്ള പ്രവേശനം അനുവദിച്ചു. സ്വാഭാവികമായും, നൂറുകണക്കിന് സിസ്റ്റങ്ങളിൽ ഒരേസമയം ഒരു റോൾ മോഡൽ നിർമ്മിക്കുന്നത് അസാധ്യമാണ്; നിങ്ങൾ എവിടെയെങ്കിലും ആരംഭിക്കേണ്ടതുണ്ട്. ആക്‌സസ് കൺട്രോൾ പ്രോസസിന്റെ മെച്യൂരിറ്റി ലെവൽ നിർണ്ണയിക്കാൻ ഞങ്ങൾ അതിന്റെ ആഴത്തിലുള്ള വിശകലനം നടത്തി. വിശകലന പ്രക്രിയയിൽ, വിവര സംവിധാനങ്ങൾക്ക് മുൻഗണന നൽകുന്നതിനുള്ള മാനദണ്ഡങ്ങൾ വികസിപ്പിച്ചെടുത്തു - വിമർശനം, സന്നദ്ധത, ഡീകമ്മീഷൻ ചെയ്യുന്നതിനുള്ള പദ്ധതികൾ മുതലായവ. അവരുടെ സഹായത്തോടെ, ഈ സിസ്റ്റങ്ങൾക്കായുള്ള റോൾ മോഡലുകളുടെ വികസനം/അപ്‌ഡേറ്റ് എന്നിവ ഞങ്ങൾ അണിനിരത്തി. ആക്‌സസ് കൺട്രോൾ ഓട്ടോമേറ്റ് ചെയ്യുന്നതിനുള്ള ഐഡന്റിറ്റി മാനേജ്‌മെന്റ് സൊല്യൂഷനുമായി സംയോജിപ്പിക്കുന്നതിനുള്ള പദ്ധതിയിൽ ഞങ്ങൾ റോൾ മോഡലുകൾ ഉൾപ്പെടുത്തി.

ഒരു സിസ്റ്റത്തിന്റെ നിർണായകത എങ്ങനെ നിർണ്ണയിക്കും? ഇനിപ്പറയുന്ന ചോദ്യങ്ങൾക്ക് സ്വയം ഉത്തരം നൽകുക:

• കമ്പനിയുടെ പ്രധാന പ്രവർത്തനങ്ങൾ ആശ്രയിക്കുന്ന പ്രവർത്തന പ്രക്രിയകളുമായി സിസ്റ്റം ബന്ധിപ്പിച്ചിട്ടുണ്ടോ?
• സിസ്റ്റം തടസ്സം കമ്പനിയുടെ ആസ്തികളുടെ സമഗ്രതയെ ബാധിക്കുമോ?
• ഒരു തടസ്സത്തിന് ശേഷം പ്രവർത്തനം പുനഃസ്ഥാപിക്കുന്നത് അസാധ്യമായ സിസ്റ്റത്തിന്റെ പരമാവധി അനുവദനീയമായ പ്രവർത്തനരഹിതമായ സമയം എന്താണ്?
• സിസ്റ്റത്തിലെ വിവരങ്ങളുടെ സമഗ്രതയുടെ ലംഘനം സാമ്പത്തികവും പ്രശസ്തവുമായ മാറ്റാനാവാത്ത പ്രത്യാഘാതങ്ങളിലേക്ക് നയിക്കുമോ?
• വഞ്ചനയുടെ വിമർശനം. പ്രവർത്തനക്ഷമതയുടെ സാന്നിധ്യം, ശരിയായി നിയന്ത്രിച്ചില്ലെങ്കിൽ, ആന്തരിക/ബാഹ്യ വഞ്ചനാപരമായ പ്രവർത്തനങ്ങളിലേക്ക് നയിച്ചേക്കാം;
• ഈ സംവിധാനങ്ങൾക്കുള്ള നിയമപരമായ ആവശ്യകതകളും ആന്തരിക നിയമങ്ങളും നടപടിക്രമങ്ങളും എന്തൊക്കെയാണ്? പാലിക്കാത്തതിന് റെഗുലേറ്റർമാരിൽ നിന്ന് പിഴ ഈടാക്കുമോ?

ഞങ്ങളുടെ സാമ്പത്തിക കമ്പനിയിൽ, ഞങ്ങൾ ഇതുപോലെ ഒരു ഓഡിറ്റ് നടത്തി. ഏറ്റവും ഉയർന്ന മുൻഗണനാ ലിസ്റ്റിലുള്ള വിവര സംവിധാനങ്ങളിലെ നിലവിലുള്ള ഉപയോക്താക്കളെയും അവകാശങ്ങളെയും ആദ്യം നോക്കുന്നതിനായി മാനേജ്മെന്റ് ആക്സസ് റൈറ്റ്സ് റിവ്യൂ ഓഡിറ്റ് നടപടിക്രമം വികസിപ്പിച്ചെടുത്തു. ഈ പ്രക്രിയയുടെ ഉടമയായി സുരക്ഷാ വിഭാഗത്തെ ചുമതലപ്പെടുത്തി. എന്നാൽ കമ്പനിയിലെ ആക്സസ് അവകാശങ്ങളുടെ പൂർണ്ണമായ ചിത്രം ലഭിക്കുന്നതിന്, ഈ പ്രക്രിയയിൽ ഐടി, ബിസിനസ്സ് വകുപ്പുകളെ ഉൾപ്പെടുത്തേണ്ടത് ആവശ്യമാണ്. ഇവിടെ തർക്കങ്ങളും തെറ്റിദ്ധാരണകളും ചിലപ്പോൾ അട്ടിമറികളും ആരംഭിച്ചു: ആരും അവരുടെ നിലവിലെ ഉത്തരവാദിത്തങ്ങളിൽ നിന്ന് ഒഴിഞ്ഞുമാറാനും ചിലത് ഒറ്റനോട്ടത്തിൽ മനസ്സിലാക്കാൻ കഴിയാത്ത പ്രവർത്തനങ്ങളിൽ ഏർപ്പെടാനും ആഗ്രഹിക്കുന്നില്ല.

NB വികസിത ഐടി പ്രക്രിയകളുള്ള വലിയ കമ്പനികൾക്ക് ഐടി ഓഡിറ്റ് നടപടിക്രമം പരിചിതമായിരിക്കും - ഐടി ജനറൽ കൺട്രോൾസ് (ഐടിജിസി), ഇത് ഐടി പ്രക്രിയകളിലെ പോരായ്മകൾ തിരിച്ചറിയാനും മികച്ച സമ്പ്രദായത്തിന് അനുസൃതമായി പ്രക്രിയകൾ മെച്ചപ്പെടുത്താനും നിയന്ത്രണം സ്ഥാപിക്കാനും നിങ്ങളെ അനുവദിക്കുന്നു (ITIL, COBIT, IT. ഭരണം മുതലായവ) അത്തരം ഓഡിറ്റ് ഐടിയും ബിസിനസും പരസ്പരം നന്നായി മനസ്സിലാക്കാനും ഒരു സംയുക്ത വികസന തന്ത്രം വികസിപ്പിക്കാനും അപകടസാധ്യതകൾ വിശകലനം ചെയ്യാനും ചെലവുകൾ ഒപ്റ്റിമൈസ് ചെയ്യാനും കൂടുതൽ ഫലപ്രദമായ സമീപനങ്ങൾ വികസിപ്പിക്കാനും അനുവദിക്കുന്നു.



വിവര സംവിധാനങ്ങളിലേക്കുള്ള ലോജിക്കൽ, ഫിസിക്കൽ ആക്സസ്സിന്റെ പാരാമീറ്ററുകൾ നിർണ്ണയിക്കുക എന്നതാണ് ഓഡിറ്റിന്റെ ഒരു മേഖല. ഒരു റോൾ മോഡൽ നിർമ്മിക്കുന്നതിനുള്ള കൂടുതൽ ഉപയോഗത്തിനുള്ള അടിസ്ഥാനമായി ലഭിച്ച ഡാറ്റ ഞങ്ങൾ എടുത്തു. ഈ ഓഡിറ്റിന്റെ ഫലമായി, ഞങ്ങൾക്ക് ഐടി സിസ്റ്റങ്ങളുടെ ഒരു രജിസ്റ്റർ ഉണ്ടായിരുന്നു, അതിൽ അവയുടെ സാങ്കേതിക പാരാമീറ്ററുകൾ നിർണ്ണയിക്കുകയും വിവരണങ്ങൾ നൽകുകയും ചെയ്തു. കൂടാതെ, ഓരോ സിസ്റ്റത്തിനും, ആരുടെ താൽപ്പര്യങ്ങൾക്കനുസൃതമായാണ് ബിസിനസ്സ് ദിശയിൽ നിന്ന് ഒരു ഉടമയെ തിരിച്ചറിഞ്ഞത്: ഈ സിസ്റ്റം സേവിക്കുന്ന ബിസിനസ്സ് പ്രക്രിയകളുടെ ഉത്തരവാദിത്തം അവനായിരുന്നു. ഒരു ഐടി സർവീസ് മാനേജരെയും നിയമിച്ചു, ഒരു നിർദ്ദിഷ്ട ഐഎസിന്റെ ബിസിനസ് ആവശ്യകതകളുടെ സാങ്കേതിക നിർവ്വഹണത്തിന് ഉത്തരവാദി. കമ്പനിയുടെ ഏറ്റവും നിർണായകമായ സംവിധാനങ്ങളും അവയുടെ സാങ്കേതിക പാരാമീറ്ററുകൾ, കമ്മീഷൻ ചെയ്യൽ, ഡീകമ്മീഷൻ ചെയ്യുന്നതിനുള്ള നിബന്ധനകൾ മുതലായവ രേഖപ്പെടുത്തി.ഒരു മാതൃക സൃഷ്ടിക്കുന്നതിനുള്ള തയ്യാറെടുപ്പ് പ്രക്രിയയിൽ ഈ പാരാമീറ്ററുകൾ വളരെ സഹായകമായിരുന്നു.

ഘട്ടം 3 ഒരു രീതിശാസ്ത്രം സൃഷ്ടിക്കുക

ഏതൊരു ബിസിനസ്സിന്റെയും വിജയത്തിന്റെ താക്കോൽ ശരിയായ രീതിയാണ്. അതിനാൽ, ഒരു റോൾ മോഡൽ നിർമ്മിക്കുന്നതിനും ഒരു ഓഡിറ്റ് നടത്തുന്നതിനും, ഞങ്ങൾ വകുപ്പുകൾ തമ്മിലുള്ള ആശയവിനിമയം വിവരിക്കുന്ന ഒരു രീതിശാസ്ത്രം സൃഷ്ടിക്കേണ്ടതുണ്ട്, കമ്പനിയുടെ നിയന്ത്രണങ്ങളിൽ ഉത്തരവാദിത്തം സ്ഥാപിക്കുക തുടങ്ങിയവ.
ആദ്യം നിങ്ങൾ പ്രവേശനവും അവകാശങ്ങളും നൽകുന്നതിനുള്ള നടപടിക്രമം സ്ഥാപിക്കുന്ന ലഭ്യമായ എല്ലാ രേഖകളും പരിശോധിക്കേണ്ടതുണ്ട്. നല്ല രീതിയിൽ, പ്രക്രിയകൾ പല തലങ്ങളിൽ രേഖപ്പെടുത്തണം:

• പൊതു കോർപ്പറേറ്റ് ആവശ്യകതകൾ;
• വിവര സുരക്ഷാ മേഖലകൾക്കുള്ള ആവശ്യകതകൾ (ഓർഗനൈസേഷന്റെ പ്രവർത്തനങ്ങളുടെ മേഖലകളെ ആശ്രയിച്ച്);
• സാങ്കേതിക പ്രക്രിയകൾക്കുള്ള ആവശ്യകതകൾ (നിർദ്ദേശങ്ങൾ, പ്രവേശന മെട്രിക്സ്, മാർഗ്ഗനിർദ്ദേശങ്ങൾ, കോൺഫിഗറേഷൻ ആവശ്യകതകൾ).

ഞങ്ങളുടെ ഫിനാൻഷ്യൽ കമ്പനിയിൽ, കാലഹരണപ്പെട്ട ധാരാളം രേഖകൾ ഞങ്ങൾ കണ്ടെത്തി; നടപ്പിലാക്കുന്ന പുതിയ പ്രക്രിയകൾക്ക് അനുസൃതമായി ഞങ്ങൾ അവ കൊണ്ടുവരേണ്ടതുണ്ട്.

മാനേജ്മെന്റിന്റെ ഉത്തരവനുസരിച്ച്, ഒരു വർക്കിംഗ് ഗ്രൂപ്പ് സൃഷ്ടിച്ചു, അതിൽ സുരക്ഷ, ഐടി, ബിസിനസ്സ്, ആന്തരിക നിയന്ത്രണം എന്നിവയിൽ നിന്നുള്ള പ്രതിനിധികൾ ഉൾപ്പെടുന്നു. ഗ്രൂപ്പ് സൃഷ്ടിക്കുന്നതിന്റെ ലക്ഷ്യങ്ങൾ, പ്രവർത്തനത്തിന്റെ ദിശ, നിലനിൽപ്പിന്റെ കാലഘട്ടം, ഓരോ വശത്തുനിന്നും ഉത്തരവാദിത്തമുള്ളവർ എന്നിവയും ഓർഡർ വിശദീകരിച്ചു. കൂടാതെ, ഞങ്ങൾ ഒരു ഓഡിറ്റ് മെത്തഡോളജിയും ഒരു റോൾ മോഡൽ നിർമ്മിക്കുന്നതിനുള്ള ഒരു നടപടിക്രമവും വികസിപ്പിച്ചെടുത്തു: അവ പ്രദേശങ്ങളിലെ എല്ലാ ഉത്തരവാദിത്തപ്പെട്ട പ്രതിനിധികളും അംഗീകരിക്കുകയും കമ്പനിയുടെ മാനേജ്മെന്റ് അംഗീകരിക്കുകയും ചെയ്തു.

ജോലി നിർവഹിക്കുന്നതിനുള്ള നടപടിക്രമം, സമയപരിധി, ഉത്തരവാദിത്തങ്ങൾ മുതലായവ വിവരിക്കുന്ന രേഖകൾ. - ആദ്യം എല്ലാവർക്കും വ്യക്തമല്ലാത്ത പ്രിയപ്പെട്ട ലക്ഷ്യത്തിലേക്കുള്ള വഴിയിൽ, ആർക്കും “ഞങ്ങൾ ഇത് ചെയ്യുന്നത് എന്തുകൊണ്ട്, എന്തുകൊണ്ടാണ് ഞങ്ങൾക്ക് ഇത് വേണ്ടത് മുതലായവ” എന്ന ചോദ്യങ്ങളുണ്ടാകില്ല എന്നതിന് ഒരു ഉറപ്പ്. കൂടാതെ "ചാടാൻ" അല്ലെങ്കിൽ പ്രക്രിയ മന്ദഗതിയിലാക്കാൻ അവസരമുണ്ടാകില്ല.

ഘട്ടം 4. നിലവിലുള്ള ആക്സസ് കൺട്രോൾ മോഡലിന്റെ പാരാമീറ്ററുകൾ പരിഹരിക്കുക

ആക്സസ് നിയന്ത്രണത്തിന്റെ കാര്യത്തിൽ ഞങ്ങൾ "സിസ്റ്റം പാസ്പോർട്ട്" എന്ന് വിളിക്കപ്പെടുന്ന ഒരു വരയ്ക്കുകയാണ്. സാരാംശത്തിൽ, ഇത് ഒരു നിർദ്ദിഷ്ട വിവര സംവിധാനത്തിലെ ഒരു ചോദ്യാവലിയാണ്, അതിലേക്കുള്ള ആക്സസ് നിയന്ത്രിക്കുന്നതിനുള്ള എല്ലാ അൽഗോരിതങ്ങളും രേഖപ്പെടുത്തുന്നു. ഇതിനകം തന്നെ IdM-ക്ലാസ് സൊല്യൂഷനുകൾ നടപ്പിലാക്കിയിട്ടുള്ള കമ്പനികൾക്ക് അത്തരമൊരു ചോദ്യാവലി പരിചിതമായിരിക്കും, കാരണം ഇവിടെയാണ് സിസ്റ്റങ്ങളുടെ പഠനം ആരംഭിക്കുന്നത്.

സിസ്റ്റത്തെയും ഉടമകളെയും കുറിച്ചുള്ള ചില പാരാമീറ്ററുകൾ ഐടി രജിസ്ട്രിയിൽ നിന്നുള്ള ചോദ്യാവലിയിലേക്ക് ഒഴുകി (ഘട്ടം 2, ഓഡിറ്റ് കാണുക), എന്നാൽ പുതിയവയും ചേർത്തു:

• അക്കൗണ്ടുകൾ എങ്ങനെ കൈകാര്യം ചെയ്യുന്നു (നേരിട്ട് ഡാറ്റാബേസിൽ അല്ലെങ്കിൽ സോഫ്റ്റ്വെയർ ഇന്റർഫേസുകൾ വഴി);
• ഉപയോക്താക്കൾ എങ്ങനെയാണ് സിസ്റ്റത്തിലേക്ക് ലോഗിൻ ചെയ്യുന്നത് (ഒരു പ്രത്യേക അക്കൗണ്ട് ഉപയോഗിച്ച് അല്ലെങ്കിൽ ഒരു AD അക്കൗണ്ട്, LDAP മുതലായവ);
• സിസ്റ്റത്തിലേക്കുള്ള ആക്‌സസ്സിന്റെ ഏത് തലങ്ങളാണ് ഉപയോഗിക്കുന്നത് (അപ്ലിക്കേഷൻ ലെവൽ, സിസ്റ്റം ലെവൽ, നെറ്റ്‌വർക്ക് ഫയൽ ഉറവിടങ്ങളുടെ സിസ്റ്റം ഉപയോഗം);
• സിസ്റ്റം പ്രവർത്തിക്കുന്ന സെർവറുകളുടെ വിവരണവും പാരാമീറ്ററുകളും;
• എന്ത് അക്കൗണ്ട് മാനേജ്മെന്റ് പ്രവർത്തനങ്ങൾ പിന്തുണയ്ക്കുന്നു (തടയുക, പേരുമാറ്റുക, മുതലായവ);
• സിസ്റ്റം ഉപയോക്തൃ ഐഡന്റിഫയർ സൃഷ്ടിക്കുന്നതിന് എന്ത് അൽഗോരിതങ്ങൾ അല്ലെങ്കിൽ നിയമങ്ങൾ ഉപയോഗിക്കുന്നു;
• പേഴ്സണൽ സിസ്റ്റത്തിൽ ഒരു ജീവനക്കാരന്റെ റെക്കോർഡുമായി ഒരു കണക്ഷൻ സ്ഥാപിക്കാൻ എന്ത് ആട്രിബ്യൂട്ട് ഉപയോഗിക്കാം (മുഴുവൻ പേര്, പേഴ്സണൽ നമ്പർ മുതലായവ);
• സാധ്യമായ എല്ലാ അക്കൗണ്ട് ആട്രിബ്യൂട്ടുകളും അവ പൂരിപ്പിക്കുന്നതിനുള്ള നിയമങ്ങളും;
• സിസ്റ്റത്തിൽ എന്ത് ആക്സസ് അവകാശങ്ങൾ നിലവിലുണ്ട് (റോളുകൾ, ഗ്രൂപ്പുകൾ, ആറ്റോമിക് അവകാശങ്ങൾ മുതലായവ, നെസ്റ്റഡ് അല്ലെങ്കിൽ ഹൈറാർക്കിക്കൽ അവകാശങ്ങൾ ഉണ്ടോ);
• ആക്സസ് അവകാശങ്ങൾ വിഭജിക്കുന്നതിനുള്ള സംവിധാനങ്ങൾ (സ്ഥാനം, വകുപ്പ്, പ്രവർത്തനം മുതലായവ);
• സിസ്റ്റത്തിന് അവകാശങ്ങൾ വേർതിരിക്കുന്നതിനുള്ള നിയമങ്ങൾ ഉണ്ടോ (എസ്ഒഡി - ചുമതലകളുടെ വേർതിരിവ്), അവ എങ്ങനെ പ്രവർത്തിക്കുന്നു;
• അസാന്നിദ്ധ്യം, കൈമാറ്റം, പിരിച്ചുവിടൽ, ജീവനക്കാരുടെ ഡാറ്റ അപ്‌ഡേറ്റ് ചെയ്യൽ തുടങ്ങിയ സംഭവങ്ങൾ സിസ്റ്റത്തിൽ എങ്ങനെ പ്രോസസ്സ് ചെയ്യുന്നു.

ആക്സസ് നിയന്ത്രണ പ്രക്രിയയിൽ ഉൾപ്പെട്ടിരിക്കുന്ന വിവിധ പാരാമീറ്ററുകളെയും മറ്റ് ഒബ്ജക്റ്റുകളേയും കുറിച്ചുള്ള വിശദമായി ഈ ലിസ്റ്റ് തുടരാം.

ഘട്ടം 5. അനുമതികളുടെ ബിസിനസ്സ് അധിഷ്ഠിത വിവരണം സൃഷ്ടിക്കുക

ഒരു റോൾ മോഡൽ നിർമ്മിക്കുമ്പോൾ ഞങ്ങൾക്ക് ആവശ്യമായ മറ്റൊരു പ്രമാണം, അതിന്റെ പിന്നിൽ നിൽക്കുന്ന ബിസിനസ്സ് പ്രവർത്തനത്തിന്റെ വിശദമായ വിവരണത്തോടെ വിവര സിസ്റ്റത്തിലെ ഉപയോക്താക്കൾക്ക് നൽകാവുന്ന സാധ്യമായ എല്ലാ അധികാരങ്ങളെയും (അവകാശങ്ങൾ) കുറിച്ചുള്ള ഒരു റഫറൻസ് പുസ്തകമാണ്. മിക്കപ്പോഴും, സിസ്റ്റത്തിലെ അധികാരികൾ അക്ഷരങ്ങളും അക്കങ്ങളും അടങ്ങുന്ന ചില പേരുകൾ ഉപയോഗിച്ച് എൻക്രിപ്റ്റ് ചെയ്തിരിക്കുന്നു, കൂടാതെ ബിസിനസ്സ് ജീവനക്കാർക്ക് ഈ ചിഹ്നങ്ങൾക്ക് പിന്നിൽ എന്താണെന്ന് കണ്ടുപിടിക്കാൻ കഴിയില്ല. തുടർന്ന് അവർ ഐടി സേവനത്തിലേക്ക് പോകുന്നു, അവിടെ ... അവർക്ക് ചോദ്യത്തിന് ഉത്തരം നൽകാൻ കഴിയില്ല, ഉദാഹരണത്തിന്, അപൂർവ്വമായി ഉപയോഗിക്കുന്ന അവകാശങ്ങളെക്കുറിച്ച്. തുടർന്ന് അധിക പരിശോധന നടത്തേണ്ടതുണ്ട്.

ഇതിനകം ഒരു ബിസിനസ്സ് വിവരണം ഉണ്ടെങ്കിലോ ഗ്രൂപ്പുകളിലേക്കും റോളുകളിലേക്കും ഈ അവകാശങ്ങളുടെ സംയോജനമുണ്ടെങ്കിൽ പോലും ഇത് നല്ലതാണ്. ചില ആപ്ലിക്കേഷനുകൾക്ക്, വികസന ഘട്ടത്തിൽ അത്തരമൊരു റഫറൻസ് സൃഷ്ടിക്കുന്നതാണ് ഏറ്റവും നല്ല രീതി. എന്നാൽ ഇത് പലപ്പോഴും സംഭവിക്കുന്നില്ല, അതിനാൽ സാധ്യമായ എല്ലാ അവകാശങ്ങളെയും കുറിച്ചുള്ള വിവരങ്ങൾ ശേഖരിക്കാനും അവ വിവരിക്കാനും ഞങ്ങൾ വീണ്ടും ഐടി വകുപ്പിലേക്ക് പോകുന്നു. ഞങ്ങളുടെ ഗൈഡിൽ ആത്യന്തികമായി ഇനിപ്പറയുന്നവ അടങ്ങിയിരിക്കും:

• ആക്സസ് അവകാശം ബാധകമാകുന്ന ഒബ്ജക്റ്റ് ഉൾപ്പെടെയുള്ള അധികാരത്തിന്റെ പേര്;
• ഒരു ഒബ്‌ജക്‌റ്റ് ഉപയോഗിച്ച് ചെയ്യാൻ അനുവദിക്കുന്ന ഒരു പ്രവർത്തനം (കാണുക, മാറ്റുക, മുതലായവ, നിയന്ത്രണത്തിനുള്ള സാധ്യത, ഉദാഹരണത്തിന്, പ്രദേശിക അടിസ്ഥാനത്തിൽ അല്ലെങ്കിൽ ക്ലയന്റുകളുടെ ഗ്രൂപ്പ്);
• ഓതറൈസേഷൻ കോഡ് (സിസ്‌റ്റം ഫംഗ്‌ഷന്റെ കോഡും പേരും/അഭ്യർത്ഥനയുടെ അംഗീകാരം ഉപയോഗിച്ച് എക്‌സിക്യൂട്ട് ചെയ്യാവുന്നതാണ്);
• അധികാരത്തിന്റെ വിവരണം (അതോറിറ്റി പ്രയോഗിക്കുമ്പോൾ IS-ലെ പ്രവർത്തനങ്ങളുടെ വിശദമായ വിവരണം, പ്രക്രിയയ്ക്കുള്ള അവയുടെ അനന്തരഫലങ്ങൾ;
• അനുമതി നില: "ആക്റ്റീവ്" (കുറഞ്ഞത് ഒരു ഉപയോക്താവിന് അനുമതി നൽകിയിട്ടുണ്ടെങ്കിൽ) അല്ലെങ്കിൽ "സജീവമല്ല" (അനുമതി ഉപയോഗിച്ചിട്ടില്ലെങ്കിൽ).

ഘട്ടം 6 ഞങ്ങൾ സിസ്റ്റങ്ങളിൽ നിന്ന് ഉപയോക്താക്കളെയും അവകാശങ്ങളെയും കുറിച്ചുള്ള ഡാറ്റ ഡൗൺലോഡ് ചെയ്യുകയും വ്യക്തിഗത ഉറവിടവുമായി താരതമ്യം ചെയ്യുകയും ചെയ്യുന്നു

തയ്യാറെടുപ്പിന്റെ അവസാന ഘട്ടത്തിൽ, എല്ലാ ഉപയോക്താക്കളെയും അവർക്ക് നിലവിൽ ഉള്ള അവകാശങ്ങളെയും കുറിച്ചുള്ള വിവര സിസ്റ്റങ്ങളിൽ നിന്ന് നിങ്ങൾ ഡാറ്റ ഡൗൺലോഡ് ചെയ്യേണ്ടതുണ്ട്. ഇവിടെ രണ്ട് സാഹചര്യങ്ങൾ സാധ്യമാണ്. ആദ്യം: സുരക്ഷാ വകുപ്പിന് സിസ്റ്റത്തിലേക്ക് നേരിട്ട് ആക്സസ് ഉണ്ട് കൂടാതെ പ്രസക്തമായ റിപ്പോർട്ടുകൾ ഡൗൺലോഡ് ചെയ്യാനുള്ള മാർഗമുണ്ട്, അത് പലപ്പോഴും സംഭവിക്കുന്നില്ല, എന്നാൽ വളരെ സൗകര്യപ്രദമാണ്. രണ്ടാമത്: ആവശ്യമായ ഫോർമാറ്റിൽ റിപ്പോർട്ടുകൾ ലഭിക്കുന്നതിന് ഞങ്ങൾ ഐടിയിലേക്ക് ഒരു അഭ്യർത്ഥന അയയ്ക്കുന്നു. ഐടിയുമായി ധാരണയിലെത്താനും ആവശ്യമായ ഡാറ്റ ആദ്യമായി നേടാനും കഴിയില്ലെന്ന് അനുഭവം കാണിക്കുന്നു. ആവശ്യമുള്ള ഫോമിലും ഫോർമാറ്റിലും വിവരങ്ങൾ ലഭിക്കുന്നതുവരെ നിരവധി സമീപനങ്ങൾ നടത്തേണ്ടത് ആവശ്യമാണ്.

എന്ത് ഡാറ്റയാണ് ഡൗൺലോഡ് ചെയ്യേണ്ടത്:

• അക്കൗണ്ട് നാമം
• അത് നിയോഗിക്കപ്പെട്ട ജീവനക്കാരന്റെ മുഴുവൻ പേര്
• നില (സജീവമായതോ തടഞ്ഞതോ)
• അക്കൗണ്ട് സൃഷ്ടിക്കുന്ന തീയതി
• അവസാനം ഉപയോഗിച്ച തീയതി
• ലഭ്യമായ അവകാശങ്ങൾ/ഗ്രൂപ്പുകൾ/റോളുകളുടെ ലിസ്റ്റ്

അതിനാൽ, എല്ലാ ഉപയോക്താക്കളുമായും സിസ്റ്റത്തിൽ നിന്ന് ഡൗൺലോഡുകളും അവർക്ക് നൽകിയിട്ടുള്ള എല്ലാ അവകാശങ്ങളും ഞങ്ങൾക്ക് ലഭിച്ചു. ഒരു റോൾ മോഡൽ നിർമ്മിക്കുന്നതിനുള്ള പ്രവർത്തനങ്ങൾ സജീവ ഉപയോക്താക്കൾക്ക് മാത്രമുള്ളതിനാൽ അവർ തടഞ്ഞ എല്ലാ അക്കൗണ്ടുകളും ഉടനടി മാറ്റിവച്ചു.

പിരിച്ചുവിട്ട ജീവനക്കാരിലേക്കുള്ള ആക്‌സസ് തടയുന്നതിന് നിങ്ങളുടെ കമ്പനിക്ക് സ്വയമേവയുള്ള മാർഗ്ഗങ്ങൾ ഇല്ലെങ്കിലോ (ഇത് പലപ്പോഴും സംഭവിക്കാറുണ്ട്) അല്ലെങ്കിൽ എല്ലായ്പ്പോഴും ശരിയായി പ്രവർത്തിക്കാത്ത പാച്ച് വർക്ക് ഓട്ടോമേഷൻ ഉണ്ടെങ്കിൽ, നിങ്ങൾ എല്ലാ "മരിച്ച ആത്മാക്കളെയും" തിരിച്ചറിയേണ്ടതുണ്ട്. ഞങ്ങൾ ഇതിനകം പിരിച്ചുവിട്ട ജീവനക്കാരുടെ അക്കൗണ്ടുകളെക്കുറിച്ചാണ് സംസാരിക്കുന്നത്, ചില കാരണങ്ങളാൽ അവരുടെ അവകാശങ്ങൾ തടഞ്ഞിട്ടില്ല - അവരെ തടയേണ്ടതുണ്ട്. ഇത് ചെയ്യുന്നതിന്, ഞങ്ങൾ അപ്‌ലോഡ് ചെയ്ത ഡാറ്റ വ്യക്തിഗത ഉറവിടവുമായി താരതമ്യം ചെയ്യുന്നു. പേഴ്‌സണൽ ഡാറ്റാബേസ് പരിപാലിക്കുന്ന ഡിപ്പാർട്ട്‌മെന്റിൽ നിന്ന് പേഴ്‌സണൽ അൺലോഡിംഗും മുൻകൂട്ടി വാങ്ങണം.

വ്യക്തിഗത ഡാറ്റാബേസിൽ ഉടമകളെ കണ്ടെത്താത്ത, ആർക്കും നൽകിയിട്ടില്ലാത്ത - അതായത് ഉടമയില്ലാത്ത അക്കൗണ്ടുകൾ പ്രത്യേകം മാറ്റിവെക്കേണ്ടത് ആവശ്യമാണ്. ഈ ലിസ്റ്റ് ഉപയോഗിക്കുമ്പോൾ, അവസാനമായി ഉപയോഗിച്ച തീയതി ഞങ്ങൾക്ക് ആവശ്യമായി വരും: ഇത് വളരെ സമീപകാലമാണെങ്കിൽ, ഞങ്ങൾ ഇപ്പോഴും ഉടമകളെ അന്വേഷിക്കേണ്ടതുണ്ട്. ഇതിൽ ബാഹ്യ കോൺട്രാക്ടർമാരുടെ അക്കൗണ്ടുകൾ അല്ലെങ്കിൽ ആർക്കും അസൈൻ ചെയ്യാത്ത, എന്നാൽ ഏതെങ്കിലും പ്രക്രിയകളുമായി ബന്ധപ്പെട്ട സേവന അക്കൗണ്ടുകൾ ഉൾപ്പെട്ടേക്കാം. അക്കൗണ്ടുകൾ ആരുടേതാണെന്ന് കണ്ടെത്താൻ, എല്ലാ വകുപ്പുകളോടും പ്രതികരിക്കാൻ ആവശ്യപ്പെട്ട് നിങ്ങൾക്ക് കത്തുകൾ അയയ്ക്കാം. ഉടമകളെ കണ്ടെത്തുമ്പോൾ, അവരെക്കുറിച്ചുള്ള ഡാറ്റ ഞങ്ങൾ സിസ്റ്റത്തിലേക്ക് നൽകുന്നു: ഈ രീതിയിൽ, എല്ലാ സജീവ അക്കൗണ്ടുകളും തിരിച്ചറിയുകയും ബാക്കിയുള്ളവ തടയുകയും ചെയ്യുന്നു.

ഞങ്ങളുടെ അപ്‌ലോഡുകൾ അനാവശ്യമായ രേഖകളിൽ നിന്ന് മായ്‌ക്കപ്പെടുകയും സജീവമായ അക്കൗണ്ടുകൾ മാത്രം അവശേഷിക്കുകയും ചെയ്‌താൽ, ഒരു പ്രത്യേക വിവര സംവിധാനത്തിനായി നമുക്ക് ഒരു റോൾ മോഡൽ നിർമ്മിക്കാൻ തുടങ്ങാം. എന്നാൽ ഇതിനെക്കുറിച്ച് അടുത്ത ലേഖനത്തിൽ ഞാൻ നിങ്ങളോട് പറയും.

രചയിതാവ്: ല്യൂഡ്മില സെവസ്ത്യാനോവ, പ്രമോഷൻ മാനേജർ സോളാർ ഇൻ റൈറ്റ്സ്

അവലംബം: www.habr.com