Securing an app service 3 – Creating and Configuring App Services

You can also consider using backups and disaster recovery (DR) for your applications. But why? If your application becomes compromised and you need to perform restoration tasks, without backups, you would potentially lose all your critical data. Therefore, anything that could cause the application to go offline or become inaccessible would compromise the security of the application. The same is true for DR; if you can’t restore an active instance of the application, its security is compromised as potential usage of the application will be restricted, which could lead to several other issues for an organization and a loss of revenue.
The next menu you should click through is TLS/SSL settings. On this blade, select the Bindings tab and ensure that HTTPS Only is set to On. This ensures that all your traffic is encrypted and secured to the application, where HTTP traffic allows compromises to occur and should always be configured to forward all HTTP requests to HTTPS. HTTP communicates in clear text, so any credentials or sensitive information that’s sent would be visible to anyone that could intercept the traffic, which is highly insecure. HTTPS requires a certificate, which can be configured within the same blade. Azure offers one free certificate per web application for a single domain:

Figure 12.31 – Protocol Settings – TLS/SSL bindings

Next, click on the Networking option from the left menu of the application. Networking is an interesting topic for your applications and can result in many sleepless nights if it’s not planned and managed correctly. The rule of thumb for hardening your network is to secure your perimeters and isolate traffic via perimeters, as well as by adopting the Zero Trust model (where you don’t trust any application or service that doesn’t intend to communicate with the application). It should only be public-facing if your application requires public access. You will also want to consider a Web Application Firewall (WAF) and firewall service for public traffic, as well as something internal. Azure provides several options for privatizing traffic for your application and it’s important to understand your traffic flow when you’re considering your implementation. The first item you must configure here is Access restriction, which applies to inbound traffic. This will act as a whitelist or blacklist for your traffic, depending on how you configure your rules. To configure this, click Access restriction:

Figure 12.32 – Network settings – Inbound Traffic 1

As the most secure option, you should restrict all traffic except for your allowed rules. You will notice that you can configure your restriction rules for two different endpoints. The first is the public endpoint for your application, while the second has a suffix starting withscm, which is used for the Kudu console and web deployments. To see the available configuration options, click + Add rule:

Figure 12.33 – Network settings – Access Restrictions

On the Add Restriction pane that appears, you can set a Name; enter something meaningful. Next, you must decide on an Action, which can be either Allow
or Deny; click Allow. You can also enter a Priority and, optionally, a Description. The next option, Type, is very important as it is used to determine the type of restriction that’s being implemented and how the rule is invoked. The default configuration is IPv4, which is limited to a known IPv4 address or range (usually a public address or range) and is added to the IP Address Block text box. When entering a range, you can enter it in CIDR notation, with a single IP being /32 for the CIDR. Enter an IP address. IPv6 works in the same fashion except for IPv6 addresses or ranges. The Virtual Network source option allows you to select a network that you have configured previously to allow traffic through. The final option is Service Tag. Click Add rule:

Figure 12.34 – Add Restriction