Diseño y requisitos de un servicio nuevo

Un requisito de seguridad que nadie convierte en control es una frase en un documento. En una revisión de diseño se comprueba, uno por uno, que cada requisito tenga al menos un control que lo cubra; que el control esté todavía «previsto» y no «implementado» es otro hallazgo, pero distinto: aquí interesa el requisito que ni siquiera tiene un control asignado.

El permiso mínimo de un rol es el que su servicio usa. El historial de llamadas de los últimos 90 días enseña qué acciones se usaron, pero una acción sin llamadas no se puede quitar a ciegas: puede cubrir un trabajo que corre pocas veces al año. Antes de recortar se separan las acciones sin uso de las que tienen un trabajo programado que las justifica.

El mapa de comunicaciones declarado es la intención del diseño; el tráfico observado es la realidad. Se comparan por pares de servicios, no por puerto: una conexión entre dos servicios que ningún flujo declarado prevé es una dependencia nueva que nadie revisó, y es justo la que rompe una política de red que se redactó a partir del mapa.

El requisito de cifrado entre servicios se mide con lo observado, no con lo declarado: el modo de mTLS que aparece en un manifiesto dice lo que se pidió, y el sensor dice lo que ocurrió. Para dimensionar el problema se cuentan las conexiones sin cifrar cuyo destino maneja datos personales; las que van hacia servicios sin datos personales son otra conversación.

Un contrato OpenAPI declara el esquema de seguridad de cada operación. «Ninguna» es válido cuando lo que se devuelve no es sensible, como el estado del servicio; deja de serlo cuando la operación devuelve datos de clientes. Se cruzan las dos columnas: la que dice qué exige y la que dice qué devuelve.