There are many different strategies that should be used to maintain uptime and availability. In this video, you’ll learn about non-persistence, high availability, the order of restoration, and technological diversity.
<< Previous Video: Backup Types Next: Embedded Systems >>
A cloud-based environment is constantly in motion. We are creating new application instances and tearing down old application instances all the time. We refer to these changes as non-persistence, because it’s very unusual in a cloud-based environment to have any particular service, that’s always going to be permanent. If we’re creating an application instance for a short period of time, and we want to tear that application instance down, we may want to recover it later and continue using that service.
We can take a snapshot of that application instance and capture the current configuration, or the configuration and all of the files that we’ve changed on that instance. Later on, if we’d like to recreate that instance, we can use the snapshot to be able to restore from where we left off. If we take multiple snapshots of that application instance, then we have different versions that we may be able to revert to.
This is especially useful if we install a new version of software and realize there’s an issue we could easily revert to one of those previous snapshots. We can also separate out the data from the configurations. If we make a change to this instance, and we realize that the data is OK, but the configuration needs to be modified, we could roll back the configuration of the application but leave all of the data in place.
Based on the way the application is written, we may have many options available for reverting back to previous snapshots. And some systems will even allow us to have everything on a single boot media, so we could plug-in a USB drive or an optical disk and be able to launch an entire system all from this single boot drive. If you’re creating redundancy in an environment, this means that you have options should there be some type of failure.
But that doesn’t always mean that these options will provide immediate availability or maintain uptime. Sometimes this means that we’ll have to go to a specific machine and power it on to be able to take advantage of this redundancy. But some redundancy is immediately available. In the case of high availability, you may be able to have devices that are always on and always available. And if the primary system fails you have immediate accessibility and can maintain the uptime and availability of that application.
This also means that you might have multiple components working together. There might be multiple firewalls that interact with multiple routers, which are then connected to multiple switches, and if any one of those happens to fail, your system still remains up and running using this high availability. And as it sounds, this high availability does come with a cost.
If you need to have high availability of firewalls, that usually means that you’re going to need multiple firewalls in place, which means you’re going to need to buy two of those to be able to implement some type of HA configuration. And there is always some type of additional contingency that could be created. It could be multiple firewalls, then you might need multiple routers. And then you might need multiple switches, which then might lead you to multiple power systems, which might require you to have multiple internet providers, and so on.
You can always increase the amount of high availability, but that’s also going to increase the amount of costs associated with that implementation. If you’re in a situation where you have to rebuild an application instance, you need to make sure that you perform that restoration in the correct order. The different application components will probably need to be restored in a very particular order. For example, there may be a database that’s at the core of this application.
And all of the components that use this application instance will access this single database. That means that you will need to restore the database before anything else is restored, because that is going to be a key component of getting this application up and running. We also have to consider how the original backups were made.
For example, if you took incremental backups, and you need to perform a restoration, you will need the last full backup and then all of the incremental backups that have been made since that time frame. But if you had a differential backup, when you perform that restore, you will only need the last full backup and the last differential backup. And one key to providing uptime and availability is to have diversity of technology.
For example, a zero-day vulnerability might cause an outage with a particular operating system. But if you’re running different operating systems, you may still be able to provide uptime and availability, because that zero-day attack is only going to affect a subset of your services. Some organizations might implement this diversity of technology by using different types of security components.
So they might not only have a firewall, but also might implement an IPS, and they might also have a separate spam filter. You can even add on to this a diversity of vendors, so that your firewall is from one vendor, your IPS from a separate vendor, and the spam filter from yet a third vendor. This means not only are you using different technologies from different manufacturers, but now you have some flexibility during the purchase process and during the renewal process.
This might also help if you need technical support, because you’re not relying on any single vendor to provide you with those support services. We can also be diverse with our cryptography. And if you think about it, the cryptography we’re using today is only temporary. Eventually the capabilities we have to be able to brute force our current key sizes is going to be surpassed by the power of the CPUs we have in the future.
So we will eventually be providing upgraded cryptography as the years go on. We could also incorporate cryptographic diversity today by using different certificate authorities. That way, if one happens to be breached, we still have other components that were from a completely different certificate authority. And from a security control perspective, diversity is incredibly important.
We might have, of course, administrative controls that determine what security policies we’re going to use. We would then combine that with physical controls that might be locks on a door and prevent people access to a particular area, and we’ll combine that with technical controls that require someone to authenticate and provide access to the file system itself. All of these are combined together to create the diversity of security controls.
And that provides us with defense in depth, which is a much better security philosophy than using only one of those security controls.