Credit: Dreamstime
Least privilege—the idea that each person in your organisation should have the least number of privileges they need in order to accomplish a given task—is an important security concept that needs to be implemented in back-up systems.
The challenge here is that network, system, and back-up admins all wield an incredible amount of power. If one of them makes a mistake, or worse, intentionally tries to do the company harm, limiting the amount of power they have reduces the amount of damage they can inflict.
For example, you might give one network administrator the ability to monitor networks, and another one the ability to create and/or reconfigure networks. Security admins might be responsible for creating and maintaining network-administration users without getting any of those privileges themselves.
System administrators do this by limiting who can login as root or administrator and requiring tools such as “run as administrator,” or sudo, both of which can give admins the privileges they need when they need them, while creating an audit log of what they did.
Like a lot of things in the security world, enacting least privilege is not easy. It may limit the number of products that you can use, as you can only use those that support the concept. It will also require much more configuration than simply giving everybody superpowers. But we have long since passed the time when you can have people with unrestricted superpowers in your environment.
Restrict back-up privileges
The idea of least privilege is often ignored in the back-up space, where a person with superpowers can actually do an incredible amount of damage with just a few keystrokes. If you do not purposefully enact least privilege in your back-up system, your back-up system admin essentially has all power. They can easily delete an incredible amount of data and delete all of the back-ups of that data.
And yet back-up systems are notoriously and woefully behind security practices in the rest of the world. Many back-up systems are simply unable to support the concept of least privilege, which means there are probably thousands of companies not following the practice.
This means back-up administrators must have the superuser password to the back-up server. This superuser is either root, administrator, or another user with the same privileges that can login directly as that superuser and there would be no record that they were ever there. This is often restricted to the physical console, but back-up admins live in the data centre. That’s really not a limitation for them.
Even if they are required to use something like sudo to become the superuser, once they are running the back-up interface as the superuser, they can literally do anything they want.
For example, they can create a script on the back-up system that does whatever they want it to do, back it up, and restore it to a system they want to exploit. Then they can run that script as the superuser via the back-up software, using its functionality to run prescripts and postscripts for a given back-up. They can make the script do anything they want it to do, run it with no accountability, then have the it delete itself and any evidence that it ever ran.
The only protection against nefarious activities would be outside the back-up system itself. For example, limiting who can login as root or administrator, and requiring sudo. But each of these systems can be circumvented.
This is not how system administration should work, and this is definitely not how back-up systems should work. But if you are ignoring the security aspects of your back-up system, this could be how your back-up system works today.
Role-based administration
From a security perspective, the most important thing in a back-up system is not having to login as a superuser in order to run it. The system should require back-up administrators to login as themselves with their own username and password.
If your back-up system only has one all-powerful username that controls everything in the back-up system, it’s time to get a new back-up system. I’m not aware of any major back-up product that still works this way, but you may be running an older version that does.
Instead, your back-up system should support role-based administration, where you assign each user various roles or powers. Very similar to the network and system administration discussed above, one person might have the ability to run and monitor back-ups, while another has the ability to configure new back-ups or delete old back-up configurations.
Even more protected should be the ability to delete back-ups prior to their assigned retention period. The best-case scenario would be that any destructive activities would require two-person authentication.
For example, if you wish to delete any back-ups prior to their assigned retention period, two people would need to login to allow that action. I would actually like to see the concept of two-person authentication integrated into a lot of places where deletion is a part of the activities.
If this article scared you to death, that was its purpose. Now that you understand just how much power a back-up administrator has, perhaps it’s time to take a look at the security configuration of your system.
