SABSA y TOGAF, arquitectura primero

SABSA es una metodología de arquitectura de seguridad que publica el SABSA Institute. Su idea central es que todo lo que se diseña tiene que poder explicarse hacia arriba: un componente existe por una decisión de diseño, la decisión por un requisito, y el requisito por un objetivo del negocio. Para eso organiza el trabajo en capas, de la visión del negocio (la capa contextual) al diseño conceptual, lógico y físico, hasta los componentes concretos y la operación, y cada capa se comprueba contra la de arriba.

La utilidad práctica es que un control sin un objetivo detrás es un gasto que nadie puede defender, y un objetivo sin controles es una promesa sin respaldo. La traza permite detectar los dos casos con una simple lectura de la matriz.

Abre objetivos y decisiones. La dirección de Aguamarca firmó tres objetivos. Siete de las ocho decisiones cuelgan de alguno; una lleva un guion donde debería ir el objetivo. No significa que sea una mala decisión: significa que nadie anotó de qué sale, y a una decisión así la acompañan dos preguntas, de cuál de los tres objetivos cuelga o si no cuelga de ninguno, y por qué entonces se paga.

Las capas no son un orden de construcción: son puntos de vista de personas distintas. La capa contextual es la del negocio, la que dice qué se promete y por qué; la conceptual, la de quien concibe la arquitectura; la lógica, la del diseñador; la física, la de quien decide dónde y cómo se despliega; la de componentes, la de quien elige productos y configuraciones; y la operativa, la de quien lo mantiene funcionando. Una decisión en la capa equivocada suele delatar que se saltó una conversación: un modelo de cortafuegos escogido antes de saber qué tráfico debe permitir, por ejemplo.

Aguamarca ubicó cada decisión en su capa. Una de ellas es una promesa contractual a los clientes, que es lo más cercano al negocio.

TOGAF es el marco de arquitectura empresarial de The Open Group; su edición vigente es la décima. Su núcleo es el ADM, un método cíclico para desarrollar y gobernar la arquitectura de toda la empresa. Tiene una fase preliminar y las fases de la A a la H: visión, arquitectura de negocio, de sistemas de información y tecnológica, oportunidades y soluciones, planificación de la migración, gobierno de la implementación y gestión del cambio. Una gestión de requisitos atraviesa todas y no es una fase.

Para el arquitecto de seguridad no es una lista de controles: es el lugar y el momento donde meter la seguridad en un cambio. Un cambio que no pasa por la visión no tiene quien pregunte qué se protege, y uno que llega directo al gobierno de la implementación ya está construido cuando alguien pregunta. En la tabla cambios hay un registro de las fases por las que pasó cada solicitud.

El cambio SC-13 es la integración con el sistema de facturación de un municipio y está en curso, con registro solo de la fase de gobierno de la implementación. Tirar lo hecho y empezar de nuevo es la respuesta más cara y casi nunca la necesaria. Lo que cuesta poco es volver atrás un paso: hacer la visión y la evaluación de seguridad que faltan, con el trabajo ya hecho como insumo, y decidir con eso qué cambia antes de que entre en producción.