Έλεγχος πρόσβασης και RBAC σε API

1) Γιατί ο έλεγχος πρόσβασης σε API

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

2) Υποδείγματα αδειοδότησης: πότε να επιλέξετε τι

RBAC (έλεγχος πρόσβασης βάσει ρόλων) - ρόλοι → άδειες. Απλή, σταθερή, αλλά επιρρεπής σε «έκρηξη ρόλων».
ABAC (με βάση το χαρακτηριστικό) - απόφαση σχετικά με τα χαρακτηριστικά του αντικειμένου/αντικειμένου/πλαισίου (χώρα, επίπεδο KYC, ιδιοκτήτης πόρων, κίνδυνος).
ReBAC (Relation-Based) - γράφημα σχέσεων (ιδιοκτήτης, μέλος της ομάδας, «διαχειριστής έργου»)· επιλύει πολύπλοκες ιεραρχίες.
Πεδίο εφαρμογής (OAuth) - σύμβαση μεταξύ του πελάτη και του εξυπηρετητή πόρων σχετικά με την «περιοχή πρόσβασης» (για παράδειγμα, 'πληρωμές: εγγραφή').
Πρακτική: RBAC για βασικό πίνακα, ABAC για το πλαίσιο και τους περιορισμούς, ReBAC για πολύπλοκες ιεραρχίες (φάκελοι, οργανισμοί, όρια και podackounts).

3) Ταξινόμηση πόρων και δράσεων

Ιεραρχίες: «org → project → πορτοφόλι → συναλλαγή». Κληρονομιά δικαιωμάτων από πάνω προς τα κάτω με πιθανούς «περιορισμούς».
Δράσεις: CRUD + ειδικός τομέας («έγκριση», «επιστροφή χρημάτων», «διακανονισμός»).
Ιδιότητες πόρων: ιδιοκτήτης, περιφέρεια, κατάσταση, ετικέτες κινδύνου (AML/KYC), όρια.
Πολλαπλή μίσθωση: όλες οι λύσεις περιέχουν «ενοικιαστής _ id», άρνηση εξ ορισμού.

4) Αρχιτεκτονική: όπου λαμβάνεται η απόφαση

PEP (σημείο επιβολής της πολιτικής) - τόπος επαλήθευσης: πύλη/πύλη API, πύλη sidecar, υπηρεσία.
PDP (σημείο απόφασης πολιτικής) - κινητήρας πολιτικής: κεντρικός (OPA-service, Cedar-engine) ή ενσωματωμένη βιβλιοθήκη.
PIP (σημείο πληροφοριών πολιτικής) - πηγές χαρακτηριστικών: κατάλογος χρηστών/ρόλων, προφίλ ενοικιαστών, κεντρικός αντισυμβαλλόμενος/κίνδυνος, χάρτης ιδιοκτησίας πόρων.
ΠΑΠΑ (Policy Administration Point) - χάραξη πολιτικής, δημοσίευση, λογιστικός έλεγχος.

Σύσταση: κεντρική μνήμη PDP + τοπικής λύσης στο PEP. πολύπλοκοι έλεγχοι αντικειμένων στην υπηρεσία παρουσία αναλλοίωτων πεδίων.

5) Μάρκες, γραμματόσημα και ταυτότητα

: 'sub' (αναγνωριστικό υποκειμένου), 'au OIDC/OAuth2 (υπηρεσία-στόχος),' scope '/' roles ',' tenant ',' kyc _ level ',' risk _ tier '.
JWT: Υπογραφή RS/ES, σύντομη «exp», επανακυκλοφορία με ανανέωση. Μην βάλετε PII? χρήση 'jti' για έλεγχο ανάκλησης/τροχιάς.
mTLS/HMAC: υπηρεσία προς υπηρεσία και εταίροι· τα γραμματόσημα αποσύρονται από τον κατάλογο από το 'client _ id'.
Συσκευή/πλαίσιο: IP/ASN, geo, ώρα της ημέρας - σύνδεση με τη λύση ABAC (για παράδειγμα, απαγόρευση εγγραφής εκτός ωρών εργασίας).

6) Εξουσιοδότηση επιπέδου αντικειμένου (BOLA-first)

Κάθε πράξη πρέπει να απαντά στο «είναι το θέμα που ο ιδιοκτήτης/έχει το δικαίωμα σε αυτό το» πόρο _ id «;».

Έλεγχος ιδιοκτησίας: "πόρος. = = θέμα. id "ή την ιδιότητα μέλους σε" org "με ρόλο.
Δείγματα φίλτρου: πάντα επικαλύψτε τον πόρο WHERE. =: ενοικιαστής ΚΑΙ... '(ασφάλεια επιπέδου σειράς).
Για πράξεις αναφοράς (ID σε διαδρομή/φορέα) - ομαλοποίηση και επικύρωση της επιχειρηματικής λογικής.

7) Σχεδιασμός RBAC: Ρόλοι, άδειες, σύνολα

Άδειες - ατομικά δικαιώματα: 'πορτοφόλι. διάβασε ',' πορτοφόλι. γράψτε ',' πληρωμή. επιστροφή ".
Ρόλοι - ονομαζόμενα σύνολα αδειών: "admin", "support. διάβασε «,» ταμίας «,» απάτη. αναλυτής ".

Πεδία εφαρμογής - εξωτερική σύμβαση για τους πελάτες (χαρτογράφηση scope→permissions)

• βασικοί ρόλοι + πακέτα αδειών,
• Περιορισμοί ABAC (χώρα/περιφέρεια/ενοικιαστής),
• «Just-In-Time πρόσβαση».

8) Περιορισμοί ABAC/πλαίσιο

Γεωγραφική/δικαιοδοσία: απαγόρευση εγγραφής από απαγορευμένες χώρες (κυρώσεις/κανονιστικές ρυθμίσεις).
Χρόνος/κίνδυνος: «κίνδυνος _ βαθμολογία <κατώτατο όριο» για μεγάλες πράξεις.
ACC/όρια: 'kyc _ level> = 2' για ακίδες> X; τον έλεγχο της «υπαναχώρησης» μεταξύ των συναλλαγών.
«Διατάξεις εμπίστευσης»: απαιτείται mTLS για τους συντρόφους σε επικίνδυνες διαδρομές.

9) REBAC και διάγραμμα δικαιωμάτων

Χρήσιμο για πολύπλοκες επιχειρηματικές δομές (ομάδες, ομάδες, εμπορικά σήματα, υποκαταστήματα).

Σχέσεις: «μέλος», «διοικητής», «ιδιοκτήτης», «θεατής».
Παράγωγα δικαιώματα: ο «θεατής» του πόρου κληρονομείται από το «μέλος» του έργου που ανήκει στο «org».
Αποθήκευση γραφήματος: μια βάση δεδομένων με έναν πίνακα σχέσεων, μια εξειδικευμένη υπηρεσία (στο πνεύμα της προσέγγισης της Ζανζιβάρης). Cache 'check (θέμα, σχέση, αντικείμενο)' απαντήσεις.

10) Απόκρυψη και απόδοση της λύσης

Κρύπτη PDP σε επίπεδο PEP (για παράδειγμα, σε μια πύλη) με το κλειδί: 'υπο' ενοικιαστής 'πόρος' δράση 'πολιτική _ έκδοση'.
TTL σύντομη (δευτερόλεπτα-λεπτά) + αναπηρία ανά εκδήλωση: ρόλος/σχέση/αλλαγή ενοικιαστή.
Έλεγχοι παρτίδων για καταλόγους: μείωση των τελών PDP.
Μέτρηση λύσεων καθυστέρησης. κατά τη διάρκεια της υποβάθμισης - χαριτωμένη-υποβάθμιση μόνο για ανάγνωση (ποτέ για γραφή/χρηματικό).

11) Παραδείγματα πολιτικής

11. 1 γραμματόσημα JWT → τραχύ PEP (ψευδοπυρηνική πύλη)

yaml
- match: { prefix: "/api/v1/wallets" }
authz:
require:
- claim: "aud"
equals: "wallet-service"
- claim: "scope"
includes_any: ["wallet. read", "wallet. write"]
context:
tenant_from: "claim:tenant"

11. 2 OPA/Rego (ABAC + BOLA)

rego package authz

default allow = false

allow {
input. action == "wallet. read"
input. subject. tenant == input. resource. tenant some role role:= input. subject. roles[_]
role == "support. read"
}

allow {
input. action == "payment. refund"
input. subject. tenant == input. resource. tenant input. subject. kyc_level >= 2 input. subject. risk_tier <= 2 input. subject. id == input. resource. owner_id # BOLA
}

11. 3 Περιορισμός δικαιοδοσίας (πολιτική αρνησικυρίας)

rego deny[msg] {
input. action == "withdraw. create"
input. context. country in {"IR","KP","SY"}
msg:= "Jurisdiction not allowed"
}

11. 4 Πολιτική ReBAC (ψευδο)

allow(subject, "wallet. write", wallet) --
related(subject, "member", wallet. project) ∧ related(subject, "admin", wallet. org)   ∧ wallet. tenant == subject. tenant.

12) Διαχείριση πολιτικής και εκδόσεων

Έκδοση πολιτικής ('policy _ version') και καναρίνι για επικίνδυνες αλλαγές.
«Dry-run» (ξηρές/σκιώδεις αποφάσεις) - log 'lable/renge' χωρίς πρόσκρουση.
Κατάλογος πολιτικής και μετανάστευσης: Ποιος άλλαξε πότε και γιατί; χαρτογράφηση συμβάντων.
Δοκιμές για αρνητικά σενάρια (απαγορευμένες περιπτώσεις) - απαιτούνται στον ΚΚΠ.

13) Παρατηρησιμότητα και λογιστικός έλεγχος

Αρχεία καταγραφής αποφάσεων: "trace _ i ," subjec , "ενοικιαστής", "action", "resource _ i ," result "," policy _ version ", λόγος αποτυχίας.
Μετρήσεις: 'authz _ decision _ latency', 'authz _ reserved _ total {action}', μερίδιο των προσπαθειών BOLA, cache hit-rate.
Dashboards: κορυφαίες αποτυχίες των δράσεων/ενοικιαστών, τάσεις μετά την κυκλοφορία των πολιτικών.

14) Ασφάλεια και βιωσιμότητα

Άρνηση εξ ορισμού: καμία ρητή άδεια = άρνηση.
Κλειστό: όταν το PDP δεν είναι διαθέσιμο, απαγορεύεται η κρίσιμη εγγραφή (ή υποβαθμίζεται στο «ελάχιστο σύνολο» αυστηρά επαληθευμένων ρόλων).
Τοπικοί «έλεγχοι φύλαξης» στο πλαίσιο υπηρεσιών για κρίσιμες αναλλοίωτες (π.χ. «ενοικιαστής »/« ιδιοκτήτης»).
ελαχιστοποίηση σημάτων κατατεθειμένων σε JWT· ευαίσθητα χαρακτηριστικά φορτίου μέσω PIP μέσω ασφαλούς διαύλου.

15) Ιδιαιτερότητες του iGaming/Finance

Ρόλοι: "ταμίας", "kyc. πράκτορας ',' aml. αξιωματικός «,» απάτη. αναλυτής ',' vip. διαχειριστής «,» κίνδυνος. admin '.
Περιορισμοί: οι πράξεις πληρωμής εξαρτώνται από το «kyc _ level», τα όρια των υπεύθυνων πληρωμών, το καθεστώς ΚΝΕΠΔ/κυρώσεις.
Μητρώα κλειδώματος: 'org/brand/device/payment _ instrument' - φίλτρα ABAC σε εγγραφή.
Αρχεία ελέγχου αμετάβλητα για τις δράσεις KYC/AML/pin αποθήκευση σύμφωνα με τις ρυθμιστικές προθεσμίες.
API εταίρων: mTLS + σύμβαση «πεδίων» σε διαδρομές, φίλτρα geo/ASN σε περίμετρο.

16) Έλεγχος και εξακρίβωση

Αρνητικός πίνακας: κατάλογος ρητών «απαγορευμένων» περιπτώσεων και διόρθωση με δοκιμές.
Έγκριση Fuzz: αντικατάσταση του 'tenant _ i ,' ιδιοκτήτης _ id ', παράκαμψη φίλτρων κατά την ειδοποίηση/διαλογή.
Δοκιμή φορτίου PDP: Ελέγξτε την καθυστέρηση και τη συμπεριφορά των κρυψώνων στο p95/p99.
Απελευθέρωση πολιτικής: ξηρή λειτουργία + καναρίνι + αυτόματη δοκιμή με αναμενόμενη άρνηση/δυνατότητα.
Περιστατικά: επανάληψη αιτήσεων στο περίπτερο με ακριβή έκδοση των πολιτικών.

17) Αντιπατερίδια

Βασιστείτε μόνο σε «πεδίο εφαρμογής» χωρίς ελέγχους αντικειμένων (BOLA).
Αναμίξτε επιχειρηματική λογική και ελέγχους δικαιωμάτων σε κάθε χειριστή χωρίς κεντρικό μοντέλο.
Hardcode ρόλους σε UI και λύσεις πελατών εμπιστοσύνης.
Απουσία φίλτρων 'tenant '/' ιδιοκτήτη' σε αιτήσεις στη βάση δεδομένων (διαβάζει διαρροή).
Κατά την αλλαγή ρόλων/σχέσεων, δεν υπάρχει λύση κρυφής μνήμης.
Μακρόβια JWT χωρίς ανάκληση/περιστροφή.

18) Κατάλογος ελέγχου ετοιμότητας Prod

• Ορίζονται οι πόροι/δραστηριότητες, οι ιεραρχίες και η πολλαπλή μίσθωση.
• Βασικοί περιορισμοί RBAC + ABAC, όπου χρειάζεται - ReBAC.
• Σχεδιάζονται PDP/PEP. υπάρχει μια τοπική κρύπτη λύσης και η αναπηρία της.
• Οι πολιτικές είναι επαληθευμένες, αρνητικές δοκιμές σεναρίων στον ΚΚΠ.
• Έλεγχοι BOLA σε κάθε εγγραφή/ανάγνωση σε συγκεκριμένο «πόρο _ id».
• JWT με ελάχιστες σφραγίδες, σύντομη «exp», έλεγχος/ανάκληση «jti».
• Καταγραφές μετρήσεων/αποφάσεων, ταμπλό, προειδοποιήσεις με άρνηση/καθυστέρηση.
• Αποτυχία-κλείσιμο για κρίσιμη εγγραφή. τεκμηριώνεται η κατάσταση εφεδρείας.
• Τεκμηρίωση πελατών: «πεδία εφαρμογής», κωδικοί σφάλματος (401/403/404/409), παραδείγματα.

19) TL, DR

Κατασκευή πρώτης εξουσιοδότησης BOLA: κεντρική κρύπτη PDP + λύσης, RBAC ως βάση, ABAC για το πλαίσιο, ReBAC για τις σχέσεις. Όλα τα αιτήματα εντάσσονται στο πλαίσιο του «ενοικιαστή» και ενός ειδικού «πόρου _ id»· άρνηση εξ ορισμού, σύντομη JWT, φίλτρα αντικειμένων στη βάση δεδομένων. Πολιτικές έκδοσης και δοκιμών, μέτρηση καθυστέρησης/άρνησης, συμβάντα αναπαραγωγής. Για το iGaming - ατομικοί ρόλοι (KYC/AML/ταμειακό μητρώο), σκληροί περιορισμοί ABAC και αμετάβλητος λογιστικός έλεγχος.