Leer un diagrama de arquitectura

Un diagrama de flujo de datos usa pocos elementos: entidades externas (quien está fuera del sistema), procesos (código que transforma datos), almacenes de datos (donde algo queda guardado), flujos (flechas con la información que viaja) y límites de confianza (líneas que separan zonas). En una carga en la nube, un navegador es una entidad externa, una función o un contenedor es un proceso, un bucket o una tabla es un almacén, y cada llamada de API es un flujo.

La regla de lectura es sencilla: las amenazas se buscan en cada elemento y, sobre todo, en cada flujo que cruza un límite. Dentro de una zona se confía más; al cruzarla, se pierde esa confianza y el destino debe comprobar quién llega.

Cada fila de flujos.txt dice de qué zona sale y a cuál llega, si va cifrado y con qué se autentica el origen. Un flujo que cruza un límite sin autenticación del origen es una puerta que acepta a cualquiera que sepa su dirección. Ojo: «ninguna» dentro de una misma zona es una decisión distinta, porque ya hay otras barreras alrededor.

Abre el laboratorio, lee flujos.txt y busca el flujo cuyo origen y destino están en zonas diferentes y que no pide autenticación.

El número de flujos que cruzan límites mide la superficie del diseño. Cada cruce es una decisión de confianza que alguien tiene que tomar y documentar. Cuéntalos con las zonas que indica cada fila de la tabla; recuerda que un flujo cuenta una sola vez, aunque salte dos zonas.

Un almacén de datos alcanzado desde más de una zona tiene más de un camino de entrada, y cada camino necesita su propio control. Los diagramas de arquitectura ordenados suelen esconder esos atajos: un flujo que no pasa por el proceso que se supone que es la única puerta del almacén.

Compara las zonas desde las que llegan flujos a cada almacén (los nombres que empiezan por ds-) y busca el que se alcanza desde más de una.