azure-network-security-design

Name: azure-network-security-design
Author: vinayaklatthe

161stars34forks

How to install azure-network-security-design?

vinayaklatthe/microsoft-security-skills/azure-network-security-design

$npx -y skills add vinayaklatthe/microsoft-security-skills --skill azure-network-security-design

Installs into the current project.

Summary

Guidance for designing secure Azure network architecture — hub-spoke topology (or Virtual WAN), segmentation with NSGs/ASGs, private endpoints / Private Link for PaaS, egress through Azure Firewall, DDoS protection, WAF on Front Door/App Gateway, and centralised private DNS. Alig

Files · 1

View on GitHub

SKILL.md

1	# Azure Network Security Design
2
3	Secure Azure networking applies Zero Trust to the network pillar: segment, control traffic
4	explicitly, prefer private connectivity, and inspect / filter egress, assuming the network is
5	hostile. The output is a hub-spoke (or Virtual WAN) topology with NSG microsegmentation,
6	private endpoints, and a single controlled egress path.
7
8	## When to use
9	Designing the network topology and controls for an Azure landing zone or workload. Use this
10	skill to pick topology, design segmentation, and place controls.
11
12	Do not use this skill for the firewall product itself (`azure-firewall`), VM hardening
13	(`defender-for-cloud-hardening`), or single-service networking (`azure-key-vault`).
14
15	## Pick the topology
16
17	\| Estate shape \| Topology \| Notes \|
18	\|---\|---\|---\|
19	\| Single region, few subscriptions \| Hub-spoke (single region) \| Default for most \|
20	\| Multi-region with many spokes / branch sites \| Virtual WAN \| Microsoft-managed transit \|
21	\| Greenfield enterprise-scale \| Azure Landing Zones (CAF) - VWAN or hub-spoke \| Use CAF blueprints \|
22	\| Heavy on-prem + Azure \| Hub-spoke + ExpressRoute / VPN gateway \| Hub holds gateway + firewall \|
23	\| Small / single-workload \| Single VNet, no hub \| Don't over-engineer \|
24
25	> Rule of thumb: hub-spoke for most enterprises, Virtual WAN at multi-region branch
26	> scale. The hub holds shared services (firewall, gateway, DNS, Bastion); workloads sit in
27	> spokes. Don't put workloads in the hub.
28
29	## Approach
30
31	1. Topology and address plan — Pick hub-spoke or Virtual WAN. Allocate non-overlapping RFC
32	1918 ranges per region / spoke; reserve gateway subnet, firewall subnet, Bastion subnet in
33	the hub.
34	*Verify: address plan documented; no overlap with on-prem ranges; no overlap between
35	regions.*
36
37	2. Segmentation with NSGs and ASGs — NSG at subnet level (preferred over per-NIC).
38	Group workloads with Application Security Groups (ASGs) instead of static IP lists -
39	ASGs survive scale events. Microsegment by tier: web / app / data.
40	*Verify: NSG flow logs enabled to a Log Analytics workspace; default-deny rule present;
41	ASGs used instead of IP-based source/dest for VM groups.*
42
43	3. Private endpoints for PaaS — Use Private Endpoints / Private Link for sensitive
44	PaaS (Storage, SQL, Key Vault, Cosmos DB). Traffic stays on Microsoft backbone. Disable
45	public network access on the PaaS resource itself.
46	*Verify: `publicNetworkAccess = Disabled` on the resource; private endpoint resolves to a
47	private IP via private DNS zone.*
48
49	4. Centralise egress through Azure Firewall — UDR on spokes: `0.0.0.0/0` next hop =
50	firewall private IP. All outbound goes through the firewall for FQDN filtering and
51	logging.
52	*Verify: effective routes on a spoke NIC show next-hop = firewall; no spoke has its own
53	public IP egress.*
54
55	5. DDoS + WAF for public-facing — Enable Azure DDoS Network Protection on VNets
56	with public IPs. Place public web apps behind Front Door or **Application Gateway
57	with WAF** in Prevention mode.
58	Verify: DDoS plan associated; WAF rules in Prevention (not Detection) for prod.
59
60	6. Centralised DNS — Private DNS zones linked from the hub; spokes auto-resolve PaaS
61	private endpoints via the zones. Don't let each spoke run its own DNS.
62
63	7. Block management plane on the internet — No direct RDP / SSH from internet to VMs.
64	Use Azure Bastion (in the hub) or Defender for Cloud just-in-time VM access.
65	Verify: NSGs block 3389 / 22 from internet on all VM subnets; Bastion deployed in hub.
66
67	## Guardrails
68	- Prefer private endpoints over service endpoints for sensitive PaaS data planes. Service
69	endpoints leave the PaaS resource public; private endpoints make it truly private.
70	- Default-deny NSGs; document every allow rule's purpose. Allow lists drift to "allow
71	everything" without discipline. Use ASGs + comments.
72	- **Don't expose management ports (RDP/SSH) to the internet - use Bastion / just-in-time
73	access.** Internet-exposed 3389 / 22 = compromise within hours.
74	- DNS is part of network security. Untrusted DNS resol

People who liked this also viewed

6 picks

Type

azure-network-security-design

161stars34forks

View on GitHub

How to install azure-network-security-design?

vinayaklatthe/microsoft-security-skills/azure-network-security-design

$npx -y skills add vinayaklatthe/microsoft-security-skills --skill azure-network-security-design

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Azure Network Security Design
2
3	Secure Azure networking applies Zero Trust to the network pillar: segment, control traffic
4	explicitly, prefer private connectivity, and inspect / filter egress, assuming the network is
5	hostile. The output is a hub-spoke (or Virtual WAN) topology with NSG microsegmentation,
6	private endpoints, and a single controlled egress path.
7
8	## When to use
9	Designing the network topology and controls for an Azure landing zone or workload. Use this
10	skill to pick topology, design segmentation, and place controls.
11
12	Do not use this skill for the firewall product itself (`azure-firewall`), VM hardening
13	(`defender-for-cloud-hardening`), or single-service networking (`azure-key-vault`).
14
15	## Pick the topology
16
17	\| Estate shape \| Topology \| Notes \|
18	\|---\|---\|---\|
19	\| Single region, few subscriptions \| Hub-spoke (single region) \| Default for most \|
20	\| Multi-region with many spokes / branch sites \| Virtual WAN \| Microsoft-managed transit \|
21	\| Greenfield enterprise-scale \| Azure Landing Zones (CAF) - VWAN or hub-spoke \| Use CAF blueprints \|
22	\| Heavy on-prem + Azure \| Hub-spoke + ExpressRoute / VPN gateway \| Hub holds gateway + firewall \|
23	\| Small / single-workload \| Single VNet, no hub \| Don't over-engineer \|
24
25	> Rule of thumb: hub-spoke for most enterprises, Virtual WAN at multi-region branch
26	> scale. The hub holds shared services (firewall, gateway, DNS, Bastion); workloads sit in
27	> spokes. Don't put workloads in the hub.
28
29	## Approach
30
31	1. Topology and address plan — Pick hub-spoke or Virtual WAN. Allocate non-overlapping RFC
32	1918 ranges per region / spoke; reserve gateway subnet, firewall subnet, Bastion subnet in
33	the hub.
34	*Verify: address plan documented; no overlap with on-prem ranges; no overlap between
35	regions.*
36
37	2. Segmentation with NSGs and ASGs — NSG at subnet level (preferred over per-NIC).
38	Group workloads with Application Security Groups (ASGs) instead of static IP lists -
39	ASGs survive scale events. Microsegment by tier: web / app / data.
40	*Verify: NSG flow logs enabled to a Log Analytics workspace; default-deny rule present;
41	ASGs used instead of IP-based source/dest for VM groups.*
42
43	3. Private endpoints for PaaS — Use Private Endpoints / Private Link for sensitive
44	PaaS (Storage, SQL, Key Vault, Cosmos DB). Traffic stays on Microsoft backbone. Disable
45	public network access on the PaaS resource itself.
46	*Verify: `publicNetworkAccess = Disabled` on the resource; private endpoint resolves to a
47	private IP via private DNS zone.*
48
49	4. Centralise egress through Azure Firewall — UDR on spokes: `0.0.0.0/0` next hop =
50	firewall private IP. All outbound goes through the firewall for FQDN filtering and
51	logging.
52	*Verify: effective routes on a spoke NIC show next-hop = firewall; no spoke has its own
53	public IP egress.*
54
55	5. DDoS + WAF for public-facing — Enable Azure DDoS Network Protection on VNets
56	with public IPs. Place public web apps behind Front Door or **Application Gateway
57	with WAF** in Prevention mode.
58	Verify: DDoS plan associated; WAF rules in Prevention (not Detection) for prod.
59
60	6. Centralised DNS — Private DNS zones linked from the hub; spokes auto-resolve PaaS
61	private endpoints via the zones. Don't let each spoke run its own DNS.
62
63	7. Block management plane on the internet — No direct RDP / SSH from internet to VMs.
64	Use Azure Bastion (in the hub) or Defender for Cloud just-in-time VM access.
65	Verify: NSGs block 3389 / 22 from internet on all VM subnets; Bastion deployed in hub.
66
67	## Guardrails
68	- Prefer private endpoints over service endpoints for sensitive PaaS data planes. Service
69	endpoints leave the PaaS resource public; private endpoints make it truly private.
70	- Default-deny NSGs; document every allow rule's purpose. Allow lists drift to "allow
71	everything" without discipline. Use ASGs + comments.
72	- **Don't expose management ports (RDP/SSH) to the internet - use Bastion / just-in-time
73	access.** Internet-exposed 3389 / 22 = compromise within hours.
74	- DNS is part of network security. Untrusted DNS resol

People who liked this also viewed

6 picks

Type