Interfaces por rol y acceso

1) Principios

1. Seguridad = tarea UX. El usuario debe entender claramente lo que puede y no puede hacer, sin «zonas grises».
2. Derechos mínimos necesarios. Desde la visualización hasta las acciones, todo se limita a las tareas de rol.
3. Señal en lugar de prohibición. Si no hay acceso - explicar por qué y cómo obtener (solicitud, solicitud, formación).
4. Duplicación en el servidor. Los guardianes de UI nunca reemplazan las inspecciones del servidor.
5. Auditoría transparente. Cada acción sensible deja una huella legible.

2) Modelos de control de acceso

RBAC (Role-Based): roles fijos: Jugador, Sapport, Finanzas, Riesgo/Cumplimiento, Director de Afiliado, Moderador, Administrador.
ABAC (Attribute-Based): política basada en atributos (jurisdicción, marca, zona horaria, nivel VIP, comando, cambio).
ReBAC (Relationship-Based): acceso por relación (curador del jugador, propietario del ticket, gerente del socio).
SoD (Segregation of Duties): separación de tareas críticas (creado ≠ aprobado).

Práctica: RBAC como base, ABAC para ajuste fino (marca/región), SoD para finanzas/límites, ReBAC - punto (carteras supervisadas).

3) Mapa de funciones por roles (ejemplo de iGaming)

4) Patrones UX para derechos y roles

4. 1 Navegación y visibilidad

Oculte las secciones inaccesibles de la navegación (reducción del ruido), pero muestre las tarjetas «vacías» de información si ayuda a comprender las posibilidades.
Para el temporalmente inaccesible - «Candado» con una pista: razón, requisitos, CTA «Solicitar acceso».

4. 2 Estados de actividad

Disabled + tooltip: "Se requiere el rol Finanzas. Solicitar acceso".
Modo sólo lectura: campos «debajo del vidrio», marcador explícito de Sólo lectura.
Escalamiento: el botón Enviar para aprobación en lugar de Aplicar.

4. 3 Enmascaramiento y edición

PII (email, teléfono, dirección) - 'user @.', '+ 380 90' para las entradas de otras personas.
PAN/IBAN - sólo tokens/últimos 4.
El botón de opción Mostrar por completo es sólo para el rol propietario/por evento con auditoría.

5) Arquitectura de permisos en IU

Contexto de política en el cliente: caché de permisos (TTL corto) + suscripción de actualizaciones.
Guardas de rutas: routs inaccesibles → página 403 con explicación y CTA.
Los guardianes de componentes son: 'Can ({action:' approve _ withdrawal ', resource:' payout '})'.
Ficheflagi: cosas experimentales/estacionales - separadas de los derechos.

tsx type Permission = string; // 'payout.approve', 'kyc.view_masked'
type Policy = { has:(p:Permission)=>boolean };
const PolicyCtx = React.createContext<Policy>({ has:()=>false });
export const Can: React.FC<{perm:Permission, children:React.ReactNode, fallback?:React.ReactNode}>
= ({perm, children, fallback=null}) => {
const { has } = React.useContext(PolicyCtx);
return has(perm)? <>{children}</>: <>{fallback}</>;
};

6) Servidor> Cliente

Cualquier acción es confirmada por el servidor mediante un token con los sellos (rol, atributos).
Las políticas están centralizadas (PDP/OPA/Cedar/Zanzibar-similares), IU sólo obtiene la solución.
Todas las operaciones críticas: confirmación de dos factores + auditoría.

7) Enmascaramiento y zonas de datos rojas

• PII: nombre, correo electrónico, teléfono, dirección, fecha de nacimiento.
• Finanzas: PAN/IBAN/criptomonedas, sumas, límites, balances de bonificación.
• Documentos: pasaportes/ID/selfies (KYC).
• Juego: historial de apuestas/ganancias/patrones.

• Completo - propietario de la función/propietario de la grabación.
• Enmascarado - sapport, finanzas (no propietario).
• Agregada - analítica (sin identificadores).

tsx function Redact({text, perm}:{text:string, perm:Permission}){
const { has } = React.useContext(PolicyCtx);
return <span>{has(perm)? text: text.replace(/.(?=.{4})/g,'•')}</span>;
}

8) Flujos de aprobación (Approvals) y SoD

Cuatro ojos: iniciador ≠ aprobador.
Rutas de varias etapas (por ejemplo, sumas> X → 2ª línea).
Caducidad de las solicitudes, SLA, escalamiento.
Revista: quién creó, quién cambió, quién aprobó, cuándo y dónde.

Ejemplos: confirmación de retirada, modificación de los límites del jugador, veredicto de KYC, retirada de la bandera sancionadora.

9) Especificidad de iGaming

Límites y autoexclusión: cambio sólo con SoD y notificación obligatoria al usuario.
KYC/AML: acceso a documentos - un papel estrecho; previsualización de miniaturas, tamaño completo - por acción separada con la guarida.
Banderas de sanciones/RR: visibles para el equipo de riesgo; sapport - sólo el estado «necesita verificación».
Pagos/Conclusiones: «Realizar/Rechazar» - sólo el papel de Finanzas; sumas superiores al umbral - doble confirmación.
Revistas de apuestas: sapport lee, pero no edita; ajustes - función separada con la investigación.

10) Localización, A11y, RTL

Los textos «sin acceso» se localizan y contienen las rutas actuales (solicitud/formación).
Control de enfoque: no transferir al usuario a una página «en blanco» sin explicaciones.
El modo RTL se admite para los roles en las regiones correspondientes.
A11y: 'aria-disabled' + explicación, disponibilidad del teclado de la escalada.

11) Estados y errores

403 (sin derechos): página amigable con contexto de rol y CTA «Solicitar acceso».
404 (sin recurso): no revelar la existencia de objetos ocultos.
413/422 (demasiado/validación): no fusionar los detalles de la política, formular neutralmente.
Ratios-límites/bloqueos: explique el temporizador/la condición de desbloqueo.

12) Métricas

Tasa de denegación de acceso: porcentaje de fallas en roles/pantallas (señal de mala IA o política).
Approval SLA: mediana de tiempo de aprobación por flujo (salida, límites, KYC).
Mask Reveal Events: frecuencia de «revelaciones» PII (esperada pequeña y justificada).
Error-to-Resolution: tiempo desde 403 hasta el acceso emitido.
Least-Privilege Drift: roles con derechos redundantes (detalle por uso).

13) Anti-patrones

Ocultar los errores bajo «no pasó nada».
Mostrar botones vacíos sin explicaciones.
Enmascarar al propietario sus propios datos.
Confíe en los guardianes de IU sin políticas de servidor.
Mezclar fichflags con accesos (diferentes tareas).
Dar un «god-mode» sapport por conveniencia.

14) Tokens del sistema de diseño (ejemplo)

json
{
"access": {
"badge": { "viewer":"#607D8B", "editor":"#4CAF50", "approver":"#FF9800", "admin":"#9C27B0" },
"lockColor": "#9E9E9E",
"maskChar": "•"
},
"states": {
"noAccess": { "bg":"var(--bg-elev)", "border":"var(--border)", "icon":"#9E9E9E" },
"approval": { "pending":"#FFC107", "approved":"#4CAF50", "rejected":"#F44336" }
},
"a11y": { "ariaDisabled": true, "explainDenial": true }
}

15) UI Snippets

tsx import { Navigate, Outlet } from 'react-router-dom';
function GuardedRoute({perm}:{perm:Permission}){
const { has } = React.useContext(PolicyCtx);
if (has(perm)) return <Outlet/>;
return <Navigate to={`/403?perm=${encodeURIComponent(perm)}`} replace/>;
}

html
<article class="no-access">
<h3>Недостаточно прав</h3>
<p>Доступ к разделу «Выплаты» доступен ролям: Финансы/Админ.</p>
<button class="btn" data-open-request>Запросить доступ</button>
</article>

json
{
"ts": "2025-11-03T18:45:12Z",
"actor": "u_5412",
"action": "payout.approve",
"target": "withdraw#w_91822",
"ip": "194...12",
"result": "success"
}

16) QA-check-list

Navegación e IA

• Las secciones inaccesibles no hacen ruido en el menú.
• Hay páginas/tarjetas «sin acceso» comprensibles con CTA.

Acciones y guardias

• Botones sin derechos - 'disabled' + tooltip/texto.
• Las rutas están protegidas; URL directa → 403 con explicación.
• El servidor confirma cada acción.

Datos

• PII/PAN/KYC se disfrazan de política.
• Los registros de «revelaciones» se escriben y rugen.
• Los informes de exportación corresponden al rol (agregados para análisis).

SoD/Approvals

• El iniciador no puede aprobar su solicitud.
• Umbrales → rutas de varios pasos.

A11u/Localización

• «Ningún acceso» está localizado; la navegación por teclado funciona.
• Los anillos de contraste/enfoque corresponden a AA.

Seguridad

• Caché de permisos con TTL corto; discapacidad en el cambio de rol.
• La caída de PDP → IU funciona en modo «default-safety».

17) Documentación en el sistema de diseño

Компоненты: `GuardedRoute`, `Can`, `NoAccessCard`, `ApprovalBanner`, `Redact`.
Políticas: matriz de roles/acciones, reglas SoD, niveles de enmascaramiento.
Proceso: solicitud de acceso, formación/certificación de roles, revisión de derechos una vez cada semanas.
Do/Don 't-gallery: «botones vacíos sin razón», «disfraz al propietario», «IU sin controles de servidor» vs «restricciones explicadas y CTA».

Resumen breve

Las interfaces de rol son una arquitectura de información comprensible + políticas estrictas + explicaciones amigables. Muestre sólo lo que necesita, enmascare los datos sensibles, proteja las rutas y acciones por parte de los guardias, registre cada evento crítico en la auditoría y comparta las responsabilidades donde afecte el dinero y el cumplimiento. En iGaming, esto no solo reduce los riesgos, sino que también hace que el trabajo de los equipos sea más rápido y más tranquilo.