Remote Access with Azure Bastion

Introduction: Why Secure Remote Access Matters

In the early days of cloud computing, many organizations managed their virtual machines (VMs) by exposing them directly to the internet. Administrators would open port 3389 for Remote Desktop Protocol (RDP) or port 22 for Secure Shell (SSH) on the public firewall, allowing anyone with the IP address and credentials to attempt a connection. This practice is incredibly dangerous. It makes your infrastructure a constant target for brute-force attacks, credential stuffing, and automated vulnerability scanning. If a single password is weak or an unpatched vulnerability exists in the RDP or SSH service, an attacker can gain full administrative control over your server.

Azure Bastion was developed to solve this fundamental security problem. Instead of exposing your virtual machines to the public internet, you place them in a private network (a Virtual Network or VNet) with no public IP addresses assigned to the individual machines. Azure Bastion acts as a hardened, managed gateway that sits inside your VNet. It provides secure RDP and SSH access to your VMs directly through the Azure Portal over SSL (Secure Sockets Layer). Because the traffic is encrypted and handled by the Bastion service, you no longer need to manage public IPs or open insecure ports on your VM network security groups.

This lesson explores the architecture of Azure Bastion, how to implement it, the differences between its various service tiers, and the best practices required to keep your environment secure. By the end of this guide, you will understand how to transition your remote management strategy from an insecure, public-facing model to a private, managed, and audited architecture.

The Architecture of Azure Bastion

To understand Azure Bastion, you must first understand the concept of a "jump box" or "bastion host." Traditionally, administrators would build a small, hardened Linux or Windows server, place it in a public subnet, and use it as a gateway to reach other private servers. The problem with this DIY approach is that the jump box itself becomes a high-value target. You have to maintain its operating system, patch its software, manage its SSH keys or RDP certificates, and configure its firewall rules. If you fail to maintain the jump box perfectly, it becomes the weakest link in your security chain.

Azure Bastion is a Platform-as-a-Service (PaaS) offering that removes the burden of maintaining that jump box. When you deploy Azure Bastion, you are essentially deploying a managed container that resides in a specific subnet within your VNet, known as the AzureBastionSubnet. This subnet must be dedicated entirely to the Bastion service. Once deployed, the service handles the RDP and SSH sessions for you.

When you initiate a connection from the Azure Portal:

1. Your browser establishes an encrypted SSL/TLS connection to the Azure Bastion service.
2. The Bastion service authenticates your request using Microsoft Entra ID (formerly Azure AD) and Azure Role-Based Access Control (RBAC).
3. Once authenticated, the Bastion service initiates a private connection to your target VM using the VM's private IP address.
4. The traffic between the Bastion service and the target VM remains entirely within the Azure backbone network.

This architecture ensures that your VMs never need a public IP address. They remain isolated from the public internet, drastically reducing the attack surface.

Callout: Bastion vs. Traditional Jump Box A traditional jump box is a VM that you own, patch, and manage. It requires a public IP address, consumes compute resources, and requires constant security hardening. Azure Bastion is a managed service. Microsoft handles the patching, scaling, and availability of the underlying platform. You simply configure the service and connect. The security posture of a managed service is significantly higher because it is purpose-built to resist common network-based attacks.

Service Tiers: Basic, Standard, and Premium

Azure Bastion offers different tiers to meet the needs of varying organizational sizes and security requirements. Understanding these tiers is essential for cost management and feature utilization.

1. Basic Tier

The Basic tier is designed for smaller environments or proof-of-concept deployments. It provides the core functionality of RDP and SSH connectivity. However, it lacks many of the advanced management and diagnostic features found in the higher tiers. It is generally suitable for simple management tasks where advanced auditing or connectivity options are not required.

2. Standard Tier

The Standard tier is the recommended choice for most enterprise production environments. It introduces several critical capabilities:

• Manual Scaling: You can scale the number of instances to handle higher numbers of concurrent connections.
• IP-based Connection: You can connect to VMs via their private IP address, even if they are outside the current VNet or in a peered VNet.
• Shareable Links: You can generate a URL that allows users to connect to a specific VM without needing access to the Azure Portal.
• Session Recording: This is a vital security feature that allows administrators to record and replay administrative sessions for auditing purposes.

3. Premium Tier

The Premium tier adds features for highly regulated environments. This includes advanced security features such as support for file transfer (copy/paste restrictions can be enforced) and deeper integration with Azure Monitor for detailed session diagnostics and alerts.

Step-by-Step Deployment Guide

Deploying Azure Bastion requires careful planning of your virtual network. The most important requirement is the creation of a dedicated subnet named AzureBastionSubnet.

Prerequisites

• An Azure Virtual Network (VNet).
• A target VM (Windows or Linux) with no public IP address (or a public IP that you intend to remove).
• Appropriate permissions (Contributor role on the VNet).

Step 1: Create the AzureBastionSubnet

Before you can deploy the Bastion service, you must prepare your VNet.

1. Navigate to your Virtual Network in the Azure Portal.
2. Select Subnets in the left-hand menu.
3. Click + Subnet.
4. Set the name to AzureBastionSubnet (this is a mandatory, hardcoded name).
5. Ensure the subnet size is at least a /26 or larger.
6. Save the configuration.

Step 2: Deploy the Bastion Resource

1. Search for "Bastion" in the top search bar and select Bastion.
2. Click + Create.
3. Fill in the project details (Subscription, Resource Group, and Name).
4. Select the region (this must match the region of your VNet).
5. Choose your Tier (Standard is recommended).
6. In the Virtual Network section, select your VNet. The portal will automatically detect the AzureBastionSubnet you created in the previous step.
7. Configure a Public IP address for the Bastion service itself (this is the only public-facing point of the entire deployment).
8. Review and click Create.

Note: The deployment of the Bastion service can take between 10 to 15 minutes. Do not be alarmed if the resource remains in a "Deploying" state for a significant amount of time; the service is performing complex network configuration behind the scenes.

Connecting to Virtual Machines

Once the deployment is complete, connecting to your machines is straightforward. You no longer need to use an RDP client like mstsc.exe or an SSH client like PuTTY or OpenSSH on your local machine.

Connecting to a Windows VM

1. Navigate to your Windows VM in the Azure Portal.
2. Click Connect in the overview blade.
3. Select Bastion.
4. Click Use Bastion.
5. Enter the username and password (or SSH key if configured).
6. The VM desktop will open inside your browser window.

Connecting to a Linux VM

1. Navigate to your Linux VM in the Azure Portal.
2. Click Connect and select Bastion.
3. Choose SSH as the connection method.
4. Provide the username and either the password or the private key file.
5. A terminal window will open within the browser, providing a full shell experience.

Automation with Azure CLI

For those who prefer the command line, you can initiate a Bastion connection using the Azure CLI. This is often faster for administrators who are already working in a terminal environment.

# Command to connect to a Windows VM via Bastion
az network bastion rdp --name "MyBastionName" \
    --resource-group "MyResourceGroup" \
    --target-resource-id "/subscriptions/.../virtualMachines/MyVM"

# Command to connect to a Linux VM via Bastion
az network bastion ssh --name "MyBastionName" \
    --resource-group "MyResourceGroup" \
    --target-resource-id "/subscriptions/.../virtualMachines/MyVM" \
    --auth-type ssh-key \
    --ssh-key "~/.ssh/id_rsa"

Explanation: These commands tell the Azure CLI to look for a specific Bastion resource and use it as a tunnel to reach the target VM. By passing the --target-resource-id, you ensure that the connection is routed through the private network fabric rather than the public internet.

Best Practices for Security and Management

Deploying Azure Bastion is a major step toward a secure environment, but it is not a "set it and forget it" solution. You must wrap the service in additional security layers.

1. Enforce Conditional Access

Since Azure Bastion allows access to your entire infrastructure, it must be protected by Multi-Factor Authentication (MFA). You should create a Conditional Access policy in Microsoft Entra ID that requires MFA for any user attempting to access the Azure Portal or the Bastion resource. This ensures that even if a password is compromised, the attacker cannot reach your VMs.

2. Restrict Network Access

While Bastion protects your VMs, you should also protect the Bastion service itself. You can use Network Security Groups (NSGs) to restrict access to the AzureBastionSubnet. Only allow incoming traffic from your corporate IP ranges (or your VPN/ExpressRoute endpoints). This creates a "double-lock" scenario: you need the correct credentials to access the portal, and you need to be coming from an approved network location.

3. Use Just-In-Time (JIT) Access

Combine Azure Bastion with Microsoft Defender for Cloud's Just-In-Time VM Access feature. JIT access ensures that the ports (even the private ones used by Bastion) are closed by default. When an administrator needs to work on a server, they request access, which opens the port for a limited, specified time window (e.g., 2 hours).

4. Audit and Monitor

Always enable diagnostic settings on your Bastion resource. Stream the logs to a Log Analytics Workspace. You should monitor:

• BastionAuditLogs: Who connected to which VM and when.
• BastionConnectionLogs: Details about the duration and status of connections.

Warning: Do not ignore the logs. If you see unauthorized connection attempts in your logs, it may indicate that your administrative accounts have been compromised. Regularly reviewing these logs is a fundamental component of a proactive security posture.

Common Pitfalls and Troubleshooting

Even with a managed service, administrators often run into configuration hurdles. Below are the most common issues.

Missing Subnet

The most frequent error is failing to name the subnet AzureBastionSubnet. If you name it "BastionSubnet" or "GatewaySubnet," the Bastion deployment will fail or will not be able to locate the subnet during the configuration phase. Remember that this name is case-sensitive and must be exact.

NSG Misconfiguration

If your Bastion is deployed but you cannot connect, check your Network Security Groups. The AzureBastionSubnet requires specific inbound and outbound rules to function correctly.

• Inbound: Allow HTTPS (443) from the Internet (or your specific IP) to the Bastion subnet.
• Inbound: Allow GatewayManager and AzureLoadBalancer service tags to communicate with the Bastion subnet.
• Outbound: Allow SSH (22) and RDP (3389) traffic to the target VMs.

Peering Issues

If you are trying to connect to a VM in a different VNet, ensure that VNet Peering is enabled between the VNet containing the Bastion service and the VNet containing the target VM. Without peering, the Bastion service cannot route traffic to the private IP address of the target machine.

Browser Compatibility

Azure Bastion relies on HTML5 and WebSockets. If you are using a strictly locked-down corporate browser or an outdated browser version, the connection may fail or the console may not render correctly. Always ensure your browser is up to date and that it is not blocking WebSocket traffic via a local web proxy.

Comparison: Connectivity Methods

To help you choose the right approach, here is a quick reference comparing common remote access methods.

• Public IP + NSG: Suitable only for non-production, disposable test environments. Never use this for sensitive data.
• VPN / ExpressRoute: The gold standard for enterprise connectivity. It extends your corporate network into Azure, allowing you to use standard RDP/SSH clients. However, it is expensive and requires complex network routing configuration.
• Azure Bastion: The "sweet spot" for most cloud-native workloads. It provides a high level of security without the architectural overhead of a full VPN deployment.

Advanced Security: Session Recording and Auditing

For organizations in highly regulated industries (finance, healthcare, government), the ability to prove what was done on a server is as important as who did it. The Standard and Premium tiers of Azure Bastion provide session recording, which is a powerful tool for compliance and incident response.

When session recording is enabled, the Bastion service captures the entire interactive session. This is not just a log of keystrokes; it is a visual recording of the RDP or SSH session. If an administrator makes a configuration error or if a malicious actor gains access, you have a complete forensic trail of their actions.

Implementation of Session Recording

1. Navigate to your Bastion resource in the Azure Portal.
2. Select Settings > Configuration.
3. Ensure the tier is set to Standard or Premium.
4. Enable the Session Recording feature.
5. Ensure you have a Storage Account configured to save the recordings.

Once enabled, every time an administrator connects via Bastion, the session is recorded. You can view these recordings directly in the Azure Portal under the Session Recordings tab. This provides an unparalleled level of transparency into administrative operations, ensuring accountability across your technical team.

Common Questions (FAQ)

Q: Can I use Azure Bastion to access VMs in an on-premises data center? A: Yes, if your on-premises network is connected to your Azure VNet via a Site-to-Site VPN or ExpressRoute. You can use Bastion to jump into the Azure VNet and then route traffic over the connection to your on-premises servers.

Q: Does Azure Bastion cost money even when I'm not using it? A: Yes. Azure Bastion is a provisioned service. You pay an hourly rate for the Bastion instance regardless of whether a user is actively connected. If you are cost-conscious, consider using the Basic tier for non-production environments where the higher costs of the Standard tier aren't justified.

Q: Can I restrict which users can access the Bastion service? A: Absolutely. Use Azure RBAC to assign the "Virtual Machine Administrator Login" or "Virtual Machine User Login" roles only to the specific users who need access. By default, do not grant these roles to any user.

Q: What happens if the Bastion service goes down? A: Azure Bastion is a managed service with a high availability SLA. However, if the service were to become unavailable, you would lose the ability to manage your VMs via the portal. It is always a best practice to have a "break-glass" account or an alternative administrative path (like a secondary VPN) for emergency situations.

Q: Can I use Azure Bastion with a multi-homed VM? A: Yes, but keep in mind that Bastion will attempt to connect to the private IP address of the NIC that is in the same VNet as the Bastion service. Ensure your routing tables are correctly configured to allow this traffic.

Key Takeaways

As we conclude this lesson, remember that the goal of Azure Bastion is to move your infrastructure toward a "Zero Trust" model. By eliminating public IP addresses and centralizing access through a managed gateway, you significantly reduce the likelihood of a successful breach.

1. Eliminate Public Exposure: The primary value of Azure Bastion is its ability to remove public IP addresses from your virtual machines, effectively making them invisible to the public internet.
2. Managed Service Advantage: Unlike a DIY jump box, Azure Bastion is a PaaS offering. Microsoft manages the underlying OS and security patches, meaning you have one less server to maintain and secure.
3. Dedicated Subnet Requirements: Always remember to create the AzureBastionSubnet with the exact name and a sufficient size (/26 or larger) to ensure the service deploys successfully.
4. Defense-in-Depth: Bastion is not a silver bullet. You must combine it with Conditional Access, MFA, and Network Security Groups to create a comprehensive security architecture.
5. Audit and Compliance: Leverage the Standard and Premium tiers for session recording, which provides a critical forensic trail for audits and incident response in sensitive environments.
6. Cost-Awareness: Choose the appropriate tier (Basic vs. Standard) based on your needs for scalability, IP-based connectivity, and session recording to optimize your cloud spend.
7. Continuous Monitoring: Regularly review your Bastion logs and connection patterns to detect anomalies or unauthorized attempts to access your infrastructure.

By mastering the deployment and management of Azure Bastion, you are not just managing servers; you are building a resilient, secure, and compliant foundation for your organization’s cloud journey. Take the time to implement these practices in your own environment, and always prioritize security over convenience.