Saltar al contingut principal
La revisió a 4 ulls afegeix una segona aprovació independent abans que una resolució tingui efecte, un control estàndard de separació de funcions per a les investigacions de major risc.

​
Configuració

Al blueprint creador, estableix Revisió a 4 ulls com a blueprint revisor. Establir aquest camp és el que activa la revisió a 4 ulls per al blueprint creador; no hi ha cap interruptor separat.

​
Com funciona

  1. Un responsable del blueprint creador resol un cas com de costum (fals positiu o amenaça vàlida, i una nota si cal).
  2. En lloc de tancar-lo, l’estat del cas es manté en Obert, la resolució proposada queda preparada i el cas passa a la cua del blueprint revisor. La línia de temps del cas registra Submitted for approval.
  3. Un revisor revisa la pestanya Visió general del cas, on un bàner de control dual mostra les accions Aprovar i Rebutjar.
  4. Aprovar aplica la resolució preparada: el cas passa a Resolt amb la resolució i la nota originals, atribuït al responsable que l’ha enviat. La línia de temps registra Approval granted i després Resolved.
  5. Rebutjar esborra la resolució preparada i torna el cas al blueprint creador. La línia de temps registra Approval rejected, i el creador rep una notificació.
El responsable que ha enviat la resolució no pot aprovar-la ni rebutjar-la ell mateix, i això es fa complir al servidor. Si ho intenta, es retorna un 403. (Aprovar o rebutjar un cas sense cap resolució pendent d’aprovació retorna un 409.)

​
Com s’anomena el revisor

El responsable que resol pot indicar el membre que ha d’aprovar la resolució, amb el camp checker de l’API per resoldre un cas. Només aquest membre pot aprovar-la o rebutjar-la; qualsevol altre, inclosa una clau d’API, rep un 403. El camp checker del cas mostra el membre indicat fins que la resolució s’aprovi, es rebutgi o el cas es retorni per a una nova revisió. Si no s’indica cap revisor, la resolució espera a la cua del blueprint revisor, tal com s’ha descrit anteriorment. El revisor indicat ha de tenir accés al cas de l’aplicació i no pot ser el responsable que ha enviat la resolució.

​
Quan canvien les evidències

Si es canvia la resposta d’una llista de verificació o si s’afegeix o s’elimina una verificació o una transacció vinculada, es cancel·la la decisió pendent i el cas torna a la seva política de revisió original. La línia de temps d’activitat registra que cal una nova decisió de revisió i conserva la proposta anterior en l’esdeveniment d’auditoria. El revisor ha d’examinar les evidències actualitzades i enviar una nova decisió abans que un segon responsable pugui aprovar-la. Repetir la mateixa resposta de la llista de verificació no cancel·la una revisió pendent. L’aprovació també comprova les evidències d’origen vinculades amb el que es va enviar a revisió. Un estat de verificació canviat, un camp de document corregit, unes evidències de transacció modificades o una font no disponible bloquegen l’aprovació amb 409. Perdre l’accés a les evidències de la xarxa global vinculades mitjançant un Fraud Check també requereix una nova revisió. Utilitza Rebutjar per tornar el cas al blueprint creador, revisar les evidències actualitzades i enviar una nova decisió. Obrir el registre d’origen o afegir una nota interna al cas no bloqueja per si sol una revisió sense canvis. Si no es poden verificar les evidències enviades, cal una nova revisió abans de l’aprovació.

​
Notes

  • Els requisits de revisió es desen quan s’obre el cas. Passar a la cua del revisor no substitueix aquests requisits per les modificacions posteriors de la política.
  • Un cas només pot tenir una resolució preparada alhora; demanar més informació (En espera de l’usuari) queda bloquejat mentre hi hagi una resolució pendent d’aprovació.
  • La revisió a 4 ulls es combina amb les notes de resolució obligatòries: activa totes dues opcions per als teus blueprints de major risc perquè es requereixin tant una justificació documentada com un segon revisor.
Darrera modificació el 7 de novembre del 2026