Merge pull request #288464 from ecfan/patch-1

Expand security guidance to regenerating access keys

Author: prmerger-automator[bot]

articles/logic-apps/logic-apps-securing-a-logic-app.md

@@ -5,7 +5,7 @@ services: logic-apps
 ms.suite: integration
 ms.reviewer: estfan, rarayudu, azla
 ms.topic: how-to
-ms.date: 08/15/2024
+ms.date: 10/15/2024
 ---
 
 # Secure access and data for workflows in Azure Logic Apps
@@ -910,7 +910,7 @@ When a workflow starts with a request-based trigger, and you save that workflow
 
 For example, to view this URL in a **Request** trigger, find the trigger's **HTTP URL** property:
 
-:::image type="content" source="media/logic-apps-securing-a-logic-app/request-trigger-url.png" alt-text="Screenshot shows Azure portal, Consumption workflow designer, and Request trigger endpoint URL." lightbox="media/logic-apps-securing-a-logic-app/request-trigger-url.png":::
+:::image type="content" source="media/logic-apps-securing-a-logic-app/request-trigger-url.png" alt-text="Screenshot shows Azure portal, Consumption workflow designer, and Request trigger endpoint URL.":::
 
 The complete URL looks like the following example:
 
@@ -924,31 +924,32 @@ The SAS in the URL has query parameters, which the following table describes:
 | **`sv`** | Specifies the SAS version to use for generating the signature. |
 | **`sig`** | Specifies the signature to use for authenticating access to the trigger. This signature is generated by using the SHA256 algorithm with a secret access key on all the URL paths and properties. This key is kept secret and encrypted, stored with the logic app, and is never exposed or published. Your logic app authorizes only those triggers that contain a valid signature created with the secret key. |
 
-> [!CAUTION]
+> [!IMPORTANT]
 >
-> Make sure to protect an SAS just as you would protect an account key from unauthorized use. 
-> Set up or have a plan in place for revoking a compromised SAS key. Employ discretion in 
-> distributing an SAS URI, and only distribute SAS URIs over a secure connection such as HTTPS. 
-> Make sure to only perform operations that use an SAS over an HTTPS connection. 
+> Make sure to protect your SAS key just as you protect an account key from unauthorized use. Set up or have a plan 
+> for revoking a compromised access key. Use discretion when you distribute URIs that use access keys, and only
+> distribute such URIs over a secure connection such as HTTPS. Make sure to only perform operations that use an access 
+> key over an HTTPS connection. Anyone that has a URI with valid key can access the associated resource. To maintain
+> security and protect access to your logic app workflow, [regenerate access keys](#regenerate-access-keys) on a regular
+> schedule as they might need to comply with security policies or become compromised. This way, you can make sure that
+> only authorized requests can trigger your workflow, which protects your data and processes from unauthorized access.
 >
-> If you use an SAS to access storage services, Microsoft recommends that you 
+> If you use an SAS key to access storage services, Microsoft recommends that you 
 > [create a user delegation SAS](/rest/api/storageservices/create-user-delegation-sas), 
 > which is secured with [Microsoft Entra ID](/entra/identity/authentication/overview-authentication), 
 > rather than an account key.
-
-Inbound calls to the endpoint on a request-based trigger can use only one authorization scheme, either SAS or [OAuth 2.0 with Microsoft Entra ID](#enable-oauth). Although using one scheme doesn't disable the other, if you use both schemes at the same time, Azure Logic Apps generates an error because the service doesn't know which scheme to choose.
-
-If your Consumption workflow starts with the **Request** trigger, you can [disable SAS authentication](#disable-sas). This option works even if you also [restrict authorization to use only OAuth 2.0 with Microsoft Entra ID](#enable-oauth-only-option). For Standard workflows, you can use other authentication types without disabling SAS.
-
-> [!IMPORTANT]
 >
 > For optimal security, Microsoft recommends using [Microsoft Entra ID](/entra/identity/authentication/overview-authentication) 
-> with [managed identities](/entra/identity/managed-identities-azure-resources/overview) for authentication when possible. 
+> with [managed identities](/entra/identity/managed-identities-azure-resources/overview) for authentication whenever possible. 
 > This option provides superior security without having to provide credentials. Azure manages this identity and helps keep 
 > authentication information secure so that you don't have to manage this sensitive information. To set up a managed identity 
 > for Azure Logic Apps, see [Authenticate access and connections to Azure resources with managed identities in Azure Logic Apps](authenticate-with-managed-identity.md).
 
-For more information about using SAS, see the following sections in this guide:
+Inbound calls to the endpoint on a request-based trigger can use only one authorization scheme, either SAS or [OAuth 2.0 with Microsoft Entra ID](#enable-oauth). Although using one scheme doesn't disable the other, if you use both schemes at the same time, Azure Logic Apps generates an error because the service doesn't know which scheme to choose.
+
+If you have a Consumption workflow that starts with the **Request** trigger, you can [disable SAS authentication](#disable-sas). This option works even if you also [restrict authorization to use only OAuth 2.0 with Microsoft Entra ID](#enable-oauth-only-option). For Standard workflows, you can use other authentication types without disabling SAS.
+
+For more information about security when you use an SAS key, see the following sections in this guide:
 
 * [Regenerate access keys](#regenerate-access-keys)
 * [Create expiring callback URLs](#expiring-callback-urls)
@@ -968,9 +969,9 @@ This option works even if you also [enable OAuth 2.0 with Microsoft Entra ID as
 
 > [!NOTE]
 >
-> This action disables SAS authentication for incoming requests and blocks existing SAS tokens or 
-> signatures from working. However, your SAS tokens or signatures remain valid and still work 
-> if you enable SAS authentication again. To disable SAS tokens and signatures, see 
+> This action disables SAS authentication for incoming requests and blocks existing SAS keys or 
+> signatures from working. However, your SAS keys or signatures remain valid and still work if you
+> enable SAS authentication again. To disable SAS keys and signatures by creating new versions, see 
 > [Regenerate access keys](#regenerate-access-keys).
 
 After you disable SAS authentication, the endpoint URL for the **Request** trigger no longer includes the SAS key, for example:
@@ -1051,14 +1052,34 @@ For Consumption workflows where you want to disable SAS authentication, follow t
 
 ### Regenerate access keys
 
-To generate a new security access key at any time, use the Azure REST API or Azure portal. All previously generated URLs that use the old key are invalidated and no longer have authorization to trigger the logic app. The URLs that you retrieve after regeneration are signed with the new access key.
+To maintain security and protect access to your logic app workflow, regenerate access keys on a regular schedule as they might need to comply with security policies or become compromised. This way, you can make sure that only authorized requests can trigger your workflow, which protects your data and processes from unauthorized access.
+
+To generate a new access key at any time, use the Azure REST API or Azure portal. All previously generated URIs or URLs that use the old key are invalidated and no longer have authorization to trigger your logic app workflow. The URIs that you retrieve after regeneration are signed with the new access key.
 
-1. In the [Azure portal](https://portal.azure.com), open the logic app that has the key you want to regenerate.
+1. In the [Azure portal](https://portal.azure.com), open the logic app resource that uses the key you want to regenerate.
 
 1. On the logic app resource menu, under **Settings**, select **Access Keys**.
 
 1. Select the key that you want to regenerate and finish the process.
 
+> [!IMPORTANT]
+>
+> Make sure to protect your access key just as you protect an account key from unauthorized use. Set up or have a plan 
+> for revoking a compromised access key. Use discretion when you distribute URIs that use access keys, and only
+> distribute such URIs over a secure connection such as HTTPS. Make sure to only perform operations that use an access 
+> key over an HTTPS connection. Anyone that has a URI with valid key can access the associated resource. 
+>
+> If you use an SAS key to access storage services, Microsoft recommends that you 
+> [create a user delegation SAS](/rest/api/storageservices/create-user-delegation-sas), 
+> which is secured with [Microsoft Entra ID](/entra/identity/authentication/overview-authentication), 
+> rather than an account key.
+>
+> For optimal security, Microsoft recommends using [Microsoft Entra ID](/entra/identity/authentication/overview-authentication) 
+> with [managed identities](/entra/identity/managed-identities-azure-resources/overview) for authentication when possible. 
+> This option provides superior security without having to provide credentials. Azure manages this identity and helps keep 
+> authentication information secure so that you don't have to manage this sensitive information. To set up a managed identity 
+> for Azure Logic Apps, see [Authenticate access and connections to Azure resources with managed identities in Azure Logic Apps](authenticate-with-managed-identity.md).
+
 <a name="expiring-callback-urls"></a>
 
 ### Create expiring callback URLs
@@ -1593,7 +1614,7 @@ On all other triggers and actions that support the **Active Directory OAuth** (O
 | Property (designer) | Property (JSON) | Required | Value | Description |
 |---------------------|-----------------|----------|-------|-------------|
 | **Authentication** | `type` | Yes | **Active Directory OAuth** (OAuth 2.0 with Microsoft Entra ID) <br>or <br>`ActiveDirectoryOAuth` | The authentication type to use. Azure Logic Apps currently follows the [OAuth 2.0 protocol](/entra/architecture/auth-oauth2). |
-| **Authority** | `authority` | No | <*URL-for-authority-token-issuer*> | The URL for the authority that provides the access token, such as `https://login.microsoftonline.com/` for Azure global service regions. For other national clouds, review [Microsoft Entra authentication endpoints - Choosing your identity authority](/entra/identity-platform/authentication-national-cloud#application-endpoints). |
+| **Authority** | `authority` | No | <*URL-for-authority-token-issuer*> | The URL for the authority that provides the access key, such as `https://login.microsoftonline.com/` for Azure global service regions. For other national clouds, review [Microsoft Entra authentication endpoints - Choosing your identity authority](/entra/identity-platform/authentication-national-cloud#application-endpoints). |
 | **Tenant** | `tenant` | Yes | <*tenant-ID*> | The tenant ID for the Microsoft Entra tenant |
 | **Audience** | `audience` | Yes | <*resource-to-authorize*> | The resource that you want to use for authorization, for example, `https://management.core.windows.net/` |
 | **Client ID** | `clientId` | Yes | <*client-ID*> | The client ID for the app requesting authorization |
@@ -1765,7 +1786,7 @@ For more information about isolation, see the following documentation:
 * [Isolation in the Azure Public Cloud](../security/fundamentals/isolation-choices.md)
 * [Security for highly sensitive IaaS apps in Azure](/azure/architecture/reference-architectures/n-tier/high-security-iaas)
 
-## Related contet
+## Related content
 
 * [Azure security baseline for Azure Logic Apps](security-baseline.md)
 * [Automate deployment for Azure Logic Apps](logic-apps-azure-resource-manager-templates-overview.md)