Πώς να προσθέσετε έλεγχο πρόσβασης βάσει ρόλων (RBAC) στην εφαρμογή σας

Για να προσθέσετε έλεγχο πρόσβασης βάσει ρόλων, δώστε σε κάθε χρήστη έναν ή περισσότερους ρόλους (για παράδειγμα διαχειριστής, επεξεργαστής, αναγνώστης), ορίστε ποιες ενέργειες επιτρέπονται σε κάθε ρόλο, και ελέγξτε αυτά τα δικαιώματα στον διακομιστή για κάθε αίτημα — όχι απλώς κρύβοντας κουμπιά. Ελέγξτε επίσης ότι η εγγραφή στην οποία αποκτάται πρόσβαση ανήκει στον λογαριασμό ή την ομάδα του χρήστη. Ξεκινήστε με λίγους σταθερούς ρόλους στη βάση σας και δοκιμάστε προσπαθώντας να φτάσετε απευθείας στα δεδομένα άλλου χρήστη.

Ταυτοποίηση έναντι εξουσιοδότησης

Δύο λέξεις που συχνά μπερδεύονται:

• Ταυτοποίηση είναι το ποιος είσαι; — η σύνδεση. Δείτε πώς να προσθέσετε σύνδεση στην εφαρμογή σας.
• Εξουσιοδότηση είναι το τι επιτρέπεται να κάνεις; — ποιες σελίδες, εγγραφές και ενέργειες μπορεί να φτάσει ένας συνδεδεμένος χρήστης.

Το RBAC είναι ο συνηθέστερος τρόπος εξουσιοδότησης. Έχει σημασία: από τον Σεπτέμβριο του 2026, το Broken Access Control βρίσκεται στην πρώτη θέση του OWASP Top 10:2025, της ευρέως χρησιμοποιούμενης λίστας με τους σοβαρότερους κινδύνους ασφαλείας για web εφαρμογές. Τυπικές αστοχίες είναι οι χρήστες που διαβάζουν εγγραφές άλλων αλλάζοντας ένα ID στη διεύθυνση URL, ή κανονικοί χρήστες που καλούν διαδρομές API μόνο για διαχειριστές.

Επιλέξτε ένα μοντέλο

Στην πράξη, οι περισσότερες εφαρμογές συνδυάζουν δύο πράγματα: ρόλους για το είδος των ενεργειών που μπορεί να κάνει κάποιος, και ιδιοκτησία για τις εγγραφές πάνω στις οποίες μπορεί να τις κάνει. «Οι επεξεργαστές μπορούν να επεξεργάζονται αναρτήσεις» είναι κανόνας ρόλου· «…αναρτήσεις στον δικό τους χώρο εργασίας» είναι κανόνας ιδιοκτησίας. Χρειάζεστε και τα δύο.

Ξεκινήστε πιο απλά από ό,τι νομίζετε. Ο διαχειριστής, το μέλος και ο αναγνώστης καλύπτουν έναν εκπληκτικό αριθμό εφαρμογών. Είναι ευκολότερο να χωρίσετε έναν ρόλο αργότερα παρά να ξεμπλέξετε δέκα ρόλους που κανείς δεν καταλαβαίνει.

Σχεδιάστε τους ρόλους πριν γράψετε κώδικα

Γράψτε πρώτα έναν πίνακα δικαιωμάτων με απλά λόγια. Χρησιμεύει ως προδιαγραφή για τον δημιουργό AI και ως σχέδιο δοκιμών σας:

Αποφασίστε και τις ακραίες περιπτώσεις: μπορεί ο τελευταίος ιδιοκτήτης να φύγει; Μπορεί ένας διαχειριστής να αφαιρέσει τον ιδιοκτήτη; Τι βλέπει ένας αφαιρεμένος χρήστης;

Βήμα προς βήμα

1. Έχετε πρώτα λειτουργική σύνδεση

Το RBAC στηρίζεται στην ταυτοποίηση. Ο διακομιστής πρέπει να ξέρει αξιόπιστα ποιος κάνει κάθε αίτημα, από μια συνεδρία ή ένα επαληθευμένο token — ποτέ από ένα 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)
);

Ποτέ μην αφήνετε τους χρήστες να ορίζουν τον δικό τους ρόλο μέσω μιας κανονικής ενημέρωσης προφίλ. Οι αλλαγές ρόλων περνούν από ένα αφιερωμένο τελικό σημείο που ελέγχει δικαιώματα.

3. Ελέγξτε τα δικαιώματα στον διακομιστή, σε ένα σημείο

Γράψτε μία βοηθητική συνάρτηση — κάτι σαν can(user, 'projects.delete', project) — και καλέστε την σε κάθε διαδρομή API, κάθε server action και κάθε εργασία παρασκηνίου που διαβάζει ή αλλάζει δεδομένα. Μία κεντρική συνάρτηση είναι ευκολότερη στην αναθεώρηση και στη δοκιμή από έλεγχους διάσπαρτους στον κώδικα. Απορρίπτετε από προεπιλογή: αν κανένας κανόνας δεν επιτρέπει μια ενέργεια, αρνείστε την.

4. Περιορίστε κάθε ερώτημα

Κάθε ερώτημα για δεδομένα ομάδας πρέπει να περιλαμβάνει την ομάδα: where organization_id = :currentOrg, όχι μόνο where id = :id. Αυτό σταματά κάποιον να αλλάξει το /projects/123 σε /projects/124 και να δει το έργο άλλης εταιρείας. Για εγγραφές άλλων ομάδων, επιστρέφετε «δεν βρέθηκε» αντί για «απαγορεύεται», ώστε να μην αποκαλύπτετε ότι υπάρχουν.

5. Προσθέστε προστασία σε επίπεδο βάσης όπου έχει σημασία

Το row-level security (RLS) του Postgres επιτρέπει στη βάση να επιβάλλει ποιες γραμμές βλέπει κάθε χρήστης. Είναι απαραίτητο αν ο περιηγητής μιλά απευθείας με τη βάση (όπως σε ορισμένες φιλοξενούμενες backend υπηρεσίες), και χρήσιμο δεύτερο επίπεδο για ευαίσθητους πίνακες αλλιώς.

6. Αντικατοπτρίστε τους ρόλους στη διεπαφή

Τώρα κρύψτε ή απενεργοποιήστε ό,τι δεν μπορούν να κάνουν οι χρήστες, ώστε η εφαρμογή να μην μπερδεύει. Αυτό είναι μόνο για τη χρηστικότητα· οι έλεγχοι στον διακομιστή είναι αυτοί που προστατεύουν.

7. Καταγράψτε τις ευαίσθητες ενέργειες

Καταγράψτε ποιος άλλαξε ρόλους, διέγραψε δεδομένα ή εξήγαγε εγγραφές, και πότε. Ένα αρχείο ελέγχου (audit log) βοηθά με ερωτήματα υποστήριξης και περιστατικά.

8. Δοκιμάστε σαν επιτιθέμενος

Συνδεθείτε ως κάθε ρόλος και δοκιμάστε κάθε ενέργεια του πίνακα δικαιωμάτων. Μετά δοκιμάστε όσα δεν θα έπρεπε να λειτουργούν: καλέστε διαδρομές διαχειριστή ως αναγνώστης, αλλάξτε ID σε διευθύνσεις URL και αιτήματα, αφαιρέστε τον εαυτό σας ως τελευταίο ιδιοκτήτη. Αυτοματοποιημένες δοκιμές για τον πίνακα δικαιωμάτων αξίζουν μόλις σταθεροποιηθούν οι κανόνες.

Προτροπές που δουλεύουν

Πρόσθεσε έλεγχο πρόσβασης βάσει ρόλων. Ρόλοι ανά οργανισμό: owner, admin, member, viewer, αποθηκευμένοι σε πίνακα memberships. Τα δικαιώματα είναι σε αυτόν τον πίνακα: [επικόλλησε τον πίνακά σου]. Δημιούργησε μία βοηθητική συνάρτηση can(user, action, resource) στον διακομιστή, με προεπιλογή την απόρριψη, και χρησιμοποίησέ την σε κάθε διαδρομή API. Περιόρισε κάθε ερώτημα με organization_id. Κρύψε τις ενέργειες που ο χρήστης δεν μπορεί να κάνει στη διεπαφή, αλλά ποτέ μην βασίζεσαι σε αυτό για την ασφάλεια.

Ελέγξτε κάθε διαδρομή API και κάθε συνάρτηση διακομιστή σε αυτή την εφαρμογή. Για καθεμία, γράψτε τι δεδομένα διαβάζει ή αλλάζει, αν ελέγχει ότι ο χρήστης έχει συνδεθεί, αν ελέγχει τον ρόλο του, και αν περιορίζει το ερώτημα στον οργανισμό του. Διόρθωσε όσες δεν έχουν έλεγχο και δείξε μου τη λίστα.

Πρόσθεσε σελίδα /admin μόνο για τον ιδιοκτήτη, όπου ο ιδιοκτήτης αλλάζει ρόλους μελών. Απαγόρευσε την αφαίρεση ή υποβάθμιση του τελευταίου ιδιοκτήτη, κατέγραψε κάθε αλλαγή ρόλου με το ποιος την έκανε και πότε, και βεβαιώσου ότι το τελικό σημείο αλλαγής ρόλου απορρίπτει όποιον δεν είναι ιδιοκτήτης.

Συνηθισμένα λάθη

• Έλεγχος ρόλων μόνο στην μπροστινή πλευρά. Το API παραμένει ανοιχτό σε όποιον το καλεί.
• Εμπιστοσύνη σε ID από τον πελάτη — ένα userId ή role στο σώμα του αιτήματος αντί για τη συνεδρία.
• Ερωτήματα χωρίς περιορισμό που φέρνουν εγγραφή μόνο με το ID της.
• Ρόλοι ελεγμένοι σε σελίδες αλλά όχι σε διαδρομές API, εξαγωγές, λήψεις αρχείων ή webhooks.
• Διαχειριστής με βάση τη διεύθυνση email γραμμένη σταθερά στον κώδικα (if email === 'me@...'), που είναι εύκολο να ξεχαστεί και δύσκολο να αλλάξει.
• Πάρα πολλοί ρόλοι πολύ νωρίς, που κανείς δεν μπορεί να εξηγήσει έξι μήνες αργότερα.
• Παλιές συνεδρίες: ένας υποβιβασμένος χρήστης διατηρεί δικαιώματα διαχειριστή μέχρι να αποσυνδεθεί. Ελέγξτε τους ρόλους από τη βάση, ή ανανεώστε τους, σε ευαίσθητες ενέργειες.

Λίστα ελέγχου RBAC

• Πίνακας δικαιωμάτων γραμμένος με απλά λόγια, οι ακραίες περιπτώσεις αποφασισμένες
• Ο διακομιστής ξέρει τον χρήστη από τη συνεδρία, ποτέ από δεδομένα αιτήματος
• Οι ρόλοι αποθηκεύονται στη βάση· οι χρήστες δεν μπορούν να αλλάξουν τους δικούς τους
• Ένας κεντρικός έλεγχος δικαιωμάτων, με προεπιλογή την απόρριψη, σε κάθε διαδρομή
• Κάθε ερώτημα περιορισμένο στον οργανισμό ή την ιδιοκτησία του χρήστη
• Ασφάλεια σε επίπεδο γραμμής όπου η διεπαφή μπορεί να φτάσει τη βάση
• Η διεπαφή κρύβει ό,τι δεν μπορούν να κάνουν οι χρήστες (μόνο για χρηστικότητα)
• Ευαίσθητες ενέργειες καταγράφονται
• Κάθε ρόλος δοκιμάστηκε, συμπεριλαμβανομένων των άμεσων κλήσεων API και των αλλαγμένων ID

Ο έλεγχος πρόσβασης είναι ένα στοιχείο σε μια μακρύτερη λίστα· η λίστα ασφαλείας για εφαρμογές που χτίστηκαν με AI καλύπτει τα υπόλοιπα. Αν φτιάχνετε εργαλείο για το δικό σας προσωπικό, το πώς να φτιάξετε εσωτερικό εργαλείο δείχνει πού ταιριάζουν οι ρόλοι.

RBAC στο Mythex

Το Mythex δεν παρέχει ενσωματωμένο σύστημα σύνδεσης ή ρόλων για τους χρήστες της εφαρμογής σας. Επιλέγετε μια βιβλιοθήκη ή πάροχο ταυτοποίησης και περιγράφετε τους ρόλους, και ο πράκτορας τα συνδέει στον κώδικά σας και στη Postgres βάση δεδομένων του έργου (προσθήκη σύνδεσης στην εφαρμογή σας). Οι ρόλοι χώρου εργασίας του Mythex, όπως Owner και Member, ελέγχουν ποιος μπορεί να επεξεργάζεται τα έργα σας στο Mythex, όχι ποιος μπορεί να χρησιμοποιεί τη δημοσιευμένη εφαρμογή σας. Χρησιμοποιήστε τη λειτουργία Plan για να συμφωνήσετε τον πίνακα δικαιωμάτων πριν χτίσετε, μετά χρησιμοποιήστε την παραπάνω προτροπή αναθεώρησης και δοκιμάστε κάθε ρόλο στο Preview πριν δημοσιεύσετε. Οι προτροπές ασφαλείας της τεκμηρίωσης είναι χρήσιμη συνέχεια.

Ερωτήσεις