Autorización: quién puede hacer qué y cómo lo demuestras

Control Center responde a dos preguntas de autorización, y son realmente distintas. «¿Puede esta persona invocar esta operación?» tiene que ver con personas, roles y repositorios. «¿Puede este agente provocar este efecto?» tiene que ver con acciones, argumentos y radio de impacto; esa está en Barandillas.

Esta página trata de la primera pregunta, además del registro que ambas dejan atrás.

Un único punto de decisión

Toda decisión de autorización del lado humano se resuelve mediante una única función:

can(principal, permission, resource) → allow | deny + why

Un permiso es <domain>:<tier>: tickets:write, members:administer, repos:read. El catálogo es derivado, no está escrito a mano: se calcula a partir de la propia superficie de operaciones (el prefijo del nombre de la operación da el dominio y el rol mínimo que ya exige da el nivel), de modo que las ~550 operaciones llevan un permiso sin que nadie escriba ninguno.

Esa derivación es la propiedad que vale la pena proteger. Significa que toda operación NUEVA queda restringida por defecto; el modo de falla de un modelo anotado a mano es que alguien se olvide, y lo que se olvida es justamente la restricción. Una prueba de trinquete fija el conjunto de dominios resultante, de modo que agregar una operación bajo un prefijo nuevo es una decisión de nomenclatura que toma una persona, y no un accidente.

Los cuatro niveles se corresponden exactamente con los roles integrados:

Nivel	Rol mínimo	Ejemplo
read	Invitado	tickets:read
write	Miembro	tickets:write
administer	Admin	members:administer
own	Propietario	workspace:own

Roles

Cinco roles integrados —Propietario, Admin, Miembro, Observador, Invitado— son ajustes preestablecidos sobre ese catálogo. La propiedad es un único asiento por espacio de trabajo, que se cede de manera explícita con Transferir la propiedad (de lo contrario, un propietario que se va no se puede eliminar: el desaprovisionamiento SCIM rechaza a cualquier propietario de un espacio de trabajo; transfiere la propiedad primero).

Los roles personalizados son sustractivos. Un rol personalizado nombra un ajuste preestablecido base (admin, member, viewer o guest — nunca owner) y un conjunto de permisos que se ELIMINAN de él: «admin, pero no puede administrar miembros». Nunca puede conceder más que su base, y eso es lo que los hace seguros de introducir en una instalación existente: toda verificación existente sigue siendo un límite superior válido. Los miembros los tienen como custom:<id>, y un cliente demasiado antiguo para entender ese valor recurre a invitado en lugar de adivinar.

Por debajo de los roles están las concesiones por repositorio (none / read / review / write): la pertenencia a un espacio de trabajo nunca otorga más privilegios que el host de código de manera silenciosa. Todas las superficies que exponen código las verifican, incluidas las que llegan al código de forma indirecta, como un terminal o una sesión de editor abierta en el worktree de un espacio.

Autoridad del servidor

Algunas operaciones no tienen que ver con un espacio de trabajo en absoluto: la configuración de toda la instalación, la configuración de SSO, las credenciales de proveedores, la administración de modelos y los respaldos de toda la instalación. Estas declaran autoridad del servidor y se rechazan para todos salvo el operador de la instalación (el propietario del servidor registrado). Deliberadamente hay una sola identidad de operador y una sola definición de ella.

El registro de auditoría

Toda decisión de autorización —permitir y denegar— se agrega a un registro de auditoría por espacio de trabajo encadenado por hash.

Un registro que solo guarda las denegaciones responde a «¿qué bloqueamos?», pero no a «¿qué hizo en realidad este agente y quién lo autorizó?», que es la pregunta con la que empieza la revisión de un incidente. Por eso cada entrada registra toda la cadena de atribución: el principal que actúa, la persona en cuyo nombre actuó, la delegación por la que llegó, la acción y sus argumentos (como resumen), la decisión y la regla que la determinó.

Las entradas están encadenadas: el hash de cada una cubre el de la anterior, así que editar, eliminar o reordenar cualquier fila rompe todos los hash posteriores. Verificar la cadena vuelve a derivar todo el conjunto y señala el primer eslabón que no se sostiene. Un registro de auditoría que no puedes verificar es solo un registro; uno que puedes volver a derivar es evidencia.

Dos consecuencias que conviene conocer:

• La tabla de auditoría está exenta de la purga por antigüedad. Una cadena de hash no se puede recortar por el medio. La retención consiste en exportar y luego truncar, y el truncado deja un punto de control que lleva el hash terminal del segmento eliminado, de modo que lo que sobrevive aún se verifica hasta el inicio.
• Está junto a la línea de tiempo de actividad, no por encima de ella. La línea de tiempo es lo que hizo la gente; esto es lo que se autorizó y lo que se rechazó. Un id de correlación compartido permite leer una misma llamada en ambas.

Se exporta como JSON delimitado por saltos de línea y puede transmitirse a un SIEM (Splunk, Elastic, Sentinel — un endpoint HTTP con un token de portador). La transmisión es de mejor esfuerzo por diseño: que un SIEM esté caído nunca debe bloquear la llamada a una herramienta de un agente, y la copia duradera y verificable está en el disco de cualquier manera.

Sesiones

Una instalación puede establecer una vigencia máxima de la sesión y un tiempo de espera por inactividad. Ambos se aplican en la verificación de credenciales del dispositivo por la que pasan todos los canales autenticados; un límite de sesión que un cliente pudiera ignorar responde a un cuestionario, no a un atacante. Una instalación también puede exigir SSO, lo que desactiva el emparejamiento manual de dispositivos nuevos (con una protección contra bloqueos: se niega mientras no exista ninguna conexión SSO funcional).

Qué no es esto

• No son ACL por objeto. Deliberadamente, no existe ningún permiso por ticket ni por mensaje. La separación a nivel de repositorio es lo que de verdad piden los equipos y ya existe; el uso compartido por objeto es una superficie combinatoria sin demanda demostrada aquí.
• No es un motor de políticas que configures en un DSL. El vocabulario es cerrado a propósito, de modo que toda la política se puede representar, explicar y enumerar.
• No se aplica en ningún otro lado salvo en el servidor. Las verificaciones del lado del cliente solo existen para no ofrecer un control que se va a rechazar. La decisión autoritativa es siempre la del servidor.