[MUSIC PLAYING] Welcome. This is "Quest Unscripted," a vlog series on trending topics and Quest solutions related to Active Directory, Office 365-- oh, and don't forget, Azure AD. You're here because you have questions. We're here because we have answers, I think. We will address questions we've received from customers experiencing the same challenges as you, all with the goal of helping you confidently move, manage, and secure your Microsoft environment. We call the show "Quest Unscripted" because, except for this intro, nothing we say is scripted or rehearsed. And we're pretty sure you'll notice that right away.
Hey, Brian.
Hey, Bryan. How are you?
Good. First question for you--
Yeah?
Is secure storage and immutable storage the same?
No, actually it's not. So secure storage, for us, is simply a place to store backups that cannot be reached from the network. So we essentially have firewalled a server to the point where it's air gapped.
Air gapped-- why? Why are we doing this?
Well, because the ransomware guys are getting really, really smart. There's a vendor that touts itself as a ransomware proof solution that one of my clients recently had, and the attackers simply learned how to get administrative access to that system. And before they dropped ransomware, they went in and deleted all the backups-- not a very good thing. So--
Yeah, it's becoming more and more common nowadays. So--
Yeah.
With that said, can you describe how we're doing and what we're doing with secure storage to protect our AD backups?
Sure. Absolutely. So the first big thing to know is that secure storage is a secure storage location. And implementation is important at that, but the real thing is that, when those backups are stored, the only way for you to pull them back out is to gain physical access to the server that you set up as secure storage. So why don't I show you on some slides here.
And when you're saying physical access-- so somebody has to physically go to the server or get access, console-level access, to that server to extract it off?
Yes. And we'll talk about some of those details, because those are good questions. So here is my example. I've got my RMAD server and my RMAD console, and then I have a server I want to use for secure storage. So you identify that server first.
And then you tell the RMAD console, and it creates-- well, here, I'll step through a couple of slides here. But it creates this agent that's specific for the server you're going to make your secure storage server. And then you deploy that agent and install it.
And the agent sets up a TLS encrypted port. Sorry, I think I tapped twice-- sets up a TLS encrypted port back at the-- back into itself, so that the console is able to talk. And we use a high-level port. You can pick what you want. I think we use 48001 by default, but you can pick whatever port you want. And then we encrypt that traffic with TLS using a mutually shared key.
Now, the commands that are issued here cannot do anything more-- and I'll talk about the details there. They can't do anything to manipulate the backups that are on the box. But as soon as this connection is established, the server gets hardened.
So you write, but you can't read. Is that right?
Yes, essentially. Yeah, not quite. No, I'm going to take that back, not quite. The secure storage server allows you to read data back out, but the commands that you issue are not allowed to manipulate the backups that are already stored here. And so we'll walk through those details, Brian. It'll make more sense.
So again, only that high-level TLS port is available. Everything else is gone-- no remote desktop, no remote procedure calls. You can't even ping this box, so ICMP is completely shut down. And we kick off any SMB protocols. We actually disable them so that, even if the firewall were to drop, SMB is not enabled on this box. And you can't create a share or access a share.
I'm just assuming this is not a member of the domain whatsoever, right?
Yeah, that's not smart to make it a member of the domain.
Agreed.
Any little bit that you open the door is bad, in our opinion. But the nice thing is you can have as many secure storage servers as you want. So here, I've got two data centers. And you can see I've got one in each data center.
When backups are made, what happens is the RMAD console starts the backup. You can see the commands go to the backup agents. The agents then what they've always done. They store those backups. They create them, and they store them in what I like to call tier one storage.
So that could be on the RMAD server. That could be on some share closer to the DCs. It could be on the DCs themselves. It doesn't really matter where that is, as long as it's an SMB share and we can reach them from secure storage.
And then as soon as those backups are done, the console notifies the storage agents and says, hey, you've got a new backup. Go get it. And so the storage agent then reaches out and pulls that backup in. So you don't have to have the firewall drop to do that. I'm reaching a share that's open on tier one. And I can pull that backup in and then I store it.
Now, storage is done by a number of days, not by a number of copies. And again, the commands that you can issue-- I think I'll just move forward a slide. Those commands that you can issue in this secure notification-- they can only tell the storage agent, hey, you've got a new backup. Go get it.
Retention is taken
09:10