Is Azure Backup as good as offline backup?

I am posing this question, not just for Azure Backup, but any cloud-based backup. Here’s the question:

Is Azure Backup (or any cloud-based backup for that matter) as good as having an offline backup?

The Benefits of Azure / Cloud Backup

Certainly one of the biggest benefits of a cloud-based backup is that it is offsite. Usually encryption is available with the cloud providers (like Azure), so the backup is secured with a private key, before it ever leaves your network. Last, the solution is automated, meaning there is no human intervention required, and notification capability is usually built-in (again, as it is with Azure). These are all markers of a solid backup solution over all–I would even say they are mandatory.

But, what about offline? Isn’t offline backup a critical consideration these days, especially with the evolution of modern malware–worms and the like? The best solutions are actually comprised of more than one backup, and usually one of those backups is either offsite, offline, or both.

Offline means air-gapped, in other words, no wires connecting the media back to the fabric of your network (or any other). Most backups used to be this way by default (tapes that could be taken offsite and so forth). Most modern backups are now on done on disk (like a NAS for example), or written to the cloud.

Azure Backup, and other clouds like it, are online. They are always online, and accessible, by their very design and nature. So definitely not air-gapped. But the question is whether they are “as good.”  Why do we pose this question?

How Azure Backup credentials work

Before you configure Azure Backup, or many other cloud backups, you typically have to provision some kind of storage container up in the cloud, to which your backup data will be written. You probably have a set of admin credentials to sign into a cloud portal, such as the Azure Portal, and create a vault, such as Microsoft’s Azure Recovery Services vault.

However, when you go to configure your backup on the server(s) themselves, you will find that you need to download a separate set of “credentials” in the form of a small file. This file is your “key” to associate the server with that vault. And that “key” is not the same as your administrative credentials for signing into the Azure Portal.

In fact, the key does not grant your server the capability of deleting backups!! The easiest way to demonstrate this, is to see how one would go about turning off the Azure Backup functionality.

How to remove Azure Backup

Let’s say I was an advanced piece of malware on your network, or an actual human attacker. If I wanted to do damage or put you in a tight spot, and hold your data for ransom, I would probably start by attacking your backups.

If you were smart and setup notifications in the Azure Portal, then you will be notified when this happens:

Oh no! My backup was deleted. Reading further, I see that I have 14 days to re-enable protection, and keep the data:

Okay, so I have a chance to recover from this, assuming the attacker does not also intercept or remove this message from my mailbox (and he or she might).  But wait, how did we even get to this point in the first place?!

In order to delete data from the Azure Portal I cannot simply effect this change from my Azure backup-enabled on-premises systems. Let’s see what happens when I attempt this from an on-premise server that is under protection:

From the Azure Backup console, click Schedule Backup, and find the option to Stop using this backup schedule and delete all of the stored backups.

If I click Next and attempt to Finish the wizard, I am prompted for… you guessed it, a security PIN that can only be generated by an admin in the Azure Portal.

Remember, the software only has that vault credential for writing backup data in, and it does NOT have permission to delete or destroy data, without further human administrative intervention.

Considerations for optimal protection

Most security gurus will sneer at this: “So what?” They might say.  All the attacker needs is your admin credentials to Azure portal. Done. This was a stupid question, and you just posted it to get clicks.

All true enough. But pressing on, here is what I would do to hedge my bets, so to speak:

1. I would have my Azure portal account be a cloud-only user (i.e. not synchronized from the local Active Directory) with a completely different password than any on-premises administrative account
2. I would enable multifactor authentication for this account so the attacker would need: access to the server, access to my Azure password, and access to my mobile device, for example
3. I would have notifications turned ON so that I am alerted when there are strange things happening with the backup

None of these on their own are perfect, but together, I would wager a guess that they severely increase your likelihood of surviving an attack.

Summary

So is Azure cloud-based backup as good as offline backup? Well, is anything?

But seriously, offline has it’s drawbacks, too. Usually offline means you are relying on a human being to remember to do something every day, or every week, or whatever your acceptable RPO is–they have to change out tapes, swap a NAS to bring offsite, rotate drives, or whatever the case may be. And there is still plenty of risk in that as well.

How is backup media stored/transported? Is it encrypted? How reliable is the media? How reliable is the human? And so on.

Don’t get me wrong: if I could have both offsite to the cloud, and offline, I would. But in the absence of both, I’d have to settle for just one. Which would you pick?