Roles y permisos en SSP Enterprise
La pregunta que decide si la custodia compartida funciona de verdad no es «¿quién manda?». Es «¿quién puede mover el dinero?», y en un sistema bien construido esas son preguntas distintas con respuestas distintas.
SSP Enterprise las responde en dos lugares separados. La autoridad administrativa vive en los registros de la organización, donde se puede conceder y revocar como cualquier otro permiso. La autoridad de gasto vive en la dirección de la bóveda, donde no se puede. Este artículo es el mapa completo de ambas, incluidos los casos en los que la gente se sorprende más a menudo.
Si no has leído el panorama de cómo encajan organizaciones y bóvedas, SSP Enterprise: bóvedas multisig para equipos es la pieza anterior a esta.
Dos sistemas, a propósito
Un rol de organización gobierna el espacio de trabajo: invitar personas, crear bóvedas, cambiar ajustes, leer el registro de auditoría. Es un registro de base de datos. Cámbialo y el cambio surte efecto de inmediato.
Un rol de bóveda gobierna una bóveda concreta, y uno de sus tres valores —firmante— significa que tu clave pública forma parte de cómo se derivó la dirección de esa bóveda. Eso no se cambia editando nada. Solo se cambia creando otra bóveda en otra dirección y moviendo los fondos.
La consecuencia práctica, y la frase más importante de este artículo: un propietario de la organización que no sea firmante de una bóveda no puede gastar de esa bóveda. Ni con acceso al panel, ni con acceso a la base de datos, ni con la colaboración de SSP. La dirección no sabe qué es un propietario.
Roles de organización, con precisión
Cuatro roles, estrictamente jerarquizados.
| Capacidad | Propietario | Administrador | Miembro | Observador |
|---|---|---|---|---|
| Leer bóvedas, actividad, auditoría | Sí | Sí | Sí | Sí |
| Invitar a nuevas personas | Sí | Sí | Solo si la organización lo permite | No |
| Cambiar el rol de un miembro u observador | Sí | Sí | No | No |
| Cambiar el rol de otro administrador | Sí | No | No | No |
| Cambiar ajustes de la organización | Sí | Sí | No | No |
| Transferir la propiedad, eliminar la organización | Sí | No | No | No |
| Salir de la organización | No: transfiere primero | Sí | Sí | Sí |
Tres detalles de esa tabla merecen destacarse.
Los administradores no pueden tocar a otros administradores. Un administrador puede promover, degradar y quitar a miembros y observadores, pero en el momento en que el objetivo es otro administrador la operación se rechaza. Es deliberado: significa que una única cuenta de administrador comprometida no puede desmantelar en silencio el resto de la capa administrativa.
Las invitaciones de los miembros son un interruptor de la organización. Por defecto, invitar es una capacidad de administrador. Una organización puede optar por permitir que también inviten los miembros —útil en equipos grandes donde la incorporación no debería hacer cola detrás de dos personas— y conviene dejarlo desactivado si quieres un perímetro estrecho.
El propietario no puede salir. Hay exactamente un propietario, y la salida consiste en transferir primero la propiedad a otra persona. Eso evita el modo de fallo en el que una organización acaba sin nadie capaz de realizar operaciones exclusivas del propietario.
Roles de bóveda, con precisión
Tres roles, y su alcance es una única bóveda y no la organización.
Un administrador de bóveda gestiona la bóveda: sus políticas, sus ajustes de notificación, sus observadores. Un administrador de bóveda no es necesariamente firmante, y un administrador de bóveda que no sea firmante no puede aprobar una propuesta.
Un firmante posee una de las claves del M-de-N de la bóveda. Los firmantes redactan propuestas y las aprueban. Su clave pública está en la dirección.
Un observador de bóveda ve saldos, propuestas e historial sin poder redactar ni aprobar nada. Útil para auditores, contables y cualquiera que necesite visibilidad sin autoridad.
Como los roles de bóveda son por bóveda, una misma persona puede ser firmante en la bóveda de operaciones y solo observadora en la de tesorería. Es un arreglo normal y sano: permite dar autoridad de gasto diario a quien la necesita mientras la reserva queda tras un comité distinto y más pequeño.
Las invitaciones van a identidades, no a buzones
Una invitación en SSP Enterprise se dirige a una identidad WK —la identidad multisig 2-de-2 derivada de la SSP Wallet y la SSP Key de alguien— y no a una dirección de correo.
Es una propiedad de seguridad, no una molestia. Una dirección de correo puede verse comprometida, reenviada o tecleada mal hasta acabar en manos ajenas. Una identidad WK solo puede presentarla quien tenga ambos dispositivos de esa persona, lo que significa que una invitación no puede aceptarla quien casualmente lea el mensaje.
De ahí se derivan dos consecuencias. Primera: la persona a la que invitas necesita tener SSP configurado antes de poder unirse; no existe la vía «regístrate desde el correo de invitación», por diseño. Segunda: las invitaciones son auditables de un modo en que no lo son las invitaciones por correo, porque la aceptación es un acto firmado.
Las invitaciones caducadas no se eliminan. Se conservan indefinidamente, porque «a quién se invitó y nunca se unió» es exactamente el tipo de pregunta que hace una auditoría meses después. Nada del rastro de auditoría tiene tiempo de vida.
Qué exige volver a firmar
Algunas operaciones son demasiado trascendentes para autorizarlas con una cookie de sesión. Trece de ellas exigen volver a firmar con tus dos dispositivos en el momento de actuar, entre ellas:
- Transferir la propiedad de una organización
- Eliminar una organización
- Quitar a un miembro
- Cambiar el correo empresarial de una cuenta
Aquí importa la mecánica. El servidor genera el desafío a firmar —nunca el cliente— y el desafío queda ligado a la acción concreta, al objetivo concreto y a una marca de tiempo. Una firma capturada de una operación no puede reproducirse en otra.
Cada intento se registra de forma permanente, incluidos los fallidos. Un patrón de intentos fallidos de acciones críticas es en sí mismo una señal que conviene tener anotada.
Dónde quedan registrados los cambios de rol
Todo cambio de permisos se escribe en el registro de auditoría de la organización: concesiones y revocaciones de rol, invitaciones emitidas, aceptadas, rechazadas y revocadas, miembros que entran y salen, expulsiones y transferencias de propiedad. Los cambios a nivel de bóveda tienen sus propios eventos: firmantes y observadores añadidos o quitados, ediciones de políticas, cambios de estado de la bóveda.
Los registros de auditoría son permanentes. No hay caducidad ni tarea de limpieza, porque el valor de un rastro de auditoría está enteramente en las partes que nadie anticipó necesitar. Una organización que descubre un problema en noviembre quiere el registro de marzo.
Cómo diseñar tu reparto de roles
Unos cuantos patrones que aguantan en la práctica.
Separa al administrador de los firmantes. Deja que un responsable de operaciones tenga administración de la organización para gestionar personas y ajustes de bóveda, sin poner su clave en la dirección de tesorería. Así la comodidad administrativa no arrastra riesgo de custodia.
Reparte roles de observador con generosidad en finanzas. El acceso de lectura es barato y hace posible la conciliación sin ampliar el conjunto de quienes pueden gastar. No hay razón para que un contable sea firmante.
Mantén el comité de tesorería más pequeño que el de operaciones. Una reserva 3-de-5 y una bóveda operativa 2-de-3 es una división común y sensata: el dinero que tocas a diario tiene una barrera de aprobación más baja que el que tocas una vez al año. 2-de-2 frente a 2-de-3 y m-de-n explica cómo razonar sobre los números.
Decide el procedimiento de salida antes de que alguien salga. Quitar a alguien de la organización es un cambio de rol; quitarlo como firmante es una bóveda nueva y una migración de fondos. Escribe cuál harás y confirma que el conjunto de firmantes restante sigue alcanzando el umbral. Qué pasa si una de tus claves se ve comprometida recorre el escenario contiguo.
No trates las políticas como permisos. Las listas blancas, los bloqueos temporales y las reglas de aprobación dan forma a lo que se propone, pero el umbral es lo único que impone la cadena. Diseña tus roles como si el motor de políticas no existiera y luego añade políticas como mejoras de proceso por encima.
La jerarquía de roles es fácil de acertar si mantienes una pregunta en primer plano: ¿cuáles de estos cambios requieren una dirección nueva y cuáles son solo registros? Todo lo de la capa de organización es un registro. Solo el conjunto de firmantes es una dirección.
