Tokens de autenticación de funciones sin servidor en la nube: explotación y detección

Resumen ejecutivo

Este artículo describe la mecánica y las implicaciones de seguridad de la autenticación sin servidor en las principales plataformas en la nube. Los atacantes se dirigen a las funciones sin servidor con la esperanza de explotar las vulnerabilidades que surgen como resultado de que los desarrolladores de aplicaciones implementen código inseguro y configuren mal las funciones en la nube. El éxito en la explotación de estas debilidades permite a los atacantes obtener credenciales de las que luego pueden abusar.

Las funciones de computación sin servidor suelen asociarse con identidades en la nube que utilizan tokens de autenticación para obtener acceso temporal y limitado a los servicios y recursos de la nube. La exfiltración de estos tokens puede exponer los entornos de nube a riesgos de seguridad.

Amazon Web Services (AWS) Lambda, Azure Functions y Cloud Run Functions de Google son ejemplos de plataformas y funciones sin servidor que se valen de credenciales. Estas credenciales incluyen roles de gestión de acceso e identidad (IAM) en AWS, identidades gestionadas en Azure y tokens de cuentas de servicio en Google Cloud Platform (GCP).

Comprender cómo funcionan estos servicios nos permite aplicar estrategias eficaces para evitar la exposición de tokens y detectar el abuso de tokens expuestos que puede llevar a comprometer entornos en la nube. Tales compromisos implican la escalada de privilegios, la persistencia maliciosa dentro del entorno y la exfiltración de información confidencial a la que solo las identidades legítimas deberían poder acceder.

Los clientes de Palo Alto Networks están mejor protegidos a través de nuestra línea de productos Cortex frente a las amenazas comentadas en este artículo. Si cree que puede haber resultado vulnerado o tiene un problema urgente, póngase en contacto con el equipo de respuesta ante incidentes de Unit 42.

Introducción

La computación sin servidor es un modelo de nube en el que proveedores como AWS (Lambda), Azure (Functions) y Google Cloud (Functions) gestionan la infraestructura, el escalado y el mantenimiento. Este modelo permite a las organizaciones y a sus desarrolladores centrarse únicamente en el código, mientras que el proveedor de la nube se encarga de las tareas de backend.

Al funcionar por eventos, las funciones sin servidor se ejecutan en respuesta a desencadenantes como solicitudes HTTP, cambios en la base de datos o eventos programados. El escalado automatizado del servicio de funciones ajusta los recursos a la demanda, garantizando la rentabilidad al cobrar el proveedor de la nube únicamente por el tiempo de ejecución y los recursos utilizados.

Si bien la computación sin servidor simplifica el desarrollo y la implementación, es importante comprender los riesgos potenciales asociados con estos servicios. Algunos de esos riesgos surgen del hecho de que los desarrolladores pueden asignar identidades a las funciones sin servidor, y esas identidades se presentan como conjuntos de credenciales que son accesibles al código que se ejecuta dentro de la función. Estas credenciales se utilizan para la autenticación y autorización para realizar operaciones en la nube.

Estas credenciales se aplican con un conjunto de permisos que dictan su uso. Según los permisos asociados a la identidad vinculada a la función, esas credenciales pueden permitir el acceso a los recursos de la nube y a datos confidenciales.

Los atacantes apuntan a las funciones sin servidor por estas razones:

• Muchas veces, las funciones sin servidor pueden ser vulnerables a ataques de ejecución remota de código (RCE) o de falsificación de peticiones del lado del servidor (SSRF) debido a prácticas de desarrollo inseguras.
• Las funciones sin servidor suelen estar expuestas públicamente (ya sea por diseño o debido a una mala configuración) o procesan entradas de fuentes externas.
• Los atacantes pueden explotar los tokens de autenticación de funciones sin servidor para obtener acceso no autorizado de lectura/escritura que podría poner en peligro infraestructuras y datos críticos.

Cuando se utilizan funciones sin servidor, es importante tener en cuenta los riesgos que se producen cuando los desarrolladores de aplicaciones implementan código inseguro en funciones en la nube, y comprender las amenazas que se dirigen a estas funciones.

Cómo funciona la autenticación sin servidor en las principales plataformas en la nube

Mediante el enfoque sin servidor, las aplicaciones se implementan con la ejecución de funciones bajo demanda. La mayor ventaja de este planteamiento es que las aplicaciones o componentes específicos pueden ejecutarse en función de las necesidades, sin necesidad de un entorno de ejecución continuo.

Cada uno de los proveedores de nube más importantes comparte conceptos parecidos para las funciones sin servidor, como por ejemplo:

• Compatibilidad con varios lenguajes de programación.
• La ausencia de acceso SSH debido a su arquitectura totalmente gestionada.
• Uso de funciones, cuentas de servicio o identidades gestionadas para gestionar de forma segura el acceso a los recursos.

AWS Lambda

El servicio IAM de AWS permite crear y administrar usuarios, permisos, grupos y roles. El servicio es responsable de administrar las identidades y su nivel de acceso a las cuentas y servicios de AWS, así como del control de diversas características dentro de una cuenta de AWS.

Las funciones sin servidor usan roles de Lambda, que no tienen permisos por defecto; se deben usar políticas de IAM para administrar los permisos y asegurar el acceso a otros servicios de AWS.

Para simplificar la administración de permisos, AWS proporciona políticas administradas (como AWSLambdaBasicExecutionRole) que los desarrolladores suelen adjuntar a estas funciones para habilitar rápidamente la funcionalidad básica.

Cuando se asocia un rol de IAM a una función de Lambda, el servicio de tokens de seguridad (STS) de AWS genera automáticamente credenciales de seguridad temporales para ese rol.

Se trata de una forma segura de acceder a las credenciales en tiempo de ejecución sin los riesgos asociados con las credenciales codificadas a largo plazo.

Estas credenciales se rigen por los permisos definidos en la política de acceso asociada con el rol. Incluyen un identificador de clave de acceso, una clave de acceso secreta y un token de sesión.

En tiempo de ejecución, el servicio en tiempo de ejecución de Lambda carga las credenciales de rol en el entorno de ejecución de la función y las almacena como variables de entorno, por ejemplo, AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY y AWS_SESSION_TOKEN. Estas variables son accesibles al código de la función durante el tiempo de ejecución, lo que permite a la función interactuar de forma segura con otros servicios de AWS.

Google Cloud Functions

Google Cloud Functions utiliza tokens de cuenta de servicio para autenticar y autorizar el acceso a otros servicios de Google Cloud. Una cuenta de servicio es una cuenta de Google especializada que está vinculada con un proyecto y representa una identidad no humana, en lugar de representar a un usuario individual.

Al implementar una Cloud Function, los desarrolladores pueden adjuntar la función a una cuenta de servicio personalizada o a la cuenta de servicio por defecto. Cuando se utiliza una cuenta de servicio personalizada, los desarrolladores pueden asignar roles IAM específicos para definir los permisos exactos que requiere la función para realizar sus tareas.

Las cuentas de servicio por defecto son cuentas gestionadas por el usuario que Google Cloud crea automáticamente cuando los usuarios habilitan servicios específicos. Por defecto, Google Cloud Functions utiliza diferentes cuentas de servicio en función de la generación:

• Cloud Run functions de primera generación utilizan la cuenta de servicio por defecto de App Engine (<project_id>@appspot.gserviceaccount.com)
• Cloud Run functions de segunda generación utilizan la cuenta de servicio por defecto de Compute (<project_number>- compute@developer.gserviceaccount.com)

A estas cuentas de servicio por defecto se les conceden permisos de editor cuando los desarrolladores se incorporan a GCP sin una organización, lo que les permite crear, modificar y eliminar recursos dentro del proyecto. Sin embargo, en los proyectos que dependen de una organización GCP, las cuentas de servicio por defecto se crean sin ningún permiso. En esos casos, solo pueden realizar acciones permitidas explícitamente por los roles que se les han asignado.

Aunque una función de GCP opera en un entorno sin servidor, cuando se trata de acceder a las credenciales asociadas con la función, se comporta de manera similar a un servidor tradicional, como una instancia de máquina virtual (VM), recuperando sus tokens de cuenta de servicio del servidor de metadatos de instancia (IMDS) en tiempo de ejecución. El IMDS en hxxp://metadata.google[.]internal/ proporciona tokens de acceso de corta duración para la cuenta de servicio asociada con la función. Estos tokens permiten a la función autenticarse en los servicios de GCP.

Azure Functions

Las identidades gestionadas de Azure proporcionan una forma segura y transparente para que los recursos de Azure se autentiquen e interactúen con otros servicios de Azure sin necesidad de utilizar credenciales codificadas. Del mismo modo que los servicios de funciones de AWS y GCP, estas identidades eliminan los riesgos asociados con la gestión de credenciales en el código.

Las identidades gestionadas asignadas por el sistema se vinculan a un único recurso y se eliminan automáticamente cuando se elimina el recurso. Por otro lado, las identidades gestionadas asignadas por el usuario son recursos independientes que pueden asignarse a diversos servicios, lo que ofrece más flexibilidad para escenarios de autenticación compartida.

Una función de Azure con una identidad gestionada adjunta debe utilizar su token de identidad gestionada para autenticarse en un recurso de Azure. El proceso de autenticación paso a paso es el siguiente:

• La función consulta sus variables de entorno para recuperar los valores de IDENTITY_ENDPOINT e IDENTITY_HEADER.
  • IDENTITY_ENDPOINT: Una variable de entorno que contiene la dirección del endpoint local de identidad gestionada proporcionado por Azure. Se trata de una URL local desde la que una aplicación puede solicitar tokens.
  • IDENTITY_HEADER: Parámetro obligatorio al consultar el endpoint local de identidad gestionada. Esta cabecera se utiliza para mitigar los ataques SSRF.
• La función envía una solicitud HTTP GET al endpoint local de identidad gestionada con el IDENTITY_HEADER incluido como cabecera HTTP. (Para obtener más información sobre la estructura de la solicitud, consulte la documentación de Azure sobre la adquisición de tokens para App Services)
• Microsoft Entra ID (anteriormente Azure Active Directory) verifica la identidad de la función y emite un token OAuth 2.0 temporal que se asigna específicamente al recurso de destino.
• La función incluye el token emitido en su solicitud al recurso Azure (p. ej., Azure Key Vault, Storage Account).
• El recurso Azure valida el token y comprueba los permisos de la función mediante el control de acceso basado en roles o políticas de acceso específicas del recurso.

Si está autorizado, el recurso concede acceso para realizar la operación solicitada. Esto garantiza una autenticación segura y perfecta sin necesidad de utilizar secretos codificados en el código.

Vectores de ataque de extracción de tokens

En esta sección se analizan los riesgos y amenazas que conlleva el uso de funciones sin servidor. Al desarrollar y configurar funciones, los desarrolladores de aplicaciones deben asegurarse de proteger esas funciones contra ataques como SSRF y RCE. En ausencia de dicha seguridad, los atacantes podrían manipular las funciones sin servidor que son vulnerables a SSRF, haciendo que las funciones envíen solicitudes no autorizadas a los servicios internos. Esto puede conducir a un acceso no intencionado o a la exposición de información confidencial dentro del sistema, como tokens de acceso, contenido de bases de datos internas o configuraciones de servicios. Es importante subrayar que estos riesgos surgen principalmente cuando las funciones son públicas o procesan entradas de usuarios externos y otras fuentes.

En los ataques SSRF, un atacante engaña a un servidor (como una función sin servidor) para que realice peticiones HTTP a recursos internos o externos a los que el atacante no debería tener acceso. Dado que es el propio servidor el que realiza la petición, puede acceder a servicios internos que no están expuestos a Internet. Una función vulnerable sin servidor toma una URL como entrada y obtiene datos de ella.

En GCP, SSRF puede utilizarse para acceder al IMDS en hxxp://metadata.google[.]internal/, extrayendo tokens de cuenta de servicio de corta duración. Un atacante puede entonces aprovechar estos tokens para hacerse pasar por la función y realizar acciones no autorizadas dentro de los permisos de su rol IAM. Las vulnerabilidades de ejecución remota de código permiten a los atacantes ejecutar código arbitrario dentro del entorno de una función.

Para AWS Lambda, los ataques RCE podrían exponer credenciales temporales almacenadas en variables de entorno, como AWS_ACCESS_KEY_ID y AWS_SESSION_TOKEN.

Es esencial señalar que estos vectores de ataque no son fallos inherentes a las propias plataformas en nube, sino que surgen de código inseguro escrito por desarrolladores de aplicaciones que podrían introducir vulnerabilidades, como SSRF o RCE. Los desarrolladores de aplicaciones pueden mitigar estos riesgos mediante la aplicación de prácticas de codificación seguras, como la validación de entradas.

Simulaciones de vectores de ataque

En las siguientes simulaciones se muestran posibles formas en las que los atacantes podrían extraer tokens de autenticación de funciones sin servidor y utilizarlos para actividades maliciosas en diferentes proveedores de servicios en la nube (CSP). Estos ataques podrían aprovechar el código de función inseguro implementado por los desarrolladores de aplicaciones.

Simulación 1: acceso directo al IMDS desde la función GCP

Para llevar a cabo esta simulación, implementamos dos funciones de Cloud Run de Google que acceden al servicio de metadatos de funciones y extraen los tokens de las dos cuentas de servicio adjuntas diferentes de la siguiente ruta:

• hxxp[://]metadata.google[.]internal/computeMetadata/v1/instance/service-accounts/default/token

En el primer ejemplo se muestra la extracción de una cuenta de servicio por defecto. En el segundo ejemplo se muestra la extracción de una cuenta de servicio personalizada. En estos ejemplos se muestra cómo el código puede acceder directamente al servicio de metadatos, del mismo modo que una aplicación de código SSRF vulnerable también podría acceder a él.

Ejemplo 1: extracción de una cuenta de servicio por defecto de GCP

Como se muestra en la Figura 1, la cuenta de servicio adjunta a la función era la cuenta de servicio sin servidor predeterminada. En la Figura 2 se muestra que el token de acceso devuelto pertenece a la misma cuenta de servicio.

Ejemplo 2: extracción de una cuenta de servicio personalizada de GCP

En la Figura 3 se muestra la cuenta de servicio personalizada que adjuntamos a la función. En la Figura 4 se muestra el token de acceso devuelto perteneciente a la cuenta de servicio personalizada. A continuación, utilizamos el token devuelto para realizar operaciones en el entorno.

En la Figura 5 se muestra un ejemplo de comando para mostrar depósitos.

Si los atacantes pueden mostrar y leer el contenido de los depósitos en GCP, pueden acceder a archivos confidenciales como credenciales, copias de seguridad o configuraciones internas. Esto les permite robar datos, comprometer el sistema o moverse lateralmente dentro del entorno.

Una vez que los atacantes obtienen un token de acceso para una cuenta de servicio con permisos de editor en GCP (como la cuenta de servicio Compute Engine predeterminada), pueden modificar, eliminar o crear recursos en la mayoría de los servicios. Esto incluye acceder a datos confidenciales, implementar cargas de trabajo maliciosas, escalar privilegios o interrumpir servicios. El acceso de editor otorga un control casi total sobre el proyecto.

Simulación 2: uso de RCE para recuperar tokens almacenados en variables de entorno de funciones de AWS Lambda

En esta simulación, accedimos a las variables de entorno de la función Lambda y extrajimos de ella el AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY y AWS_SESSION_TOKEN.

En la Figura 6 se muestra la salida del código de la función Lambda.

En la Figura 7 se muestra la configuración de las credenciales temporales de AWS obtenidas en el paso anterior (las variables de entorno de Lambda).

A continuación, utilizamos el siguiente comando para mostrar todos los depósitos de S3 a los que puede acceder la sesión autenticada.

Simulación 3: uso de RCE para recuperar tokens del endpoint local de identidad de Azure Function

En esta simulación, accedimos a las variables de entorno de Azure y extrajimos el IDENTITY_ENDPOINT y el IDENTITY_HEADER ejecutando comandos remotos. A continuación, extrajimos el token de identidad gestionada del endpoint local de identidad, proporcionando estos parámetros que se muestran a continuación en la Figura 8:

• Recurso
• api-version
• X-IDENTITY-HEADER

Detección y prevención de la filtración de tokens

Detección de la exfiltración de tokens en entornos sin servidor

Los mecanismos de detección eficaces son fundamentales para identificar la exfiltración de tokens en entornos sin servidor. Estos mecanismos se centran en las anomalías de comportamiento para señalar actividades no autorizadas. A continuación se exponen algunas de las mejores estrategias de detección aplicadas en las principales plataformas en nube.

La detección consta de dos etapas:

• Validación de que la identidad está vinculada con una función sin servidor.
• Identificación de comportamientos anómalos de las identidades sin servidor. Tal comportamiento podría incluir lo siguiente:
  • Direcciones IP de origen que no se ajustan al contexto en el que se ejecuta la función, como direcciones de Números de Sistema Autónomo (ASN) que no están asociadas con un proveedor de nube.
  • Identidades sin servidor que realizan peticiones con agentes de usuario sospechosos.

Paso 1: identificación de identidades sin servidor

Para identificar las cuentas de servicio adjuntas a las funciones sin servidor en GCP, analizamos la sección serviceAccountDelegationInfo en los registros. Esta información proporciona datos cruciales sobre la cadena de delegación de cuentas de servicio. En concreto, cuando una cuenta de servicio se adjunta a una función, delega su autoridad en una cuenta de servicio sin servidor por defecto:

• Agente del servicio de Cloud Run de Google (service-<PROJECT_NUMBER>@serverless-robot-prod.iam.gserviceaccount[.]com)
• gcf-admin-robot.iam.gserviceaccount[.]com (service-PROJECT_NUMBER@gcf-admin-robo.iam.gserviceaccount[.]com)

Estas cuentas de servicio ejecutan tareas en nombre de la función.

Por ejemplo, en la entrada de registro de la Figura 9, vemos la cuenta de servicio personalizada que se adjuntó a una función (sa-test@<project-id>.iam.gserviceaccount[.]com) que delega su autoridad en el agente de servicio Cloud Run.

En la Figura 9, el campo principalEmail de authenticationInfo especifica la cuenta de servicio que se está utilizando (sa-test[@]xdr-analytics.iam.gserviceaccount[.]com).

El serviceAccountDelegationInfo muestra el principal de la primera parte (en este caso: service-<PROJECT_NUMBER>@serverless-robot-prod.iam.gserviceaccount[.]com), indicando que la cuenta de servicio está operando dentro de un entorno sin servidor como Cloud Functions o Cloud Run.

Un enfoque eficaz para descubrir identidades sin servidor es crear perfiles de cuentas de servicio que hayan delegado previamente su autoridad en cuentas de servicio sin servidor por defecto. De este modo se garantiza que incluso si se adjuntan cuentas de servicio no predeterminadas a las funciones, estas se identifiquen.

En AWS, las funciones Lambda se basan en roles IAM para el acceso seguro a los servicios de AWS. Estas funciones generan credenciales temporales. Podemos identificar la identidad Lambda por su nombre de rol.

En Azure, las identidades gestionadas adjuntas a Azure Function Apps se utilizan para la autenticación.

Paso 2: identificación de comportamientos inusuales en las identidades sin servidor

En un entorno de nube seguro, las funciones sin servidor suelen estar destinadas a realizar tareas automatizadas y de alcance limitado, como responder a solicitudes de API o procesar eventos. Estas funciones no deben utilizarse de forma interactiva. Sin embargo, si los atacantes obtienen acceso al entorno de una función sin servidor o a su identidad, podrían hacer un uso indebido para ejecutar comandos de interfaz de línea de comandos (CLI) (por ejemplo, gcloud CLI o curl) para interactuar directamente con los recursos de la nube.

Una forma de detección consiste en analizar el agente de usuario de las llamadas a la API. Si el agente de usuario coincide con herramientas CLI conocidas (por ejemplo, gcloud CLI) o marcos de pruebas de penetración, se marca como sospechoso, ya que las identidades sin servidor no deberían utilizar normalmente CLI. Esto indica una posible explotación de los tokens del entorno o de la cuenta de servicio.

Cabe destacar que este método de identificar el uso remoto de tokens de autenticación de funciones sin servidor según el agente de usuario no se puede realizar en Azure, ya que la información del agente de usuario no aparece en los registros de Azure.

Otro enfoque para detectar el uso remoto de un token de identidad sin servidor consiste en correlacionar la ubicación del uso de un token con rangos ASN de direcciones IP de proveedores de nube conocidos. Si una solicitud se origina en una dirección IP externa no asociada con el CSP, se activa una alerta que pone de manifiesto el posible uso no autorizado de tokens fuera del entorno de la nube.

Estrategias de prevención

Asegurar los tokens de autenticación de funciones sin servidor requiere una combinación de medidas proactivas, gestión de posturas y prácticas de seguridad de monitorización en tiempo de ejecución para minimizar el riesgo de explotación. En primer lugar, aplique el principio del menor privilegio asignando roles con los permisos mínimos necesarios para las funciones sin servidor. Esto reduce el impacto potencial del uso indebido de tokens.

Además, para proteger los entornos de ejecución sin servidor en GCP y Azure, restrinja el acceso a IMDS configurando controles a nivel de red y aplicando mecanismos de validación de solicitudes. Garantice una sólida validación y limpieza de entradas para evitar que los atacantes utilicen técnicas de explotación como SSRF para acceder a metadatos confidenciales, tokens y otros recursos de la nube como API y bases de datos.

Conclusión

La computación sin servidor es la opción preferida para el desarrollo de aplicaciones modernas porque ofrece ventajas significativas en escalabilidad, rentabilidad y gestión simplificada de la infraestructura.

Las credenciales que permiten a estas funciones interactuar con los servicios en la nube son un elemento de seguridad crítico y un objetivo prioritario para los atacantes. Comprometer estas credenciales puede acarrear graves consecuencias, como el acceso no autorizado a los recursos de la nube y la filtración de datos.

La implementación de protecciones proactivas de gestión de posturas y supervisión en tiempo de ejecución es una estrategia crucial para proteger los entornos en nube.

Las organizaciones pueden proteger mejor sus entornos sin servidor mediante:

• Comprender la mecánica de las credenciales sin servidor y las mejores prácticas para aprovisionarlas y administrarlas en AWS, Azure y GCP.
• Reconocimiento de vectores de ataque comunes, como la exfiltración de tokens mediante la explotación de IMDS o el acceso a variables de entorno.

Protección y mitigación de Palo Alto Networks

Los clientes de Palo Alto Networks están mejor protegidos frente a las amenazas mencionadas gracias a los siguientes productos:

Si cree que puede haber resultado vulnerado o tiene un problema urgente, póngase en contacto con el equipo de respuesta ante incidentes de Unit 42 o llame al:

• Teléfono gratuito para Norteamérica: +866.486.4842 (+866.4.UNIT42)
• EUROPA, ORIENTE MEDIO Y ÁFRICA: +31.20.299.3130
• APAC: +65.6983.8730
• Japón: +81.50.1790.0200

Palo Alto Networks ha compartido estos resultados con nuestros compañeros de Cyber Threat Alliance (CTA). Los miembros de CTA utilizan esta inteligencia para implementar rápidamente medidas de protección para sus clientes y desarticular sistemáticamente a los ciberdelincuentes. Más información sobre Cyber Threat Alliance.

Recursos adicionales

• Trabajar con variables de entorno de Lambda: guía de desarrollo de AWS Lambda
• Protección de las variables de entorno de Lambda: guía de desarrollo de AWS Lambda
• Administración de permisos en AWS Lambda: guía de desarrollo de AWS Lambda
• Función Identidad: Google Cloud
• ¿Qué son las identidades gestionadas para los recursos de Azure?: Microsoft Learn
• Protección de Azure Functions: Microsoft Learn
• ¿Qué es AWS Secrets Manager?: guía del usuario de AWS Secret Manager
• Conceptos básicos de Azure Key Vault: Microsoft Learn
• Descripción general de Secret Manager: documentación de Google Cloud Secret Manager
• ¿Qué es la gestión de identidades y accesos (IAM)?: Microsoft Security
• ¿Qué son las identidades gestionadas para los recursos de Azure?: Microsoft Learn
• Identidad y control de acceso: introducción a la seguridad de AWS Whitepaper de AWS
• Credenciales de la cuenta de servicio: documentación de Google Cloud IAM
• Credenciales de seguridad temporales en IAM: guía del usuario de la gestión de acceso e identidades de AWS
• Referencia de la API del servicio de tokens de seguridad de AWS: documentación del servicio de tokens de seguridad de AWS
• Instancias de Compute Engine: documentación sobre Google Cloud
• Proyectos de Google Cloud: documentación de Google Cloud
• Cuentas de servicio gestionadas por el usuario: documentación de Google Cloud
• Comparación de las funciones de Cloud Run: documentación de Cloud Run de Google
• Cuentas de servicio por defecto: documentación de Google Cloud
• Referencia de endpoint REST: identidades gestionadas para App Service y Azure Functions
• Variables de entorno y configuración de aplicaciones en Azure App Service: Microsoft Learn
• Cómo utilizar identidades gestionadas para recursos Azure en una máquina virtual Azure para adquirir un token de acceso: Microsoft Learn
• ¿Qué es Microsoft Entra ID?: Microsoft Entra ID
• Acerca de Azure Key Vault: Microsoft Learn
• Autorizar el acceso a blobs mediante Microsoft Entra ID: Microsoft Learn
• Descripción general de la cuenta de almacenamiento: Microsoft Learn
• ¿Qué es el control de acceso basado en rol de Azure (RBAC)?: Microsoft Learn
• Políticas de acceso a recursos específicos: Microsoft Learn