Securing Azure Service Bus

Author: Olena Borzenko

Security should be considered from the initial stages of designing a product rather than as an afterthought. This is particularly important for Service Bus as it often forms a part of a larger system. Security requirements may vary depending on the use case; for instance, a banking solution would have different security needs compared to a solution for a local bakery.

Let’s examine common security risks, understand the importance of data encryption and various robust authentication methods such as Azure AD and shared access signatures, explore strategies for network protection, and emphasize the value of logging for enhanced oversight.

Data Protection and Risks

The sensitivity or potential impact of a data leak may be high when transmitting data via Service Bus, particularly if it involves financial transactions, medical records, or sensitive personal information. It is crucial to protect the data from risks such as data exfiltration, unauthorized data movements, and unauthorized access. It is also important to have proper logging to monitor what is happening with the data.

Service Bus performs encryption in transit, or in other words, it ensures that data is encrypted while being transmitted. This includes encryption when data is moving from the client to Service Bus, within Service Bus, and from Service Bus to the consumer. By default, Azure Service Bus supports TLS 1.2 protocol on public endpoints. Initially, it was TLS 1.0, but due to customer demands for higher security, it now defaults to the higher version. However, this doesn’t mean that versions 1.0 and 1.1 are deprecated; they are still supported for backward compatibility, and users can set a minimum TLS version in their namespace. During other exchanges, secure protocols like HTTPS for straightforward RESTful operations and AMQP for efficient message queuing are used.

Besides encryption in transit, Service Bus also performs encryption at rest, meaning messages are encrypted while they are at rest (stored). This process is done automatically, and users don’t have to do anything to enable it. The encryption uses Azure storage encryption, and Service Bus is transitioning to service fabric storage for improved performance and cost savings.

But what if the built-in security layers are not sufficient to meet customer requirements? In such cases, users can enhance security by bringing their own encryption key, stored in Azure Key Vault — a method commonly referred to as BYOK (Bring Your Own Key). The provided key can be used to encrypt data, adding an extra layer of security. This is particularly important for organizations with stringent security policies.

So far we’ve examined some built-in security features as well as the method of introducing an extra layer of protection using the BYOK approach. There are also actions that can be taken on the client side for more advanced scenarios.

For example, an additional layer of encryption can be implemented by the client, an approach we can refer to as client-side encryption. The data protection step is performed before sending the data to Service Bus. While this is the most secure method, it also requires the most effort, as the client is responsible for both encryption and decryption. This approach is commonly used in highly sensitive environments like healthcare, where data breaches can have significant consequences.

As we can see, there are many different mechanisms to secure our data. For maximum security, we can go a step further and opt for multi-layer encryption. By combining client-side encryption, bringing your own key, and the platform encryption provided by Service Bus, we can achieve the highest level of data protection.

Authentication methods

As previously mentioned, Azure Service Bus offers two types of authentication: Azure Active Directory (Azure AD) and Shared Access Signatures (SAS) keys. Let’s take a brief overview of these two types to understand what might be more suitable for certain needs.

As a more modern and recommended form of authentication, Azure Active Directory (Azure AD) offers a range of features that enhance security and ease of management. It supports various types of accounts, service principals and provides a streamlined and secure method for managing identities. Its flexibility makes it easier to manage access for different clients or customers. For those looking to further tighten security, it’s possible to disable SAS authentication entirely and rely solely on Azure AD. Additionally, custom roles can be created to offer more granular permissions, allowing for tailored access control based on specific needs.

Another robust authentication option, known as Shared Access Signatures (SAS) keys, involves generating a connection string from primary and secondary keys for authentication. These keys can be set at different scopes — namespace, topic, or queue — to allow fine-grained access control. To serve various consumers or users you can also create multiple keys but it’s important to note that they are static and require manual rotation for enhanced security, especially the root manager key that controls the entire namespace. For extra security, using a token provider, such as an API that issues authentication tokens, is recommended over direct key usage. Although SAS are somewhat dated, they remain supported and are useful for systems restricted to this authentication method.

Network-level security

Having explored data protection measures and authentication methods, let’s now turn our attention to another crucial aspect of securing Azure Service Bus: network-level security.

One effective measure is to set Service Tags on the Service Bus namespace, which allows you to specify which Azure services can access your Service Bus. Additionally, IP Filtering can be employed to limit access to specific IP addresses or ranges. For those using the premium tier of Service Bus, adding the Service Bus to a Virtual Network can further minimize the attack surface.

It’s worth mentioning that Service Bus is a foundational element of Azure’s architecture and offers tier-specific features. For instance, the premium tier provides advanced options like VNet integration, mainly because it operates on a dedicated resource model, unlike the standard tier.

Who knows, maybe in the future the gap between the two tiers will be bridged to some extent. But for now, this gap results in a significant price difference between the standard and premium plans. Despite the use of dedicated hardware resources like virtual machines in the premium service, efforts are underway to narrow this price difference and make the subscription more accessible and affordable. Additionally, guidance and templates may be introduced to help determine the continuous need for the service or its occasional use.

Logging and monitoring for security and system health

As we conclude our comprehensive exploration of Azure Service Bus security, let’s delve into the indispensable aspects of logging and monitoring for both security and overall system health.

Service Bus generates a significant amount of logs, accessible through Application Insights and Log Analytics. The Kusto Query Language (KQL) is particularly useful for those who wish to work with these logs, as they include information about messages sent, connections made, and operations performed.

There is also support for Azure Policy, which allows users to set policies for various configurations. For example, a user can set a minimum TLS version across all subscriptions to ensure that security standards are met. This helps ensure that everyone adheres to the same security principles.

It is important to not only log information but also to actively monitor it for anomalies or issues. Service Bus allows users to set up alerts based on certain conditions or dynamic thresholds. For instance, if there is an unusual spike in connections, an alert can be triggered. This proactive monitoring is crucial, especially for those on duty, to quickly identify and address issues.

Through Azure Monitor, users can integrate with other services such as Logic Apps or Azure Functions. Some companies have automated their workflow such that when an alert is triggered, the system analyzes what’s happening, assigns it to the correct team, sets a priority, and creates a ticket. This streamlines the process and ensures that the right people can start working on the issue promptly.

In summary, the level of security implementation should be tailored to the specific scenario, taking into account the criticality of the data and operations involved. For instance, a small customer sending a few messages may not need the same robust measures as a large organization handling sensitive data. Alongside this, configuring encryption is a pivotal step, with options like client-side encryption providing added assurance by keeping keys on-premises. While Azure is compliant with GDPR and other standards, it’s essential to verify these, especially when dealing with sensitive information.

This article is part of XPRT. Magazine #15

Download here

The post Securing Azure Service Bus appeared first on Xebia | Xpirit.