Understand Network Security Group Association and Rule Evaluation
Network Security Groups (NSGs) act as a virtual firewall that filters traffic for Azure resources using a set of security rules. Each rule uses a five-tuple system—source, source port, destination, destination port, and protocol (TCP or UDP)—to decide whether to allow or deny traffic. Because NSGs are stateful, when a rule permits traffic in one direction, the return traffic is automatically allowed without needing a separate rule.
You can associate an NSG at the subnet level, the network interface (NIC) level, or both, creating layers of security. For inbound traffic, Azure evaluates the subnet NSG first and then the NIC NSG; both must allow the traffic for it to reach the resource. For outbound traffic, the order is reversed: the NIC NSG is processed before the subnet NSG. If a resource has no NSG associated with its subnet or NIC, all traffic is blocked by default when the resource has a public IP.
Every rule has a priority number ranging from 100 to 4096, where lower numbers have higher priority and are processed first. Once traffic matches a rule, Azure stops evaluating any further rules, making priority critical for resolving conflicts. Azure includes several default rules to ensure basic connectivity, including AllowVNetInBound for traffic within the same virtual network, AllowAzureLoadBalancerInBound for health probes, and DenyAllInBound to block other traffic not explicitly allowed.
To manage complex environments, you can use Application Security Groups (ASGs) and Service Tags to reduce the number of rules. ASGs let you group virtual machines by function (for example, "WebServers") so you apply rules to logical groups instead of individual IP addresses. Service Tags represent groups of IP addresses for specific Azure services, such as Storage.EastUS, and update dynamically as the service's IP ranges change.
For centralized management, Security Admin Rules from Azure Virtual Network Manager provide a higher level of control that sits above standard NSG rules. These rules are evaluated before any NSG rules and can be set to "Always Allow" or "Deny" to enforce company-wide policies. This creates a defense-in-depth strategy where central administrators set the baseline security, while individual teams manage application-specific needs through their own NSGs.
Leverage Application Security Groups for Application-Centric Segmentation
Application Security Groups (ASGs) allow you to logically group virtual machines by application workload, enabling application-centric network segmentation. Instead of creating individual NSG rules for each VM or managing lists of IP addresses, you define ASGs that represent roles or tiers—such as web servers, business logic, or databases. This approach simplifies network security policy management and aligns it closely with your application architecture.
You create an ASG using the Azure Portal, PowerShell, or CLI, specifying the resource group and region. After creation, you associate the network interfaces of your VMs with the appropriate ASG. A single network interface can belong to multiple ASGs, allowing flexible grouping based on workload requirements. All network interfaces in an ASG must reside in the same virtual network, ensuring consistent policy enforcement within that boundary.
NSGs act as the enforcement mechanism by filtering inbound and outbound traffic using rules that reference ASGs as the source or destination. For example, you can allow HTTP traffic from the Internet to all VMs in the "asg-web" group, or restrict database access so only VMs in the "asg-logic" group can connect to those in "asg-db". NSG rules are processed in order of priority, and when multiple rules apply, the one with the highest priority (lowest number) takes precedence.
Define and Implement Network Security Group Rules
Network Security Groups (NSGs) are essential for controlling inbound and outbound traffic to Azure resources. They act as a basic, stateful, packet-filtering firewall, allowing you to manage access based on IP address and TCP or UDP protocols. NSGs help ensure that only legitimate traffic is allowed to and from your virtual machines and services.
NSGs include several features that simplify management and reduce configuration errors. Augmented security rules simplify rule definitions, allowing complex rules without needing multiple simple rules. Service tags are Microsoft-created labels representing groups of IP addresses that update dynamically, such as Storage.EastUS for all Azure storage in the East US region. Application security groups allow you to group resources and create rules based on these groups, such as allowing traffic to all systems in the "Webservers" application group.
To configure NSG rules, you must understand priority and default rules. NSG rules are evaluated based on their priority, with lower numbers having higher precedence. Each rule specifies a priority, action (allow or deny), direction (inbound or outbound), protocol (TCP, UDP, or any), and source and destination (IP addresses or service tags). You apply NSGs to subnets or network interfaces; when applied to a subnet, the rules affect all resources within that subnet, and when applied to a network interface, the rules only affect the specific resource connected to that interface.
Evaluate Effective Security Rules in NSGs
Evaluate NSG Rule Precedence and Interaction
Network Security Groups (NSGs) filter network traffic using security rules that either allow or deny communication. Each rule has a Priority number ranging from 100 to 4096, where lower numbers indicate higher precedence. When traffic enters or leaves a resource, Azure evaluates rules in order and stops processing as soon as it finds a matching rule, meaning a rule with priority 100 always overrides a conflicting rule with priority 200.
The interaction between different NSGs depends on the direction of traffic. For Inbound Traffic, Azure evaluates rules at the subnet level first, then at the Network Interface (NIC) level. For Outbound Traffic, the order reverses: NIC rules are processed before subnet rules. Traffic must be explicitly allowed at both levels to successfully reach its destination or exit the network.
Every NSG includes Default Security Rules that provide basic connectivity, such as allowing internal virtual network traffic and outbound internet access. These default rules have the lowest possible priority to ensure any custom rules you create will take precedence. To simplify management, you can use Augmented Security Rules to group multiple IP addresses and ports into a single rule, Service Tags to represent groups of Azure service IP prefixes, and Application Security Groups (ASGs) to filter traffic based on application structure.
For global governance, Security Admin Rules created in Azure Virtual Network Manager (AVNM) take precedence over standard NSG rules and are evaluated first in the hierarchy. If a security admin rule is set to "Deny" or "Always Allow," Azure terminates further evaluation, meaning local NSG rules will not be checked. This ensures high-level security policies cannot be accidentally bypassed by local administrators.
To understand the cumulative impact of multiple NSGs and admin rules, administrators should examine the Effective Security Rules for a specific NIC, which provides a consolidated list of all rules currently applied to the resource. Additionally, IP Flow Verify within Azure Network Watcher can test if a specific packet is allowed or denied, making it essential for troubleshooting complex reachability issues.
Analyze Inbound and Outbound Security Rules
NSGs manage and secure network traffic by containing security rules that control both inbound and outbound communication to and from Azure resources. To create an inbound security rule, navigate to your NSG in the Azure portal and select Inbound security rules, then click + Add to enter the details. Key settings include Source (typically set to Any), Source port ranges (typically * for any), Destination (select IP Addresses), Destination IP addresses/CIDR ranges (specify your virtual network subnet range), Service (select Custom), Destination port ranges (enter 22, 3389 for SSH and RDP access), Protocol (select Any), Action (select Allow), Priority (enter 1000 to ensure the rule is processed before Deny rules), and Name.
After creating the inbound security rule, associate the NSG with the virtual network subnet to apply the traffic rules. This involves selecting Subnets in your NSG, clicking + Associate, choosing your virtual network and subnet, and confirming the association. Outbound security rules control traffic leaving your Azure resources and can be configured to allow or deny traffic based on specific criteria, including Destination (specify target IP addresses or CIDR ranges), Destination port ranges, Protocol (TCP, UDP, or Any), Action (Allow or Deny), and Priority.
Utilize Azure Network Watcher for Security Rule Validation and Troubleshooting
NSG diagnostics within Azure Network Watcher helps administrators understand how traffic moves through a virtual network. A key feature is IP flow verify, which checks if a specific packet is allowed or denied based on security and admin rules. By using a 5-tuple approach—source and destination IP, ports, and protocol—it identifies the exact rule responsible for the traffic decision, making it essential for quickly diagnosing connectivity issues.
To properly evaluate the impact of security configurations, administrators must examine effective security rules, which represent the aggregation of all NSG settings applied at both the subnet and network interface levels. Because rules are processed by priority (lowest number first), understanding this combined list is vital for resolving conflicts. Azure provides a clear view of these rules, allowing you to see which custom or default rules are currently active on a running virtual machine.
NSG flow logs provide visibility by recording all IP traffic flowing through an NSG at Layer 4 of the OSI model. These logs capture the traffic decision (allow or deny) and throughput information when using version 2, with data stored in Azure Storage for auditing, compliance, or security analysis. When troubleshooting, remember that NSGs act as a stateful firewall, though some non-default inbound TCP rules may behave in a stateless manner. To ensure accurate logging, enable NSG flow logs on all critical subnets and verify that the Microsoft.Insights resource provider is registered.
For more intuitive understanding of network data, Traffic Analytics visualizes flow logs within a Log Analytics workspace, helping identify security "hot spots" and misconfigurations. However, NSG flow logs are scheduled for retirement in 2027, so Microsoft recommends migrating to virtual network flow logs to overcome current limitations and ensure long-term support for network monitoring.
Implement Azure Bastion
Azure Bastion is a fully managed platform-as-a-service that provides secure RDP and SSH access to virtual machines directly through the Azure portal. This setup ensures that your target virtual machines do not need public IP addresses, which protects them from internet-based attacks. To begin, you must deploy the service within a virtual network that contains a dedicated subnet named AzureBastionSubnet, which must use a prefix size of at least /26 to ensure there are enough IP addresses to support the host and any future scaling.
Deploying the Bastion host involves a clear sequence of operations to establish a secure boundary. First, you configure the target virtual network with its standard subnets and the specialized Bastion subnet. Next, you must provision a public IP address using the Standard SKU, which the Bastion host uses to receive incoming management traffic on port 443. Finally, you associate the public IP address and the designated subnet when creating the Bastion host resource.
To control traffic moving in and out of the Bastion subnet, you must attach a specialized Network Security Group (NSG). The inbound rules must allow HTTPS traffic over port 443 from the public internet to enable administrator connections. Meanwhile, the outbound rules must permit traffic to reach your target virtual machines on ports 3389 for RDP and 22 for SSH, restricting these outbound rules to the private IP addresses of your target virtual machines to prevent unauthorized network traversal.
Troubleshoot and Optimize Azure Bastion Connectivity
When connection errors occur, administrators should use the Connection Troubleshoot tool within Network Watcher. This utility tests the direct TCP connection between the Bastion host and the target virtual machine to pinpoint where the traffic is being blocked. For example, if a user experiences a black screen upon connecting, the root cause is often client-side firewalls blocking WebSockets or a missing NSG rule. Additionally, virtual machines that rely on Just-In-Time (JIT) VM access require specific role assignments so that the Bastion service can successfully request temporary network openings.
Maintaining reliable access requires strict adherence to NSG rule configurations on the Bastion subnet. For inbound traffic, the NSG must allow port 443 from the GatewayManager service tag and ports 8080 and 5701 for internal data plane communication between host instances. For outbound traffic, the NSG must allow communication to the target VMs on ports 3389 and 22, as well as port 443 to the AzureCloud service tag to send diagnostic logs.
To support high-traffic environments, you can scale the Bastion deployment to handle more concurrent sessions. Utilizing the Standard SKU or higher allows you to configure host scaling, which increases the number of instances up to a maximum of 50. A single instance typically supports up to 20 concurrent RDP sessions or 40 SSH sessions. To leverage this capability, the initial subnet must be sized at /26 or larger.
Authentication issues are often caused by using incorrect formatting or unsupported security keys. When connecting to domain-joined Windows virtual machines, users must input their credentials using the User Principal Name format, such as username@domain.com. For Linux connections, the private SSH keys must use RSA, DSA, or OPENSSH formats. Monitoring who is accessing your workloads is critical by enabling BastionAuditLogs, which records every administrative session. For environments with strict compliance regulations, the Premium SKU offers session recording, which captures all graphical activity during RDP and SSH connections and stores it in an Azure storage account.
Manage Network Security and Access Controls for Azure Bastion
Azure Bastion operates as a fully managed service that protects your workloads by keeping virtual machines entirely isolated from the public internet. By forcing all management traffic through TLS-encrypted sessions, you eliminate the risk of port scanning on your private servers. To further strengthen this boundary, you can integrate Azure Firewall into your virtual network topology to inspect and filter traffic before it reaches Bastion. The NSG on the Bastion subnet must also allow outbound traffic over port 80 to the internet for certificate validation and session management.
Securing access to the Bastion host itself depends on a combination of Microsoft Entra ID and Azure RBAC. Users who need to connect to target virtual machines must be assigned the Reader role on the virtual machine, the network interface card, the virtual network, and the Bastion resource itself. To enforce the principle of least privilege, you can implement Privileged Identity Management (PIM) to grant these administrative roles on a temporary, just-in-time basis. Additionally, SSH keys should be managed securely within Azure Key Vault with access permissions restricted to simple retrieval operations.
To optimize costs and streamline operations in large environments, you can deploy a single Bastion host in a hub virtual network and connect to virtual machines residing in peered spoke virtual networks. For environments demanding maximum isolation, the Premium SKU supports a private-only deployment that completely eliminates the public IP address, allowing secure connections exclusively through private endpoints. To guarantee high availability, you can deploy Bastion across multiple availability zones.
Continuous monitoring ensures that your remote access methods remain compliant with corporate security policies. You should enable NSG flow logs along with Azure Monitor, Traffic Analytics, and Microsoft Defender for Cloud to detect anomalous traffic patterns and security threats. Session recordings generated by Premium SKU deployments must be stored in secure Azure storage accounts governed by strict retention and access lifecycle policies.
Implement Service Endpoints for Secure Access
Virtual Network service endpoints provide a secure way for resources in your virtual network to connect directly to Azure platform services. When you enable a service endpoint for a subnet, traffic from that subnet to the supported Azure service flows over the Microsoft Azure backbone network, keeping the traffic off the public internet and enhancing security. A key benefit is that enabling a service endpoint extends your virtual network's identity to the Azure service, allowing you to configure the service to only accept traffic from your specific subnets, effectively removing its public internet exposure.
Service endpoints are widely available for many core Azure services including Azure Storage, Azure SQL Database, Azure Cosmos DB, Azure Key Vault, Azure Service Bus, and Azure App Service. While Azure Private Link is recommended for the most private access, service endpoints are a simpler, no-cost option to secure service access at the network level.
Analyze the Operational Mechanics and Supported Services of Azure Service Endpoints
When you enable a service endpoint for a subnet, the fundamental routing for traffic to that Azure service changes, shifting from going over the public internet to traveling exclusively over the Azure backbone. A critical operational effect is that the source IP address seen by the Azure service changes from a public IP address to the private IP address of the virtual machine or instance inside your virtual network. This private IP sourcing is what allows you to create virtual network firewall rules on the service itself.
You configure service endpoints at the subnet level, not on individual virtual machines. Once enabled for a subnet, all resources in that subnet can use the endpoint to reach the service. It's important to understand that DNS resolution for the service still returns its public IP address; the routing change happens at the network layer. To control this traffic, you use Network Security Groups (NSGs) on the subnet, and you can simplify NSG rule creation by using Service Tags which represent the IP address groups for entire Azure services.
Service endpoints are enabled by registering specific Resource Providers for your subscription. Major supported services include Azure Storage (via Microsoft.Storage), Azure SQL Database (Microsoft.Sql), Azure Key Vault (Microsoft.KeyVault), and Azure Cosmos DB (Microsoft.AzureCosmosDB). A key benefit is optimal routing, which prevents service traffic from being forced through an on-premises network (forced tunneling), thus improving performance. However, for Azure SQL, the virtual network and the database must be in the same region, and service endpoints do not natively provide private connectivity from on-premises networks without additional firewall configuration.
Differentiate Service Endpoints from Private Endpoints and Evaluate Advanced Security Implications
Azure Service Endpoints and Azure Private Endpoints solve similar problems but in fundamentally different ways. A service endpoint secures access at the service level (e.g., all Azure Storage accounts), routing traffic from your subnet over the Azure backbone but the service retains its public endpoint. A private endpoint, powered by Azure Private Link, provides connectivity at the individual resource level (e.g., one specific storage account), creating a network interface with a private IP address inside your virtual network that maps directly to that single resource instance.
StudyCerts
StudyCerts