Қолданбаға рөлге негізделген қолжетімділікті (RBAC) қалай қосуға болады

Рөлге негізделген қолжетімділікті қосу үшін әр пайдаланушыға бір немесе бірнеше рөл беріңіз (мысалы әкімші, редактор, көруші), әр рөлдің қандай әрекеттерді орындай алатынын анықтаңыз және бұл рұқсаттарды әр сұрау үшін серверде тексеріңіз — тек түймелерді жасырмай. Сонымен қатар қол жеткізілетін жазба пайдаланушының аккаунтына немесе командасына тиесілі екенін тексеріңіз. Дерекқорыңызда бірнеше бекітілген рөлден бастаңыз және басқа пайдаланушының деректеріне тікелей қолжеткізуге тырысып сынаңыз.

Аутентификация мен авторизация

Жиі шатастырылатын екі ұғым:

• Аутентификация — сен кімсің? — жүйеге кіру. Қолданбаға логин қалай қосуға болады бөлімін қараңыз.
• Авторизация — сен не істеуге құқығың бар? — жүйеге кірген пайдаланушы қандай беттерге, жазбаларға және әрекеттерге қол жеткізе алатыны.

RBAC — авторизацияны жүзеге асырудың ең кең таралған тәсілі. Бұл маңызды: 2026 жылдың қыркүйегі бойынша Broken Access Control — OWASP Top 10:2025 тізімінде №1, бұл веб-қолданба қауіпсіздігінің ең маңызды қатерлерінің кеңінен қолданылатын тізімі. Әдеттегі қателер — URL-дегі ID-ді өзгертіп басқа пайдаланушының жазбаларын оқу немесе қарапайым пайдаланушылардың тек әкімшіге арналған API маршруттарын шақыруы.

Модельді таңдаңыз

Іс жүзінде көп қолданбалар екі нәрсені біріктіреді: әрекет түріне арналған рөлдер және оларды қай жазбаларға қолдануға болатынына арналған иелік. «Редакторлар постарды өңдей алады» — рөл ережесі; «…өз жұмыс кеңістігіндегі постарды» — иелік ережесі. Екеуі де керек.

Жоспарлағаннан гөрі қарапайымырақ бастаңыз. Әкімші, мүше және көруші көптеген қолданбаға жетеді. Он рөлді түсінбейтін адамдар үшін ажырату қиын; бір рөлді кейін бөлу оңай.

Кодты жазбас бұрын рөлдерді жобалаңыз

Алдымен рұқсаттар кестесін қарапайым тілмен жазыңыз. Ол ЖИ үшін техникалық тапсырма және сынақ жоспары ретінде де қызмет етеді:

Шеткі жағдайларды да шешіңіз: соңғы иесі кете ала ма? Әкімші иесін шығара ала ма? Шығарылған пайдаланушы не көреді?

Қадам-қадаммен

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 id = :id емес, where organization_id = :currentOrg. Бұл адамның /projects/123 URL-ін /projects/124 деп өзгертіп, басқа компанияның жобасын көруін тоқтатады. Басқа командалардың жазбалары үшін «табылмады» жауабын «тыйым салынған» орнына қайтарыңыз, сонда олардың бар екені ашылмайды.

5. Маңызды жерлерде дерекқор деңгейіндегі қорғанысты қосыңыз

Postgres жол деңгейіндегі қауіпсіздік (RLS) дерекқордың әр пайдаланушы қандай жолдарды көре алатынын орындатуына мүмкіндік береді. Браузер дерекқорға тікелей қосылғанда (кейбір хостингтелген backend-терде сияқты) ол маңызды, ал басқа жағдайда құпия кестелер үшін пайдалы екінші қабат.

6. Рөлдерді интерфейсте көрсетіңіз

Енді пайдаланушы орындай алмайтын нәрселерді жасырыңыз немесе өшіріңіз, сонда қолданба түсініксіз болмайды. Бұл тек ыңғайлылық үшін; қорғауды серверлік тексерулер жүзеге асырады.

7. Маңызды әрекеттерді журналға жазыңыз

Рөлдерді кім өзгертті, деректерді кім жойды немесе экспорттады және қашан екенін жазыңыз. Аудит журналы қолдау сұрақтарына және оқиғаларға көмектеседі.

8. Шабуылдаушы сияқты сынаңыз

Әр рөлмен кіріп, рұқсаттар кестесіндегі әр әрекетті сынаңыз. Содан кейін жұмыс істемеуі керек нәрселерді сынаңыз: көруші ретінде әкімші API маршрутын шақырыңыз, URL мен сұраныстардағы ID-лерді өзгертіңіз, соңғы иесі ретінде өзіңізді өшіріңіз. Ереже тұрақтанғанда рұқсаттар кестесіне арналған автоматты тесттер жазу тиімді.

Жұмыс істейтін промпттар

RBAC қосыңыз. Әр ұйым үшін рөлдер: иесі, әкімші, мүше, көруші, мүшелік кестесінде сақталады. Рұқсаттар осы кестеде: [кестеңізді қойыңыз]. Бір серверлік can(user, action, resource) көмекшісін жасаңыз, әдепкі бойынша жабыңыз және оны әр API маршрутында қолданыңыз. Әр сұрауды organization_id бойынша шектеңіз. Пайдаланушы орындай алмайтын әрекеттерді UI-да жасырыңыз, бірақ қауіпсіздік үшін оған ешқашан сенбеңіз.

Осы қолданбадағы әр API маршрутын және серверлік функцияны қараңыз. Әр біреуі үшін оның қандай деректерді оқитынын немесе өзгертетінін, пайдаланушының кірген-кірмегенін, рөлін тексеретінін және сұранысты оның ұйымына шектейтінін тізіп шығыңыз. Тексеруі жоқтарды түзетіңіз және тізімді көрсетіңіз.

Иесі мүшелердің рөлдерін өзгерте алатын тек әкімшілерге арналған /admin бетін қосыңыз. Соңғы иені шығаруға немесе төмендетуге жол бермеңіз, әр рөл өзгерісін кім және қашан жасағанын журналға жазыңыз, ал рөлді өзгерту endpoint-і иесі болмаған кез келген адамды қабылдамасын.

Жиі кездесетін қателер

• Рөлдерді тек фронтендте тексеру. API бәріне ашық болып қала береді.
• Клиенттен келген ID-лерге сену — сессияның орнына сұраныс денесіндегі userId немесе role.
• Шектелмеген сұраулар, жазба ID-і бойынша ғана іздейтін.
• Рөлдер беттерде тексеріледі, бірақ API маршруттарында, экспорттарда, файлды жүктеуде немесе webhook-терде тексерілмейді.
• Email адресі бойынша әкімші, кодта қатты жазылған (if email === 'me@...') — оны ұмыту оңай, өзгерту қиын.
• Тым ерте тым көп рөл, оларды алты айдан кейін ешкім түсіндіре алмайды.
• Ескірген сессиялар: төмендетілген пайдаланушы шығып кеткенше әкімші құқығын сақтайды. Құпия әрекеттерде рөлдерді дерекқордан тексеріңіз немесе жаңартыңыз.

RBAC тексеру тізімі

• Рұқсаттар кестесі қарапайым тілмен жазылған, шеткі жағдайлар шешілген
• Сервер пайдаланушыны сессиядан біледі, сұраныс деректерінен емес
• Рөлдер дерекқорда сақталған; пайдаланушылар өздері өзгерте алмайды
• Бір орталық рұқсат тексеруі, әдепкі бойынша жабық, әр маршрутта қолданылады
• Әр сұрау пайдаланушының ұйымына немесе иелігіне шектелген
• Браузер дерекқорға қол жеткізетін жерлерде жол деңгейіндегі қауіпсіздік бар
• UI пайдаланушы орындай алмайтын нәрселерді жасырады (тек ыңғайлылық үшін)
• Құпия әрекеттер журналға жазылған
• Әр рөл сыналған, оның ішінде тікелей API сұраулары және өзгертілген ID-лер

Қолжетімділікті басқару — ұзын тізімнің бір бөлігі; қалғанын ЖИ арқылы салынған қолданбаларға арналған қауіпсіздік тексеру тізімі қамтиды. Егер компанияңыздың қызметкерлеріне арналған құрал жасасаңыз, ішкі құрал қалай жасалады бөлімінде рөлдердің қайда сәйкес келетіні көрсетілген.

Mythex-тегі RBAC

Mythex қолданбаңыздың пайдаланушылары үшін кірістірілген логин немесе рөлдер жүйесін ұсынбайды. Аутентификация кітапханасын немесе провайдерді таңдап, рөлдерді сипаттайсыз, ал агент оларды кодыңызға және жобаның Postgres дерекқорына енгізеді (қолданбаға логин қосу). Mythex-тің өзіндік жұмыс кеңістігі рөлдері, мысалы Owner және Member, Mythex жобаларыңызды кімнің өңдей алатынын басқарады, ал жарияланған қолданбаны кімнің пайдалана алатынын емес. Құрастыруға дейін рұқсаттар кестесін келісу үшін Plan режимін қолданыңыз, содан кейін жоғарыдағы тексеру промптын пайдаланыңыз және жариялаудан бұрын Preview-де әр рөлді сынаңыз. Құжаттамадағы қауіпсіздік промпттары — жақсы келесі қадам.

Сұрақтар