Хэрэглэгчийн зөвшөөрөл (Authorization)-г RBAC аргаар зохиомжлох нь
Нийтэлсэн:
Програм хангамжийн инженер Б.Ариунсанаа
Сайн уу? 👋 Энэхүү блог маань 2 үндсэн хэсгээс бүрдэх бөгөөд эхний хэсгээрээ бид дижитал системд түгээмэл хөгжүүлэгддэг authentication буюу хэрэглэгчдийн бүртгэл👪, authorization буюу хэрэглэгчдийн зөвшөөрөл ⚠️ гэж юу болох, тэдгээрийн ялгааг товч тайлбарласан. Харин дараах хэсгээс бидний authorization-г хэрэгжүүлэх аргууд дундаас RBAC аргыг сонгон авч өөрсдийн жишээ системийг хөгжүүлэх замаар эхнээс нь өгөгдлийн санг зохиомжилж буйг унших 📖 боломжтой. Уншигч та бүхэнд ойлгомжтой байлгахын тулд элдэв гүнзгий зүйл ярих бус харин хамгийн ерөнхий байдлаар жишээнүүдийг авч, зохиомжилсон гэдгийг анхаараарай. За эхэлцгээх үү? 💪
/Зарим Англи нэршлийг Монголоор орчуулалгүй бичсэн болно/
Ямар ч IT инженер, веб хөгжүүлэгч бүхэн өөрийн аугаа их хөгжүүлэлтийн замналдаа хэрэглэгчийн бүртгэл (authentication), зөвшөөрөл (authorization) гэх зүйлтэй учирдаг нь тавилан билээ🫡. Authentication болон authorization гэх үгнүүд нь хоёул хэрэглэгчтэй холбоотой боловч хоорондоо ялгаатай агуулга буй. Хэрэв та дээрх хоёрын ялгааг сайн мэдэхгүй бол доорх хэсгийг уншаарай. 👇
Authentication болон Authorization хоёрын ялгаа: 🧐
Товчоор тайлбарлавал authentication нь таны систем дэх бүх хэрэглэгчдийн бүртгэл буюу аливаа хэрэглэгчийг систем рүү тань бүртгэж, тухайн бүртгүүлсэн хаягаараа “Login” 💻 хийж нэвтрэх боломжийг олгодог гэж ойлгоход болно. Мэдээж authentication-г хэрэгжүүлэх олон аргууд бий ч бидний ярилцах гол агуулга энэ биш учраас гүн тайлбарлахгүйгээр энэ хүргээд орхиё.👌
Тэгвэл authorization гэдэг нь таны системийн хэрэглэгчдийг юу хийж чадах, юу хийж чадахгүй вэ? Гэдгийг тодорхойлж, хязгаарлаж өгдөг зүйл юм. Аливаа системд админ хэрэглэгч байна аа гэдэг нь тэнд тодорхой хэмжээнд authorization хэрэгжүүлсэн байна аа 🤔 л гэсэн үг. Админ гэдэг нь нэг ёсондоо тухайн хэрэглэгчийг бусдаас илүү давуу үйлдлүүд хийх эрхтэй хэрэглэгч гэж ялгаж өгч буй хэрэглэгчийн төрөл бөгөөд хөгжүүлэгч нар үүнийг ихэвчлэн “Role” гэж нэрлэж заншжээ. Мэдээж аливаа системд олон төрлийн хэрэглэгчийн role байж болох ба бүртгэлтэй хэрэглэгч нар бүгд өөр өөрсдийн гэсэн тохирох role-той байж болно. 👪
Одоо бүгдээрээ жишээ аван ярилцацгаая. Та өөрийгөө их сургуулийн цахим сургалтын системд authorization-г хэрэгжүүлэх гэж байна хэмээн төсөөлөөрэй 💭. Систем оюутнуудын дүнг бүртгэж харуулдаг, багш нь хичээл, даалгавруудаа оруулж оюутнууддаа илгээж буцааж дүгнэдэг гэх мэт үйлдлүүдтэй.
За, түр байж байгаарай🤚 нэг хөгжилтэй зүйл гялс энд дурдъя 😄. Бидний ихэнх маань 10 жилдээ сурч байхад “Хэрэв болдог бол багшийн дүнгийн дэвтэр дээрх өөрийнхөө бүх дүнг нууцаар “A” болгох юм сан.” гэж ядаж 1 удаа нууцхан хүсэж байсан байх. Эргээд санахад тэр хүсэл маань том болж оюутан🧑🎓 болоход арай өөрчлөгдөөд “За байз, энэ оюутны веб дээр бүртгэгдсэн бүх дүнгээ “A” болгочихвол гоё доо!” гэж хувирсан байж.
Тэгэхээр дээрх түүхээс нэг зүйлийг ажиглая 🧐. Оюутан бүр сургалтын систем рүүгээ нэвтэрч ороод өөрийн дүнгээ хүссэнээрээ солиод байж болохгүй ❌ бас багшийнхаа оруулсан даалгаврыг хийгээд илгээсэн мэт өөрчлөөд дүнгээ тооцуулж ч болохгүй ❌. Тиймээс оюутан гэдэг төрөлд хамаарах хэрэглэгчдийг дээрх зохисгүй үйлдлийг хийлгэхгүй байхын тулд бид зайлшгүй эрхийн хязгаарлалт оноож өгч системд хийх үйлдлүүдийг нь хязгаарлаж, гүйцэтгэхийг нь хорьдог байх хэрэгтэй 👌. Харин багш гэдэг төрлийн хэрэглэгч нарт дээрх эрхүүдийг нээж өгснөөр оюутнуудын дүнг бүртгэх, даалгавар нэмж, хасах гэх мэт үйлдлүүдээ хийж чадах юм. Нэмэлтээр системд оролцох хэрэглэгчдийг энэ бол оюутан юм шүү, энэ бол багш юм шүү гэдгийг ялгаж тохируулж өгдөг админ 🦹 хэрэглэгч байж болно.
Үүнээс харвал системд багш, оюутан мөн админ гэсэн 3 хэрэглэгч байна. Тэгвэл мэдээж хэрэглэгч бүрд тохирсон дараах role-үүд байж болно. Үүнд:
- Админ - admin 🦹
- Багш - teacher 🧑🏫
- Оюутан - student 🧑🎓
Бид role-үүдээ тодорхойлчихлоо. Одоо системд хэрэглэгч бүртгэх бүрд дээрх role-үүдээс тохирохыг нь оноож role тус бүрийн хийж чадах, хийж чадахгүй үйлдлүүдийг системдээ хязгаарлаж өгөх юм. 🔥
Баяр хүргэе, Та authentication болон authorization хоёрын гол ялгааг бага ч ойлгодог боллоо. Let’s move on!
ROLE-BASED ACCESS CONTROL (RBAC)
Authorization-г хэрэгжүүлэх нийтлэг аргууд олон бий. Үүнд Role-Based Access Control (RBAC), Attribute-Based Access Control (ABAC) болон Policy-Based Access Control (PBAC) орно. Эдгээр аргуудын үндсэн зорилго төстэй боловч хэрэгжүүлж буй байдлаараа ялгарах буй. Тэгвэл RBAC аргыг голчлон сонгож тайлбарлая. 📃
Блогийн эхэн хэсэгт дурдсан authentication болон authorization хоёрын ялгаа дээрх “Их сургуулийн сургалтын систем”-ийн жишээ бол RBAC юм. Системд хэд хэдэн төрлийн role-үүд байх бөгөөд системд хийж болох үйлдлүүд, функцүүдийг тухайн role-үүдэд хязгаарлах буюу нөгөө талаас нь харвал тухайн үйлдлүүдийг холбож өгнө (шууд утгаараа өгөгдлийн сан дээр холбож өгөхийг хэлж байгаа) мэдээж хийх ямар үйлдлүүд холбогдсон гэдгээсээ хамаарч тухайн role нь зарим талаараа давуу эрхтэй эсвэл хязгаарлагдмал эрхтэй болно. Дараа нь системд бүртгэлтэй хэрэглэгч нар өөрт харьяалагдах тохирсон role-той холбогдоно. RBAC-д байх гол зүйлс: 👇
- Permissions - Тухайн системийн хэрэглэгч нарын гүйцэтгэж болох үйлдлүүд буюу эрхүүд. Жишээ нь харах, засах, устгах гэх мэт.
- Roles - Тухайн системд буй хэрэглэгчийн төрлүүд. Дээр дурдсан үйлдлүүдийг аливаа role-үүдэд ялгаатай байдлаар холбож өгснөөр хэрэглэгчийн төрлүүдийг хүссэнээрээ тэлэх боломжийг олгоно. Жишээ нь менежер, санхүүч, багш, оюутан гэх мэт.
- Users - Системд бүртгэлтэй хэрэглэгч нар. Аливаа хэрэглэгч нэг болон түүнээс олон role-үүдтэй зэрэг холбогдсон байж болно. Жишээ нь та багш болон админ гэсэн 2 role-тэй бол энэ хоёр role-д холбогдсон бүх permission-үүд буюу үйлдлүүдийг та хийх эрхтэй гэсэн үг.
RBAC аргын давуу тал
Мэдээж аливаа системийн нэгэн чухал зүйл бол maintanence юм. Хэрэглэгчийн role-г солих, засах, permission нэмж хасах гэх мэт үйлдлүүдийг хийхийн тулд та тухайн хэрэглэгчид холбогдсон role-г эсвэл role-д холбогдсон permission-үүдийн холболтыг өөрчлөхөд л хангалттай юм. 💪
Бусад аргуудтай танилцах бол эндээс уншаарай.
Authorization-г RBAC аргаар зохиомжилъё
За, дээр дурдсан их сургуулийн сургалтын системийн жишээг үргэлжлүүлэн илүү дэлгэрэнгүй авч үзье 🔍. Системд маань админ, багш, оюутан гэсэн 3 төрлийн хэрэглэгч байх бөгөөд оюутан нь хичээлүүдээ харж, татаж чаддаг, мөн өөрийн дүнгээ харж чаддаг 👁️ бол багш нь оюутны хийх бүх үйлдлийг хийж чадахын зэрэгцээ хичээл, дүнгүүдийг нэмэх, засах, устгах гэх мэтээр бүрэн удирдаж чадна 💪. Харин админ бол багш, сурагч хоёрын бүх үйлдлийг хийж чадахын зэрэгцээ системд хэрэглэгчдийг нэмж, хасаж гэх мэт системийг бүрэн удирдаж чадна 🦹 гэж үзье.
Тэгвэл одоо технологи уруу гүн оролгүйгээр өгөгдлийн сангийн бүтцээ Prisma Schema ашиглан ерөнхийлөн зохиомжилъё. Prisma суулгаж ажиллуулах талаар эндээс уншаарай. 📖
Юуны өмнө бидний жишээнд 3 enum тодорхойлогдсон байх хэрэгтэй.
enum PositionType { admin teacher student}
PositionType нь систем дахь хэрэглэгч нарын төрлүүдийн нэрс (Role Name) юм. Бидэнд хэрэгтэй байгаа role-үүд буюу admin, teacher, student гэсэн 3 хэрэглэгчийн төрлүүдийг оруулав.
enum ActionType { create read update delete download}
ActionType нь систем дахь хэрэглэгч нарын гүйцэтгэж болох нийт үйлдлүүд юм. Жишээ байдлаар CRUD + Download гэх мэт үйлдлүүдийг оруулав.
enum ResourceType { user lesson grade}
ResourceType нь систем дахь объектууд юм. Бидний жишээнд хэрэглэгч, хичээл, дүн гэсэн объектууд байж болно.
Одоо бид дээрх enum-уудыг ашиглан RBAC-г зохиомжлох table-үүдийг тодорхойлж өгнө.
Permission table
model Permission { id Int @id @default(autoincrement()) resource ResourceType action ActionType @@unique([resource, action])}
Permission table бол ямар resource дээр ямар action хийж болох вэ? (Many to Many) Гэдгийг холбосон мөрүүд хадгалах зорилготой юм. Жишээг доор харуулав. 👇 Хэрэглэгчтэй холбоотой хийгдэх үйлдлүүд:
Бид permission-үүдийг ашиглахдаа тэдний id-гаар нь холбож ашиглах болно. Хичээлтэй холбоотой хийгдэх үйлдлүүд:
Оюутны дүнтэй холбоотой хийгдэх үйлдлүүд:
Role Table
model Role { id Int @id @default(autoincrement()) position PositionType}Role table бол системд байж болох хэрэглэгч нарын төрлүүдийг хадгалах зорилготой. Бидний өмнө тодорхойлсон ResourceType дахь утгуудын дагуу role-үүд үүснэ. Жишээг доор харуулав. 👇
Эдгээр Role-үүд өөрсдийн id-гаар дараа нь ашиглагдах тул id-нуудыг нь сайн цээжлээд аваарай. 📝
RolePermission Table
model RolePermission { id Int @id @default(autoincrement()) role Role @relation(fields: [roleId], references: [id]) roleId Int permission Permission @relation(fields: [permissionId], references: [id]) permissionId Int @@unique([roleId, permissionId])}
Бидэнд одоогоор Permission table-д хичээл нэмэх, хичээл устгах, дүн нэмэх гэх мэт permission-үүд байна. Мөн Role table-д багш гэсэн role байна. Тэгвэл “Багш” role-той хэрэглэгч ийм ийм үйлдлүүдийг хийж чадна аа гэдгийг хэрхэн холбож хадгалах вэ? RolePermission table үүнийг биелүүлэх зорилготой юм. Шууд жишээг харцгаая.
3 гэсэн id-тай Role ямар Role гэдгийг санаж байгаа биз? Энэ бол Student гэсэн Role бөгөөд permission баганад харин 3, 4, 8 гэсэн permission-үүд холбогджээ. Тус бүрийг доор дахин сануулъя.
Permissions:
- 3: Lesson - Read
- 4: Lesson - Download
- 8: Grade - Read
Үүнээс харвал Student гэдэг Role-тэй хэрэглэгч дээрх 3 үйлдлийг гүйцэтгэж чадна буюу эдгээр эрхүүдтэй гэсэн үг. 🔥
Харин Teacher болон Admin Role-үүдийн RolePermission table-н мөрүүдийг харцгаая.
Админ хэрэглэгч бол бүх үйлдлүүдийг хийж чадахаар холбогдсон байгааг харж байна.
Харин Teacher role бол 1 болон 2 гэсэн id-тай permission-ээс бусад бүх permission-үүдтэй холбогдсон байгааг харж байна.
Зөвхөн админ хийж чадах үйлдлүүд: 🦹
- 1: User - Create
- 2: User - Delete
User Table
model User { id String @id email String @unique name String}User table-д хэрэглэгчдээ бүртгэнэ. Жишээг шууд харчихъя доо. 👇
Бидэнд одоогоор user1, user2 гэсэн id-тай хэрэглэгчид байна. Дараагийн алхам бол эдгээр хэрэглэгч тус бүрд role-үүдийг холбох юм. Хэрхэн холбохыг та аль хэдийн бодоод олчихсон байх. Yes! Бидэнд дахин нэг table хэрэг болох нь ээ.
UserRole Table
model UserRole { id Int @id @default(autoincrement()) user User @relation(fields: [userId], references: [id]) userId String role Role @relation(fields: [roleId], references: [id]) roleId Int @@unique([userId, roleId])}
User1 id-тай хэрэглэгчийг багш гэж үзье. Тэгвэл бид холбогдох Role буюу 2 гэсэн id-тай Teacher role-г тухайн user1 id-тай хамт холбон 1 мөр нэмэхэд л хангалттай. Гэх мэтчилэн бүх хэрэглэгч нараа тохирох Role-үүдтэй нь холбож өгнө. Жишээг доор харуулав.
Мэдээж нэг хэрэглэгч нэг болон түүнээс дээш role-тэй байж болно. Жишээ нь user1 id-тай багш маань ирээдүйд албан тушаал ахиж багшлахын хажуугаар сургалт хариуцсан менежер боллоо гэж төсөөлье 💭. Сургалт хариуцсан менежерүүд системд admin role-тэй байх ёстой. Тэгвэл бид teacher role дээрээ нэмээд admin role-той болгох шаардлага үүснэ. Үүнийг хэрхэн хийх вэ? RBAC арга энэ мэт maintenence хийх, засах гэх мэт өөрчлөлтүүдийг маш хялбар 🔥 хийх боломжийг олгодгоороо давуу талтай. Та зөвхөн UserRole table-д доор улаан хүрээгээр тэмдэглэсэн мөрийг нэмэхэд л хангалттай.
Ингээд user1 id-тай хэрэглэгч маань Teacher болон Admin role-үүдийн хийж чадах бүх үйлдлийг хийх эрхтэй боллоо. 🧑🏫 + 🦹 = 😎
Tip: Хэрэв та анзаарсан бол admin role маань өөрөө teacher role-ийн хийх бүх үйлдлийг хийх эрхтэй билээ. Тиймээс бид user1 id-тай хэрэглэгчид зөвхөн admin role-г дангаар нь холбосон ч ижил үр дүнд хүрэх юм. Тиймээс бид RBAC аргаар authorization-г хэрэгжүүлэх бол системдээ ямар permission-үүд байх уу? Ямар role-үүд байх уу? Дараа нь засаж өөрчлөхөд хялбар засагдахаар байна уу? Гэх мэт зүйлсээ сайн бодож төлөвлөсөн байх хэрэгтэйг анхаараарай.
Өгөгдлийн Ерөнхий Схем (ERD)
Дээр үүсгэсэн table-үүдийг нэгтгэн ERD-г харууллаа. User, Role, Permission гээд RBAC аргын үндсэн table-үүд байх бөгөөд UserRole болон RolePermission table-үүд тэдгээрийн холбоосуудыг (many to many) хадгалах бөгөөд junction table ашиглан шийдсэн.
Мэдээж бүх систем authentication, authorization-г хэрэгжүүлсэн байх шаардлагагүй байдаг. Таны системийн хэрэгцээ шаардлага тань үнэхээр хэрэглэгчдээ бүртгэж таних хэрэгтэй, хэрэглэгчдээ ангилж хийх үйлдлүүдээр нь хязгаарлаж, ялгаж өгөх хэрэгтэй байвал дээрх хоёр хэсгийг зайлшгүй системдээ оруулж өгнө. 😎
Authorization-г хэрэгжүүлэх олон арга замууд дундаас бидний хувьд анхлан суралцаж буй хүмүүст ойлгоход хамгийн амархан гэж үзээд RBAC аргыг сонгон тайлбарласан билээ. RBAC арга нь бодит амьдрал дээрх жишээтэй ижил төстэй мэт санагддаг. Нэг компанийн ERP систем байлаа гэвэл компани дотор ажилтнууд байна, тухайн ажилтнууд өөрсдийн албан тушаалаас хамаарч өөр өөр үүргүүдтэй байна, тухайн үүрэг бүрд харьяалагдах ажлаа л хийж, харьяалагдах орчиндоо л байна гэх мэт. Жишээ нь компанийн санхүүгийн ажилтан хүссэнээрээ захирлынхаа өрөө рүү ороод чухал баримт бичгүүдийг нь зөвшөөрөлгүй шүүгээнээс нь авдаггүйтэй адил. 😉
Authentication болон Authorization-ы талаар суралцаж буй хүмүүст энэхүү блог маань бага ч гэсэн тус болох болов уу гэж найдаж байна 🙏. Үүнээс цааших зүйлсийг та өөрөө бие дааж суралцаж өөрийгөө хөгжүүлээрэй. Танд амжилт хүсье! 🔥💪
References:
