Chapter 6

Secure access, security & load balancing

Your two web servers are running but nobody can reach them. In this chapter you open exactly one port with an NSG, get admin access through Bastion without public IPs, and put a load balancer in front of them. Then you step back and look at security as a whole: Zero Trust, defense in depth, encryption and Key Vault, and Microsoft Defender for Cloud.

Network security groups

A network security group (NSG) is a stateful packet filter: a list of allow and deny rules for traffic to and from a subnet or a NIC. "Stateful" means that if a request is allowed in, the reply is automatically allowed out; you don't need a rule for the return traffic.

Rule properties

• Priority: 100 to 4096. Lower numbers are processed first, and processing stops at the first match.
• Source and destination: an IP address or CIDR range, a service tag, or an application security group.
• Port ranges and protocol (TCP, UDP, ICMP or Any).
• Action: Allow or Deny. Direction: Inbound or Outbound.

Default rules

Every NSG has six default rules that you can't delete, only override with a lower priority number:

So by default: traffic inside the VNet (including peered VNets and on-premises via a gateway) is allowed, internet inbound is blocked, and internet outbound is allowed.

Service tags

A service tag is a Microsoft-maintained group of IP ranges, so you don't have to track IPs yourself. The ones you'll meet most:

• Internet: everything outside the VNet address space and Azure's public ranges.
• VirtualNetwork: the VNet, peered VNets, connected on-premises ranges.
• AzureLoadBalancer: the source of load balancer health probes (168.63.129.16).
• Storage, Sql, AzureMonitor, AzureCloud…, optionally per region, like Storage.WestEurope.

Subnet NSG, NIC NSG, or both

You can associate an NSG with a subnet, a NIC, or both. When both exist, traffic must be allowed by both:

An NSG must be in the same region as the subnet or NIC, and one NSG can be associated with many subnets and NICs.

Application security groups

An application security group (ASG) is a label you put on NICs, like asg-web or asg-db. You then write NSG rules with ASGs as source or destination: "allow TCP 1433 from asg-web to asg-db". When you add a new web server, you only add its NIC to asg-web; no rule changes.

Limits: all NICs in an ASG must be in the same VNet, and if a rule uses two ASGs, both must be in the same VNet.

Evaluating effective rules

The exam loves "here are three NSG rules, is this traffic allowed?" questions. Work like ARM does:

1. Pick the right direction and the right NSG(s) (subnet, NIC, or both).
2. Go through the rules from the lowest priority number up. The first rule that matches source, destination, port and protocol decides.
3. If nothing matches, the default rules decide.

In Azure you can check this with NIC → Effective security rules (the merged view of subnet and NIC NSGs) and Network Watcher → IP flow verify (tests one packet and names the rule that allowed or denied it).

Azure Bastion

Azure Bastion gives you RDP and SSH in the browser (over HTTPS 443) to VMs that have no public IP. You don't open 22 or 3389 to the internet, and you don't need a jump box.

The usual design is one Bastion in the hub (Basic or higher) that serves all peered spokes. If you put an NSG on AzureBastionSubnet, it needs specific rules (inbound 443 from Internet and GatewayManager, outbound 22/3389 to VirtualNetwork, and a few more), so most people don't.

Azure Load Balancer

Azure Load Balancer distributes TCP and UDP traffic (layer 4) across healthy backend instances. It doesn't look at HTTP, so no URL routing and no TLS termination; that's what Application Gateway is for.

• Public load balancer: has a public IP frontend; balances internet traffic to VMs, and provides outbound internet access through outbound rules.
• Internal load balancer: has a private IP frontend in a subnet; balances traffic inside the VNet, for example from a web tier to an app tier, or from on-premises.

Use the Standard SKU. Basic was retired in September 2025. Standard is zone-redundant (or zonal), supports up to 1,000 backend instances, has an SLA, and is closed by default: an NSG must allow the traffic to the backends.

The parts of a load balancer

• Frontend IP configuration: the public or private IP clients connect to. One LB can have several.
• Backend pool: the VMs or scale set instances, by NIC or by IP address. All backends must be in the same VNet.
• Health probe: TCP, HTTP or HTTPS check on each backend. HTTP/HTTPS probes need a 200 OK. An instance that fails is taken out of rotation; existing connections continue.
• Load-balancing rule: maps a frontend IP and port to the backend pool and port, using a probe.
• Inbound NAT rule: port forwarding to one specific backend, e.g. frontend port 50001 → vm-web1 port 22.
• Outbound rule: lets backends reach the internet via the frontend's public IP (SNAT), with explicit port allocation. When you use one, set the LB rule to not use implicit outbound SNAT.

Distribution and special options

• Session persistence: None (default; 5-tuple hash: source IP, source port, destination IP, destination port, protocol), Client IP (2-tuple: same client goes to the same backend), Client IP and protocol (3-tuple).
• HA ports (internal Standard LB only): one rule for all ports and protocols. Used to load-balance NVAs/firewalls.
• Floating IP (direct server return): needed for SQL Server Always On listeners.
• Cross-region load balancer: a global frontend in front of regional Standard LBs.

Which load balancing service?

Troubleshooting a load balancer

When the frontend doesn't answer or only some backends get traffic, check in this order:

1. Health probe status (LB → Monitoring → Metrics → Health Probe Status, or Insights). Are the backends healthy?
2. Is the app listening on the probe port and returning 200 on the probe path?
3. Does an NSG block the probe? The default rule AllowAzureLoadBalancerInBound allows it, but a custom Deny all with a lower number would block it.
4. Does an NSG allow the client traffic? Standard LB needs an explicit allow.
5. Are you testing from a backend VM to its own LB frontend? That doesn't work for an internal LB (the flow hairpins back to the same VM and fails).

Zero Trust

The old security model was a castle with a moat: everything inside the corporate network was trusted, everything outside wasn't. With cloud apps, home working and personal devices, there is no clear "inside" any more. Zero Trust replaces the moat with one rule: never trust, always verify. Every request is checked as if it came from an open network.

Zero Trust has three principles. Each one maps to things you already use in this guide:

Microsoft applies these principles across six areas, often called the pillars of Zero Trust: identities, endpoints (devices), applications, data, infrastructure and network, with visibility and automation across all of them.

Defense in depth

Defense in depth means stacking several layers of protection, so that if one layer fails, the next one still stops or slows down the attacker. No single control is trusted to do the whole job.

Two perimeter services you haven't met yet in this guide:

• Azure DDoS Protection: every Azure public IP gets basic infrastructure protection for free. The paid tiers (DDoS Network Protection per VNet, or DDoS IP Protection per public IP) add tuning to your traffic, attack reports, and cost protection during an attack.
• Azure Firewall: a managed, stateful firewall as a service, usually placed in the hub VNet. Spokes send their traffic to it with a UDR (chapter 3). It filters by FQDN and application rules, adds threat intelligence, and in the Premium SKU does TLS inspection and IDPS. NSGs filter within a VNet; Azure Firewall controls traffic between networks and to the internet.

Encryption and Azure Key Vault

Data needs protecting in three states:

• At rest: on disk. Azure encrypts storage, managed disks and databases by default with platform-managed keys (chapters 5 and 7). You can switch to customer-managed keys if you must control or revoke the key.
• In transit: on the network. Use TLS 1.2 or later (enforce a minimum TLS version on storage and App Service), "secure transfer required" on storage, IPsec for VPNs. Traffic between Azure datacenters is also encrypted at the link layer by Microsoft.
• In use: in memory while being processed. Confidential computing (confidential VMs, chapter 5's security type) keeps data encrypted inside a hardware-based trusted execution environment.

Azure Key Vault

Key Vault is the central, secure store for three kinds of objects:

• Secrets: passwords, connection strings, API keys.
• Keys: cryptographic keys for encryption and signing, e.g. the customer-managed keys for storage and disks.
• Certificates: TLS certificates, with automatic renewal from integrated CAs.

Things the exam likes about Key Vault:

• Two permission models. Azure RBAC (recommended, default for new vaults) uses data roles such as Key Vault Secrets User (read secrets), Key Vault Secrets Officer, Key Vault Crypto Officer and Key Vault Administrator. The legacy access policies model sets permissions per vault.
• Management plane vs data plane, as with storage (chapter 2): Owner or Contributor on a vault can't read its secrets in the RBAC model. They need a data role.
• Soft delete is always on: a deleted vault or secret can be recovered for 7–90 days (default 90), and its name stays reserved until it's purged. Purge protection blocks even a purge until the retention ends; it's required for customer-managed keys and can't be turned off once on.
• Apps read secrets with a managed identity, so no credential is stored in code. App Service and Functions can use Key Vault references in app settings.
• Like storage, a vault has a firewall and supports private endpoints.

Microsoft Defender for Cloud

Microsoft Defender for Cloud is Azure's security posture and threat protection service. It covers Azure, AWS and Google Cloud (through connectors), and on-premises servers (through Azure Arc). It does two jobs:

• Cloud security posture management (CSPM): finds misconfigurations before an attacker does.
• Cloud workload protection (CWP): detects attacks on running workloads and raises security alerts.

The secure score is a percentage: the more recommendations you fix, the higher it goes. Recommendations are grouped into security controls (like "Enable MFA" or "Restrict unauthorized network access"), and you only get a control's points when all its affected resources are fixed. Many recommendations have a Fix button or can be enforced with Azure Policy, which is what Defender for Cloud uses behind the scenes.

Just-in-time (JIT) VM access, mentioned in chapter 5, is part of Defender for Servers Plan 2: management ports stay closed in the NSG and are opened only for an approved IP, for a limited time, when someone requests access.

Self-check

You open port 80 to the web servers only, put them behind lbe-web with the public IP from chapter 3, give them outbound internet through the load balancer, log in with Bastion, and break and fix the load balancer.

The variables from chapter 0 ($RG, $LOC, $LOC2, $INIT, $ST, $ACR, $MYIP) load automatically in every terminal; if they don't, run . ~/az104.env. Any other variable a task needs is set at the top of that task's Azure CLI solution, so every solution works on its own in a fresh terminal.

Start the VMs first:

az vm start -g $RG -n vm-web1 --no-wait; az vm start -g $RG -n vm-web2 --no-wait

1. Task

   Label the web servers

   Create an application security group asg-web and put the network interfaces of both web VMs in it.

   Done when

   • Each VM's Networking → Application security groups tab shows asg-web.
   Solution · Portal

   1. Create a resource → Application security group: name asg-web, your region.
   2. vm-web1 → Networking → Network settings (or Application security groups) → Add application security groups → asg-web. Repeat for vm-web2.
   Solution · Azure CLI

   az network asg create -g $RG -n asg-web -l $LOC
   for VM in vm-web1 vm-web2; do
     NICID=$(az vm show -g $RG -n $VM --query "networkProfile.networkInterfaces[0].id" -o tsv)
     NICNAME=$(basename $NICID)
     IPCFG=$(az network nic show --ids $NICID --query "ipConfigurations[0].name" -o tsv)
     az network nic ip-config update -g $RG --nic-name $NICNAME -n $IPCFG --application-security-groups asg-web
   done

2. Task

   Allow HTTP to the web servers only

   Use nsg-web (created with Bicep in chapter 4) to allow TCP 80 from the internet to members of asg-web, and protect the whole snet-web subnet with it. Don't open SSH.

   Done when

   • nsg-web is associated with snet-web and has one custom inbound rule.
   • The effective security rules of vm-web1's NIC show your rule above the defaults.
   Hint

   Source: service tag Internet. Destination: Application security group. Priority: something low like 100.

   Solution · Portal

   1. nsg-web → Settings → Inbound security rules → Add: Source Service Tag Internet, source ports *, Destination Application security group asg-web, service HTTP / port 80, TCP, Allow, priority 100, name allow-http-internet.
   2. Settings → Subnets → Associate: vnet-spoke / snet-web.
   3. vm-web1 → Networking → NIC → Help → Effective security rules.
   Solution · Azure CLI

   az network nsg rule create -g $RG --nsg-name nsg-web -n allow-http-internet --priority 100 \
     --direction Inbound --access Allow --protocol Tcp \
     --source-address-prefixes Internet --source-port-ranges '*' \
     --destination-asgs asg-web --destination-port-ranges 80
   az network vnet subnet update -g $RG --vnet-name vnet-spoke -n snet-web --network-security-group nsg-web
   
   NIC=$(az vm show -g $RG -n vm-web1 --query "networkProfile.networkInterfaces[0].id" -o tsv)
   az network nic list-effective-nsg --ids $NIC --query "value[0].effectiveSecurityRules[].{name:name, prio:priority, access:access, dir:direction}" -o table

3. Task

   Build the public load balancer

   Create a Standard public load balancer lbe-web that:

   • uses the existing public IP pip-lbe-web as frontend (fe-web);
   • has both web VMs in backend pool be-web;
   • checks health with an HTTP probe on port 80, path / (hp-http);
   • forwards TCP 80 to port 80 on the backends (lbr-http);
   • gives the backends outbound internet through an outbound rule (obr-web) instead of implicit SNAT.
   Done when

   • http://<pip-lbe-web address> in your browser shows "Hello from vm-web1" or "vm-web2". Refresh a few times, or use curl repeatedly, to see both.
   • If you did the optional DNS task in chapter 3: http://web.lab.yourdomain.com works too.
   Hint

   A browser often reuses its connection and keeps hitting the same backend. for i in $(seq 6); do curl -s http://IP; done opens a new connection each time.

   Solution · Portal

   1. Create a resource → Load balancer: name lbe-web, SKU Standard, type Public, tier Regional.
   2. Frontend IP configuration → Add: name fe-web, public IP use existing pip-lbe-web.
   3. Backend pools → Add: be-web, VNet vnet-spoke, configuration NIC, add both VMs.
   4. Inbound rules → Add a load balancing rule: lbr-http, frontend fe-web, pool be-web, TCP, port 80, backend port 80, Create new health probe hp-http (HTTP, port 80, path /), session persistence None, Outbound SNAT: (Recommended) Use outbound rules….
   5. Outbound rules → Add: obr-web, frontend fe-web, protocol All, pool be-web, port allocation default.
   6. Review + create, wait a minute, then test.
   Solution · Azure CLI

   az network lb create -g $RG -n lbe-web -l $LOC --sku Standard \
     --frontend-ip-name fe-web --public-ip-address pip-lbe-web --backend-pool-name be-web
   az network lb probe create -g $RG --lb-name lbe-web -n hp-http --protocol Http --port 80 --path /
   az network lb rule create -g $RG --lb-name lbe-web -n lbr-http --protocol Tcp \
     --frontend-port 80 --backend-port 80 --frontend-ip-name fe-web --backend-pool-name be-web \
     --probe-name hp-http --disable-outbound-snat true
   az network lb outbound-rule create -g $RG --lb-name lbe-web -n obr-web --protocol All \
     --frontend-ip-configs fe-web --address-pool be-web
   
   for VM in vm-web1 vm-web2; do
     NICNAME=$(basename $(az vm show -g $RG -n $VM --query "networkProfile.networkInterfaces[0].id" -o tsv))
     IPCFG=$(az network nic show -g $RG -n $NICNAME --query "ipConfigurations[0].name" -o tsv)
     az network nic ip-config address-pool add -g $RG --nic-name $NICNAME --ip-config-name $IPCFG \
       --lb-name lbe-web --address-pool be-web
   done
   
   PIP=$(az network public-ip show -g $RG -n pip-lbe-web --query ipAddress -o tsv)
   for i in $(seq 6); do curl -s http://$PIP; done

4. Task

   Prove where outbound traffic comes from

   Find out which public IP address vm-web1 uses when it browses the internet. Explain why.

   Done when

   • The address you see is the address of pip-lbe-web.
   Solution · Azure CLI

   az vm run-command invoke -g $RG -n vm-web1 --command-id RunShellScript \
     --scripts "curl -s https://api.ipify.org" --query "value[0].message" -o tsv

   The outbound rule is an explicit outbound method, so it takes precedence over default outbound access. From now on the VMs would still have internet even in a private subnet.

5. Task

   Log in with Bastion

   Open an SSH session in your browser to vm-web1 using Azure Bastion, with the free Developer SKU. The VM must keep having no public IP.

   Done when

   • You're at a azureuser@vm-web1 prompt in a browser tab.
   • You can explain why Developer can't reach a VM in vnet-hub.
   Solution · Portal

   1. vm-web1 → Connect → Connect via Bastion → Deploy Bastion Developer (it attaches to vnet-spoke; takes a few minutes).
   2. Enter azureuser and your password (or private key) → Connect.

   Developer works for one VNet only, without peering. A hub VM would need Bastion Basic or higher.

   If Developer isn't offered in your region: add subnet AzureBastionSubnet 10.20.254.0/26 to vnet-spoke and deploy Basic. It costs about €0.20/hour, so delete it after this chapter.

6. Task

   Break the load balancer, then fix it

   In your Bastion session, stop nginx on vm-web1. Then find out, from the load balancer, what it thinks about each backend, and check what clients now get. Start nginx again afterwards.

   Done when

   • All curl requests return "Hello from vm-web2" while nginx is stopped.
   • You found the probe status in the load balancer's metrics or Insights.
   • Both backends serve again.
   Solution · Portal

   1. In Bastion: sudo systemctl stop nginx.
   2. lbe-web → Monitoring → Metrics → metric Health Probe Status, Apply splitting by Backend IP Address: 10.20.1.4 drops to 0. (Or Monitoring → Insights.)
   3. From your Linux VM, call the public IP of pip-lbe-web (on its Overview) six times: for i in $(seq 6); do curl -s http://<public-ip>; done.
   4. In Bastion: sudo systemctl start nginx.
   Solution · Azure CLI

   PIP=$(az network public-ip show -g $RG -n pip-lbe-web --query ipAddress -o tsv)
   az vm run-command invoke -g $RG -n vm-web1 --command-id RunShellScript --scripts "systemctl stop nginx"
   sleep 30; for i in $(seq 6); do curl -s http://$PIP; done
   az vm run-command invoke -g $RG -n vm-web1 --command-id RunShellScript --scripts "systemctl start nginx"

7. Task

   Prove that SSH from the internet is blocked

   Without trying to connect, find out whether an SSH packet (TCP 22) from internet address 198.51.100.10 to vm-web1 would be allowed, and which rule decides.

   Done when

   • You have the answer Deny and the rule name DenyAllInBound.
   Hint

   Network Watcher has a tool that tests exactly one packet.

   Solution · Portal

   Network Watcher → Network diagnostic tools → IP flow verify: VM vm-web1, protocol TCP, direction Inbound, local port 22, remote IP 198.51.100.10, remote port 60000 → Access denied, rule DenyAllInBound. Try again with port 80: allowed by allow-http-internet.

   Solution · Azure CLI

   IP1=$(az vm show -g $RG -n vm-web1 -d --query privateIps -o tsv)
   az network watcher test-ip-flow -g $RG --vm vm-web1 --direction Inbound --protocol TCP \
     --local $IP1:22 --remote 198.51.100.10:60000
   az network watcher test-ip-flow -g $RG --vm vm-web1 --direction Inbound --protocol TCP \
     --local $IP1:80 --remote 198.51.100.10:60000

8. Task

   Store a secret, the least-privilege way

   Create a key vault kv-az104-xx01 in rg-az104-lab that uses the Azure RBAC permission model and keeps deleted items for only 7 days. Then store a secret demo-secret in it and read it back.

   Before you give yourself any extra role, try to create the secret first, and note the error.

   Done when

   • Your first attempt failed with Forbidden, although you're Owner of the subscription. You can explain why.
   • After a role assignment on the vault only, you can read the secret's value from your Linux VM.
   Hint

   Vault names are global, 3–24 characters. If yours is taken, add a digit. The role you need to write secrets is Key Vault Secrets Officer; to only read them, Key Vault Secrets User. New role assignments can take a minute to work.

   Solution · Portal

   1. Create a resource → Key Vault: RG rg-az104-lab, name kv-az104-xx01, your region, tier Standard, days to retain deleted vaults: 7, purge protection Disabled. Tab Access configuration: Azure role-based access control. Create.
   2. Vault → Objects → Secrets → Generate/Import: the portal says you're unauthorized to view or create secrets.
   3. Vault → Access control (IAM) → Add role assignment → Key Vault Secrets Officer → your own account.
   4. Back in Secrets → Generate/Import: name demo-secret, any value. Open it and Show Secret Value.
   Solution · Azure CLI

   KV=kv-az104-${INIT}01
   az keyvault create -g $RG -n $KV -l $LOC --enable-rbac-authorization true --retention-days 7
   az keyvault secret set --vault-name $KV -n demo-secret --value "Hello from Key Vault"   # Forbidden
   
   KVID=$(az keyvault show -n $KV --query id -o tsv)
   ME=$(az ad signed-in-user show --query id -o tsv)
   az role assignment create --assignee $ME --role "Key Vault Secrets Officer" --scope $KVID
   sleep 60
   az keyvault secret set --vault-name $KV -n demo-secret --value "Hello from Key Vault"
   az keyvault secret show --vault-name $KV -n demo-secret --query value -o tsv

   Owner is a control-plane role: it manages the vault resource, not what's inside. Reading and writing secrets are DataActions, just like reading blobs in chapter 2.

9. Task

   Check your security posture

   Open Microsoft Defender for Cloud and find out, without enabling any paid plan:

   • your subscription's secure score;
   • at least two recommendations that concern a resource in rg-az104-lab, with their severity;
   • for one of them, which Zero Trust principle or defense-in-depth layer it belongs to.
   Done when

   • You've noted the score and two recommendations, and you've matched one to a principle or layer.
   • All Defender plans in Environment settings are still Off (except free foundational CSPM).
   Hint

   A brand-new subscription can take up to 24 hours before the score and recommendations appear. If it's still empty, come back to this task at the start of chapter 7.

   Solution · Portal

   1. Microsoft Defender for Cloud → Overview: the secure score tile.
   2. Recommendations: filter Resource group = rg-az104-lab. Typical results: "Key vaults should have deletion protection enabled", "Storage accounts should restrict network access" or "Machines should have a vulnerability assessment solution". Note the risk level / severity.
   3. Example mapping: "Key vaults should have deletion protection enabled" → data layer / assume breach. "Management ports should be closed" → network/compute layer / least privilege.
   4. Environment settings → your subscription → Defender plans: check that everything is Off. Don't start the free trial here; it switches on paid plans after 30 days.
   Solution · Azure CLI

   az security secure-scores list --query "[].{name:displayName, current:current, max:max, pct:percentage}" -o table
   az security assessment list --query "[?contains(id,'rg-az104-lab') && status.code=='Unhealthy'].{rec:displayName, resource:resourceDetails.id}" -o table
   az security pricing list --query "value[].{plan:name, tier:pricingTier}" -o table