A reviewer treats Azure Bastion and just-in-time VM access as the same control for lock-chamber servers. How should the security engineer describe their relationship?
Select an answer to reveal the explanation.
Short Explanation
Bastion is the private hallway into the lock house; JIT is the timed key that opens the management door. You want the hallway and the timed key—not one confused for the other.
Full Explanation
Bastion and just-in-time VM access are complementary, not interchangeable. Bastion is the brokered session path: RDP/SSH over TLS to a VM that needs no public IP. JIT is the time-boxed network allow on the management port from an approved source—often AzureBastionSubnet when Bastion is the only intended path—so the NSG does not leave 3389/22 open permanently. For lock-chamber servers, keep both: private brokered access plus default-deny management ports that open only when requested.
Choosing only Bastion because “JIT permanently replaces NSG denies” fails by concept: Bastion does not itself time-box NSG allows, and misunderstanding JIT as a permanent deny replacement is backwards—JIT temporarily relaxes deny. Choosing only JIT because a time-bound Allow from the Internet equals Bastion’s TLS brokering fails: JIT still opens the real management protocol toward a source IP; it does not provide Bastion’s TLS broker or remove the need for a safe path. Replacing both with PIM eligible Owner on the VM fails because identity elevation does not create a secure network path or close Internet-exposed ports by itself.
Exam caveat: when Bastion is used, JIT source IPs should typically allow the Bastion subnet (or documented Bastion ranges), not arbitrary coffee-shop Internet addresses. Operational check: remove public IPs, connect via Bastion, request JIT with Bastion as the allowed source, and verify RDP works only during the JIT window and fails afterward without reopening standing Any rules.