I'm in the processing of rolling out McAfee Endpoint Encryption and I'm intending to to encrypt most of the servers on the network as well but not the server with Object Directory, obviously. I've dropped SafeBoot onto a test server and everything seemed fine and dandy but I'm being told that SafeBoot and servers don't mix, especially where RAID arrays are concerned. Is this right? Or is it, as I suspect, a load of old tosh?
The problem is really when things go wrong - if you break a standard drive, we have 20 years of experience in recovering the data from it.
However, if you break a raid array on an EFI bios server, I don't have a clue where to start.
In theory a hardware raid array presents itself as a single volume to the machine, so (again in theory) all the standard diagnostic tools should work fine. But, what happens if the array isn't supported at BIOS level, if it requires windows drivers etc? Then there's no way we can run the toolkit on it.
So, officially no, we don't support RAID - this is clearly spelt out in the release notes. However, we do have many customers encrypting servers successfully, but not holding us to any SLA's if things go wrong.
Can you share why you want to encrypt the servers at disk level? Do you have a problem with people stealing drives from them?
Thanks for the quick response. These are serious servers using proper, hardware RAID controllers that are supported in the BIOS. They don't require windows drivers just to make the arrays visible - I'm not that crazy 🙂
As to why I want to encrypt the server drives it's simply because users will be saving files to them. I don't have the problem of people stealing drives - nicking entire servers is not unheard of though. And the files on these server may contain highly confidential data, so I want to encrypt the drives.
I'm working on the principle of "If it stores data, encrypt it! It's the only way to be sure". happy
I used to support servers remotely when they were the size of refrigerators. One day one server went offline, I tried for an hour to get it to respond, then eventually called the local security guard and asked him to power cycle it for me.
He came back about 10 min's later to remind me that the server had been collected for repair earlier in the day, and thus was not going to respond until it was returned and reinstalled.
It was "collected" by an engineer who had been fired earlier that week for stealing parts.
And your management supports your effort to encrypt these servers? How will you handle Patch Tuesday with all your servers encrypted? When they reboot, they'll be sitting at the SB login with no network connectivity (yeah, sure... if you have a card for network console access). If you enable AutoBoot, then what is the point of encrypting?
I think you should do a sanity check before you get too excited about encrypting the world. Do you only have Windows servers storing data? Do your backups also go to these same servers? If so, then your SB server backups would be stored in an encrypted machine. In the event of a problem, you basically locked the keys in the car (or in this case a bunker). If your domain controllers can't boot, you can't login to the SB server to issue codes.
If you are talking about a specific set of servers (remote file servers) and not all core services servers, then it may be worth the effort. Encryption doesn't solve all problems. If data loss is a concern, you're going to have to use a form of Content Encryption too to prevent loss over network or removable media. Just make sure you think several moves ahead before your adversaries call checkmate.