Azure App Service

Security recommendations

There are numerous security recommendations to consider when hosting apps on App Service. These are some of the most common ones:

• Use the latest version if possible Make sure the platforms, frameworks, programming languages, and protocols used by your apps are up to date. This can significantly reduce the attack surface.

• Turn off anonymous access Anonymous access is one of the leading causes of data theft. Unless there is a need to allow anonymous requests, it is recommended that you disable it completely. If you absolutely must allow anonymous requests, expose only the app elements that require anonymous access while securing all other APIs or access points.

• Use the built-in authentication module Rather than using custom code, employ the built-in authentication module to handle all authentication and authorization requests. This helps reduce coding errors that might pose a security threat—not to mention saving you time and effort.

• Protect access to back-end resources Make sure back-end resources are protected by using authentication. This authentication could call for either the user’s identity or their managed identity. Managed identity is an identity managed by the Azure platform itself. This makes it easy to maintain because it eliminates the need to rotate secrets manually.

• Map custom domains and use certificates It is a good practice to map custom domains for apps. This makes it easier for end-users to access the app. App Service supports several types of certificates, based on security needs:

  • Free App Service Managed certificate This is a free certificate issued by DigiCert, which is automatically renewed every six months. Be aware that this certificate has some limitations. For example, it does not allow exports, it is not supported with ASE, and it does not support wildcard certifications. In addition, it does not support client authentication and does not integrate with Traffic Manager. However, if these are acceptable, then it is a great option.

  • App Service certificate This is a certificate issued by GoDaddy. There are two types currently available: Standard and Wildcard. The certificate is stored in Azure Key vault and automatically renewed.

  • Third-party certificate This is a certificate procured from a trusted third-party certificate provider. These certificates can either be imported into Azure Key Vault and then imported into App Service or imported directly into App Service.

• Private certificate This is a certificate created by the customer using an internal PKI infrastructure. This certificate is best for apps used for internal testing or for apps used by internal employees on managed devices. This certificate requires the certificate chain to be deployed on the device. The certificate can be imported into Azure Key Vault and then imported into App Service or imported directly into App Service.

• Use certificates to limit access If you need to limit access to the application to specific clients, using a certificate for client authentication is highly recommended, as it blocks connections from clients missing the required certificate.

• Use HTTPS instead of HTTP Although App Service allows both HTTP and HTTPS connections, it is highly recommended that all HTTP requests be redirected to HTTPS. This ensures that all connections are secured by default using the SSL/TLS certificate deployed for HTTPS. All authentication and client communication would take place on a secure channel, reducing traffic snooping.

• Disable TLS 1.0 Industry standards such as PCI DSS have deemed TLS 1.0 as an unsecure protocol. It is highly recommended that you disable TLS 1.0, forcing all apps to use TLS 1.1 or, preferably, TLS 1.2. Figure 3-51 shows the settings to use HTTPS only and to disable TLS 1.0.

  

  FIGURE 3-51 Setting HTTPS only and specifying the minimum TLS version.

• Encrypt communication When integrating apps with other Azure services such as Azure Storage, Azure SQL Database, or other database services, all communication between the workloads remains within the Azure back end. However, that traffic is on shared network infrastructure within Azure. Therefore, it is highly recommended that you encrypt this traffic to ensure that all communication is secure at all times.

• Secure FTP traffic Use the FTP protocol judiciously, only when required. In addition, use it only over SSL/TLS so that all communication is secure. In short, avoid using FTP unless absolutely necessary.

• Use Key Vault or environment variables Use Azure Key Vault and managed identity for secure storage, access, and management of application secrets. This includes API tokens, database credentials, and private keys that are otherwise included in the application code. If you cannot use managed identities, then it is recommended that you use environment variables in app settings and connection strings to store these values. These are stored securely with encryption and are decrypted just before being passed on to the application’s process memory. The Azure platform manages the encryption keys and rotates them on a regular basis, making the system very difficult to breach.

• Define IP restrictions (if necessary) Depending on your application access requirements, access to the app can be restricted for certain IP addresses or IP ranges only. This can help secure access especially for highly sensitive apps where the users accessing the application are known and access has to be limited to known networks only.

• Define dynamic access restrictions For apps hosted on a Windows-based App Service, you can prevent external distributed denial of service (DDoS) attacks defining the following parameters to dynamically restrict access:

  • Deny IP address based on the number of concurrent requests.

  • Deny IP address based on the number of requests over a period of time.

• Use the Isolated pricing tier for network isolation The Isolated tier is best used for apps that require all network infrastructure to be isolated and dedicated for use by a single organization only. If your organization has compliance or security needs that require such enforcement, use the Isolated tier.

• Protect communications when accessing on-premises resources On-premises resources can be accessed using Hybrid Connections, via site-to-site VPNs, or by connecting the ASE directly to an on-premises environment. Each of these methods provides secure access to resources. Based on the network topology in place, select the best method for your environment, making sure all communication is directed over the selected channel only.

• Use NSGs for ingress traffic Use NSGs to protect and manage ingress traffic and network access. Expose only the required endpoints and prevent access to others. Periodically review the NSG configuration to make sure no unwanted endpoints are exposed.

• Leverage Azure Security Center You should use the Azure Security Center service to periodically carry out security assessments. You should also implement recommendations issued by Azure Security Center to plug security holes and employ its Integrated Threat Intelligence functionality to prevent traffic from known-malicious IP addresses.

• Use Azure Policy Use Azure Policy to define and implement built-in policies for App Service, such as HTTPS enforcement, minimum allowed TLS version, and enforcement of a virtual network service endpoint.

• Use Azure Activity Log to monitor changes After policy definitions are in place, you can use Azure Activity Log to monitor configuration changes to network resources, network settings, and any resources related to App Service.

• Use Azure Monitor for centralized logging You can store Azure Activity and App Service Diagnostic Logs in Azure storage, Log Analytics, or event hubs. Azure Monitor then uses these to centrally monitor events and changes.

• Encrypt source data at rest It is a recommended practice to encrypt application source data at rest. This means encrypting the data stored in Azure storage with platform- or customer-managed encryption keys and using Azure Key Vault to inject application secrets at runtime as part of the application settings.

• Use WAF for inbound traffic Secure access to an internet-facing application using the WAF deployed in front of the app. Then use service endpoints and access restrictions on the WAF to secure ingress traffic. A WAF protects internet-facing applications from DDoS attacks, URI filtering, and SQL injection attacks.

• Use Azure Firewall for outbound traffic Use the Azure Firewall service to centrally divert all outbound traffic. This allows the enforcement of traffic-management policies and captures and monitors logs for centralized analysis.