You dont have javascript enabled! Please enable it!

Enforce TLS 1.2 on Web Apps with Azure Policy

8 Min. Read

This article will demonstrate how to enforce TLS 1.2 on Azure App Services (Web App and Function App) with Azure Policy.

A common theme in cloud environments is enforcing organizational standards and adopting cloud governance since day one. And this is very important since it will give you the ability to define policies, processes, and procedures. These policies then dictate what can be done and verify that what does exist is correct. A service from Microsoft called Azure Policy is a great way to make that happen and take proactive action.

Introduction

Azure Policy is a service in Azure that you use to create, assign, and manage policies. These policies enforce different rules and effects over your resources, so those resources stay compliant with your corporate standards and service level agreements. Azure Policy meets this need by continuously evaluating your resources for non-compliance with assigned policies.

Azure App Service enables you to build and host web apps, mobile back ends, and RESTful APIs in the programming language of your choice without managing infrastructure. It offers auto-scaling and high availability, supports both Windows and Linux, and enables automated deployments from GitHub, Azure DevOps, or any Git repo.

You have a policy in your organization that dictates to enforce the implementation of the latest TLS encryption version on all new and existing App Services (web applications and function apps) within your subscriptions. As you know, you should protect your applications from potential threats by encrypting data in transit.

If we take a quick look at Microsoft Defender for Cloud as shown in the figure below, we do have already a built-in Policy definition which is based on the latest and default Azure Security Benchmark (V3) that requires having the latest TLS version used for web apps and function apps to pass this recommendation.

TLS should be updated to the latest version for web apps
TLS should be updated to the latest version for web apps

Based on this built-in policy, when you deploy a web app or function app, Microsoft Defender for Cloud will evaluate the configuration and check if you are using a lower TLS version (i.e.  TLS 1.0 or TLS 1.1) and then recommends using the latest TLS version to ensure your data is secured and encrypted in transit from network layer eavesdropping attacks.

However, this policy does not auto-remediate the unhealthy resources, therefore, you should manually remediate them as described in the ‘Remediation steps‘, you can remediate all the unhealthy resources at once by triggering a logic app if you want. You can also exempt this security recommendation if needed, but we don’t recommend doing so because it’s categorized as ‘High‘ severity.

Once you have invested time and effort in remediating these resources to increase your Secure Score, you want to make sure that it will not decrease by a serious percentage, again. The problem is that the remediation is always done for existing resources, but NOT for new ones and/or if the user sets a lower TLS version afterward.

By default, when you create a web app or function app, Microsoft will enable the latest TLS version available (today is v1.2 and in the near future they will include TLS v1.3). You can think of remediating resources as a reactive versus a proactive approach.

As cybersecurity hygiene (practice), you need to have solid governance to ensure that the resources you deploy will not deviate and meet certain security standards, patterns, and configurations. And even if the application owner changes the configuration, your applications will remain secure by default.

To ensure proper governance, we need to use Azure Policy. This will allow us to enable and enforce the latest TLS version on new deployed App Services, as well as remediating existing resources at scale if the users create a less secure web app, so you can make sure your organization’s policy and security requirements are met.

Prerequisites

To follow this article, you need to have the following:

1) An Azure subscription. If you don’t have an Azure subscription, you can create a free one here.

2) At least one web app or function app is deployed in your subscription.

3) You need to have the appropriate permissions to create and manage Azure Policy definitions. The Azure RBAC built-in roles that you can use are Resource Policy Contributor or Security Admin.

4) Last but not least, you need to have the appropriate permissions to assign the Contributor role for the Managed Identity (Application ID) created during the assignment of the policy either on a management group or a subscription, so the policy with “DeployIfNotExists” can remediate and modify your Web App settings. Azure Policy creates a managed identity for each assignment but must have details about what roles to grant the managed identity.

If the managed identity is missing roles, an error is displayed during the assignment of the policy or an initiative. Please note that when creating an assignment through the Azure Portal, the role assignments are auto-granted. However, when using PowerShell, you must manually configure the managed identity. More information can be found here.

Assuming you have all the prerequisites in place, take now the following steps:

Enforce the Latest TLS Policy definition

A quick overview of Azure Policy effects. Each policy definition that you create in the Azure Policy has a single effect. That effect determines what happens when the policy rule is evaluated to match. The effects behave differently if they are for a new resource, an updated resource, or an existing resource.

In this example, we need to enable and enforce the latest TLS encryption version for all new web apps and functions apps, as well as on existing resource(s) in our environment. For this to work, we need to use the “DeployIfNotExists” policy. To understand how the Azure Policy effect works with the “DeployIfNotExists” policy definition, please check the official documentation from Microsoft here.

Open the Azure Portal, click “All services” and then search for “Policy” and then click on “Definitions” → “+ Policy definition”.

For the “Definition location“, select the location by clicking the ellipsis [] and select either a management group or a subscription.

In the “Name“ field, give a descriptive name for the policy definition such as – “Enforce The Latest TLS Version for Azure App Services” and Description.

In the “Category” section, select the appropriate category for this policy. In this example, we will choose “App Service” as shown in the figure below.

Create Azure Policy Custom Definition
Create Azure Policy Custom Definition

For the “POLICY RULE“, paste the following policy definition in JSON format and then click “Save“.

For the “Role definitions“, make sure that the Contributor is selected. The contributor role is required to enable and enforce the latest TLS version on the resources.

Here is the Policy definition in JSON format:

{
  "mode": "All",
  "policyRule": {
    "if": {
      "field": "type",
      "equals": "Microsoft.Web/sites"
    },
    "then": {
      "effect": "[parameters('effect')]",
      "details": {
        "type": "Microsoft.Web/sites/config",
        "name": "web",
        "existenceCondition": {
          "field": "Microsoft.Web/sites/config/minTlsVersion",
          "equals": "1.2"
        },
        "roleDefinitionIds": [
          "/providers/Microsoft.Authorization/roleDefinitions/b24988ac-6180-42a0-ab88-20f7382dd24c"
        ],
        "deployment": {
          "properties": {
            "mode": "incremental",
            "parameters": {
              "webAppName": {
                "value": "[field('name')]"
              },
              "location": {
                "value": "[field('location')]"
              },
              "kind": {
                "value": "[field('kind')]"
              }
            },
            "template": {
              "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
              "contentVersion": "1.0.0.0",
              "parameters": {
                "webAppName": {
                  "type": "string"
                },
                "location": {
                  "type": "string"
                },
                "kind": {
                  "type": "string"
                }
              },
              "resources": [
                {
                  "type": "Microsoft.Web/sites/config",
                  "apiVersion": "2021-02-01",
                  "name": "[concat(parameters('webAppName'), '/web')]",
                  "location": "[parameters('location')]",
                  "kind": "[parameters('kind')]",
                  "properties": {
                    "minTlsVersion": "1.2"
                  }
                }
              ]
            }
          }
        }
      }
    }
  },
  "parameters": {
    "effect": {
      "type": "String",
      "metadata": {
        "displayName": "Effect",
        "description": "Enable or disable the execution of the policy"
      },
      "allowedValues": [
        "DeployIfNotExists",
        "AuditIfNotExists",
        "Disabled"
      ],
      "defaultValue": "DeployIfNotExists"
    }
  }
}

In this custom policy, we are looking for all kinds of applications (web app, container, Windows, Linux, and function app), and then we are checking if the minimum TLS version is set to 1.2.

Improvement (work in progress): As part of the next update of this policy, we will check if you are using staging environments in Azure App Service, as you probably know, you can clone the app settings from the production app, or set the configuration differently. In this case, the user can also set a lower TLS version for the staging app as shown in the figure below. The Policy will detect that and flag it as Non-compliant.

Set up staging environments in Azure App Service
Set up staging environments in Azure App Service

The ExistenceCondition option in the template above is super useful for the Azure App Services that has already the TLS version set to 1.2. If this condition is true, the policy definition will skip the deployment defined in the “DeployIfNotExists” section in the template. Please check the documentation here to learn more about the ExistenceCondition option for the “DeployIfNotExists” properties.

Assign Custom Policy definition

To assign the custom policy definition, take the following steps:

If you want to automate the deployment and assignment of Azure Policies via Azure DevOps instead of using the Azure Portal, then please check the following step-by-step guide.

Open the Azure Portal, click “All services” and then search for “Policy” and then click on “Assignments”. An assignment is a policy that has been assigned to take place within a specific scope.

Select “Assign policy” from the top of the “Policy | Assignments” page.

On the “Assign Policy” page, select the Scope by clicking the ellipsis [] and select either a management group or subscription. You can optionally select a resource group if you want. A scope determines what resources or grouping of resources the policy assignment gets enforced on. Then click Select at the bottom of the Scope page.

Select the Policy definition ellipsis [] to open the list of available definitions. Choose the custom policy that we created in the previous step. The Policy enforcement is Enabled by default. Click Next to continue.

On the Parameters page, specify the parameters for this policy assignment (DeployIfNotExists, AuditIfNotExists, or Disabled). The default value is set to “DeployIfNotExists“, you can disable the effect of this policy later on by setting the effect to “Disabled“. The “Audit” is used to create a warning event in the activity log when evaluating a non-compliant resource, but it doesn’t stop the request. Click Next to continue.

Assign Azure Policy Custom Definition
Assign Azure Policy Custom Definition

In the Remediation page, by default “Create a Managed Identity” is selected for you because existing resources can be updated via a remediation task after the policy is assigned only. Choose the default location for the “Managed Identity“, this is required because policies with the “deployIfNotExists” and “Modify” effect types need the ability to modify resources and edit the configuration on existing resources respectively. To do this, a managed identity will be created automatically for each policy assignment. This identity will also be given the “Contributor” permissions on the scope that you have selected. Click Next to continue.

Remediation - Create a Managed Identity
Remediation – Create a Managed Identity

On the Non-compliance messages page, set the desired message (i.e. TLS should be at the latest version for web apps). Then click the “Review + create” button.

Azure Policy - Non-compliance message
Azure Policy – Non-compliance message

Finally, click “Create” to create the assignment.

Verify TLS on Azure App Services

To verify that the custom policy is deployed successfully, you need to wait for at least 30 minutes after a resource has been created or updated. The policy won’t be triggered immediately, this is by design. To trigger the policy compliance scan manually (immediately), open the cloud shell and run the following command:

$job = Start-AzPolicyComplianceScan -AsJob
$job | ft -AutoSize

The scan job will run in the background as shown in the output below.

Trigger Azure Policy Compliance Evaluation Manually
Trigger Azure Policy Compliance Scan manually

If you want to check Azure Policy compliance status and remediate non-compliant resources via Azure DevOps Pipelines, then please check the following step-by-step guide.

Behind the scene, Azure Policy will create a Remediation task as shown in the figure below. To remediate existing resources, select the desired policy and then click on the “Remediate” button.

Policy Remediation - Enforce The Latest TLS Version for Azure App Services
Policy Remediation – Enforce The Latest TLS Version for Azure App Services

Please note that during an evaluation cycle, the policy definition with a “DeployIfNotExists” effect that matches resources is marked as non-compliant only, but no action is taken on that resource. For this reason, the remediation task was created when you assign the policy definition as described in the previous section.

Open the Azure Portal, click “All services” and then search for “Policy” and then click on “Remediation”. In the Policy | Remediation page, select the Remediation tasks tab, and check the status of the auto-remediation task. It’s completed successfully without any error.

Azure Policy - Remediation tasks
Azure Policy – Remediation tasks

If you look at the Web App resource under Settings | TLS/SSL settings, you can see that the “Minimum TLS Version” toggle is set to 1.2.

Azure App Service - TLS Version 1.2
Azure App Service – TLS Version 1.2

If we look at the compliance policy state, we will see that all Azure App Services in this environment (5) are compliant and the TLS version is at the latest.

Azure Policy Compliance State
Azure Policy Compliance State

That’s it there you have it!

Summary

In this article, we showed you how to enable and enforce TLS 1.2 on Azure App Services with Azure Policy at the application level, so you can make sure your organization’s policy and security requirements are met.

Please note that you need to have a separate custom policy for each Azure resource or for each configuration you need to enforce such as enabling FTPS, HTTPS, TLS, etc. You could create all the needed policy definitions for your environment and then add them all to an initiative definition and then assign the initiative scope based on Management Group, Subscription, or Resource Group. We highly recommend using Management Groups if you are not doing so already.

> Learn more about enabling HTTPS on Azure App Services with Azure Policy, check the following step-by-step guide.

> Learn more about auditing publicly accessible Azure App Services with Azure Policy, check the following step-by-step guide.

> Learn more about auditing subnets that do not have Network Security Group (NSG) associated, check the following step-by-step guide.

> Learn more about enabling diagnostic settings for storage accounts to Event Hub, check the following step-by-step guide.

> Learn more about Azure Policy, check the official documentation from Microsoft.

__
Thank you for reading my blog.

If you have any questions or feedback, please leave a comment.

-Charbel Nemnom-

Related Posts

Previous

Simulate and Validate CEF Logs to Microsoft Sentinel

How to Recover Corrupted PDF Files

Next

Let me know what you think, or ask a question...

error: Alert: The content of this website is copyrighted from being plagiarized! You can copy from the 'Code Blocks' in 'Black' by selecting the Code. Thank You!