Authorization matrix σε CRM και portals: ποιος βλέπει τι, πότε και γιατί

Σε ένα custom CRM ή customer portal, το login απαντά μόνο στο ποιος είναι ο χρήστης. Δεν απαντά τι επιτρέπεται να δει ή να κάνει.

Αυτό είναι authorization. Και όταν η εφαρμογή έχει πελάτες, ομάδες, αρχεία, αιτήματα, approvals ή dashboards, το authorization πρέπει να σχεδιαστεί πριν γραφτεί κώδικας.

Τι είναι authorization matrix

Authorization matrix είναι ένας πρακτικός πίνακας που δείχνει ποιοι ρόλοι ή χρήστες έχουν πρόσβαση σε ποιες λειτουργίες και δεδομένα.

Παράδειγμα διαστάσεων:

• ρόλος χρήστη
• τύπος αντικειμένου
• ενέργεια
• ιδιοκτησία αντικειμένου
• κατάσταση workflow
• οργανισμός ή tenant

Έτσι ξεκαθαρίζεται αν ένας πελάτης μπορεί να δει μόνο τα δικά του tickets, αν ένας account manager μπορεί να αλλάξει status, αν ένας admin μπορεί να εξάγει δεδομένα ή αν ένας συνεργάτης βλέπει μόνο συγκεκριμένα projects.

RBAC δεν αρκεί πάντα

Το role-based access control είναι χρήσιμο όταν οι ρόλοι είναι απλοί. Για παράδειγμα user, manager, admin.

Σε πραγματικά portals όμως, χρειάζονται συχνά πιο λεπτοί κανόνες:

• ο χρήστης βλέπει μόνο δεδομένα της εταιρείας του
• manager εγκρίνει μόνο requests του τμήματός του
• συνεργάτης βλέπει μόνο projects όπου έχει ανατεθεί
• customer support βλέπει ticket αλλά όχι οικονομικά στοιχεία
• admin μπορεί να αλλάξει ρόλους αλλά όχι να εγκρίνει δική του αίτηση

Το OWASP επισημαίνει ότι το authorization πρέπει να ελέγχεται σε κάθε request και ότι least privilege και deny-by-default είναι βασικές αρχές.

Object-level access

Πολλά authorization bugs εμφανίζονται όταν η εφαρμογή ελέγχει μόνο ότι ο χρήστης είναι logged in ή έχει γενικό ρόλο, αλλά δεν ελέγχει αν έχει δικαίωμα στο συγκεκριμένο αντικείμενο.

Παράδειγμα:

Ο χρήστης ανοίγει /portal/files/123. Αν αλλάξει το 123 σε 124, βλέπει αρχείο άλλου πελάτη. Αυτό είναι σοβαρό access control πρόβλημα.

Η εφαρμογή πρέπει να ελέγχει ownership και permissions σε κάθε request, server-side.

Business logic rules

Authorization δεν είναι μόνο τεχνικοί ρόλοι. Είναι και κανόνες διαδικασίας.

Παραδείγματα:

• ένα αίτημα δεν μπορεί να εγκριθεί από τον ίδιο που το δημιούργησε
• παραγγελία δεν μπορεί να ακυρωθεί μετά την αποστολή
• οικονομικά στοιχεία φαίνονται μόνο σε συγκεκριμένη ομάδα
• αρχείο μπορεί να διαγραφεί μόνο πριν κλειδώσει η υπόθεση
• AI automation δεν μπορεί να στείλει απάντηση χωρίς έγκριση σε high-risk θέμα

Αυτοί οι κανόνες πρέπει να υπάρχουν στο backend, όχι μόνο στο UI.

Testing authorization

Το authorization χρειάζεται tests. Δεν αρκεί χειροκίνητος έλεγχος με έναν admin λογαριασμό.

Πρακτικά tests:

• user A δεν βλέπει αντικείμενα user B
• tenant A δεν βλέπει tenant B
• απλός χρήστης δεν καλεί admin endpoint
• archived item δεν τροποποιείται
• approval δεν γίνεται από μη εξουσιοδοτημένο ρόλο
• API επιστρέφει 403 αντί για κρυφή επιτυχία

Όταν προστίθεται νέα λειτουργία, πρέπει να ενημερώνεται και το authorization matrix.

Πώς το κάνει η Ai Foundry

Στην Ai Foundry σχεδιάζουμε custom CRM, portals και web applications με authorization από την αρχή. Καταγράφουμε ρόλους, resources, actions, ownership rules και workflow states πριν υλοποιηθούν τα screens.

Αυτό μειώνει access control λάθη και κάνει την εφαρμογή πιο συντηρήσιμη καθώς μεγαλώνει. Ειδικά σε portals με πελάτες, συνεργάτες, έγγραφα, approvals ή AI automations, η σωστή authorization λογική είναι βασικό κομμάτι της ποιότητας της λύσης.

Checklist

Πριν ξεκινήσει η υλοποίηση, ορίστε:

• ποιοι ρόλοι υπάρχουν
• ποια αντικείμενα προστατεύονται
• ποιες ενέργειες επιτρέπονται ανά ρόλο
• ποιοι κανόνες ownership ισχύουν
• ποιες ενέργειες απαιτούν approval
• τι γίνεται όταν ο έλεγχος αποτύχει
• ποια authorization tests χρειάζονται
• πώς θα καταγράφονται failed access attempts

Το authorization matrix δεν είναι γραφειοκρατία. Είναι ο χάρτης που αποτρέπει να βλέπει ο λάθος άνθρωπος τα λάθος δεδομένα.