Gestionarea identității și a accesului

Scurt rezumat

IAM este o colecție de procese, politici și instrumente care oferă cine are acces la ce, în ce condiții și cum este controlat. Obiective: minimizarea drepturilor redundante, reducerea suprafeței de atac, accelerarea onboardingului și a auditului, conformitatea (PCI DSS, GDPR etc.) și fiabilitatea măsurabilă a accesului.

Concepte de bază

Identitate: persoana (angajat, contractant), serviciu/aplicatie, dispozitiv.
Autentificare (AuthN): cine verifică (parola → MFA → scheme de FIDO2/passkeys fără parolă).
Autorizare (AuthZ): decizie „ce este permis” (RBAC/ABAC/ReBAC, politici).
Acreditări: parole, chei, jetoane, certificate (mTLS).
Managementul secret: KMS/HSM/Vault, rotații, TTL scurt, secrete dinamice.
Ciclul de viață: Joiner-Mover-Leaver (JML) - creați, schimbați rolurile, rechemați.

Arhitectura țintă IAM

Avioane și roluri:

IdP (furnizor de identitate): SSO, MFA, director, federație (OIDC/SAML), politici de risc.
PDP/PEP: Decizie/Executare - motor de politică (OPA/Cedar) + puncte de aplicare (gateway-uri API, proxy-uri, plasă de serviciu).
Cataloage/HR System: Sursa adevărului de către angajat și rol
Provizionare: SCIM/Automatizare pentru crearea/modificarea/revocarea acceselor.
Audit: jurnale centralizate, UEBA, rapoarte de rol și acces.

Fluxul de acces (user→app):

SSO (+ MFA) → problemă token (OIDC/JWT/SAML) → PEP verifică token/context → PDP decide cu privire la politica (rol/atribute/risc) → problemele aplicației/refuză accesul.

Autentificare: de la parole la parole

Parole: numai cu managerii de parole, cel puțin 12-14 caractere, fără rotație „conform calendarului”, dar cu obligatoriu în cazul unui incident.
MFA implicit: TOTP/WebAuthn/Push; evitați SMS-urile ca factor major.
Conectare fără parolă: FIDO2/passkeys pentru domenii critice.
Adaptive AuthN: Luați în considerare semnalul de risc (geo, ASN, dispozitiv, anomalii) → necesită factor/bloc suplimentar.

Autorizatie: RBAC, ABAC, ReBAC

RBAC: roluri corespunzătoare funcțiilor (Suport, Finanțe, DevOps). Simplu și ușor de înțeles, dar „în creștere”.
ABAC: reguli privind atributele (departament, nivel de risc, timp, fus orar, etichete de resurse). Scalabil.
ReBAC: „cine aparține ce” relații (proprietari de proiect, membri ai echipei). Convenabil pentru scenarii multi-chiriaș.

Cele mai bune practici:

Combină RBAC (grila de bază) + ABAC/ReBAC (context/limite).
JIT (Just-In-Time): emiterea de privilegii temporare prin cerere/aplicație, revocarea automată.
JEA (Just-Enough Access): Drepturi minime suficiente pentru operațiune.
PAM: accesări izolate „puternice” (administratori DB/cloud) cu broker de sesiune, înregistrare ecran/comandă și emiterea de credite de scurtă durată.

Federația și SSO

Protocoale: OIDC (jetoane JWT), SAML 2. 0 (afirmații XML) - pentru furnizori/parteneri externi.
SSO: un singur punct de intrare cu MFA, reducerea phishing, rechemare centralizată.
B2B/B2C: federație cu parteneri, restricție de domeniu, politici bazate pe domenii.
mTLS/m2m: pentru servicii, utilizați x.509 de scurtă durată (SPIFFE/SVID) sau OAuth2 acreditările clienților.

Ciclul de viață (JML) și provizionare

Joiner: aprovizionarea automată SCIM a conturilor și rolurilor de bază din HR/director.
Mover: rolurile se schimbă automat după atribute (departament, proiect, locație).
Leaver: rechemare imediată a SSO-urilor, cheilor, jetoanelor, depozitului/cloud/CI/CD access.
Procese: cereri de acces (ITSM), matrice SoD (împărțirea taxelor), revizuirea periodică a accesului.

Secrete, chei și rotații

KMS/HSM: Stocați tastele rădăcină/critice, activați auditul operațiunii.
Managerii Vault/Secrets: credite dinamice (DB, nori), auto-revok la finalizarea TTL.
Rotații: token-uri OAuth, chei de semnare JWT, parole de serviciu - la program și în caz de incidente.
mTLS: certificate de scurtă durată (ore/zile), reemitere automată.

Politici și motor de soluție

Declarativitate: Politica de stocare în Git; check in CI (teste de politică).
Context: timp/locație/ASN/nivel de risc/starea dispozitivului (MDM/EDR).

Exemplu (Rego, simplificat):

rego package authz. payments default allow = false

allow {
input. user. role == "finance"
input. device. compliant == true input. action == "read"
input. resource. type == "report"
time. now_hh >= 8 time. now_hh <= 20
}

Monitorizare, SLO și audit

Măsurători:

Succesul AuthN/AuthZ (%), timpul de conectare/decizie p95, cota de intrări MFA/fără parole.
Numărul de escaladări JIT/PAM, durata medie a privilegiului.
Acoperirea dispozitivelor conforme, cota de secrete de scurtă durată.

SLO (exemple):

Disponibilitatea SSO/IdP ≥ 99. 95% pe lună.
Decizia p95 AuthZ ≤ 50 мс.
100% închiderea contului ≤ 15 minute după offboarding.
Audit și UEBA: jurnale imuabile centralizate (accesări, modificări de rol, intrări eșuate, soluții PDP), analize comportamentale și alarme de anomalie.

Incident-răspuns în IAM

Compromiterea jetoanelor/cheilor: revocarea imediată, deconectarea forțată, rotirea cheilor de semnătură, reemiterea secretelor de scurtă durată.
Abuzul de drepturi: suspendarea contului, blocarea JIT/JEA, efectuarea unei revizuiri a accesului entităților vecine.
IdP nu este disponibil: moduri offline (validarea temporară a jetoanelor cu TTL scurt), proceduri de recuperare prioritară.
Phishing: MAE obligatoriu, controale de risc ale sesiunilor, notificări către utilizatori, instruire.

Nori și Kuberneți (modele)

Public Cloud IAM: utilizați roluri native cu cel mai mic privilegiu; în loc de chei „eterne” - sarcini de lucru cu federația OIDC în cloud (IRSA/Workload Identity).
Kubernetes: RBAC după neimspaces/roluri, limită 'cluster-admin'; secrete - prin intermediul managerilor externi; plasă de serviciu + OPA pentru politicile L7; Controlori de admitere (imagini semnate, interdicție „: cele mai recente”).
Gateway-uri API: verificarea JWT/mTLS, limitele ratei, semnături de cerere (HMAC) pentru obiective sensibile.

Practică pentru iGaming/fintech

Domenii de acces: plăți, anti-fraudă, PII, furnizori de conținut - izolați cu roluri și segmente de rețea.
SoD: Nu combinați roluri contradictorii (de ex. creați plăți promo + aproba).
PAM și JIT: pentru acces la PSP/bănci și prod-DB - numai printr-un broker de sesiune, cu înregistrare și auto-rechemare.
Conformitate: PCI DSS - MFA, privilegii minime, segmentarea zonei CHD; GDPR - principiul de minimizare a datelor și jurnalele de puncte de acces la PII.
Parteneri și furnizori de conținut: politici federative și per-chiriaș; jetoane cu durată scurtă de viață și lista permisă IP/ASN.

Erori comune

Cheile și jetoanele „eterne”: nu există rotații și TTL → un risc ridicat de scurgeri.
Offboarding manual: întârzieri în revocarea drepturilor → acces „fantomatic”.
Roluri monolit: un „rol super” în loc de compoziție și atribute.
MAE numai în panoul de administrare: MAE ar trebui să fie pentru toate intrările și operațiunile critice.
Jurnalele „nicăieri”: nu există centralizare și UEBA → detectarea ulterioară a incidentelor.

Foaie de parcurs pentru implementarea IAM

1. Inventarierea utilizatorilor/serviciilor/resurselor; harta datelor și a sensibilității.
2. SSO + MFA pentru toți, includ factori rezistenți la phishing.
3. Model de rol: atribute de bază RBAC + (ABAC) pentru context; Matricea SoD.
4. Provizionare SCIM: auto-creare/schimbare/revocare drepturi din HR/catalog; aplicații și actualizări în ITSM.
5. PAM și JIT/JEA: pentru accesele privilegiate; sesiuni de înregistrare, TTL-uri scurte.
6. Managementul secret: respingerea cheilor statice; secrete dinamice, rotații, mTLS cu certificate scurte.
7. Politici în Git + CI: teste de regulă, controlul schimbării, implementări de politici canare.
8. Observabilitate și SLO: tablouri de bord AuthN/AuthZ, alerte, revizuire regulată a accesului.

Exemple de artefacte

Politica AWS IAM (minim pentru citirea rapoartelor S3)

json
{
"Version": "2012-10-17",
"Statement": [{
"Sid": "ReadOnlyReports",
"Effect": "Allow",
"Action": ["s3:GetObject","s3:ListBucket"],
"Resource": [
"arn:aws:s3:::reports-bucket",
"arn:aws:s3:::reports-bucket/"
],
"Condition": {
"IpAddress": { "aws:SourceIp": "203. 0. 113. 0/24" }
}
}]
}

Kubernetes RBAC (namespace-scoped developer)

yaml apiVersion: rbac. authorization. k8s. io/v1 kind: Role metadata:
name: dev-read-write namespace: app-prod rules:
- apiGroups: ["","apps"]
resources: ["pods","deployments","services","configmaps"]
verbs: ["get","list","watch","create","update","patch","delete"]
apiVersion: rbac. authorization. k8s. io/v1 kind: RoleBinding metadata:
name: dev-bind namespace: app-prod subjects:
- kind: User name: alice@example. com roleRef:
kind: Role name: dev-read-write apiGroup: rbac. authorization. k8s. io

OIDC: aprobări pentru ABAC (exemplu)

json
{
"sub": "d81f0b5c-...",
"email": "bob@example. com",
"dept": "finance",
"role": "analyst",
"device_compliant": true,
"tenant": "casino-eu"
}

Politica poate necesita 'device _ compiant = true' și 'chiriaș' pentru a se potrivi resursei.

Check-list

SSO este activat pentru toate aplicațiile; MFA în mod implicit, cheile de acces în prioritate.
RBAC definit; ABAC/ReBAC adaugă context; implementat de JIT/JEA.
PAM protejează accesele privilegiate; se înregistrează sesiuni.
provizionarea SCIM din HR; offboarding-ul este complet automatizat.
Secretele sunt dinamice, cu un TTL scurt; rotațiile sunt automatizate.
Politicile sunt versionate în Git, testate în CI; există calcule canare.
Tablouri de bord și SLO în conformitate cu AuthN/AuthZ; jurnale centralizate și UEBA.
Revizuirea periodică a accesului și verificările SoD; rapoarte de conformitate.

ÎNTREBĂRI FRECVENTE

ReBAC are nevoie de toată lumea?
Nu, nu este. RBAC + ABAC este suficient pentru medii simple. ReBAC este util într-o ierarhie complexă de proprietate a resurselor și multi-chirie.

Pot lăsa conturile locale?
Numai pentru scenarii de spargere și offline, cu restricții stricte și verificare periodică.

Cum de a reduce „explozia rolurilor”?
Creșteți granularitatea resurselor, utilizați ABAC/șabloane, automatizați recenziile și eliminați rolurile neutilizate.

Total

Arhitectura IAM matură este SSO + MFA, drepturile minime necesare, JML automatizat, politici centralizate și observabilitate. Combinând RBAC cu modele de atribute și relaționale, aplicând JIT/JEA și PAM și automatizând provizionarea și rotațiile secrete, obțineți un acces gestionat, auditabil și scalabil care îndeplinește cerințele de securitate și de afaceri.