Least privilege—the idea that each person in your organization 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 your backup system.
The challenge here is that network, system, and backup 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 backup privileges
The idea of least privilege is often ignored in the backup 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 backup system, your backup system admin essentially has all power. They can easily delete an incredible amount of data and delete all of the backups of that data.
And yet backup systems are notoriously and woefully behind security practices in the rest of the world. Many backup 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 backup administrators must have the superuser password to the backup 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 backup admins live in the data center. 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 backup interface as the superuser, they can literally do anything they want. For example, they can create a script on the backup 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 backup software, using its functionality to run prescripts and postscripts for a given backup. 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 backup 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 backup systems should work. But if you are ignoring the security aspects of your backup system, this could be how your backup system works today.
From a security perspective, the most important thing in a backup system is not having to login as a superuser in order to run it. The system should require backup administrators to login as themselves with their own username and password.
If your backup system only has one all-powerful username that controls everything in the backup system, it’s time to get a new backup system. I’m not aware of any major backup product that still works this way, but you may be running an older version that does.
Instead, your backup 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 backups, while another has the ability to configure new backups or delete old backup configurations.
Even more protected should be the ability to delete backups 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 backups 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 backup administrator has, perhaps it’s time to take a look at the security configuration of your system.
Do you have a story that you think would interest our readers? write to us firstname.lastname@example.org