Azure security baseline for Service Bus

The Azure Security Baseline for Service Bus contains recommendations that will help you improve the security posture of your deployment. The baseline for this service is drawn from the Azure Security Benchmark version 1.0, which provides recommendations on how you can secure your cloud solutions on Azure with our best practices guidance. For more information, see Azure Security Baselines overview.

To see how Service Bus completely maps to the Azure Security Benchmark, see the full Service Bus security baseline mapping file.

Network security

For more information, see the Azure Security Benchmark: Network security.

1.1: Protect Azure resources within virtual networks

Guidance: The integration of Service Bus with the Azure Private Link service enables secure private access to messaging capabilities from workloads such as virtual machines that are bound to virtual networks. Create a private endpoint connection to your Service Bus namespace. The private endpoint uses a private IP address from your virtual network, effectively bringing the service into your virtual network. All traffic to the service can be routed through that private endpoint, so no gateways, NAT devices, ExpressRoute or VPN connections, or public IP addresses are needed.

You can also secure your Azure Service Bus namespace by using firewalls. Azure Service Bus supports IP-based access controls for inbound firewall support. You can set firewall rules by using the Azure portal, Azure Resource Manager templates, or through the Azure CLI or Azure PowerShell.

Azure Security Center monitoring: Yes

Responsibility: Customer

1.2: Monitor and log the configuration and traffic of virtual networks, subnets, and network interfaces

Guidance: If using Azure virtual machines to access your Service Bus entities, enable network security group (NSG) flow logs and send logs into a storage account for traffic audit. You may also send NSG flow logs to a Log Analytics workspace and use Traffic Analytics to provide insights into traffic flow in your Azure cloud. Some advantages of Traffic Analytics are the ability to visualize network activity and identify hot spots, identify security threats, understand traffic flow patterns, and pinpoint network misconfigurations.

Use Azure Security Center and follow network protection recommendations to help secure your Service Bus resources in Azure.

Azure Security Center monitoring: Yes

Responsibility: Customer

1.4: Deny communications with known-malicious IP addresses

Guidance: Enable DDoS Protection Standard on the virtual networks associated with your Service Bus namespaces to guard against distributed denial-of-service (DDoS) attacks. Use Azure Security Center Integrated Threat Intelligence to deny communications with known malicious or unused Internet IP addresses.

Azure Security Center monitoring: Yes

Responsibility: Customer

1.5: Record network packets

Guidance: If using Azure virtual machines to access your Service Bus entities, you can use Network Watcher packet capture to investigate anomalous activities.

Azure Security Center monitoring: Currently not available

Responsibility: Customer

1.6: Deploy network-based intrusion detection/intrusion prevention systems (IDS/IPS)

Guidance: If using Azure virtual machines to access your Service Bus entities, select an offer from the Azure Marketplace that supports IDS/IPS functionality with payload inspection capabilities. If intrusion detection and/or prevention based on payload inspection is not required for your organization, you may use Azure Service Bus's built-in firewall feature. You can limit access to your Service Bus namespace for a limited range of IP addresses, or a specific IP address by using Firewall rules.

Azure Security Center monitoring: Yes

Responsibility: Customer

1.8: Minimize complexity and administrative overhead of network security rules

Guidance: Use Virtual Network Service Tags to define network access controls on Network Security Groups or Azure Firewall which filter traffic to and from Service Bus resources. You can use service tags in place of specific IP addresses when creating security rules. By specifying the service tag name (e.g., ServiceBus) in the appropriate source or destination field of a rule, you can allow or deny the traffic for the corresponding service. Microsoft manages the address prefixes encompassed by the service tag and automatically updates the service tag as addresses change.

Azure Security Center monitoring: Currently not available

Responsibility: Customer

1.9: Maintain standard security configurations for network devices

Guidance: Define and implement standard security configurations for network resources associated with your Azure Service Bus namespaces with Azure Policy. Use Azure Policy aliases in the "Microsoft.ServiceBus" and "Microsoft.Network" namespaces to create custom policies to audit or enforce the network configuration of your Service Bus namespaces. You may also make use of built-in policy definitions related to Azure Service Bus, such as:

  • Service Bus should use a virtual network service endpoint
  • Diagnostic logs in Service Bus should be enabled

You may also construct custom policy definitions if the built-in definitions do not fit your organization's needs.

Azure Security Center monitoring: Not applicable

Responsibility: Customer

1.10: Document traffic configuration rules

Guidance: Use tags for virtual networks and other resources related to network security and traffic flow that are associated with your Service Bus namespaces. For individual network security group rules, use the "Description" field to specify business need, duration, and other descriptive information for any rules that allow traffic to or from a network associated with your Service Bus namespaces.

Use any of the built-in Azure policy definitions related to tagging, such as "Require tag and its value" to ensure that all resources are created with tags and to notify you of existing untagged resources.

You may use Azure PowerShell or Azure CLI to look-up or perform actions on resources based on their Tags.

Azure Security Center monitoring: Not applicable

Responsibility: Customer

1.11: Use automated tools to monitor network resource configurations and detect changes

Guidance: Use Azure Activity Log to monitor network resource configurations and detect changes for network resources related to Azure Service Bus. Create alerts within Azure Monitor that will trigger when changes to critical network resources take place.

Azure Security Center monitoring: Not applicable

Responsibility: Customer

Logging and monitoring

For more information, see the Azure Security Benchmark: Logging and monitoring.

2.2: Configure central security log management

Guidance: Ingest logs via Azure Monitor to aggregate security data generated by Service Bus resources. In Azure Monitor, use Log Analytics workspaces to query and perform analytics, configure Azure Storage accounts for long term or archival storage. You can also configure logs related to Service Bus to be sent to Azure Sentinel or a third-party SIEM.

Azure Security Center monitoring: Yes

Responsibility: Customer

2.3: Enable audit logging for Azure resources

Guidance: Enable Diagnostic settings for your Azure Service Bus namespace. Azure Service Bus currently supports activity and operational or diagnostic logs. Activity logs have information about operations done on a job. Diagnostic logs provide richer information about operations and actions that are done against your namespace by using API, or through management clients using the language SDK. Specifically, these logs capture the operation type, including queue creation, resources used, and the status of the operation.

Azure Security Center monitoring: Yes

Responsibility: Customer

2.5: Configure security log storage retention

Guidance: Within Azure Monitor, set your Log Analytics workspace retention period according to your organization's compliance regulations to capture and review Service Bus-related incidents.

Azure Security Center monitoring: Not applicable

Responsibility: Customer

2.6: Monitor and review logs

Guidance: Analyze and monitor logs for anomalous behavior and regularly review results related to your Service Bus entities. Use Azure Monitor to review logs and perform queries on log data related to Service Bus.

Azure Security Center monitoring: Not applicable

Responsibility: Customer

2.7: Enable alerts for anomalous activities

Guidance: Use Azure Security Center with Log Analytics workspace for monitoring and alerting on anomalous activity found in security logs and events. Alternatively, you can also enable and on-board data to Azure Sentinel.

Azure Security Center monitoring: Currently not available

Responsibility: Customer

Identity and access control

For more information, see the Azure Security Benchmark: Identity and access control.

3.1: Maintain an inventory of administrative accounts

Guidance: Azure role-based access control (RBAC) allows you to manage access to Azure resources through role assignments. You can assign these roles to users, groups service principals and managed identities. There are pre-defined built-in roles for Service Bus, these roles can be inventoried or queried through tools such as Azure CLI, Azure PowerShell or the Azure portal.

Azure Security Center monitoring: Yes

Responsibility: Customer

3.2: Change default passwords where applicable

Guidance: Control plane access to Service Bus is controlled through Azure Active Directory (Azure AD). Azure AD does not have the concept of default passwords.

Data plane access to Service Bus is controlled through Azure AD by using Managed Identities, App registrations, or shared access signatures. Shared access signatures are used by the clients connecting to your Service Bus namespace and can be regenerated at any time.

Azure Security Center monitoring: Not applicable

Responsibility: Customer

3.3: Use dedicated administrative accounts

Guidance: Create standard operating procedures around the use of dedicated administrative accounts. Use Azure Security Center Identity and Access Management to monitor the number of administrative accounts.

Additionally, to help you keep track of dedicated administrative accounts, you may use recommendations from Azure Security Center or built-in Azure Policies, such as:

  • There should be more than one owner assigned to your subscription
  • Deprecated accounts with owner permissions should be removed from your subscription
  • External accounts with owner permissions should be removed from your subscription

You may also construct custom policy definitions if the built-in definitions do not fit your organization's needs.

Azure Security Center monitoring: Yes

Responsibility: Customer

3.4: Use Azure Active Directory single sign-on (SSO)

Guidance: Microsoft Azure provides integrated access control management for resources and applications based on Azure Active Directory (Azure AD). A key advantage of using Azure AD with Azure Service Bus is that you don't need to store your credentials in the code anymore. Instead, you can request an OAuth 2.0 access token from the Microsoft Identity platform. The resource name to request a token is https://azure.microsoft.com/services/service-bus/. Azure AD authenticates the security principal (a user, group, or service principal) running the application. If the authentication succeeds, Azure AD returns an access token to the application, and the application can then use the access token to authorize request to Azure Service Bus resources.

Azure Security Center monitoring: Not applicable

Responsibility: Customer

3.5: Use multi-factor authentication for all Azure Active Directory-based access

Guidance: Enable Azure Active Directory Multi-Factor Authentication (MFA) and follow Azure Security Center Identity and access management recommendations to help protect your Service Bus-enabled resources.

Azure Security Center monitoring: Yes

Responsibility: Customer

3.6: Use secure, Azure-managed workstations for administrative tasks

Guidance: Use privileged access workstations (PAW) with Multi-Factor Authentication (MFA) configured to log into and configure Service Bus-enabled resources.

Azure Security Center monitoring: Not applicable

Responsibility: Customer

3.7: Log and alert on suspicious activities from administrative accounts

Guidance: Use Azure Active Directory security reports and monitoring to detect when suspicious or unsafe activity occurs in the environment. Use Azure Security Center to monitor identity and access activity.

Azure Security Center monitoring: Yes

Responsibility: Customer

3.8: Manage Azure resources from only approved locations

Guidance: Use Azure AD named locations to allow access only from specific logical groupings of IP address ranges or countries/regions.

Azure Security Center monitoring: Not applicable

Responsibility: Customer

3.9: Use Azure Active Directory

Guidance: Use Azure Active Directory (AD) as the central authentication and authorization system for Azure resources such as Service Bus. This allows for Azure role-based access control (Azure RBAC) to administrative sensitive resources.

Azure Security Center monitoring: Not applicable

Responsibility: Customer

3.10: Regularly review and reconcile user access

Guidance: Azure Active Directory (Azure AD) provides logs to help you discover stale accounts. In addition, use Azure Identity Access Reviews to efficiently manage group memberships, access to enterprise applications, and role assignments. User access can be reviewed on a regular basis to make sure only the right Users have continued access.

In additional, regularly rotate your Service Bus namespace's shared access signature.

Azure Security Center monitoring: Yes

Responsibility: Customer

3.11: Monitor attempts to access deactivated credentials

Guidance: You have access to Azure Active Directory (Azure AD) sign-in activity, audit and risk event log sources, which allow you to integrate with Azure Sentinel or a third-party SIEM tool.

You can streamline this process by creating diagnostic settings for Azure AD user accounts and sending the audit logs and sign-in logs to a Log Analytics workspace. Then in Azure Monitor you can configure desired log alerts for certain actions that occur in the logs.

Azure Security Center monitoring: Not applicable

Responsibility: Customer

3.12: Alert on account sign-in behavior deviation

Guidance: Use Azure Active Directory's Identity Protection and risk detection features to configure automated responses to detected suspicious actions related to your Service Bus-enabled resources. You should enable automated responses through Azure Sentinel to implement your organization's security responses.

Azure Security Center monitoring: Not applicable

Responsibility: Customer

3.13: Provide Microsoft with access to relevant customer data during support scenarios

Guidance: Currently not available; Customer Lockbox is not yet supported for Service Bus.

Azure Security Center monitoring: Not applicable

Responsibility: Customer

Data protection

For more information, see the Azure Security Benchmark: Data protection.

4.1: Maintain an inventory of sensitive Information

Guidance: Use tags on resources related to your Service Bus to assist in tracking Azure resources that store or process sensitive information.

Azure Security Center monitoring: Not applicable

Responsibility: Customer

4.2: Isolate systems storing or processing sensitive information

Guidance: Implement separate subscriptions and management groups for development, test, and production. Service Bus namespaces should be separated by virtual networks with private endpoints configured and tagged appropriately.

Azure Security Center monitoring: Not applicable

Responsibility: Customer

4.3: Monitor and block unauthorized transfer of sensitive information

Guidance: When using virtual machines to access your Service Bus entities, make use of virtual networks, private endpoints, Service Bus firewall, network security groups, and service tags to mitigate the possibility of data exfiltration.

Microsoft manages the underlying infrastructure for Azure Service Bus and has implemented strict controls to prevent the loss or exposure of customer data.

Azure Security Center monitoring: Not applicable

Responsibility: Shared

4.4: Encrypt all sensitive information in transit

Guidance: Azure Service Bus enforces TLS-encrypted communications by default. TLS versions 1.0, 1.1 and 1.2 are currently supported. However, TLS 1.0 and 1.1 are on a path to deprecation industry-wide, so use TLS 1.2 or newer where possible.

Azure Security Center monitoring: Not applicable

Responsibility: Shared

4.5: Use an active discovery tool to identify sensitive data

Guidance: Data identification, classification, and loss prevention features are not yet available for Azure Service Bus. Implement third-party solution if required for compliance purposes.

For the underlying platform which is managed by Microsoft, Microsoft treats all customer content as sensitive and goes to great lengths to guard against customer data loss and exposure. To ensure customer data within Azure remains secure, Microsoft has implemented and maintains a suite of robust data protection controls and capabilities.

Azure Security Center monitoring: Currently not available

Responsibility: Shared

4.6: Use Role-based access control to control access to resources

Guidance: Azure Service Bus supports using Azure Active Directory (Azure AD) to authorize requests to Service Bus entities. With Azure AD, you can use Azure role-based access control (Azure RBAC) to grant permissions to a security principal, which may be a user, or an application service principal.

Azure Security Center monitoring: Not applicable

Responsibility: Customer

4.8: Encrypt sensitive information at rest

Guidance: Azure Service Bus supports the option of encrypting data at rest with either Microsoft-managed keys or customer-managed keys. This feature enables you to create, rotate, disable, and revoke access to the customer-managed keys that are used for encrypting Azure Service Bus data at rest.

Azure Security Center monitoring: Not applicable

Responsibility: Customer

4.9: Log and alert on changes to critical Azure resources

Guidance: Use Azure Monitor with the Azure Activity log to create alerts for when changes take place to production instances of Azure Service Bus and other critical or related resources.

Azure Security Center monitoring: Not applicable

Responsibility: Customer

Inventory and asset management

For more information, see the Azure Security Benchmark: Inventory and asset management.

6.1: Use automated asset discovery solution

Guidance: Use Azure Resource Graph to query and discover all resources (including Azure Service Bus namespaces) within your subscriptions. Ensure you have appropriate (read) permissions in your tenant and are able to enumerate all Azure subscriptions as well as resources within your subscriptions.

Azure Security Center monitoring: Not applicable

Responsibility: Customer

6.2: Maintain asset metadata

Guidance: Apply tags to Azure resources giving metadata to logically organize them into a taxonomy.

Azure Security Center monitoring: Not applicable

Responsibility: Customer

6.3: Delete unauthorized Azure resources

Guidance: Use tagging, management groups, and separate subscriptions, where appropriate, to organize and track Azure Service Bus namespaces and related resources. Reconcile inventory on a regular basis and ensure unauthorized resources are deleted from the subscription in a timely manner.

Azure Security Center monitoring: Not applicable

Responsibility: Customer

6.4: Define and maintain inventory of approved Azure resources

Guidance: Create an inventory of approved Azure resources and approved software for compute resources as per your organizational needs.

Azure Security Center monitoring: Not applicable

Responsibility: Customer

6.5: Monitor for unapproved Azure resources

Guidance: Use Azure Policy to put restrictions on the type of resources that can be created in customer subscriptions using the following built-in policy definitions:

  • Not allowed resource types

  • Allowed resource types

In addition, use Azure Resource Graph to query and discover resources within the subscriptions.

Azure Security Center monitoring: Yes

Responsibility: Customer

6.9: Use only approved Azure services

Guidance: Use Azure Policy to put restrictions on the type of resources that can be created in customer subscriptions using the following built-in policy definitions:

  • Not allowed resource types
  • Allowed resource types

You may also construct custom policy definitions if the built-in definitions do not fit your organization's needs.

Azure Security Center monitoring: Yes

Responsibility: Customer

6.11: Limit users' ability to interact with Azure Resource Manager

Guidance: Configure Azure Conditional Access to limit users' ability to interact with Azure Resource Manager by configuring "Block access" for the "Microsoft Azure Management" App.

Azure Security Center monitoring: Not applicable

Responsibility: Customer

Secure configuration

For more information, see the Azure Security Benchmark: Secure configuration.

7.1: Establish secure configurations for all Azure resources

Guidance: Define and implement standard security configurations for your Azure Service Bus deployments. You may also make use of built-in policy definitions for Azure Service Bus such as:

  • Diagnostic logs in Service Bus should be enabled
  • Service Bus should use a virtual network service endpoint to limit network traffic to your private networks.

Use Azure Policy aliases in the "Microsoft.ServiceBus" namespace to create custom policies to audit or enforce configurations.

Azure Security Center monitoring: Not applicable

Responsibility: Customer

7.3: Maintain secure Azure resource configurations

Guidance: Use Azure Policy [deny] and [deploy if not exist] to enforce secure settings across your Service Bus-enabled resources or applications.

Azure Security Center monitoring: Not applicable

Responsibility: Customer

7.7: Deploy configuration management tools for Azure resources

Guidance: Use Azure Policy aliases in the "Microsoft.ServiceBus" namespace to create custom policies to alert, audit, and enforce system configurations. Additionally, develop a process and pipeline for managing policy exceptions.

Azure Security Center monitoring: Not applicable

Responsibility: Customer

7.9: Implement automated configuration monitoring for Azure resources

Guidance: Use Azure Policy aliases in the "Microsoft.ServiceBus" namespace to create custom policies to alert, audit, and enforce system configurations. Use Azure Policy [audit], [deny], and [deploy if not exist] to automatically enforce configurations for your Azure Service Bus deployments and related resources.

Azure Security Center monitoring: Not applicable

Responsibility: Customer

7.11: Manage Azure secrets securely

Guidance: For Azure virtual machines or web applications running on Azure App Service being used to access your Service Bus entities, use a Managed Service Identity in conjunction with Azure Key Vault to simplify and secure shared access signature management for your Azure Service Bus deployments. Ensure Key Vault soft-delete is enabled.

Azure Security Center monitoring: Yes

Responsibility: Customer

7.12: Manage identities securely and automatically

Guidance: For Azure virtual machines or web applications running on Azure App Service being used to access your Service Bus entities, use Managed Service Identity in conjunction with Azure Key Vault to simplify and secure Azure Service Bus. Ensure Key Vault soft-delete is enabled.

Use Managed Identities to provide Azure services with an automatically managed identity in Azure Active Directory (Azure AD). Managed Identities allows you to authenticate to any service that supports Azure AD authentication, including Azure Key Vault, without any credentials in your code.

Azure Security Center monitoring: Yes

Responsibility: Customer

7.13: Eliminate unintended credential exposure

Guidance: Implement Credential Scanner to identify credentials within code. Credential Scanner will also encourage moving discovered credentials to more secure locations such as Azure Key Vault.

Azure Security Center monitoring: Not applicable

Responsibility: Customer

Malware defense

For more information, see the Azure Security Benchmark: Malware defense.

8.2: Pre-scan files to be uploaded to non-compute Azure resources

Guidance: Pre-scan any content being uploaded to non-compute Azure resources, such as Azure Service Bus, App Service, Data Lake Storage, Blob Storage, Azure Database for PostgreSQL, etc. Microsoft cannot access your data in these instances.

Microsoft anti-malware is enabled on the underlying host that supports Azure services, however it does not run on customer content.

Azure Security Center monitoring: Not applicable

Responsibility: Shared

Data recovery

For more information, see the Azure Security Benchmark: Data recovery.

9.1: Ensure regular automated back-ups

Guidance: Configure geo-disaster recovery for Azure Service Bus. When entire Azure regions or datacenters (if no availability zones are used) experience downtime, it is critical for data processing to continue to operate in a different region or datacenter. As such, Geo-disaster recovery and Geo-replication are important features for any enterprise. Azure Service Bus supports both geo-disaster recovery and geo-replication, at the namespace level.

Azure Security Center monitoring: Currently not available

Responsibility: Customer

9.2: Perform complete system backups and backup any customer-managed keys

Guidance: Azure Service Bus provides encryption of data at rest with Azure Storage Service Encryption (Azure SSE). Service Bus relies on Azure Storage to store the data and by default, all the data that is stored with Azure Storage is encrypted using Microsoft-managed keys. If you use Azure Key Vault for storing customer-managed keys, ensure regular automated backups of your Keys.

Ensure regular automated backups of your Key Vault Secrets with the following PowerShell command: Backup-AzKeyVaultSecret

Azure Security Center monitoring: Not applicable

Responsibility: Customer

9.3: Validate all backups including customer-managed keys

Guidance: Test restoration of backed up customer-managed keys use to encrypt Service Bus data.

Azure Security Center monitoring: Not applicable

Responsibility: Customer

9.4: Ensure protection of backups and customer-managed keys

Guidance: Enable soft-delete in Key Vault to protect keys against accidental or malicious deletion. Azure Service Bus requires customer-managed keys to have Soft Delete and Do Not Purge configured.

Azure Security Center monitoring: Yes

Responsibility: Customer

Incident response

For more information, see the Azure Security Benchmark: Incident response.

10.1: Create an incident response guide

Guidance: Develop an incident response guide for your organization. Ensure there are written incident response plans that define all the roles of personnel as well as the phases of incident handling and management from detection to post-incident review.

Azure Security Center monitoring: Not applicable

Responsibility: Customer

10.2: Create an incident scoring and prioritization procedure

Guidance: Azure Security Center assigns a severity to each alert to help you prioritize which alerts should be investigated first. The severity is based on how confident Security Center is in the finding or the analytic used to issue the alert as well as the confidence level that there was malicious intent behind the activity that led to the alert.

Additionally, mark subscriptions using tags and create a naming system to identify and categorize Azure resources, especially those processing sensitive data. It's your responsibility to prioritize the remediation of alerts based on the criticality of the Azure resources and environment where the incident occurred.

Azure Security Center monitoring: Yes

Responsibility: Customer

10.3: Test security response procedures

Guidance: Conduct exercises to test your systems' incident response capabilities on a regular cadence. Identify weak points and gaps and revise plan as needed.

Azure Security Center monitoring: Not applicable

Responsibility: Customer

10.4: Provide security incident contact details and configure alert notifications for security incidents

Guidance: Security incident contact information will be used by Microsoft to contact you if the Microsoft Security Response Center (MSRC) discovers that your data has been accessed by an unlawful or unauthorized party. Review incidents after the fact to ensure that issues are resolved.

Azure Security Center monitoring: Yes

Responsibility: Customer

10.5: Incorporate security alerts into your incident response system

Guidance: Export your Azure Security Center alerts and recommendations using the continuous export feature to help identify risks to Azure resources. Continuous export allows you to export alerts and recommendations either manually or in an ongoing, continuous fashion. You can use the Azure Security Center data connector to stream the alerts to Azure Sentinel.

Azure Security Center monitoring: Not applicable

Responsibility: Customer

10.6: Automate the response to security alerts

Guidance:

Use workflow automation feature Azure Security Center to automatically trigger responses to security alerts and recommendations to protect your Azure resources.

Azure Security Center monitoring: Not applicable

Responsibility: Customer

Penetration tests and red team exercises

For more information, see the Azure Security Benchmark: Penetration tests and red team exercises.

11.1: Conduct regular penetration testing of your Azure resources and ensure remediation of all critical security findings

Guidance: 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.

Azure Security Center monitoring: Not applicable

Responsibility: Shared

Next steps