La ingeniería de seguridad transforma un requisito de la carga de trabajo en un control que puede probarse, supervisarse y eliminarse de forma segura. En Azure, esta labor abarca el inquilino de Microsoft Entra, Azure Resource Manager dentro de una suscripción y el plano de datos de cada servicio; por ello, una configuración aparentemente correcta podría estar protegiendo un ámbito equivocado.
Utilizaremos una carga de trabajo de desarrollo acotada dentro del grupo de recursos ficticio rg-orders-dev. El objetivo es exponer las decisiones, las evidencias y los límites que un ingeniero de seguridad en la nube debe establecer antes de considerar una configuración como una medida de protección.
Comience con un requisito vinculado a un activo y a una amenaza. Por ejemplo, una API de procesamiento de pedidos debe recuperar un secreto sin exponerlo a través de la Internet pública. Un control es el mecanismo configurado para satisfacer dicho requisito, mientras que una evidencia es un registro observable que respalda una afirmación concreta sobre su configuración o actividad.
Nuestro flujo de trabajo es coherente. Identificamos el activo, el límite de datos, la identidad y la amenaza; elegimos el control adecuado más sencillo; definimos el fallo esperado si se deniega el acceso o si el tráfico sigue una ruta no prevista; y, finalmente, verificamos el resultado deseado mediante evidencias de configuración y de tiempo de ejecución. La fase de limpieza elimina los permisos temporales, los secretos de prueba o las configuraciones de diagnóstico cuando ya no son necesarios, evitando así que los artefactos de prueba se conviertan en riesgos de exposición permanente.
Las evidencias de configuración y las de tiempo de ejecución responden a preguntas diferentes. Una asignación de roles o la configuración de un punto de conexión privado (private endpoint) demuestran el estado previsto del plano de control. Un evento de auditoría de Key Vault, un registro de diagnóstico de almacenamiento o un fallo de la aplicación demuestran un intento observado en el plano de datos dentro de su ventana temporal registrada. Ninguna de estas evidencias por sí sola garantiza que todas las rutas sean seguras o que un incidente no tenga otra causa.
Las recomendaciones identifican brechas en la postura de seguridad, pero la aplicación efectiva de las medidas debe provenir de una política de denegación o del propio control.
Microsoft protege la infraestructura física subyacente de Azure, mientras que el cliente sigue siendo responsable de los datos de la carga de trabajo, el comportamiento de la aplicación, las identidades y las decisiones de acceso. Este límite de responsabilidad compartida no significa que un servicio administrado por la plataforma no requiera tareas de seguridad por parte del cliente. Implica que debemos identificar qué parte es responsable de cada capa antes de seleccionar medidas de evidencia o corrección.
El directorio Microsoft Entra autentica a usuarios, aplicaciones e identidades administradas. Azure Resource Manager (a menudo denominado ARM) es el plano de control de Azure para crear y configurar recursos en una suscripción o un grupo de recursos. Las asignaciones de roles de Azure RBAC en estos ámbitos autorizan acciones en el plano de control, como modificar la configuración de red de una cuenta de almacenamiento.
El plano de datos de un servicio es la interfaz específica del servicio que lee, escribe o utiliza datos protegidos. La recuperación de secretos de Key Vault y el acceso a datos de blobs se producen en sus respectivos planos de datos, donde la autorización y los controles de red de dicho plano se aplican independientemente de la autorización de ARM. Un usuario con el rol de Colaborador que puede configurar un almacén no está autorizado por ello a leer sus secretos.
La regla reutilizable consiste en identificar la entidad de seguridad (principal), la acción, el ámbito y el plano antes de determinar si el acceso debe realizarse correctamente.
Nuestra carga de trabajo ficticia es app-orders-api, una aplicación de Azure App Service ubicada en rg-orders-dev, dentro de una suscripción ficticia <subscription-id>. Se ejecuta en una región de Azure seleccionada y utiliza vnet-orders-dev para la integración de red virtual de salida. La aplicación requiere datos de pedidos en stordersdev y un secreto en kv-orders-dev, mientras que law-sec-01 es el área de trabajo de Log Analytics utilizada por Microsoft Sentinel.
La red virtual constituye el límite de red de la aplicación, no la ubicación de todos los recursos de los servicios de Azure. stordersdev y kv-orders-dev siguen siendo servicios de la plataforma Azure externos a vnet-orders-dev; los puntos de conexión privados sitúan interfaces de red privadas para dichos servicios dentro de la red virtual. El DNS privado y la configuración de red del servicio deben dirigir las solicitudes salientes de la API hacia las direcciones de esos puntos de conexión, en lugar de hacia un punto de conexión público.
La identidad administrada de la aplicación requerirá posteriormente permisos independientes en el plano de datos para las operaciones previstas en Key Vault y Storage. Sentinel se ejecuta en law-sec-01, donde los conectores y la configuración de diagnóstico determinan qué registros se reciben para su análisis. Un área de trabajo solo permite realizar investigaciones sobre los datos que se han recopilado efectivamente en ella.
Defina el límite de la carga de trabajo desde la API hasta sus puntos de conexión privados y el área de trabajo de supervisión.