I’m reversing a long-standing position of mine, and people who know me know I don’t do that sort of thing very often. (My wife would tell you I never do.) Typical backup software installs an agent on each system to be protected. Agentless backup gets the job done without installing agents, choosing instead to log in to each server each time it does a backup. I’ve never liked this for security reasons, but someone has finally described to me an agentless setup that is just as secure (if not more secure) than the typical agent-based approach. Click Read More to find out which one.
Asigra has been touting their agentless backup system for many years. Agents, they say, have issues. I would agree that in most cases, with most backup products, the problems they describe are spot on:
- Installing the agent is often difficult. I could go into details, but no one who has installed agents at a large site would disagree with that. Even when it’s automated it’s usually a pain.
- Maintaining and upgrading it to the latest version is usually manual. Some products, like NetBackup, use their own protocol to update their clients, so the upgrade process is pretty smooth. With most products, the upgrade is as difficult as the install.
- The agent is listening on a port just waiting to be hacked, and the hacker can try to hack dozens or even hundreds of servers — often without being detected. The more clients you have, the more attack points he/she has.
If a backup system is agentless, it has to use traditional login techniques to log into the server it’s going to back up. It needs an account with sufficient privileges to access the data. (Usually this means it’s going to be in the Administrator group in Windows, or have a UID of 0 in Unix, but if you’re only going to back up Curtis’ files, you only need an account that can access that data.)
My concerns with this method are around security:
- I tell people not to give the backup admin root/Administrator on their systems. They don’t need it to get their job done.
- If I have to create an account that is essentially root/Administrator, and have the backup person configure the backup system using the password for that account, we just did exactly what I told people not to do.
- Then there is the password change issue. Many companies require changing passwords (especially root/Admin level accounts) every 30 or 90 days. If change the password for this privileged account and the backup system has the old one, now the backup system can’t log in and backups fail. Gee THAT sounds easy to manage.
I’m aware that agent-based and agent-less backup software products alike have issues about an all-powerful system that can access any file or run any command they choose. The backup system is the single most powerful system in the data center from that respect. But that’s still not as bad as giving the backup person the root/Administrator password.
I’ve told Asigra my concerns about agent-less backup for a long time, and said that they were a pretty big deal for me. I like backup, but security is just as important. I’m not sure if they just recently added the features I’m going to describe below, or if Eran Farajun just thought he had enough sales without my blessings, but they finally got someone on the phone today that explained to me why their implementation of agentless backup doesn’t have the issues I described.
Andy was his name, and I hope Erun gives him a raise. He was a technical guy who never answered a question with “Yes.” If I said, “Do you backup Oracle?” He would say something like, “We backup Oracle on Solaris, HP-UX, Windows, and Linux using RMAN. After performing an initial full, we perform block level incrementals forever, while giving you the benefits of a full. We do this and we do that, and here’s an example of the machine code that we use to detect….” Five minutes later, I’d say, “So that’s a Yes, then?” I LOVED it. So many times I’m talking to backup companies and they’ve got the marketing guy there who can’t spell daemon, let alone tell me if they have one. (You know, there are 10 types of people in this world. Those who understand binary and those who don’t.)
Anyway, on to what Andy said. They specifically designed Asigra’s product to address the needs of service providers who were going to back up other people’s data — just the type of people who don’t want to give you their password. So how do they do it, then?
- The customer whose machine you’re going to back up runs a small utility they have that generates a file. This file contains an encrypted form of the username and password of the account that they’re going to use. He gives the output of this tool to the backup admin who then feeds it into the Asigra product.
- Without letting the backup admin ever see the account or password, the Asigra product (actually, the dsclient) now has the username and password, and stores it in its encrypted database.
- To address the revolving password requirement, you can actually set it to do that automatically. It can change the password every 30, 90, or however many days you require. It changes it to a random password that only it knows, and again stores that in the password database in encrypted format.
- We then went through a long, involved discussion of how the encrypted password is stored and protected, and the multiple levels of encryption you’d have to hack through to ever get to that password. Let’s just say my head was spinning trying to think of a way to hack into it. They tell me that they’re actually working on a FIPS certification, but I’ll let them talk about that when it’s real.
It’s… like… they… addressed… all… of… my… concerns. To summarize:
- The admin never sees, nor can they access, the privileged account or password.
- The password can automatically be changed to deal with revolving password requirements.
- You can’t hack into the password database to steal it.
- By doing this, it doesn’t have the aforementioned downsides of an agentless based architecture.
Now what have I got to complain about? I know! I heard that when you restore something with Asigra, all the filenames are appended with an “, eh?” (In case the reader is unaware, Erun and his company are from Toronto, eh?)
Erun. Good job on changing my mind, eh?
----- Signature and Disclaimer -----
Written by W. Curtis Preston (@wcpreston). For those of you unfamiliar with my work, I've specialized in backup & recovery since 1993. I've written the O'Reilly books on backup and have worked with a number of native and commercial tools. I am now Chief Technical Architect at Druva, the leading provider of cloud-based data protection and data management tools for endpoints, infrastructure, and cloud applications. These posts reflect my own opinion and are not necessarily the opinion of my employer.