ആക്സസ് കൺട്രോൾ, ഐഡൻ്റിറ്റി, സീക്രട്ട് മാനേജ്മെൻ്റ്

നേട്ടങ്ങൾ:

• പ്രാമാണീകരണവും അംഗീകാരവും വേർതിരിക്കാനും RBAC/ABAC ഉപയോഗിച്ച് ഏറ്റവും കുറഞ്ഞ അംഗീകാരം പ്രയോഗിക്കാനുമുള്ള കഴിവ്
• ഉപയോക്തൃ സന്ദർഭത്തിൽ മോഡൽ പ്രവർത്തിപ്പിക്കുന്നതിലൂടെ മിക്സഡ് പ്രോക്സി റിസ്ക് ഒഴിവാക്കാനുള്ള കഴിവ്
• രഹസ്യ മാനേജ്മെൻ്റ് സിസ്റ്റം ഉപയോഗിച്ച് API കീകൾ സംഭരിക്കാനും തിരിക്കാനും ഉള്ള കഴിവ്

ഒരു AI സിസ്റ്റത്തിലെ ആക്രമണങ്ങളുടെ ഒരു പ്രധാന ഭാഗം ആരംഭിക്കുന്നത് മോഡലിനെ "കബളിപ്പിക്കൽ" കൊണ്ടല്ല, മോഷ്ടിച്ച API കീ അല്ലെങ്കിൽ ഒരു അധിക അംഗീകൃത അക്കൗണ്ട് ഉപയോഗിച്ചാണ്. ഈ സുരക്ഷാ പാളി ക്ലാസിക്കൽ വിവര സുരക്ഷയിൽ നിന്നാണ് വരുന്നത്, എന്നാൽ AI-യുടെ പശ്ചാത്തലത്തിൽ പുതിയ അപകടസാധ്യതകൾ ചേർക്കുന്നു: ഒരു മോഡൽ മറ്റൊരാളുടെ പേരിൽ ഒരു റൈഡ് വിളിക്കുന്നു, ഒരു സേവന അക്കൗണ്ട് എല്ലാ ഡാറ്റയും ആക്‌സസ് ചെയ്യുന്നു, GitHub-ലേക്കുള്ള ഒരു കീ ചോർച്ച. ഈ യൂണിറ്റിൽ, പ്രാമാണീകരണം, അംഗീകാരം (RBAC/ABAC), മിനിമം അംഗീകാരം, രഹസ്യ മാനേജുമെൻ്റ് എന്നിവ ഉപയോഗിച്ച് AI സിസ്റ്റത്തിലേക്കുള്ള പ്രവേശനം എങ്ങനെ ചുരുക്കാമെന്ന് ഞങ്ങൾ പഠിക്കും.

പ്രാമാണീകരണവും അംഗീകാരവും തമ്മിലുള്ള വ്യത്യാസം

രണ്ട് പദങ്ങളും പലപ്പോഴും ആശയക്കുഴപ്പത്തിലാണ്:

• പ്രാമാണീകരണം: "നിങ്ങൾ ആരാണ്?" — ഉപയോക്താവ്/സേവനം യഥാർത്ഥത്തിൽ അവർ അവകാശപ്പെടുന്നവരാണെന്ന് തെളിയിക്കുന്നു (പാസ്വേഡ്, ടോക്കൺ, സർട്ടിഫിക്കറ്റ്, എംഎഫ്എ).
• അംഗീകാരം: "നിങ്ങൾക്ക് എന്ത് ചെയ്യാൻ കഴിയും?" - ആധികാരിക കക്ഷിക്ക് ഏത് റിസോഴ്സ്/ആക്ഷൻ ആക്സസ് ചെയ്യാനാകുമെന്ന് നിർണ്ണയിക്കുക.

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

മുന്നറിയിപ്പ്: "ആശയക്കുഴപ്പത്തിലായ ഡെപ്യൂട്ടി" പ്രശ്നം: ഒരു താഴ്ന്ന അധികാരമുള്ള ഉപയോക്താവ്, ഉയർന്ന അധികാരമുള്ള മോഡൽ ഔട്ട്സോഴ്സിംഗ് വഴി തനിക്ക് ആക്സസ് ചെയ്യാൻ കഴിയാത്ത ഡാറ്റ പരോക്ഷമായി ആക്സസ് ചെയ്യുന്നു. മോഡൽ എല്ലായ്‌പ്പോഴും പ്രവർത്തിക്കേണ്ടത് ഉപയോക്താവിൻ്റെ അധികാരത്തിൻ്റെ പശ്ചാത്തലത്തിലാണ്, അല്ലാതെ അവൻ്റെ സ്വന്തം വിശാലമായ അധികാരമല്ല.

RBAC, ABAC എന്നിവ

• RBAC (റോൾ-ബേസ്ഡ് ആക്സസ് കൺട്രോൾ): പ്രവേശനം ഉപയോക്താവിൻ്റെ റോളിനെ ആശ്രയിച്ചിരിക്കുന്നു. "പിന്തുണ സ്പെഷ്യലിസ്റ്റ്" റോളിന് ഉപഭോക്തൃ കുറിപ്പുകൾ വായിക്കാൻ കഴിയും, പക്ഷേ അവ ഇല്ലാതാക്കാൻ കഴിയില്ല. ലളിതവും പൊതുവായതും.
• ABAC (ആട്രിബ്യൂട്ട് അടിസ്ഥാനമാക്കിയുള്ള ആക്‌സസ് കൺട്രോൾ): ആക്‌സസ് ആട്രിബ്യൂട്ടുകളെ ആശ്രയിച്ചിരിക്കുന്നു: ഉപയോക്താവിൻ്റെ വകുപ്പ്, ഡാറ്റയുടെ സ്വകാര്യത ലേബൽ, ദിവസത്തിൻ്റെ സമയം, അഭ്യർത്ഥന വരുന്ന നെറ്റ്‌വർക്ക്. കൂടുതൽ സൂക്ഷ്മമായതും എന്നാൽ കൂടുതൽ സങ്കീർണ്ണവുമാണ്.

മിക്ക ഓർഗനൈസേഷനുകളും RBAC-ൽ ആരംഭിക്കുകയും സെൻസിറ്റീവ് ഡാറ്റയ്‌ക്കായി ABAC-ലേക്ക് ആഴപ്പെടുകയും ചെയ്യുന്നു. AI-യുടെ പ്രധാന നിയമം: അഭ്യർത്ഥന നടത്തുന്ന ഉപയോക്താവിൻ്റെ റോൾ/ആട്രിബ്യൂട്ടുകളെ അടിസ്ഥാനമാക്കി മോഡൽ അത് വിളിക്കുന്ന എല്ലാ ഏജൻ്റിനെയും ആക്‌സസ് ചെയ്യുന്ന എല്ലാ ഡാറ്റയെയും ഫിൽട്ടർ ചെയ്യണം.

ഘട്ടം ഘട്ടമായി: മിനിമൽ അതോറിറ്റി പ്രയോഗിക്കുന്നു

1. ഇൻവെൻ്ററി എടുക്കുക. ഏത് ഉപകരണങ്ങളെയാണ് മോഡൽ വിളിക്കുന്നത്, ഏത് ഡാറ്റയാണ് അത് ആക്‌സസ് ചെയ്യുന്നത്? അവയെല്ലാം പട്ടികപ്പെടുത്തുക.
2. ഓരോ പ്രവേശനവും ന്യായീകരിക്കുക. "ഈ അസിസ്റ്റൻ്റിന് ശരിക്കും ഡിലീറ്റ് അതോറിറ്റി ആവശ്യമുണ്ടോ?" അല്ലെങ്കിൽ, അത് നീക്കം ചെയ്യുക.
3. വായന-മാത്രം ഡിഫോൾട്ട്. മോഡലിന് സ്ഥിരസ്ഥിതിയായി വായിക്കാൻ കഴിയണം; പ്രത്യേകം, ഇടുങ്ങിയ സ്കോപ്പ് ടോക്കൺ എഴുതുക/ഇല്ലാതാക്കുക ആവശ്യമാണ്.
4. ഉപയോക്തൃ സന്ദർഭം നീക്കുക. സേവന അക്കൗണ്ട് ഉപയോഗിച്ചല്ല, ഉപയോക്താവിൻ്റെ അധികാരത്തോടെ വാഹനത്തെ വിളിക്കുക.
5. ഹ്രസ്വകാല ക്രെഡൻഷ്യൽ. ദീർഘകാല കീകൾക്ക് പകരം ഹ്രസ്വകാല, സ്വയമേവ പുതുക്കുന്ന ടോക്കണുകൾ ഉപയോഗിക്കുക.

രഹസ്യ മാനേജ്മെൻ്റ്

API കീ, പാസ്‌വേഡ്, ടോക്കൺ അല്ലെങ്കിൽ സർട്ടിഫിക്കറ്റ് പോലെ രഹസ്യമായി തുടരേണ്ട ക്രെഡൻഷ്യലുകളാണ് രഹസ്യം. AI പ്രോജക്റ്റുകളിലെ ഏറ്റവും സാധാരണമായ അപകടം, മോഡൽ ദാതാവിൻ്റെ API കീ കോഡിൽ ഉൾച്ചേർത്ത് പതിപ്പ് നിയന്ത്രണത്തിലേക്ക് (Git) ചോർന്നുപോകുമ്പോഴാണ്.

ശരിയായ അപേക്ഷ:

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

പകർത്താവുന്ന നാല് ടെംപ്ലേറ്റുകൾ

ആക്സസ് അവലോകന നിയന്ത്രണ നിർദ്ദേശം:

ചുവടെയുള്ള ടൂൾ ലിസ്റ്റിലെ ഓരോ ടൂളിനും, വിലയിരുത്തുക:- ഈ അസിസ്റ്റൻ്റിൻ്റെ ജോലി നിർവഹിക്കാൻ ഈ ടൂൾ ആവശ്യമാണോ? (അതെ/ഇല്ല) - ഇത് വായിക്കാൻ മാത്രമാണോ അതോ എഴുതുക/മായ്ക്കുകയാണോ? - ഈ ഉപകരണം ഉപയോക്താവിൻ്റെ അധികാരം അല്ലെങ്കിൽ സേവന അക്കൗണ്ട് ഉപയോഗിച്ച് വിളിക്കപ്പെടുന്നുണ്ടോ? ആവശ്യമില്ലാത്തതോ അമിതമായി അംഗീകൃതമായതോ ആയവയെ "നീക്കം ചെയ്യുക/പുനർപ്പെടുത്തുക" എന്ന് അടയാളപ്പെടുത്തുക.<tools>{{ tool_list }}</tools>

രഹസ്യ ചോർച്ച സ്കാനിംഗ് പ്രോംപ്റ്റ്:

ഇനിപ്പറയുന്ന കോഡ് സ്‌നിപ്പറ്റിൽ ഹാർഡ്‌കോഡ് ചെയ്‌ത രഹസ്യമായേക്കാവുന്ന എന്തും കണ്ടെത്തുക: API കീ, പാസ്‌വേഡ്, ടോക്കൺ, കണക്ഷൻ സ്ട്രിംഗ്, സ്വകാര്യ കീ. ഓരോന്നിനും വരിയും തരവും നൽകുക. പ്രതികരണത്തിലേക്ക് മൂല്യം പകർത്തുക;മാസ്ക് (ആദ്യത്തെ 4 പ്രതീകങ്ങൾ + ***).<code>{{ source }}</code>

ഏറ്റവും കുറഞ്ഞ അധികാര തീരുമാന നിയമം:

ഒരു പുതിയ ടൂൾ/ആക്സസ് അഭ്യർത്ഥന വരുമ്പോൾ, ചോദിക്കുക:1. ഈ ആക്സസ് ഇല്ലാതെ ചുമതല നിർവഹിക്കാൻ കഴിയുമോ? -> ഉണ്ടെങ്കിൽ: REJECT2. വായന മാത്രം മതിയോ? -> ഉണ്ടെങ്കിൽ: ഗ്രാൻ്റ് റൈറ്റ് പെർമിഷൻ3. വ്യാപ്തി ഒരൊറ്റ ഉറവിടത്തിലേക്ക് ചുരുക്കാൻ കഴിയുമോ? -> ഉണ്ടെങ്കിൽ: darat സ്ഥിരസ്ഥിതി ഉത്തരം "ഇല്ല"; യുക്തിയാൽ പ്രവേശനം ലഭിക്കുന്നു.

റൊട്ടേഷൻ കലണ്ടർ ഓർമ്മപ്പെടുത്തൽ:

ഓരോ രഹസ്യത്തിനും, റെക്കോർഡ്: ഉടമ, സൃഷ്ടിച്ച തീയതി, കാലഹരണപ്പെടൽ, വ്യാപ്തി. 90 ദിവസം കവിഞ്ഞതോ 30 ദിവസമായി ഉപയോഗിക്കാത്തതോ ആയ ഏതെങ്കിലും കീ "റൊട്ടേഷൻ/റദ്ദാക്കൽ സ്ഥാനാർത്ഥി" ആയി റിപ്പോർട്ട് ചെയ്യുക.

ദുർബലമായ പ്രോംപ്റ്റ് / ശക്തമായ പ്രോംപ്റ്റ്

മോശം സമീപനം

ശക്തമായ സമീപനം

ഒരൊറ്റ സേവന അക്കൗണ്ട് ഉപയോഗിച്ച് മോഡൽ എല്ലാ ഡാറ്റയും ആക്‌സസ് ചെയ്യുന്നു

അഭ്യർത്ഥന നടത്തുന്ന ഉപയോക്താവിൻ്റെ അധികാരം ഉപയോഗിച്ച് മോഡൽ ആക്സസ് ചെയ്യുന്നു

API കീ കോഡിൽ ഉൾപ്പെടുത്തിയിട്ടുണ്ട്, അത് ഒരിക്കലും മാറില്ല

പ്രധാന രഹസ്യ മാനേജരിൽ റൊട്ടേഷൻ, 90 ദിവസം

അസിസ്റ്റൻ്റിന് വിശാലമായ "എന്തും ചെയ്യുക" അധികാരം

വായന-മാത്രം ഡിഫോൾട്ട്, ഇടുങ്ങിയ രീതിയിൽ എഴുതുക

ആക്സസുകൾ ഒരിക്കലും അവലോകനം ചെയ്യില്ല

പതിവ് ആക്സസ് അവലോകനവും അസാധുവാക്കലും

മൂന്ന് മിനി കേസുകൾ

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

കേസ് 2 - ചോർന്ന കീ, 2 ആഴ്ചയ്ക്കുള്ളിൽ 190,000 TL ബിൽ. ഒരു ഡെവലപ്പർ ഒരു ഹെൽപ്പർ സ്ക്രിപ്റ്റിൽ മോഡൽ API കീ ഉൾച്ചേർക്കുകയും അത് ഒരു പൊതു ശേഖരത്തിലേക്ക് തള്ളുകയും ചെയ്തു. ഒരു ബോട്ട് 40 മിനിറ്റിനുള്ളിൽ കീ കണ്ടെത്തി രണ്ടാഴ്ചയോളം ഉപയോഗിച്ചു; ബിൽ 190,000 TL ആയി. താക്കോൽ രഹസ്യ മാനേജറിലേക്ക് മാറ്റി, റൊട്ടേഷനുമായി ബന്ധിപ്പിച്ച്, റിപ്പോസിറ്ററി സ്കാനിംഗ് ചേർത്തപ്പോൾ, സംഭവം വീണ്ടും ഉണ്ടായില്ല.

കേസ് 3 - വായന-മാത്രം ഡിഫോൾട്ട് തടസ്സം തടഞ്ഞു. ഒരു DevOps അസിസ്റ്റൻ്റിന് പ്രോംപ്റ്റ് ഇഞ്ചക്ഷൻ വഴി "റീസെറ്റ് പ്രൊഡക്ഷൻ ഡാറ്റാബേസ്" കമാൻഡ് ലഭിച്ചു. എന്നിരുന്നാലും, അസിസ്റ്റൻ്റിന് വായിക്കാൻ മാത്രമുള്ള ടോക്കൺ മാത്രമാണ് നൽകിയത്; എഴുതുക/മായ്ക്കുക ഒരു പ്രത്യേക അംഗീകൃത ഫ്ലോയിലായിരുന്നു. അധികാരപ്പെടുത്തൽ പിശക് ഉപയോഗിച്ച് കമാൻഡ് നിരസിക്കുകയും ഇവൻ്റ് ഒരു അലാറമായി ലോഗ് ചെയ്യുകയും ചെയ്തു; ഡാറ്റ നഷ്‌ടമായില്ല.

നുറുങ്ങ്: ഒരു പുതിയ ആക്‌സസ് അഭ്യർത്ഥനയ്ക്കുള്ള നിങ്ങളുടെ ഡിഫോൾട്ട് ഉത്തരം "ഇല്ല" ആക്കുക. ന്യായീകരണത്തിലൂടെ നേടിയെടുത്ത ഒന്നാണ് പ്രവേശനം; എല്ലാവർക്കും വിശാലമായി നൽകുകയും പിന്നീട് വെട്ടിക്കുറയ്ക്കുകയും ചെയ്യുന്നത് ഒരിക്കലും ചെയ്യപ്പെടുന്നില്ല, അപകടസാധ്യത കുമിഞ്ഞുകൂടുന്നു.

സാധാരണ തെറ്റുകൾ

• ഒരു വലിയ സേവന അക്കൗണ്ട് ഉപയോഗിച്ച് മോഡൽ പ്രവർത്തിപ്പിക്കുകയും ഉപയോക്തൃ സന്ദർഭം (മിക്സഡ് പ്രോക്സി) നഷ്ടപ്പെടുകയും ചെയ്യുന്നു.
• കോഡിൽ API കീ ഉൾച്ചേർത്ത് പതിപ്പ് നിയന്ത്രണത്തിലേക്ക് ചോർത്തുന്നു.
• കീകൾ തിരിയുന്നില്ല ("പ്രവർത്തിക്കുന്നു, തൊടരുത്").
• അസിസ്റ്റൻ്റിന് ഡിഫോൾട്ടായി എഴുത്ത്/ഇല്ലാതാക്കൽ അനുമതികൾ നൽകുന്നു.
• ഒരിക്കൽ പ്രവേശനം അനുവദിക്കുക, അത് ഒരിക്കലും പുനർവിചിന്തനം ചെയ്യരുത്.
• ആധികാരികതയെ ആശയക്കുഴപ്പത്തിലാക്കുകയും "അവൻ ലോഗിൻ ചെയ്‌തിരിക്കുന്നു, അവന് എല്ലാം ആക്‌സസ് ചെയ്യാൻ കഴിയും" എന്ന് അനുമാനിക്കുകയും ചെയ്യുക.

ചുരുക്കത്തിൽ

• ആധികാരികത എന്നത് "നിങ്ങൾ ആരാണ്" എന്ന ചോദ്യമാണ്, അംഗീകാരം എന്നത് "നിങ്ങൾക്ക് എന്ത് ചെയ്യാൻ കഴിയും" എന്നതിൻ്റെ ഒരു ചോദ്യമാണ്; AI-യിൽ, രണ്ടും ഉപയോക്താവിൻ്റെ പശ്ചാത്തലത്തിൽ പ്രവർത്തിക്കണം.
• അഭ്യർത്ഥന നടത്തുന്ന ഉപയോക്താവിൻ്റെ അധികാരത്തോടെയാണ് മോഡൽ പ്രവർത്തിക്കേണ്ടത്, അതിൻ്റേതായ വിശാലമായ അധികാരത്തോടെയല്ല (മിക്സഡ് ഏജൻസിയുടെ അപകടസാധ്യത ഒഴിവാക്കുന്നു).
• RBAC ഉപയോഗിച്ച് ആരംഭിക്കുക, സെൻസിറ്റീവ് ഡാറ്റയിൽ ABAC ഉപയോഗിച്ച് ആഴത്തിലാക്കുക; മിനിമം അധികാരം ഡിഫോൾട്ടാക്കുക.
• രഹസ്യങ്ങൾ കോഡിൽ അടക്കം ചെയ്യരുത്; അത് രഹസ്യ മാനേജറിൽ സംഭരിക്കുക, ചുരുക്കുക, പതിവ് റൊട്ടേഷനിൽ ഇടുക.
• വായന-മാത്രം സ്ഥിരസ്ഥിതിയും ഇടുങ്ങിയ എഴുത്തും കുത്തിവയ്പ്പിൻ്റെ ആഘാതത്തെ വളരെയധികം പരിമിതപ്പെടുത്തുന്നു.

ആപ്ലിക്കേഷൻ ടാസ്ക്

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

ചെക്ക്ലിസ്റ്റ്

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