Ένας χρήστης μπορεί να έχει δικαίωμα να ανοίξει μια καρτέλα πελάτη χωρίς να πρέπει να βλέπει όλα τα πεδία της. Ο πωλητής χρειάζεται στοιχεία επικοινωνίας, το λογιστήριο φορολογικά δεδομένα και ο manager ίσως εμπορικό περιθώριο. Αν η εφαρμογή κρύβει πεδία μόνο με CSS ή page layout, τα δεδομένα μπορεί να συνεχίζουν να επιστρέφονται από API, exports, search ή reports.
Τα field-level permissions εφαρμόζονται στο backend και καθορίζουν χωριστά read και edit access για κάθε πεδίο ή ομάδα πεδίων.
Object, record και field access είναι διαφορετικά επίπεδα
- Object access: αν ο χρήστης μπορεί να χρησιμοποιεί γενικά customers ή deals.
- Record access: ποια συγκεκριμένα records μπορεί να δει, όπως μόνο τη δική του περιοχή.
- Field access: ποια πεδία μέσα στο επιτρεπόμενο record μπορεί να διαβάσει ή να αλλάξει.
Η Salesforce τεκμηρίωση επισημαίνει ότι το field-level security μπορεί να προστατεύει ευαίσθητα πεδία χωρίς να κρύβει όλο το object και ότι πρέπει να ισχύει σε λίστες, reports, search και APIs, όχι μόνο στη detail page.
Read και edit permission χωριστά
Ένα πεδίο μπορεί να είναι hidden, read-only ή editable. Για παράδειγμα, ένας sales rep μπορεί να βλέπει credit status αλλά μόνο το finance role να το αλλάζει. Η edit άδεια προϋποθέτει read, αλλά το αντίστροφο όχι.
Τα permissions μπορούν να βασίζονται σε role, team, tenant και context. Σε ορισμένες περιπτώσεις χρειάζεται dynamic policy: ο account owner βλέπει πλήρες τηλέφωνο, ενώ άλλοι χρήστες της ομάδας βλέπουν masked τιμή. Οι κανόνες πρέπει να παραμένουν κατανοητοί και να μην εξαρτώνται από δεκάδες αλληλοσυγκρουόμενες εξαιρέσεις.
Server-side projection
Το API δεν πρέπει να επιστρέφει forbidden fields και να περιμένει από το frontend να τα κρύψει. Ο serializer ή query layer δημιουργεί response projection σύμφωνα με το permission context.
{
"name": "Εταιρεία Α",
"phone": "210******",
"creditLimit": null,
"_permissions": {"phone": "masked", "creditLimit": "hidden"}
}
Για hidden fields είναι συχνά καλύτερο να λείπει το property αντί να επιστρέφει πραγματική τιμή με UI hint. Το _permissions βοηθά τη διεπαφή να καταλάβει αν πρέπει να εμφανίσει read-only state ή αίτημα πρόσβασης, χωρίς να εκθέτει την τιμή.
Writes με allowlist
Στα update endpoints, το backend φιλτράρει ή απορρίπτει fields που ο actor δεν επιτρέπεται να αλλάξει. Δεν κάνει blind merge ολόκληρο το request object στο record. Αυτό αποτρέπει mass assignment και αλλαγή protected πεδίων μέσω χειροποίητου API call.
Η ασφαλέστερη συμπεριφορά είναι explicit validation error όταν το request περιέχει forbidden field. Η σιωπηλή αγνόηση μπορεί να κάνει τον χρήστη να πιστεύει ότι η αλλαγή αποθηκεύτηκε. Για integrations χρησιμοποιούνται ξεχωριστά service roles με περιορισμένα fields.
Masking δεν είναι encryption
Το masking αλλάζει την παρουσίαση, όπως 69******12. Η πραγματική τιμή παραμένει στη βάση και πρέπει να προστατεύεται με access controls και, όπου απαιτείται, encryption. Το masked value δεν πρέπει να χρησιμοποιείται για update ή να αποθηκεύεται πίσω ως πραγματικό δεδομένο.
Μπορεί να υπάρχει privileged reveal action που απαιτεί reason, step-up authentication και audit event. Το reveal δεν πρέπει να φορτώνει αυτόματα όλες τις τιμές στη σελίδα. Γίνεται συγκεκριμένο server request και καταγράφεται.
Search, filters και sorting
Αν ο χρήστης δεν μπορεί να δει ένα πεδίο, συνήθως δεν πρέπει να μπορεί να φιλτράρει ή να αναζητήσει με αυτό, γιατί τα αποτελέσματα αποκαλύπτουν έμμεσα πληροφορία. Το ίδιο ισχύει για sort order, counts και facets.
Η query builder γνωρίζει ποια fields είναι filterable ανά role. Τα saved views ελέγχονται ξανά όταν ανοίγουν, επειδή τα permissions μπορεί να έχουν αλλάξει από τη στιγμή δημιουργίας τους.
Exports, reports και notifications
Τα exports είναι συχνό σημείο διαρροής. Το CSV generator χρησιμοποιεί την ίδια policy engine με το API και δεν βασίζεται στα visible columns του browser. Τα scheduled reports εκτελούνται με το service ή owner context που έχει οριστεί και δεν στέλνονται σε recipients χωρίς πρόσβαση.
Email templates και notifications δεν πρέπει να ενσωματώνουν protected fields επειδή ένας admin τα επέλεξε παλιότερα. Η permission αξιολόγηση γίνεται τη στιγμή παραγωγής. Αν δεν υπάρχει δικαίωμα, το field αφαιρείται ή η αποστολή απορρίπτεται.
Audit trail
Για ευαίσθητα πεδία καταγράφονται αλλαγές με actor, time, source, old/new representation ή ασφαλές hash ανάλογα με την πολιτική. Τα read events καταγράφονται επιλεκτικά όταν έχουν υψηλό ρίσκο, όπως reveal πλήρους προσωπικού αριθμού ή εξαγωγή.
Το audit log έχει δικά του αυστηρότερα permissions. Δεν πρέπει να μετατρέπεται σε δεύτερη βάση που αποθηκεύει για πάντα όλες τις παλιές ευαίσθητες τιμές. Retention και redaction εφαρμόζονται και εκεί.
Permission matrix και tests
Η ομάδα ορίζει matrix ανά role και field group. Τα automated tests ελέγχουν detail, list, search, export και API update. Δεν αρκεί manual έλεγχος μιας οθόνης.
Χρήσιμες δοκιμές είναι hidden field σε GraphQL selection, bulk update, import, mobile client, background job και impersonation. Ελέγχεται επίσης ότι cache keys περιλαμβάνουν permission context ώστε response με πλήρη fields να μη σερβιριστεί σε χαμηλότερο ρόλο.
Πώς το υλοποιεί η Ai Foundry
Στην Ai Foundry σχεδιάζουμε object, record και field permissions ως ενιαία policy layer. Το backend παράγει επιτρεπόμενα projections, εφαρμόζει write allowlists και χρησιμοποιεί την ίδια λογική σε search, exports, reports και integrations. Προσθέτουμε masking ή audited reveal μόνο όπου έχει πραγματική επιχειρηματική ανάγκη.
Δημιουργούμε permission matrix με την ομάδα, admin εργαλεία για roles και automated tests για κάθε channel. Έτσι τα custom CRM και portals της Ai Foundry επιτρέπουν στους ανθρώπους να κάνουν τη δουλειά τους χωρίς να διανέμουν περισσότερα δεδομένα από όσα χρειάζονται.
Συμπέρασμα
Το να κρύβεται ένα field από τη φόρμα δεν είναι ασφάλεια. Field-level permissions πρέπει να ισχύουν από το query και το API μέχρι τα reports και τα exports. Μόνο τότε το sensitive data παραμένει πραγματικά περιορισμένο.