This brief guide on security is not exhaustive, but investigates common security pitfalls on Azure VMs.

You still need a backup solution

Having your machines in the cloud does not mean that you can compromise on a resilient backup solution. Azure offers a suite of recovery services that you may want to use.

If it does not need internet access, do not give it internet access

All machines provisioned via the portal come preconfigured with a public IP address, you may however want to consider removing this public IP.

You can still access your VMs via a so-called “jump box”, a machine that has internet access and is used simply as a connector between you and your VMs.

NSGs are very powerful

NSGs or network security groups allow you to flexibly allow and restrict connections from certain sources. You can couple NSGs with network interfaces or entire subnets.

If you are hosting a website – for instance – you can make sure that only traffic via port 80 or 443 is allowed and only to the machine that hosts, the web front end.

More about NSGs:

Load balancers can help too

You can create an Azure Load Balancer in front of a VM or a pool of VMs. This allows you to configure an access control list.

Know when an attack happens

Make sure firewall logging is set up on any “high risk” machines in your infrastructure.

Firewall logging is not enabled by default.

On Windows:
On Linux: (for example)

Consider configuring Azure Security Center…
…and alert rules for unusual amounts of traffic

Make sure the operating systems you are using are up to date

Configure automatic updates, or schedule regular maintenance windows to run updates.

Use secure credentials

Both the Linux “root” user and the Windows “Administrator” are disabled by default in all Azure images for security reasons.

When creating user accounts, you should make sure that you use secure passwords and that you change them regularly.

On Linux, the use of SSH key pairs is recommended over the use of passwords. (especially in production environments)