Proteger el acceso y los datos en Azure Logic Apps

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 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:

• Acceso de las llamadas entrantes a desencadenadores basados en solicitud
• Acceso a las operaciones de las aplicaciones lógicas
• Acceso a las entradas y salidas del historial de ejecución
• Acceso a las entradas de parámetros
• Acceso de las llamadas salientes a otros servicios y sistemas
• Bloquear la creación de conexiones para conectores específicos
• Guía de aislamiento para aplicaciones lógicas
• Base de referencia de seguridad de Azure para Azure Logic Apps

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

• Información general del cifrado de Azure
• Cifrado en reposo de datos de Azure
• Azure Security Benchmark

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 Request (Solicitud) o el desencadenador HTTP Webhook (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). Logic Apps aplica esta versión al recibir una llamada entrante al desencadenador Request (Solicitud) o una devolución de llamada al desencadenador o acción HTTP Webhook (Webhook de HTTP). 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

En la siguiente lista se incluyen más formas de limitar el acceso a los desencadenadores que reciben llamadas entrantes a la aplicación lógica para que solo los clientes autorizados puedan llamar a la aplicación lógica:

• Generación de firmas de acceso compartido (SAS)
• Habilitación de Azure Active Directory Open Authentication (Azure AD OAuth)
• Exposición de su aplicación lógica con Azure API Management
• Direcciones IP entrantes restringidas

Generación de firmas de acceso compartido (SAS)

Cada de punto de conexión de la solicitud de una aplicación lógica tiene una Firma de acceso compartido (SAS) en la dirección URL del punto de conexión con el formato siguiente:

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

Cada dirección URL contiene el parámetro de consulta sp, sv y sig, tal y como se describe en esta tabla:

Las llamadas entrantes a un punto de conexión de solicitud solo pueden usar un esquema de autorización, ya sea SAS u Azure Active Directory Open Authentication. Aunque el uso de un esquema no deshabilita el otro, si se utilizan ambos al mismo tiempo se produce un error porque el servicio no sabe cuál elegir.

Para obtener más información sobre la protección del acceso con la Firma de acceso compartido, consulte estas secciones del tema:

• Regenerar las claves de acceso
• Crear direcciones URL de devolución de llamada de expiración próxima
• Crear direcciones URL con clave principal o secundaria

Regenerar las claves de acceso

Para generar una nueva clave de acceso de seguridad en cualquier momento, use la API REST de Azure o Azure Portal. Se invalidan todas las direcciones URL generadas previamente que usan la clave anterior y ya no tienen autorización para desencadenar la aplicación lógica. Las direcciones URL que se recuperan tras la regeneración se firman con la nueva clave de acceso.

1. En Azure Portal, abra la aplicación lógica donde está la clave que quiere regenerar.

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

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

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 Logic Apps; por ejemplo:

POST /subscriptions/<Azure-subscription-ID>/resourceGroups/<Azure-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 mediante una cadena de fecha de 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 la API REST de Logic Apps; por ejemplo:

POST /subscriptions/<Azure-subscription-ID>/resourceGroups/<Azure-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.

Habilitación de Azure Active Directory Open Authentication (Azure AD OAuth)

Para las llamadas entrantes a un punto de conexión que se haya creado con un desencadenador basado en una solicitud, puede habilitar Azure AD OAuth mediante la definición o la incorporación de una directiva de autorización para la aplicación lógica. De este modo, las llamadas entrantes usan tokens de acceso de OAuth para la autorización.

Cuando la aplicación lógica recibe una solicitud entrante que incluye un token de acceso de OAuth, Azure Logic Apps compara las notificaciones del token con las especificadas en 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.

Consideraciones antes de habilitar Azure AD OAuth

• Una llamada entrante al punto de conexión de la solicitud solo puede usar un esquema de autorización, ya sea Azure AD OAuth o firma de acceso compartido (SAS). Aunque el uso de un esquema no deshabilita el otro, si se utilizan ambos al mismo tiempo se produce un error porque el servicio Logic Apps no sabe cuál elegir.

• Solo se admiten esquemas de autorización de tipo portador para los tokens de acceso de Azure AD OAuth, lo que significa que en el encabezado Authorization para el token de acceso se debe especificar el tipo Bearer.

• La aplicación lógica está limitada 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 identificador de emisor de Azure AD.

  Por ejemplo, supongamos que la aplicación lógica tiene una directiva de autorización que requiere dos tipos de notificaciones: Emisor y Audiencia. 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": "72f988bf-86f1-41af-91ab-2d7cd011db47",
      "unique_name": "SophiaOwen@fabrikam.com",
      "upn": "SophiaOwen@fabrikam.com",
      "uti": "TPJ7nNNMMZkOSx6_uVczUAA",
      "ver": "1.0"
  }
  

Habilitación de Azure AD OAuth para la aplicación lógica

Siga estos pasos tanto para Azure Portal como para la plantilla de Azure Resource Manager:

"resources": [
   {
      // Start logic app resource definition
      "properties": {
         "state": "<Enabled-or-Disabled>",
         "definition": {<workflow-definition>},
         "parameters": {<workflow-definition-parameter-values>},
         "accessControl": {
            "triggers": {
               "openAuthenticationPolicies": {
                  "policies": {
                     "<policy-name>": {
                        "type": "AAD",
                        "claims": [
                           {
                              "name": "<claim-name>",
                              "value": "<claim-value>"
                           }
                        ]
                     }
                  }
               }
            },
         },
      },
      "name": "[parameters('LogicAppName')]",
      "type": "Microsoft.Logic/workflows",
      "location": "[parameters('LogicAppLocation')]",
      "apiVersion": "2016-06-01",
      "dependsOn": [
      ]
   }
   // End logic app resource definition
],

Inclusión del encabezado "Authorization" en las salidas del desencadenador por solicitud

En el caso de las aplicaciones lógicas que permiten Azure Active Directory Open Authentication (Azure AD OAuth) para autorizar el acceso de las llamadas entrantes a desencadenadores por solicitud, puede habilitar que las salidas del desencadenador Request o HTTP Webhook 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 Request (Solicitud):

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

Para más información, consulte los temas siguientes:

• Referencia de esquema para los tipos de desencadenador y de acción: desencadenador Request (Solicitud)
• Referencia de esquema para los tipos de desencadenador y de acción: desencadenador HTTP Webhook
• Referencia de esquema para los tipos de desencadenador y de acción: opciones de operación

Exposición de su aplicación lógica con Azure API Management

Para obtener más protocolos y opciones de autenticación, considere la posibilidad de exponer la 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 Azure Active Directory Open Authentication (Azure AD OAuth), el certificado del 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 que solo API Management pueda llamar a la aplicación lógica, puede limitar el número de direcciones IP de entrada de la aplicación lógica.

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

• Acerca de API Management
• Protección de un back-end de API web en Azure API Management mediante la autorización de OAuth 2.0 con Azure AD
• Protección de API mediante la autenticación de certificados de cliente en API Management
• Directivas de autenticación de Azure API Management

Direcciones IP entrantes restringidas

Junto con la Firma de acceso compartido (SAS), es posible que quiera especificar el límite de clientes que pueden llamar a su aplicación lógica. Por ejemplo, si administra el punto de conexión de solicitud mediante Azure API Management, puede restringir la aplicación lógica para que solo acepte solicitudes procedentes de la dirección IP de la instancia de servicio de API Management que crea.

Independientemente de las direcciones IP que se especifiquen, es posible ejecutar una aplicación lógica que tenga un desencadenador basado en una solicitud mediante la API REST de Logic Apps: desencadenadores de flujo de trabajo: ejecutar o de 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 de entrada para la aplicación lógica, siga estos pasos tanto para Azure Portal como para la plantilla de Azure Resource Manager:

{
   "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
   "contentVersion": "1.0.0.0",
   "parameters": {},
   "variables": {},
   "resources": [
      {
         "name": "[parameters('LogicAppName')]",
         "type": "Microsoft.Logic/workflows",
         "location": "[parameters('LogicAppLocation')]",
         "tags": {
            "displayName": "LogicApp"
         },
         "apiVersion": "2016-06-01",
         "properties": {
            "definition": {
               <workflow-definition>
            },
            "parameters": {
            },
            "accessControl": {
               "triggers": {
                  "allowedCallerIpAddresses": []
               },
               "actions": {
                  "allowedCallerIpAddresses": []
               },
               // Optional
               "contents": {
                  "allowedCallerIpAddresses": []
               }
            },
            "endpointsConfiguration": {}
         }
      }
   ],
   "outputs": {}
}

{
   "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
   "contentVersion": "1.0.0.0",
   "parameters": {},
   "variables": {},
   "resources": [
      {
         "name": "[parameters('LogicAppName')]",
         "type": "Microsoft.Logic/workflows",
         "location": "[parameters('LogicAppLocation')]",
         "tags": {
            "displayName": "LogicApp"
         },
         "apiVersion": "2016-06-01",
         "properties": {
            "definition": {
               <workflow-definition>
            },
            "parameters": {
            },
            "accessControl": {
               "triggers": {
                  "allowedCallerIpAddresses": [
                     {
                        "addressRange": "192.168.12.0/23"
                     }
                  ]
               },
               "actions": {
                  "allowedCallerIpAddresses": [
                     {
                        "addressRange": "192.168.12.0/23"
                     }
                  ]
               }
            },
            "endpointsConfiguration": {}
         }
      }
   ],
   "outputs": {}
}

Acceso a las operaciones de las aplicaciones lógicas

Puede permitir que solo determinados usuarios o grupos ejecuten tareas específicas, como administrar, editar y ver aplicaciones lógicas. Para controlar los permisos, use el control de acceso basado en roles de Azure (RBAC de Azure). Puede asignar roles integrados o personalizados a los miembros que tienen acceso a la suscripción de Azure. Azure Logic Apps tiene estos roles específicos:

• Colaborador de aplicación lógica: Le permite administrar aplicaciones lógicas, pero no puede cambiar el acceso a ellas.

• Operador de aplicación lógica: Le permite leer, habilitar y deshabilitar aplicaciones lógicas, pero no puede editarlas ni actualizarlas.

• Colaborador: concede acceso completo para administrar todos los recursos, pero no le permite asignar roles en RBAC de Azure, administrar asignaciones en Azure Blueprints ni compartir galerías de imágenes.

  Por ejemplo, imagine que tiene que trabajar con una 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 elimine la 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.

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, 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:

• Restricción del acceso por intervalo de direcciones IP.

  Esta opción le permite proteger el acceso al historial de ejecución en función de las solicitudes de un intervalo de direcciones IP específico.

• Protección de los datos del historial de ejecución mediante ofuscación.

  En muchos desencadenadores y acciones, puede proteger las entradas, las salidas, o ambas, en el historial de ejecución de una aplicación lógica.

Restringir el acceso por intervalo de direcciones IP

Puede limitar el acceso a las entradas y salidas del historial de ejecución de la aplicación lógica para que solo las solicitudes de intervalos de direcciones IP específicas puedan ver los 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 quitar esta restricción, lo que proporciona la posibilidad de usar el acceso "Just-In-Time" para los datos de la aplicación lógica.

Para especificar los intervalos IP permitidos, siga estos pasos tanto para Azure Portal como para la plantilla de Azure Resource Manager:

{
   "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
   "contentVersion": "1.0.0.0",
   "parameters": {},
   "variables": {},
   "resources": [
      {
         "name": "[parameters('LogicAppName')]",
         "type": "Microsoft.Logic/workflows",
         "location": "[parameters('LogicAppLocation')]",
         "tags": {
            "displayName": "LogicApp"
         },
         "apiVersion": "2016-06-01",
         "properties": {
            "definition": {<workflow-definition>},
            "parameters": {},
            "accessControl": {
               "contents": {
                  "allowedCallerIpAddresses": [
                     {
                        "addressRange": "192.168.12.0/23"
                     },
                     {
                        "addressRange": "2001:0db8::/64"
                     }
                  ]
               }
            }
         }
      }
   ],
   "outputs": {}
}

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:

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, 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 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, 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, 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.

  

  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, 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, Logic Apps no oculta las entradas o salidas de la acción de nivel inferior.

  

  Opción Entradas seguras

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

  

  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, 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, Logic Apps no oculta las entradas o salidas de la acción de nivel inferior.

  

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

1. En Azure Portal, abra la aplicación lógica en Diseñador de aplicación lógica.

   

2. En el desencadenador o la acción donde quiera proteger los datos confidenciales, seleccione los puntos suspensivos ( ... ) y, luego, elija Configuración.

   

3. Active Entradas seguras, Salidas seguras o ambas opciones. Cuando haya finalizado, seleccione Listo.

   

   Ahora, la acción o el desencadenador muestra un icono de candado en la barra de título.

   

   Los tokens que representan las salidas protegidas de acciones anteriores también muestran los iconos de candado. Por ejemplo, al seleccionar un resultado de este tipo en la lista de contenido dinámico para usarlo en una acción, el token muestra un icono de candado.

   

4. Una vez ejecutada la aplicación lógica, puede ver el historial de esa ejecución.

   1. En el panel Información general de la aplicación lógica, seleccione la ejecución que quiera ver.

   2. En el panel Ejecución de aplicación lógica, expanda las acciones que quiera revisar.

      Si decide ocultar las entradas y las salidas, esos valores aparecerán ahora ocultos.

      

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 Azure Active Directory Open Authentication (Azure AD OAuth), 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 para la aplicación lógica, use la sección parameters dentro de la definición de flujo de trabajo de la aplicación lógica y 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.

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

• Parámetros protegidos en las definiciones de flujo de trabajo
• Protección del historial de ejecución mediante ofuscación

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 más información, consulte los temas siguientes:

• Uso de Azure Key Vault para pasar valores confidenciales durante la implementación
• Parámetros seguros en plantillas de Azure Resource Manager más adelante en este tema

Parámetros protegidos en las definiciones de flujo de trabajo

Para proteger la información confidencial en la definición del flujo de trabajo de aplicación lógica, use parámetros seguros, de forma que esta información no esté visible después de guardar 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.

"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

Una plantilla de Resource Manager para una aplicación lógica tiene varias secciones parameters. 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.

Aquí tiene 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 del flujo de trabajo, una sección parameters define los parámetros que usa la aplicación lógica 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:

{
   "$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": {}
}

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). 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.

A continuación se muestra información acerca de los certificados autofirmados de TLS/SSL:

• En el caso de aplicaciones lógicas en el entorno global multiinquilino de Azure Logic Apps, las operaciones HTTP no permiten certificados de 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.

• En el caso de aplicaciones lógicas en el entorno de Azure Logic Apps de inquilino único, 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 el certificado de cliente o Azure Active Directory y Open Authentication (Azure AD OAuth) con el tipo de credencial "Certificado" en su lugar, todavía tiene 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, revise Certificado de cliente o Azure Active Directory y Open Authentication (Azure AD OAuth) con el tipo de credencial "Certificado" para Azure Logic Apps de inquilino único.

• En el caso de las aplicaciones lógicas en un entorno de servicio de integración (ISE), el conector HTTP permite certificados autofirmados para los protocolos de enlace TLS/SSL. Sin embargo, primero debe habilitar la compatibilidad con certificados autofirmados para un ISE existente o un ISE nuevo mediante la API REST de Logic Apps, y, después, instalar el certificado público en la ubicación de TrustedRoot.

Estas son otras formas en que se puede ayudar a proteger los punto de conexión que controlan las llamadas enviadas desde su 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:

  • Autenticación básica

  • Autenticación de certificados de clientes

  • Autenticación de Active Directory OAuth

  • Autenticación de identidad administrada

• Restricción del acceso desde direcciones IP de aplicación lógica.

  Todas las llamadas a los puntos de conexión desde aplicaciones lógicas proceden de direcciones IP designadas específicas que se basan en las regiones de las 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 del servicio API Management, puede llamar a esa API en el flujo de trabajo de la aplicación lógica seleccionando la acción o el desencadenador de API Management integrados en el Diseñador de aplicación lógica.

    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.

    1. En el Diseñador de aplicación lógica, escriba api management en el cuadro de búsqueda. Elija el paso en función de si va a agregar un desencadenador o una acción:

       • Si agrega un desencadenador, que siempre es el primer paso en el flujo de trabajo, seleccione Choose an Azure API Management trigger (Elegir un desencadenador de Azure API Management).

       • Si agrega una acción, seleccione Choose an Azure API Management action (Elegir una acción de Azure API Management).

       En este ejemplo se agrega un desencadenador:

       

    2. Seleccione su instancia de servicio API Management creada anteriormente.

       

    3. Seleccione la llamada API que se va a usar.

       

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 aplicación lógica, 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 Agregar nuevo parámetro y seleccione Autenticación.

Tipos de autenticación para desencadenadores y acciones que admiten la autenticación

En esta tabla se identifican los tipos de autenticación que están disponibles en los desencadenadores y las acciones donde puede seleccionar un tipo de autenticación:

Autenticación básica

Si la opción Básica está disponible, especifique estos valores de propiedad:

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 cliente

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

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": {}
}

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

• Cómo mejorar la seguridad de las API mediante la autenticación de certificados de cliente en Azure API Management
• Cómo mejorar la seguridad de los servicios back-end con la autenticación de certificados de cliente en Azure API Management
• Cómo mejorar la seguridad de los servicios RESTful mediante certificados de cliente
• Credenciales de certificado para la autenticación de aplicaciones
• Uso de un certificado TLS/SSL en el código de Azure App Service

Azure Active Directory Open Authentication

En los desencadenadores Request (Solicitud), se puede usar Azure Active Directory Open Authentication (Azure AD OAuth) para autenticar las llamadas entrantes después de configurar las directivas de autorización de Azure AD de la aplicación lógica. En el caso del resto de desencadenadores y acciones que proporcionan el tipo de autenticación Active Directory OAuth, especifique estos valores de propiedad:

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": {}
}

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.

Por ejemplo, el siguiente es 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:

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 Azure Active Directory (Azure AD), en lugar de credenciales, secretos o tokens de Azure AD. 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 Azure AD. Obtenga más información sobre Servicios de Azure que admiten las identidades administradas para la autenticación de Azure AD.

• El tipo de recurso Aplicación lógica (consumo) puede usar la identidad asignada por el sistema o una única identidad asignada por el usuario creada manualmente.

• El tipo de recurso Aplicación lógica (estándar) solo puede usar la identidad asignada por el sistema, que se habilita de forma automática. La identidad asignada por el usuario no está disponible actualmente.

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	Value	Descripción
   Autenticación	type	Sí	Identidad administrada or ManagedServiceIdentity	Tipo de autenticación que se debe usar.
   Identidad administrada	identity	Sí	* Identidad administrada asignada por el sistema or SystemAssigned * <Id. de identidad asignada por el usuario>	Identidad administrada que se debe usar.
   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 Agregar nuevo parámetro y seleccione Público. Importante: Asegúrese de que el identificador de este recurso de destino coincide exactamente con el valor esperado en Azure AD, incluida toda barra diagonal necesaria al final. 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 Id. de recursos, consulte Servicios de Azure que admiten la autenticación de Azure AD.

   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",
            "identity": "SystemAssigned",
            "audience": "https://management.azure.com/"
         },
      },
      "runAfter": {}
   }
   

   Desencadenadores y acciones del conector administrado

   Propiedad (diseñador)	Obligatorio	Value	Descripción
   Nombre de la conexión	Sí	<connection-name>
   Identidad administrada	Sí	Identidad administrada asignada por el sistema or <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 Bloquear las conexiones creadas por conectores específicos en Azure Logic Apps.

Guía de aislamiento para aplicaciones lógicas

Puede usar Azure Logic Apps en Azure Government, que admite todos los niveles de impacto en las regiones que se describen en la guía de aislamiento de nivel de impacto 5 de Azure Government. Para cumplir estos requisitos, Logic Apps admite la funcionalidad para que cree y ejecute flujos de trabajo en un entorno con recursos dedicados de modo que pueda reducir el impacto en el rendimiento de otros inquilinos de Azure en las aplicaciones lógicas y evitar compartir recursos informáticos con otros inquilinos.

• Para ejecutar su propio código o realizar la transformación XML, cree y llame a una función de Azure, en vez de usar la funcionalidad de código en línea o proporcionar ensamblados para usarlos como mapas, respectivamente. Asimismo, configure el entorno de hospedaje de la aplicación de funciones para cumplir los requisitos de aislamiento.

  Por ejemplo, para cumplir los requisitos de nivel de impacto 5, cree la aplicación de funciones con el plan de App Service mediante el plan de tarifa aislado junto con una instancia de App Service Environment (ASE) que también usa el plan de tarifa aislado. En este entorno, las aplicaciones de funciones se ejecutan en máquinas virtuales y redes virtuales de Azure dedicadas, que proporcionan aislamiento de red sobre el aislamiento de proceso para las aplicaciones y las máximas posibilidades de escalabilidad horizontal.

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

  • Planes de Azure App Service
  • Opciones de redes de Azure Functions
  • Hosts dedicados de Azure para máquinas virtuales
  • Aislamiento de máquina virtual de Azure
  • Implementación de servicios de Azure dedicados en las redes virtuales

• En función de si usa Azure Logic Apps de inquilino único y multiinquilino, tiene estas opciones:

  • Con las aplicaciones lógicas basadas en un solo inquilino, puede comunicarse de forma privada y segura entre flujos de trabajo de aplicación lógica y una instancia de Azure Virtual Network mediante la configuración de puntos de conexión privados para el tráfico entrante, así como usar la integración de Virtual Network para el tráfico saliente. Para obtener más información, revise Protección del tráfico entre redes virtuales y Azure Logic Apps de inquilino único mediante puntos de conexión privados.

  • Con las aplicaciones lógicas basadas en varios inquilinos, puede crear y ejecutar las aplicaciones lógicas en un entorno del servicio de integración (ISE). De esa forma, las aplicaciones lógicas se ejecutan en recursos dedicados y pueden acceder a recursos protegidos por una instancia de Azure Virtual Network. Para obtener más control sobre las claves de cifrado utilizadas por Azure Storage, puede configurar, usar y administrar su propia clave mediante Azure Key Vault. Esta funcionalidad también se conoce como "Bring Your Own Key" (BYOK) y la clave se denomina "clave administrada por el cliente". Para obtener más información, revise Configure claves administradas por el cliente para cifrar los datos en reposo para los entornos del servicio de integración (ISE) en Azure Logic Apps.

  Importante

  Algunas redes virtuales de Azure usan puntos de conexión privados (Azure Private Link) para proporcionar acceso a los servicios de PaaS de Azure, como Azure Storage, Azure Cosmos DB o Azure SQL Database, servicios de asociados o servicios de clientes que se hospedan en Azure.

  Si los flujos de trabajo necesitan acceso a redes virtuales que usan puntos de conexión privados y desea desarrollar esos flujos de trabajo mediante el tipo de recurso Aplicación lógica (consumo) , debe crear y ejecutar las aplicaciones lógicas en un entorno del servicio de integración. Sin embargo, si desea desarrollar esos flujos de trabajo mediante el tipo de recurso Aplicación lógica (estándar) , no necesita un entorno del servicio de integración. En su lugar, los flujos de trabajo pueden comunicarse de forma privada y segura con redes virtuales mediante el uso de puntos de conexión privados para el tráfico entrante y la integración de Virtual Network para el tráfico saliente. Para obtener más información, revise Protección del tráfico entre redes virtuales y Azure Logic Apps de inquilino único mediante puntos de conexión privados.

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

• Aislamiento en la nube pública de Azure
• Seguridad para aplicaciones IaaS altamente confidenciales en Azure

Pasos siguientes

• Base de referencia de seguridad de Azure para Azure Logic Apps
• Automatización de la implementación para Azure Logic Apps
• Supervisión de aplicaciones lógicas