Crypto Casino
Torrent Gear
Claves API, tokens y mandatos de acceso: autenticación segura
Texto completo del artículo
1) Por qué todo esto: modelo de amenazas para iGaming
Dinero y PII: compromiso de la llave → frod, fugas, multas.
Integraciones de red: docenas de proveedores externos, diferentes regiones/licencias.
Tasas elevadas de SLA: pago simple o doble: riesgos reputacionales y legales.
Conclusión: la autenticación y la autorización deben ser «por defecto seguras», con mínimos privilegios y una estricta observabilidad.
2) Herramientas: lo que tenemos en el arsenal
Claves API: identificadores de cliente estáticos. Fácil integración, alto riesgo de fugas.
OAuth2 (Clientes Credentials): fichas de Bearer de breve vida con scope/audience.
mTLS: comprobación TLS recíproca, fuerte vinculación del cliente al canal.
Firmas HMAC/EdDSA: integridad criptográfica del cuerpo de la solicitud y protección contra réplicas (timestamp + nonce).
Proof-of-Possession: tokens MTLS-bound o DPoP (firma de solicitud HTTP por clave de cliente).
JWT/PASETO: tokens auto-descriptivos (preferiblemente con TTL corto).
RBAC/ABAC: autorización de rol/atributo base (ORA/decisiones de políticas).
Mandatos de acceso temporal (delegation/STS): tickets de tiempo y propósito limitados emitidos para un escenario específico.
3) Principios básicos («signos de parada»)
1. Privilegio Least: cada clave/token es el mínimo derecho posible.
2. Short-lived by default: TTL minutos, no días. La rotación es automática.
3. Bind to channel: vincular tokens a mTLS/DPoP → es inútil cuando se filtra.
4. Per-brand/region: claves/certificados y permisos - para la marca/licencia/región.
5. No compartidos secretos en el código: secretos sólo a través de Vault/HSM/KMS, ni en Git/logs.
6. Auditoría WORM: registros inmutables de todas las operaciones/entregas/rotaciones.
7. Idempotencia en los caminos de escritura: cualquier repetición con la misma clave no cambia el dinero por segunda vez.
4) Cuándo utilizar qué (contexto iGaming)
5) Diseño de los mandatos de acceso (scopes, audiencia, condiciones)
Scope-s (ejemplos):- `bets:write`, `settlements:write`, `wallet:credit`, `wallet:debit`, `rg:read`, `rg:enforce`, `jackpot:trigger`.
Audiencia: a quién se dirige el token (por ejemplo, 'aud: wallet. api`).
Constraints (fine-grained):- `brand_id`, `region`, `ip/cidr`, `time_of_day`, `rate_limit`, `max_amount`.
- Se almacenan en token (claims JWT) o en un «mandato» emitido en Vault/STS.
6) Flow de referencia
6. 1 Plataforma ⇄ RGS: dinero por RPC
1. mTLS handshake (certificados por marca/región).
2. OAuth2 CC: RGS recibe 'access _ token' (TTL 2-5 min, 'aud = wallet. api`, `scope=bets:write settlements:write`).
3. Consulta 'POST/v1/bets/authorize' con los encabezados:- `Authorization: Bearer
`, `X-Idempotency-Key`, `X-Trace-Id`. - 4. Respuesta + entrada en auditoría WORM (quién/qué/cuándo/dónde).
- 5. La rotación del token es perfecta, después de la repetición de CC.
6. 2 Webhooks plataforma → proveedor
La cabecera 'X-Signature: eddsa =
El proveedor comprueba: ventana de validez (± 5 min), desechabilidad 'nonce', firma del cuerpo.
Si no está disponible - Retray c backoff, dedoup por 'event _ id'.
6. 3 Delegación (servicio de jackpot → billetera)
JP llama a STS: «dar un token temporal en 'wallet: credit' para 'player _ id = p _...', suma ≤ X, TTL 2 min».
STS comprueba las políticas/límites → emite un mandato (token estrecho).
JP está prestando una cartera con este token. Comprometer tal token no tiene sentido: TTL corto, derechos estrechos, enlace a mTLS.
7) Diseños de consultas
7. 1 Idempotencia (obligatoria)
POST /v1/bets/settle
Authorization: Bearer <MTLS-bound>
X-Idempotency-Key: settle_r_8c12_1
X-Trace-Id: tr_a1b2
{
"bet_id":"b_001", "round_id":"r_8c12", "win":{"amount":1460,"currency":"EUR"}
}
→ 200 { "status":"credited", "settlement_id":"st_77" }
(repetición con la misma clave → la misma respuesta)7. 2 Firma Webhook (HMAC)
X-Signature: sha256=BASE64(HMAC(secret, timestamp + "." + nonce + "." + body))
X-Timestamp: 1730000000
X-Nonce: 1f7a...8) Gestión de secretos y claves
Vault/HSM/KMS: generación, almacenamiento, rotación, revocación.
El entorno del PER: sandbox/prod - diferentes raíces de confianza.
Per-marca/región: claves y certificados individuales.
Auto-rotación: cron/alertas; períodos overlap para reemplazos sin fisuras.
Prohibición en código/logs: los secretos no se escriben en stdout, no entran en crash-reports.
Device/Workload identity: SPIFFE/SPIRE, K8s ServiceAccount → mTLS sin secretos manuales.
9) Políticas de autorización (RBAC/ABAC) y OPA
RBAC: роли «rgs», «wallet», «jackpot», «reporting».
ABAC: reglas «si 'region = EU' y 'brand = A' → permitir 'wallet: credit' ≤ 10k».
OPA/REGO o análogos: toma de decisiones centralizada, versionamiento de políticas, pruebas en seco.
10) Observabilidad y auditoría
Los 'trace _ id' y 'client _ id' de extremo a extremo en cada consulta/evento.
Métricas: p50/p95/p99 latencia por endpoints, error-puntuación por códigos ('AUTH _ FAILED', 'SCOPE _ DENIED', 'IDEMPOTENCY _ MISMATCH'), frecuencia de rotación, proporción de tokens vencidos.
Registro WORM: emisiones/revocaciones de tokens, cambio de claves, cambio de políticas.
Alertas: estallido de 'AUTH _ FAILED', anomalías por geo/ASN, crecimiento 'caducado/revocado'> umbral.
11) Residencia regional y segmentación
Los tokens/certificados están vinculados a una región (EU/UK/BR/...).
En los estigmas - 'región', las pasarelas de plataformas prohíben las llamadas entre regiones.
Los clústeres separados KMS y Vault por región; las claves no «conducen» entre regiones.
12) Incidentes y retroalimentación
Compromise playbook: revoke instantáneo de claves/tokens, bloque de redes/ASN, cierre de scope.
Kill-switch a nivel de gateway: "no new sessions/funds'.
Postmortem: «como cayó en los registros/repositorio», «por qué el DLP/escáner de secretos no funcionó».
13) Hojas de cheques
A. Para la plataforma
- Todas las pistas de escritura: mTLS + OAuth2 CC (TTL ≤ 5 min), 'X-Idempotency-Key', 'X-Trace-Id'.
- Webhooks: HMAC/EdDSA + timestamp + nonce, dedoup por 'event _ id'.
- Keistor: Vault/HSM/KMS, rotación y revocación, separación por marca/región.
- ORA/políticas: RBAC/ABAC, registros de cambios, pruebas.
- Auditoría WORM y SLO-dashboards (latency, error, revoke/rotate).
- Ejercicios DR/xaoc: tokens vencidos, sustitución de firma, MITM sin mTLS.
B. Para proveedor (RGS/live/JP)
- No guardo secretos en el código; uso Vault/submenú a través de variables de entorno.
- Rotación automática de tokens; handle 401/403 con actualización.
- Firmo webhooks/compruebo ventanas de validez y desechabilidad.
- Llevo a cabo una auditoría de las acciones clave y respondo a los titulares de Deprecation/Sunset.
- Idempotencia en todos los desafíos de escritura, dedoop en 'Idempotency-Key'.
14) Anti-patrones (banderas rojas)
Claves API estáticas sin fecha de caducidad en la venta.
Bearer-tokens sin enlace al canal (sin MTLS/DPoP).
Almacenar secretos en la configuración de Git/CI-Login/Frontend.
Clave/certificado compartido para múltiples marcas/regiones.
Webhooks sin firma y ventana temporal → réplica.
No hay revocación centralizada y registro WORM.
Falta de idempotencia → toma de débitos/créditos.
15) Mini plantillas de política (ejemplo, humanitariamente)
Mandato 'rgs→wallet' (UE, marca A):- `aud=wallet. api`, `scope=["bets:write","settlements:write"]`
- `constraints: region=EU, brand=A, ip in {asn:…}, max_amount=5000 EUR, ttl=300s`
- `binding: mTLS(cert_hash=sha256:…)`
- 'alg = Ed25519', la ventana '± 300s',' nonce 'es única, dedoop' event _ id '24 horas.
La autenticación segura en iGaming es una combinación de prácticas: mandatos de vida corta, enlace de canal (mTLS/DPoP), scope/audience estrecho, idempotencia estricta, auditoría Vault/HSM y WORM, segmentación regional y observabilidad. Tal pila no interfiere con la velocidad de las integraciones, pero reduce radicalmente el riesgo de fugas e incidentes financieros - el dinero y los datos permanecen bajo control, las actualizaciones pasan previsiblemente y el cumplimiento se realiza «fuera de la caja».