Qué es un patrón y cómo se documenta con su amenaza y su control

Un patrón de arquitectura de seguridad es una solución que se repite para un problema que se repite. No es una marca ni una herramienta: «pasarela de API» es un patrón; el nombre comercial de un producto que la implementa, no. Esa diferencia importa porque el patrón sobrevive al cambio de proveedor y el producto no.

Lo que convierte una buena idea en una entrada útil del catálogo es que diga, por escrito, qué problema resuelve, en qué contexto, qué amenaza mitiga, con qué control, qué cuesta y cuándo no conviene. Sin la amenaza, nadie puede comprobar si el patrón sigue haciendo falta; sin el «cuándo no», el patrón se aplica en todas partes, también donde estorba.

Un antipatrón es lo contrario: una solución que parece razonable, se repite y abre una amenaza. Se documenta con la amenaza que abre, la señal para encontrarlo en un inventario y el patrón que lo reemplaza.

La plantilla de Cuchavira marca un campo como obligatorio. Una entrada sin ese campo puede tener un control impecable, pero nadie sabrá si lo que protege sigue existiendo ni si otro control lo cubre mejor.

Abre el laboratorio. Lee plantilla-de-patron.txt y después recorre catalogo-de-patrones.txt campo por campo.

La plantilla pide que el control responda a la amenaza escrita. Un error frecuente al copiar entradas es dejar la amenaza de otro patrón: la entrada queda completa a la vista, pero el control y la amenaza ya no hablan de lo mismo. Quien lea solo el título no lo notará; quien lea los dos campos juntos, sí.

Compara, en cada entrada, el campo de amenaza con el de control. Pregúntate: ¿este control corta de verdad esta amenaza?

Un antipatrón sin reemplazo es una prohibición sin salida: el equipo de proyecto sabe qué no hacer, pero no qué hacer en su lugar, y suele acabar pidiendo una excepción. Por eso cada antipatrón remite a un patrón por su id. Si ese id no está en el catálogo, el antipatrón no tiene salida aunque lo parezca.

Cruza los reemplazos de antipatrones.txt con los ids de catalogo-de-patrones.txt.

El campo «Cuándo no usarlo» es el que más se deja vacío y el que más evita errores. La pasarela de API de Cuchavira, por ejemplo, dice que no sirve para transferencias masivas por lotes; el intermediario dice que no sirve para administrar servidores. Ese campo enlaza los patrones entre sí y evita que uno bueno se use para un problema que no es el suyo.