Identity & Access Management

Brief Summary

IAM is a collection of processes, policies and tools that provide who gets access to what, under what conditions and how it is controlled. Objectives: minimization of redundant rights, reduction of attack surface, acceleration of onboarding and auditing, compliance (PCI DSS, GDPR, etc.) and measurable access reliability.

Basic concepts

Identity: person (employee, contractor), service/application, device.
Authentication (AuthN): who checks (password → MFA → password-free FIDO2/passkeys schemes).
Authorization (AuthZ): decision "what is allowed" (RBAC/ABAC/ReBAC, policies).
Credentials: passwords, keys, tokens, certificates (mTLS).
Secret management: KMS/HSM/Vault, rotations, short TTL, dynamic secrets.
Life cycle: Joiner-Mover-Leaver (JML) - create, change roles, recall.

Target IAM Architecture

Planes and roles:

IdP (identity provider): SSO, MFA, directory, federation (OIDC/SAML), risk policies.
PDP/PEP: Decision/Enforcement - policy engine (OPA/Cedar) + application points (API gateways, proxies, service mesh).
Catalogs/HR System: Source of Truth by Employee and Role
Provisioning: SCIM/Automation to create/modify/revoke accesses.
Audit: centralized logs, UEBA, role and access reports.

Access Flow (user→app):

SSO (+ MFA) → token issue (OIDC/JWT/SAML) → PEP checks the token/context → PDP decides on policy (role/attributes/risk) → the application issues/denies access.

Authentication: from passwords to passkeys

Passwords: only with password managers, at least 12-14 characters, without rotation "according to the calendar," but with mandatory in case of an incident.
Default MFA: TOTP/WebAuthn/Push; avoid SMS as a major factor.
Password-free login: FIDO2/passkeys for critical domains.
Adaptive AuthN: Consider risk signal (geo, ASN, device, anomalies) → require additional factor/block.

Authorization: RBAC, ABAC, ReBAC

RBAC: roles corresponding to functions (Support, Finance, DevOps). Simple and understandable, but "growing."

ABAC: rules on attributes (department, risk level, time, zone, resource labels). Scalable.
ReBAC: "who belongs to what" relationships (project owners, team members). Convenient for multi-tenant scenarios.

Best practices:

Combine RBAC (base grid) + ABAC/ReBAC (context/bounds).
JIT (Just-In-Time): issuance of temporary privileges via request/app, automatic revocation.
JEA (Just-Enough Access): Minimum sufficient rights for the operation.
PAM: isolated "strong" accesses (DB/cloud admins) with session broker, screen/command recording and issuing short-lived credits.

Federation and SSO

Protocols: OIDC (JWT tokens), SAML 2. 0 (XML assertions) - for external providers/partners.
SSO: single point of entry with MFA, phishing reduction, centralized recall.
B2B/B2C: federation with partners, domain restriction, domain-based policies.
mTLS/m2m: for services, use short-lived x.509 (SPIFFE/SVID) or OAuth2 Client Credentials.

Life Cycle (JML) and Provisioning

Joiner: automatic SCIM provisioning of accounts and basic roles from HR/directory.
Mover: roles change automatically by attributes (department, project, location).
Leaver: immediate recall of SSOs, keys, tokens, repository/cloud/CI/CD accesses.
Processes: access requests (ITSM), SoD matrix (division of duties), periodic access review.

Secrets, keys and rotations

KMS/HSM: Store root/critical keys, enable operation auditing.
Vault/Secrets managers: dynamic credits (DB, clouds), auto-revok at TTL completion.
Rotations: OAuth tokens, JWT signing keys, service passwords - on schedule and in case of incidents.
mTLS: short-lived certificates (hours/days), automatic reissue.

Policies and solution engine

Declarativeness: Store policies in Git; check in CI (policy-tests).
Context: time/location/ASN/risk level/device status (MDM/EDR).

Example (Rego, simplified):

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
}

Monitoring, SLO and auditing

Metrics:

Success of AuthN/AuthZ (%), p95 login/decision time, share of MFA/password-free inputs.
Number of JIT/PAM escalations, average privilege duration.
Coverage of compliant devices, share of short-lived secrets.

SLO (examples):

Availability of SSO/IdP ≥ 99. 95% per month.
p95 AuthZ decision ≤ 50 мс.
100% shutdown of the account ≤ 15 minutes after offboarding.
Audit and UEBA: centralized immutable logs (accesses, role changes, failed inputs, PDP solutions), behavioral analytics, and anomaly alarms.

Incident-response in IAM

Compromise of tokens/keys: immediate revocation, forced logout, rotation of signature keys, re-issue of short-lived secrets.
Abuse of rights: suspend the account, block the JIT/JEA, conduct an access review of neighboring entities.
IdP is not available: offline modes (temporary cache validation of tokens with short TTL), priority recovery procedures.
Phishing: mandatory MFA, risk checks of sessions, notifications to users, training.

Clouds and Kubernetes (patterns)

Public Cloud IAM: use native roles with least privilege; instead of "eternal" keys - workloads with OIDC federation to the cloud (IRSA/Workload Identity).
Kubernetes: RBAC by neimspaces/roles, limit 'cluster-admin'; secrets - through external managers; service mesh + OPA for L7 policies; Admission controllers (signed images, prohibition ": latest").
API gateways: checking JWT/mTLS, rate limits, request signatures (HMAC) for sensitive endpoints.

Practice for iGaming/fintech

Access domains: payments, anti-fraud, PII, content providers - isolate with roles and network segments.
SoD: Do not combine conflicting roles (e.g. create promo + approve payments).
PAM and JIT: for access to PSP/banks and prod-DB - only through a session broker, with recording and auto-recall.
Compliance: PCI DSS - MFA, minimum privileges, CHD zone segmentation; GDPR - the principle of data minimization and point logs of access to PII.
Partners and content providers: federation and per-tenant policies; short-lived tokens and IP/ASN allow-list.

Common errors

"Eternal" keys and tokens: there are no rotations and TTL → a high risk of leaks.
Manual offboarding: delays in revocation of rights → "ghostly" access.
Monolith roles: one "super role" instead of composition and attributes.
MFA only in the admin panel: MFA should be for all inputs and critical operations.
Logs "to nowhere": there is no centralization and UEBA → later detection of incidents.

IAM Implementation Roadmap

1. Inventory of users/services/resources; data and sensitivity map.
2. SSO + MFA for all, include phishing-resistant factors.
3. Role model: basic RBAC + attributes (ABAC) for context; SoD matrix.
4. SCIM provisioning: auto-creation/change/revocation of rights from HR/catalog; applications and updates in ITSM.
5. PAM and JIT/JEA: for privileged accesses; recording sessions, short TTLs.
6. Secret management: rejection of static keys; dynamic secrets, rotations, mTLS with short certificates.
7. Policies in Git + CI: rule tests, change control, canary policy deployments.
8. Observability and SLO: AuthN/AuthZ dashboards, alerts, regular access review.

Examples of artifacts

AWS IAM Policy (minimum for reading S3 reports)

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: approvals for ABAC (example)

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

The policy may require 'device _ compliant = true' and 'tenant' to match the resource.

Check-list

SSO is enabled for all applications; MFA by default, passkeys in priority.
RBAC defined; ABAC/ReBAC add context; implemented by JIT/JEA.
PAM protects privileged accesses; sessions are being recorded.
SCIM provisioning from HR; offboarding is fully automated.
Secrets are dynamic, with a short TTL; rotations are automated.
Policies are versioned in Git, tested in CI; there are canary calculations.
Dashboards and SLO according to AuthN/AuthZ; centralized logs and UEBA.
Periodic access review and SoD checks; reports for compliance.

FAQ

Does ReBAC need everyone?
No, it isn't. RBAC + ABAC is sufficient for simple environments. ReBAC is useful in a complex hierarchy of resource ownership and multi-tenancy.

Can I leave local accounts?
Only for break-glass and offline scenarios, with strict restrictions and periodic verification.

How to reduce the "explosion of roles"?
Increase resource granularity, use ABAC/templates, automate reviews, and discard unused roles.

Total

Mature IAM architecture is SSO + MFA, minimum necessary rights, automated JML, centralized policies and observability. By combining RBAC with attribute and relational models, applying JIT/JEA and PAM, and automating provisioning and secret rotations, you get managed, auditable, and scalable access that meets security and business requirements.