Funciones sin servidor y sus permisos

Una función puede tener su propia dirección web, y esa dirección lleva un tipo de autenticación que solo toma dos valores. Con el primero, el proveedor autentica y autoriza a quien llama con su identidad. Con el segundo no hay autenticación ninguna: quien conozca la dirección llega a la función, siempre que la política de recursos conceda la invocación, y con un principal comodín esa política la concede a todo el mundo.

No es un error por sí mismo. Una página de rastreo de pedidos tiene que estar abierta. Lo que convierte la configuración en hallazgo es la segunda columna, que es hasta dónde llega lo que corre detrás.

En la exportación hay dos funciones con dirección abierta. Una la documenta el cliente y tiene sentido: es la página de rastreo que usa el comprador. La otra no aparece en ninguna decisión escrita, y además está pensada para que la llame un socio desde su propia cuenta, que es justo lo que el otro tipo de autenticación resuelve.

Abre el laboratorio y cruza la tabla de funciones con la documentación del cliente.

El rol de ejecución es la segunda columna, y es la que mide el hallazgo. Una función abierta cuyo rol lee una sola tabla vale poco para quien la encuentre; una función cuyo rol toca todos los cubos de la cuenta, con lectura, escritura y borrado, convierte cualquier fallo de esa función en un problema de toda la cuenta. El criterio es el mismo de siempre, el mínimo privilegio, aplicado a algo que no es una persona.

El cliente preguntará si alguien llamó a la función abierta y cuántas veces. La respuesta sale de la configuración del registro, no de la intuición: las invocaciones de funciones y las lecturas de objetos son eventos de datos, y los eventos de datos no se registran de forma automática, hay que activarlos. Con ellos apagados, el informe no puede afirmar que no pasó nada; solo que no hay forma de saberlo, y ese vacío es un hallazgo propio.