Azure Connectors, the DMZ 2.0?

  • Article

Hi,

I wanted to write this blog post because I'm often facing hard resistance from customers working with the Cloud and Hybrid Architectures regarding some security aspects.

A very well-known way to secure access to on-premises resources is by using a buffer perimeter called a DMZ, which is something everybody knows, including junior developers because it's probably as old as the Internet. While this way of working is usually very effective, it is certainly not the most efficient since it usually takes more time to have something new added to the DMZ than to the regular data center or directly in the Cloud (PaaS, Faas).

What alternative do we have? Well, we can still use good old reverse proxies which are also very effective but why not modernizing our thoughts and start using Azure built-in components that were conceived from the start to enable Hybrid Architectures, and more particularly the Azure Active Directory Proxy.

Providing you trust Microsoft as a vendor (if not, you can skip the remainder of this blog post :)), the Azure Active Directory Proxy (and basically most of the Azure Connectors) only require outbound traffic to ports 443 & 80 (80 being used for the connector setup). Don't get me wrong, opening only outbound traffic might be highly insecure as it is always possible for an attacker to reverse-shell your environment  but this is only true if you do not control your outbound connections.

The value proposition of the Azure Active Directory Proxy is to install connectors right in the data center using outbound connections that you can perfectly control as explained here . Your data center is indeed exposed but only to Microsoft which ensures eligible requests (should you enforce pre-authentication) are forwarded to the connector using the bi-directional outbound socket.

That said, there is no one size fits all and the AAD proxy is probably not adequate for every situation, however, I strongly encourage security people to be rational when it comes to modern approaches. Here is an ideal scenario of use for the proxy and some rational arguments:

Scenario: you have an on-premises hosted API that should be consumed by various consumers including native mobile apps.

Old fashion approach: you move the on-prem API to the DMZ or you put a DMZ component that relays calls to the on-prem API or you publish the on-prem API through a reverse-proxy.

Modern approach: you publish your on-premises API through the AAD proxy and you enforce pre-authentication (OAuth or OpenID at proxy level). You might also enable protocol transition (OAuth/OpenID to Kerberos) should you need it for your on-prem API.

Arguments:

  • Non-authenticated requests will be automatically discarded by the proxy service. So you already have a barrier against DOS/DDOS and you do not have to take care of it unlike you'd have with your own reverse-proxy and/or DMZ servers where you should validate incoming authorization tokens and be prepared for DOS/DDOS attacks over your public endpoint.
  • You have an automatic HA & Load Balanced architecture if you install multiple connectors and you can isolate these connectors on dedicated machines within the data center although this is optional.
  • The outbound connection only targets well-known endpoints (proxy service) protected by Microsoft which can be white-listed by your internal firewalls.
  • All the traffic but an initial call upon connector setup completion is TLS
  • Fast and easy configuration
  • You save yourself from maintenance burdens
  • Easy application-specific setup thanks to the Connector Groups
  • API consumers such as mobile developers can seamlessly request a token from Azure Active Directory for your on-premises API using the same SDKs as the ones they use to target Cloud services such as the Graph API.

and if you're still not convinced, run a pen test!

Happy Security!