Επαλήθευση ταυτότητας και εξουσιοδότηση

Ο αξιόπιστος βρόχος AuthN/AuthZ είναι ένα μόνο σημείο αλήθειας για το ποιος είστε (επαλήθευση ταυτότητας) και τι επιτρέπεται να κάνετε (εξουσιοδότηση). Σε μια πλατφόρμα με πολλά εμπορικά σήματα, περιφέρειες, ενοποιήσεις και υψηλές κανονιστικές απαιτήσεις, το περίγραμμα αυτό θα πρέπει να είναι αρθρωτό, να παρακολουθείται και να διοικείται από πολιτικούς και όχι «διασπορά των ΕΟ ανά υπηρεσία».

1) Βασικοί όροι και ρόλοι

Ταυτοποίηση (ID): ταυτοποίηση (χρήστης, υπηρεσία, πάροχος).
Ταυτοποίηση (AuthN): απόδειξη ταυτότητας (κωδικός πρόσβασης, MFA, πιστοποιητικό).
Η εξουσιοδότηση (AuthZ) -Πολική και βασισμένη στο πλαίσιο μπορεί/δεν μπορεί να αποφασίσει.
PDP/PEP: Σημείο απόφασης πολιτικής/σημείο επιβολής πολιτικής.
IdP: Πάροχος ταυτότητας (OIDC).
Θέμα/Πόροι/Δράση/Πλαίσιο: ποιος/τι/τι κάνει/υπό ποιες συνθήκες.

2) Αρχιτεκτονική συνολικού βρόχου

[ IdP (OIDC) ]
│ OIDC/OAuth 2. 1 (PKCE, JAR/JARM)

[ Token Service / JWKS / KMS ]
│klyuchi (rotate)
│ JWT/Access/Refresh, mTLS

[API Gateway (PEP)] Solution/Policy ──kesh
│ authN/CSRF/CORS/rate-limit

[ Microservices (PEP)]──PDP (OPA/cedar) ──Policy Store (GitOps)
│audit/metriki

[ Data/Providers ]── service-to-service (mTLS+JWT/Spiffe)

Αρχές: συγκέντρωση της δημιουργίας σημάτων και πολιτικών, τοπική εφαρμογή· «ελάχιστα προνόμια» και σαφείς αντιπροσωπείες.

3) Επαλήθευση ταυτότητας χρήστη (OIDC/OAuth 2. 1)

• Κωδικός αδειοδότησης + PKCE (πάντα για SPA/Mobile).
• SSO: εξωτερική υποστήριξη IdP (SAML/OIDC) για b2b/χειριστές.
• TOTP/WebAuthn/SMS (συνιστάται WebAuthn και TOTP) SMS - εφεδρική).
• Για ευαίσθητες δράσεις (απόσυρση κεφαλαίων, αλλαγή λεπτομερειών) απαιτείται ΜΧΣ/pe-Auth.

• Ανανέωση μητρώου περιστροφής Token + RT με ανίχνευση επαναχρησιμοποίησης.
• Nonce/State + PKCE, αυστηρή CORS/CSRF για ροές περιηγητή.
• Μάρκες βραχύβιας πρόσβασης (5-15 мин) + σιωπηλή ανανέωση/RT.
• Συνδέσεις συσκευών (DPoP/mtls-δεσμευμένες μάρκες) για κρίσιμες λειτουργίες.

json
{
"iss": "https://auth. example. com",
"sub": "user_9f12",
"aud": ["wallet","catalog"],
"exp": 1730385600,
"iat": 1730384700,
"tenant": "brand_eu",
"region": "EE",
"amr": ["pwd, ""webauthn"] ,//authentication methods
"scp": ["wallet:read","bets:place","kyc:status. read"],
"sid": "sess_a1b2c3",      // session id
"acr": "urn: mfa: strong "//warranty level
}

4) Εξακρίβωση ταυτότητας υπηρεσίας (mTLS, SPIFFE, JWT)

mTLS μεταξύ υπηρεσιών + SPIFFE/SPIRE για αναγνωριστικά σταθερού φόρτου εργασίας.
Υπηρεσία JWT με σύντομο χρονικό διάστημα (≤5 λεπτά), υπογεγραμμένη από την HSM/KMS· τον έλεγχο της έκδοσης.
Οπτικό πεδίο: Η JWT είναι κατάλληλη μόνο για συγκεκριμένη υπηρεσία/τομέα.
Ζώνες εμπιστοσύνης: υπηρεσίες από άλλη περιφέρεια/ενοικιαστή - χωριστές ΕΚΕ και πολιτικές.

5) Υποδείγματα αδειοδότησης: RBAC, ABAC, ReBAC

RBAC (ρόλοι → άδειες): απλό και διαφανές (κατάλληλο για διαφημιστικά πάνελ, χειριστές).

ABAC (θέμα/πόρος/χαρακτηριστικά του πλαισίου): ευέλικτη για "ενοικιαστής =... ΚΑΙ περιοχή =... ΚΑΙ kyc_tier≥2"

ReBAC (σχέσεις): Χρήσιμο για πολύπλοκες συμμετοχές («που κατέχει εμπορικό σήμα/φάκελο/εκστρατεία»).

Σύσταση: υβριδικό - βασικό RBAC + πλαίσιο ABAC προϋποθέσεις + σημείο σχέσεις ReBAC.

6) Πολιτικές και επιβολή (PDP/PEP)

PEP για την πύλη και τις υπηρεσίες: ανακτά το πλαίσιο (JWT, εισιτήρια, IP/ASN, χρόνος, περιοχή, επίπεδο KYC), υποβάλλει αίτημα στο PDP.

json
{
"subject": { "sub":"user_9f12", "roles":["support"], "kyc":2, "tenant":"brand_eu" },
"action": "bets. place",
"resource": { "game_id":"g_42", "provider":"pr_x" },
"context": { "region":"EE", "ip_asn":"AS12345", "time":"2025-10-31T12:34:56Z" }
}

και επιστρέφει 'ABLE/DENY' + εξήγηση.

Η μνήμη διαλύματος PEP (TTL 30-120 c) μειώνει την καθυστέρηση· αναπηρία με εκδηλώσεις «αλλαγής ρόλου/πολιτικής».

rego package bets

default allow = false

allow {
input. action == "bets. place"
input. subject. kyc >= 2 input. subject. tenant == input. context. tenant not blocked_region within_limits
}

blocked_region { input. context. region == "NL" }
within_limits { input. context. bet_amount <= data. limits. max_bet[input. subject. tenant] }

7) Πεδία εφαρμογής και ψηφίσματα

• Πόρος: δράση - 'πορτοφόλι: ανάγνωση', 'πορτοφόλι: μεταφορά', 'στοιχήματα: θέση', 'kyc: κατάσταση. διάβασε '.
• Για τους διαχειριστές - 'admin:' σε ένα αυτόνομο πεδίο.
• Για τους παρόχους - "πάροχος: αναφορά. διάβασε «,» πάροχος: εκδηλώσεις. ώθηση '.

Η αρχή των ελάχιστων προνομίων: αναθέτουμε μόνο τα απαραίτητα πεδία εφαρμογής. «κλιμάκωση» (προσωρινές επεκτάσεις δικαιωμάτων) - με εισιτήριο και με TTL.

8) Πολυπληθείς και περιφέρειες (κατοικία)

Οι μάρκες περιέχουν «ενοικιαστή», «περιφέρεια», «άδεια». Το PDP ελέγχει την αλληλογραφία με τον πόρο.
Ρόλοι/πολιτικές - χώροι ονομάτων ανά ενοικιαστή («ρόλος: brand _ eu/support»).
Διαχωρισμός των κλειδιών υπογραφής και των καταλόγων ανάκλησης ανά περιφέρεια. διαπεριφερειακά αιτήματα - μόνο μέσω αξιόπιστων πυλών.

9) Συνεδρίαση και διαχείριση συσκευών

Αποθήκευση συνεδρίας Server-side για ιστό (σύνδεση συσκευής/περιηγητή, περιστροφή αναγνωριστικού).
Βραδυπορία/Απόλυτο χρονοδιάγραμμα (π.χ. 30 λεπτά/24 ώρες), ευαίσθητες δράσεις - εκ νέου Auth/MAX.
Κατάλογος ενεργών συσκευών, «έξοδος από όλους».
Ανωμαλίες: ταυτόχρονες εισροές από διαφορετικές περιοχές, συχνές βουτιές ΜΧΣ - σήματα κινδύνου.

10) Ανάθεση και συναίνεση (συναίνεση)

Για λογαριασμό του (OBO): η υπηρεσία ενεργεί εξ ονόματος του χρήστη (σύμβολο πληρεξουσίου με χωριστό «επιμέρους »/« πράξη»).
Συγκατάθεση: ρητή οθόνη για την πρόσβαση των εταίρων στα δεδομένα, καταγραφή της συγκατάθεσης με ανάκληση.
Προσωρινές εντολές πρόσβασης: τα δικαιώματα για N ώρες/ημέρες λήγουν αυτόματα.

11) Κλειδιά, υπογραφές και εναλλαγή

JWKS με «παιδί», αυτόματη περιστροφή, αποθήκευση ιδιωτικών κλειδιών σε KMS/HSM.
Αλγόριθμοι: ES256/EdDSA για JWT. TLS 1. 2 +/mTLS.
Περίοδος διπλού κλειδιού: Αποδοχή και των δύο 'kids' πριν ολοκληρωθεί η αναβάθμιση του πελάτη.
Το RT και το Token Introspection υπενθυμίζουν κρίσιμα περιστατικά.

12) Ασφάλεια εφαρμογών πελάτη

SPA: Κωδικός αδείας + PKCE, όχι «έμμεσος», строгий CORS/Content-Security-Policy.
Κινητό: Έλεγχος βεβαίωσης/συσκευής App, ασφαλής αποθήκευση RT, προστασία ρίζας/jailbreak.
Επιτραπέζιος υπολογιστής: φυλλομετρητής συστήματος για σύνδεση (χωρίς ενσωματωμένες web-views), PKCE.

13) Βολικές συμβάσεις SDK

http
POST /authz/evaluate
Authorization: Bearer <access_jwt>
Body: { "action":"bets. place", "resource":{"game_id":"g_42"}, "context":{"bet_amount":5. 0} }
→ 200 { "decision":"ALLOW", "ttlMs":60000, "explain":"kyc>=2, limit ok" }

http
POST /oauth/token grant_type=urn:ietf:params:oauth:grant-type:token-exchange subject_token=<user_jwt>&actor_token=<service_jwt>&audience=wallet

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

• 'authn _ success _ rate '/' mfa _ challenge _ rate '/' mfa _ fail _ rate'
• 'authz _ p95 _ m ,' authz _ return _ rate {reason} '
• 'invalid _ token _ rate', 'jwks _ skew _ m ,' rt _ reuse _ dicted '
• Ανωμαλίες εισόδου (νέα συσκευή, γεω-ταχύτητα), ύποπτα πεδία.

• "who/what/when/where/why", "decision", "policy _ version", "token _ kid", "client _ i .
• Εξαγωγή για συμμόρφωση (ρυθμιστική αρχή/έλεγχος πωλητή).

15) Περίμετρος και προστασία των πελατών

Πύλη PEP: οριακές τιμές, έλεγχοι bot/υπογραφή, προστασία CSRF, αυστηρή CORS, HSTS.
Εσωτερική κυκλοφορία: mTLS + υπηρεσία JWT + περιορισμένα δίκτυα.
Webhooks/εξωτερικές collbacks: υπογραφές σώματος (HMAC/JWS), παράθυρα χρόνου, αντι-αναπαραγωγή.

16) Τυπικά σφάλματα

Μακρόβια σημεία πρόσβασης → διαρροές.
Έμμεση ροή OAuth στη ΖΕΠ.
Καμία βασική εναλλαγή και περίοδος διπλής κλείδας.
Ιδιαίτερης σοβαρότητας ρόλοι αντί πολιτικών (είναι αδύνατο να ελεγχθούν/εξηγηθούν οι αποφάσεις).
Ανάμειξη ενοικιαστών/περιφερειών σε ένα «ρολό» ή «κλειδί».
Καμία ενισχυμένη ΜΧΣ για ευαίσθητες δράσεις.
Αυτόματες λύσεις cache χωρίς αναπηρία αλλαγής ρόλων.

17) Playbooks (runbooks)

1. Βασικός συμβιβασμός υπογραφής JWT

Άμεση ανάκληση του «παιδιού», δημοσίευση του νέου JWKS, αναγκαστική αναπηρία RT/συνεδριών, έκθεση ελέγχου.

2. Χύμα 'invalid _ token'

Ελέγξτε για τη μη ευθυγράμμιση/διάρκεια ζωής του ρολογιού, τη συνάφεια JWKS, τις καταρρεύσεις μνήμης.

3. Ανωμαλίες εισόδου

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

4. Αποτυχία IdP

Μετάβαση στην κρύπτη/συσκευή ρόλων συνεδρίας, περιορισμός νέων συνδέσμων, διατήρηση ενεργών συνεδριών σε TTL.

18) Κατάλογος ελέγχου πριν από την πώληση

• OIDC/OAuth 2. 1 με PKCE, σύντομη περιστροφή AT, RT, διάταξη σύνδεσης για κρίσιμες λειτουργίες.
• ΜΧΣ (WebAuthn/TOTP) και κλιμάκωση για την παραγωγή/αλλαγή λεπτομερειών/κλιμακώσεων ρόλων.
• Υπηρεσία προς υπηρεσία: mTLS + SPIFFE, βραχύβια υπηρεσία JWT.
• Πολιτικές Authz (RBAC + ABAC/ReBAC) στο κεντρικό PDP. PEP σχετικά με την πύλη και τις υπηρεσίες.
• Λύσεις αναπηρίας Cache αμετάβλητη διαδρομή ελέγχου.
• Πολυπληθείς/περιφέρειες: απομόνωση κλειδιού/πολιτικής/ημερολογίου, λογιστική αδειοδότησης.
• JWKS/κλειδιά σε KMS/HSM, περιστροφή διπλού κλειδιού, παρακολούθηση 'kid'.
• Φίλτρα CSRF/CORS/HSTS/Όριο ταχύτητας/bot στην περίμετρο.
• Βιβλία παιχνιδιών περιστατικών, ανάκληση/περιστροφή/κλείδωμα τρέχει κουμπιά.
• Δοκιμαστική σουίτα: μονάδα (πολιτικές), σύμβαση (SDK/ροές), χάος (IdP, JWKS), e2e (κλιμάκωση, OBO, ανάκληση).

19) Υποδείγματα ελάχιστων ρυθμίσεων

yaml scopes:
wallet: read: {desc: "Reading balance"}
wallet: transfer: {desc: "Transfer of funds," sensitive: true, step_up: true}
bets: place: {desc: "Bet"}
kyc:status. read: {desc: "KYC status"}
roles:
support:
allow: [wallet:read, kyc:status. read]
finance:
allow: [wallet:read, wallet:transfer]
player:
allow: [bets:place]

yaml deny:
- when: { region: ["NL","BE"] }
actions: ["bets."]

Συμπέρασμα

Ο βρόχος επαλήθευσης και αδειοδότησης δεν είναι βιβλιοθήκη, αλλά μια δυνατότητα πλατφόρμας: βραχύβια μαρκέ και διαχειριζόμενα κλειδιά, κεντρικές πολιτικές και την τοπική εφαρμογή τους, πολυπαραγοντική και κλιμακωτή, αυστηρή απομόνωση των ενοικιαστών/περιοχών, έλεγχος και τηλεμετρία. Αυτός ο σχεδιασμός καθιστά τις αλλαγές ασφαλείς, εξηγήσιμες στον ρυθμιστή και διαφανείς στο προϊόν - και η κλιμάκωση ανά αγορά και εντολή γίνεται μια συνήθης λειτουργία, όχι ένα κατόρθωμα.