You must have come across the scenario in your IT solution where customers have asked you to implement security layer across internet facing applications and organization’s internal applications. Main challenges we generally overcome are like below…
- Internal and external apps must be well differentiated (not mixed-up) in such a way that organization’s internal APIs must not be accessible from outside network (expect through customer’s LAN), and hence must be protected from external people and cyber attacks.
- External APIs (public or internet facing APIs – like customer or supplier connectivity modules) must be able to access securely over internet, which must be restricted to authorized users only.
There’re couple of common questions which most of your customers ask are :
- How do we protect the Internet-facing public endpoint of API Management?
- How can we selectively expose some API’s externally whilst keeping all other API’s internal to organization?
In Microsoft Azure cloud, security can be easily implemented for internet facing APIs and organization’s internal APIs with the use of Azure Application Gateway and Azure API Management. Most importantly, we should allow authorized people only (customer or supplier) to access internet facing APIs, whereas internal APIs must be made accessible to your organization employees within LAN network only. Single instance of Azure Application Gateway and Azure API Management will help you to implement such robust security layer across both the type of APIs. Let us discuss both of them in detail first, and then followed by their integration methodology to achieve the target.
What is Azure Application Gateway (AGW)?
Azure Application Gateway (AGW) is combination of web traffic manager and load balancer that helps you to manage traffic to you web applications, which are hosted inside Azure and/or on-premise.
Application Gateway works at Application Layer (OSI Layer 7), and specifically with HTTP/S including Web Sockets.
Traditional load balancers operate at the transport layer (OSI layer 4 – TCP and UDP) and route traffic based on source IP address and port, to a destination IP address and port. It supports secure socket layer termination security which makes a more secure way of load balancing and also supports HTTP-based load balancing and creates sessions on the basis of cookies.
Main features of AGW
1) Web traffic load balancer: It enables WebSocket and HTTPS protocols thereby enabling full-duplex communication between client and server using TCP connection. It handles balancing of load across pool of resources (ex: VM servers) in backend based on configurations made in AGW. The backend pool instances can be Azure Virtual Machines or instances in a virtual machine scale set. Traditional load balancers operate at the Transport Layer (OSI layer 4) and route traffic based on source IP address and port, to a destination IP address and port.
2) Routing with URI path and Host headers: It allows you to manage traffic across backend pools on the basis of URLs. In other words; it differentiates the traffic by URL and host header names. For example, you can route traffic based on the incoming URL. If /images are in the inbound URL, you can route traffic to a specific set of servers (or pool) configured for images. If /video is in the URL, that traffic is routed to another pool. This is depicted in below diagram.
Figure #1: Routing in AGW
3) Security: It supports a Web Application Firewall (WAF) which enables filtering of the traffic and protection with Zone Redundancy feature. Big advantage of WAF is that, it protects your workload from common exploits like SQL injection attacks or cross-site scripting attacks. Also note that, AGW acts as a reverse-proxy service.
4) Sticky Session Supported: it supports traffic based on the cookies. When you stop using a web app and re-login into the web app after some time, then the AGW diverts your request (or traffic) to the same web server (that was used earlier) as per the cookies for quick connection and faster delivery of services.
5) TLS/SSL termination/SSL Offload: TLS/SSL termination can be useful to allow unencrypted traffic between AGW and backend servers saving some of processing load needed to encrypt and decrypt said traffic. However, sometimes unencrypted communication to the servers is not acceptable because of security requirements, compliance requirements, or application may only accept a secure connection. In these situations, Application Gateway also supports end-to-end TLS/SSL encryption.
What is Azure API Management (API-M)?
1) It allows you to manage APIs across clouds and on-premises: Means; deploy the API gateways side-by-side with the APIs hosted in other clouds and on-premises to optimize API traffic flow. Meet security and compliance requirements while enjoying a unified management experience and full observability across all internal and external APIs.
Figure #2: Single API-M to manage APIs across clouds and on-premises (both internal and external internet facing APIs)
2) Enables single HTTPS endpoint: API Management is a wonderful service in Azure for abstracting your back-end services (many API services) and exposing those API’s via a single HTTPS endpoint.
3) APIs accessible only from within your LAN: The API Management service can be configured in a Virtual Network in internal mode, which makes your APIs accessible only from within your LAN (or Virtual Network).
Main features of Azure API Management
The API gateway is the endpoint that :-
- Accepts API calls and routes them to your backends.
- Verifies API keys, JWT tokens, certificates, and other credentials.
- Enforces usage quotas and rate limits.
- Transforms your API on the fly without code modifications.
- Caches backend responses where set up.
- Logs call metadata for analytics purposes.
Now, let’s discuss about AGW and API-M integration to gain intended security
Combining API Management provisioned in an internal VNET with the Application Gateway frontend enables the following scenarios:
- Use the same API Management resource for consumption by both internal consumers and external consumers.
- Use a single API Management resource and have a subset of APIs defined in API Management available for external consumers.
- Provide a turn-key way to switch access to API Management from the public Internet on and off.
Below architecture demonstrates integration of AGW and API-M. It highlights couple of key components like below…
- API Management deployed in “internal” VNET mode.
- Application Gateway (WAF) for exposing a subset of API’s externally.
Figure #3: Integration of AGW and API-M – High level architecture only
Now the question arises in your mind is, how are the API’s segregated so that only the ones deemed “external” are accessible via the Internet? Is it configured on API-M or the App Gateway?
It turns out the solution is a combination of both and is relatively simple…
- Within API-M, APIs are created with separate base URL’s like /external and /internal
- Within AGW, a path-based routing rule is created that redirects any API requests that contain /external to the API-M backend.
- The same routing rule drops requests to any other API requests containing /internal.
While API-M provides the ability to whitelist specific source IP addresses, the benefit of this architecture is that non-permitted API requests are blocked at the perimeter of your network as depicted below.
Figure #4: Shows APIs security through AGW and API-M integration (Internal API calls v/s external internet facing API calls + how they are deployed and protected)
Microsoft has a supported blueprint for above scenario, which basically covers below implementation topics. Hence consider to read through this blueprint to understand the implementation steps in details…
- How to use a single API Management service for both internal and external consumers and make it act as a single frontend for both on premises and cloud APIs.
- You will also see how to expose only a subset of your APIs (in the example they are highlighted in green in figure #3 above) for external consumption using routing functionality available in Application Gateway.
- All your APIs are managed only from within your Virtual Network. Internal consumers (highlighted in orange in figure #3 above) can access all your internal and external APIs. Hence, traffic never goes out to the internet.
- However please note that, high performance connectivity is delivered via Express Route circuits.
+++ Must read about Garner Magic Quadrant regarding API-Management services +++
Microsoft is proven as a Leader in the 2020 Gartner Magic Quadrant for Full Life Cycle API Management. Facts to know about Azure API Management are…
- API management is an essential component of digital transformation.
- API management enables security management across clouds and on-premises.
- It offers API discovery and onboarding.
- It is possible to deploy API Management artifacts using popular DevOps solutions such as GitHub Actions.