Fallar de forma segura

Fallar de forma segura tiene dos mitades. La primera: ante un error, el sistema queda en el estado que más protege, que suele ser denegar. La segunda: lo que no está permitido de forma expresa está denegado. Una política predeterminada de permitir invierte la segunda mitad y hace que cada hueco en las reglas sea una puerta abierta.

Fallar cerrado cuesta disponibilidad, y esa es la razón por la que a veces se configura lo contrario. El arquitecto no lo prohíbe: pide que sea una decisión escrita, con dueño.

La tabla componentes de Ostral dice, para cada pieza, qué pasa cuando falla su servicio de decisión (al_fallar) y si alguien escribió la razón (justificacion). Dos componentes se abren al fallar. Uno tiene una razón escrita y firmada; el otro no tiene ninguna, y ese es el problema de diseño.

Un comportamiento de fallo suele salir de una línea de configuración. Leer el archivo es la forma más barata de comprobar si el diseño dice una cosa y el sistema hace otra. En la tabla configuracion_gateway, tres claves gobiernan qué ocurre con una petición cuando el servicio de autorización no contesta o cuando ninguna regla la cubre.

Hay fallos que se resuelven abriendo, y no por descuido. Una cerradura que se bloquea sin energía puede encerrar a personas durante un incendio. Cuando la vida o la integridad física dependen de que algo se abra, ese principio manda sobre el de denegar por defecto, y el riesgo que queda se compensa con otros controles: vigilancia, alarma, una puerta con guardia.

La tabla componentes incluye uno así. Lee su justificación y su control compensatorio antes de decidir.