Compartir vía

Protección de acceso y datos de los flujos de trabajo en Azure Logic Apps

  • Artículo

Azure Logic Apps se basa en Azure Storage para almacenar y cifrar los datos en reposo automáticamente. Este cifrado protege los datos y le ayuda a cumplir los compromisos de cumplimiento y seguridad de la organización. De forma predeterminada, Azure Storage usa claves que administra Microsoft para cifrar sus datos. Para obtener más información, consulte Cifrado de Azure Storage para datos en reposo.

Para controlar el acceso y proteger los datos confidenciales en Azure Logic Apps aún más, puede configurar más seguridad en estas áreas:

Para obtener más información sobre la seguridad en Azure, consulte estos temas:

Acceso a las operaciones de las aplicaciones lógicas

Solo para las aplicaciones lógicas de consumo, antes de poder crear o administrar aplicaciones lógicas y sus conexiones, necesita permisos específicos que se proporcionan a través de roles, utilizando el control de acceso basado en roles de Azure (RBAC de Azure). También puede configurar permisos para que solo usuarios o grupos específicos puedan ejecutar tareas específicas, como administrar, editar y ver aplicaciones lógicas. Para controlar sus permisos, puede asignar roles integrados o personalizados a los miembros que tienen acceso a la suscripción de Azure. Azure Logic Apps tiene los siguientes roles específicos, en función de si tiene un flujo de trabajo de aplicación lógica Estándar o de Consumo:

Flujos de trabajo de consumo
Role Descripción
Colaborador de aplicación lógica Puede administrar flujos de trabajo de aplicación lógica, pero no puede cambiar el acceso a ellos.
Operador de aplicación lógica Puede leer, habilitar y deshabilitar flujos de trabajo de aplicación lógica, pero no puede editarlos ni actualizarlos.
Colaborador Tiene acceso completo para administrar todos los recursos, pero no puede asignar roles en Azure RBAC, administrar asignaciones en Azure Blueprints ni compartir galerías de imágenes.

Por ejemplo, imagine que tiene que trabajar con un flujo de trabajo de aplicación lógica que no ha creado y autenticar las conexiones usadas que usa el flujo de trabajo de esa aplicación lógica. La suscripción de Azure necesita permisos de Colaborador para el grupo de recursos que contiene el recurso de esa aplicación lógica. Si crea un recurso de aplicación lógica, tendrá acceso de colaborador automáticamente.

Para evitar que otros usuarios cambien o eliminen el flujo de trabajo de aplicación lógica, puede usar el Bloqueo de recursos de Azure. Esta funcionalidad evita que otros usuarios cambien o eliminen los recursos de producción. Para obtener más información sobre la seguridad de la conexión, revise Configuración de conexión en Azure Logic Apps y Seguridad y cifrado de la conexión.

Flujos de trabajo estándar

Nota:

Esta funcionalidad está en versión preliminar y está sujeta a las Condiciones de uso complementarias para las versiones preliminares de Microsoft Azure.

Role Descripción
Lector de Logic Apps Estándar (vista previa) Tiene acceso de solo lectura a todos los recursos de una aplicación lógica Estándar y los flujos de trabajo, incluidas las ejecuciones de flujo de trabajo y su historial.
Operador de Logic Apps Estándar (vista previa) Tiene acceso para habilitar, volver a enviar y deshabilitar flujos de trabajo y crear conexiones a servicios, sistemas y redes para una aplicación lógica Estándar. El rol de Operador puede realizar tareas de administración y soporte técnico en la plataforma Azure Logic Apps, pero no tiene permisos para editar flujos de trabajo o configuración.
Desarrollador de Logic Apps Estándar (vista previa) Tiene acceso para crear y editar flujos de trabajo, conexiones y configuraciones para una aplicación lógica Estándar. El rol de Desarrollador no tiene permisos para realizar cambios fuera del ámbito de los flujos de trabajo, por ejemplo, cambios en toda la aplicación, como configurar la integración de red virtual. No se admiten planes de App Service.
Colaborador de Logic Apps Estándar (vista previa) Tiene acceso para administrar todos los aspectos de una aplicación lógica estándar, pero no puede cambiar el acceso ni la propiedad.

Acceso a los datos del historial de ejecución

Durante la ejecución de una aplicación lógica, todos los datos se cifran en tránsito con Seguridad de la capa de transporte (TLS) y en reposo. Cuando finaliza la ejecución de la aplicación lógica, puede ver el historial de esa ejecución, incluidos los pasos que se ejecutaron junto con el estado, la duración, las entradas y las salidas de cada acción. Este completo detalle proporciona información sobre cómo se ejecuta la aplicación lógica y dónde puede empezar a solucionar los problemas que surjan.

Cuando visualiza el historial de ejecución de la aplicación lógica, Azure Logic Apps autentica su acceso y proporciona vínculos a las entradas y salidas para las solicitudes y respuestas de cada ejecución. Sin embargo, para las acciones que controlan contraseñas, secretos, claves u otra información confidencial, es recomendable evitar que otros usuarios vean los datos y accedan a ellos. Por ejemplo, si la aplicación lógica obtiene un secreto de Azure Key Vault para usarlo al autenticar una acción HTTP, puede ocultar ese secreto de la vista.

Para controlar el acceso a las entradas y salidas del historial de ejecución de la aplicación lógica, tiene estas opciones:

Restringir el acceso por intervalo de direcciones IP

Puede limitar el acceso a las entradas y salidas del historial de ejecución de los flujos de trabajo de su aplicación lógica para que solo las solicitudes de rangos de direcciones IP específicos puedan ver esos datos.

Por ejemplo, para impedir que alguien tenga acceso a las entradas y salidas, especifique un intervalo de direcciones IP como, por ejemplo, 0.0.0.0-0.0.0.0. Solo una persona con permisos de administrador puede eliminar esta restricción, lo que ofrece la posibilidad de acceder "Just-In-Time" a los datos de los flujos de trabajo de su app lógica. Un intervalo IP válido usa estos formatos: x.x.x.x/x o x.x.x.x-x.x.x.x

Para especificar los intervalos IP permitidos, siga estos pasos para la aplicación lógica de Consumo o Estándar en Azure Portal o en la plantilla de Azure Resource Manager:

Flujos de trabajo de consumo

  1. En Azure Portal, abra el flujo de trabajo de la aplicación lógica de consumo en el diseñador.

  2. En el menú de la aplicación lógica, en Configuración, seleccione Configuración del flujo de trabajo.

  3. En la sección Configuración del control de acceso, en Direcciones IP de entrada permitidas, en la lista Opción de acceso del desencadenador, seleccione Intervalos IP específicos.

  4. En el cuadro Intervalos IP para contenido, especifique los intervalos de direcciones IP que pueden acceder a contenido desde las entradas y salidas.

Flujos de trabajo estándar

  1. En Azure Portal, abra el recurso Aplicación lógica estándar.

  2. En el menú de la aplicación lógica, en Configuración, seleccione Redes.

  3. En la sección Configuración del tráfico entrante, junto a Acceso a la red pública, seleccione Habilitado sin restricción de acceso.

  4. En la página Restricciones de acceso, en Acceso a aplicaciones, seleccione Habilitado desde redes virtuales y direcciones IP seleccionadas.

  5. En Acceso y reglas del sitio, en la pestaña Sitio principal, agregue una o varias reglas para Permitir o Denegar solicitudes de intervalos IP específicos. También puede utilizar la configuración del filtro de encabezado HTTP y la configuración de reenvío. Un intervalo IP válido usa estos formatos: x.x.x.x/x o x.x.x.x-x.x.x.x

    Para más información, consulte Bloqueo de direcciones IP entrantes en Azure Logic Apps (Estándar).

Protección del historial de ejecución mediante ofuscación

Muchos desencadenadores y acciones cuentan con una configuración para proteger las entradas, las salidas, o ambas, en el historial de ejecución de una aplicación lógica. Todos los conectores administrados y conectores personalizados admiten estas opciones. Sin embargo, las siguientes operaciones integradas no admiten estas opciones:

Proteger entradas: no se admite Proteger salidas: no se admite
Anexar a la variable de matriz
Anexar a la variable de cadena
Reducir variable
For Each
Si
Incrementar variable
Inicializar la variable
Periodicidad
Ámbito
Establecer la variable
Switch
Terminate
Until		 Anexar a la variable de matriz
Anexar a la variable de cadena
Compose
Reducir variable
For Each
Si
Incrementar variable
Inicializar la variable
Parse JSON
Periodicidad
Response
Ámbito
Establecer la variable
Switch
Terminate
Until
Esperar

Consideraciones para proteger las entradas y salidas

Antes de usar esta configuración para proteger los datos, hay algunos aspectos que se deben tener en cuenta:

  • Cuando se ocultan las entradas o las salidas de un desencadenador o una acción, Azure Logic Apps no envía los datos protegidos a Azure Log Analytics. Además, no se pueden agregar propiedades con seguimiento al desencadenador o acción para su supervisión.

  • La API de Azure Logic Apps para controlar el historial del flujo de trabajo no devuelve salidas protegidas.

  • Para proteger las salidas de una acción que oculta las entradas o explícitamente las salidas, active de forma manual Salidas seguras en esa acción.

  • Asegúrese de activar las Entradas seguras o las Salidas seguras en las acciones de nivel inferior en las que espera que el historial de ejecución oculte los datos.

    Configuración de las salidas seguras

    Al activar manualmente Salidas seguras en un desencadenador o una acción, Azure Logic Apps oculta estas salidas en el historial de ejecución. Si una acción de nivel inferior usa explícitamente estas salidas protegidas como entradas, Azure Logic Apps oculta las entradas de esta acción en el historial de ejecución, pero no habilita la opción de Entradas seguras de la acción.

    Salidas seguras como entradas y repercusión descendente en la mayoría de las acciones

    Las acciones de redacción, análisis JSON y respuesta solo tienen la opción Entradas seguras. Cuando está activada, esta opción también oculta las salidas de estas acciones. Si estas acciones usan explícitamente las salidas protegidas de nivel superior como entradas, Azure Logic Apps ocultará las entradas y salidas de estas acciones, pero no habilitará la opción Entradas seguras de estas acciones. Si una acción de nivel inferior usa explícitamente las salidas ocultas de las acciones de redacción, análisis JSON o respuesta como entradas, Azure Logic Apps no oculta las entradas o salidas de la acción de nivel inferior.

    Salidas seguras como entradas y repercusión descendente en acciones especificas

    Opción Entradas seguras

    Al activar manualmente Entradas seguras en un desencadenador o una acción, Azure Logic Apps oculta estas entradas en el historial de ejecución. Si una acción de nivel inferior usa explícitamente las salidas visibles de ese desencadenador o acción como entradas, Azure Logic Apps oculta las entradas de esta acción de nivel inferior en el historial de ejecución, pero no habilita Entradas seguras en esta acción y no oculta las salidas de la acción.

    Entradas seguras y repercusión descendente en la mayoría de las acciones

    Si las acciones de redacción, análisis JSON y respuesta usan explícitamente las salidas visibles del desencadenador o la acción que tiene las entradas protegidas, Azure Logic Apps oculta las entradas y salidas de estas acciones, pero no habilita la opción Entradas seguras de la acción. Si una acción de nivel inferior usa explícitamente las salidas ocultas de las acciones de redacción, análisis JSON o respuesta como entradas, Azure Logic Apps no oculta las entradas o salidas de la acción de nivel inferior.

    Entradas seguras y repercusión descendente en determinadas acciones

Protección de entradas y salidas en el diseñador

  1. En Azure Portal abra el flujo de trabajo de la aplicación lógica en el diseñador.

  2. En el diseñador, seleccione el desencadenador o la acción donde quiera proteger los datos confidenciales.

  3. En el panel de información que se abre, seleccione Configuración y expanda Seguridad.

    Captura de pantalla que muestra Azure Portal, el diseñador de flujos de trabajo y el desencadenador o la acción con la configuración abierta.

  4. Active Entradas seguras, Salidas seguras o ambas opciones.

    Captura de pantalla que muestra el flujo de trabajo con la configuración de Entradas seguras o Salidas seguras de una acción habilitados.

    El activador o la acción muestra ahora un icono de candado en la barra de título. Cualquier token que represente las salidas protegidas de acciones anteriores también mostrará los iconos de bloqueo. Por ejemplo, en una acción posterior, después de seleccionar un token para una salida segura de la lista de contenido dinámico, ese token muestra un icono de candado.

    Captura de pantalla que muestra el flujo de trabajo con la lista de contenido dinámico de una acción posterior abierta y el token de la acción anterior para la salida segura con el icono de bloqueo.

  5. Después de que se ejecute el flujo de trabajo, puede ver el historial de esa ejecución.

    1. Seleccione Información general en el menú Aplicación lógica Consumo o en el menú Flujo de trabajo Estándar.

    2. En Historial de ejecuciones, seleccione la ejecución que desee ver.

    3. En el panel del historial de ejecución del flujo de trabajo, seleccione las acciones que desee revisar.

      Si eligió ocultar tanto las entradas como las salidas, estos valores aparecerán ahora ocultos.

      Captura de pantalla muestra la vista del historial de ejecución del flujo de trabajo estándar con entradas y salidas ocultas.

Protección de entradas y salidas en la vista Código

En la definición de desencadenador o acción subyacente, agregue o actualice la matriz runtimeConfiguration.secureData.properties con uno de estos valores o con ambos:

  • "inputs": Protege las entradas en el historial de ejecución.
  • "outputs": Protege las salidas en el historial de ejecución.
"<trigger-or-action-name>": {
   "type": "<trigger-or-action-type>",
   "inputs": {
      <trigger-or-action-inputs>
   },
   "runtimeConfiguration": {
      "secureData": {
         "properties": [
            "inputs",
            "outputs"
         ]
      }
   },
   <other-attributes>
}

Acceso a entradas de parámetros

Si implementa en entornos diferentes, considere la posibilidad de parametrizar los valores de la definición de flujo de trabajo que varían en función de esos entornos. De este modo, puede evitar los datos incluidos en el código mediante una plantilla de Azure Resource Manager para implementar la aplicación lógica, proteger los datos confidenciales definiendo parámetros seguros y pasar dichos datos como entradas separadas mediante los parámetros de la plantilla con un archivo de parámetros.

Por ejemplo, si autentica acciones HTTP con OAuth con Microsoft Entra ID, puede definir y ocultar los parámetros que aceptan el identificador de cliente y el secreto de cliente utilizados para la autenticación. Para definir estos parámetros en el flujo de trabajo de su aplicación lógica, utilice la sección parameters en la definición del flujo de trabajo de su aplicación lógica y la plantilla del Resource Manager para la implementación. Para proteger los valores de parámetros que no quiera mostrar al editar la aplicación lógica o visualizar el historial de ejecución, defina los parámetros con el tipo securestring o secureobject y use la codificación necesaria. Los parámetros de este tipo no se devuelven con la definición del recurso y no son accesibles al visualizar el recurso después de la implementación. Para tener acceso a estos valores de parámetro durante el tiempo de ejecución, use la expresión @parameters('<parameter-name>') dentro de la definición del flujo de trabajo. Esta expresión solo se evalúa en tiempo de ejecución y se describe con el lenguaje de definición de flujo de trabajo.

Nota

Si usa un parámetro en un cuerpo o encabezado de solicitud, dicho parámetro podría ser visible al visualizar el historial de ejecución del flujo de trabajo y la solicitud HTTP saliente. Asegúrese de definir también las directivas de acceso al contenido según corresponda. También puede usar la ofuscación para ocultar entradas y salidas en el historial de ejecución. De forma predeterminada, los encabezados de Authorization no son visibles a través de entradas o salidas. Por lo tanto, si aquí se usa un secreto, no se podrá recuperar.

Para obtener más información, consulte las secciones siguientes en este tema:

Si automatiza la implementación de aplicaciones lógicas con plantillas de Azure Resource Manager, puede definir parámetros de plantilla protegidos, que se evalúan en la implementación, mediante los tipos securestring y secureobject. Para definir parámetros de plantilla, use la sección parameters de nivel superior de la plantilla, que es independiente y diferente de la sección parameters de la definición de flujo de trabajo. Para proporcionar valores para los parámetros de plantilla, use un archivo de parámetros independiente.

Por ejemplo, si usa secretos, puede definir y usar parámetros de plantilla protegidos que recuperen dichos secretos de Azure Key Vault en la implementación. A continuación, puede hacer referencia a Key Vault y al secreto en el archivo de parámetros. Para obtener más información, consulte estos temas:

Parámetros seguros en definiciones de flujo de trabajo (flujo de trabajo de consumo)

Para proteger la información confidencial en la definición del flujo de trabajo de la aplicación lógica, utilice parámetros seguros para que esta información no sea visible después de guardar el flujo de trabajo de la aplicación lógica. Por ejemplo, supongamos que tiene una acción HTTP que requiere autenticación básica que usa un nombre de usuario y una contraseña. En la definición del flujo, la sección parameters define los parámetros basicAuthPasswordParam y basicAuthUsernameParam mediante el tipo securestring. A continuación, la definición de la acción hace referencia a estos parámetros en la sección authentication.

Importante

Para una seguridad óptima, Microsoft recomienda usar Microsoft Entra ID con identidades administradas para la autenticación cuando sea posible. Esta opción proporciona seguridad superior sin tener que proporcionar credenciales. Azure administra esta identidad y ayuda a proteger la información de autenticación para que no tenga que administrar esta información confidencial. Para establecer una identidad administrada para Azure Logic Apps, consulte Autenticación del acceso y las conexiones a los recursos de Azure con identidades administradas en Azure Logic Apps.

"definition": {
   "$schema": "https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json#",
   "actions": {
      "HTTP": {
         "type": "Http",
         "inputs": {
            "method": "GET",
            "uri": "https://www.microsoft.com",
            "authentication": {
               "type": "Basic",
               "username": "@parameters('basicAuthUsernameParam')",
               "password": "@parameters('basicAuthPasswordParam')"
            }
         },
         "runAfter": {}
      }
   },
   "parameters": {
      "basicAuthPasswordParam": {
         "type": "securestring"
      },
      "basicAuthUsernameParam": {
         "type": "securestring"
      }
   },
   "triggers": {
      "manual": {
         "type": "Request",
         "kind": "Http",
         "inputs": {
            "schema": {}
         }
      }
   },
   "contentVersion": "1.0.0.0",
   "outputs": {}
}

Parámetros seguros en plantillas de Azure Resource Manager (flujo de trabajo de consumo)

Una plantilla de Resource Manager para un recurso y flujo de trabajo de aplicación lógica tiene varias parameters secciones. Para proteger las contraseñas, las claves, los secretos y otros datos confidenciales, defina parámetros seguros en el nivel de plantilla y de definición de flujo de trabajo mediante el tipo securestring o secureobject. Después, puede almacenar estos valores en Azure Key Vault y usar el archivo de parámetros para hacer referencia al almacén de claves y al secreto. A continuación, la plantilla recupera esa información en la implementación. Para obtener más información, consulte Uso de Azure Key Vault para pasar valores confidenciales durante la implementación.

Importante

Para una seguridad óptima, Microsoft recomienda usar Microsoft Entra ID con identidades administradas para la autenticación cuando sea posible. Esta opción proporciona seguridad superior sin tener que proporcionar credenciales. Azure administra esta identidad y ayuda a proteger la información de autenticación para que no tenga que administrar esta información confidencial. Para establecer una identidad administrada para Azure Logic Apps, consulte Autenticación del acceso y las conexiones a los recursos de Azure con identidades administradas en Azure Logic Apps.

Esta lista incluye más información sobre estas secciones parameters:

  • En el nivel superior de la plantilla, una sección parameters define los parámetros de los valores que utiliza la plantilla durante la implementación. Por ejemplo, estos valores pueden incluir cadenas de conexión para un entorno de implementación concreto. Después, puede almacenar estos valores en un archivo de parámetros, lo que facilita la modificación de estos valores.

  • Dentro de la definición de recursos de la aplicación lógica, pero fuera de la definición del flujo de trabajo, una sección parameters especifica los valores de los parámetros de la definición del flujo de trabajo. En esta sección, puede asignar estos valores mediante expresiones de plantilla que hagan referencia a los parámetros de la plantilla. Estas expresiones se evalúan en la implementación.

  • Dentro de la definición de su flujo de trabajo, una sección parameters define los parámetros que su flujo de trabajo de aplicación lógica utiliza en tiempo de ejecución. Después, puede hacer referencia a estos parámetros en el flujo de trabajo de la aplicación lógica mediante expresiones de definición de flujo de trabajo, que se evalúan en tiempo de ejecución.

Esta plantilla de ejemplo tiene varias definiciones de parámetros seguros que usan el tipo securestring:

Nombre de parámetro Descripción
TemplatePasswordParam Parámetro de plantilla que acepta una contraseña que se pasa, a continuación, al parámetro basicAuthPasswordParam de la definición del flujo de trabajo.
TemplateUsernameParam Parámetro de plantilla que acepta un nombre de usuario que se pasa a continuación al parámetro basicAuthUserNameParam de la definición del flujo de trabajo
basicAuthPasswordParam Parámetro de definición de flujo de trabajo que acepta la contraseña para la autenticación básica en una acción HTTP
basicAuthUserNameParam Parámetro de definición de flujo de trabajo que acepta el nombre de usuario para la autenticación básica en una acción HTTP 
{
   "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
   "contentVersion": "1.0.0.0",
   "parameters": {
      "LogicAppName": {
         "type": "string",
         "minLength": 1,
         "maxLength": 80,
         "metadata": {
            "description": "Name of the Logic App."
         }
      },
      "TemplatePasswordParam": {
         "type": "securestring"
      },
      "TemplateUsernameParam": {
         "type": "securestring"
      },
      "LogicAppLocation": {
         "type": "string",
         "defaultValue": "[resourceGroup().location]",
         "allowedValues": [
            "[resourceGroup().location]",
            "eastasia",
            "southeastasia",
            "centralus",
            "eastus",
            "eastus2",
            "westus",
            "northcentralus",
            "southcentralus",
            "northeurope",
            "westeurope",
            "japanwest",
            "japaneast",
            "brazilsouth",
            "australiaeast",
            "australiasoutheast",
            "southindia",
            "centralindia",
            "westindia",
            "canadacentral",
            "canadaeast",
            "uksouth",
            "ukwest",
            "westcentralus",
            "westus2"
         ],
         "metadata": {
            "description": "Location of the Logic App."
         }
      }
   },
   "variables": {},
   "resources": [
      {
         "name": "[parameters('LogicAppName')]",
         "type": "Microsoft.Logic/workflows",
         "location": "[parameters('LogicAppLocation')]",
         "tags": {
            "displayName": "LogicApp"
         },
         "apiVersion": "2016-06-01",
         "properties": {
            "definition": {
               "$schema": "https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json#",
               "actions": {
                  "HTTP": {
                     "type": "Http",
                     "inputs": {
                        "method": "GET",
                        "uri": "https://www.microsoft.com",
                        "authentication": {
                           "type": "Basic",
                           "username": "@parameters('basicAuthUsernameParam')",
                           "password": "@parameters('basicAuthPasswordParam')"
                        }
                     },
                  "runAfter": {}
                  }
               },
               "parameters": {
                  "basicAuthPasswordParam": {
                     "type": "securestring"
                  },
                  "basicAuthUsernameParam": {
                     "type": "securestring"
                  }
               },
               "triggers": {
                  "manual": {
                     "type": "Request",
                     "kind": "Http",
                     "inputs": {
                        "schema": {}
                     }
                  }
               },
               "contentVersion": "1.0.0.0",
               "outputs": {}
            },
            "parameters": {
               "basicAuthPasswordParam": {
                  "value": "[parameters('TemplatePasswordParam')]"
               },
               "basicAuthUsernameParam": {
                  "value": "[parameters('TemplateUsernameParam')]"
               }
            }
         }
      }
   ],
   "outputs": {}
}

Tipos de autenticación para conectores que admiten la autenticación

En la siguiente tabla se identifican los tipos de autenticación que están disponibles en las operaciones del conector donde puede seleccionar un tipo de autenticación:

Tipo de autenticación Conectores admitidos y aplicaciones lógicas
Basic Azure API Management, Azure App Service, HTTP, HTTP y Swagger, webhook HTTP
Certificado de cliente Azure API Management, Azure App Service, HTTP, HTTP y Swagger, webhook HTTP
OAuth de Active Directory (OAuth 2.0 con Microsoft Entra ID) - Consumo: Azure API Management, Azure App Service, Azure Functions, HTTP, HTTP + Swagger, Webhook HTTP

- Estándar: Azure Automation, Azure Blob Storage, Azure Event Hubs, Colas de Azure, Azure Service Bus, Tablas de Azure, HTTP, Webhook HTTP, SQL Server
Sin formato Azure API Management, Azure App Service, Azure Functions, HTTP, HTTP + Swagger, webhook HTTP
Identidad administrada Conectores integrados:

- Consumo: Azure API Management, Azure App Service, Azure Functions, HTTP, Webhook HTTP

- Estándar: Azure Automation, Azure Blob Storage, Azure Event Hubs, Colas de Azure, Azure Service Bus, Tablas de Azure, HTTP, Webhook HTTP, SQL Server

Nota: Actualmente, la mayoría de los conectores integrados basados en proveedores de servicios no admiten la selección de identidades administradas asignadas por el usuario para la autenticación.

Conector administrado: Azure App Service, Azure Automation, Azure Blob Storage, Azure Container Instances, Azure Cosmos DB, Azure Data Explorer, Azure Data Factory, Azure Data Lake, Azure Event Grid, Azure Event Hubs, Azure IoT Central V2, Azure IoT Central V3, Azure Key Vault, Azure Log Analytics, Azure Queues, Azure Resource Manager, Azure Service Bus, Azure Sentinel, Azure Table Storage, Azure VM, HTTP con Microsoft Entra ID, SQL Server

Importante

Para una seguridad óptima, Microsoft recomienda usar Microsoft Entra ID con identidades administradas para la autenticación cuando sea posible. Esta opción proporciona seguridad superior sin tener que proporcionar credenciales. Azure administra esta identidad y ayuda a proteger la información de autenticación para que no tenga que administrar esta información confidencial. Para establecer una identidad administrada para Azure Logic Apps, consulte Autenticación del acceso y las conexiones a los recursos de Azure con identidades administradas en Azure Logic Apps.

Acceso de las llamadas entrantes a desencadenadores basados en solicitud

Las llamadas entrantes que una aplicación lógica recibe a través de un desencadenador basado en solicitud, como el desencadenador Solicitud o el desencadenador Webhook de HTTP, admiten el cifrado y se protegen con la versión 1.2 de Seguridad de la capa de transporte (TLS), como mínimo, que antes se conocía como Capa de sockets seguros (SSL). Azure Logic Apps aplica esta versión al recibir una llamada entrante al desencadenador Solicitud o una devolución de llamada al desencadenador o acción Webhook de HTTP.

Nota:

Si obtiene errores de protocolo de enlace TLS, asegúrese de usar TLS 1.2. Para más información, consulte Solución del problema de TLS 1.0.

Para las llamadas entrantes, use los siguientes conjuntos de cifrado:

  • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
  • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

Importante

Para obtener compatibilidad con las versiones anteriores, Azure Logic Apps admite actualmente algunos conjuntos de cifrado antiguos. Sin embargo, no use conjuntos de cifrado antiguos cuando desarrolle nuevas aplicaciones, ya que estos conjuntos puede que no se admitan en el futuro.

Por ejemplo, puede encontrar los siguientes conjuntos de cifrado si inspecciona los mensajes de protocolo de enlace TLS en Azure Logic Apps o mediante una herramienta de seguridad en la dirección URL de la aplicación lógica. Recuerde que no debe usar estos conjuntos antiguos:

  • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
  • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
  • TLS_RSA_WITH_AES_256_GCM_SHA384
  • TLS_RSA_WITH_AES_128_GCM_SHA256
  • TLS_RSA_WITH_AES_256_CBC_SHA256
  • TLS_RSA_WITH_AES_128_CBC_SHA256
  • TLS_RSA_WITH_AES_256_CBC_SHA
  • TLS_RSA_WITH_AES_128_CBC_SHA
  • TLS_RSA_WITH_3DES_EDE_CBC_SHA

La siguiente lista incluye las formas en que puede limitar el acceso a los desencadenadores que reciben llamadas entrantes al flujo de trabajo de su aplicación lógica, de modo que solo los clientes autorizados puedan llamar a su flujo de trabajo:

Habilitación de OAuth 2.0 con Microsoft Entra ID

En un flujo de trabajo de Consumo que comienza con un desencadenador basado en una solicitud, puede autenticar y autorizar las llamadas entrantes enviadas al punto de conexión creado por ese desencadenador habilitando OAuth 2.0 con Microsoft Entra ID. Para establecer esta autenticación, defina o agregue una directiva de autorización en el nivel de recursos de la aplicación lógica. De este modo, las llamadas entrantes usan tokens de acceso de OAuth para la autorización.

Cuando el flujo de trabajo de su aplicación lógica recibe una solicitud entrante que incluye un token de acceso OAuth, Azure Logic Apps compara las reclamaciones del token con las reclamaciones especificadas por cada directiva de autorización. Si existe una coincidencia entre las notificaciones del token y todas las notificaciones en al menos una directiva, la autorización de la solicitud entrante se realiza correctamente. El token puede tener más notificaciones que el número especificado por la directiva de autorización.

En un flujo de trabajo estándar que comience con el desencadenador Solicitud (pero no con un desencadenador de webhook), puede utilizar la provisión de Azure Functions para autenticar las llamadas entrantes enviadas al punto de conexión creado por el desencadenador Solicitud utilizando una identidad administrada. Este aprovisionamiento también se denomina "Easy Auth". Para más información, consulte Desencadenamiento de flujos de trabajo en Aplicaciones lógicas estándar con Easy Auth.

Consideraciones antes de habilitar OAuth 2.0 con Microsoft Entra ID

  • Para una seguridad óptima, Microsoft recomienda usar Microsoft Entra ID con identidades administradas para la autenticación cuando sea posible. Esta opción proporciona seguridad superior sin tener que proporcionar credenciales. Azure administra esta identidad y ayuda a proteger la información de autenticación para que no tenga que administrar esta información confidencial. Para establecer una identidad administrada para Azure Logic Apps, consulte Autenticación del acceso y las conexiones a los recursos de Azure con identidades administradas en Azure Logic Apps.

  • En los flujos de trabajo de Consumo, las llamadas entrantes a la dirección URL del punto de conexión para un desencadenador basado en una solicitud pueden usar solo un esquema de autorización, ya sea OAuth 2.0 con Microsoft Entra ID o Firma de acceso compartido (SAS). Aunque usar un esquema no deshabilita el otro, si usa ambos al mismo tiempo, Azure Logic Apps genera un error porque el servicio no sabe qué esquema elegir. Si su flujo de trabajo de Consumo comienza con el desencadenador Solicitud, puede deshabilitar la autenticación de SAS así como restringir la autorización para usar solo OAuth 2.0 con Microsoft Entra ID. En el caso de los flujos de trabajo estándar, puede usar otros tipos de autenticación sin deshabilitar SAS.

  • Azure Logic Apps admite los esquemas de autorización de tipo portador o de tipo de prueba de posesión (solo aplicación lógica de consumo) para los tokens de acceso de Microsoft Entra ID OAuth. Sin embargo, el encabezado Authorization del token de acceso debe especificar el tipo Bearer o el tipo PoP. Para obtener más información sobre cómo obtener y usar un token de PoP, consulte Obtener un token de prueba de posesión (PoP).

  • El recurso de su aplicación lógica de Consumo está limitado a un número máximo de directivas de autorización. Cada directiva de autorización también tiene un número máximo de notificaciones. Para más información, consulte el artículo de límites y configuración para Azure Logic Apps.

  • Una directiva de autorización debe incluir al menos la notificación de Emisor, que tiene un valor que comienza por https://sts.windows.net/ o https://login.microsoftonline.com/ (OAuth V2) como de emisor de Microsoft Entra ID.

    Por ejemplo, supongamos que su recurso de aplicación lógica tiene una directiva de autorización que requiere dos tipos de reclamaciones, Audiencia y Emisor. En este ejemplo de sección de carga para un token de acceso descodificado se incluyen los dos tipos de notificaciones, donde aud es el valor Audiencia y iss el valor Emisor:

    {
    "aud": "https://management.core.windows.net/",
    "iss": "https://sts.windows.net/<Azure-AD-issuer-ID>/",
    "iat": 1582056988,
    "nbf": 1582056988,
    "exp": 1582060888,
    "_claim_names": {
       "groups": "src1"
    },
    "_claim_sources": {
       "src1": {
          "endpoint": "https://graph.windows.net/7200000-86f1-41af-91ab-2d7cd011db47/users/00000-f433-403e-b3aa-7d8406464625d7/getMemberObjects"
       }
    },
    "acr": "1",
    "aio": "AVQAq/8OAAAA7k1O1C2fRfeG604U9e6EzYcy52wb65Cx2OkaHIqDOkuyyr0IBa/YuaImaydaf/twVaeW/etbzzlKFNI4Q=",
    "amr": [
       "rsa",
       "mfa"
    ],
    "appid": "c44b4083-3bb0-00001-b47d-97400853cbdf3c",
    "appidacr": "2",
    "deviceid": "bfk817a1-3d981-4dddf82-8ade-2bddd2f5f8172ab",
    "family_name": "Sophia Owen",
    "given_name": "Sophia Owen (Fabrikam)",
    "ipaddr": "167.220.2.46",
    "name": "sophiaowen",
    "oid": "3d5053d9-f433-00000e-b3aa-7d84041625d7",
    "onprem_sid": "S-1-5-21-2497521184-1604012920-1887927527-21913475",
    "puid": "1003000000098FE48CE",
    "scp": "user_impersonation",
    "sub": "KGlhIodTx3XCVIWjJarRfJbsLX9JcdYYWDPkufGVij7_7k",
    "tid": "aaaabbbb-0000-cccc-1111-dddd2222eeee",
    "unique_name": "SophiaOwen@fabrikam.com",
    "upn": "SophiaOwen@fabrikam.com",
    "uti": "TPJ7nNNMMZkOSx6_uVczUAA",
    "ver": "1.0"
}

Habilitar OAuth 2.0 con Microsoft Entra ID como única opción para llamar a un punto de conexión de solicitud (solo Consumo)

Para puntos de conexión basados en solicitudes, puede restringir la autorización para usar solo OAuth 2.0 con Microsoft Entra ID. Esta opción funciona incluso si también se deshabilita la autenticación de firma de acceso compartido (SAS).

  1. Para su flujo de trabajo de Consumo, configure su desencadenador Solicitud o su desencadenador Webhook de HTTP con la capacidad de comprobar el token de acceso de OAuth siguiendo los pasos para incluir el encabezado 'Autorización' en las salidas del desencadenador Solicitud o HTTP webhook.

    Nota:

    Este paso hace que el encabezado Authorization sea visible en el historial de ejecución del flujo de trabajo y en las salidas del desencadenador.

  2. En Azure Portal, abra el flujo de trabajo de Consumo en el diseñador.

  3. En el diseñador, seleccione el desencadenador. En el panel de información que se abre, seleccione Configuración.

  4. En General>Condiciones del desencadenador, seleccione Agregar. En el cuadro de condición del desencadenador, escriba cualquiera de las siguientes expresiones en función del tipo de token que quiera usar:

    @startsWith(triggerOutputs()?['headers']?['Authorization'], 'Bearer')

    O bien

    @startsWith(triggerOutputs()?['headers']?['Authorization'], 'PoP')

Si llama al punto de conexión del desencadenador sin la autorización correcta, el historial de ejecución solo muestra el desencadenador como Skipped, sin ningún mensaje de error en la condición del desencadenador.

Obtener un token de prueba de posesión (PoP)

Las bibliotecas de MSAL (Biblioteca de autenticación de Microsoft) proporcionan tokens de PoP para que los use. Si el flujo de trabajo de Consumo de la aplicación lógica a la que desea llamar requiere un token de PoP, puede obtener este token mediante las bibliotecas de MSAL. En los ejemplos siguientes se muestra cómo adquirir tokens de PoP:

Para usar el token de PoP con el flujo de trabajo de aplicación lógica de Consumo, siga los pasos siguientes para configurar OAuth con Microsoft Entra ID.

Habilitar OAuth con Microsoft Entra ID para el recurso de su aplicación lógica de Consumo

Para agregar una directiva de autorización a su aplicación lógica de Consumo, siga los pasos correspondientes a la plantilla de Azure Portal o de Azure Resource Manager:

  1. En el Azure Portal, abra su aplicación lógica de consumo y su flujo de trabajo en el diseñador.

  2. En el menú de la aplicación lógica, en Configuración, seleccione Autorización.

  3. En la página Autorización, seleccione Añadir directiva.

    Recorte de pantalla que muestra Azure Portal, la página de Autorización y el botón seleccionado para agregar directivas.

  4. Proporcione información sobre la directiva de autorización; puede especificar los tipos de notificaciones y los valores que espera la aplicación lógica en el token de acceso presentado por cada llamada entrante al desencadenador Solicitud:

    Recorte de pantalla que muestra Azure Portal, la página de Autorización y los detalles de la directiva de autorización.

    Propiedad Obligatorio Type Descripción
    Nombre de directiva Sí String El nombre que quiere usar para la directiva de autorización.
    Tipo de directiva Sí Cadena AAD para tokens de tipo portador o AADPOP para tokens de tipo prueba de posesión.
    Notificaciones Sí Cadena Un par clave-valor que especifica el tipo de notificación y el valor que el desencadenador de solicitud del flujo de trabajo espera en el token de acceso presentado por cada llamada entrante al desencadenador. Puede agregar cualquier notificación estándar que desee seleccionando Agregar notificación estándar. Para agregar una notificación específica de un token de PoP, seleccione Agregar notificación personalizada.

    Tipos de notificaciones estándar disponibles:

    - Emisor
    - Audiencia
    - Asunto
    - Id. de JWT (identificador de JSON Web Token)

    Requisitos:

    Como mínimo, la lista Notificaciones debe incluir la notificación de Emisor, que tiene un valor que comienza por https://sts.windows.net/ o https://login.microsoftonline.com/ como identificador de emisor de Microsoft Entra.

    - Cada notificación debe ser un valor de cadena único, no una matriz de valores. Por ejemplo, puede haber una notificación con Rol como tipo y Desarrollador como valor. No puede haber una notificación que tenga Rol como tipo y los valores establecidos en Desarrollador y Administrador de programas.

    - El valor de la notificación está limitado a un número máximo de caracteres.

    Para obtener más información sobre estos tipos de notificación, consulte Notificaciones de tokens de seguridad de Microsoft Entra. También puede especificar su propio tipo de notificaciones y valor.

    En el ejemplo siguiente se muestra la información de un token de PoP:

    Recorte de pantalla que muestra Azure Portal, la página de autorización y la información sobre la directiva de prueba de posesión.

  5. Para agregar otra notificación, seleccione una de estas opciones:

    • Para agregar otro tipo de notificaciones, seleccione Add standard claim (Agregar notificación estándar), seleccione el tipo de notificación y especifique su valor.

    • Para agregar su propia notificación, seleccione Agregar notificación personalizada. Para obtener más información, consulte Procedimientos: Proporcionar notificaciones opcionales a la aplicación. La notificación personalizada se almacena después como parte del id. de JWT; por ejemplo, "tid": "aaaabbbb-0000-cccc-1111-dddd2222eeee".

  6. Para agregar otra directiva de autorización, seleccione Agregar directiva. Repita los pasos anteriores para configurar la directiva.

  7. Cuando finalice, seleccione Guardar.

  8. Para incluir el encabezado Authorization del token de acceso en las salidas del desencadenador basado en solicitudes, consulte Inclusión del encabezado "Authorization" en las salidas del desencadenador de solicitud y de webhook HTTP.

Las propiedades de flujo de trabajo, como las directivas, no aparecen en la vista de código de flujo de trabajo en Azure Portal. Para acceder a las directivas mediante programación, llame a la siguiente API a través de Azure Resource Manager: https://management.azure.com/subscriptions/{Azure-subscription-ID}/resourceGroups/{Azure-resource-group-name}/providers/Microsoft.Logic/workflows/{your-workflow-name}?api-version=2016-10-01&_=1612212851820. Asegúrese de reemplazar los valores de marcador de posición para el identificador de suscripción de Azure, el nombre del grupo de recursos y el nombre del flujo de trabajo.

Incluir el encabezado "Authorization" en las salidas del desencadenador de solicitud o de webhook HTTP

En el caso de las aplicaciones lógicas que habilitan OAuth con Microsoft Entra ID para autorizar el acceso de las llamadas entrantes a desencadenadores por solicitud, puede habilitar que las salidas del desencadenador Solicitud o Webhook de HTTP incluyan el encabezado Authorization del token de acceso de OAuth. En la definición de JSON subyacente del desencadenador, agregue y establezca la propiedad operationOptions en IncludeAuthorizationHeadersInOutputs. Este es un ejemplo del desencadenador Solicitud:

"triggers": {
   "manual": {
      "inputs": {
         "schema": {}
      },
      "kind": "Http",
      "type": "Request",
      "operationOptions": "IncludeAuthorizationHeadersInOutputs"
   }
}

Para obtener más información, consulte estos temas:

Generación de un token de firma de acceso compartido (SAS) o token

Cuando un flujo de trabajo comienza con un desencadenador basado en solicitudes y guarda ese flujo de trabajo por primera vez, Azure Logic Apps crea un punto de conexión al que se puede llamar en ese desencadenador. Este punto de conexión tiene una dirección URL que puede recibir llamadas entrantes o solicitudes para iniciar el flujo de trabajo. La dirección URL incluye una Firma de acceso compartido (SAS), que es una clave o token que concede permisos, por ejemplo, a los servicios de almacenamiento. Esta dirección URL del punto de conexión usa el siguiente formato:

https://<request-endpoint-URI>sp=<permissions>sv=<SAS-version>sig=<signature>

Por ejemplo, para ver esta dirección URL en un desencadenador Solicitud, busque la propiedad HTTP URL del desencadenador:

Recorte de pantalla que muestra Azure Portal, el diseñador de flujo de trabajo de Consumo y la URL del punto de conexión del desencadenador de solicitudes.

La dirección URL completa tiene el siguiente aspecto:

https://{domain}:443/workflows/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX/triggers/When_a_HTTP_request_is_received/paths/invoke?api-version=2016-10-01&sp=%2Ftriggers%2FWhen_a_HTTP_request_is_received%2Frun&sv=1.0&sig=ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ

La SAS de la dirección URL tiene parámetros de consulta, que se describen en la tabla siguiente:

Parámetro de consulta Descripción
sp Especifica los permisos para los métodos HTTP permitidos que se usarán.
sv Especifica la versión de SAS que se usará para generar la firma.
sig Especifica la firma que se usará para autenticar el acceso al desencadenador. Esta firma se genera mediante el algoritmo SHA256 con una clave de acceso secreta en todas las rutas de acceso de direcciones URL y propiedades. Esta clave se mantiene en secreto y cifrada, se almacena con la aplicación lógica y nunca se expone ni se publica. La aplicación lógica solo autoriza los desencadenadores que contienen una firma válida creada con la clave secreta.

Importante

Asegúrese de proteger la clave SAS al mismo tiempo que protege una clave de cuenta frente al uso no autorizado. Configure o tenga un plan para revocar una clave de acceso en peligro. Sea discreto cuando distribuya URI que utilicen claves de acceso, y distribuya dichos URI únicamente a través de una conexión segura como HTTPS. Asegúrese de realizar solo operaciones que usen una clave de acceso a través de una conexión HTTPS. Cualquiera que tenga un URI con una clave válida puede acceder al recurso asociado. Para mantener la seguridad y proteger el acceso al flujo de trabajo de la aplicación lógica, regenerar las claves de acceso con regularidad, ya que podían tener que cumplir las directivas de seguridad o verse en peligro. De este modo, puede asegurarse de que solo las solicitudes autorizadas pueden desencadenar el flujo de trabajo, que protege los datos y los procesos del acceso no autorizado.

Si utiliza una clave SAS para acceder a los servicios de almacenamiento, Microsoft recomienda crear una SAS de delegación de usuario, que esté protegida con Microsoft Entra ID, en lugar de una clave de cuenta.

Para una seguridad óptima, Microsoft recomienda usar Microsoft Entra ID con identidades administradas para la autenticación siempre que sea posible. Esta opción proporciona seguridad superior sin tener que proporcionar credenciales. Azure administra esta identidad y ayuda a proteger la información de autenticación para que no tenga que administrar esta información confidencial. Para establecer una identidad administrada para Azure Logic Apps, consulte Autenticación del acceso y las conexiones a los recursos de Azure con identidades administradas en Azure Logic Apps.

Las llamadas entrantes al punto de conexión en un desencadenador basado en una solicitud pueden usar solo un esquema de autorización, ya sea SAS o OAuth 2.0 con Microsoft Entra ID. Aunque usar un esquema no deshabilita el otro, si usa ambos al mismo tiempo, Azure Logic Apps genera un error porque el servicio no sabe qué esquema elegir.

Si tiene un flujo de trabajo de Consumo que comienza con el desencadenador Solicitud, puede deshabilitar la autenticación SAS. Esta opción funciona incluso si también restringe la autorización para usar solo OAuth 2.0 con Microsoft Entra ID. En el caso de los flujos de trabajo estándar, puede usar otros tipos de autenticación sin deshabilitar SAS.

Para obtener más información sobre la seguridad al usar una clave SAS, consulte las secciones siguientes de esta guía:

Deshabilitar la autenticación de firma de acceso compartido (SAS) (solo para Consumo)

De manera predeterminada, un desencadenador basado en una solicitud tiene habilitada la autenticación SAS. La URL del punto de conexión del desencadenador incluye una SAS, que comienza con los parámetros de consulta, sp-<permissions>sv-<SAS-version>sig=<signature>, por ejemplo:

https://{domain}:443/workflows/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX/triggers/When_a_HTTP_request_is_received/paths/invoke?api-version=2016-10-01&sp=%2Ftriggers%2FWhen_a_HTTP_request_is_received%2Frun&sv=1.0&sig=ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ

Si su flujo de trabajo de Consumo comienza con el desencadenador Solicitud, y quiere usar OAuth con Microsoft Entra ID, puede deshabilitar la autenticación de SAS para evitar errores y problemas en la ejecución de su flujo de trabajo. También agrega una capa de seguridad al eliminar la dependencia de los secretos, lo que reduce el riesgo de que se registren o se filtren.

Esta opción funciona incluso si también habilita OAuth 2.0 con Microsoft Entra ID como única opción para llamar a un punto de conexión basado en solicitud. En el caso de los flujos de trabajo estándar, puede usar otros tipos de autenticación sin deshabilitar SAS.

Nota:

Esta acción deshabilita la autenticación SAS para las solicitudes entrantes y impide que las firmas o claves de SAS existentes funcionen. Sin embargo, las claves o firmas de SAS siguen siendo válidos y siguen funcionando si habilita la autenticación SAS de nuevo. Para deshabilitar las claves y firmas de SAS mediante la creación de nuevas versiones, consulte Regenerar claves de acceso.

Después de deshabilitar la autenticación de SAS, la dirección URL del punto de conexión del desencadenador Solicitud ya no incluye la clave SAS, por ejemplo:

https://{domain}:443/workflows/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX/triggers/When_a_HTTP_request_is_received/paths/invoke?api-version=2016-10-01

Requisitos previos

Para esta tarea, necesita una herramienta para enviar llamadas a la API de REST, por ejemplo:

Precaución

En escenarios en los que tiene datos confidenciales, como credenciales, secretos, tokens de acceso, claves de API y otra información similar, asegúrese de usar una herramienta que proteja los datos con las características de seguridad necesarias, funcione sin conexión o localmente, no sincronice los datos en la nube y no requiera que inicie sesión en una cuenta en línea. De este modo, se reduce el riesgo de exponer datos confidenciales al público.

Comprobación de desencadenadores con SAS habilitado o deshabilitado

Cuando la autenticación de SAS está deshabilitada, la dirección URL del punto de conexión del desencadenador ya no incluye la clave SAS. Además, la definición de flujo de trabajo de Consumo incluye el objeto JSON sasAuthenticationPolicy. Este objeto tiene una propiedad state que se establece en Deshabilitado, por ejemplo:

"properties": {
    "accessControl": {
        "triggers": {
            "sasAuthenticationPolicy": {
                "state": "Disabled"
            }
        }
    }
}

Para encontrar los flujos de trabajo de Consumo en los que SAS está habilitada o deshabilitada, compruebe si la definición del flujo de trabajo incluye el objeto sasAuthenticationPolicy en el que la propiedad state está establecida en Deshabilitada.

  1. Con su herramienta que envía llamadas a la API de REST, obtenga información sobre su flujo de trabajo ejecutando la operación Workflows - Get usando la siguiente solicitud GET, por ejemplo:

    GET https://management.azure.com/subscriptions/{subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Logic/workflows/{workflow-name}?api-version=2016-06-01

  2. Tome la salida de la operación Workflows - Get y compruebe si existe el objeto sasAuthenticationPolicy en el que la propiedad state esté establecida en Deshabilitada.

Agregar la propiedad sasAuthenticationPolicy a la definición de su flujo de trabajo

Para flujos de trabajo de Consumo en los que desea deshabilitar la autenticación SAS, siga estos pasos:

  1. Si aún no lo ha hecho, obtenga información sobre su flujo de trabajo ejecutando la operación Workflows - Get usando la siguiente solicitud GET, por ejemplo:

    GET https://management.azure.com/subscriptions/{subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Logic/workflows/{workflow-name}?api-version=2016-06-01

  2. Tome la salida de la operación Workflows - Get y agregue manualmente los siguientes elementos:

    1. En el objeto properties, agregue un objeto accessControl que contenga un objeto triggers, si no existe ninguno.

    2. En el objeto triggers, agregue un objeto sasAuthenticationPolicy que contenga la propiedad state establecida en Disabled.

    Cuando termine, el elemento editado será similar al ejemplo siguiente:

    "properties": {
    "accessControl": {
        "triggers": {
            "sasAuthenticationPolicy": {
                "state": "Disabled"
            }
        }
    }
}

  3. Envíe otra solicitud para actualizar el flujo de trabajo con la salida editada, que se usa como entrada en el cuerpo de la solicitud, ejecutando la operación Flujos de trabajo: Actualizar mediante la siguiente solicitud PUT, por ejemplo:

    PUT https://management.azure.com/subscriptions/{subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Logic/workflows/{workflow-name}?api-version=2016-06-01

  4. En Azure Portal, vaya a su flujo de trabajo de Consumo en el diseñador y confirme que la dirección URL del desencadenador Solicitud ya no incluye la SAS.

  5. Para habilitar Oauth 2.0 con Microsoft Entra ID, en el nivel de recursos de la aplicación lógica, agregue una directiva de autorización para OAuth con Microsoft Entra ID.

    Para más información, consulte Habilitar OAuth 2.0 con Microsoft Entra ID.

Regenerar las claves de acceso

Para mantener la seguridad y proteger el acceso al flujo de trabajo de la aplicación lógica, regenere las claves de acceso con regularidad, ya que podían tener que cumplir las directivas de seguridad o verse en peligro. De este modo, puede asegurarse de que solo las solicitudes autorizadas pueden desencadenar el flujo de trabajo, que protege los datos y los procesos del acceso no autorizado.

Para generar una nueva clave de acceso en cualquier momento, use la API REST de Azure o Azure Portal. Todos los URI o direcciones URL generados anteriormente que usan la clave antigua se invalidan y ya no tienen autorización para desencadenar el flujo de trabajo de la aplicación lógica. Los URI que se recuperan tras la regeneración se firman con la nueva clave de acceso.

  1. En Azure Portal, abra el recurso de aplicación lógica que usa la clave que desea regenerar.

  2. En el menú del recurso de aplicación lógica, en Configuración, seleccione Claves de acceso.

  3. Seleccione la clave que quiere regenerar y finalice el proceso.

Importante

Asegúrese de proteger la clave de acceso al mismo tiempo que protege una clave de cuenta frente al uso no autorizado. Configure o tenga un plan para revocar una clave de acceso en peligro. Sea discreto cuando distribuya URI que utilicen claves de acceso, y distribuya dichos URI únicamente a través de una conexión segura como HTTPS. Asegúrese de realizar solo operaciones que usen una clave de acceso a través de una conexión HTTPS. Cualquiera que tenga un URI con una clave válida puede acceder al recurso asociado.

Si utiliza una clave SAS para acceder a los servicios de almacenamiento, Microsoft recomienda crear una SAS de delegación de usuario, que esté protegida con Microsoft Entra ID, en lugar de una clave de cuenta.

Para una seguridad óptima, Microsoft recomienda usar Microsoft Entra ID con identidades administradas para la autenticación cuando sea posible. Esta opción proporciona seguridad superior sin tener que proporcionar credenciales. Azure administra esta identidad y ayuda a proteger la información de autenticación para que no tenga que administrar esta información confidencial. Para establecer una identidad administrada para Azure Logic Apps, consulte Autenticación del acceso y las conexiones a los recursos de Azure con identidades administradas en Azure Logic Apps.

Crear direcciones URL de devolución de llamada de expiración próxima

Si comparte la dirección URL del punto de conexión de un desencadenador basado en solicitudes con otras partes, puede generar direcciones URL de devolución de llamada con claves específicas y fechas de expiración. De esta forma puede acumular claves fácilmente o restringir el acceso para desencadenar la aplicación lógica en función de un determinado intervalo de tiempo. Para especificar una fecha de expiración para una dirección URL, use la API REST de Azure Logic Apps; por ejemplo:

POST /subscriptions/{subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Logic/workflows/{workflow-name}/triggers/{trigger-name}/listCallbackUrl?api-version=2016-06-01

En el cuerpo, incluya la propiedad NotAfter usando una cadena de fecha JSON. Esta propiedad devuelve una dirección URL de devolución de llamada que solo es válida hasta la fecha y hora NotAfter.

Creación de direcciones URL con clave secreta principal o secundaria

Al generar o enumerar direcciones URL de devolución de llamada para desencadenadores basados en solicitudes, puede especificar qué clave se va a usar para firmar la dirección URL. Para generar una dirección URL firmada por una clave específica, use, por ejemplo, la API de REST de Azure Logic Apps:

POST /subscriptions/{subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Logic/workflows/{workflow-name}/triggers/{trigger-name}/listCallbackUrl?api-version=2016-06-01

En el cuerpo, incluya la propiedad KeyType como Primary o Secondary. Esta propiedad devuelve una dirección URL firmada por una clave de seguridad especificada.

Exponga su flujo de trabajo de aplicación lógica con Azure API Management

Para obtener más protocolos y opciones de autenticación, considere la posibilidad de exponer el flujo de trabajo de su aplicación lógica como una API mediante Azure API Management. Este servicio proporciona funcionalidades completas de supervisión, seguridad, directiva y documentación para cualquier punto de conexión. API Management puede exponer un punto de conexión público o privado para la aplicación lógica. Para autorizar el acceso a este punto de conexión, puede usar OAuth con Microsoft Entra ID, el certificado de cliente u otros estándares de seguridad. Cuando API Management recibe una solicitud, el servicio la envía a la aplicación lógica y hace cualquier transformación o restricción necesaria en el proceso. Para permitir que solo API Management llame al flujo de trabajo de su aplicación lógica, puede restringir las direcciones IP entrantes de su aplicación lógica.

Para más información, consulte la siguiente documentación:

Direcciones IP entrantes restringidas

Junto con la Firma de acceso compartido (SAS), es posible que desee limitar específicamente los clientes que pueden llamar al flujo de trabajo de su aplicación lógica. Por ejemplo, si administra su punto de conexión de solicitudes mediante la Azure API Management, puede restringir el flujo de trabajo de su aplicación lógica para que solo acepte solicitudes de la dirección IP de la instancia de servicio API Management que cree.

Independientemente de las direcciones IP que especifique, puede ejecutar el flujo de trabajo de una aplicación lógica que tenga un desencadenador basado en una solicitud usando la solicitud de operación Workflow Triggers - Run o usando API Management. Sin embargo, en este escenario aún se necesita la autenticación con la API REST de Azure. Todos los eventos aparecen en el registro de auditoría de Azure. Asegúrese de establecer las directivas de control de acceso como corresponda.

Para restringir las direcciones IP entrantes para el flujo de trabajo de su aplicación lógica, siga los pasos correspondientes para Azure Portal o su plantilla de Azure Resource Manager. Un intervalo IP válido usa estos formatos: x.x.x.x/x o x.x.x.x-x.x.x.x

En el Azure Portal, la restricción de direcciones IP afecta tanto a los activadores como a las acciones, al contrario de lo que se describe en el portal en Direcciones IP entrantes permitidas. Para configurar este filtro por separado para desencadenadores y para acciones, utilice el objeto accessControl de una plantilla de Azure Resource Manager para su recurso de Logic Apps o la operación Workflow - Create Or Update de la API de REST de Azure Logic Apps.

Flujos de trabajo de consumo

  1. En Azure Portal, abra la aplicación lógica de Consumo en el diseñador de flujos de trabajo.

  2. En el menú de la aplicación lógica, en Configuración, seleccione Configuración del flujo de trabajo.

  3. En la sección Configuración de control de acceso, en Direcciones IP entrantes permitidas, elija la ruta de acceso del escenario:

    • Para que se pueda llamar a su flujo de trabajo mediante la acción integrada Azure Logic Apps, pero solo como flujo de trabajo anidado, seleccione Solo otras Logic Apps. Esta opción funciona solo cuando se utiliza la acción Azure Logic Apps para llamar al flujo de trabajo anidado.

      Esta opción escribe una matriz vacía en su recurso de aplicación lógica y requiere que sólo las llamadas de flujos de trabajo principales que utilizan la acción Azure Logic Apps incorporada puedan activar el flujo de trabajo anidado.

    • Para que su flujo de trabajo se pueda llamar utilizando la acción HTTP, pero solo como un flujo de trabajo anidado, seleccione Rangos IP específicos. Cuando aparezca el cuadro Rangos IP para activadores, introduzca las direcciones IP de salida del flujo de trabajo principal. Un intervalo IP válido usa estos formatos: x.x.x.x/x o x.x.x.x-x.x.x.x

      Nota

      Si utiliza la opción Solo otras Logic Apps y la acción HTTP para llamar a su flujo de trabajo anidado, la llamada se bloqueará y obtendrá un error "401 No autorizado".

    • En el caso de los escenarios en los que quiere restringir las llamadas entrantes desde otras direcciones IP, cuando aparezca el cuadro Intervalos de IP para desencadenadores, especifique los intervalos de direcciones IP que acepta el desencadenador. Un intervalo IP válido usa estos formatos: x.x.x.x/x o x.x.x.x-x.x.x.x

  4. Si quiere, en Restringir las llamadas para obtener mensajes de entrada y salida del historial de ejecución a las direcciones IP proporcionadas, puede especificar los intervalos de direcciones IP para las llamadas entrantes que pueden acceder a los mensajes de entrada y salida en el historial de ejecución.

Flujos de trabajo estándar

  1. En Azure Portal, abra el recurso Aplicación lógica estándar.

  2. En el menú de la aplicación lógica, en Configuración, seleccione Redes.

  3. En la sección Configuración del tráfico entrante, junto a Acceso a la red pública, seleccione Habilitado sin restricción de acceso.

  4. En la página Restricciones de acceso, en Acceso a aplicaciones, seleccione Habilitado desde redes virtuales y direcciones IP seleccionadas.

  5. En Acceso y reglas del sitio, en la pestaña Sitio principal, agregue una o varias reglas para Permitir o Denegar solicitudes de intervalos IP específicos. Un intervalo IP válido usa estos formatos: x.x.x.x/x o x.x.x.x-x.x.x.x

    Para más información, consulte Bloqueo de direcciones IP entrantes en Azure Logic Apps (Estándar).

Acceso de las llamadas salientes a otros servicios y sistemas

En función de la funcionalidad del punto de conexión de destino, las llamadas salientes enviadas por el desencadenador HTTP o la acción HTTP admiten el cifrado y están protegidas mediante el protocolo Seguridad de la capa de transporte (TLS) 1.0, 1.1 o 1.2, conocido anteriormente como Capa de sockets seguros (SSL). Azure Logic Apps negocia con el punto de conexión de destino el uso de la versión más alta que sea compatible. Por ejemplo, si el punto de conexión de destino admite la versión 1.2, el desencadenador o la acción HTTP usan primero esta versión. De lo contrario, el conector utiliza la siguiente versión compatible más alta.

Esta lista incluye información acerca de los certificados autofirmados de TLS/SSL:

  • Para los flujos de trabajo de aplicaciones lógicas de consumo en el entorno Azure Logic Apps de varios inquilinos, las operaciones HTTP no permiten certificados TLS/SSL autofirmados. Si la aplicación lógica realiza una llamada HTTP a un servidor y presenta un certificado autofirmado de TLS/SSL, la llamada HTTP produce un error TrustFailure.

  • Para los flujos de trabajo de la aplicación lógica Estándar en el entorno Azure Logic Apps de un solo inquilino, las operaciones HTTP admiten certificados TLS/SSL autofirmados. Sin embargo, debe completar algunos pasos adicionales para este tipo de autenticación. De lo contrario, se produce un error en la llamada. Para obtener más información, revise Autenticación con certificados TLS/SSL para Azure Logic Apps de inquilino único.

    Si quiere usar OAuth o el certificado de cliente con Microsoft Entra ID con el tipo de credencial Certificado en su lugar, todavía tendrá que completar algunos pasos adicionales para este tipo de autenticación. De lo contrario, se produce un error en la llamada. Para obtener más información, consulte OAuth o certificado de cliente con Microsoft Entra ID con el tipo de credencial "Certificado" para Azure Logic Apps de inquilino único.

A continuación se describen otras formas de proteger los puntos de conexión que administran las llamadas enviadas desde los flujos de trabajo de la aplicación lógica:

  • Incorporación de la autenticación a las solicitudes salientes.

    Cuando se usa el desencadenador o la acción HTTP para realizar llamadas salientes, se puede agregar autenticación a la solicitud enviada por la aplicación lógica. Por ejemplo, puede seleccionar estos tipos de autenticación:

  • Restrinja el acceso desde direcciones IP de flujos de trabajo de aplicaciones lógicas.

    Todas las llamadas a endpoints desde flujos de trabajo de aplicaciones lógicas se originan desde direcciones IP específicas designadas que se basan en las regiones de sus aplicaciones lógicas. Puede agregar un filtrado que solo acepta solicitudes provenientes de esas direcciones IP. Para obtener esas direcciones IP, consulte Límites y configuración de Azure Logic Apps.

  • Mejore la seguridad de las conexiones a sistemas locales.

    Azure Logic Apps ofrece integración con estos servicios para permitir una comunicación local más segura y confiable.

    • Puerta de enlace de datos local

      Muchos conectores administrados de Azure Logic Apps proporcionan conexiones seguras a sistemas locales, como el sistema de archivos, SQL, SharePoint y DB2. La puerta de enlace envía datos desde orígenes locales en canales cifrados hasta Azure Service Bus. Todo el tráfico se origina como tráfico de salida seguro desde el agente de la puerta de enlace. Obtenga información sobre el funcionamiento de la puerta de enlace de datos local.

    • Conexión mediante Azure API Management

      Azure API Management ofrece opciones de conexión local, como la integración de ExpressRoute y una red privada virtual sitio a sitio para un proxy seguro y comunicación con sistemas locales. Si tiene una API que proporciona acceso al sistema local y expuso esa API mediante la creación de una instancia de servicio API Management, llame a esa API en el flujo de trabajo de la aplicación lógica seleccionando la operación API Management correspondiente en el diseñador de flujos de trabajo.

      Nota:

      El conector muestra solo los servicios de API Management donde cuenta con permisos para ver y conectarse, pero no muestra los servicios de API Management basados en el consumo.

      Según el tipo de recurso de su aplicación lógica, siga los pasos correspondientes:

      Flujos de trabajo de consumo

      1. En función de si va a agregar una acción o un desencadenador de API Management, siga estos pasos:

        • Desencadenador:

          1. En el diseñador de flujos de trabajo, seleccione Agregar un desencadenador.

          2. Una vez que se abra el panel Agregar un desencadenador, en el cuadro de búsqueda, escriba API Management.

          3. En la lista de resultados del desencadenador, seleccione Elegir un desencadenador de Azure API Management.

        • Acción:

          1. En el diseñador de flujo de trabajo, seleccione el signo más (+) donde desee agregar la acción.

          2. Una vez que se abra el panel Agregar una acción, en el cuadro de búsqueda, escriba API Management.

          3. En la lista de resultados de la acción, seleccione Elegir una acción de Azure API Management.

        En el ejemplo siguiente, se muestra cómo buscar un desencadenador de Azure API Management:

        Captura de pantalla que muestra Azure Portal, el diseñador de flujos de trabajo de Consumo y la búsqueda del desencadenador de API Management.

      2. En la lista de instancias de servicio de API Management, seleccione la instancia de servicio de API Management creada anteriormente.

      3. En la lista de operaciones de API, seleccione la operación de API que se llamará y, a continuación, seleccione Agregar acción.

      Flujos de trabajo estándar

      En el caso de los flujos de trabajo Estándar, solo es posible agregar acciones de API Management, no desencadenadores.

      1. En el diseñador de flujo de trabajo, seleccione el signo más (+) donde desee agregar la acción.

      2. Una vez que se abra el panel Agregar una acción, en el cuadro de búsqueda, escriba API Management.

      3. En la lista de resultados de la acción, seleccione Llamada de API de Azure API Management.

        Captura de pantalla muestra el Azure Portal, el diseñador de flujo de trabajo estándar y la acción de Azure API Management.

      4. En la lista de instancias de servicio de API Management, seleccione la instancia de servicio de API Management creada anteriormente.

      5. En la lista de operaciones de API, seleccione la operación de API que se llamará y, a continuación, seleccione Crear nueva.

        Captura de pantalla que muestra el Azure Portal, el diseñador de flujos de trabajo estándar y la API seleccionada para llamar.

Incorporación de la autenticación en las llamadas salientes

Los extremos HTTP y HTTPS admiten varios tipos de autenticación. En algunos desencadenadores y acciones que se usan para enviar llamadas o solicitudes salientes a estos puntos de conexión, se puede especificar un tipo de autenticación. En el diseñador de flujo de trabajo, los desencadenadores y las acciones que admiten la elección de un tipo de autenticación tienen una propiedad Autenticación. Sin embargo, es posible que esta propiedad no aparezca siempre de forma predeterminada. En estos casos, en el desencadenador o la acción, abra la lista Parámetros avanzados y seleccione Autenticación.

Importante

Para proteger la confidencialidad de la información que controla el flujo de trabajo de su aplicación lógica, use parámetros seguros y codifique los datos según sea necesario. Para obtener más información sobre cómo usar y proteger los parámetros, consulte Acceso a las entradas de parámetro.

Para una seguridad óptima, Microsoft recomienda usar Microsoft Entra ID con identidades administradas para la autenticación cuando sea posible. Esta opción proporciona seguridad superior sin tener que proporcionar credenciales. Azure administra esta identidad y ayuda a proteger la información de autenticación para que no tenga que administrar esta información confidencial. Para establecer una identidad administrada para Azure Logic Apps, consulte Autenticación del acceso y las conexiones a los recursos de Azure con identidades administradas en Azure Logic Apps.

Autenticación básica

Para las llamadas HTTP, la autenticación básica utiliza una cadena codificada en base64 que contiene un nombre de usuario y una contraseña para realizar una solicitud. Este método transmite las credenciales sin cifrado y plantea mayores riesgos de seguridad a menos que use esta opción con el protocolo HTTPS/SSL.

Importante

Para una seguridad óptima, Microsoft recomienda usar Microsoft Entra ID con identidades administradas para la autenticación cuando sea posible. Esta opción proporciona seguridad superior sin tener que proporcionar credenciales. Azure administra esta identidad y ayuda a proteger la información de autenticación para que no tenga que administrar esta información confidencial. Para establecer una identidad administrada para Azure Logic Apps, consulte Autenticación del acceso y las conexiones a los recursos de Azure con identidades administradas en Azure Logic Apps.

Si la opción Aspectos básicos está disponible y seleccionada, especifique estos valores de propiedad:

Propiedad (diseñador) Propiedad (JSON) Obligatorio Valor Descripción
Autenticación type Sí Básico Tipo de autenticación que se debe usar.
Nombre de usuario username Sí <nombre-de-usuario> Nombre de usuario para autenticar el acceso al extremo del servicio de destino.
Contraseña password Sí <contraseña> Contraseña para autenticar el acceso al extremo del servicio de destino.

Al usar parámetros protegidos para administrar y proteger la información confidencial, por ejemplo, en una plantilla de Azure Resource Manager para automatizar la implementación, puede usar expresiones para acceder a estos valores de parámetros en tiempo de ejecución. Esta definición de acción HTTP de ejemplo especifica el type de autenticación como Basic y usa la función parameters() para obtener los valores de parámetro:

"HTTP": {
   "type": "Http",
   "inputs": {
      "method": "GET",
      "uri": "@parameters('endpointUrlParam')",
      "authentication": {
         "type": "Basic",
         "username": "@parameters('userNameParam')",
         "password": "@parameters('passwordParam')"
      }
  },
  "runAfter": {}
}

Autenticación de certificados de clientes

Autenticación de certificados de cliente permite o requiere que los usuarios se autentiquen directamente con certificados X.509 en Microsoft Entra ID para el inicio de sesión en aplicaciones y exploradores. Esta capacidad le ayuda a adoptar una autenticación resistente al phishing y a autenticar con un certificado X.509 en su infraestructura de clave pública (PKI).

Importante

Para una seguridad óptima, Microsoft recomienda usar Microsoft Entra ID con identidades administradas para la autenticación cuando sea posible. Esta opción proporciona seguridad superior sin tener que proporcionar credenciales. Azure administra esta identidad y ayuda a proteger la información de autenticación para que no tenga que administrar esta información confidencial. Para establecer una identidad administrada para Azure Logic Apps, consulte Autenticación del acceso y las conexiones a los recursos de Azure con identidades administradas en Azure Logic Apps.

Si la opción Certificado de cliente está disponible y seleccionada, especifique estos valores de propiedad:

Propiedad (diseñador) Propiedad (JSON) Obligatorio Valor Descripción
Autenticación type Sí Certificado de cliente
o bien
ClientCertificate		 Tipo de autenticación que se debe usar. Puede administrar certificados con Azure API Management.

Nota: Los conectores personalizados no admiten la autenticación basada en certificados para las llamadas entrantes y salientes.
Pfx pfx Sí <contenido-archivo-pfx-codificado> El contenido codificado en base 64 del archivo de intercambio de información personal (PFX)

Para convertir el archivo PFX en formato codificado en base64, puede utilizar PowerShell 7 siguiendo estos pasos:

1. Guarde el contenido del certificado en una variable:

$pfx_cert = [System.IO.File]::ReadAllBytes('c:\certificate.pfx')

2. Convierta el contenido del certificado mediante la función ToBase64String() y guarde el contenido en un archivo de texto:

[System.Convert]::ToBase64String($pfx_cert) | Out-File 'pfx-encoded-bytes.txt'

Solución de problemas: si usa el comando cert mmc/PowerShell, podría obtener este error:

Could not load the certificate private key. Please check the authentication certificate password is correct and try again.

Para resolver este error, intente convertir el archivo PFX en un archivo PEM y nuevamente mediante el comando openssl:

openssl pkcs12 -in certificate.pfx -out certificate.pem
openssl pkcs12 -in certificate.pem -export -out certificate2.pfx

Después, al obtener la cadena codificada en base64 para el archivo PFX recién convertido del certificado, la cadena funcionará en Azure Logic Apps.
Contraseña password No <contraseña-archivo-pfx> La contraseña para acceder al archivo PFX

Nota:

Si intenta autenticarse con un certificado de cliente mediante OpenSSL, es posible que reciba el siguiente error:

BadRequest: Could not load private key

Para solucionar el error, siga estos pasos:

  1. Desinstale todas las instancias de OpenSSL.
  2. Instale OpenSSL versión 1.1.1t.
  3. Renuncie al certificado mediante la nueva actualización.
  4. Agregue el nuevo certificado a la operación HTTP al usar la autenticación de certificado de cliente.

Al usar parámetros protegidos para administrar y proteger la información confidencial, por ejemplo, en una plantilla de Azure Resource Manager para automatizar la implementación, puede usar expresiones para acceder a estos valores de parámetros en tiempo de ejecución. Esta definición de acción HTTP de ejemplo especifica el type de autenticación como ClientCertificate y usa la función parameters() para obtener los valores de parámetro:

"HTTP": {
   "type": "Http",
   "inputs": {
      "method": "GET",
      "uri": "@parameters('endpointUrlParam')",
      "authentication": {
         "type": "ClientCertificate",
         "pfx": "@parameters('pfxParam')",
         "password": "@parameters('passwordParam')"
      }
   },
   "runAfter": {}
}

Importante

Si tiene un recurso de aplicación lógica estándar en Azure Logic Apps de inquilino único y quiere usar una operación HTTP con un certificado TSL/SSL, un certificado de cliente o Microsoft Entra ID Open Authentication (Microsoft Entra ID OAuth) con el tipo de credencial Certificate, asegúrese de completar los pasos de configuración adicionales para este tipo de autenticación. De lo contrario, se produce un error en la llamada. Para obtener más información, revise Autenticación en un entorno de inquilino único.

Para obtener más información sobre cómo proteger los servicios mediante la autenticación de certificados de cliente, consulte estos temas:

Plataforma Microsoft Entra

En el desencadenador Solicitud, puede utilizar la plataforma de Microsoft Entra para autenticar las llamadas entrantes después de configurar las directivas de autorización de Microsoft Entra para su aplicación lógica.

Importante

Para una seguridad óptima, Microsoft recomienda usar Microsoft Entra ID con identidades administradas para la autenticación cuando sea posible. Esta opción proporciona seguridad superior sin tener que proporcionar credenciales. Azure administra esta identidad y ayuda a proteger la información de autenticación para que no tenga que administrar esta información confidencial. Para establecer una identidad administrada para Azure Logic Apps, consulte Autenticación del acceso y las conexiones a los recursos de Azure con identidades administradas en Azure Logic Apps.

En todos los demás desencadenadores y acciones compatibles con el tipo de autenticación de Active Directory OAuth (OAuth 2.0 con Microsoft Entra ID), especifique estos valores de propiedad:

Propiedad (diseñador) Propiedad (JSON) Obligatorio Valor Descripción
Autenticación type Sí OAuth de Active Directory (OAuth 2.0 con Microsoft Entra ID)
o bien
ActiveDirectoryOAuth		 Tipo de autenticación que se debe usar. Actualmente, Azure Logic Apps sigue el protocolo OAuth 2.0.
Autoridad authority No <URL-for-authority-token-issuer> Dirección URL de la autoridad que proporciona la clave de acceso, como https://login.microsoftonline.com/ para las regiones de servicio globales de Azure. Para otras nubes nacionales, consulte Puntos de conexión de Microsoft Entra de autenticación: elección de una autoridad de identidad.
Inquilino tenant Sí <tenant-ID> Identificador de inquilino del inquilino de Microsoft Entra
Audiencia audience Sí <resource-to-authorize> Recurso que quiere usar para la autorización; por ejemplo, https://management.core.windows.net/
Id. de cliente clientId Sí <client-ID> El identificador de cliente para la aplicación que solicita autorización
Tipo de credencial credentialType Sí Certificado
o bien
Secreto		 El tipo de credencial que el cliente usa para solicitar autorización. Esta propiedad y el valor no aparecen en la definición subyacente de la aplicación lógica, pero determina las propiedades que se muestran para el tipo de credencial seleccionado.
Secreto secret Sí, pero solo para el tipo de credencial de "Secreto". <secreto-de-cliente> Secreto de cliente para solicitar la autorización
Pfx pfx Sí, pero solo para el tipo de credencial de "Certificado". <contenido-archivo-pfx-codificado> El contenido codificado en base 64 del archivo de intercambio de información personal (PFX)
Contraseña password Sí, pero solo para el tipo de credencial de "Certificado". <contraseña-archivo-pfx> La contraseña para acceder al archivo PFX

Al usar parámetros protegidos para administrar y proteger la información confidencial, por ejemplo, en una plantilla de Azure Resource Manager para automatizar la implementación, puede usar expresiones para acceder a estos valores de parámetros en tiempo de ejecución. Esta definición de acción HTTP de ejemplo especifica el type de autenticación como ActiveDirectoryOAuth, el tipo de credencial Secret y usa la función parameters() para obtener los valores de parámetro:

"HTTP": {
   "type": "Http",
   "inputs": {
      "method": "GET",
      "uri": "@parameters('endpointUrlParam')",
      "authentication": {
         "type": "ActiveDirectoryOAuth",
         "tenant": "@parameters('tenantIdParam')",
         "audience": "https://management.core.windows.net/",
         "clientId": "@parameters('clientIdParam')",
         "credentialType": "Secret",
         "secret": "@parameters('secretParam')"
     }
   },
   "runAfter": {}
}

Importante

Si tiene un recurso de aplicación lógica estándar en Azure Logic Apps de inquilino único y quiere usar una operación HTTP con un certificado TSL/SSL, un certificado de cliente o Microsoft Entra ID OAuth con el tipo de credencial Certificate, asegúrese de completar los pasos de configuración adicionales para este tipo de autenticación. De lo contrario, se produce un error en la llamada. Para más información, consulte Autenticación en un entorno de inquilino único.

Autenticación sin formato

Si la opción Raw está disponible, puede usar este tipo de autenticación cuando tenga que usar esquemas de autenticación que no siguen el protocolo OAuth 2.0. Con este tipo, se crea manualmente el valor del encabezado de autorización que se envía con la solicitud saliente y se especifica ese valor de encabezado en el desencadenador o la acción.

Importante

Para una seguridad óptima, Microsoft recomienda usar Microsoft Entra ID con identidades administradas para la autenticación cuando sea posible. Esta opción proporciona seguridad superior sin tener que proporcionar credenciales. Azure administra esta identidad y ayuda a proteger la información de autenticación para que no tenga que administrar esta información confidencial. Para establecer una identidad administrada para Azure Logic Apps, consulte Autenticación del acceso y las conexiones a los recursos de Azure con identidades administradas en Azure Logic Apps.

El siguiente ejemplo muestra un encabezado de ejemplo para una solicitud HTTPS que sigue el protocolo OAuth 1.0:

Authorization: OAuth realm="Photos",
   oauth_consumer_key="dpf43f3p2l4k3l03",
   oauth_signature_method="HMAC-SHA1",
   oauth_timestamp="137131200",
   oauth_nonce="wIjqoS",
   oauth_callback="http%3A%2F%2Fprinter.example.com%2Fready",
   oauth_signature="74KNZJeDHnMBp0EMJ9ZHt%2FXKycU%3D"

En el desencadenador o la acción que admite la autenticación sin formato, especifique estos valores de propiedad:

Propiedad (diseñador) Propiedad (JSON) Obligatorio Valor Descripción
Autenticación type Sí Raw Tipo de autenticación que se debe usar.
Valor value Sí <valor de encabezado de autorización> Valor del encabezado de autorización que se va a usar para la autenticación.

Al usar parámetros protegidos para administrar y proteger la información confidencial, por ejemplo, en una plantilla de Azure Resource Manager para automatizar la implementación, puede usar expresiones para acceder a estos valores de parámetros en tiempo de ejecución. Esta definición de acción HTTP de ejemplo especifica el type de autenticación como Raw y usa la función parameters() para obtener los valores de parámetro:

"HTTP": {
   "type": "Http",
   "inputs": {
      "method": "GET",
      "uri": "@parameters('endpointUrlParam')",
      "authentication": {
         "type": "Raw",
         "value": "@parameters('authHeaderParam')"
      }
   },
   "runAfter": {}
}

Autenticación de identidad administrada

Cuando la opción Identidad administrada está disponible en el desencadenador o la acción que admite la autenticación de identidad administrada, la aplicación lógica puede usar esta identidad para autenticar el acceso a recursos de Azure que están protegidos por Microsoft Entra ID, en lugar de credenciales, secretos o tokens de Microsoft Entra. Azure administra esta identidad y le ayuda a proteger las credenciales porque, de esta forma, no tiene que administrar secretos ni usar directamente tokens de Microsoft Entra. Obtenga más información sobre Servicios de Azure que admiten las identidades administradas para la autenticación de Microsoft Entra.

  • Un recurso de aplicación lógica de consumo puede usar la identidad asignada por el sistema o una única identidad asignada por el usuario creada manualmente.

  • Un recurso de aplicación lógica estándar admite tener habilitadas la identidad administrada asignada por el sistema y varias identidades administradas asignadas por el usuario al mismo tiempo, aunque puede seleccionar solo una identidad para usarla en cualquier momento.

    Nota:

    De manera predeterminada, la identidad asignada por el sistema ya está habilitada para autenticar las conexiones en tiempo de ejecución. Esta identidad se diferencia de las credenciales de autenticación o de la cadena de conexión que se usan al crear una conexión. Si deshabilita esta identidad, las conexiones no funcionarán en tiempo d ejecución. Para ver este valor, en el menú de la aplicación lógica, en Configuración, seleccione Identidad.

  1. Para que la aplicación lógica pueda usar una identidad administrada, siga los pasos descritos en Autenticación de acceso a los recursos de Azure con identidades administradas en Azure Logic Apps. En estos pasos se habilita la identidad administrada en la aplicación lógica y se configura el acceso de dicha identidad al recurso de Azure de destino.

  2. Para que una función de Azure pueda usar una identidad administrada, primero habilite la autenticación de Azure Functions.

  3. En el desencadenador o la acción que admite el uso de una identidad administrada, proporcione esta información:

    Acciones y desencadenadores integrados

    Propiedad (diseñador) Propiedad (JSON) Obligatorio Valor Descripción
    Autenticación type Sí Identidad administrada
    o bien
    ManagedServiceIdentity    		 Tipo de autenticación que se debe usar.
    Identidad administrada identity No <Id. de identidad asignada por el usuario> Identidad administrada asignada por el usuario que se va a usar. Nota: No incluya esta propiedad cuando use la identidad administrada asignada por el sistema.
    Audiencia audience Sí <Id-recurso-destino> El Id. de recurso para el recurso de destino al que quiere obtener acceso.

    Por ejemplo, https://storage.azure.com/ hace que los tokens de acceso para la autenticación sean válidos con todas las cuentas de almacenamiento. Sin embargo, también puede especificar una dirección URL de servicio raíz, como https://fabrikamstorageaccount.blob.core.windows.net para una cuenta de almacenamiento específica.

    Nota: La propiedad Audiencia puede estar oculta en algunos desencadenadores o acciones. Para que la propiedad sea visible, en el desencadenador o la acción, abra la lista Parámetros avanzados y seleccione Público.

    Importante: asegúrese de que este id. del recurso de destino coincide exactamente con el valor que espera Microsoft Entra ID, incluidas las barras finales necesarias. Por lo tanto, el Id. de recurso de https://storage.azure.com/ para todas las cuentas de Azure Blob Storage requiere una barra diagonal final. Sin embargo, el Id. de recurso de una cuenta de almacenamiento específica no requiere una barra diagonal final. Para buscar estos identificadores de recurso, consulte Servicios de Azure que admiten Microsoft Entra ID.

    Al usar parámetros protegidos para administrar y proteger la información confidencial, por ejemplo, en una plantilla de Azure Resource Manager para automatizar la implementación, puede usar expresiones para acceder a estos valores de parámetros en tiempo de ejecución. Por ejemplo, esta definición de acción HTTP especifica el type de autenticación como ManagedServiceIdentity y usa la función parameters() para obtener los valores de parámetro:

    "HTTP": {
   "type": "Http",
   "inputs": {
      "method": "GET",
      "uri": "@parameters('endpointUrlParam')",
      "authentication": {
         "type": "ManagedServiceIdentity",
         "audience": "https://management.azure.com/"
      },
   },
   "runAfter": {}
}

    Desencadenadores y acciones del conector administrado

    Propiedad (diseñador) Obligatorio Valor Descripción
    Nombre de la conexión Sí <connection-name>
    Identidad administrada Sí Identidad administrada asignada por el sistema
    o bien
    <user-assigned-managed-identity-name>    		 Tipo de autenticación que se debe usar.

Bloquear la creación de conexiones

Si su organización no permite la conexión a recursos específicos mediante el uso de sus conectores en Azure Logic Apps, puede bloquear la capacidad para crear esas conexiones para conectores específicos en flujos de trabajo de aplicaciones lógicas mediante el uso de Azure Policy. Para obtener más información, consulte Bloqueo de conexiones creadas por conectores específicos en Azure Logic Apps.

Guía de aislamiento para aplicaciones lógicas

Para obtener más información sobre el aislamiento, consulte la siguiente documentación:

Contenido relacionado