10 Things To Include in Your DR Plan for Your Cloud-Based Workload

When solidifying your disaster recovery plan for your cloud-based workload, don’t leave these things off your list…

Manage Domain Registration Separate From Your DNS Service

Your corporate domain is an incredibly valuable asset.  It’s how your customers find you, how Google knows you, and you likely spent a lot of money on it.

Domain registration is also the root of your DNS setup.  Your registered domain points at the domain name servers that provide authoritative IP addresses for entries under your domain.

If you ever lose control of your DNS – such as a cyber-attack that compromises your DNS setup, or a provider outage that takes down DNS entirely – your last line of defense is to update your domain registration and point it at different DNS servers.  For this reason, you want to ensure that your domain is registered elsewhere, and that your security practices around that registration are flawless.

Manage DNS Separate From Your Production Cloud Environment

We just discussed how important DNS is, but let’s harp on it a bit more.  If your cloud environment were ever compromised, you’d be looking at restoring your service in a different environment.  And you’d want to update DNS to send traffic to that new environment.

But if your cloud environment is compromised, and your DNS is managed in that same environment, will you even have access to it?  Will the attacker use your DNS to send your traffic to their malicious site?

To ensure you don’t lose control of both your DNS and your production environment in the event of a breach, you should manage DNS outside of your production environment.  This is frequently done in a different account with the same cloud provider, but you may also choose to use a different provider entirely.

Store Backups Outside of Your Production Cloud Environment

If your cloud environment is ever compromised, and the attacker intends to do something malicious (i.e. ransomware), they’ll be looking to destroy data backups to undermine your ability to recover.

To protect from this, the best practice is to store your backups “air-gapped” – disconnected from any accessible network – so the attacker can’t access them.  That’s reasonable in a physical environment such as a traditional data center, but in a cloud environment, we have to leverage virtual solutions.

The cloud equivalent to air-gapping is to store your backups in a separate security domain.  The attack vectors that allow an attacker to breach your production environment should not exist there.  This can be accomplished in many ways, but it’s commonly done by copying backups into a second account on the same cloud provider, and ensuring that this account is locked tight.

Ensure Your Recovery Environment is Fully Locked Down

If you have a cyber disaster, you’ll be relying on your recovery environment to restore your service.  You want to make sure that the attacker can’t compromise your recovery environment as well.

To do that, you’ll want to utilize completely different access control for the recovery environment.  And you’ll want to use best practices – like multi-factor authentication – to manage access.

If you use single-sign-on in your corporate environment, though, you probably want to ignore that best practice in your recovery environment.  If your SSO has been compromised along with your production environment, you don’t want it to allow them to compromise your recovery environment as well.

Protect PaaS Encryption Services

If you use a managed encryption key service from your cloud provider, such as AWS’s Key Management Service, you may need to consider how you’ll recover your keys in a different environment in the event of a disaster.  If the disaster is a cyber-attack, you may also have to contend with the attacker eliminating your access to your own encryption keys.  Your data is useless if you can’t decrypt it.

As a best practice, if you’re using PaaS encryption services from your cloud provider, manage your encryption keys in a separate locked-down account.  Share the keys with your production account – and your recovery account – so they can be used, but not deleted or administered by workloads in your production account.

Protect Secret Management Services

Similar to PaaS encryption services, cloud platforms provide managed services for storing passwords, API keys, and other secret material.  If you need to rebuild your environment to recover from a disaster, you will probably need to recover these as well.

Make sure your backup process contemplates capturing these secrets, and storing them in a location where they will be accessible in the event of a disaster.  Obviously, the contents of this data are extremely sensitive, so ensure that you’re using appropriate encryption to protect them.

Mirror Static IP Addresses Before the Disaster

You may have public IP addresses that your business relies upon to deliver service.  This often comes in the form of IP addresses that your business partners trust for receiving traffic from your systems.

In the event of a recovery, you’ll probably lose access to those public IP addresses.  You’ll want to recover your service in a manner that leverages a new set of IP addresses, and that new set will need to be trusted by those same business partners.

This is best achieved in advance of the disaster.  Create a second set of static IP addresses in your recovery environment, and have your business partners start trusting them today, before you actually need them.

Pre-Create SSL Certificates in Your Recovery Environment

There’s not a lot to say on this one.  You’ll need SSL certificates – that match your domain name – in your recovery environment.  And depending on how you manage your certificates, it could take hours to get new ones.  You might as well do that in advance, so you’ve got one less item to deal with during your recovery.

Replicate Quota Increases From Your Production Environment

To manage risks around costs and service availability, cloud providers restrict their customers’ usage of their services through “quotas” or “limits.”  These limits are typically set too low for most production environments, and you’ve likely requested some increases.  Those same limits will be too low for your recovery environment, and you’ll need to request the same increases over there.

Cloud providers will occasionally deny an increase if you haven’t previously hit a given limit in a given environment.  Explain to your provider that this is a disaster recovery environment, and you need the limits to match what you’ve been granted in your production environment.  This will overcome their concern.

Pre-License Software for the Recovery Environment

If your production environment relies on licensed software – oftentimes from a marketplace that your cloud provider operates – your recovery environment will probably rely on the same.  You’ll need to purchase those same licenses in the recovery environment.  In many cases, you won’t even be able to backup the licensed application to a recovery environment where you aren’t also licensing that application.

Luckily, most licensed software in your cloud environment will be billed based on usage.  You won’t have to pay for the software in your recovery environment until you need it.  And you’ll probably be happy to pay for it if that time comes.

Arpio is a leader in automated disaster recovery solutions for Amazon Web Services (AWS) cloud workloads.

Give Us 5 Minutes and We’ll Show You

We’ve got your back with automated cross-region, cross-account recovery for AWS environments. Our interactive product tour shows you how easy it is to set up a complete disaster recovery solution for your AWS workloads. Check it out. https://arpio.io/product-tour/