Modelo de Autorización
Asset Core utiliza un modelo de autorización por defecto de denegación. Cada solicitud es autenticada, mapeada a un principal y evaluada en función de los permisos basados en roles y las reglas de gobernanza de espacios de nombres. El objetivo es mantener estable el contrato de comportamiento: las decisiones de acceso son deterministas, auditables y resistentes a la filtración de información.
Esta página describe el modelo en el que puedes confiar. Evita detalles de implementación interna para que el contrato siga siendo correcto incluso a medida que evoluciona el tiempo de ejecución.
Entidades principales
Los Principales representan identidades autenticadas. Un principal lleva un inquilino, un conjunto de roles y un contexto de grupo o agente opcional. Las decisiones de autorización siempre se resuelven a un principal explícito o se deniegan por defecto.
Los roles se asignan a permisos. Los permisos se definen sobre el catálogo de operaciones públicas (puntos finales de API y operaciones de commit-world). Los roles desconocidos o las operaciones desconocidas nunca otorgan acceso.
La reversión de commit es una operación API distinta. Conceda acceso explícitamente cuando desee que los principales soliciten planes de reversión almacenados contra commits retenidos; no asuma que el acceso al commit implica acceso a la reversión de commit.
Los espacios de nombres son la principal frontera de aislamiento. La mayoría de las operaciones están limitadas al espacio de nombres y requieren contexto de espacio de nombres para evaluar el acceso.
Postura de denegación por defecto
Asset Core asume entradas no confiables. Si falta o es inválido alguno de los siguientes elementos, se deniega la solicitud:
- No hay un contexto principal válido.
- Asignación de rol faltante o no reconocida.
- Falta contexto de espacio de nombres para una operación con alcance de espacio de nombres.
- Restricciones de clase de política que prohíben la operación solicitada.
Esta postura es central para la auditabilidad del sistema y el comportamiento determinista en entornos adversariales.
Control de acceso a espacios de nombres (ACLs)
Los espacios de nombres pueden adjuntar vinculaciones de control de acceso que otorgan o deniegan roles a sujetos o grupos específicos. Estas vinculaciones son aditivas y anulan el conjunto de roles a nivel de inquilino para ese espacio de nombres. El modelo admite vinculaciones de denegación explícita y previene el acceso no autorizado incluso cuando un sujeto es válido a nivel de inquilino.
Utilice ACLs cuando necesite aislamiento por espacio de nombres, acceso delegado o restricciones temporales durante incidentes.
Clases de políticas y puertas de riesgo
Los espacios de nombres se asignan a una clase de política (por ejemplo, scratch, project o production). Las puertas de clase de política imponen reglas más estrictas en entornos de mayor riesgo. Esto permite realizar experimentos con menor fricción en entornos scratch mientras se aplican controles más estrictos en los espacios de nombres de producción.
Las clases de políticas son parte del contrato público. Si una clase de política prohíbe una operación, la solicitud es denegada incluso si el principal tiene un rol amplio.
Postura de divulgación (401/403/404)
Los resultados de autorización están diseñados para evitar la filtración de información. Si un espacio de nombres es desconocido o inaccesible, el sistema responde con una denegación sin revelar su existencia. Los fallos de autenticación generan 401, los fallos de autorización generan 403, y la cuota o limitación genera 429. Consulte el Modelo de Error para el mapeo completo.
Auditoría y trazabilidad
Cada decisión puede correlacionarse a través de identificadores de correlación del servidor y identificadores de correlación del cliente opcionales. Esto hace posible rastrear las denegaciones de acceso hasta una solicitud, token y contexto de espacio de nombres exactos en los registros y métricas.
No objetivos
El modelo de autorización no intenta inferir la intención ni implementar políticas específicas del negocio. Proporciona una capa de aplicación estricta y determinista; las reglas específicas del dominio deben codificarse en la lógica de su aplicación o en los procedimientos operativos.
Próximos pasos
- Configurar RBAC para un inquilino para la configuración basada en tareas.
- Gobernanza de espacios de nombres para operaciones de ciclo de vida y plano de control.
- Por qué se denegó el acceso para la clasificación rápida de operadores.