Arxi Decision Gate Asset Core
Docs
Documentació d'Asset Core

Documentació del motor d'estat del món determinista i referències de l'API.

Decision Gate docs

Model d’Autorització

Asset Core utilitza un model d’autorització de denegació per defecte. Cada sol·licitud és autenticada, mapejada a un principal i avaluada segons permisos basats en rols i regles de governança de l’espai de noms. L’objectiu és mantenir estable el contracte de comportament: les decisions d’accés són deterministes, auditable i resistents a la filtració d’informació.

Aquesta pàgina descriu el model en què podeu confiar. Evita detalls d’implementació interns perquè el contracte es mantingui correcte fins i tot a mesura que l’execució evoluciona.

Entitats principals

Principals representen identitats autenticades. Un principal porta un inquilí, un conjunt de rols i un context de grup o agent opcional. Les decisions d’autorització sempre es resolen a un principal explícit o es deneguen per defecte.

Els rols es corresponen amb permisos. Els permisos es defineixen sobre el catàleg d’operacions públiques (punts d’API i operacions del món de compromís). Rols desconeguts o operacions desconegudes mai atorguen accés.

El commit invers és una operació d’API distincta. Concedeix-lo explícitament quan vulguis que els principals sol·licitin plans inversos emmagatzemats contra commits retinguts; no assumeixis que l’accés al commit implica l’accés al commit invers.

Els espais de noms són el principal límit d’aïllament. La majoria de les operacions són d’àmbit d’espai de noms i requereixen un context d’espai de noms per avaluar l’accés.

Postura de denegació per defecte

Asset Core assumeix entrades no fiables. Si falta o és invàlid qualsevol dels següents, la sol·licitud és denegada:

  • No hi ha un context principal vàlid.
  • Falta o assignació de rol no reconeguda.
  • Falta de context de l’espai de noms per a una operació amb abast d’espai de noms.
  • Restriccions de classe de política que prohibeixen l’operació sol·licitada.

Aquesta postura és central per a l’auditoria del sistema i el seu comportament determinista en entorns adversos.

Control d’accés a l’espai de noms (ACLs)

Els espais de noms poden adjuntar vinculacions de control d’accés que concedeixen o deneguen rols a principals o grups específics. Aquestes vinculacions són additives i substitueixen el conjunt de rols a nivell de llogater per a aquell espai de noms. El model admet vinculacions de denegació explícita i impedeix l’accés no autoritzat fins i tot quan un principal és vàlid a nivell de llogater.

Utilitzeu ACLs quan necessiteu aïllament per espai de noms, accés delegat o restriccions temporals durant incidents.

Classes de polítiques i portes de risc

Els espais de noms se’ls assigna una classe de política (per exemple, scratch, project, o production). Les portes de classe de política imposen regles més estrictes en entorns de major risc. Això permet realitzar experiments amb menys fricció en entorns scratch mentre s’apliquen controls més estrictes en espais de noms de producció.

Les classes de política són part del contracte públic. Si una classe de política prohibeix una operació, la sol·licitud és denegada fins i tot si el principal té un rol ampli.

Postura de divulgació (401/403/404)

Els resultats d’autorització estan dissenyats per evitar la filtració d’informació. Si un espai de noms és desconegut o inaccessible, el sistema respon amb una denegació sense revelar l’existència. Els errors d’autenticació donen un 401, els errors d’autorització donen un 403, i les limitacions o restriccions donen un 429. Vegeu el Model d’Error per al mapeig complet.

Auditoria i traçabilitat

Cada decisió es pot correlacionar mitjançant IDs de correlació del servidor i IDs de correlació del client opcionals. Això permet rastrejar els denegaments d’accés fins a una sol·licitud, un token i un context d’espai de noms exactes en els registres i mètriques.

No-objectius

El model d’autorització no intenta inferir la intenció ni implementar polítiques específiques del negoci. Proporciona una capa d’aplicació estricta i determinista; les regles específiques del domini haurien d’estar codificades en la lògica de la vostra aplicació o en els procediments operatius.

Properes passes