Lesson: Azure Bastion and Secure Access

Introduction: The Challenge of Remote Management

In traditional cloud network architectures, administrators often open RDP (Remote Desktop Protocol, port 3389) or SSH (Secure Shell, port 22) ports to the public internet to manage virtual machines. This is a critical security vulnerability. Exposing these management ports makes your infrastructure a target for brute-force attacks, port scanning, and credential harvesting.

Azure Bastion is a Platform-as-a-Service (PaaS) offering that provides secure, seamless RDP and SSH connectivity to your virtual machines directly in the Azure portal over SSL. With Azure Bastion, your virtual machines do not require a public IP address, and you no longer need to manage Network Security Group (NSG) rules for remote access.

How Azure Bastion Works

Azure Bastion is deployed within your Virtual Network (VNet) in a specific subnet named AzureBastionSubnet. When an administrator initiates a connection through the Azure Portal, the Bastion service acts as a gateway. It establishes a secure tunnel, proxying the RDP/SSH traffic from the portal directly to the private IP of the target virtual machine.

Key Benefits

• No Public IPs Required: VMs stay isolated from the public internet.
• Integrated Authentication: Uses your existing Azure AD/RBAC permissions.
• Zero-Footprint Client: No need to install agents or software on the target VM or the local machine.
• Integrated Security: Works seamlessly with NSGs and Azure Firewall.

Practical Example: Deploying Azure Bastion

1. Prerequisites

• A Virtual Network (VNet).
• A dedicated subnet named AzureBastionSubnet (minimum size /26).

2. Deployment via Azure CLI

You can deploy Bastion using the Azure CLI. This is often faster and more repeatable than using the portal.

# Create the dedicated subnet
az network vnet subnet create \
  --resource-group MyResourceGroup \
  --vnet-name MyVNet \
  --name AzureBastionSubnet \
  --address-prefixes 10.0.1.0/26

# Create a Public IP for the Bastion service
az network public-ip create \
  --resource-group MyResourceGroup \
  --name MyBastionIP \
  --sku Standard

# Deploy the Bastion resource
az network bastion create \
  --name MyBastionHost \
  --resource-group MyResourceGroup \
  --vnet-name MyVNet \
  --public-ip-address MyBastionIP \
  --location eastus

3. Connecting to a VM

Once deployed, navigate to your Virtual Machine in the Azure Portal:

1. Select Connect > Bastion.
2. Enter your credentials (username/password or SSH private key).
3. The session will open in a new tab within your browser.

Note: The connection is encrypted via TLS, ensuring that your management traffic is secure from end-to-end.

Best Practices for Secure Access

1. Use the "Standard" SKU

Always prefer the Standard SKU for Bastion in production environments. It includes features like:

• IP-based connection: Connect to VMs via private IP.
• File Transfer: Move files between your local machine and the target VM.
• Shareable Links: Allow users to connect without needing Azure Portal access.

2. Network Security Group (NSG) Configuration

To ensure Bastion functions correctly, your NSG rules must allow specific traffic.

• Inbound: Allow GatewayManager and AzureLoadBalancer tags to communicate with the AzureBastionSubnet on port 443.
• Outbound: Allow the AzureBastionSubnet to communicate with the target VM subnet on ports 3389 (RDP) and 22 (SSH).

3. Least Privilege Access

Use Azure RBAC to control who can access the Bastion service. Assign the Reader role to the VM and the Virtual Machine Administrator Login or Virtual Machine User Login roles to those who need management access.

Common Pitfalls

• Subnet Sizing: The AzureBastionSubnet must be named exactly that. If you misspell it or use a different name, the deployment will fail.
• Forgetting to remove Public IPs: A common mistake is leaving public IPs on VMs after setting up Bastion. Once Bastion is configured, audit your VMs and remove all public IP addresses to maximize your security posture.
• Ignoring Costs: Azure Bastion is a premium service that incurs an hourly cost. For small dev/test environments, consider shutting down the Bastion resource when not in use, though this is not recommended for production.
• NSG Blocking: If the connection fails, 90% of the time it is due to an overly restrictive NSG rule on the target VM's subnet blocking the internal traffic from the AzureBastionSubnet.

⚠️ Security Warning

Even with Bastion, ensure your target VMs are hardened. Bastion secures the path to the VM, but it does not protect the VM from internal threats or malware if the VM is improperly configured. Always follow the principle of "Defense in Depth."

Key Takeaways

1. Eliminate Public Exposure: Azure Bastion is the gold standard for removing public-facing RDP/SSH ports from your cloud infrastructure.
2. Infrastructure as Code: Always automate your Bastion deployment using Terraform, Bicep, or CLI to ensure consistent networking configurations across environments.
3. Governance: Use Azure Policy to restrict the creation of Public IPs on VMs, forcing developers to use Bastion for access.
4. Operational Efficiency: Bastion removes the need for complex VPN configurations for simple administrative tasks, allowing teams to connect instantly from any secure browser.
5. Monitoring: Enable Azure Bastion diagnostic logs to track who is accessing which VMs and when, providing a robust audit trail for compliance.