Azure – Protect My App

If you’ve taken a path to adopt public cloud and part of that adoption is a public facing application, you need to review how you are protecting it within Azure. When your application was on-premises, there was most likely only a single well managed solution to granting external access. In Azure, there are several various solutions available and each carries its own set of functionality and risk.

Rather than try define that entire list, let us look at how best to protect your application, regardless of how you have deployed it. With Azure, these are my three preferred options:

  1. Azure AD Application Proxy
  2. Azure Application Gateway
  3. 3rd Party Network Virtual Appliance

These arguably run from least to most secure. An important tip is to treat each application as unique, because it is. There is not a single best solution for all of your applications and as Azure is a shared model of security it is up to you to protect your data!

Awkward stuff out of the way, let’s look at Application Proxy, we’ve already had a post on setting this up here. The key point with this service is that you do not have your site exposed externally at a network level. Of course, the application itself will be and therefore possibly your server and data, but there is not an open endpoint accepting traffic.

Next is Application Gateway. This is actually a load-balancing solution but you can enable the Web Application Firewall tier easily. This provides protection of your applications from common exploits and vulnerabilities. However, this protection is based on rules from the OWASP core rule set and while it is configurable, this only means you can disable certain rules, not add custom ones. Application Gateway can seamlessly integrate into your environment whether you are running PaaS or IaaS solutions and is economical from a cost perspective. However, that point regarding customisation can often be the deciding factor in choosing our third option instead.

Finally, a 3rd party appliance. Azure offers solutions from the majority of the major providers in this space. Easily deployable from the Azure Marketplace within minutes. Integration options are good but require some work, (See post on routing here) and cost can be a factor to meet required availability levels. But if you need maximum protection and customisation, this is your best option.

Overall, I think there is definitely a solution in Azure that will meet your requirements. Take the time to understand your application, consult with your SMEs and you won’t go wrong!

 

 

Azure AD Application Proxy

Web applications that are only accessible on your corporate LAN are common place in most companies. The lack of public access can be the result of many factors, most commonly the reason is the complexity of allowing a route through your secure perimeter. As a result, providing access to these applications has traditionally involved creating and utilising virtual private networks (VPNs) or demilitarized zones (DMZs), both requiring significant IT effort to put in place and keep secure. Adding to this, a lot of these applications can be quite difficult to lift and shift into a DMZ which would of course be best practise. Overall, both solutions have several complexities and offer different degrees of difficulty to manage.

Enter Azure AD Application Proxy (AP). This service can provide single sign-on (SSO) and secure remote access for these common web applications. It leverages your current infrastructure and ties into Azure AD for identity management so if you are already using Office 365, the authentication process for users is identical and the configuration required is minimal. Additionally, the page will be available on any web-accessible device at all times. This greatly simplifies the process as you don’t need to change your network infrastructure or allow VPN access for external users.

Again, those already using Office 365 will have their identities, or a version of them, active within Azure AD. When using AP, you can require users pre-authenticate before the internal page loads, offering an additional layer of security and auditing. If your identities are federated for example, this process ties-in seamlessly without any further configuration required. The ability to then add a method of passthrough authentication is when your end users life is made a lot easier.

To make use of AP, you need to install at least one connector in your environment. The requirements for this installation are here. The beauty of the connector is that it only requires outbound ports on your firewall and the main ports are 80 and 443, ports you would most likely already have open. Again, Microsoft are trying to make this as simple as possible! Once you have a connector installed and active, it is a good idea to install at least one more. This allows for high availability should one of the servers be inaccessible accidentally or due to maintenance.

Next, you obviously want to publish your application. This can be done in several ways, from the very simple to the completely integrated. Digging through those complexities is something that requires a lot more time than this blog post is suitable for, but believe me, with some guidance from an experienced architect, this process is very much achievable in the majority of environments. Here is some additional reading on application publishing:

Publishing Applications

SSO utilising KCD

Remember, AP isn’t just for simple internal web applications like your intranet page. It can be leveraged to provide SSO and secure remote access to your on-premise Sharepoint farm and even applications published locally via RDS.

I’ve implemented this service for several clients and they all compliment the functionality it allows them to leverage. The guidance during the configuration phase allows IT admins to then layer additional points of access to applications that would previously have been simply to cumbersome to offer externally. In my opinion, AP is one of the best features of Azure AD and it is only improving as Microsoft adds additional options for security and functionality.

This post is much more of an introduction to AP than a guide to configuration, if you want to talk about config, or have any other questions you can contact me on Twitter – @wedoAzure or via email.