The session focuses on adding security to Azure virtual network resources by using Network Security Groups, or NSGs.
Without filtering, traffic inside a virtual network can flow across subnets and reach network interfaces before being rejected by non-target resources.
NSGs add a filtering layer for network traffic based on source IP, destination IP, source port, destination port, and protocol.
NSG Association Model
NSGs do not attach directly to a virtual network; they are associated with subnets or network interface cards.
A subnet or network interface card can be associated with only one NSG at a time, but one NSG can be associated with multiple subnets or NICs.
The same NSG can be reused across multiple subnets when the rule requirements are identical, while separate NSGs may be used when requirements differ.
To move a resource from one NSG to another, it must first be disassociated from the existing NSG.
Subnet and NIC Filtering
When both subnet-level and NIC-level NSGs are applied, inbound traffic must be allowed by both layers to reach the virtual machine.
For a web server using HTTP on TCP port 80, blocking port 80 at the subnet stops traffic before it reaches the NIC.
If port 80 is allowed at the subnet but blocked at the NIC, traffic enters the subnet but still cannot reach the web server.
NSGs are stateful, so allowing inbound traffic such as port 80 also permits the related response traffic without requiring a separate outbound rule in typical cases.
Creating and Associating NSGs
An NSG can be created in the Azure portal by searching for Network Security Groups, selecting Create, and providing subscription, resource group, name, and region.
Creating the NSG is simple, but planning the rules is more important because incorrect rules can allow or deny backend resource traffic unexpectedly.
A newly created NSG has no custom inbound or outbound rules and is not associated with any subnet or NIC until explicitly linked.
The demo associates DemoNSG1 with DemoVnet Subnet1 and shows that the same NSG can be associated with additional subnets.
The portal shows unavailable NICs or subnets when they are already associated with another NSG.
Default NSG Rules
Every NSG includes default inbound and outbound rules that cannot be deleted or edited.
Default rules use high priority numbers in the 65000 range, such as 65000, 65001, and 65500.
The AllowVnetInBound rule allows traffic within the same virtual network by default.
The Azure load balancer default rule allows load balancer health probe traffic to reach resources.
The default deny-all inbound rule blocks all other inbound traffic that does not match an earlier allow rule.
Custom NSG Rules and Priority
Custom inbound rules can define source, destination, source port range, destination port range, protocol, service, action, priority, name, and description.
Source and destination can be set broadly to Any or restricted by IP address, service tag, or application security group.
Service tags allow rules to reference Azure services such as storage or SQL without manually maintaining service IP addresses.
Selecting a known service such as HTTP or RDP automatically fills in the corresponding protocol and port, such as TCP 80 for HTTP or TCP 3389 for RDP.
Explicit deny rules are often unnecessary because the default deny-all rule already blocks unmatched traffic, though explicit denies can be created when needed.
Custom rule priorities range from 100 to 4096, where smaller numbers have higher priority.
An NSG can have up to 1000 rules per NSG per subscription, even though the priority range contains more possible numbers.
Leaving gaps between priority numbers, such as using 500 and 510, makes it easier to insert future rules between existing ones.
Traffic processing stops at the first matching rule in priority order, so a higher-priority deny for port 80 overrides a lower-priority allow for the same traffic.
If traffic reaches the deny-all rule, it usually means no specific rule was created for that service or traffic type.
Application Security Groups
Application Security Groups, or ASGs, group virtual machines so NSG rules can target logical application groups instead of individual IP addresses.
ASGs are useful when only some virtual machines in a subnet need certain ports, such as allowing HTTP for web servers or HTTPS for a smaller subset.
Using ASGs can reduce administrative effort compared with creating many separate NSGs for each traffic scenario.
After the first resource is associated with an ASG, the ASG becomes bound to that virtual network and cannot be reused for virtual machines in another virtual network.
An ASG can be created in the Azure portal with basic details such as subscription, resource group, name, and region, and it contains no rules by itself.
A virtual machine can be added to an ASG from its networking settings under Application security groups.
NSG rules can then use the ASG as the destination so only resources with that ASG label receive the allowed traffic, such as HTTPS on port 443.
Actiepunten
Check both subnet-level and NIC-level NSGs when troubleshooting blocked traffic.
Create a specific custom NSG rule when valid traffic is hitting the default deny-all rule.
Add descriptions to custom NSG rules so collaborators understand why each rule exists.
Leave priority gaps between custom NSG rules to make future rule insertion easier.
