Detección y respuesta en el diseño

La sección de detección del pilar de seguridad de AWS la describe en dos partes: detectar cambios de configuración no deseados y detectar comportamientos inesperados. Para eso hacen falta registros de lo que ocurre en cada componente, reunidos en ubicaciones estandarizadas y con alertas definidas. Azure añade en su pilar la idea de asumir la brecha: mantener un rastro de auditoría de los accesos para detectar y recuperar más rápido.

Al revisar un diseño, el primer control es de cobertura: qué componentes registran, hacia dónde envían sus registros y cuánto los conservan.

Abre SELECT * FROM fuentes_registro. En la columna registro figura el tipo de registro de cada componente. Un componente que no genera ninguno es un punto ciego: si algo pasa ahí, no quedará rastro para reconstruirlo.

La política interna fija mínimos de conservación por tipo de registro. Abre SELECT * FROM minimos_politica para verlos y compara con la retención de cada fuente de actividad administrativa en las dos nubes. Es el registro que más se pide en una investigación: dice quién cambió qué en la cuenta.

La auditoría de consultas de la base de datos de carga también tiene un mínimo en la política, y el diseño no lo cumple. Para el informe hace falta la cifra: cuántos días de retención faltan para llegar al mínimo.

Un plan de respuesta se valida ejercitándolo: un ejercicio de mesa o un simulacro revela datos de contacto caducados, permisos que faltan y pasos que nadie sabe ejecutar. Abre SELECT * FROM plan_respuesta. Un escenario sin guía escrita es otro hallazgo; aquí interesa el que sí tiene guía pero nadie la ha ejercitado.