Security patterns

Contents

Sensitive information management patterns

Secrets are important, but the information they protect is even more critical. There are many options for securing your data, but not all options are born equal, and it can be tricky to choose the right ones. Consider, for example, data protection at rest: all storage options from Azure allow or even enforce encryption of data at rest. For example, Azure encrypts Azure Managed Disks automatically. You have only a few options to determine how they are protected and who provides the encryption key. But do you need this type of encryption? Of course, the answer is yes, but things aren’t so simple. You have to satisfy multiple needs for encryption, and this sort of protection addresses just a few of them. Again, relying on patterns is important to correctly address the most significant problems.

Create secure channels

Intent and motivation

Communications are usually the main risk for a solution. If you have a closed box that does not receive any input and does not provide any output, it is fully protected and will not be attacked. Unfortunately, such an isolated system makes sense only as an intellectual exercise.

All practical applications of technology are connected to something. It could be the internet, a local network, or even just a power outlet. Even devices that aren’t connected to anything, because they use a battery and have their Wi-Fi connectivity disabled, still send out information through screens or simply through the electromagnetic field emitted by their electronics.

In Chapter 2, you learned that the Azure security model assigns customers partial responsibility for the security of the solutions it hosts. But whatever model you choose—IaaS, PaaS, or SaaS—it is Microsoft’s responsibility to protect the physical devices. Good news, then: you do not need to be concerned about power connections and electromagnetic fields! Still, all the other concerns are well within your scope.

Description

What does it mean to create secure channels? Or better, how can you determine whether a channel is secure? There are a few requirements that must be satisfied:

  • Confidentiality The channel must preserve data confidentiality. Transmission over the internet moves through many systems, and each of these systems could potentially read and disclose the contents of the communication. To preserve confidentiality, you must wrap the content such that unauthorized parties cannot read it, typically through encryption.

  • Authentication The channel must authenticate with certainty all parties that are privy to the communication. In most situations, the main concern is the authentication of the caller, but this should not be the case. You also need to ensure that the called service authenticates itself. Fortunately, the adoption of TLS provides the authentication of the service implicitly. Still, you might need to ensure that your callers perform additional checks on the provided certificate—for example, checking whether the certificate has been issued by the expected certification authority.

  • Integrity You must confirm the integrity of transmitted information. In other words, those who receive it must check whether it has been modified by some third party while in transit. Transmission protocols usually split big messages into multiple packets. Therefore, some of these packets may be lost in transit or received in a different order than expected. To preserve integrity, you must ensure that what is received matches what has been sent.

Azure addresses some of these requirements by imposing channel encryption for most communications. With channel cryptography, like TLS, you can provide confidentiality, integrity and server authentication. But you still have to address client authentication, which is optional in TLS..

There are various ways to authenticate the client—too many to include them all here. But it might be helpful to talk about one of them in particular: client certificates. These establish a strong connection that prevents man-in-the-middle attacks. If you don’t use client certificates, an attacker can intercept a communication, terminate the TLS channel at its end, and create a new, false one directed toward the server. If you do use client certificates with TLS, however, this would not be possible because the man in the middle would not present your certificate to the target server. (Admittedly, we rarely use client certificates because they involve a high cost.)

Another approach is to create secure channels and isolate them from the internet. You can then use these secure channels to prevent the exposure of your resources and services over the internet. You can typically achieve this by using VPNs or ExpressRoute.

THE LIKELIHOOD OF INTERCEPTION

How likely is it that an attacker will intercept your traffic? After all, the internet is vast, with billions of messages sent every second. Intercepting your traffic isn’t like finding a needle in a haystack; it’s harder! So, how big of a problem is it, really?

The truth is, there are a couple situations in which the chances of your traffic being intercepted raise significantly:

  • The attacker might just be in the right place at the right moment, and you might unknowingly send your traffic their way. This could happen if you use an easily intercepted channel, like Wi-Fi, when the attacker is near you. This type of attack occurs more frequently than you might imagine—particularly in specific situations, like at security conferences.

  • You might unknowingly send your traffic through malicious nodes. A typical example of this situation is when you use Tor or some free VPN. Malicious actors host many of these resources, and they use them to tap into your traffic and potentially perform malicious actions.

Examples

  • Configure end-to-end TLS with Azure Application Gateway to ensure that TLS encryption is provided internally between Application Gateway and the target service or resource.

  • Use a point-to-site VPN to connect a single workstation to resources on Azure to avoid exposing them over the internet.

  • Use a site-to-site VPN to connect a site, which could be your office, to cloud resources not exposed over the internet. This typically requires the installation of VPN gateways to collect the traffic on both sides.

  • Use ExpressRoute to connect a site similarly to the site-to-site VPN. The main difference is that ExpressRoute is based on a dedicated infrastructure, so the connection is typically faster and more reliable.

Related security principles

  • Defense in depth

Related patterns

  • Encrypt data client-side

  • Use bring your own key (BYOK)

Encrypt data client-side

Intent and motivation

As discussed at the beginning of this section, Azure uses encryption to protect all storage. This is obviously a great feature, but does it address all your needs? To answer this question, you must first identify exactly what needs this sort of encryption does address.

The encryption at rest provided by Azure for most storage options falls under the category of transparent encryption. In other words, it ensures that if you access the storage using one of the sanctioned channels, data will be available in unencrypted form. If you access the storage using any other means, however, the data will unreadable. For example, if you try to access the data by stealing the virtual or physical disks, you will wind up with encrypted content that is not readable, even if you have the required rights.

So, transparent encryption increases the isolation of the customer data from Microsoft management environments. More specifically, it makes it more difficult for Microsoft’s administrators to get to your data. However, there are other needs that transparent encryption does not address. For example, data in memory remains unencrypted.

Data can assume three states, and you have to protect all three of them:

  • At rest This is when the data is stored somewhere.

  • In transit This happens when you transmit the data between two locations.

  • In memory This is when the data is temporarily stored in computer memory, ready for processing.

Transparent encryption only protects data at rest. When you use transparent encryption, the data is unencrypted in memory for both the database or storage server and the client. So, you typically protect data in transit by adopting TLS, which Azure enables by default.

Still, if a malicious actor manages to get hold of some authentication material, that person could access the data stored in some repository. Of course, there are a few conditions for this to happen. For example, the malicious actor must have access to the repository. But when these conditions are met, the malicious actor can read the data. This is a scenario that, in most cases, could be safely considered “already mitigated.” Still, if your solution requires a higher level of security assurances, you need to consider something else, like client-side encryption.

Description

The idea behind client-side encryption is that you encrypt the data on the client before sending it to the storage system. This ensures that the data is encrypted from that point on, including in the repository memory. Of course, the application must decrypt the data to consume it. At that point, the data would be potentially at risk.

If your storage system is a database server, things become interesting. Because the client-side encrypted data is not readable by the logic executed on the database server, it would be impossible to perform typical activities like searching its content. Still, with some implementation of client-side encryption, like Cosmos DB and SQL Server Always Encrypted, it is possible to perform limited comparisons.

The implementation of client-side encryption is possible when the platform supports it, and it might still be achievable as a custom activity. But in that case, it should be treated as a delicate task, requiring thorough testing and in-depth validation by experts, because it is possible to make fatal mistakes. And even under the best conditions, client-side encryption can have a significant impact on the performance of the system, due to computational costs and because it may be impossible to index data to improve search speed.

tip.jpg TIP

When you implement client-side encryption, a typical pattern is to consider adopting Azure Key Vault for storing the cryptographic keys.

Examples

  • Cosmos DB and SQL Server Always Encrypted provides a way to encrypt data client-side. It includes a mode called deterministic encryption, which allows to search for records having some specific value. For example, if you encrypt a tax code with deterministic encryption, you can get all rows in a table where a field has the same tax code.

note.jpg NOTE

The very characteristic that makes deterministic encryption worthwhile is also its main weakness. For example, an attacker could group all the records associated with the same tax code, which could provide them with enough information to identify a person from the other metadata. For this reason, consider randomized encryption as the first option and revert to deterministic encryption if necessary.

  • Some libraries that provide programmatic access to Azure Storage implement the necessary logic to perform client-side encryption for Azure Storage. For examples of this with .NET, Java, and Python code, see https://azsec.tech/ci5.

Related security principles

  • Defense in depth

  • Fail secure

  • Leveraging existing components

Related patterns

  • Protect secrets with Azure Key Vault

Use bring your own key (BYOK)

Intent and motivation

Data encryption has multiple roles. One of the least commonly considered is crypto-shredding. Cryptoshredding involves deliberately deleting or overwriting encryption keys used to secure sensitive data. In this way, you can ensure that nobody can read the data you no longer need, or you can block data exfiltration in an emergency. With crypto-shredding, you can make it impossible for anyone to access your data.

Description

One of the best ways to do this is to use BYOK. With this approach, Azure Key Vault stores the key, which is under your control. So, to crypto-shred your data, you simply purge your key from its Key Vault. When you do, all that data becomes immediately unrecoverable.

MORE ON BYOK

One of the primary purposes of BYOK is to increase users’ control over their keys. The idea is that by introducing their own keys, users make it harder for the cloud service provider to access their data. Unfortunately, that’s not why BYOK is useful. If you do not trust Microsoft with your data, why should you trust it to handle your key securely? You are storing it in its systems. In other words, if you assume that a malicious administrator could access your data, you should also assume that person could access your keys, too. Fortunately, Azure includes many other controls to prevent this from happening, including strong physical controls and various isolation layers that require escalation paths under the control of the customer to access the data.

Of course, this is a two-edged sword, because a malicious actor could leverage this approach to cause a denial of service. Some SaaS solutions like Microsoft 365 implement mechanisms to prevent losses due to the destruction of the BYOK. One such feature is called Availability Key and is discussed here: https://azsec.tech/89t.

Example

If you have an Azure SQL or Azure Storage and have used BYOK to encrypt them at rest, you can remove the key from Azure Storage to crypto-shred the content.

Related security principles

  • Defense in depth

  • Leveraging existing components

  • Separation of duties

Related patterns

  • Protect secrets with Azure Key Vault

Save to your account

This chapter is from the book