Microsoft Azure, like any other hosting and cloud platform, provides tradeoffs between control of resources and ease of implementation. Additionally, cybersecurity responsibilities are shared between you, the cloud customer, and Microsoft, the cloud-service provider. General hardening practices still apply, but the scale and customizability of the Azure platform gives you some tools in your security toolbox that may not be available in an on-premises data center.

This blog post will walk through some of the available tools and provide insight into some of the tradeoffs you’ll have to make when deciding how to best secure your Azure cloud resources.

The first decision you’ll make when using Azure is what deployment model to utilize and even this initial decision comes with security implications. Azure has two different deployment models, “classic deployment” and “resource management mode”.

Resource management mode groups related cloud-resources into a single entity and is the more recent addition to the Azure product-line. Classic mode is a prepackaged “cloud service” that contains a load-balancer, a virtual machine, a network interface card and an external IP address, out-of-the-box. As of 2017, Microsoft recommends that you deploy all resources in resource management mode, and you should follow that recommendation where possible.

However, virtual machines, storage accounts, and virtual networks are supported in both resource management mode and classic mode, so it stands to reason that you could wind up being responsible for securing a classic-mode deployment in Azure.

Resource management mode uses a tool known as the Azure Resource Manager (ARM). ARM allows you the ability to create deployment templates which encourage standardized security controls for your cloud solutions, a good step towards avoiding user error.  Additionally, ARM allows you to at-once apply Role-Based Access Control (RBAC), a finer-grained access control model than the traditional discretionary access control model, to all virtual resources in a group. If you have been using Azure since before ARM was available and have grown accustomed to Classic-mode deployments, be sure to explicitly add a load-balancer to your resource groups. Load balancers came standard in classic-mode deployments, but do not in Resource Management Mode.

You’ve deployed your resources and now Azure runs your production application or stores your production data. The next obvious step is to ensure that management access to Azure instance and is tightly controlled. Start with the Azure Web Portal, https://portal.azure.com. You should use Azure Active Directory to manage who has access to the portal — and use multi-factor authentication (MFA) to harden that access.

When using the other interfaces to conduct Azure management, which includes Azure Powershell and a RESTful API, always use an encrypted method of communication with the Azure infrastructure and be careful about persisting credentials across machines. These alternative methods of resource management can perform powerful and sensitive operations just as the web-based management portal can, such as updating or deleting firewall rules.

Within the management interfaces, utilize RBAC to control access to your cloud resources. Azure provides basic roles that apply to all resource types: “Owner, Contributor, and Reader.” An owner has more capabilities than a contributor and a contributor more capabilities than a reader. Principle of Least Privilege always applies: make sure that someone who only needs to read certain data doesn’t have permission to change it. If none of these basic roles fit your purposes, you can also define your own rules with special properties that define specific capabilities. However, deviating from default comes with some potential mistakes. An easy misstep when creating custom roles, is to consider the NotActions property a deny rule for a given capability. For example, if a user is assigned a role that has NotActions property defined for reading some sensitive data, he or she will not be able to read that data. However, if at some point in the future, the user takes on an additional role that allows read access to that data, the user will be allowed to read the data regardless of what the NotActions property says.

In a common scenario, Cloud users utilize Azure to store sensitive data within a MS-SQL database. Azure makes available a variety of database security tools that can provide layers of defense including database firewalls, data masking, and the “Always Encrypted Databases”.

On the network level, both database firewalls and server-level firewalls can be tuned to whitelist allowed-IP ranges to access authorized databases. Just as it sounds, database firewall rules grant access to specific databases. Server-level firewall rules, on the other hand, grant access to a server which may host multiple databases. Microsoft recommends that you use Database-level security firewall rules as opposed to the Server-level firewall rules, because it keeps your databases more portable and access control more fine-grained. It goes without saying that you should take a whitelist approach rather than a blacklist approach, when managing any firewall.

Microsoft recently added the “Always Encrypted Database Engine” to its security toolbox and it’s especially useful in Azure. The Always Encrypted Database provides an additional layer of security for especially sensitive data. It encrypts data in the client application, for example a web application that asks users to input some sensitive data, before sending it to the backend database. Once implemented in your cloud instance, it never reveals the decryption key to the database engine or database administrator. This can be especially powerful when you have a client application and a trusted key store running on your premises, and an Azure SQL database running in the cloud. Deploying Always Encrypted database engine in this scenario would make it impossible for even Microsoft administrators to get access to the protected data, which remains a nice property.

When full-data privacy through encryption is not appropriate, consider using data masking. Database data masking in Azure allows you to shield sensitive data from legitimate users of an Azure application who do not need knowledge of the data. This can be especially handy in situations of compliance, such as PCI and HIPPA. For example, you run an application in the cloud that stores credit card numbers for a legitimate business purpose. You don’t need to expose anything but the last four digits of a credit card number to customer service representatives and can use Azure data masking to obscure the entire card number. Configure data masking with Azure SQL Cmdlets, Azure RestAPI or the Azure Portal.

Security without strong encryption is practically impossible and, thankfully, Azure allows for end-to-end encryption of data between your virtual resources, meaning data can be encrypted both at-rest and in-transit.

Accomplish encryption of data in-transit by using the most up-to-date TLS or HTTPS implementation, this is nothing new. However, encrypting data at-rest on the Azure platform becomes a more interesting discussion as you will be faced with a number of decisions. Let’s assume that you’ve decided to store encryption keys in the Azure cloud, rather than on your own premises, as on-premises key management represents a whole other blog post. Next, you must decide whether you’d like Microsoft to manage your encryption keys for you or if you’d like to take on the management burden yourself.

When deciding this, you make tradeoffs between ease-of-implementation and the amount of control that you maintain over your data. The quickest solution is to allow Microsoft to manage the keys, as it’s often as easy as checking a box indicating that you’d like encryption at rest for a service. Checking the box for encryption advantages you by adding virtually nothing to your management workload while still providing some out-of-the box encryption functionality. The disadvantage is that you have no control over key rotation and key backup and can’t segregate key management from the overall service management. Segregation of key management from service management is a useful property in large organizations, where, for example, the operations management of an application is left to the IT operations team and the management of the keys and encryption stays within the cybersecurity team.

If you’d like to manage the keys in the Azure cloud yourself, you’ll be using a tool called the Azure Key Vault. The Azure Key Vault stores your encryption keys and is thus a juicy target for attackers; control access to this key vault as you would your banking account! Azure services that house and process your data will need access to the Azure Key Vault to encrypt and decrypt data. You manage which services are allowed access to which keys through a role-based access control policy and Azure Active Directory. A service that needs access to a key will authenticate itself to Azure Active Directory to receive a token that it presents to the Azure Key Vault. Assuming the token is valid, the Azure Key Vault provides the requesting service with the encryption key that it needs.

While managing the encryption keys yourself gives you more control, it does come with added extra risk. For example, if an attacker gains “Contributor” rights to your Key Vault, he could grant himself access to the actual DEKs which in turn could be used to decrypt your sensitive data. In some cases, your organization may be well-suited to take on this risk and in other cases, it may be advantageous to allow Microsoft to take on the key-management responsibility.

Azure is a robust cloud platform that contains a number of tools and implementation options that all can affect the security of your production data and services. When implementing these security tools, such as encryption, you’ll be faced with a number of decisions and tradeoffs that need to be considered to choose the best configuration for your organization.  Furthermore, some access control options are highly configurable and with that configurability comes the potential for mistakes.