This is Dan Conrad from One Identity, and today I'm going to do a quick whiteboarding session on securing privileged remote access. So in my whiteboard here, I have my data center, which is typical of any on-prem data center with systems and applications and operating systems running in it, and that could be a Windows operating system, Unix operating systems, networking devices, all that make up this data center. And then I have my remote administrator.
So through years of system administration, we used to connect into our data centers a long time ago via things like dial-up access, and we would actually dial directly into the data center when all of your traveling laptops had modems in them. Of course, nobody does that anymore. So what we do today is we actually connect via the internet.
So I'm going to connect my remote administrator to the internet via access point, which is typically the way we do it-- we all have our Wi-Fi hotspots at home, or this could be sitting in a coffee shop somewhere connected to the local-- coffee shop's Wi-Fi. Now that Wi-Fi is providing us access to the internet, but the internet is actually providing us access to that data center.
Now the data center is rarely ever connected directly to the internet, so they're going to be traversing a firewall. The firewall is designed to protect the internal IP space from the external IP space and only publish things to that firewall that are required for external use. So that firewall is going to be the part that's actually connected to the internet. Let me go ahead and connect that here.
So as a remote administrator, I need to get from this point to, say, a server in that data center, I need to traverse that firewall and have that controlled. Now publishing the ports that are required to do that is usually not recommended. In the case of a Windows operating system, the ports are going to be port 3389, which is remote desktop protocol-- RDP-- and in the non-Windows environment, which is your Unix platforms and your network devices, that's going to be a secure shell protocol-- SSH-- which runs over port 22. We really never recommend publishing those ports to the internet because there's a lot of vulnerabilities that go along with that, and attackers are constantly looking for ways to exploit those ports.
So what we do is we bring in something like a VPN concentrator or virtual private network. Most of us that work remotely or very familiar with VPNs. We use them to access internal resources-- virtual private network. So it's designed to make it seem like you are working in the building when you're actually remote.
And those are great for things like especially the traveling worker. And the way it works is there's a VPN client running on the system down here, whether it's an in-home office workstation or a traveling laptop, what have you. That VPN client, when you launch that VPN client, it encrypts all the traffic destined for that target network. So all of that would be unreadable to anybody in between, and it's decrypted at the VPN concentrator, and then the VPN makes that connection out to your end systems or applications. So that applies to both users and administrators.
So you can see that it provides a significant level of security traversing the internet. It also provides a level of security based on things like unsecured Wi-Fi. So if you're sitting in a coffee shop somewhere and you're connected to a Wi-Fi, there's really no guarantee of the encryption of that Wi-Fi, and there's no guarantee that that Wi-Fi even is who it says it is.
So somebody may be listening to that traffic off of that Wi-Fi or they may have even stood up a Wi-Fi, something called a rogue-- or an evil twin and be able to mirror somebody else's Wi-Fi and sniff traffic in between, capturing things like authentication and even passwords that are passed in clear text-- hopefully you're not doing that. But it gives them a lot of capability to analyze that traffic. We want to eliminate that. We want to encrypt it at every opportunity that we have, and the VPN provides that.
So once I'm at the VPN, and I can now can launch my remote desktop or my SSH down here and connect out to these end systems. So I've got a auditing mechanism at the VPN, so I know when people are connecting to my VPN because that's going to write an event log and that's going to fire out to my SIM and I'm going to go back and look at that traffic later. Then I'll have events on the end systems that I'm actually connecting to, so I can see when people are connecting and authenticating.
That's really about all I can do from that perspective. Unless there's some level of auditing involved on these other systems, I'm not going to have any capabilities beyond just that. So administrators, when they connect to these VPNs or they come in and they administer the network, they're very familiar with the carte blanche capabilities that they have to launch connections out to end systems and authenticate anywhere they need to.
And this may or may not be a problem in your environment, you might want to think about what that means to you. So what I want to do is show you the opportunity to add a level of trust to that so that I can actually add a layer of security between that VPN and the end systems. The way this would work is this is Safeguard for Privilege Sessions, and this is a sessions management appliance. It's designed specifically to manage sessions between remote administrators or even contractors in this case and give them a secure session to the end system that they need to manage, and give me
09:25
