Service tags, private networking, and reducing public attack surface

Overview

Reducing public attack surface means limiting which Azure resources can be reached from the internet, which ports and protocols are exposed, and which identities and networks can access each service. The goal is not simply to place resources in a virtual network. It is to create explicit, verifiable paths for required traffic and deny unnecessary paths.

Azure networking controls commonly used for this purpose include:

• Virtual networks and subnets.
• Network security groups.
• Service tags.
• Application security groups.
• Private endpoints and Azure Private Link.
• Virtual network service endpoints.
• Public network access controls and service firewalls.
• Virtual network peering, VPN, and ExpressRoute.
• Azure Firewall, network virtual appliances, and user-defined routes.
• Private DNS zones and DNS forwarding.
• Controlled administrative access through Azure Bastion, just-in-time access, or private management paths.

A private endpoint gives a supported Azure service a private IP address in a virtual network. It does not automatically guarantee that the service's public endpoint is disabled. Secure design usually requires validating the private path and then explicitly disabling or restricting public network access.

Service tags are Microsoft-managed groups of IP prefixes for Azure services. They simplify network rules, but a service tag does not identify a particular resource instance or caller identity. A broad tag such as AzureCloud can include addresses used by many Azure customers and is rarely an appropriate trust boundary by itself.

For interviews, candidates should be able to:

• Explain how NSGs and service tags work.
• Distinguish service tags, service endpoints, and private endpoints.
• Describe the DNS requirements of private endpoints.
• Explain why private reachability and public-access restriction are separate controls.
• Design inbound, east-west, and outbound traffic paths.
• Combine network restrictions with identity and application authorization.
• Discuss hub-and-spoke networking, peering, private DNS, egress filtering, and operational trade-offs.

Core Concepts

Start with Required Traffic Flows

A secure network design begins with a flow inventory rather than a list of Azure products.

For each flow, identify:

• Source workload or user group.
• Destination resource.
• Direction.
• Protocol and port.
• DNS name.
• Authentication mechanism.
• Authorization boundary.
• Whether internet transit is acceptable.
• Logging and ownership.

Example:

This approach exposes accidental paths, such as a public backend that allows clients to bypass the gateway or a database public endpoint that remains enabled after private connectivity is added.

Virtual Networks and Subnets

An Azure virtual network provides an isolated IP address space for Azure resources. Subnets divide that space into security and routing boundaries.

Useful subnet design principles include:

• Separate ingress, application, data, management, and private-endpoint roles where their controls differ.
• Reserve address space for growth and managed service requirements.
• Avoid overlapping address ranges with peered or on-premises networks.
• Apply NSGs and route tables deliberately.
• Do not assume subnet separation creates isolation without security rules.

Some Azure services require dedicated subnets or impose subnet-policy requirements. Validate service-specific requirements before assigning address ranges.

Network Security Groups

An NSG filters inbound and outbound traffic for supported subnet and network-interface attachments. Rules specify:

• Priority.
• Direction.
• Source.
• Destination.
• Protocol.
• Source and destination ports.
• Allow or deny action.

Lower priority numbers are evaluated first. Evaluation stops at the first matching rule.

NSGs are stateful. If an outbound connection is allowed, return traffic for that established flow is allowed without a separate inbound rule. Similarly, an allowed inbound flow can send its response without a corresponding outbound response rule.

Default NSG rules include virtual-network and Azure load-balancer allowances, an inbound deny, an outbound internet allowance, and an outbound deny at lower precedence. Custom higher-priority rules can override the defaults.

Important operational behavior:

• NSG changes primarily affect new connections.
• Existing stateful flows can continue until their flow state expires or the connection closes.
• Both subnet and network-interface NSGs can apply, and traffic must be allowed by the effective combination.
• Effective security rules and flow logs are essential for troubleshooting.

Service Tags

A service tag represents Microsoft-managed IP address prefixes for an Azure service or platform function. Microsoft updates the prefixes when the service addresses change.

Service tags can be used in supported:

• NSG source or destination fields.
• Azure Firewall rules.
• User-defined routes for supported scenarios.

Examples include:

• Storage
• Sql
• AzureKeyVault
• AzureMonitor
• AzureLoadBalancer
• AzureFrontDoor.Backend
• ApiManagement

Some tags support regional forms, such as a storage tag scoped to a particular Azure region. Regional scoping should be used when it satisfies the application flow because it is narrower than a cloud-wide tag.

Service tags reduce IP maintenance, but they have important limits:

• They represent service address ranges, not one resource instance.
• They do not authenticate the caller.
• They do not encrypt traffic.
• They do not prove that traffic belongs to the expected subscription or tenant.
• Broad tags can include infrastructure used by unrelated Azure customers.
• Availability, direction, and regional support vary by tag.

Use the narrowest tag that matches the required flow and combine it with identity, resource firewalls, private connectivity, and application authorization.

Why AzureCloud Is Usually Too Broad

The AzureCloud tag represents a broad set of Azure public IP ranges. Allowing it means trusting traffic based on its origin somewhere in Azure, not based on ownership by your organization.

This is risky because an attacker can also operate resources in Azure. Prefer:

• A service-specific tag.
• A regional service tag where available.
• A private endpoint.
• A known application ingress service tag plus an application-specific verification mechanism.
• Explicit organization-controlled egress IPs.

IP origin is one signal, not a complete identity boundary.

Application Security Groups

Application security groups, or ASGs, group virtual machine network interfaces by application role. NSG rules can then refer to logical groups rather than individual IP addresses.

For example:

WebTier ASG -> AppTier ASG : TCP 443
AppTier ASG -> DataTier ASG: TCP 1433
All other east-west traffic: deny

ASGs are useful for scalable VM-based segmentation. They do not replace service tags: an ASG identifies organization-controlled network interfaces, while a service tag represents Azure service IP ranges.

Private Endpoints and Azure Private Link

A private endpoint is a network interface placed in a subnet and assigned a private IP address. That interface maps to a specific supported Azure service resource or subresource through Azure Private Link.

Common examples include private connectivity to:

• Azure Storage.
• Azure SQL Database.
• Key Vault.
• Cosmos DB.
• Container Registry.
• App Service.
• Organization-published Private Link services.

The client connects to the service's normal hostname, but DNS should resolve that hostname to the private endpoint IP from the approved network.

Benefits include:

• Private IP reachability.
• Traffic over the Microsoft backbone.
• Resource-specific approval and connection state.
• Access from connected networks through peering, VPN, or ExpressRoute when routing and DNS are configured.
• Reduced dependency on public IP allowlists.

Private endpoints consume subnet IP addresses and create DNS, routing, ownership, and lifecycle dependencies. They should be planned centrally rather than added without naming and DNS standards.

Private Endpoint DNS

DNS is one of the most common private endpoint failure points. Applications normally keep using the public service hostname. Azure DNS resolution uses a private-link DNS zone to return the private endpoint IP from linked virtual networks.

A common resolution path is:

Application asks for service hostname
-> DNS follows private-link mapping
-> Private DNS zone returns private endpoint IP
-> Client connects over the private network

Design considerations include:

• Link the correct private DNS zone to every virtual network that needs resolution.
• Avoid creating conflicting zones for the same namespace.
• Ensure spoke and on-premises clients can query the authoritative private zone.
• Configure DNS forwarding or Azure DNS Private Resolver for hybrid environments.
• Verify both name resolution and network reachability.
• Understand how multiple private endpoints for the same service namespace affect records.

Testing only by IP can hide a broken production configuration because applications and TLS certificates usually depend on DNS names.

Private Reachability Does Not Automatically Disable Public Access

Creating a private endpoint usually adds a private path. For many Azure services, the public endpoint can remain reachable until public network access or the resource firewall is explicitly changed.

A safe migration sequence is:

1. Create the private endpoint.
2. Configure private DNS.
3. Validate application and administrative connectivity.
4. Validate monitoring, backup, deployment, and disaster-recovery paths.
5. Disable public network access or restrict it to an approved exception.
6. Verify from an untrusted internet location that the public path no longer works.
7. Monitor for attempted public access and private-path failures.

Skipping the final restriction leaves the original public attack surface in place.

Private Endpoints Versus Service Endpoints

Both features help secure access to supported Azure PaaS services, but they use different models.

Service endpoints extend virtual-network identity to a supported Azure service and optimize routing over the Azure backbone. The service is still addressed through its public endpoint. A service firewall rule then allows selected subnets.

Private endpoints are often selected when the requirement is a private IP, hybrid access, stronger resource isolation, or disabling public access. Service endpoints can remain appropriate when their simpler subnet-based model meets the threat model and service capabilities.

Service Endpoint Policies

A service endpoint by itself grants a subnet path to a service category, while resource-side virtual-network rules restrict which resources accept that subnet.

Service endpoint policies can add outbound control by limiting subnet traffic over service endpoints to specified Azure service resources. They help reduce data-exfiltration risk in supported scenarios.

They do not replace identity authorization. The workload still needs permission to access the destination resource.

Virtual Network Peering

Peering connects virtual networks over the Azure backbone. It enables private IP communication subject to NSGs, routes, service behavior, and DNS.

Important characteristics include:

• Address spaces must not overlap.
• Peering is not automatically transitive.
• Hub-to-spoke connectivity does not automatically permit spoke-to-spoke routing.
• Gateway transit and remote gateway settings require deliberate configuration.
• DNS resolution is separate from IP reachability.

Hub-and-spoke topologies centralize shared services such as firewalls, DNS resolvers, VPN or ExpressRoute gateways, and administration. Centralization improves governance but can create bottlenecks or large failure domains if capacity and redundancy are ignored.

VPN and ExpressRoute

Site-to-site VPN and point-to-site VPN provide encrypted connectivity over the internet. ExpressRoute provides private connectivity through a provider.

Neither option automatically grants access to every subnet or private endpoint. The complete path still depends on:

• Advertised and effective routes.
• NSGs and firewalls.
• Private endpoint and resource approval.
• DNS resolution.
• Identity and resource authorization.

A connection reported as up can coexist with application failure caused by DNS, asymmetric routing, or a blocked port.

User-Defined Routes and Central Firewalls

User-defined routes, or UDRs, override or supplement Azure system routes for matching prefixes. They are commonly used to send outbound or east-west traffic through Azure Firewall or a network virtual appliance.

Central inspection can provide:

• Egress allowlisting.
• Threat intelligence.
• Network and application rules.
• Central logs.
• Consistent policy across spokes.

Risks include:

• Asymmetric routing.
• Missing routes for return traffic.
• Appliance throughput bottlenecks.
• Platform-service dependencies being blocked.
• Unexpected interaction with service endpoint routes.
• A centralized outage affecting many workloads.

Routing should be validated through effective routes and real connectivity tests, not inferred only from the route-table definition.

Outbound Access and Egress Control

Reducing public attack surface includes controlling outbound traffic. Unrestricted egress enables command-and-control communication, data exfiltration, dependency drift, and accidental use of unapproved services.

Outbound design options include:

• Azure Firewall or a network virtual appliance.
• NAT Gateway for stable outbound IPs.
• Service tags for approved Azure services.
• Private endpoints for supported PaaS dependencies.
• Firewall application rules for approved FQDNs.
• Explicit deny rules after required dependencies are identified.

NAT Gateway provides scalable source NAT and predictable public IPs, but it does not inspect destinations or content. It can complement a firewall but is not itself an egress security policy.

Outbound dependencies include operating-system updates, package repositories, certificate revocation, identity endpoints, monitoring, DNS, time synchronization, and deployment systems. Deny-by-default egress should be introduced with dependency discovery and monitoring.

Protecting Public Ingress

Some applications must remain public. Reducing attack surface then means exposing only the controlled entry layer:

• Azure Front Door or Application Gateway with WAF.
• API Management for governed APIs.
• Public Load Balancer for required Layer 4 services.

Backends should be private or restrict ingress to the approved proxy path. Additional verification may include:

• Service-specific origin restrictions.
• Managed identity or mutual TLS between proxies and origins.
• Secret origin headers where appropriate and securely managed.
• NSG or resource firewall rules.

Allowing the proxy service tag alone can be insufficient when that tag represents shared service infrastructure. Combine network rules with a mechanism that proves the request traversed the organization's intended frontend.

Administrative Access

Management ports should not be broadly internet-exposed. Safer patterns include:

• Azure Bastion.
• Point-to-site VPN.
• Private jump hosts with controlled access.
• Just-in-time VM access.
• Microsoft Entra authentication and role-based access.
• Privileged access workstations.

Avoid permanent 0.0.0.0/0 rules for SSH, RDP, database administration, or internal dashboards. Time-bound access and auditable identity reduce exposure and improve incident investigation.

Identity Remains Required

Private networking answers, "Can this network path reach the resource?" Identity answers, "Which workload or person is making the request?" Authorization answers, "What may that identity do?"

A workload connected through a private endpoint can still be compromised or overprivileged. Use:

• Managed identities.
• Least-privilege RBAC.
• Database and application permissions.
• Object-level authorization.
• Conditional Access for human users where appropriate.
• Short-lived credentials and secret rotation.

Network controls and identity controls should both fail closed for sensitive resources.

Deployment and Management Paths

Private-only services affect more than runtime traffic. Teams must plan connectivity for:

• CI/CD deployment agents.
• Schema migrations.
• Administrative tools.
• Monitoring and diagnostics.
• Backup and restore.
• Vulnerability scanning.
• Incident response.
• Disaster recovery.

Possible approaches include self-hosted agents in an approved network, managed service private integration, controlled jump paths, or temporary tightly governed exceptions. Do not re-enable broad public access during every deployment.

Monitoring and Validation

Useful evidence includes:

• Effective NSG rules.
• Effective routes.
• Virtual network flow logs.
• Firewall logs.
• Private endpoint connection state.
• DNS query and resolution tests.
• Resource firewall and public-access configuration.
• Azure Policy compliance.
• Public exposure inventories.

Validation should test both positive and negative paths:

• Approved workload can connect.
• Unapproved subnet cannot connect.
• Internet client cannot reach a private resource.
• Backend cannot be reached directly around the gateway.
• DNS resolves privately from every required network.
• Disaster-recovery and administration paths work.

A diagram or desired-state configuration is not proof that a path is secure.

Governance at Scale

At scale, use:

• Infrastructure as code.
• Azure Policy to audit or deny unwanted public access.
• Standard private DNS architecture.
• Naming and subnet allocation conventions.
• Central inventories of public IPs and private endpoints.
• Reusable firewall and NSG modules.
• Ownership and expiration metadata for exceptions.
• Automated exposure and connectivity tests.

Policies should account for services that legitimately require public ingress. A blanket deny without an exception model can cause teams to create unmanaged workarounds.

Common Mistakes

Common mistakes include:

• Creating a private endpoint but leaving public network access enabled.
• Using AzureCloud as if it identified trusted organization traffic.
• Assuming service tags authenticate callers or specific resources.
• Configuring private endpoints without private DNS.
• Testing connectivity by IP instead of the production hostname.
• Forgetting deployment, monitoring, backup, or on-premises paths.
• Assuming peering is transitive.
• Applying broad NSG allows to solve a routing or DNS problem.
• Exposing backend services publicly behind a WAF or gateway.
• Restricting inbound traffic while leaving unrestricted outbound access.
• Treating a virtual network as a complete security boundary.
• Failing to combine network restrictions with least-privilege identity.

Best-Practice Design Checklist

A production design should normally:

• Inventory required inbound, east-west, outbound, and management flows.
• Expose only intended ingress services publicly.
• Use private endpoints for sensitive supported PaaS services where justified.
• Configure and test private DNS before disabling public access.
• Explicitly disable or restrict public network access.
• Use service-specific and regional service tags instead of broad tags.
• Apply least-privilege NSG and firewall rules.
• Control egress and provide stable outbound identity where required.
• Restrict backends from bypassing approved gateways.
• Combine network controls with managed identity and authorization.
• Include CI/CD, monitoring, backup, and recovery paths.
• Enforce standards through infrastructure as code and Azure Policy.
• Test allowed and denied paths continuously.