Аппдаа үүрэгт суурилсан хандалтын хяналт (RBAC) нэмэх хэрхэн вэ

Үүрэгт суурилсан хандалтын хяналт нэмэхийн тулд хэрэглэгч бүрт нэг буюу хэд хэдэн үүрэг (жишээ нь админ, редактор, үзэгч) өг, үүрэг бүр юу хийж болохыг тодорхойл, хүсэлт бүрийг серверт шалга — зөвхөн товчлуур нуух биш. Мөн хандаж буй бичлэг нь хэрэглэгчийн бүртгэл эсвэл багт харьяалагдаж байгааг шалга. Өгөгдлийн санд эхлээд хэдэн тогтмол үүрэг тавьж, бусдын өгөгдөлд шууд хүрэх оролдлого хийж туршаарай.

Баталгаажуулалт ба эрх олголт

Холилддог хоёр үг:

• Баталгаажуулалт бол чи хэн бэ? — нэвтрэх. Аппдаа нэвтрэлт нэмэх хэрхэн вэ хуудсыг үзнэ үү.
• Эрх олголт бол чи юу хийх эрхтэй вэ? — нэвтэрсэн хэрэглэгч аль хуудас, бичлэг, үйлдэлд хүрч болохыг.

RBAC бол эрх олголтыг хийх хамгийн түгээмэл арга юм. Чухал нь: 2026 оны 9-р сарын байдлаар Broken Access Control нь OWASP Top 10:2025-д 1-р байранд байна — вэб аппын аюулгүй байдлын хамгийн ноцтой эрсдэлүүдийн өргөн хэрэглэгддэг жагсаалт. Түгээмэл алдаа нь хэрэглэгчид URL дахь ID-г солиод бусдын бичлэгийг уншдаг, эсвэл энгийн хэрэглэгчид зөвхөн админд зориулсан 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 маршрут, серверийн action, арын ажил бүрт дууд. Нэг төвлөрсөн функцийг кодонд тарсан шалгалтаас илүү шалгах, туршихад хялбар. Үндсэн утга нь үгүйсгэх: ямар ч дүрэм зөвшөөрөөгүй бол үйлдлийг татгалзана.

4. Асуулга бүрийг хязгаарла

Багийн өгөгдлийн асуулга бүр багийг агуулах ёстой: зөвхөн where id = :id биш, where organization_id = :currentOrg. Энэ нь хэн нэгэн /projects/123-ыг /projects/124 болгож өөр компанийн төслийг харахаас сэргийлнэ. Бусад багийн бичлэгийн хувьд "хориглосон" биш "олдсонгүй" гэж хариулж, тэдгээр бичлэг байгааг илчлэхгүй бай.

5. Өгөгдлийн санд хамгаалалт шаардлагатай газарт нэм

Postgres-ийн мөр түвшний аюулгүй байдал (RLS) нь өгөгдлийн сан өөрөө хэрэглэгч аль мөрийг харж болохыг хэрэгжүүлдэг. Хөтөч өгөгдлийн сантай шууд холбогддог үед (зарим хостлогдсон арын системийн нэгэн адил) үүнд заавал шаардлагатай, бусад тохиолдолд мэдрэмтгий хүснэгтүүдэд хэрэгтэй нэмэлт давхарга болно.

6. Интерфэйст үүргээ тусгах

Одоо хэрэглэгчийн хийж чадахгүй зүйлийг нуу эсвэл идэвхгүй бол, ингэснээр апп эргэлзээтэй харагдахгүй. Энэ нь зөвхөн хэрэглээний тав тухын төлөө; аюулгүй байдлыг серверийн шалгалт хамгаална.

7. Мэдрэмтгий үйлдлийг бүртгэ

Үүрэг солисон, өгөгдөл устгасан эсвэл экспортолсон хүнийг, мөн хэзээ гэдгийг бичиж ав. Аудитын лог нь дэмжлэгийн асуулт болон осол гарсан үед тусалдаг.

8. Халдагч шиг туршаа

Үүрэг бүрээр нэвтэрч, зөвшөөрлийн хүснэгтийн үйлдэл бүрийг туршаарай. Дараа нь ажиллах ёсгүй зүйлсийг туршаарай: үзэгчээр админ API маршрут дуудах, URL болон хүсэлтийн ID-г солих, сүүлийн эзэмшигч өөрийгөө хасах. Дүрмүүд тогтсоны дараа зөвшөөрлийн хүснэгтэд автомат тест бичих нь үнэ цэнэтэй.

Ажилладаг запрууд

Үүрэгт суурилсан хандалтын хяналт нэм. Байгууллага бүрт үүрэг: owner, admin, member, viewer, гишүүнчлэлийн хүснэгтэд хадгалагдсан. Зөвшөөрөл нь энэ хүснэгтэд байна: [хүснэгтээ энд буулгана]. Серверт нэг can(user, action, resource) туслах функц үүсгэ, үндсэндээ татгалз, бүх API маршрутад ашигла. Асуулга бүрийг organization_id-аар хязгаарла. Хэрэглэгчийн хийж чадахгүй үйлдлийг UI дээр нуу, гэхдээ аюулгүй байдлын хувьд хэзээ ч зөвхөн үүнд найдаарай.

Энэ аппын API маршрут болон серверийн функц бүрийг шалга. Тус бүрийн хувьд ямар өгөгдөл уншиж эсвэл өөрчилж байгааг, нэвтэрсэн эсэхээ шалгаж байгааг, үүргээ шалгаж байгааг, асуулгыг байгууллагаар хязгаарлаж байгааг жагсаа. Шалгалт дутуу байгаа аливааг засаад, жагсаалтаа надад үзүүл.

Зөвхөн админд зориулсан /admin хуудас нэм, энд owner гишүүдийн үүргийг солих боломжтой байна. Сүүлийн owner-ийг хасах эсвэл бууруулахыг хориглож, үүрэг солих бүрийг хэн, хэзээ хийснийг бүртгэж, үүрэг солих endpoint нь owner биш хүн бүрийг татгалзаж байгааг баталгаажуул.

Түгээмэл алдаанууд

• Үүргийг зөвхөн фронтэнд шалгах. API нь хэн ч дуудаж болох нээлттэй хэвээр байна.
• Клиентээс ирсэн ID-д итгэх — сессийн оронд хүсэлтийн биед userId эсвэл role байх.
• Хязгаарлаагүй асуулгууд зөвхөн бичлэгийн ID-аар татдаг.
• Хуудсан дээр шалгагдсан, API маршрут, экспорт, файл татах эсвэл webhook дээр шалгагдаагүй үүрэг.
• Имэйл хаягаар админ кодонд хатуу бичигдсэн (if email === 'me@...'), энэ нь мартахад амархан, солихад хэцүү.
• Хэт олон үүрэг хэт эрт, зургаан сарын дараа хэн ч тайлбарлаж чаддаггүй.
• Хуучирсан сессүүд: бууруулсан хэрэглэгч гарах хүртэл админы эрхээ хадгална. Мэдрэмтгий үйлдэл дээр үүргийг өгөгдлийн сангаас шалгах эсвэл шинэчил.

RBAC жагсаалт

• Зөвшөөрлийн хүснэгтийг энгийн хэлээр бичсэн, хүрээний тохиолдлуудыг шийдсэн
• Сервер хэрэглэгчийг сесснээс мэддэг, хүсэлтийн өгөгдлөөс биш
• Үүргийг өгөгдлийн санд хадгалсан; хэрэглэгч өөрийгөө өөрчилж чадахгүй
• Нэг төвлөрсөн зөвшөөрлийн шалгалт, үндсэндээ татгалзсан, бүх маршрутад ашигласан
• Асуулга бүр хэрэглэгчийн байгууллага эсвэл эзэмшилээр хязгаарлагдсан
• Хөтөч өгөгдлийн санд хүрдэг газарт мөр түвшний аюулгүй байдал
• UI нь хэрэглэгчийн хийж чадахгүй зүйлийг нуудаг (зөвхөн хэрэглээний тав тухын төлөө)
• Мэдрэмтгий үйлдлүүд бүртгэгддэг
• Үүрэг бүр туршигдсан, шууд API дуудлага болон солигдсон ID-г оруулаад

Хандалтын хяналт бол урт жагсаалтын нэг хэсэг; AI-ээр бүтээсэн аппын аюулгүй байдлын жагсаалт бусад зүйлийг хамарна. Хэрэв та өөрийн ажилтнуудад зориулсан хэрэгсэл бүтээж байгаа бол дотоод хэрэгсэл хэрхэн бүтээх вэ хуудсанд үүрэг хаана тохирохыг харуулсан.

Mythex дээрх RBAC

Mythex нь таны аппын хэрэглэгчдэд зориулсан нэвтрэлт эсвэл үүргийн систем суулгаж өгдөггүй. Та баталгаажуулалтын сан эсвэл үйлчилгээ сонгож, үүргүүдийг тайлбарлана, агент тэдгээрийг таны кодонд болон төслийн Postgres өгөгдлийн санд холбоно (аппдаа нэвтрэлт нэмэх). Mythex-ийн өөрийн ажлын орчны үүрэг, жишээ нь Owner ба Member, нь таны Mythex төслүүдийг хэн засахыг удирдана, таны нийтэлсэн аппыг хэн ашиглахыг биш. Бүтээхээсээ өмнө зөвшөөрлийн хүснэгтээ тохиролцохын тулд Plan горимыг ашиглаж, дараа нь дээрх шалгах запрыг ашиглан нийтлэхээсээ өмнө Preview дээр үүрэг бүрийг туршаарай. Docs-ийн аюулгүй байдлын запрууд нь үргэлжлэл болгон сайн хэрэглэгдэнэ.

Асуултууд