Ինչպես ավելացնել դերերի վրա հիմնված մուտքի կառավարում (RBAC) ձեր հավելվածին

Դերերի վրա հիմնված մուտքի կառավարում ավելացնելու համար յուրաքանչյուր օգտատիրոջը տվեք մեկ կամ մի քանի դեր (օրինակ՝ ադմին, խմբագիր, դիտող), սահմանեք, թե յուրաքանչյուր դեր ինչ գործողություններ կարող է կատարել, և ստուգեք այդ թույլտվությունները սերվերում յուրաքանչյուր հարցման համար, ոչ միայն կոճակները թաքցնելով։ Նաև ստուգեք, որ մուտքի ենթարկվող գրառումը պատկանում է օգտատիրոջ հաշվին կամ թիմին։ Սկսեք մի քանի ֆիքսված դերերից ձեր տվյալների բազայում և փորձարկեք՝ փորձելով ուղղակիորեն հասնել մեկ այլ օգտատիրոջ տվյալներին։

Նույնականացում և թույլտվություն

Երկու բառ, որ շփոթվում են․

• Նույնականացում — ով ես դու՞։ Մուտք գործելը։ Տես ինչպես ավելացնել մուտք ձեր հավելված։
• Թույլտվություն — ինչ իրավունք ունես անելու՞։ Թե որ էջերին, գրառումներին և գործողություններին կարող է հասնել մուտք գործած օգտատերը։

RBAC-ը թույլտվության ամենատարածված եղանակն է։ Կարևոր է․ 2026 թվականի սեպտեմբերի դրությամբ Broken Access Control-ը OWASP Top 10:2025-ում առաջինն է՝ լայնորեն օգտագործվող ցանկը ամենալուրջ վեբ հավելվածների անվտանգության ռիսկերի։ Տիպիկ ձախողումներն են՝ օգտատերերը կարդում են ուրիշների գրառումները՝ փոխելով ID-ն URL-ում, կամ սովորական օգտատերերը կանչում են միայն ադմինի API երթուղիները։

Ընտրեք մոդել

Պրակտիկայում շատ հավելվածներ համադրում են երկու բան․ դերեր այն մասին, թե ինչ տեսակի գործողություններ կարող է անել մարդը, և սեփականություն այն մասին, թե որ գրառումների վրա կարող է դրանք կատարել։ «Խմբագիրները կարող են խմբագրել գրառումները» դերի կանոն է․ «…իրենց աշխատանքային տարածքի գրառումները» սեփականության կանոն է։ Ձեզ պետք են երկուսն էլ։

Սկսեք ավելի պարզ, քան կարծում եք։ Ադմին, անդամ և դիտող դերերը ծածկում են զարմանալիորեն շատ հավելվածներ։ Ավելի հեշտ է դերը ավելի սկզբում բաժանել, քան տասը դեր քանդել, որոնք ոչ ոք չի հասկանում։

Նախ նկարագրեք դերերը, նոր գրեք կոդը

Նախ գրեք թույլտվությունների աղյուսակը պարզ լեզվով։ Այն միաժամանակ ծառայում է որպես 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 երթուղում, սերվերային գործողությունում և ֆոնային աշխատանքում, որ կարդում կամ փոխում է տվյալները։ Մեկ կենտրոնական ֆունկցիան ավելի հեշտ է վերանայել և փորձարկել, քան ստուգումները ցրված կոդում։ Մերժեք լռելյայն․ եթե ոչ մի կանոն թույլ չի տալիս գործողությունը, այն մերժվում է։

4. Սահմանափակեք յուրաքանչյուր հարցում

Թիմի տվյալների յուրաքանչյուր հարցում պետք է ներառի թիմը՝ where organization_id = :currentOrg, ոչ թե միայն where id = :id։ Սա կանգնեցնում է մարդուն /projects/123-ից /projects/124 փոխելուց և մեկ այլ ընկերության նախագիծը տեսնելուց։ Այլ թիմերի գրառումների համար վերադարձրեք «չի գտնվել», այլ ոչ թե «արգելված», որ չբացահայտեք, որ դրանք գոյություն ունեն։

5. Ավելացրեք տվյալների բազայի պաշտպանություն այնտեղ, որտեղ այն կարևոր է

Postgres row-level security (RLS)-ը թույլ է տալիս տվյալների բազային ինքը կիրառել, թե որ տողերը կարող է տեսնել յուրաքանչյուր օգտատեր։ Դա էական է, եթե բրաուզերը ուղղակիորեն խոսում է տվյալների բազայի հետ (ինչպես որոշ հոստված backend-ներում), և օգտակար երկրորդ շերտ է զգայուն աղյուսակների համար, հակառակ դեպքում։

6. Արտացոլեք դերերը ինտերֆեյսում

Այժմ թաքցրեք կամ անջատեք այն, ինչ օգտատերերը չեն կարող անել, որ հավելվածը շփոթեցնող չլինի։ Սա միայն օգտագործման համար է․ պաշտպանում են սերվերի ստուգումները։

7. Գրանցեք զգայուն գործողությունները

Մատյանում գրանցեք, թե ով է փոխել դերերը, ջնջել տվյալներ կամ արտահանել գրառումներ և երբ։ Աուդիտի մատյանը օգնում է աջակցության հարցերի և միջադեպերի դեպքում։

8. Փորձարկեք ինչպես հարձակվող

Մուտք գործեք որպես յուրաքանչյուր դեր և փորձեք թույլտվությունների աղյուսակի յուրաքանչյուր գործողություն։ Ապա փորձեք այն, ինչ չպետք է աշխատի․ կանչեք ադմինի API երթուղիները որպես դիտող, փոխեք ID-ները URL-ներում և հարցումներում, հեռացրեք ինքներդ ձեզ որպես վերջին սեփականատեր։ Թույլտվությունների աղյուսակի համար ավտոմատ թեստեր գրելը արժե, երբ կանոնները կայունանան։

Հրամաններ, որ աշխատում են

Ավելացրու դերերի վրա հիմնված մուտքի կառավարում։ Դերեր յուրաքանչյուր կազմակերպության համար՝ owner, admin, member, viewer, պահված memberships աղյուսակում։ Թույլտվությունները այս աղյուսակում են՝ [տեղադրեք ձեր աղյուսակը]։ Ստեղծիր մեկ սերվերային can(user, action, resource) օգնական, մերժիր լռելյայն և օգտագործիր յուրաքանչյուր API երթուղում։ Սահմանափակիր յուրաքանչյուր հարցում organization_id-ով։ Թաքցրու UI-ում այն գործողությունները, որ օգտատերը չի կարող կատարել, բայց երբեք մի հիմնվիր դրա վրա անվտանգության համար։

Վերանայիր այս հավելվածի յուրաքանչյուր API երթուղի և սերվերային ֆունկցիա։ Յուրաքանչյուրի համար ցույց տուր, թե ինչ տվյալներ է կարդում կամ փոխում, արդյոք ստուգում է, որ օգտատերը մուտք է գործել, արդյոք ստուգում է նրա դերը, և արդյոք սահմանափակում է հարցումը նրա կազմակերպությամբ։ Շտկիր այն ստուգումները, որ բացակայում են, և ցույց տուր ցուցակը։

Ավելացրու միայն ադմինների /admin էջ, որտեղ սեփականատերը կարող է փոխել անդամների դերերը։ Արգելիր վերջին սեփականատիրոջը հեռացնելը կամ նվազեցնելը, մատյանում գրանցիր յուրաքանչյուր դերի փոփոխություն՝ ով և երբ է արել, և համոզվիր, որ դերերի փոփոխման endpoint-ը մերժում է ցանկացած մեկին, ով սեփականատեր չէ։

Հաճախակի սխալներ

• Դերերի ստուգում միայն ֆրոնտենդում։ API-ն դեռ բաց է ցանկացած մեկի համար, ով այն կանչում է։
• Վստահել հաճախորդից եկած ID-ներին՝ userId կամ role հարցման մարմնում, սեսիայի փոխարեն։
• Չսահմանափակված հարցումներ, որ բերում են գրառում միայն ID-ով։
• Դերերը ստուգվում են էջերի վրա, բայց ոչ API երթուղիներում, արտահանումներում, ֆայլերի ներբեռնումներում կամ webhook-ներում։
• Ադմին՝ էլ. փոստի հասցեով, կոշտ կոդավորված կոդում (if email === 'me@...'), որ հեշտ է մոռանալ և դժվար է փոխել։
• Չափազանց շատ դեր շատ շուտ, որ վեց ամիս հետո ոչ ոք չի կարող բացատրել։
• Հնացած սեսիաներ․ իջեցված օգտատերը պահում է ադմինի իրավունքները մինչև դուրս գալը։ Զգայուն գործողությունների ժամանակ ստուգեք դերերը տվյալների բազայից կամ թարմացրեք դրանք։

RBAC ստուգացանկ

• Թույլտվությունների աղյուսակը գրված է պարզ լեզվով, եզրային դեպքերը որոշված են
• Սերվերը իմանում է օգտատիրոջը սեսիայից, երբեք հարցման տվյալներից
• Դերերը պահված են տվյալների բազայում․ օգտատերերը չեն կարող փոխել իրենցը
• Մեկ կենտրոնական թույլտվության ստուգում, մերժում լռելյայն, օգտագործվում է յուրաքանչյուր երթուղում
• Յուրաքանչյուր հարցում սահմանափակված է օգտատիրոջ կազմակերպությամբ կամ սեփականությամբ
• Row-level security այնտեղ, որտեղ բրաուզերը կարող է հասնել տվյալների բազային
• UI-ն թաքցնում է այն, ինչ օգտատերերը չեն կարող անել (միայն օգտագործման համար)
• Զգայուն գործողությունները գրանցված են
• Յուրաքանչյուր դեր փորձարկված է, ներառյալ ուղղակի API կանչերը և փոխված ID-ները

Մուտքի կառավարումը ընդամենը մեկ կետ է ավելի երկար ցանկում․ AI-ով կառուցված հավելվածների անվտանգության ստուգացանկը ծածկում է մնացածը։ Եթե կառուցում եք գործիք ձեր աշխատակիցների համար, ինչպես կառուցել ներքին գործիք ցույց է տալիս, թե որտեղ են դերերը տեղավորվում։

RBAC Mythex-ում

Mythex-ը ձեր հավելվածի օգտատերերի համար ներկառուցված մուտք կամ դերերի համակարգ չի տրամադրում։ Դուք ընտրում եք նույնականացման գրադարան կամ մատակարար և նկարագրում դերերը, իսկ գործակալը դրանք միացնում է ձեր կոդին և նախագծի Postgres տվյալների բազային (ավելացնել մուտք ձեր հավելվածին)։ Mythex-ի սեփական աշխատանքային տարածքի դերերը, ինչպիսիք են Owner և Member, վերահսկում են, թե ով կարող է խմբագրել ձեր Mythex նախագծերը, ոչ թե ով կարող է օգտագործել ձեր հրապարակված հավելվածը։ Օգտագործեք Plan mode՝ թույլտվությունների աղյուսակը նախապես համաձայնեցնելու համար, ապա օգտագործեք վերևի վերանայման հրամանը և փորձարկեք յուրաքանչյուր դեր Preview-ում, նախքան հրապարակելը։ Փաստաթղթերի անվտանգության հրամանները օգտակար հետագա քայլ են։

Հարցեր