როგორ დავამატოთ როლებზე დაფუძნებული წვდომის კონტროლი (RBAC) თქვენს აპში

როლებზე დაფუძნებული წვდომის კონტროლის დასამატებლად მიანიჭეთ თითოეულ მომხმარებელს ერთი ან მეტი როლი (მაგალითად ადმინისტრატორი, რედაქტორი, მნახველი), განსაზღვრეთ, რა მოქმედებები შეუძლია თითოეულ როლს, და ეს უფლებები შეამოწმეთ სერვერზე ყოველ მოთხოვნაზე — არა მხოლოდ ღილაკების დამალვით. ასევე შეამოწმეთ, რომ ჩანაწერი, რომელზეც წვდომა ხდება, მომხმარებლის ანგარიშს ან გუნდს ეკუთვნის. დაიწყეთ რამდენიმე ფიქსირებული როლით თქვენს მონაცემთა ბაზაში და ტესტირება ისე გააკეთეთ, რომ სცადოთ სხვა მომხმარებლის მონაცემებზე პირდაპირ წვდომა.

ავთენტიფიკაცია და ავტორიზაცია

ორი სიტყვა, რომლებსაც ხშირად ურევენ:

• ავთენტიფიკაცია არის ვინ ხარ? — შესვლა. იხილეთ როგორ დავამატოთ შესვლა აპში.
• ავტორიზაცია არის რა შეგიძლია? — რომელ გვერდებს, ჩანაწერებსა და მოქმედებებს აღწევს შესული მომხმარებელი.

RBAC ავტორიზაციის ყველაზე გავრცელებული გზაა. ეს მნიშვნელოვანია: 2026 წლის სექტემბრის მდგომარეობით, Broken Access Control OWASP Top 10:2025-ში პირველ ადგილზეა — ეს ფართოდ გამოყენებადი სია ვებ-აპლიკაციების ყველაზე სერიოზულ უსაფრთხოების რისკებს აჯამებს. ტიპიური შეცდომებია: მომხმარებლები კითხულობენ სხვისი ჩანაწერებს 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 მარშრუტში, სერვერულ მოქმედებასა და ფონურ ამოცანაში, რომელიც მონაცემს კითხულობს ან ცვლის. ერთი ცენტრალური ფუნქციის გადახედვა და ტესტირება ადვილია, ვიდრე შემოწმებები კოდში გაბნეული. უარი არის ნაგულისხმევი: თუ არცერთი წესი არ აძლევს ნებას მოქმედებას, ის უარყოფილია.

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-ით. ინტერფეისში დამალე ის მოქმედებები, რისი გაკეთებაც მომხმარებელს არ შეუძლია, მაგრამ უსაფრთხოებისთვის ეს არასდროს დაეყრდნო.

გადახედე ამ აპის ყველა API მარშრუტსა და სერვერულ ფუნქციას. თითოეულისთვის ჩამოწერე, რა მონაცემს კითხულობს ან ცვლის, ამოწმებს თუ არა, რომ მომხმარებელი შესულია, ამოწმებს თუ არა მის როლს და ზღუდავს თუ არა შეკითხვას მის ორგანიზაციაზე. გაასწორე ის, სადაც შემოწმება აკლია, და მაჩვენე სია.

დაამატე მხოლოდ ადმინისტრატორისთვის განკუთვნილი /admin გვერდი, სადაც მფლობელს შეუძლია წევრების როლების შეცვლა. აუკრძალე ბოლო მფლობელის წაშლა ან დაქვეითება, ჩაწერე ყოველი როლის ცვლილება — ვინ და როდის შეცვალა, და დარწმუნდი, რომ როლის ცვლილების endpoint უარყოფს ყველას, ვინც მფლობელი არ არის.

გავრცელებული შეცდომები

• როლების შემოწმება მხოლოდ ფრონტენდში. API მაინც ღია რჩება ყველასთვის, ვინც მას გამოიძახებს.
• კლიენტიდან მიღებულ ID-ებზე ნდობა — userId ან role მოთხოვნის სხეულში სესიის ნაცვლად.
• შეუზღუდავი შეკითხვები, რომლებიც მხოლოდ ჩანაწერის ID-ით იძებნება.
• როლები შემოწმებულია გვერდებზე, მაგრამ არა API მარშრუტებზე, ექსპორტზე, ფაილების ჩამოტვირთვაზე ან webhook-ებზე.
• ადმინისტრატორობა ელფოსტის მისამართით, კოდში ხისტად ჩაწერილი (if email === 'me@...'), რომელსაც ადვილად ივიწყებენ და ძნელად ცვლიან.
• ძალიან ბევრი როლი ძალიან ადრე, რომელსაც ექვს თვეში ვერავინ აუხსნის.
• მოძველებული სესიები: დაქვეითებული მომხმარებელი ადმინისტრატორის უფლებებს გამოსვლამდე ინარჩუნებს. მგრძნობიარე მოქმედებებზე როლები მონაცემთა ბაზიდან შეამოწმეთ ან განაახლეთ.

RBAC ჩამონათვალი

• უფლებების ცხრილი ჩაწერილია ჩვეულებრივი ენით, გამონაკლისები გადაწყვეტილია
• სერვერმა მომხმარებელი სესიიდან იცის, არასდროს მოთხოვნის მონაცემებიდან
• როლები შენახულია მონაცემთა ბაზაში; მომხმარებლები საკუთარ როლს ვერ შეცვლიან
• ერთი ცენტრალური უფლების შემოწმება, უარი ნაგულისხმევი, ყველა მარშრუტში გამოყენებული
• ყოველი შეკითხვა შეზღუდულია მომხმარებლის ორგანიზაციით ან კუთვნილებით
• row-level security იმ ადგილას, სადაც ბრაუზერს ბაზასთან წვდომა აქვს
• ინტერფეისი მალავს იმას, რისი გაკეთებაც მომხმარებელს არ შეუძლია (მხოლოდ მოხერხებულობისთვის)
• მგრძნობიარე მოქმედებები ჩაწერილია
• ყველა როლი შემოწმებულია, მათ შორის პირდაპირი API გამოძახებები და შეცვლილი ID-ები

წვდომის კონტროლი გრძელი სიის ერთი პუნქტია; დანარჩენს AI-ით აგებული აპების უსაფრთხოების ჩამონათვალი ფარავს. თუ თქვენი თანამშრომლებისთვის ინსტრუმენტს აგებთ, როგორ ავაშენოთ შიდა ინსტრუმენტი გაჩვენებთ, სად ერგება როლები.

RBAC Mythex-ზე

Mythex არ გთავაზობთ ჩაშენებულ შესვლის ან როლების სისტემას თქვენი აპის მომხმარებლებისთვის. თქვენ ირჩევთ ავთენტიფიკაციის ბიბლიოთეკას ან პროვაიდერს და აღწერთ როლებს, აგენტი კი მათ თქვენს კოდსა და პროექტის Postgres მონაცემთა ბაზაში აერთიანებს (შესვლის დამატება აპში). Mythex-ის საკუთარი სამუშაო სივრცის როლები, როგორიცაა მფლობელი და წევრი, აკონტროლებს, ვინ შეიძლება არედაქტირებდეს თქვენს Mythex პროექტებს, და არა ის, ვინ იყენებს გამოქვეყნებულ აპს. გამოიყენეთ Plan რეჟიმი, რომ უფლებების ცხრილი ააგებამდე შეთანხმდეთ, შემდეგ კი ზემოთ მოცემული გადახედვის პრომპტი გამოიყენეთ და ყოველი როლი Preview-ში გამოქვეყნებამდე გამოსცადეთ. დოკუმენტაციის უსაფრთხოების პრომპტები სასარგებლო გაგრძელებაა.

კითხვები