നിങ്ങളുടെ ആപ്പിൽ റോൾ-അടിസ്ഥാനമാക്കിയ ആക്സസ് കൺട്രോൾ (RBAC) ചേർക്കുന്നത് എങ്ങനെ

ഒരു റോൾ-അടിസ്ഥാനമാക്കിയ ആക്സസ് കൺട്രോൾ ചേർക്കാൻ, ഓരോ ഉപയോക്താവിനും ഒന്നോ അതിലധികമോ റോളുകൾ നൽകുക (ഉദാഹരണത്തിന് admin, editor, viewer), ഓരോ റോളിനും ചെയ്യാവുന്ന പ്രവർത്തനങ്ങൾ നിർവചിക്കുക, ഓരോ അഭ്യർത്ഥനയ്ക്കും ആ അനുമതികൾ സെർവറിൽ പരിശോധിക്കുക — ബട്ടണുകൾ ഒളിപ്പിക്കുന്നത് മാത്രം പോരാ. ആക്സസ് ചെയ്യുന്ന റെക്കോർഡ് ഉപയോക്താവിന്റെ അക്കൗണ്ടിലോ ടീമിലോ പെട്ടതാണോ എന്നും പരിശോധിക്കുക. ഡേറ്റാബേസിൽ കുറച്ച് സ്ഥിര റോളുകളിൽ തുടങ്ങുക, മറ്റൊരു ഉപയോക്താവിന്റെ ഡേറ്റ നേരിട്ട് എത്താൻ ശ്രമിച്ച് പരീക്ഷിക്കുക.

ഓതെന്റിക്കേഷനും ഓതറൈസേഷനും

പരസ്പരം കൂടിക്കലരുന്ന രണ്ട് വാക്കുകൾ:

• ഓതെന്റിക്കേഷൻ എന്നാൽ നിങ്ങൾ ആരാണ്? — ലോഗിൻ ചെയ്യൽ. നിങ്ങളുടെ ആപ്പിൽ ലോഗിൻ ചേർക്കുന്നത് എങ്ങനെ കാണുക.
• ഓതറൈസേഷൻ എന്നാൽ നിങ്ങൾക്ക് എന്ത് ചെയ്യാൻ അനുവാദമുണ്ട്? — ലോഗിൻ ചെയ്ത ഉപയോക്താവിന് എത്താവുന്ന പേജുകൾ, റെക്കോർഡുകൾ, പ്രവർത്തനങ്ങൾ.

ഓതറൈസേഷൻ ചെയ്യാനുള്ള ഏറ്റവും സാധാരണ വഴിയാണ് RBAC. ഇത് പ്രധാനമാണ്: 2026 സെപ്റ്റംബർ വരെ, Broken Access Control OWASP Top 10:2025-ൽ ഒന്നാമതാണ്, വെബ് ആപ്പ് സുരക്ഷാ അപകടങ്ങളുടെ ഏറ്റവും ഗുരുതരമായവയുടെ വ്യാപകമായി ഉപയോഗിക്കുന്ന പട്ടിക. സാധാരണ പരാജയങ്ങൾ: URL-ലെ ഒരു ID മാറ്റി മറ്റുള്ളവരുടെ റെക്കോർഡുകൾ വായിക്കുക, അല്ലെങ്കിൽ സാധാരണ ഉപയോക്താക്കൾ അഡ്മിൻ-മാത്രം API റൂട്ടുകൾ വിളിക്കുക.

ഒരു മോഡൽ തിരഞ്ഞെടുക്കുക

പ്രായോഗികമായി, മിക്ക ആപ്പുകളും രണ്ട് കാര്യങ്ങൾ സംയോജിപ്പിക്കുന്നു: ഏത് തരം പ്രവർത്തനം ചെയ്യാമെന്നതിന് റോളുകൾ, ഏത് റെക്കോർഡുകളിൽ ചെയ്യാമെന്നതിന് ഉടമസ്ഥത. "എഡിറ്റർമാർക്ക് പോസ്റ്റുകൾ എഡിറ്റ് ചെയ്യാം" ഒരു റോൾ നിയമമാണ്; "…അവരുടെ സ്വന്തം വർക്ക്സ്‌പേസിലെ പോസ്റ്റുകൾ" ഒരു ഉടമസ്ഥതാ നിയമമാണ്. രണ്ടും വേണം.

നിങ്ങൾ കരുതുന്നതിനേക്കാൾ ലളിതമായി തുടങ്ങുക. Admin, member, viewer എന്നിവ അത്ഭുതകരമാംവിധം പല ആപ്പുകളെയും മതിയാകും. പത്ത് റോളുകൾ ആരും മനസ്സിലാക്കാത്ത അവസ്ഥയിൽ എത്തിച്ച് പിന്നീട് അഴിക്കുന്നതിനേക്കാൾ എളുപ്പമാണ് പിന്നീട് ഒരു റോൾ വിഭജിക്കുന്നത്.

കോഡ് എഴുതുന്നതിന് മുമ്പ് റോളുകൾ രൂപകൽപ്പന ചെയ്യുക

ആദ്യം സാധാരണ ഭാഷയിൽ ഒരു അനുമതി പട്ടിക എഴുതുക. അത് AI-ക്കുള്ള സ്പെസിഫിക്കേഷനായും നിങ്ങളുടെ ടെസ്റ്റ് പ്ലാനായും ഇരട്ടിക്കും:

എഡ്ജ് കേസുകളും തീരുമാനിക്കുക: അവസാന ഉടമയ്ക്ക് വിട്ടുപോകാമോ? ഒരു admin ഉടമയെ നീക്കം ചെയ്യാമോ? നീക്കം ചെയ്യപ്പെട്ട ഉപയോക്താവ് എന്ത് കാണും?

ഘട്ടം ഘട്ടമായി

1. പ്രവർത്തിക്കുന്ന ലോഗിൻ ആദ്യം

RBAC ഓതെന്റിക്കേഷന് മുകളിലാണ് ഇരിക്കുന്നത്. ഓരോ അഭ്യർത്ഥനയും ആരാണ് ചെയ്യുന്നതെന്ന് സെർവർ വിശ്വസനീയമായി അറിയണം, ഒരു സെഷനിൽ നിന്നോ പരിശോധിച്ച ടോക്കണിൽ നിന്നോ — ഒരിക്കലും അഭ്യർത്ഥന ബോഡിയിൽ ബ്രൗസർ അയക്കുന്ന ഒരു user ID-യിൽ നിന്നല്ല.

2. റോളുകൾ ഡേറ്റാബേസിൽ സൂക്ഷിക്കുക

ഒരൊറ്റ ടീം ആപ്പിന് ഉപയോക്താക്കളിൽ ഒരു role കോളം മതി. ടീമുകൾക്ക് ഒരു മെമ്പർഷിപ്പ് ടേബിൾ ഉപയോഗിക്കുക:

create table memberships (
  user_id uuid references users(id),
  organization_id uuid references organizations(id),
  role text not null check (role in ('owner','admin','member','viewer')),
  primary key (user_id, organization_id)
);

സാധാരണ പ്രൊഫൈൽ അപ്ഡേറ്റിലൂടെ ഉപയോക്താക്കൾ സ്വന്തം റോൾ സജ്ജമാക്കാൻ ഒരിക്കലും അനുവദിക്കരുത്. റോൾ മാറ്റങ്ങൾ അനുമതി പരിശോധിക്കുന്ന ഒരു പ്രത്യേക എൻഡ്പോയിന്റ് വഴി മാത്രം പോകണം.

3. അനുമതികൾ സെർവറിൽ, ഒരിടത്ത് പരിശോധിക്കുക

can(user, 'projects.delete', project) പോലുള്ള ഒരു ഹെൽപ്പർ എഴുതി, ഡേറ്റ വായിക്കുകയോ മാറ്റുകയോ ചെയ്യുന്ന ഓരോ API റൂട്ടിലും, സെർവർ ആക്ഷനിലും, ബാക്ക്ഗ്രൗണ്ട് ടാസ്കിലും വിളിക്കുക. ഒരു കേന്ദ്ര ഫംഗ്ഷൻ കോഡിലുടനീളം ചിതറിയ പരിശോധനകളേക്കാൾ അവലോകനം ചെയ്യാനും ടെസ്റ്റ് ചെയ്യാനും എളുപ്പമാണ്. സ്ഥിരമായി നിഷേധിക്കുക: ഒരു നിയമവും പ്രവർത്തനം അനുവദിക്കുന്നില്ലെങ്കിൽ അത് നിരസിക്കപ്പെടും.

4. ഓരോ ക്വറിയും പരിമിതപ്പെടുത്തുക

ടീം ഡേറ്റയ്ക്കുള്ള ഓരോ ക്വറിയിലും ടീം ഉൾപ്പെടണം: where id = :id മാത്രമല്ല, where organization_id = :currentOrg. /projects/123 എന്നത് /projects/124 ആക്കി മറ്റൊരു കമ്പനിയുടെ പ്രോജക്റ്റ് കാണുന്നത് തടയുന്നത് ഇതാണ്. മറ്റ് ടീമുകളിലെ റെക്കോർഡുകൾക്ക് "forbidden" എന്നതിന് പകരം "not found" നൽകുക, അവ നിലനിൽക്കുന്നു എന്ന് വെളിപ്പെടുത്താതിരിക്കാൻ.

5. പ്രധാനപ്പെട്ടിടത്ത് ഡേറ്റാബേസ് തലത്തിലുള്ള സംരക്ഷണം ചേർക്കുക

Postgres row-level security (RLS) ഏത് വരികൾ ആർക്ക് കാണാമെന്ന് ഡേറ്റാബേസിനെ തന്നെ നടപ്പിലാക്കാൻ അനുവദിക്കുന്നു. ബ്രൗസർ ഡേറ്റാബേസുമായി നേരിട്ട് സംസാരിക്കുമ്പോൾ (ചില ഹോസ്റ്റഡ് ബാക്കെൻഡുകളിലെപ്പോലെ) ഇത് അത്യാവശ്യമാണ്, അല്ലാത്തപക്ഷം സെൻസിറ്റീവ് ടേബിളുകൾക്ക് ഉപയോഗപ്രദമായ രണ്ടാം പാളിയുമാണ്.

6. ഇന്റർഫേസിൽ റോളുകൾ പ്രതിഫലിപ്പിക്കുക

ഇപ്പോൾ ഉപയോക്താക്കൾക്ക് ചെയ്യാൻ കഴിയാത്തത് ഒളിപ്പിക്കുകയോ പ്രവർത്തനരഹിതമാക്കുകയോ ചെയ്യുക, ആപ്പ് ആശയക്കുഴപ്പമില്ലാതെ. ഇത് ഉപയോഗക്ഷമതയ്ക്ക് മാത്രമാണ്; സംരക്ഷിക്കുന്നത് സെർവർ പരിശോധനകളാണ്.

7. സെൻസിറ്റീവ് പ്രവർത്തനങ്ങൾ രേഖപ്പെടുത്തുക

ആര് റോളുകൾ മാറ്റി, ഡേറ്റ ഇല്ലാതാക്കി, അല്ലെങ്കിൽ റെക്കോർഡുകൾ എക്സ്പോർട്ട് ചെയ്തു, എപ്പോൾ എന്നത് രേഖപ്പെടുത്തുക. ഒരു ഓഡിറ്റ് ലോഗ് സപ്പോർട്ട് ചോദ്യങ്ങൾക്കും സംഭവങ്ങൾക്കും സഹായിക്കുന്നു.

8. ഒരു ആക്രമണകാരിയെപ്പോലെ ടെസ്റ്റ് ചെയ്യുക

ഓരോ റോളിലും ലോഗിൻ ചെയ്ത് അനുമതി പട്ടികയിലെ ഓരോ പ്രവർത്തനവും പരീക്ഷിക്കുക. പിന്നെ പ്രവർത്തിക്കാൻ പാടില്ലാത്തവ പരീക്ഷിക്കുക: viewer ആയി admin API റൂട്ടുകൾ വിളിക്കുക, URL-ലും അഭ്യർത്ഥനകളിലും IDകൾ മാറ്റുക, അവസാന ഉടമ എന്ന നിലയിൽ സ്വയം നീക്കം ചെയ്യുക. നിയമങ്ങൾ ഉറച്ചുകഴിഞ്ഞാൽ അനുമതി പട്ടികയ്ക്കായി ഓട്ടോമേറ്റഡ് ടെസ്റ്റുകൾ എഴുതുന്നത് മൂല്യമുള്ളതാണ്.

പ്രവർത്തിക്കുന്ന പ്രോംപ്റ്റുകൾ

റോൾ-അടിസ്ഥാനമാക്കിയ ആക്സസ് കൺട്രോൾ ചേർക്കുക. ഓരോ ഓർഗനൈസേഷനും റോളുകൾ: owner, admin, member, viewer, memberships ടേബിളിൽ സൂക്ഷിക്കുന്നു. അനുമതികൾ ഈ പട്ടികയിലാണ്: [നിങ്ങളുടെ പട്ടിക ഒട്ടിക്കുക]. ഒരു സെർവർ-സൈഡ് can(user, action, resource) ഹെൽപ്പർ ഉണ്ടാക്കുക, സ്ഥിരമായി നിഷേധിച്ച്, ഓരോ API റൂട്ടിലും ഉപയോഗിക്കുക. ഓരോ ക്വറിയും organization_id വഴി പരിമിതപ്പെടുത്തുക. ഉപയോക്താവിന് ചെയ്യാൻ കഴിയാത്ത പ്രവർത്തനങ്ങൾ UI-ൽ ഒളിപ്പിക്കുക, പക്ഷേ സുരക്ഷയ്ക്ക് അതിൽ മാത്രം ആശ്രയിക്കരുത്.

ഈ ആപ്പിലെ എല്ലാ API റൂട്ടും സെർവർ ഫംഗ്ഷനും അവലോകനം ചെയ്യുക. ഓരോന്നിനും ഏത് ഡേറ്റ വായിക്കുന്നു അല്ലെങ്കിൽ മാറ്റുന്നു, ഉപയോക്താവ് ലോഗിൻ ചെയ്തിട്ടുണ്ടോ എന്ന പരിശോധന ഉണ്ടോ, റോൾ പരിശോധിക്കുന്നുണ്ടോ, ക്വറി അവരുടെ organisation-ൽ പരിമിതപ്പെടുത്തുന്നുണ്ടോ എന്നതിന്റെ പട്ടിക തയ്യാറാക്കുക. പരിശോധന കാണാത്തവ ശരിയാക്കി, പട്ടിക എന്നെ കാണിക്കുക.

ഉടമയ്ക്ക് അംഗങ്ങളുടെ റോളുകൾ മാറ്റാൻ കഴിയുന്ന, admin-മാത്രമുള്ള /admin പേജ് ചേർക്കുക. അവസാന ഉടമയെ നീക്കം ചെയ്യുന്നതോ തരംതാഴ്ത്തുന്നതോ തടയുക, ഓരോ റോൾ മാറ്റവും ആര് എപ്പോൾ ചെയ്തു എന്ന് രേഖപ്പെടുത്തുക, ഉടമയല്ലാത്ത ആരെയും റോൾ-മാറ്റ എൻഡ്പോയിന്റ് നിരസിക്കുന്നുവെന്ന് ഉറപ്പാക്കുക.

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

• റോളുകൾ ഫ്രണ്ട് എൻഡിൽ മാത്രം പരിശോധിക്കുന്നത്. API ഇപ്പോഴും ആർക്കും വിളിക്കാവുന്നതാണ്.
• ക്ലയന്റിൽ നിന്നുള്ള IDകളെ വിശ്വസിക്കുന്നത് — സെഷന് പകരം അഭ്യർത്ഥന ബോഡിയിലെ userId അല്ലെങ്കിൽ role.
• പരിമിതപ്പെടുത്താത്ത ക്വറികൾ റെക്കോർഡ് ID മാത്രം വെച്ച് എടുക്കുന്നത്.
• പേജുകളിൽ റോളുകൾ പരിശോധിക്കുന്നു, പക്ഷേ API റൂട്ടുകൾ, എക്സ്പോർട്ടുകൾ, ഫയൽ ഡൗൺലോഡുകൾ അല്ലെങ്കിൽ വെബ്ഹുക്കുകൾ പരിശോധിക്കുന്നില്ല.
• കോഡിൽ ഹാർഡ്-കോഡ് ചെയ്ത ഇമെയിൽ വിലാസം വെച്ചുള്ള അഡ്മിൻ (if email === 'me@...'), ഇത് മറക്കാനും മാറ്റാൻ പ്രയാസമുള്ളതുമാണ്.
• വളരെ നേരത്തെ അധികം റോളുകൾ, ആറ് മാസം കഴിഞ്ഞ് ആർക്കും വിശദീകരിക്കാനാകാത്തത്.
• പഴയ സെഷനുകൾ: തരംതാഴ്ത്തപ്പെട്ട ഉപയോക്താവ് ലോഗ് ഔട്ട് ചെയ്യും വരെ അഡ്മിൻ അവകാശങ്ങൾ നിലനിർത്തുന്നു. സെൻസിറ്റീവ് പ്രവർത്തനങ്ങളിൽ ഡേറ്റാബേസിൽ നിന്ന് റോളുകൾ പരിശോധിക്കുക, അല്ലെങ്കിൽ പുതുക്കുക.

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

• സാധാരണ ഭാഷയിൽ എഴുതിയ അനുമതി പട്ടിക, എഡ്ജ് കേസുകൾ തീരുമാനിച്ചത്
• സെർവർ സെഷനിൽ നിന്ന് ഉപയോക്താവിനെ അറിയുന്നു, ഒരിക്കലും അഭ്യർത്ഥന ഡേറ്റയിൽ നിന്നല്ല
• റോളുകൾ ഡേറ്റാബേസിൽ; ഉപയോക്താക്കൾക്ക് സ്വന്തം റോൾ മാറ്റാൻ കഴിയില്ല
• ഒരു കേന്ദ്ര അനുമതി പരിശോധന, സ്ഥിരമായി നിഷേധിക്കുന്നത്, ഓരോ റൂട്ടിലും ഉപയോഗിച്ചത്
• ഓരോ ക്വറിയും ഉപയോക്താവിന്റെ സംഘടനയോ ഉടമസ്ഥതയോ വഴി പരിമിതപ്പെടുത്തി
• ബ്രൗസർ ഡേറ്റാബേസിൽ എത്താവുന്നിടത്ത് row-level security
• ഉപയോക്താക്കൾക്ക് ചെയ്യാൻ കഴിയാത്തത് UI ഒളിപ്പിക്കുന്നു (ഉപയോഗക്ഷമതയ്ക്ക് മാത്രം)
• സെൻസിറ്റീവ് പ്രവർത്തനങ്ങൾ രേഖപ്പെടുത്തിയിരിക്കുന്നു
• ഓരോ റോളും പരീക്ഷിച്ചു, നേരിട്ടുള്ള API കോളുകളും മാറ്റിയ IDകളും ഉൾപ്പെടെ

ആക്സസ് കൺട്രോൾ ഒരു നീണ്ട പട്ടികയിലെ ഒരു ഇനം മാത്രമാണ്; AI-നിർമിത ആപ്പുകൾക്കുള്ള സുരക്ഷാ ചെക്ക്‌ലിസ്റ്റ് ബാക്കിയുള്ളവ ഉൾക്കൊള്ളുന്നു. നിങ്ങളുടെ സ്റ്റാഫിനായി ഒരു ടൂൾ നിർമിക്കുകയാണെങ്കിൽ, ഒരു ഇന്റേണൽ ടൂൾ എങ്ങനെ നിർമിക്കാം റോളുകൾ എവിടെ ചേരുന്നു എന്ന് കാണിക്കുന്നു.

Mythex-ൽ RBAC

Mythex നിങ്ങളുടെ ആപ്പിന്റെ ഉപയോക്താക്കൾക്കായി അന്തർനിർമിത ലോഗിൻ അല്ലെങ്കിൽ റോൾ സിസ്റ്റം നൽകുന്നില്ല. ഒരു ഓത്ത് ലൈബ്രറിയോ ദാതാവോ തിരഞ്ഞെടുത്ത് റോളുകൾ വിവരിക്കുക; ഏജന്റ് അവ നിങ്ങളുടെ കോഡിലും പ്രോജക്റ്റിന്റെ Postgres ഡേറ്റാബേസിലും ബന്ധിപ്പിക്കുന്നു (നിങ്ങളുടെ ആപ്പിൽ ലോഗിൻ ചേർക്കുക). Mythex-ന്റെ സ്വന്തം വർക്ക്സ്‌പേസ് റോളുകൾ, Owner, Member പോലുള്ളവ, നിങ്ങളുടെ Mythex പ്രോജക്റ്റുകൾ ആർക്ക് എഡിറ്റ് ചെയ്യാമെന്ന് നിയന്ത്രിക്കുന്നു, നിങ്ങൾ പ്രസിദ്ധീകരിക്കുന്ന ആപ്പ് ആർക്ക് ഉപയോഗിക്കാമെന്നല്ല. നിർമിക്കുന്നതിന് മുമ്പ് അനുമതി പട്ടിക അംഗീകരിക്കാൻ Plan mode ഉപയോഗിക്കുക, തുടർന്ന് മുകളിലെ അവലോകന പ്രോംപ്റ്റ് ഉപയോഗിച്ച്, പ്രസിദ്ധീകരിക്കുന്നതിന് മുമ്പ് Preview-ൽ ഓരോ റോളും പരീക്ഷിക്കുക. ഡോക്സിലെ സുരക്ഷാ പ്രോംപ്റ്റുകൾ ഒരു ഉപയോഗപ്രദമായ തുടർപഠനമാണ്.

ചോദ്യങ്ങൾ