Mastering Secure Connectivity: Azure Bastion and Just-In-Time Access

Introduction: The Challenge of Secure Remote Administration

In the early days of cloud computing, many organizations treated their virtual machines much like physical servers in a local data center. Administrators would often assign public IP addresses to these virtual machines, open up RDP (Remote Desktop Protocol) or SSH (Secure Shell) ports on the Network Security Group (NSG), and connect directly from their local machines. While this approach was simple to set up, it introduced a massive security vulnerability: the management interface of your infrastructure was exposed to the entire internet. Automated bots and malicious actors constantly scan these open ports, attempting brute-force attacks to gain unauthorized access to your environment.

As cloud environments have grown in complexity, the need for a more controlled, hardened approach to remote administration has become non-negotiable. This is where Azure Bastion and Just-In-Time (JIT) VM Access come into play. These tools represent a shift in philosophy: rather than exposing management ports to the public, you move the access point behind a secure, managed gateway and restrict the duration of that access to only when it is strictly necessary. By implementing these technologies, you significantly reduce the attack surface of your virtual machines and make it exponentially harder for an attacker to gain a foothold in your network.

This lesson explores how these two technologies function, how to implement them effectively, and how they contribute to a layered security strategy. We will walk through the configuration, the operational workflows, and the industry best practices required to maintain a secure environment in Azure.

Understanding Azure Bastion: The Secure Gateway

Azure Bastion is a platform-as-a-service (PaaS) offering that provides secure and seamless RDP and SSH connectivity to your virtual machines directly through the Azure portal over SSL. Instead of your virtual machine needing a public IP address, the Bastion service acts as a proxy. You connect to the Bastion service, and it establishes a secure connection to your virtual machine over the private internal network.

Why Use Azure Bastion?

The primary advantage of Azure Bastion is that it eliminates the need for public IP addresses on your virtual machines for administrative purposes. By removing the public IP, you effectively "hide" your virtual machines from the public internet. Even if an attacker knows the IP address of your machine, they cannot reach the RDP or SSH ports because the NSG rules do not allow traffic from the internet—they only allow traffic originating from the subnet where the Bastion service resides.

Furthermore, because the connection happens over SSL/TLS, the traffic is encrypted end-to-end. You do not need to install any additional software on your local machine or on the target virtual machine. Everything is handled through the browser, which simplifies the experience for administrators who might be working from different locations or different operating systems.

Callout: Bastion vs. Traditional Jumpbox A traditional "jumpbox" is a virtual machine you provision yourself, which you then harden, patch, and maintain to act as a gateway. While this offers high customization, it also adds significant management overhead—you are responsible for the security of the jumpbox itself. Azure Bastion, by contrast, is a fully managed service. Microsoft handles the patching, scaling, and underlying infrastructure, allowing you to focus purely on the access policies.

Key Features of Azure Bastion

• Browser-based connectivity: Access your VMs directly via the Azure Portal.
• No Public IPs required: VMs can remain entirely within private subnets.
• Integration with NSGs: Seamlessly works with existing Network Security Group rules.
• Support for multiple protocols: Supports both RDP (Windows) and SSH (Linux).
• Copy/Paste and File Transfer: Allows for convenient clipboard and file transfer operations within the session.

Implementing Azure Bastion: Step-by-Step

To implement Azure Bastion, you must follow a specific networking configuration. Bastion requires a dedicated subnet named AzureBastionSubnet within the virtual network where your target virtual machines reside.

Step 1: Create the AzureBastionSubnet

Before you can deploy the Bastion service, you must ensure your Virtual Network (VNet) has a subnet specifically reserved for it. This subnet must be at least a /26 or larger.

1. Navigate to your Virtual Network in the Azure Portal.
2. Select "Subnets" from the left-hand menu.
3. Click "+ Subnet" and name it exactly AzureBastionSubnet.
4. Specify the address range (e.g., 10.0.1.0/26) and save the configuration.

Step 2: Deploy the Bastion Resource

Once the subnet is ready, you can create the Bastion host.

1. Search for "Bastion" in the Azure search bar and select "Create".
2. Provide the resource group, name, and region (ensure it matches your VNet).
3. In the "Virtual Network" section, select the VNet you configured in Step 1.
4. Select the AzureBastionSubnet you created.
5. Choose a public IP address for the Bastion service itself (this is the only public entry point).
6. Review and create the resource.

Step 3: Connecting to a VM

Once the deployment finishes, connecting to a VM is straightforward.

1. Go to the "Virtual Machines" blade in the portal.
2. Select your target VM and click "Connect".
3. Select the "Bastion" tab.
4. Enter your credentials (username/password or SSH key).
5. Click "Connect" to open the session in a new browser tab.

Note: Ensure that your Network Security Group (NSG) associated with the target VM allows ingress traffic from the AzureBastionSubnet on the appropriate ports (3389 for RDP or 22 for SSH). If you do not configure this, the connection will time out despite the Bastion service being active.

Just-In-Time (JIT) VM Access: Reducing the Exposure Window

While Azure Bastion secures the connection path, Just-In-Time (JIT) VM Access focuses on when that path is open. Without JIT, your management ports (22 or 3389) are often left open 24/7 in your NSG rules. If a vulnerability is discovered in the RDP or SSH daemon, or if a user’s credentials are leaked, an attacker has a permanent window of opportunity to exploit those ports.

JIT VM Access, part of Microsoft Defender for Cloud, solves this by modifying your NSG rules dynamically. When a user requests access, JIT creates a temporary "allow" rule for that specific user’s IP address for a limited time (e.g., 3 hours). Once the time expires, the rule is automatically removed, effectively closing the port again.

How JIT Enhances Security

JIT enforces the principle of least privilege. By ensuring that management ports are only open when an administrator is actively performing a task, you eliminate the possibility of long-term unauthorized access attempts. This is a critical component of a "Zero Trust" architecture, where you assume that the network is always hostile and access must be explicitly granted and verified.

Implementing JIT VM Access

JIT is configured via the Microsoft Defender for Cloud dashboard.

1. Navigate to "Microsoft Defender for Cloud" in the portal.
2. Go to "Workload protections" and find "Just-in-time VM access".
3. You will see a list of your virtual machines. Select the machines you want to protect and click "Enable JIT on VMs".
4. Configure the default policy, including which ports to protect (e.g., 3389/22) and the maximum duration for which access can be requested.
5. When an administrator needs access, they return to this dashboard, select the VM, and click "Request Access".

The Workflow of a JIT Request

1. Request: The admin clicks "Request Access" for a specific VM and port.
2. Validation: Azure checks if the user has the required Azure RBAC permissions to request access.
3. NSG Update: Azure automatically updates the NSG to allow traffic from the requester’s specific public IP address.
4. Audit: An entry is logged in the Azure Activity Log for compliance and auditing purposes.
5. Expiration: After the time limit (e.g., 3 hours) passes, Azure automatically deletes the NSG rule, returning the VM to its hardened state.

Best Practices and Industry Standards

Implementing these tools is not a "set it and forget it" task. To truly gain the security benefits, you must follow established industry standards.

1. Enforce Multi-Factor Authentication (MFA)

Regardless of how secure your gateway is, if an attacker steals an admin's password, they could potentially bypass your defenses. Always enforce MFA for any user who has the RBAC permissions to request JIT access or use Azure Bastion. This adds a second layer of verification that is independent of the password.

2. Use Role-Based Access Control (RBAC)

Not every developer or IT staff member needs the ability to request JIT access. Use Azure RBAC to restrict who can initiate a JIT request or connect via Bastion. Create custom roles or use built-in roles like "Virtual Machine Administrator Login" to ensure that permissions are scoped to the minimum necessary level.

3. Maintain Comprehensive Logging

Both Bastion and JIT generate audit trails. Ensure that these logs are being sent to a Log Analytics Workspace or a SIEM (Security Information and Event Management) system like Microsoft Sentinel. This allows you to monitor for unusual patterns, such as an administrator requesting access at 3:00 AM or a high frequency of failed access requests, which could indicate a compromised account.

4. Regularly Review NSG Rules

While JIT handles the dynamic rules, you should still conduct periodic audits of your static NSG rules. Ensure that no other rules accidentally override the JIT-managed rules or open ports to the entire internet. A common mistake is having a broad rule (e.g., "Allow all from VNet") that might inadvertently expose the management ports to other, less-secure virtual machines within the same network.

Warning: The "Any/Any" Trap Never create NSG rules that allow traffic from 0.0.0.0/0 (the entire internet) on management ports, even if you think it's temporary. It is almost guaranteed that an automated scanner will find that port within minutes. If you need temporary access, use JIT or a VPN, never leave the port open to the public internet.

Comparison: Azure Bastion vs. VPN Gateway vs. Public IP

It is helpful to compare Bastion with other common connectivity methods to understand when each is appropriate.

When to use which:

• Azure Bastion: Best for management of individual VMs for administrative tasks. It is ideal for teams who want a simple, browser-based, secure way to access VMs without managing VPN tunnels.
• VPN Gateway: Best for connecting an entire office or data center network to your Azure VNet. Use this when you need persistent access to many resources simultaneously, not just for management.
• Public IP: Generally discouraged for management. Only use this for web servers or services that must be accessible to the public, and ensure those services are protected by a Web Application Firewall (WAF) or similar security layer.

Common Pitfalls and How to Avoid Them

Even with the best tools, implementation errors can lead to security gaps. Here are some of the most frequent mistakes administrators make.

Misconfiguring Subnet Requirements

One of the most common issues is failing to size the AzureBastionSubnet correctly. If you assign a subnet that is too small, you might encounter issues when trying to scale or update the Bastion service. Additionally, forgetting to name the subnet exactly AzureBastionSubnet will result in the portal failing to recognize it during the deployment process.

Over-Privileged Access

Giving every user in your organization the "Contributor" role on the virtual machines is a significant security risk. If a user is a Contributor, they can potentially change the NSG rules themselves, bypassing the security you have put in place. Always follow the principle of least privilege: assign roles that only allow the specific actions needed for the task.

Ignoring the "JIT Request" Workflow

Sometimes, teams enable JIT but then find it "too slow" to request access every time they need to connect. They might be tempted to create a permanent rule to "save time." This is a major security failure. If the workflow is too cumbersome, consider automating the request process via PowerShell or the Azure CLI, rather than disabling the security control.

Example: Automating JIT Requests with PowerShell

If you find the portal workflow tedious, you can automate the JIT access request using the Azure PowerShell module. This allows you to integrate the request into your own scripts or CI/CD pipelines.

# Define the parameters for the request
$ResourceGroupName = "MyResourceGroup"
$VMName = "MySecureVM"
$Location = "eastus"
$Port = 3389

# Request JIT access for the specified VM and port
# This command triggers the backend to update the NSG
Set-AzJitNetworkAccessPolicy -ResourceGroupName $ResourceGroupName `
    -Location $Location `
    -Name "default" `
    -VirtualMachine @{
        Id = "/subscriptions/.../resourceGroups/$ResourceGroupName/providers/Microsoft.Compute/virtualMachines/$VMName"
        Ports = @{
            Number = $Port
            Protocol = "TCP"
            AllowedSourceAddressPrefix = @("YOUR_PUBLIC_IP_HERE")
            MaxRequestAccessDuration = "PT3H"
        }
    }

Explanation: This script updates the JIT policy for a specific VM, specifying the port, the requester's IP, and the duration. Using scripts like this ensures consistency and allows you to build "Self-Service" portals for your developers.

Advanced Considerations: Scaling and Multi-Region

As your infrastructure grows, you might find that a single Bastion host is not sufficient. Azure Bastion supports scaling, but it is important to understand the limitations.

Scaling Bastion

Azure Bastion supports "Host Scaling" for the Premium SKU. If you have a large number of concurrent users connecting to VMs, you can increase the number of instances to handle the load. This is useful for large enterprise environments where dozens of administrators might be working simultaneously.

Multi-Region Deployments

Azure Bastion is a regional service. A Bastion host in "East US" cannot connect to a virtual machine in "West Europe" over the private network. If you have a multi-region architecture, you must deploy a Bastion host in each region where you have virtual machines that require secure management. This can increase costs, so plan your architecture accordingly.

Integrating with Private Links

For even tighter security, you can integrate Azure Bastion with Azure Private Link. This ensures that all traffic between your local environment and the Bastion service is kept on the Microsoft backbone network and never traverses the public internet at all. This is a common requirement in highly regulated industries like finance or healthcare.

Summary and Key Takeaways

Securing remote access is one of the most fundamental tasks in cloud security. By moving away from exposed public IP addresses and embracing managed services like Azure Bastion and Just-In-Time access, you can transform your security posture from reactive to proactive.

Key Takeaways

• Eliminate Public IPs: Never assign public IP addresses to virtual machines intended for internal administration. Use Azure Bastion to bridge the gap between your local machine and your private virtual network.
• Embrace Just-In-Time Access: Use Microsoft Defender for Cloud to ensure that management ports are closed by default and only opened on a per-request basis. This drastically limits the exposure window for brute-force attacks.
• Layered Security is Essential: Bastion and JIT are not "silver bullets." They must be combined with strong identity management (MFA), role-based access control (RBAC), and continuous monitoring/logging to be truly effective.
• Automate, Don't Bypass: If security controls seem to hinder productivity, look for ways to automate the process (e.g., via PowerShell or CLI) rather than creating exceptions or permanent firewall rules.
• Audit Regularly: Use Azure Activity Logs and Microsoft Sentinel to review who is accessing your systems, when, and from where. A security system that is not audited is a system that can be silently compromised.
• Plan for Regionality: Remember that Azure Bastion is a regional service. When planning your global architecture, ensure you have sufficient Bastion capacity in each region where your virtual machines reside.
• Keep it Simple: The best security configurations are often the simplest ones. By adhering to standard practices—like using the AzureBastionSubnet naming convention and standard ports—you reduce the likelihood of human error and configuration drift.

By following these principles, you ensure that your cloud environment remains resilient against unauthorized access. The goal is to make the "front door" of your infrastructure as secure as possible, ensuring that only authenticated, authorized, and verified users can reach your critical assets, and only for as long as they need to perform their duties.