Motor de rol

1) Modelos de autorización

RBAC (Role-Based Access Control): el sujeto obtiene roles, roles asociados a derechos (permissions). Sólo para gestionar, bueno para las responsabilidades típicas.
ABAC (Attribute-Based Access Control): la solución depende de los atributos de sujeto, recurso, acción y entorno (tiempo, IP, región, riesgo). Flexible y escalable en reglas complejas.
RBAC + ABAC híbrido: los roles dan una capacidad «básica», los atributos la estrechan (conditions).
(Opcional) ReBAC/Relationship-based: el gráfico de relaciones (propietario, miembro del equipo, delegado) es útil para las estructuras de documentos y org.

2) Arquitectura: PDP/PEP y hilos

PEP (Policy Enforcement Point): ubicación de aplicación de la solución (puerta de enlace API, método backend, capa SQL, UI).
PDP (Policy Decision Point): servicio/biblioteca que calcula 'ALLOW/DENY' por políticas y atributos.
Punto de información de políticas (PIP): fuentes de atributos (IdP/perfil, metadatos de recursos, score de riesgo, geo).
NAT (Punto de administración de políticas): interfaz administrativa/repositorio de políticas (versiones, borradores, publicación).

Flujo: consulta → PEP forma el contexto → PDP aprieta los atributos que faltan (a través de PIP) → calcula la solución → PEP aplica (permitir/denegar/cortar campos) → auditoría.

3) Modelo de datos

• `subject` (user/service) с атрибутами: `tenant_id`, `roles`, `departments`, `risk_level`, `mfa_verified`, `scopes`, `claims`.
• 'resource' c tipo y atributos: 'type', 'owner _ id', 'tenant _ id', 'classification' (público/confidencial), 'region', 'tags'.
• `action`: `read`, `write`, `delete`, `export`, `approve`, `impersonate` и т. п.
• `environment`: `time`, `ip`, `device`, `geo`, `auth_strength`, `business_context` (канал, тариф).

• 'roles (id, tenant_id, name, inherits [])' - mantener jerarquías y plantillas.
• `permissions(id, resource_type, action, constraint?)`.
• `role_permissions(role_id, permission_id)`.
• 'assignments (subject_id, role_id, scope)' - scope: global/por proyecto/por objeto.

• `policy(id, effect=allow|deny, target: {subject, resource, action}, condition: expr, priority, version, status)`.

4) Principios para la toma de decisiones

Deny-overrides: prohibiciones explícitas más prioritarias que los permisos.
Privilegio Least (PoLP): proporcione el acceso mínimo necesario, extienda a través de las condiciones.
Separation of Duties (SoD): prohibición de combinaciones de roles/acciones (por ejemplo, «creó un pago» ≠ «aprouvle»).
Context-aware: refuerza los requisitos en caso de mayor riesgo (no MFA, IP sospechosa).
Determinismo: el mismo contexto → la misma respuesta; confirme la versión de la política en el registro.

5) Patrones de implementación

5. 1 Híbrido de RBAC→ABAC (acondicionamiento)

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 Row/Field-Level Security

En el nivel DB: políticas RLS (por 'tenant _ id', 'owner _ id').
En el nivel API: filtre las colecciones y enmascare los campos si no hay 'allow: read_sensitive_fields'.

5. 3 Soluciones «step-up»

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

5. 4 Tolerancias temporales

Subvenciones con TTL: 'assignment. expires_at', «ventanas» de acceso (durante el horario de trabajo de la región del recurso).

6) Rendimiento y almacenamiento en caché

Caché de soluciones (decision cache) por clave '(subject_hash, resource_key, acción, policy_version)' con TTL corto.
Caché edge de atributos de sujeto (claims en token) + lazy-fetch de atributos de recurso.
Invalidación Incremental: invalidez por eventos (cambio de roles, cambio de políticas, traducción de recursos a «confidencial»).
Revisiones de Batch: para las listas, evalúe con un «filtro» (pushdown policy-predicate) para no tirar de PDP de forma constructiva.

7) Multi-arrendamiento (Multi-tenant)

En cada tabla, 'tenant _ id'; las directivas predeterminadas restringen el acceso dentro del arrendamiento.
Los administradores de arrendamiento sólo administran los roles/derechos de su arrendamiento.
Acceso de alquiler cruzado - exclusivamente a través de invitaciones explícitas/sharing con deny-override explícito.

8) Administración y ciclo de vida de las políticas

Versioning: 'policy. version 'en la respuesta PDP, almacene en la auditoría.
Entornos: draft → canary (partes de tráfico/modo sombra) → prod.
Test matrix: tablas de verdad sobre roles/atributos clave (pruebas contractuales).
Gestión de cambios: búsqueda Merge en políticas con revisión de seguridad/cumplimiento por pares.

9) Auditoría y observabilidad

Журнал решений: `decision_id`, `subject`, `action`, `resource_ref`, `result`, `matched_policies`, `policy_version`, `attributes_digest`.
Métricas: QPS PDP, latencia p95, memoria caché hit-rate, fracción deny, frecuencia step-up, incidentes SoD.
Tracks: span a una llamada PDP; correlación con una solicitud de API.
Replay: la capacidad de «reproducir» decisiones históricas en la nueva versión de la política (safety check).

10) Integración con autenticación y tokens

La identidad es de IdP (OIDC/SAML). Las señales llevan un mínimo de atributos: 'sub', 'tenant', 'roles', 'auth _ time', 'amr', 'scopes'.
Para ABAC, apriete las señales «pesadas» del lado del servidor (PIP) para no inflar el token.
Tokens de recursos firmados (capability/invitaciones) - para delegaciones estrictamente limitadas.

11) Pseudocódigo PDP (simplificado)

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) Anti-patrones

«Role = page» (cientos de roles pequeños sin un modelo de área de tema).
Almacenar directivas sólo en código sin versiones ni auditorías.
La ausencia de deny-override y SoD → un mayor riesgo de fraude.
Listas rígidas 'user _ id' en las reglas (en lugar de atributos/relaciones).
No hay filtrado a nivel de datos (RLS) si sólo hay filtro en UI.
Sincroniza los roles a través de scripts manuales sin eventos ni cachés inválidos.

13) Casos y recetas

13. 1 Cuadro de enmascaramiento de nivel:

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

13. 2 Exportación de datos sólo con MFA:

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 Delegación (token limitado):

Capability-token contiene 'resource _ id', 'actions = [' read ']', 'expires _ at', 'aud'. PEP comprueba la firma y la fecha límite.

14) Pruebas

Pruebas de políticas unitarias: tablas de verdad por combinaciones principales.
Property-based: genera atributos aleatorios para buscar «agujeros».
Pruebas de oro: fijación de un conjunto de soluciones para endpoints críticos.
Canary/Shadow: evaluación paralela de versiones antiguas y nuevas de políticas con lógica de discrepancias.

15) Capacidades relacionadas de la sección «Arquitectura y Protocolos»

Autenticación y autorización (OIDC/OAuth2)

Gestión del consentimiento

Tokenización y administración de claves

Observabilidad: registros, métricas, trazados

Geo-enrutamiento y localización

Encriptación en el Tránsito En/En

16) Check-list del arquitecto

1. ¿Se han definido las funciones sustantivas y sus jerarquías?
2. ¿Existe un modelo híbrido: roles + condiciones en atributos?
3. ¿Ha implementado PDP con deny-overrides, SoD y step-up?
4. ¿Dónde está el PEP? (gateway, backend, DB, UI) - ¿es uniforme en todas partes?
5. ¿Se han configurado las cachés de soluciones y la discapacidad por eventos?
6. ¿Las políticas se versionan, se prueban, se enrollan por proceso?
7. ¿Está habilitada la auditoría de soluciones, métricas y seguimiento?
8. ¿Es compatible con multiarrendamiento y RLS/field-masking?
9. ¿Hay un runbook sobre incidentes y regresión de políticas?

Conclusión

RBAC proporciona manejabilidad, ABAC - contexto y precisión. Al combinar roles con condiciones de atributos, compartir PDP/PEP, implementar almacenamiento en caché, auditoría y pruebas de políticas, construye la autorización como una capacidad de plataforma: predecible, verificable y escalable para los requisitos de producto y regulación.