Organizations today face critical decisions when choosing how to protect their cloud applications and data. As architects and developers, we strive to design for optimal security when building in Azure. With applications running on Azure VMs (IaaS) or Azure App Service (PaaS), a key decision that often comes up is how to secure client access in a way that provides the right amount of control and visibility while allowing the flexibility needed to iterate forward. A few options we’ll explore are Network Security Groups (NSGs), Azure Application Gateway, and security devices available as Network Virtual Appliances (NVAs).
Some Clarification
First off, we need to define the problems we’re trying to address and what each proposed solution brings to the table. Common risks include unauthorized or inappropriate access to applications, application tiers, and individual servers and data sources. Issues also include web vulnerabilities, exploits, distributed denial of service (DDoS) attacks, and the list goes on. For more detailed examples, see the OWASP Top Ten Project, the seemingly endless list of security alerts from US-CERT, and others. Clearly, there are many facets to this issue, so there is rarely a one-size-fits-all solution.
The three options listed above, while not exhaustive, offer different capabilities and are each commonly used in Azure to address these problems. At a basic level, NSGs provide IP and port-based access control lists that apply to either subnets or network interfaces and can limit inbound traffic, outbound traffic, or both. These are useful for restricting management traffic to a server, for example, or allowing traffic between application subnets. Application Gateways, when deployed using the Web Application Firewall (WAF) SKU, operate as load-balancing reverse proxies at Layer 7 of the OSI Model (NSGs occupy Layer 4), providing them the ability to inspect HTTP headers and content while implementing rule sets that protect against the most common web vulnerabilities. NVAs, on the other hand, can function similarly to advanced next generation firewall devices within the Azure virtual network, allowing custom routing, security policies, integration with existing network management tools, and in some cases IPS/IDS features. This comes at the cost of added complexity.
Solution Summary:
NSGs
Application Gateway/WAF
NVAs
OSI Layers
Layer 4
Layer 7
Layers 3-7
Feature Summary
ACLs
Varies by vendor
Complexity
Low
Medium
High
Cost
None (only pay for resource consumption)
Varies based on compute requirements and vendor licensing cost
Better Together?
It’s important to note that not all these options are mutually exclusive. It’s perfectly reasonable—indeed, appropriate—to say that NSGs and either an Application Gateway or NVA would provide complementary functionality within an environment. Still, avoid duplicating protections across multiple products or management scopes to prevent introducing unnecessary complexity.
Ultimately, the unique needs of each project and organization will drive the decision on network security. A static public website running on Azure Web Apps will have vastly different requirements than a patient healthcare portal or a BI dashboard. There are, however, some common guidelines and limitations that may help guide the approach.
Network Security Groups
When designing NSGs, consider both the scope and the other elements of security in play. If an NVA is filtering requests on port 80, an NSG whitelisting hosts on port 80 for a certain VM may be overkill, or it may provide needed protections from other VMs on the subnet. It may also make more sense to separate VMs into subnets by application or tier and apply NSGs at the subnet level. NSGs are especially useful for allowing or denying traffic between network segments in this manner. It helps to plan security boundaries carefully before attempting to lock things down.
NSGs provide many diagnostic logging and monitoring features, including output to Log Analytics for more advanced OMS and compliance-related integration. They also have key limitations of operating only at Layer 4 (i.e., TCP and UDP), not having application-level insights, and not offering any additional protections for DDoS attacks or unauthorized users connecting from allowed IPs.
Azure Application Gateway With WAF
The Application Gateway with WAF is a newer Azure service that is rapidly improving. The core functionality is a Layer 7 load balancer, but it is commonly used with its WAF SKU to protect web-based apps regardless of other load balancing needs. It is capable of protecting apps running on Azure VMs, dedicated App Service Environments, and in recent months, multi-tenant services like standard App Service Web Apps, integrated with Azure Security Center. Due to its support for SSL termination, end-to-end SSL, TLS 1.2+, prevention mode for common vulnerabilities in the OWASP core rule sets, and diagnostic logging, it’s featured in Microsoft’s Azure Security and Compliance Blueprint reference architectures for PCI DSS 3.2 and FFIEC Financial Services Regulated Workloads (any solution based on the Microsoft blueprints must be certified by an accredited qualified security assessor to meet compliance requirements for PCI DSS or by an accredited auditor to meet FFIEC compliance requirements). NSGs may also be leveraged to provide further restrictions on front-end and back-end traffic, and it can serve both internal and external clients.
Key limitations come in the form of limited protocol support (HTTP, HTTPS, and WebSockets only) and narrowly defined security rule sets (OWASP only). It is not possible for the WAF to mitigate DDoS attacks beyond Azure service protections, although you can add a CDN-based solution in front of the WAF. You also cannot bind a static public IP to the Application Gateway. Finally, the Application Gateway WAF doesn’t filter all inbound and outbound traffic as a traditional firewall, only requests and responses related to application traffic.
Network Virtual Appliances
NVAs are typically deployed from the Azure Marketplace or as ARM solution templates. They are available from multiple well-known vendors like Cisco, Check Point, F5, Fortinet, Palo Alto Networks, and many others. Highly available deployment options are usually available, and flexible architectures enable a diverse range of application requirements. For example, an Active-Passive NVA cluster can be deployed as a shared service in a virtual network, with multiple Layer 3 interfaces providing different security zones for a multi-tiered web app. In this scenario, all inbound and outbound traffic for the various application subnets can be directed through the NVAs for inspection by employing either user-defined routes or a combination of Application Gateways (Standard SKU) and internal load balancers. NVAs can process a variety of protocols, limited only by what’s available within Azure networking, and they can generally offer most services associated with traditional on-premises firewalls from their vendors (Azure-unsupported traffic like broadcast and multicast notwithstanding). The ability to use standard network management tools, firewall rules, etc., is a definite advantage for many organizations, positioning NVAs as a highly capable solution in many scenarios from a technical standpoint.
The disadvantages lie primarily in complexity and cost. Certain features that are expected in on-premises products such as VRRP and active-active configurations will not work due to Azure networking limitations. Adding an NVA to a virtual network can introduce significant routing table changes, additional infrastructure complexity (load balancers, availability sets, etc.), and have unintended side effects on service reachability and hybrid connectivity. These must be carefully planned and considered when dealing with NVAs. Finally, there is the issue of cost. In most cases, the NVA resides on underlying Azure VMs, which incur compute costs of their own on top of the device licensing costs from the vendor.
Deployment Benefits of Native Azure Services
Multiple deployment options are available for NSGs and WAFs as Azure-native services, including the Azure Portal, Azure CLI, Azure PowerShell (see our related blog article on this), ARM templates, and even unofficial or third-party tools such as Azure Building Blocks or Terraform. This makes installing, configuring and managing these resources straightforward, and in many cases, it enables automated deployment through infrastructure-as-code and DevOps.
With NVAs, the picture is not as clear. NVAs are typically available as Azure Marketplace deployments, but some vendors recommend using custom templates for production use, since their Marketplace options are designed more for proof of concept and are missing, for example, high availability required in production. Consequently, NVA deployment will depend highly on the vendor and the client ecosystem due to issues such as this and device-level configuration.
Deciding the Approach
There are many elements involved in securing Azure workloads. The above three serve as a good starting point, but many other pieces such as threat management, CDN, DDoS mitigation, log analytics, etc., should be evaluated before arriving at a final network security posture, especially when more complex requirements or compliance frameworks are involved. Hybrid networking also plays a role for many organizations and offers additional opportunities to optimize for security, performance, and cost.
Have questions about how to approach application and network security in Azure? Credera has worked with clients in ecommerce, healthcare, financial services, and other industries to improve and automate their cloud infrastructure. Contact us at findoutmore@credera.com.
Contact Us
Ready to achieve your vision? We're here to help.
We'd love to start a conversation. Fill out the form and we'll connect you with the right person.
Searching for a new career?
View job openings
