Introduction
In the blog post-https://fredrkl.com/blog/private-aks-access/, I mentioned the Azure Bastion service to safely and securely access a jump-host with only private IP. But what security considerations do we need to consider to avoid having your local developer machine become a connected device according to the PCI-DSS standard? Is it enough to use the Azure Bastion service?
Azure Bastion
Azure Bastion is a secure, fully managed network service by Microsoft. It provides seamless Remote Desktop Protocol (RDP) and Secure Shell (SSH) access to your virtual machines directly through the Azure Portal or from using the az cli. The crucial advantage of Azure Bastion is that it eliminates the need to expose your virtual machines to the public internet, enhancing the security of your infrastructure.
Instead of needing a public IP address, all interactions with your virtual machines take place through Azure Bastion, which is itself a service in the Azure portal. By doing this, Azure Bastion significantly reduces the surface area that is exposed to potential security vulnerabilities and attacks.
Another key aspect of Azure Bastion is that Microsoft fully manages it. This means that you don't have to worry about the operational overhead of maintaining the service. Microsoft takes care of all patching, scaling, and availability, letting you focus on what matters most: your applications and data.
Azure Bastion has the following settings:
PCI-DSS connected device
The Payment Card Industry Data Security Standard (PCI-DSS) defines a connected device as any device that is connected to a network where cardholder data is transmitted or stored. These devices need to be managed and secured according to the PCI-DSS requirements to protect cardholder data and sensitive authentication data. These requirements include maintaining a secure network, protecting stored cardholder data, implementing strong access control measures, regularly monitoring and testing networks, and maintaining information security policies.
AD login support
Ideally, we want to log in to our jump-host through the Azure bastion service using Azure AD. Developers need to use PIM to get jump-host access temporarily through a dedicated Azure AD group. However after having investigated it seems that using Azure AD for login is only supported when using the az cli and not through the portal(https://learn.microsoft.com/en-us/answers/questions/409639/enable-azure-ad-login-with-bastion-on-exisitng-vm):
az network bastion ssh --name "<BastionName>" --resource-group "<ResourceGroupName>" --target-resource-id "<VMResourceId or VMSSInstanceResourceId>" --auth-type "AAD"or:
az network bastion rdp --name "<BastionName>" --resource-group "<ResourceGroupName>" --target-resource-id "<VMResourceId or VMSSInstanceResourceId>" --auth-type "AAD"If you use the az network bastion ssh command is your computer, according to the PCI-DSS description above, then a connected device? I think the idea behind the PCI-DSS connected requirement is to make it difficult to make data dumps or give access to programs running on an insecure computer, e.g., your developer machine, indirectly access to card data.
If you want to be on the safe side, turn off ssh access using Azure Network Security Group by restrict ssh port usage, and only let the developers use RDP.
Conlusion
In conclusion, while Azure Bastion offers significant security benefits by reducing the exposure of your virtual machines to the public internet, careful consideration must be given to how you choose to access your VMs. Using Azure AD to log in through the Azure Bastion service is ideal, particularly for developers needing temporary access. However, the fact that Azure AD login is only supported when using the az cli and not through the portal could potentially conflict with PCI-DSS requirements. Thus, it is advisable to disable ssh access and restrict port usage, relying on RDP for access to ensure you are on the safe side of your security and compliance obligations.