ሚና ላይ የተመሰረተ መዳረሻ ቁጥጥር (RBAC) ወደ አፕዎ እንዴት ማከል

ሚናዎች ላይ የተመሰረተ መዳረሻ ቁጥጥር ለመጨመር ለእያንዳንዱ ተጠቃሚ አንድ ወይም ብዙ ሚናዎች ይስጡ (ለምሳሌ admin፣ editor፣ viewer)፣ እያንዳንዱ ሚና ምን ድርጊቶች ማድረግ እንደሚችል ይግለጹ፣ እና ፈቃዶቹን ለእያንዳንዱ ጥያቄ በአገልጋዩ ላይ ያረጋግጡ — ቁልፎችን ብቻ በመደበቅ አይደለም። የተደረሰበት መዝገብ የተጠቃሚው መለያ ወይም ቡድን አካል መሆኑንም ያረጋግጡ። በዳታቤዝዎ ውስጥ ጥቂት ቋሚ ሚናዎች ይጀምሩ፣ እና የሌላ ተጠቃሚን ዳታ በቀጥታ ለመድረስ በመሞከር ይፈትሹ።

ማረጋገጥ እና ፈቃድ

ብዙ ጊዜ የሚምታቱ ሁለት ቃላት፦

• ማረጋገጥ (Authentication) ማን ነህ? ነው — መግባት። ወደ አፕዎ መግቢያ እንዴት ማከል ይመልከቱ።
• ፈቃድ (Authorisation) ምን ማድረግ ትችላለህ? ነው — የገባ ተጠቃሚ ምን ገጾችን፣ መዝገቦችንና ድርጊቶችን መድረስ እንደሚችል።

RBAC ፈቃድን ለመስራት በጣም የተለመደው መንገድ ነው። ይህ አስፈላጊ ነው፦ እ.ኤ.አ. በሴፕቴምበር 2026 Broken Access Control በOWASP Top 10:2025 ቁጥር 1 ላይ ነው፣ ይህም በሰፊው የሚጠቀሰው የድር አፕሊኬሽን ከፍተኛ የደህንነት ስጋቶች ዝርዝር ነው። የተለመዱ ውድቀቶች፦ ተጠቃሚዎች በURL ውስጥ ያለውን ID በመቀየር የሌሎችን መዝገብ ማንበብ፣ ወይም ተራ ተጠቃሚዎች ለአድሚን ብቻ የሆኑ የAPI መንገዶችን መጥራት ናቸው።

ሞዴል ይምረጡ

በተግባር አብዛኞቹ አፖች ሁለቱን ያጣምራሉ፦ ሚናዎች ለየትኛው አይነት ድርጊት አንድ ሰው መፈጸም እንደሚችል፣ እና ባለቤትነት በየትኞቹ መዝገቦች ላይ ድርጊቱን መፈጸም እንደሚችል። «አርታኢዎች ልጥፎችን ማረም ይችላሉ» የሚሉ የሚና ህግ ነው፤ «…በራሳቸው የስራ ቦታ ያሉ ልጥፎችን» የባለቤትነት ህግ ነው። ሁለቱም ያስፈልጋሉ።

ከምታስቡት ቀለል አድርጉት። Admin፣ member እና viewer ብዙ አፖችን ይሸፍናሉ። ሚናን በኋላ መከፋፈል ከአንድ ማንም የማይረዳውን አሥር ሚናዎች መፍታት ይቀላል።

ኮድ ከመጻፍዎ በፊት ሚናዎቹን ይንደፉ

መጀመሪያ በቀላል ቋንቋ የፈቃድ ሰንጠረዥ ይጻፉ። ለAI ዝርዝር ሆኖ ያገለግላል፣ እንደ የፈተና እቅድም ይሆናል፦

የጠርዝ ጉዳዮቹንም ይወስኑ፦ የመጨረሻው ባለቤት መልቀቅ ይችላል? አድሚን ባለቤቱን ማስወገድ ይችላል? የተወገደ ተጠቃሚ ምን ያያል?

ደረጃ በደረጃ

1. መሥራት የሚችል መግቢያ መጀመሪያ ይኑርዎት

RBAC በማረጋገጫው ላይ ይቆማል። አገልጋዩ ለእያንዳንዱ ጥያቄ ማን እንደሚልክ በእርግጠኝነት ማወቅ አለበት፣ ከክፍለ-ጊዜ ወይም ከተረጋገጠ ቶክን — ፈጽሞ አሳሹ በጥያቄው አካል ውስጥ ከሚልከው የተጠቃሚ 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)
);

ተጠቃሚዎች በተለመደው የመገለጫ ዝማኔ የራሳቸውን ሚና እንዲያዘጋጁ በፍጹም አይፍቀዱ። የሚና ለውጦች በተለየ፣ በፈቃድ የተፈተሸ endpoint ውስጥ ማለፍ አለባቸው።

3. ፈቃዶችን በአገልጋዩ ላይ በአንድ ቦታ ይፈትሹ

አንድ አጋዥ ተግባር ይጻፉ — ለምሳሌ can(user, 'projects.delete', project) — እና ዳታ የሚያነብ ወይም የሚቀይር በእያንዳንዱ API መንገድ፣ server action እና የጀርባ ስራ ውስጥ ይጥሩት። አንድ ማዕከላዊ ተግባር ከኮዱ ውስጥ በተበታተኑ ፍተሻዎች ይልቅ ለመመርመርና ለመፈተን ይቀላል። በነባሪ ከልክሉ፦ ምንም ህግ ድርጊቱን ካልፈቀደ፣ ውድቅ ይሆናል።

4. ሁሉንም መጠይቆች በወሰን ይገድቡ

ለቡድን ዳታ ያለ ማንኛውም መጠይቅ ቡድኑን ማካተት አለበት፦ where organization_id = :currentOrg፣ where id = :id ብቻ አይደለም። ይህ አንድ ሰው /projects/123 ወደ /projects/124 በመቀየር የሌላ ኩባንያ ፕሮጀክት እንዳያይ ይከለክላል። ለሌሎች ቡድኖች መዝገቦች «ተከልክሏል» ከማለት ይልቅ «አልተገኘም» ይመልሱ፣ ስለዚህ መኖራቸውን እንዳያሳዩ።

5. ቦታ ሲያስፈልግ በዳታቤዝ ደረጃ ጥበቃ ይጨምሩ

Postgres row-level security (RLS) ዳታቤዙ ራሱ የትኞቹን መዝገቦች ማየት እንደሚችል እንዲያስገድድ ያስችለዋል። አሳሹ ከዳታቤዙ ጋር በቀጥታ ሲገናኝ (እንደ አንዳንድ የተስተናገዱ backends) አስፈላጊ ነው፤ ያለበለዚያም ለሚስጥራዊ ሰንጠረዦች ተጨማሪ ንብርብር ነው።

6. ሚናዎችን በበይነገጹ ላይ ያንጸባርቁ

አሁን ተጠቃሚዎች ማድረግ የማይችሉትን ይደብቁ ወይም ያሰናክሉ፣ አፑ ግራ እንዳያጋባ። ይህ ለአጠቃቀም ብቻ ነው፤ የሚጠብቀው የአገልጋዩ ፍተሻ ነው።

7. ስሱ ድርጊቶችን ይመዝግቡ

ሚናዎችን ማን እንደቀየረ፣ ዳታ እንደሰረዘ ወይም መዝገቦችን እንደላከ፣ እና መቼ ይመዝግቡ። የኦዲት መዝገብ ለድጋፍ ጥያቄዎችና ለአደጋዎች ይረዳል።

8. እንደ አጥቂ ይፈትሹ

በእያንዳንዱ ሚና ይግቡ እና በፈቃድ ሰንጠረዡ ውስጥ ያለውን እያንዳንዱን ድርጊት ይሞክሩ። ከዚያ መስራት የሌለባቸውን ነገሮች ይሞክሩ፦ የአድሚን API መንገዶችን እንደ viewer መጥራት፣ በURLና በጥያቄዎች ውስጥ IDs መቀየር፣ የመጨረሻው ባለቤት ሆነው ራስዎን ማስወገድ። ህጎቹ ከተረጋጉ በኋላ ለፈቃድ ሰንጠረዡ አውቶማቲክ ፈተናዎች መጻፍ ተገቢ ነው።

የሚሠሩ ጥያቄዎች

ሚና ላይ የተመሰረተ መዳረሻ ቁጥጥር ጨምር። በድርጅት ሚናዎች፦ owner፣ admin፣ member፣ viewer፣ በmemberships ሰንጠረዥ ውስጥ ይቀመጡ። ፈቃዶቹ በዚህ ሰንጠረዥ ውስጥ ናቸው፦ [የእርስዎን ሰንጠረዥ ለጥፍ]። አንድ የአገልጋይ ጎን can(user, action, resource) አጋዥ ፍጠር፣ በነባሪ ውድቅ አድርግ፣ እና በእያንዳንዱ API መንገድ ተጠቀምበት። እያንዳንዱን መጠይቅ በorganization_id ገድብ። ተጠቃሚው ማድረግ የማይችላቸውን ድርጊቶች በUI ውስጥ ደብቅ፣ ነገር ግን ለደህንነት ፈጽሞ አትተማመንበት።

በዚህ አፕ ውስጥ ያለውን እያንዳንዱን API መንገድ እና የአገልጋይ ተግባር ገምግም። ለእያንዳንዱ ምን ዳታ እንደሚያነብ ወይም እንደሚቀይር፣ ተጠቃሚው መግባቱን እንደሚፈትሽ፣ ሚናውን እንደሚፈትሽ፣ እና መጠይቁን ለድርጅቱ እንደሚገድብ ዘርዝር። ፍተሻ የጎደለውን አስተካክል፣ እና ዝርዝሩን አሳየኝ።

ባለቤቱ የአባላትን ሚናዎች መቀየር የሚችልበት አድሚን-ብቻ /admin ገጽ ጨምር። የመጨረሻውን ባለቤት ከማስወገድ ወይም ከማውረድ ከልክል፣ እያንዳንዱን የሚና ለውጥ ማን እንዳደረገው እና መቼ እንደሆነ ጋር መዝግብ፣ እና የሚና ለውጥ endpoint ባለቤት ያልሆነን ሰው ውድቅ እንደሚያደርግ አረጋግጥ።

የተለመዱ ስህተቶች

• ሚናዎችን በፊት-ገጹ ላይ ብቻ መፈተሽ። API ማንኛውም ሰው በሚጠራው ክፍት ነው።
• ከደንበኛው የሚመጡ IDs ማመን — userId ወይም role በጥያቄው አካል ውስጥ ከክፍለ-ጊዜው ይልቅ።
• ያልተገደቡ መጠይቆች በመዝገብ ID ብቻ የሚያመጡ።
• ሚናዎች በገጾች ላይ የሚፈተሹ ግን በAPI መንገዶች፣ በኤክስፖርቶች፣ በፋይል ማውረዶች ወይም በwebhooks ላይ የማይፈተሹ።
• አድሚን በኢሜል አድራሻ በኮዱ ውስጥ የተጻፈ (if email === 'me@...')፣ ለመርሳት ቀላል እና ለመቀየር ከባድ።
• በጣም ብዙ ሚናዎች ቀድመው፣ ስድስት ወር በኋላ ማንም ሊያብራራው የማይችለው።
• ያረጁ ክፍለ-ጊዜዎች፦ የተወረደ ተጠቃሚ እስኪወጣ ድረስ የአድሚን መብቱን ይይዛል። ሚናዎችን ከዳታቤዙ ይፈትሹ ወይም በስሱ ድርጊቶች ላይ ያድሷቸው።

የRBAC ዝርዝር

• ፈቃድ ሰንጠረዥ በቀላል ቋንቋ ተጽፏል፣ የጠርዝ ጉዳዮች ተወስነዋል
• አገልጋዩ ተጠቃሚውን ከክፍለ-ጊዜው ያውቃል፣ ፈጽሞ ከጥያቄ ዳታ አይደለም
• ሚናዎች በዳታቤዝ ውስጥ ተቀምጠዋል፤ ተጠቃሚዎች የራሳቸውን መቀየር አይችሉም
• አንድ ማዕከላዊ የፈቃድ ፍተሻ፣ በነባሪ ውድቅ፣ በእያንዳንዱ መንገድ ላይ ጥቅም ላይ ውሏል
• እያንዳንዱ መጠይቅ ለተጠቃሚው ድርጅት ወይም ባለቤትነት ተገድቧል
• አሳሹ ዳታቤዙን በቀጥታ በሚደርስበት ቦታ row-level security አለ
• UI ተጠቃሚዎች የማይችሉትን ይደብቃል (ለአጠቃቀም ብቻ)
• ስሱ ድርጊቶች ተመዝግበዋል
• እያንዳንዱ ሚና ተፈትኗል፣ ቀጥታ API ጥሪዎችና የተቀየሩ IDs ጨምሮ

የመዳረሻ ቁጥጥር በረዥም ዝርዝር ውስጥ አንዱ ነገር ነው፤ ለAI የተገነቡ አፖች የደህንነት ዝርዝር የቀረውን ይሸፍናል። ለራስዎ ሰራተኞች መሣሪያ እየገነቡ ከሆነ፣ የውስጥ መሣሪያ እንዴት መገንባት ሚናዎች የት እንደሚገቡ ያሳያል።

በMythex ላይ RBAC

Mythex ለአፕዎ ተጠቃሚዎች አብሮ የተሰራ መግቢያ ወይም የሚና ስርዓት አይሰጥም። የማረጋገጫ ቤተ-መጽሐፍት ወይም አቅራቢ ይመርጣሉ እና ሚናዎቹን ይገልጻሉ፤ ወኪሉ በኮድዎና በፕሮጀክትዎ Postgres ዳታቤዝ ውስጥ ያገናኘዋል (ወደ አፕዎ መግቢያ ጨምር)። የMythex የራሱ የስራ ቦታ ሚናዎች፣ እንደ Owner እና Member፣ የMythex ፕሮጀክቶችዎን ማን ማረም እንደሚችል ይቆጣጠራሉ፣ ያተሙትን አፕ ማን መጠቀም እንደሚችል አይደለም። ከመገንባትዎ በፊት የፈቃድ ሰንጠረዡን ለመስማማት Plan mode ይጠቀሙ፣ ከዚያ ከላይ ያለውን የግምገማ ጥያቄ ይጠቀሙ እና ከማተምዎ በፊት እያንዳንዱን ሚና በPreview ይሞክሩ። የሰነዱ የደህንነት ጥያቄዎች ጥሩ ተከታይ ናቸው።

ጥያቄዎች