Apr 14, 2020
Azure – Security Best Practices
Azure Security Best Practices – Part 1
Hello and welcome again!
This time around, I’ve decided to make this blog post as a Part 1 of many several parts that will be released. There is just too much Azure security information to put up in a single post. So, my plan is to make multiple posts over time.
Azure has many great security features that not everyone may be aware of right from the start. This post will focus on some key areas of Azure, and how it can better enhance the security of the environment. Key focus will investigate security best practices for Azure.
Subscription Security Best Practices
When most Azure accounts are created one of the first things needed is a “subscription”. This is what holds all your resources. Organizations can make use of subscriptions in multiple methods.
- Try to use a separate subscription for each project, such as a Marketing Project X, Finance Project Y, IT Project Z. This way you organize and structure your resources within various subscriptions.
- Reduce the number of administrator users (not everyone needs to be an admin, think least access privileges).
- Reduce the access limits of non-human accounts (avoid service accounts, and automation accounts unless necessary).
- Enable auditing within the subscription, giving you the ability to understand what type of activities took place. This will help defenders identify the possible attack vectors and compromised account(s).
- Use JIT and Azure PIM, where JIT can protect your subscription by limiting user(s) access to set timelines. PIM will control your sensitive admin groups in Azure, and force methods such as approvals for accessing sensitive roles.
- All user accounts within the subscription should be forced to use MFA. Mandate this from the start, as it builds a norm of using MFA. But, also protects your subscription from compromised credentials of admin users.
- Placing something like key vault in its own subscription, as it will enhance security. Think of it to segregate your secrets off in its own environment. Very few people should have access to that particular subscription which contains the key vault and it’s secrets.
Network Security Best Practices
Networking within Azure is a huge component, and there are several ways to secure all of your network and connections.
- Create smaller dedicated virtual networks using NSG’s (network security groups) to control access making sure to not lead every connection back to your corporate environment.
- In the virtual networks using NSG, only be sure allow network access to Virtual Machines on services that need to be open/exposed. Lock every other service/port/network connection down. If it’s not needed it should not be open or accessible.
- By default, start to block all outbound network connections. If a VM or service does not need outbound access, then lock it down right away. This will reduce the chances of a machine getting compromised and being able to call back home to its command and control center. Or will prevent the attacker from downloading additional malware.
- Corporate to corporate (site to site) network bridging is a huge issue. Many companies will have a direct connection from their Azure environment to their on prem corporate environment. The issue here is if network controls are not setup well, someone could compromise an external facing Azure device. And, now would have free range access to your on prem corporate environment.
- A good security measure to allow network connections back into your on prem environment is to create a separate subscription for services that need to make use of some IT hybrid systems that are on prem. That way you are limiting the access to internal systems based off a subscription. You could have subscription strictly for systems that never need to communicate back to the corporate environment. And, another that does need to talk back to the corporate environment.
Virtual Machine Security Best Practices
One of the primary uses within Azure is the ability to spin up Virtual Machines. Azure contains many security features that can be used for VM’s.
- For any VM being deployed be sure to setup different types of virtual networks. Make one that is used only to connect to external 3rd parties. Be sure that any need services and ports are exposed only. Also, setup virtual networks for VM’s that will stay within the private Azure environment. This virtual network can be exposed internally, and have another virtual network that is totally segregated off on its own.
- Use the VM Firewall in conjunction with NSG’s as this should also be used to restrict ports and services to those that are ONLY needed.
- Azure provides an option for full disk encryption for VM’s. Utilize full disk encryption. as it will prevent anyone from accessing the VM storage when the VM is offline. The encryption keys are managed by key vault within Azure. Therefore, the onus of managing keys is not placed on a particular individual or having the need to manually manage any keys.
- Make sure Azure monitoring and VM logging is enabled. This way you can gain insight into the activities that are taking place within and on the VM.
Storage Security Best Practices
In Azure, storage accounts are frequently used and will be needed for storing all kinds of data. Therefore, the security controls on them are vital in protecting the data in each storage account.
- One major risk with storage accounts is the use of access keys. Many can be found in code repos, which are then uploaded to a public repo website such as GitHub.
- Make sure your storage account is set to private (unless it needs to be made public). Major issues can occur such as a breach of the data on the storage account if someone accidentally leaves a Blob storage account accessible to the public. Best case be sure to force authentication via RBAC, or at the very least a password.
- Roll or reset access keys on routinely basis. Create a wiki document for each access key, so you know where it is being used. And, in the case you need to reset or change it. You know exactly where to change it when you have created a new key. This will save you during a major incident where access keys have been compromised and you need to change them to contain the breach.
- Enforce, encryption in transit and at rest when accessing and storing data in a storage account. Azure usually defaults to using a secure connection in transit and has the ability to encrypt the storage account data at rest.
- Make sure the HTTPS settings is enabled to allow for a secure connection to be made when uploading or downloading files. This will force https to be used at all times for the connection. The option is called “secure transfer required”.
Key Vault Best practices
Eventually, everyone will resort to making use of key vault. It’s a great feature Azure has to store sensitive secrets and credentials. It is recommended that the key vault is hardened by controlling access to objects in key vault, pre-encrypting secrets and placing in monitoring of all activities.
- One option is to create a separate subscription just for your key vault. This isolates the key vault off on its own and makes it easier to manage than having to figure out individual key vaults in various subscriptions.
- RBAC should be added so only those that need access to the key vault have any sort of access to it. The list of users should be relative short and possibly even restricting it to only the global admins.
- The purpose of pre-encrypting secrets is that if your key vault gets compromised. The attacker is still stuck with encrypted secrets and would need the key to decrypt the actual secret. This key could be stored somewhere else other than the key vault.
- Logging helps with viewing deletions, creations, modifications and access to key vault secrets. It will become very helpful for identifying malicious activity that may be taking or has taken place.
To be continued
Well, that’s all for this post. I plan on having more in a part 2 and 3 and possibly more. If there is something in particular you would like to hear about related to Azure feel free to leave comments below!
My name is Harry Taheem
I am a Cyber Security Engineer.
My aim is to post things I learn or find interesting and allow others to hopefully gain some more insight. I also plan on posting general IT related issues, as I’d like 
This is really helpful. Thank you for sharing this information with us. I have a question on one of the practices you have listed for subscriptions:
– Try to use a separate subscription for each project, such as a Marketing Project X, Finance Project Y, IT Project Z. This way you organize and structure your resources within various subscriptions.
How resource groups and management group would fit here? Can you share an example?
Glad you found it useful Rameez.
So for each subscription you would have different resource groups. There are a few ways you can do this. One example is where you want to segregate them out.
eg. RSG_MarketingServers, RSG_MarketingDatabases etc.. That way they are grouped in their own RSG, but you allow specific access among each group.
The other option is you create all the needed devices in a single RSG for every environment.
eg. MarketingProjectXPROD_RSG, MarketingProjectXQA_RSG.
Then you would set NSG to protect each RG, and set Firewall rules for each device in that RG.
Hope that helps.