10.2 Azure Bastion and JIT VM Access

Why Remote Access Controls Dominate Server Security Questions

The SC-500 secure-compute domain calls out two operational controls for servers and VMs: plan and implement Azure Bastion and enable and enforce just-in-time (JIT) VM access. Both attack the same problem—management plane exposure—from different angles. Attackers continuously scan the internet for open RDP (3389) and SSH (22). Standing public access is an exam fail condition and a real-world breach pattern.

Your default secure design:

1. No public IP on workload VMs for management.
2. Azure Bastion (or another controlled private path) for interactive admin sessions.
3. JIT so even private/path-allowed management ports are not always open in NSGs.
4. Identity hardening (Entra login, Conditional Access, PIM) so network access alone is not enough.

---

Azure Bastion: Managed RDP/SSH over TLS

Azure Bastion is a fully managed PaaS service that provides secure and seamless RDP/SSH connectivity to VMs directly from the Azure portal (and, on higher SKUs, from native clients) over TLS. Key security properties examiners expect you to state:

• VMs do not need public IP addresses for Bastion connectivity.
• You do not open inbound 3389/22 from the internet to the VM.
• Traffic from the operator to Bastion is encrypted (HTTPS/TLS); Bastion then reaches the VM over the virtual network private space.
• Bastion removes the need to run and patch a customer-managed jump box (though jump boxes still appear in legacy architectures).

Deployment topology essentials

For dedicated Bastion deployments (Basic, Standard, Premium):

• Create a dedicated subnet named AzureBastionSubnet with size /26 or larger (smaller subnets fail deployment).
• Associate a public IP with Bastion (except private-only Premium designs that intentionally avoid a public IP on Bastion itself).
• Place Bastion in a hub virtual network and use VNet peering so one Bastion can reach spoke VMs (supported on Basic+).
• NSGs on spoke subnets should allow the Bastion service tags/paths required for RDP/SSH from Bastion—not Internet sources.

Developer SKU is different: shared Microsoft-managed infrastructure, limited concurrency (commonly one VM connection at a time), no classic AzureBastionSubnet dedicated host model, and no VNet peering support. It is fine for light lab/dev scenarios—not production hub-and-spoke estates.

---

Bastion SKUs at Exam Depth

SC-500 does not require memorizing every checkbox, but you must match SKU to requirement:

Exam scenarios:

• “Connect from the portal without public IPs on VMs” → Bastion (any appropriate dedicated SKU).
• “Record admin sessions for auditors” → Premium (session recording).
• “Bastion must not have a public IP” → Premium private-only design.
• “Native RDP/SSH client, custom ports, scale hosts” → Standard or Premium.
• “Cheap shared Bastion for a sandbox with one VM” → Developer (if regionally available).

SKU upgrades are supported along the feature ladder; downgrades generally require delete/recreate—know that operational constraint when a cost-optimization stem appears.

---

Just-in-Time (JIT) VM Access

Just-in-time VM access is a Microsoft Defender for Cloud / Defender for Servers capability that locks down inbound traffic to selected management ports and opens them only when needed.

How JIT works (Azure)

1. You enable JIT on a VM (or accept the recommendation) and configure ports, maximum request time (for example 1–3 hours), and allowed source IPs (requestor IP, CIDR, or Any—prefer least privilege).
2. Defender for Cloud ensures deny-all inbound rules exist for those ports on the NSG (and, when supported, Azure Firewall classic rules). Existing more-specific allow rules can still take precedence—review effective rules carefully.
3. An admin requests access in the portal, Defender, or API, stating justification and duration within policy limits.
4. After approval (if required by your process) or automatic grant per policy, JIT temporarily inserts/allows traffic for the approved source and window.
5. When the window expires, access closes again—no standing 3389/22 from the internet.

Plan note: JIT is a Defender for Servers Plan 2 feature in the current plan matrix (not the thin Plan 1 EDR-only tier). Exam stems that mention enabling JIT imply the subscription has the appropriate Defender for Servers coverage.

Ports and resources

Common JIT ports: 22 (SSH), 3389 (RDP), and sometimes WinRM or custom management ports. JIT supports Azure Resource Manager VMs and can work with AWS EC2 in multicloud Defender scenarios by adjusting security groups. Limitations to remember:

• JIT with Azure Firewall Manager policy-based firewalls has documented restrictions; classic Azure Firewall rule collections are the supported firewall pairing in docs.
• JIT is not a substitute for Bastion—it is a port lockdown and temporary allow control. You can use Bastion with JIT for defense in depth.

---

NSG Automation by JIT (What Changes on the Wire)

Exam questions often ask what JIT actually modifies. Answer in this order:

1. Primary control plane: Network Security Group rules on the VM/subnet path.
2. Intent: Persistent deny for management ports when idle; temporary allow for approved sources during a request.
3. Priority behavior: If a broad allow already exists for 3389 from Internet, JIT’s deny may not win—clean up reckless allow rules first.
4. Auditability: Requests, requestors, ports, and time windows are logged—useful for SOC review and exam “which control provides audited temporary access?” stems.

Never do this in production or on the exam’s “best design” answer:

• Attach a public IP and NSG allow * → 3389 or 22 permanently.
• Use a permanent jump VM with RDP open to the world “because Bastion costs money.”
• Disable JIT after the first inconvenience without compensating private access controls.

---

Bastion vs JIT vs Private Connectivity (Choose Correctly)

Layered reference design: Hub Bastion (Standard/Premium) + spoke VMs without public IPs + NSGs denying direct Internet management + JIT enabled for any residual management-port needs + Entra-based VM login + Conditional Access.

---

Exam Scenarios and Traps

Scenario A: Finance VMs must never have public IPs; admins connect from the Azure portal over TLS. → Deploy Bastion in the hub with AzureBastionSubnet /26+.

Scenario B: Security wants RDP closed except when an engineer requests a two-hour window from a specific IP. → Enable JIT and configure port 3389, max duration, and source IP.

Scenario C: Auditors need video/session evidence of who did what on production servers. → Bastion Premium session recording (plus identity and activity logs).

Scenario D: A recommendation flags unhealthy VMs because management ports are always open. → Enable JIT and remove permanent allow rules.

Classic traps

• Trap: “Bastion requires opening 3389 on the VM to the internet.” False—Bastion avoids that pattern.
• Trap: “JIT replaces MFA and PIM.” False—JIT is network-time control; identity still matters.
• Trap: “Developer SKU Bastion is fine for multi-spoke production.” False—no peering; shared limits.
• Trap: “Any Defender for Cloud free tier includes JIT.” JIT is tied to Defender for Servers Plan 2 capabilities in current docs—do not invent free-tier JIT.

Secure remote access is only half of server security. Next you extend the same controls to hybrid machines with Azure Arc and deepen runtime protection with Defender for Servers.