Ρόλοι και δικαιώματα σε ένα SaaS πριν από τον κώδικα

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

Το OWASP, η ανοιχτή κοινότητα ασφάλειας εφαρμογών, βάζει στην πρώτη θέση της λίστας Top 10 του 2021 το Broken Access Control, δηλαδή τον σπασμένο έλεγχο πρόσβασης. Σε σχέση με την προηγούμενη λίστα, ανέβηκε από την πέμπτη θέση στην πρώτη. Αυτό δείχνει πόσο συχνά οι εφαρμογές στέλνουν τους χρήστες εκεί όπου δεν έπρεπε.

Ένας ρόλος είναι ένα όνομα για μια ομάδα δικαιωμάτων. Το NIST περιγράφει το RBAC (role-based access control) ως μοντέλο όπου οι χρήστες ανατίθενται σε ρόλους, και κάθε ρόλος έχει ένα ή περισσότερα δικαιώματα. Οι διαχειριστές ορίζουν ποιες ενέργειες χρειάζεται κάθε θέση εργασίας και βάζουν τους ανθρώπους στον αντίστοιχο ρόλο.

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

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

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

Ακολουθούμε τρεις κανόνες από το Authorization Cheat Sheet του OWASP. Ο πρώτος είναι τα ελάχιστα δικαιώματα: ο χρήστης παίρνει μόνο όσα χρειάζεται για τη δουλειά του. Ο δεύτερος είναι η άρνηση από προεπιλογή, δηλαδή ό,τι δεν έχει ρητά επιτραπεί, απαγορεύεται. Ο τρίτος είναι ο έλεγχος σε κάθε αίτημα.

Ο τρίτος κανόνας έχει μια πρακτική συνέπεια. Το OWASP τονίζει ότι ο έλεγχος γίνεται στον διακομιστή και όχι μόνο στον browser, γιατί ο browser ελέγχεται από τον χρήστη. Ένα κουμπί που κρύβεται από την οθόνη δεν προστατεύει τίποτα, αν ο διακομιστής δέχεται το αίτημα. Για τον ίδιο λόγο, ένας έλεγχος που λείπει από ένα μόνο σημείο μπορεί να αποκαλύψει έναν ολόκληρο πόρο.

Ο ρόλος δεν αρκεί πάντα. Στον πίνακα παραπάνω ο πελάτης μπορεί να επεξεργάζεται αιτήματα, αλλά μόνο τα δικά του. Αυτό είναι κανόνας για την εγγραφή και όχι για τον ρόλο. Το OWASP Top 10 το αναφέρει ως πρόληψη: τα μοντέλα πρόσβασης πρέπει να επιβάλλουν την ιδιοκτησία της εγγραφής, ώστε ο χρήστης να μην μπορεί να διαβάζει, να αλλάζει ή να διαγράφει εγγραφές άλλων.

Το ίδιο το Cheat Sheet του OWASP προτείνει για τις εφαρμογές συνήθως μοντέλα που κοιτάζουν χαρακτηριστικά ή σχέσεις (ABAC, ReBAC), γιατί οι ρόλοι δυσκολεύονται όταν η απόφαση εξαρτάται από την ίδια την εγγραφή. Γι' αυτό ξεκινάμε από τους ρόλους, που εξηγούνται εύκολα σε όλη την ομάδα, και προσθέτουμε κανόνες ιδιοκτησίας όπου ο πίνακας το ζητά. Σε μια πλατφόρμα με πολλούς πελάτες υπάρχει και ένα ακόμη επίπεδο, ο διαχωρισμός των δεδομένων ανά tenant, που περιγράφεται στο άρθρο για τα δεδομένα των πελατών σε ένα SaaS.

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

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