GH GambleHub

Κινητήρας ρόλων

1) Υποδείγματα αδειοδότησης

RBAC (Role-based Access Control): το θέμα λαμβάνει ρόλους, οι ρόλοι συνδέονται με άδειες. Απλά διαχειριστείτε, καλό για τα τυπικά καθήκοντα.
ABAC (Έλεγχος πρόσβασης βάσει χαρακτηριστικών) - η λύση εξαρτάται από τα χαρακτηριστικά του θέματος, τους πόρους, τη δράση και το περιβάλλον (χρόνος, IP, περιοχή, κίνδυνος). Ευέλικτοι και κλιμακωτοί σε πολύπλοκους κανόνες.
RBAC + ABAC υβρίδιο: οι ρόλοι δίνουν μια «βασική» ικανότητα, τα χαρακτηριστικά την περιορίζουν (συνθήκες).
(προαιρετικά) ReBAC/Βασισμένο στις σχέσεις: γράφημα σχέσεων (ιδιοκτήτης, μέλος της ομάδας, αντιπρόσωπος), χρήσιμο για έγγραφα και όργανα.

2) Αρχιτεκτονική: PDP/PEP και ροές

PEP (σημείο επιβολής της πολιτικής): όπου εφαρμόζεται η λύση (πύλη API, μέθοδος υποστήριξης, στρώμα SQL, UI).
PDP (σημείο απόφασης πολιτικής): υπηρεσία/βιβλιοθήκη που υπολογίζει «ABLOR/DENY» ανά πολιτική και ιδιότητα.
PIP (σημείο πληροφοριών πολιτικής): πηγές χαρακτηριστικών (IdP/προφίλ, μεταδεδομένα πόρων, ποσοστό κινδύνου, geo).
PAP (σημείο διαχείρισης πολιτικής) - διοικητική διεπαφή/αποθετήριο πολιτικής (εκδόσεις, σχέδια, δημοσίευση).

Ροή: το αίτημα → PEP αποτελεί πλαίσιο στο → το PDP συγκεντρώνει τα ελλείποντα χαρακτηριστικά (μέσω PIP) → υπολογίζει την απόφαση → εφαρμόζεται το PEP (ενεργοποίηση/απενεργοποίηση/διακοπή) → τον έλεγχο.

3) Υπόδειγμα δεδομένων

Οντότητες (ελάχιστο):
  • 'subjec (χρήστης/υπηρεσία) :' tenant _ i , 'roles', 'distribution ,' risk _ level ',' mfa _ verified ',' scopes ',' requirement .
  • "Τύπος και χαρακτηριστικά των πόρων:" τύπος "," ιδιοκτήτης _ i , "ενοικιαστής _ i ," ταξινόμηση "(δημόσια/εμπιστευτική)," περιφέρεια "," ετικέτες ".
  • «Δράση»: «διάβασε», «γράψτε», «διαγράψτε», «εξάγετε», «εγκρίνετε», «παριστάνετε» и т. п.
  • 'environment': 'time', 'ip', 'device', 'geo', 'auth _ strength', 'business _ content' (канал, тариф).
Μέρος RBAC:
  • «ρόλοι (id, tenant_id, όνομα, κληρονομίες []» - ιεραρχίες και πρότυπα υποστήριξης.
  • «διαστάσεις (id, resource_type, δράση, περιορισμός;)».
  • 'role _ permissions (role_id, permission_id)'.
  • 'ταξινομήσεις (subject_id, role_id, πεδίο εφαρμογής)' - πεδίο εφαρμογής: παγκόσμιο/ανά έργο/αντικείμενο.
Μέρος (πολιτικές) της ABAC:
  • 'policy (id, effect = able' deny, target: {subject, resource, action}, condition: expr, priority, version, status) '.

4) Αρχές λήψης αποφάσεων

Αρνητικές παραβάσεις: Οι ρητές απαγορεύσεις δίνουν προτεραιότητα στις άδειες.
Ελάχιστο προνόμιο (PoLP): Έκδοση ελάχιστης απαιτούμενης πρόσβασης, επέκταση μέσω όρων.
Διαχωρισμός καθηκόντων (SoD): απαγόρευση συνδυασμού ρόλων/δράσεων (για παράδειγμα, «δημιουργημένη πληρωμή» ≠ «συλληφθείσα»).
Γνώση του πλαισίου: Ενίσχυση των απαιτήσεων υψηλότερου κινδύνου (όχι ΜΧΣ, ύποπτη ΔΙ).
Προσδιορισμός: το ίδιο πλαίσιο → την ίδια απάντηση. Καταγραφή της έκδοσης πολιτικής.

5) Πρότυπα εφαρμογής

5. 1 Υβριδικό RBAC→ABAC (προετοιμασία)

Οι ρόλοι δίνουν «προεπιλεγμένο δικαίωμα», οι όροι ABAC περιορίζουν:
yaml
Declarative Policy Example
- id: doc_read_own effect: allow target: { action: read, resource. type: document, subject. roles: ["editor","owner"] }
condition: resource. owner_id == subject. id

- id: doc_read_team effect: allow target: { action: read, resource. type: document, subject. roles: ["editor","viewer"] }
condition: subject. team_id in resource. shared_team_ids

- id: doc_read_confidential_external effect: deny target: { action: read, resource. type: document }
condition: resource. classification == "confidential" and subject. tenant_id!= resource. tenant_id priority: 100 # deny high priority

5. 2 Σειρά/Επιτόπου Ασφάλεια

Σε επίπεδο βάσης δεδομένων: πολιτικές RLS (από τον «ενοικιαστή _ id», «ιδιοκτήτη _ id»).
Σε επίπεδο API: συλλογές φίλτρων και πεδία μάσκας εάν δεν υπάρχει 'επιτρεπόμενο: read_sensitive_fields'.

5. 3 Κλιμακούμενες λύσεις

Εξάρτηση αντοχής ταυτοποίησης:

allow if action == "export" and subject. mfa_verified == true else deny

5. 4 Προσωρινές ανοχές

Επιχορηγήσεις με TTL: "ανάθεση. , πρόσβαση «παράθυρα» (κατά τις ώρες εργασίας της περιοχής πόρων).

6) Επιδόσεις και εγκλωβισμός

Λήψη απόφασης κατά κλειδί «(subject_hash, resource_key, δράση, policy_version)» με σύντομο TTL.
Cache Edge των ιδιοτήτων του θέματος (ισχυρισμοί στη μάρκα) + ιδιότητες τεμπέληδων πόρων.
Σταδιακή ακύρωση: αναπηρία λόγω γεγονότων (αλλαγή ρόλων, αλλαγή πολιτικής, μεταφορά πόρων σε «εμπιστευτικό»).
Έλεγχοι παρτίδων: για τους καταλόγους - αξιολόγηση με «φίλτρο» (πολιτική πρόβλεψη ώθησης) ώστε να μην τραβιέται η γραμμή PDP ανά γραμμή.

7) Πολυπληθής

Σε κάθε πίνακα - «ενοικιαστής _ id», οι προκαθορισμένες πολιτικές περιορίζουν την πρόσβαση στο πλαίσιο μίσθωσης.
Οι διαχειριστές μισθώσεων διαχειρίζονται μόνο τους ρόλους/τα δικαιώματα της μίσθωσής τους.
Πρόσβαση σε διασταυρούμενη μίσθωση - αποκλειστικά μέσω ρητών προσκλήσεων/κοινοχρησίας με ρητή παράκαμψη.

8) Διοίκηση πολιτικής και κύκλος ζωής

Έκδοση: "πολιτική. έκδοση "στην απάντηση PDP, αποθήκευση σε έλεγχο.
Περιβάλλοντα: σχέδιο καναρινιού (μέρη κυκλοφορίας/σκιώδους τρόπου) prod.
Πίνακας δοκιμής: πίνακες αλήθειας ανά βασικό ρόλο/χαρακτηριστικά (δοκιμές σύμβασης).
Διαχείριση αλλαγών: Συγχώνευση αιτημάτων για πολιτικές με επανεξετάσεις ασφάλειας/συμμόρφωσης.

9) Έλεγχος και παρατηρησιμότητα

Журнал: 'decision _ id', 'subjec решений,' action ',' resource _ ref ',' result ',' matched _ policies ',' policy _ version ',' fatures _ digest '.
Μετρήσεις: QPS PDP, p95 latency, hit-rate cache, renge share, step-up rate, SoD event.
Ίχνη: εύρος ανά κλήση PDP. συσχέτιση με το αίτημα API.
Επανάληψη: δυνατότητα «αναπαραγωγής» ιστορικών αποφάσεων σχετικά με τη νέα έκδοση της πολιτικής (έλεγχος ασφαλείας).

10) Ενσωμάτωση στην επαλήθευση ταυτότητας και στις μάρκες

Ταυτότητα - από IdP (OIDC/SAML). Οι μάρκες φέρουν ένα ελάχιστο χαρακτηριστικό: 'υπο', 'ενοικιαστής', 'ρόλοι', 'auth _ time', 'amr', 'scopes'.
Για το ABAC, τραβήξτε τις «βαριές» πινακίδες από την πλευρά του εξυπηρετητή (PIP) έτσι ώστε να μην φουσκώσετε το σύμβολο.
Υπογεγραμμένες μάρκες πόρων (δυνατότητα/προσκλήσεις) - για αυστηρά περιορισμένες αντιπροσωπείες.

11) Ψευδής κωδικός PDP (απλουστευμένος)

python def decide(subject, resource, action, env, policies):
matched = []
effect = "deny"
Explicit DENYs with priority for p in sorted (policies, key = lambda x: x.priority, reverse = True):
if target_matches(p. target, subject, resource, action):
if eval_condition(p. condition, subject, resource, env):
matched. append(p. id)
if p. effect == "deny":
return Decision("deny", matched, p. version)
Looking for ALLOW for p in policies:
if target_matches(p. target, subject, resource, action):
if eval_condition(p. condition, subject, resource, env):
matched. append(p. id)
effect = "allow"
break return Decision(effect, matched, max_version(matched, policies))

12) Αντι-μοτίβα

«Ρόλος = σελίδα» (εκατοντάδες μικροί ρόλοι χωρίς μοντέλο τομέα).
Αποθήκευση των πολιτικών μόνο σε κωδικό χωρίς εκδόσεις/ελέγχους.
Η έλλειψη παράκαμψης και SoD → αυξημένο κίνδυνο απάτης.
Hard lists 'user _ i in rules (αντί ιδιοτήτων/σχέσεων).
Χωρίς φίλτρο στρώματος δεδομένων (RLS) μόνο με φίλτρο UI.
Συγχρονισμός ρόλων μέσω χειροκίνητων σεναρίων χωρίς γεγονότα και αναπηρία κρυφής μνήμης.

13) Περιπτώσεις και συνταγές

13. 1 Κάλυψη σε επίπεδο πεδίου:


allow read invoice when subject. roles includes "support"
mask fields ["card_last4", "billing_email"] unless subject. role == "finance"

13. 2 Δεδομένα εξαγωγής μόνο με ΜΧΣ:


allow export if subject. mfa_verified and env. ip in cidr("203. 0. 113. 0/24")

13. 3 SoD:


deny approve_payment if subject. performed_actions includes ("create_payment" within last 24h)

13. 4 Αντιπροσωπεία (περιορισμένη μάρκα):

Το σύμβολο ικανότητας περιέχει' resource _ i ,' actions = [» read»] ',' explines _ at ',' aud '. Το PEP επαληθεύει την υπογραφή και την προθεσμία.

14) Δοκιμές

Μοναδιαίες δοκιμές των πολιτικών: πίνακες αλήθειας με μείζονες συνδυασμούς.
Με βάση την ιδιότητα: δημιουργία τυχαίων χαρακτηριστικών για την εύρεση «οπών».
Χρυσές δοκιμές: καθορισμός σειράς λύσεων για κρίσιμα τελικά σημεία.
Κανάριος/Σκιά: παράλληλη αξιολόγηση παλαιών και νέων μορφών πολιτικών με καταγραφή των διαφορών.

15) Συναφείς ικανότητες του τμήματος «Αρχιτεκτονική και πρωτόκολλα»

Ταυτοποίηση και εξουσιοδότηση (OIDC/OAuth2)

Διαχείριση της συναίνεσης

Δημιουργία σημάτων και διαχείριση κλειδιών

Παρατηρησιμότητα: κούτσουρα, μετρήσεις, ίχνη

Γεω-δρομολόγηση και εντοπισμός

Κρυπτογράφηση ανάπαυσης/διαμετακόμισης

16) Κατάλογος ελέγχου αρχιτεκτόνων

1. Ορίζονται οι ρόλοι των υποκειμένων και οι ιεραρχίες τους

2. Υπάρχει υβριδικό μοντέλο: ρόλοι + προϋποθέσεις για χαρακτηριστικά

3. Εφαρμογή PDP με αρνητικές παραβάσεις, SoD και κλιμάκωση

4. Πού είναι το PEP (πύλη, υποστήριξη, βάση δεδομένων, UI) - είναι ομοιόμορφη παντού

5. Ρυθμίζονται οι κρύπτες λύσης και η αναπηρία γεγονότων

6. Οι πολιτικές καθορίζονται, ελέγχονται, αναπτύσσονται ανά διαδικασία

7. Ενεργοποιούνται οι αποφάσεις ελέγχου, οι μετρήσεις και τα ίχνη

8. Υποστηριζόμενη πολλαπλή μίσθωση και RLS/κάλυψη πεδίου

9. Έχεις ένα βιβλίο για τα περιστατικά και την πολιτική οπισθοδρόμηση

Συμπέρασμα

Η RBAC παρέχει δυνατότητα ελέγχου, η ABAC παρέχει πλαίσιο και ακρίβεια. Συνδυάζοντας ρόλους με όρους χαρακτηριστικών, μοιράζοντας PDP/PEP, εφαρμόζοντας κρυπτογράφηση, έλεγχο και δοκιμές πολιτικής, δημιουργείτε εξουσιοδότηση ως δυνατότητα πλατφόρμας: προβλέψιμη, επαληθεύσιμη και κλιμακωτή για τις απαιτήσεις προϊόντων και κανονιστικών ρυθμίσεων.

Contact

Επικοινωνήστε μαζί μας

Επικοινωνήστε για οποιαδήποτε βοήθεια ή πληροφορία.Είμαστε πάντα στη διάθεσή σας.

Telegram
@Gamble_GC
Έναρξη ολοκλήρωσης

Το Email είναι υποχρεωτικό. Telegram ή WhatsApp — προαιρετικά.

Το όνομά σας προαιρετικό
Email προαιρετικό
Θέμα προαιρετικό
Μήνυμα προαιρετικό
Telegram προαιρετικό
@
Αν εισαγάγετε Telegram — θα απαντήσουμε και εκεί.
WhatsApp προαιρετικό
Μορφή: κωδικός χώρας + αριθμός (π.χ. +30XXXXXXXXX).

Πατώντας «Αποστολή» συμφωνείτε με την επεξεργασία δεδομένων.