Azure security baseline for Azure Bastion
This security baseline applies guidance from the Azure Security Benchmark version 2.0 to Azure Bastion. The Azure Security Benchmark provides recommendations on how you can secure your cloud solutions on Azure. The content is grouped by the security controls defined by the Azure Security Benchmark and the related guidance applicable to Azure Bastion.
You can monitor this security baseline and its recommendations using Microsoft Defender for Cloud. Azure Policy definitions will be listed in the Regulatory Compliance section of the Microsoft Defender for Cloud dashboard.
When a section has relevant Azure Policy Definitions, they are listed in this baseline to help you measure compliance to the Azure Security Benchmark controls and recommendations. Some recommendations may require a paid Microsoft Defender plan to enable certain security scenarios.
Note
Controls not applicable to Azure Bastion, and those for which the global guidance is recommended verbatim, have been excluded. To see how Azure Bastion completely maps to the Azure Security Benchmark, see the full Azure Bastion security baseline mapping file.
Network Security
For more information, see the Azure Security Benchmark: Network Security.
NS-1: Implement security for internal traffic
Guidance: When you deploy Azure Bastion resources you must create or use an existing virtual network. Ensure that all Azure virtual networks follow an enterprise segmentation principle that aligns to the business risks. Any system that could incur higher risk for the organization should be isolated within its own virtual network and sufficiently secured with a network security group (NSG).
Azure Bastion service requires following ports need to be open for service to function properly:
Ingress Traffic:
Ingress Traffic from public internet: The Azure Bastion will create a public IP that needs port 443 enabled on the public IP for ingress traffic. Port 3389/22 are NOT required to be opened on the AzureBastionSubnet.
Ingress Traffic from Azure Bastion control plane: For control plane connectivity, enable port 443 inbound from GatewayManager service tag. This enables the control plane, that is, Gateway Manager to be able to communicate with Azure Bastion.
Egress Traffic:
Egress Traffic to target virtual machines (VMs): Azure Bastion will reach the target VMs over private IP. The NSGs need to allow egress traffic to other target VM subnets for port 3389 and 22.
Egress Traffic to other public endpoints in Azure: Azure Bastion needs to be able to connect to various public endpoints within Azure (for example, for storing diagnostics logs and metering logs). For this reason, Azure Bastion needs outbound to 443 to AzureCloud service tag.
Connectivity to Gateway Manager and Azure service tag is protected (locked down) by Azure certificates. External entities, including the consumers of those resources, can't communicate on these endpoints.
Responsibility: Customer
Microsoft Defender for Cloud monitoring: The Azure Security Benchmark is the default policy initiative for Microsoft Defender for Cloud and is the foundation for Microsoft Defender for Cloud's recommendations. The Azure Policy definitions related to this control are enabled automatically by Microsoft Defender for Cloud. Alerts related to this control may require an Microsoft Defender plan for the related services.
Azure Policy built-in definitions - Microsoft.Network:
Name (Azure portal) |
Description | Effect(s) | Version (GitHub) |
---|---|---|---|
All Internet traffic should be routed via your deployed Azure Firewall | Microsoft Defender for Cloud has identified that some of your subnets aren't protected with a next generation firewall. Protect your subnets from potential threats by restricting access to them with Azure Firewall or a supported next generation firewall | AuditIfNotExists, Disabled | 3.0.0-preview |
Subnets should be associated with a Network Security Group | Protect your subnet from potential threats by restricting access to it with a Network Security Group (NSG). NSGs contain a list of Access Control List (ACL) rules that allow or deny network traffic to your subnet. | AuditIfNotExists, Disabled | 3.0.0 |
NS-2: Connect private networks together
Guidance: Azure Bastion supports deploying into a peered network to centralize your Bastion deployment and enable cross-network connectivity.
Responsibility: Customer
NS-7: Secure Domain Name Service (DNS)
Guidance: Not applicable; Azure Bastion does not expose its underlying DNS configurations, these settings are maintained by Microsoft.
Responsibility: Microsoft
Identity Management
For more information, see the Azure Security Benchmark: Identity Management.
IM-1: Standardize Azure Active Directory as the central identity and authentication system
Guidance: Azure Bastion is integrated with Azure Active Directory (Azure AD) which is Azure's default identity and access management service. Users can access the Azure portal using Azure AD authentication to manage Azure Bastion service (create, update, and delete Bastion resources).
Connecting to virtual machines using Azure Bastion relies on either an SSH key or username/password, and currently does not support the use of Azure AD credentials.
You can store your SSH keys as Azure Key Vault secrets and use these secrets to connect to your virtual machines using Azure Bastion. You can control user access to these secrets by assigning Key Vault access policies either on individual users or Azure AD groups. Your users will need the following permissions to use this method to connect to a virtual machine:
- Get access to the secrets stored in the chosen Azure Key Vault
- List access to the secrets stored in the chosen Azure Key Vault
In addition to an SSH key or username/password, when connecting to virtual machines using Azure Bastion your user will need the following role assignments:
- Reader role on the target virtual machine
- Reader role on the NIC with the private IP of the target virtual machine
- Reader role on the Azure Bastion resource
- Reader Role on the virtual network of the target virtual machine (if the Bastion deployment is in a peered virtual network)
For more information, see the following references:
Responsibility: Customer
IM-3: Use Azure AD single sign-on (SSO) for application access
Guidance: Azure Bastion doesn't support SSO for authentication when authenticating to virtual machine resources, only SSH or username/password are supported. However, Azure Bastion uses Azure Active Directory (Azure AD) to provide identity and access management for the overall service. Users can authenticate to Azure AD to access and manage their Azure Bastion resources, and experience seamless single-sign on with their own synced enterprise identities via Azure AD Connect.
Responsibility: Customer
Privileged Access
For more information, see the Azure Security Benchmark: Privileged Access.
PA-3: Review and reconcile user access regularly
Guidance: Azure Bastion uses Azure Active Directory (Azure AD) accounts and Azure RBAC to manage its resources. Review user accounts and access assignment regularly to ensure the accounts and their access are valid. You can use Azure AD access reviews to review group memberships, access to enterprise applications, and role assignments. Azure AD reporting can provide logs to help discover stale accounts. You can also use Azure AD Privileged Identity Management to create access review report workflow to facilitate the review process.
In addition, Azure Privileged Identity Management can also be configured to alert when an excessive number of administrator accounts are created, and to identify administrator accounts that are stale or improperly configured.
Responsibility: Customer
PA-6: Use privileged access workstations
Guidance: Secured, isolated workstations are critically important for the security of sensitive roles like administrators, developers, and critical service operators. Depending on your requirements, you can use highly secured user workstations for performing administrative management tasks with your Azure Bastion resources in production environments. Use Azure Active Directory (Azure AD), Microsoft Defender Advanced Threat Protection (ATP), and/or Microsoft Intune to deploy a secure and managed user workstation for administrative tasks. The secured workstations can be centrally managed to enforce secured configuration, including strong authentication, software and hardware baselines, and restricted logical and network access.
Responsibility: Customer
PA-7: Follow just enough administration (least privilege principle)
Guidance: Azure Bastion is integrated with Azure role-based access control (RBAC) to manage its resources. Azure RBAC allows you to manage Azure resource access through role assignments. You can assign these built-in roles to users, groups, service principals and managed identities. There are pre-defined built-in roles for certain resources, and these roles can be inventoried or queried through tools such as Azure CLI, Azure PowerShell or the Azure portal. The privileges you assign to resources through the Azure RBAC should be always limited to what is required by the roles. This complements the just in time (JIT) approach of Azure Active Directory (Azure AD) Privileged Identity Management (PIM) and should be reviewed periodically. Use built-in roles to allocate permission and only create custom roles when required.
When connecting to virtual machines using Azure Bastion your user will need the following role assignments:
- Reader role on the target virtual machine
- Reader role on the NIC with the private IP of the target virtual machine
- Reader role on the Azure Bastion resource
For more information, see the following references:
Responsibility: Customer
Data Protection
For more information, see the Azure Security Benchmark: Data Protection.
DP-4: Encrypt sensitive information in transit
Guidance: Azure Bastion uses TLS for data in transit between user and virtual machine.
Responsibility: Microsoft
Asset Management
For more information, see the Azure Security Benchmark: Asset Management.
AM-1: Ensure security team has visibility into risks for assets
Guidance: Ensure security teams are granted Security Reader permissions in your Azure tenant and subscriptions so they can monitor for security risks using Microsoft Defender for Cloud.
Depending on how security team responsibilities are structured, monitoring for security risks could be the responsibility of a central security team or a local team. That said, security insights and risks must always be aggregated centrally within an organization.
Security Reader permissions can be applied broadly to an entire tenant (Root Management Group) or scoped to management groups or specific subscriptions.
Note: Additional permissions might be required to get visibility into workloads and services.
Responsibility: Customer
AM-2: Ensure security team has access to asset inventory and metadata
Guidance: Apply tags to your Azure Bastion resources, resource groups, and subscriptions to logically organize them into a taxonomy. Each tag consists of a name and a value pair. For example, you can apply the name "Environment" and the value "Production" to all the resources in production. Ensure that security teams have access to a continuously updated inventory of assets on Azure. They can use Azure Resource Graph to query and discover all resources in your subscriptions, including Azure services, applications, and network resources.
Responsibility: Customer
AM-3: Use only approved Azure services
Guidance: Use Azure Policy to audit and restrict which services users can provision in your environment, this includes being able to allow or deny deployments of Azure Bastion resources. Use Azure Resource Graph to query for and discover resources within their subscriptions. You can also use Azure Monitor to create rules to trigger alerts when a non-approved service is detected.
Responsibility: Customer
Logging and Threat Detection
For more information, see the Azure Security Benchmark: Logging and Threat Detection.
LT-2: Enable threat detection for Azure identity and access management
Guidance: Azure Bastion integrates with Azure Active Directory (Azure AD) and the service is accessed over the Azure portal. By default management actions to the service (such as create, update, and delete) are captured via the Azure Activity Log. Users should also enable Azure Bastion resource logs, such as session BastionAuditLogs to track bastion sessions.
Azure AD provides the following user logs that can be viewed in Azure AD reporting or integrated with Azure Monitor, Microsoft Sentinel or other SIEM/monitoring tools for more sophisticated monitoring and analytics use cases:
Sign-ins – The sign-ins report provides information about the usage of managed applications and user sign-in activities.
Audit logs - Provides traceability through logs for all changes done by various features within Azure AD. Examples of audit logs include changes made to any resources within Azure AD like adding or removing users, apps, groups, roles and policies.
Risky sign-ins - A risky sign-in is an indicator for a sign-in attempt that might have been performed by someone who is not the legitimate owner of a user account.
Users flagged for risk - A risky user is an indicator for a user account that might have been compromised.
Microsoft Defender for Cloud can also alert on certain suspicious activities such as an excessive number of failed authentication attempts, and deprecated accounts in the subscription. In addition to the basic security hygiene monitoring, Microsoft Defender for Cloud’s Threat Protection module can also collect more in-depth security alerts from individual Azure compute resources (such as virtual machines, containers, app service), data resources (such as SQL DB and storage), and Azure service layers. This capability allows you to see account anomalies inside the individual resources.
Responsibility: Customer
LT-3: Enable logging for Azure network activities
Guidance: Enable Azure Bastion resource logs, use these diagnostics logs to view which users connected to which workloads, at what time, from where, and other such relevant logging information. Users can configure these logs to be sent to a storage account for long-term retention and auditing.
Enable and collect network security group (NSG) resource logs and NSG flow logs on the network security groups that are applied to the virtual networks you have your Azure Bastion resource deployed. These logs can then be used for analyzing network security and to support incident investigations, threat hunting, and security alert generation. You can send the flow logs to an Azure Monitor Log Analytics workspace and then use Traffic Analytics to provide insights.
Responsibility: Customer
Microsoft Defender for Cloud monitoring: The Azure Security Benchmark is the default policy initiative for Microsoft Defender for Cloud and is the foundation for Microsoft Defender for Cloud's recommendations. The Azure Policy definitions related to this control are enabled automatically by Microsoft Defender for Cloud. Alerts related to this control may require an Microsoft Defender plan for the related services.
Azure Policy built-in definitions - Microsoft.Network:
Name (Azure portal) |
Description | Effect(s) | Version (GitHub) |
---|---|---|---|
Network Watcher should be enabled | Network Watcher is a regional service that enables you to monitor and diagnose conditions at a network scenario level in, to, and from Azure. Scenario level monitoring enables you to diagnose problems at an end to end network level view. It is required to have a network watcher resource group to be created in every region where a virtual network is present. An alert is enabled if a network watcher resource group is not available in a particular region. | AuditIfNotExists, Disabled | 3.0.0 |
LT-4: Enable logging for Azure resources
Guidance: Activity logs, which are automatically available, contain all write operations (PUT, POST, DELETE) for your Azure Bastion resources except read operations (GET). Activity logs can be used to find an error when troubleshooting or to monitor how a user in your organization modified a resource.
Responsibility: Customer
LT-5: Centralize security log management and analysis
Guidance: Centralize logging storage and analysis to enable correlation. For each log source, ensure you have assigned a data owner, access guidance, storage location, what tools are used to process and access the data, and data retention requirements.
Ensure you are integrating Azure activity logs into your central logging. Ingest logs via Azure Monitor to aggregate security data generated by endpoint devices, network resources, and other security systems. In Azure Monitor, use Log Analytics workspaces to query and perform analytics, and use Azure Storage accounts for long term and archival storage.
In addition, enable and onboard data to Microsoft Sentinel or a third-party SIEM.
Many organizations choose to use Microsoft Sentinel for “hot” data that is used frequently and Azure Storage for “cold” data that is used less frequently.
Responsibility: Customer
LT-6: Configure log storage retention
Guidance: Ensure that any storage accounts or Log Analytics workspaces used for storing Azure Bastion logs has the log retention period set according to your organization's compliance regulations.
In Azure Monitor, you can set your Log Analytics workspace retention period according to your organization's compliance regulations.
Responsibility: Customer
LT-7: Use approved time synchronization sources
Guidance: Azure Bastion does not support configuring your own time synchronization sources. The Azure Bastion service relies on Microsoft time synchronization sources, and these are not exposed to customers for configuration.
Responsibility: Microsoft
Posture and Vulnerability Management
For more information, see the Azure Security Benchmark: Posture and Vulnerability Management.
PV-1: Establish secure configurations for Azure services
Guidance: Define and implement standard security configurations for Azure Bastion with Azure Policy. Use Azure Policy aliases in the "Microsoft.Network" namespace to create custom policies to audit or enforce the network configuration of your Azure Bastion. Customers can also establish secure configurations by leveraging Azure Blueprints or ARM templates to deploy Bastion resources securely and consistently.
Responsibility: Customer
PV-2: Sustain secure configurations for Azure services
Guidance: Define and implement standard security configurations for Azure Bastion with Azure Policy. Use Azure Policy aliases in the "Microsoft.Network" namespace to create custom policies to audit or enforce the network configuration of your Bastion resources.
Responsibility: Customer
PV-6: Perform software vulnerability assessments
Guidance: Microsoft performs vulnerability management on the underlying systems that support Azure Bastion.
Responsibility: Microsoft
PV-7: Rapidly and automatically remediate software vulnerabilities
Guidance: Microsoft performs vulnerability management and software update on the underlying systems that support Azure Bastion.
Responsibility: Microsoft
PV-8: Conduct regular attack simulation
Guidance: As required, conduct penetration testing or red team activities on your Azure resources and ensure remediation of all critical security findings.
Follow the Microsoft Cloud Penetration Testing Rules of Engagement to ensure your penetration tests are not in violation of Microsoft policies. Use Microsoft's strategy and execution of Red Teaming and live site penetration testing against Microsoft-managed cloud infrastructure, services, and applications.
Responsibility: Shared
Endpoint Security
For more information, see the Azure Security Benchmark: Endpoint Security.
ES-1: Use Endpoint Detection and Response (EDR)
Guidance: Azure Bastion is a fully managed PaaS offering and Microsoft is responsible for handling endpoint protection.
Responsibility: Microsoft
ES-2: Use centrally managed modern anti-malware software
Guidance: Azure Bastion is a fully managed PaaS offering and Microsoft is responsible for installing and managing anti-malware protection.
Responsibility: Microsoft
ES-3: Ensure anti-malware software and signatures are updated
Guidance: Azure Bastion is a fully managed PaaS offering and Microsoft is responsible for installing, managing, and updating anti-malware signature.
Responsibility: Microsoft
Next steps
- See the Azure Security Benchmark V2 overview
- Learn more about Azure security baselines
Feedback
Submit and view feedback for