Assess Azure network design, NSGs, Firewall, private endpoints, WAF, DDoS, Bastion, JIT access, DNS, egress control, traffic paths, and flow monitoring.
Paths, boundaries, and evidence
Azure network security is not the number of firewalls in a diagram. It is the controlled set of paths that users, administrators, applications, services, vendors, and attackers can take. A strong review maps ingress, egress, east-west, hybrid, platform-service, management, DNS, and recovery traffic; identifies where trust changes; verifies effective routing and filtering; and confirms that important events are visible to responders.
This guide covers virtual networks, subnets, peering, network security groups, route tables, Azure Firewall, web application firewalls, DDoS protection, Azure Front Door, Application Gateway, load balancers, private endpoints, service endpoints, Bastion, just-in-time access, VPN and ExpressRoute, DNS, egress, Network Watcher, and flow evidence.
Defense-in-depth topology
Inventory first
| Component | What to record | Security question | Evidence |
|---|---|---|---|
| Virtual networks and subnets | Address space, region, owner, workload, peering, delegations, service endpoints, NSGs | Are trust zones explicit and non-overlapping? | Resource Graph export, topology, effective rules |
| Public IP addresses | Address, SKU, association, DNS, owner, purpose, protection, last use | Is every public endpoint required and protected? | Public IP inventory, listeners, flow and application logs |
| Load balancing and edge | Front Door, Application Gateway, Load Balancer, Traffic Manager, listeners, backends, TLS, WAF | Where is traffic terminated, filtered, and forwarded? | Configuration export, WAF policy, health and access logs |
| Network security groups | Rules, priority, source, destination, port, protocol, service tag, application security group | Do rules permit only expected traffic at the right scope? | NSG export, effective security rules, flow data |
| Routes and firewalls | User-defined routes, BGP, next hops, firewall policies, rule collections, threat intelligence, DNS proxy | Can traffic bypass required inspection or leave by an uncontrolled path? | Effective routes, policy export, firewall logs, reachability test |
| Private endpoints | Target service, subnet, approval, private DNS, public network state, consumers | Does the intended name resolve privately from every authorized network? | Private endpoint and DNS records, connection test |
| Hybrid links | VPN, ExpressRoute, gateways, circuits, peers, routes, encryption, failover | What on-premises or partner networks become trusted? | Gateway configuration, route tables, monitoring, provider records |
| Administrative access | Bastion, JIT, VPN, privileged workstations, SSH/RDP paths, serial console | Can management ports be reached from the internet or normal user networks? | NSG rules, JIT policy, Bastion configuration, sign-in and activity logs |
| DNS | Private zones, resolvers, forwarders, custom DNS, links, records, logging | Can name resolution send traffic to the wrong or public endpoint? | Zone and link export, resolver rules, query tests |
| Egress | NAT Gateway, firewall, public IP, service tags, FQDN rules, proxy, direct internet paths | Can compromised workloads exfiltrate or download tools without control? | Effective routes, firewall policy, DNS and flow logs |
Segmentation
Separate internet-facing services, application tiers, data stores, management systems, identity dependencies, security tooling, development, testing, production, regulated workloads, and recovery services when the risk justifies it. Segmentation can use subscriptions, virtual networks, subnets, NSGs, application security groups, firewalls, route controls, and private endpoints. No single mechanism defines the entire boundary.
Network security groups are stateful filters. Review inbound and outbound rules, priorities, broad service tags, `Any` sources or destinations, port ranges, temporary rules, and associations. Confirm effective security rules on representative network interfaces because subnet and NIC rules combine. Remove stale rules only after owners and dependency evidence are established.
Peering creates connectivity, not transitive routing by default, but gateway transit, forwarded traffic, route servers, virtual WAN, network appliances, and custom routes can change the path. Document whether spokes may communicate, whether they must traverse a firewall, and how route propagation is controlled.
Internet-facing applications
Determine whether platform-level protections are sufficient or whether Azure DDoS Network Protection, Azure DDoS IP Protection, Front Door, or another service is justified. Identify protected public IPs, telemetry, alerts, response contacts, cost exposure, and runbooks. DDoS protection does not replace application rate control or resilient architecture.
Review managed and custom rules, prevention or detection mode, exclusions, request-size limits, rate controls, bot protection where available, policy association, rule updates, TLS, backend health, logging, tuning, and change ownership. Broad exclusions can neutralize a policy while the dashboard still appears enabled.
Restrict backends so they are reached through the approved edge service. Review direct public endpoints, service tags, private links, access restrictions, host headers, certificates, health probes, and DNS. Test whether bypassing the WAF reaches the same application.
Private PaaS access
Private Link creates a private IP path to a service, but every service subresource may require its own endpoint and DNS record. Storage accounts, for example, have separate service endpoints such as blob, file, queue, and table. Test resolution and connection from each intended network, from on-premises if applicable, and from an unauthorized source. Confirm the public endpoint behavior rather than assuming private endpoint creation disabled it.
Administrative access
Do not expose SSH or RDP broadly to the internet. Use Azure Bastion, a controlled VPN, privileged access workstation, just-in-time VM access, or another managed path appropriate to the environment. Restrict source networks, authenticate strongly, minimize local accounts, protect keys, monitor sessions and changes, and ensure that emergency procedures remain available during a network incident.
Query NSGs, public IP associations, load balancer NAT rules, firewall DNAT, VM network interfaces, Kubernetes endpoints, database listeners, and third-party appliances. Include high and alternate ports, not only 22 and 3389.
Identify the source, destination, authentication, business purpose, frequency, approving owner, monitoring, and alternative. Attempt a safe reachability test from the intended and an unauthorized source.
Deploy Bastion or JIT where appropriate, use Entra-based VM login when supported, restrict roles, remove direct public exposure, control key and local-account lifecycle, and document the operator procedure.
Confirm the approved path works, the old path is blocked, logs identify the user and target, alerts cover unexpected rule or public-IP changes, and emergency access is tested.
Central inspection and egress
Azure Firewall can centralize network and application rules, threat-intelligence filtering, DNAT, TLS inspection in selected Premium scenarios, IDPS, and logging. A network virtual appliance may provide similar functions. The control is effective only if routes send traffic through it, policies are specific, management is restricted, high availability is understood, logs are reviewed, and a bypass path does not exist.
Examine firewall policy hierarchy, rule collection group priority, network and application rules, FQDN tags, service tags, wildcard domains, threat-intelligence mode, IDPS mode and overrides, TLS certificates, DNS proxy, forced tunneling, SNAT behavior, and logging. For egress, identify workloads with direct public IPs, default outbound access, NAT Gateway, load balancer outbound rules, or service-managed egress. A future platform change can remove or alter default outbound behavior, so make production egress intentional.
Restrictive egress can disrupt package repositories, certificate validation, identity, monitoring, backups, and vendor services. Collect actual dependencies, use documented service tags and FQDNs where appropriate, pilot the policy, monitor denials, and retain an emergency change path. Do not use an unrestricted outbound rule permanently because the dependency inventory is incomplete.
Monitoring and validation
Use topology, connection troubleshoot, IP flow verify, next hop, effective security rules, packet capture, VPN troubleshoot, and connection monitor as appropriate. Authorize packet capture and protect the resulting data.
Use supported virtual network flow logs or current Azure flow capabilities, firewall logs, NSG diagnostics, load balancer metrics, and application access logs. Plan for product transitions and retention rather than depending on deprecated formats.
Alert on public IP creation, NSG or route changes, firewall policy changes, WAF disablement, new peering, gateway changes, private endpoint approval, DNS changes, and diagnostic-setting removal.
For each critical path, record the source, destination, protocol, DNS result, route, filter decision, application response, log entries, and alert. Retest after remediation or architecture change.
Connect network telemetry to the Azure logging and Microsoft Sentinel design. For broader network assessment services, see Network and Data Security.
From finding to implementation
OC Security Audit can identify and validate exposure, segmentation gaps, control weaknesses, evidence limitations, and risk. When remediation requires architecture changes, firewall deployment, VPN, DNS, routing, endpoint, server, or ongoing network operations, the IT Perfection network security resource center can support implementation planning.
Preserve the original path test, before-and-after rules, routes, DNS results, relevant logs, change approval, rollback record, and a repeat connection test from authorized and unauthorized sources.
Official guidance
Microsoft updates Azure capabilities, portal locations, licensing, defaults, feature status, and prerequisites. Confirm the current product documentation before a production change.
Practical questions
No. Use them when the security and architecture benefit justifies the complexity. Public endpoints can be acceptable when deliberately restricted and protected. Validate DNS, routing, identity, logging, and application dependencies.
No. NSGs provide distributed stateful filtering at subnets and interfaces. Azure Firewall provides centralized policy and inspection features. Use each according to the required control and architecture.
Avoid broad internet exposure. Use Bastion, JIT, a controlled VPN, privileged workstations, Entra-based login where supported, narrow roles, strong authentication, logging, and tested emergency access.
Collect relevant firewall, WAF, gateway, edge, DNS, connection, flow, load-balancer, activity, and application logs. Preserve the source, destination, protocol, decision, rule, identity where available, and time.
Test representative allowed and denied paths, inspect effective routes and security rules, validate DNS, review firewall policy, confirm application behavior, and locate the corresponding logs.
About the author
Reviewed for practical Azure security, evidence, and remediation guidance by Ali Hassani, CISO, with 25+ years of IT and cybersecurity experience.
This material is for initial guidance only and does not replace a professional cybersecurity audit, compliance assessment, penetration test, or legal/compliance review. Validate configuration, licensing, service availability, architecture, and business impact before production changes.
This website uses essential cookies for security and operation. Optional analytics and advertising cookies help measure site use and outreach. Choose Allow or Deny. You can change your choice at any time.