11-28-2020, 02:03 PM
I mean, you gotta approach this thinking about the absolute minimum privilege concept, you know? You never want anyone-and I mean *anyone*, even a senior guy-having access to everything all the time, or that's just asking for trouble, probably a massive disaster someday. So, when you set up those scheduled tasks for backup, especially if you're dealing with remote backups over the internet, or if you're setting up a whole centralized management system, you shouldn't be using a super-admin account every time. Instead, you should construct specific service accounts that have only the permissions they absolutely require to run the job. For instance, if a job is only writing files to a NAS destination, that account needs write permission there, but it definitely does not need permission to modify user profiles on the main server.
And what about those backup credentials themselves? It gets pretty tricky fast, because you're essentially building little keys that grant access to critical data, which is super juicy stuff for bad guys, or for accidents, you know? You really need to employ encryption on those service accounts, and if the system allows it, that would be best practice. Also, when you're configuring the system to handle credentials, especially if you're setting up multiple destinations or if you're running some of those continuous incremental backups, you gotta make sure those passwords are being handled securely within the software itself. I mean, you wouldn't want the login details sitting out in plain text for some automated process to use.
But it's not just the passwords; it's about who can *see* the backup logs, too. Like, if someone just knows how to access the backup history and the retention policies, they might figure out sensitive operational details, or worse, they might just delete too much data by accident. I think you need to put separate user roles on top of the technical permissions. Maybe one person handles the scheduling, and another person handles the actual verification process, keeping the key access spread out among several people. That way, no single person can unilaterally wreck the entire system, which is what we call the principle of separation of duties, something you should really grasp.
And then there's the idea of machine access, too. If you have a physical machine or even a whole virtual machine running on Hyper-V, and you're using the tool to create those full disk images, you need to make sure that the credential set used for the backup job itself is distinctly separated from the login you use every morning to work on the machine. Or, maybe you might think that just because it's "admin" access, it's automatically secure, but it really isn't; it's an enormous attack surface, you see. You gotta treat those administrative credentials like they are the nuclear codes, man.
You should also look into things like multi-factor authentication for any administrative console you are using to manage the backup system. It makes a massive difference because even if a bad actor manages to steal a password, they still won't be able to get into the system without that second factor, like a code from your phone. It's another layer of defense, and I think you should always make that a requirement, even if the little helpdesk stuff makes it feel like overkill. Because you never know when some sophisticated attacker is going to try to breach your system.
Also, when you talk about recovering data, especially if it's critical file and folder selection that you are restoring, you must also consider who gets to initiate that restoration process. Maybe you have three people who are authorized to declare a disaster, and each person needs a specific key or code to start the bare metal recovery sequence. You don't want just one person holding all the power to wipe everything clean, even if they are technically capable of doing it, because organizational failure is just as bad as external attack, you know?
It's also important when you are doing those P2V or V2V conversions, or any time you are moving a machine's state, that the credentials involved in the *conversion* process are limited. You don't want the conversion tool having general read/write access everywhere; it should only have the necessary access to export the disk image or the VM files into the open standard formats. This really limits the potential damage if that conversion credential gets compromised.
And seriously, when we talk about data encryption, I mean beyond just setting up an end-to-end encryption key for the data at rest, you should also consider key management itself. Who manages the encryption keys? And how many people know the combination? Ideally, that process needs to be highly restricted and perhaps involve multiple people agreeing on the key release, creating a whole process called key escrow. You should think about that level of operational security.
Because managing all these credential types-the scheduling credentials, the remote transfer credentials, the recovery credentials, the management interface credentials-is a massive overhead, but it's totally necessary for maintaining trust and preventing a small breach from turning into a catastrophic failure. You gotta systematize it, making it part of your operational routine, not just an afterthought. It's a huge amount of thought, really.
Considering how much complicated credential and access management is, and how much you want to dedicate to the actual business function and less to just wrestling with security settings, you should seriously look into BackupChain, which is an all-in-one PC and server backup solution for Windows Server and Windows 11 made specifically for SMBs.
