De un control a un servicio de la nube

Un servicio de la nube puede hacer dos cosas distintas por un control. Puede implementarlo, como cuando un servicio de permisos limita lo que cada rol puede hacer, o puede evidenciarlo, como cuando un servicio de registro deja la prueba de que algo ocurrió. Ninguna de las dos cosas equivale a «cumplir»: el control se cumple cuando existen el servicio, su configuración correcta, un responsable y una evidencia vigente.

Por eso un mapa de control a servicio es un punto de partida. Dice dónde mirar, no si se mira bien.

Para completar una celda se lee lo que pide el control y se busca, entre los servicios en uso, el que cumple esa función. El control CM-6 pide que los recursos se mantengan con configuraciones base definidas y que se detecte lo que se aparta. Del lado de Azure ya está mapeado un servicio con esa función.

Abre los tres cuadros de Ladera y busca el servicio de AWS que cumple la función equivalente.

El control AU-2 trata de decidir qué eventos se registran y de registrarlos. En AWS el servicio de registro de llamadas de administración ya está en el mapa. Falta su contraparte en Azure.

Lo importante al elegir es la función, no el parecido de los nombres. Compara cada descripción con lo que pide el control.

Hay controles que no se apoyan en ningún servicio porque dependen de personas: la formación, las políticas, la selección del personal. Marcarlos con un servicio sería inventar. La honestidad del mapa consiste en escribir «ninguno» cuando es así, y asignarles evidencia y responsable humanos.

Revisa el mapa de Ladera y encuentra el control que depende de un proceso humano.

El control CP-9 de Ladera tiene servicio en AWS y en Azure, pero la observación aclara que la prueba de restauración es un proceso y no una función del servicio. Tener el servicio de copias no demuestra que se pueda restaurar nada: la prueba la hace una persona y deja un acta.

Esto es lo que distingue un mapa serio de uno decorativo: la columna de servicio no cierra la fila.