RBAC y aprobaciones

El modelo de acceso de Showly tiene tres capas: roles en el espacio de trabajo, ámbitos de la acción y aprobaciones para cambios que afectan la producción. Esta página cubre cómo se compone cada capa.

Roles

El rol de un usuario se establece en el nivel del espacio de trabajo:

Los espacios de trabajo también pueden definir roles personalizados (a través de permisos de roles) cuando los cinco elementos integrados no encajan.

Un usuario puede tener como máximo un rol por espacio de trabajo. Las membresías en todos los espacios de trabajo son independientes: ser propietario de un espacio de trabajo no aporta nada en otro.

Alcances

Los tokens MCP, los tokens API y los tokens de servicio tienen alcances que son un subconjunto estricto de lo que su emisor puede otorgar. Un alcance describe un par resource:verb. Los diez alcances MCP son:

project:read
site:read
site:write
preview:read
preview:create
checks:run
publish:request
logs:read
template:read
template:create

Aproximadamente, viewer se asigna a los ámbitos de lectura básicos. member y developer recibir los alcances de Vista previa/verificaciones/publicación/registro utilizados por el bucle del agente; member además crea proyectos y tiene una gestión de productos más amplia acceso. billing recibe alcances financieros pero no escribe ningún sitio o implementación. Solo owner incluye miembro, invitación, token, seguridad del espacio de trabajo y todo el contenido alcance de facturación establecido.

Un token solo puede hacer lo que está dentro de su alcance establecido, independientemente de quién lo emitió. Se rechaza la emisión de un token con un alcance que usted no tiene.

Consulte la referencia de alcance para ver el mapeo canónico de alcance a herramienta.

Aprobaciones

Las aprobaciones introducen cambios que afectan la producción. La regla más común: la publicación en producción requiere N aprobaciones de un conjunto de roles permitidos.

Valores predeterminados de solicitud de aprobación:

• requiredApprovals por defecto es 1.
• allowedRoles por defecto es una lista vacía, lo que significa que cualquier rol puede aprobar.
• Un rechazo es definitivo: una solicitud rechazada no se puede volver a aprobar.

Cuando un agente llama a request_publish sobre MCP, la solicitud de publicación resultante es creado con requiredApprovals: 1 y allowedRoles: ["owner", "member"]. Este flujo requiere el derecho approvalWorkflows.

Personalice por sitio o por espacio de trabajo en Configuración del espacio de trabajo → Política de aprobación.

Separación de funciones

Un usuario no puede aprobar su propia solicitud. Esto se aplica a nivel del modelo de datos: si usted propuso la publicación, alguien más con un rol permitido debe aprobarla.

Qué se audita

Cada acción (agente, humano, API) escribe una fila de auditoría:

• actor (id de usuario + rol en ese momento, o MCP id de cliente + ámbitos)
• acción (el verbo de alcance + id de recurso)
• resultado (allowed, denied, pending_approval, approved, rejected)
• cuando

Las filas de auditoría solo se pueden agregar y están disponibles a través de las superficies de auditoría de Showly. Actualmente no se promete exportación SIEM externa.

Anulaciones de emergencia

Showly actualmente no expone una omisión de publicación emergency a través de MCP o el flujo web público. El trabajo de emergencia se maneja acelerando la aprobación en una vista previa ready y luego publicándola explícitamente; No se requiere inscripción en OTP. Si se agrega un futuro camino de rotura de vidrio, este debe:

• aún pasar una aprobación (la puerta son las aprobaciones, no la autorización).
• escriba una fila de auditoría emergency=true especial.
• abrir una tarea post-mortem de seguimiento automáticamente.