Control de acceso y RBAC en la API

1) Por qué control de acceso en la API

La autorización es la respuesta a la pregunta "¿Es posible que este actor realice esta acción sobre este recurso ahora? ». Los errores provocan fugas de BOLA/IDOR, escalamiento de derechos y violación de los requisitos regulatorios. El objetivo es construir un modelo multinivel: perímetro → servicio-master → reglas de negocio, con políticas explícitas y verificaciones a nivel de objeto.

2) Modelos de autorización: cuándo elegir

RBAC (Role-Based Access Control): funciones de resolución →. Simple, estable, pero propensa a una «explosión de roles».
ABAC (Attribute-Based) es una solución basada en los atributos del sujeto/objeto/contexto (país, nivel KYC, propietario del recurso, riesgo).
ReBAC (Relationship-Based) es un gráfico de relaciones (propietario, miembro del equipo, «project manager»); resuelve jerarquías complejas.
Scopes (OAuth): contrato entre el cliente y el servidor de recursos sobre una «zona de acceso» (por ejemplo, 'payments: write').
Práctica: RBAC para matriz básica, ABAC para contexto y limitaciones, ReBAC para jerarquías complejas (carpetas, organizaciones, límites y podacounts).

3) Taxonomía de recursos y acciones

Jerarquías: 'org → project → wallet → transaction'. Herencia de derechos de arriba a abajo con posibles «limitantes».
Acciones: CRUD + dominio-específico ('approve', 'refund', 'settle').
Propiedades de recursos: propietario, región, estado, etiquetas de riesgo (AML/KYC), límites.
Multiarrendamiento: todas las soluciones contienen 'tenant _ id'; la prohibición de las solicitudes cruzadas por defecto (deny-by-default).

4) Arquitectura: donde se toma la decisión

PEP (Policy Enforcement Point) - Lugar de verificación: gateway/API, sidecar mash, servicio en sí.
PDP (Policy Decision Point) es un motor de políticas: centralizado (servicio OPA, motor Cedar) o integrado en la biblioteca.
Punto de información de la política (PIP): fuentes de atributos: directorio de usuarios/roles, perfil de tenante, código de riesgo/CUS, mapa de propiedad de recursos.
NAT (Policy Administration Point) - Administración de versiones de directivas, publicación, auditoría.

Recomendación: PDP centralizado + caché de soluciones locales en PEP; comprobaciones de objetos complejas en el servicio cuando hay invariantes de dominio.

5) Tokens, estigmas e identidad

OIDC/OAuth2: 'sub' (ID de sujeto), 'aud' (servicio de destino), 'scope '/' roles', 'tenant', 'kyc _ level', 'risk _ tier'.
JWT: RS/ES-firma, corto 'amb', re-lanzamiento por refresh. No ponga PII; use 'jti' para revocar/auditar la pista.
mTLS/HMAC: servicio-a-servicio y socios; Los sellos se aprietan desde el directorio por 'client _ id'.
Dispositivo/Contexto: IP/ASN, geo, hora del día - entrada a la solución ABAC (por ejemplo, prohibición de escribir fuera del horario laboral).

6) Autorización de nivel de objeto (BOLA-first)

Cada operación debe responder a «¿el sujeto es el propietario/tiene derecho a este 'resource _ id'?».

Verificación de propiedad: 'resource. owner_id == subject. id 'o pertenencia a' org 'con un papel.
Filtrado de muestras: siempre aplica 'WHERE resource. tenant_id =:tenant AND...` (row-level security).
Para operaciones de referencia (ID en ruta/cuerpo): normalice y valide a la lógica empresarial.

7) Diseño de RBAC: roles, resoluciones, conjuntos

Permisos (permissions) - Derechos atómicos: 'wallet. read`, `wallet. write`, `payment. refund`.
Roles: conjuntos de permisos con nombre: 'admin', 'support. read`, `cashier`, `fraud. analyst`.
Scopes es un contrato externo para clientes (mapping scope→permissions).

• roles básicos + «complementos» (packs de permission),
• restricciones ABAC (país/región/tenant),
• «ascensos temporales» (acceso justo en tiempo, fecha de caducidad).

8) AVAS/Restricciones contextuales

Geo/jurisdicción: prohibición de escribir de países prohibidos (sanciones/regulaciones).
Tiempo/riesgo: 'risk _ score <threshold' para operaciones grandes.
CUS/límites: 'kyc _ level> = 2' para pines> X; control de «enfriamiento» entre transacciones.
«Dispositivos de confianza»: requiere mTLS para socios en rutas peligrosas.

9) ReBAC y el gráfico de derechos

Útil para estructuras empresariales complejas (grupos, equipos, marcas, sucursales).

Relación: 'miembro', 'admin', 'owner', 'viewer'.
Derechos derivados: el 'viewer' del recurso se hereda del 'member' del proyecto que pertenece a 'org'.
Almacenamiento gráfico: DB con matriz de relaciones, servicio especializado (en el espíritu de Zanzibar-enfoque). Almacene en caché las respuestas 'check (subject, relation, object)'.

10) Caché de soluciones y rendimiento

Caché PDP en el nivel PEP (por ejemplo, en la puerta de enlace) con la clave por: 'sub' tenant 'resource' action 'policy _ version'.
TTL corto (segundos-minutos) + invalidez por eventos: cambio de roles/relaciones/tenant.
Comprobaciones de batch (bulk authz) para listas: reducen las charjas PDP.
Medir soluciones latency; en la degradación - graceful-degradation sólo para leer (nunca para escribir/dinero).

11) Ejemplos de políticas

11. 1 etiquetas JWT → PEP áspero (pseudo-gateway)

yaml
- match: { prefix: "/api/v1/wallets" }
authz:
require:
- claim: "aud"
equals: "wallet-service"
- claim: "scope"
includes_any: ["wallet. read", "wallet. write"]
context:
tenant_from: "claim:tenant"

11. 2 OPA/Rego (ABAC + BOLA)

rego package authz

default allow = false

allow {
input. action == "wallet. read"
input. subject. tenant == input. resource. tenant some role role:= input. subject. roles[_]
role == "support. read"
}

allow {
input. action == "payment. refund"
input. subject. tenant == input. resource. tenant input. subject. kyc_level >= 2 input. subject. risk_tier <= 2 input. subject. id == input. resource. owner_id # BOLA
}

11. 3 Limitación de jurisdicción (política deny-list)

rego deny[msg] {
input. action == "withdraw. create"
input. context. country in {"IR","KP","SY"}
msg:= "Jurisdiction not allowed"
}

11. 4 Política ReBAC (pseudo)

allow(subject, "wallet. write", wallet) --
related(subject, "member", wallet. project) ∧ related(subject, "admin", wallet. org)   ∧ wallet. tenant == subject. tenant.

12) Administración de políticas y versiones

Versionar políticas ('policy _ version') y canario para cambios peligrosos.
«Dry-run/shadow decisions» es la lógica de 'allow/deny' sin impacto.
Catálogo de políticas y migraciones: quién, cuándo y por qué ha cambiado; correlación con incidentes.
Pruebas de escenarios negativos (casos prohibidos) - obligatorias en CI.

13) Observabilidad y auditoría

Los registros de soluciones son: 'trace _ id', 'subject', 'tenant', 'action', 'resource _ id', 'nat', 'policy _ version', la causa del fallo.
Métricas: 'authz _ decision _ latency', 'authz _ denied _ total {action}', proporción de intentos BOLA, caché-hit-rate.
Dashboards: fallas top en acciones/tenantes, tendencias después de lanzamientos de políticas.

14) Seguridad y sostenibilidad

Deny-by-default: ninguna resolución explícita = prohibición.
Fail-closed: si PDP no está disponible, write crítico → una prohibición (o degradación a un «conjunto mínimo» de roles estrictamente validados).
Las «comprobaciones guard» locales dentro de los servicios para invariantes críticos (por ejemplo, 'tenant '/' owner').
Minimizar los estigmas en JWT; atributos sensibles para manipular a través de PIP a través de un canal protegido.

15) Especificidad de iGaming/finanzas

Roles: 'cashier', 'kyc. agent`, `aml. officer`, `fraud. analyst`, `vip. manager`, `risk. admin`.
Restricciones: las operaciones de pago dependen de 'kyc _ level', límites de pagos responsables, estado de AML/sanciones.
Registros de bloqueo: 'org/brand/device/payment _ instrument' - Filtros ABAC en escritura.
Registros de auditoría inmutables para acciones KYC/AML/conclusiones; almacenamiento según los plazos reglamentarios.
API de afiliados: mTLS + 'scopes' contractuales a lo largo de las rutas, filtros geo/ASN en el perímetro.

16) Pruebas y verificación

Matriz negativa: enumera los casos explícitos «prohibidos» y ancla con pruebas.
Autorización Fuzz: reemplaza 'tenant _ id', 'owner _ id', elude los filtros durante la paginación/ordenación.
Prueba de carga PDP: compruebe la latencia y el comportamiento de las cachés en p95/p99.
Liberación de directivas: dry-run + canary + autocartera con deny/allow esperado.
Incidentes: réplica de solicitudes en el stand con la versión exacta de las directivas.

17) Antipatternas

Confiar únicamente en el 'scope' sin controles de objetos (BOLA).
Mezclar lógica de negocio y validación de derechos en cada handler sin un modelo centralizado.
Codificar los roles en IU y confiar en las soluciones del cliente.
Falta de filtros 'tenant '/' owner' en las solicitudes a la DB (leaky reads).
No hay ninguna discapacidad en las soluciones de caché cuando se cambia de rol/relación.
JWT de larga vida sin revocación/rotación.

18) Lista de comprobación prod

• Se han definido recursos/acciones, jerarquías y multiarrendamiento.
• Matriz RBAC básica + limitadores ABAC donde se necesita - ReBAC.
• El PDP/PEP está diseñado; hay un caché local de soluciones y su discapacidad.
• Políticas versionadas, pruebas de escenarios negativos en CI.
• BOLA-verificaciones en cada escritura/lectura en particular 'resource _ id'.
• JWT con los estigmas mínimos, el corto 'amb'; auditoría/revisión por 'jti'.
• Métricas/registros de soluciones, dashboards, alertas por deny/latency.
• Fail-cerrado para escritura crítica; el modo fallback está documentado.
• Documentación para clientes: 'scopes', códigos de error (401/403/404/409), ejemplos.

19) TL; DR

Construir la autorización BOLA-primero: PDP central + caché de soluciones, RBAC como base, ABAC para el contexto, ReBAC para las relaciones. Todas las consultas están en el contexto de 'tenant' y el 'resource _ id' específico; deny-by-default, JWT cortos, filtros de objetos en la DB. Versione y pruebe políticas, mida latency/deny, reproduzca incidentes con un replay. Para iGaming, funciones individuales (KYC/AML/taquilla), limitadores ABAC rígidos y auditorías inmutables.