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 tenga que escribir ninguno.

Esa derivación es la propiedad que merece la pena proteger. Significa que una operación NUEVA queda restringida de forma predeterminada; el modo de fallo de un modelo anotado a mano es que alguien se olvide, y lo que se olvida es precisamente la restricción. Un test de trinquete fija el conjunto de dominios resultante, de modo que añadir 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 puesto por espacio de trabajo, que se cede de forma explícita con Transferir la propiedad (si no, un propietario que se marche no se puede eliminar: el desaprovisionamiento SCIM rechaza a cualquier propietario de 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 gestionar 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 comprobación existente sigue siendo un límite superior válido. Los miembros los ostentan 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 forma silenciosa. Todas las superficies que exponen código las comprueban, 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: los ajustes de toda la instalación, la configuración de SSO, las credenciales de proveedores, la gestión de modelos y las copias de seguridad 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 única identidad de operador y una única definición de ella.

El registro de auditoría

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

Un registro que solo recoge las denegaciones responde a «¿qué bloqueamos?», pero no a «¿qué hizo realmente este agente y quién lo autorizó?», que es la pregunta por la que empieza una revisión de incidentes. 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 a través de la cual 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, de modo 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 falla. Un registro de auditoría que no puedes comprobar es un simple registro; uno que puedes volver a derivar es una prueba.

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 sigue verificándose hasta el principio.
• Está junto a la cronología de actividad, no encima de ella. La cronología es lo que hizo la gente; esto es lo que se autorizó y 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 disco en cualquier caso.

Sesiones

Una instalación puede establecer una antigüedad máxima de sesión y un tiempo de espera por inactividad. Ambos se aplican en la comprobació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 lugar salvo en el servidor. Las comprobaciones en el cliente solo existen para no ofrecer un control que se va a rechazar. La decisión autoritativa es siempre la del servidor.