Secure remote connectivity to AWS

Tom Adamski: All right. Hey folks. Can you hear me? Awesome. Welcome to Secure Remote Connectivity on AWS. My name is Tom Adamski. I'm a Principal Solutions Architect and I focus on anything to do with networking. Uh I'm joined today by Shahan Das. He's a Principal Product Manager uh focusing on AWS connectivity solutions, remote connectivity solutions. And our guest, Juan Suarez from Avalon Healthcare Solutions is gonna talk about their specific use case.

Before we dive into the agenda, I want to set the scene with differentiation between corporate connectivity and remote connectivity. When we're talking about corporate connectivity, we often think about connecting through different networks, whether their own premise, data centers, uh uh uh branches through things like VPN and PLS fiber connectivity. And then on the other side of that equation, we have remote connectivity. That's where we have a user somewhere out on the internet. And we need to give them access to our private resources, either a private network or specific applications within our network. So the right hand side is what we'll be focusing on today for the rest of the session.

On the agenda, we'll talk about remote access considerations. So what you should think about when you're deciding on the remote access solution and then we'll talk about different use cases. We're going to talk about a network use case when you're giving access to a whole network and then uh application access use cases split into SSH RDP as well as HTTP S and with the HTPS one, we'll have an example uh customer story from one, right?

So what do you need to consider when you're deciding on a remote access connectivity solution? So first of all, you need to figure out what resources you're giving access to where those resources live, you also need to figure out what level of trust and validation do you require for your users accessing those resources? And then finally, how do you audit access? You need to audit every single request or is it enough to audit just the fact that someone access the network? And this is just the tip of the iceberg. There's many other things that you might need to consider and things that can help you figure out what you need to consider are cybersecurity frameworks. So things like NISO 27 001 CIS so all of those frameworks would have some guidance on running a risk assessments and figuring out the risks within your environment and what you're concerned about and then giving you some kind of mitigation plan and you can use that mitigation plan to decide on your connectivity solutions.

Now already mentioned, we're going to have these two different use cases, network access and application layer access. And I want to explain what that means. And for that, I'm going to use a TCP/IP model. If you're familiar with networking, you're probably familiar with this model as well as with the a little bit more complicated OSI model with seven layers. This is a simpler version of that. And we use this model to figure out the different layers that are participating in forwarding network traffic between nodes within our environment.

So from the bottom we have network access layer, this is physical connectivity fiber and then the protocols running on top like Ethernet, then we have the network layer. That's the IP address layer where we have IPv4 IPv6 addresses. On top of that, we didn't have TCP, setting up our connections as well as UDP. And then finally, the actual application that's being forwarded over the network. So HTTP FTP, SSH and so on. And today the two different use cases are going to be network access. So giving access to remote user to effectively OIP addresses and then separate use cases around application or access. So granular access to a particular application.

And if we divide some of the AWS services that we have into those categories for network level access, we're going to talk about AWS Client VPN for the application use case with SSH and RDP. We'll talk about Amazon EC2 Instance Connect as well as Session Manager, which is part of Systems Manager. And then for application layer, we talk about Verified Access AWI is Verified Access AVA, right?

So let's start with network layer access. So for that, we're going to talk about Client VPN, which is a managed remote access solution from AWS that allows you to uh automatically scale with your demand. You don't have to deploy your own remote access services. Everything is managed for you. Uh you have the ability to apply granular controls for that access. But just remember that this is a network access solution. So those controls will be based around IP addresses. And then finally, something that applies to all of the services. We're going to talk about the fact that you can access your resources from anywhere and with Client VPN, because it's a network level access, you can pretty much access any resources on that network.

Alright, let's do some architectures. So we'll start with a high level overview, high level architecture and then we'll start breaking down each component separately. So at a high level, we have a region here in AWS region inside up, we have your private environment, a VPC. And inside that VPC, we have some kind of resource. This could be an EC2 instance, your virtual machine, this could be a database, this could be a load balancer, this could be a container. It really doesn't matter as long as it has an IP address it applies.

And then if we want to allow our remote user to have access to those resources, we need to provision an AWS Client VPN endpoint and then associate that endpoint with our VPC. We then have to make sure that the user has appropriate software on the machine to be able to establish a TLS connection to the Client VPN endpoint. At which point we'll do authentication and authorization to validate if the user is permitted to access the resources that are going to and then if they're permitted, we'll pass the traffic along to the destination.

Ok. So let's zoom into some of these components. So let's start with the remote user already mentioned. The remote user has to run a Client VPN software and AWS provides you with that software that you can install on Windows Mac and Linux machine. You can also use open source OpenVPN software to establish a VPN, but it will have limited functionality. So check out the documentation what the differences are.

And then from a connectivity point of view, Client VPN supports both full tunnel as well as split tunnel. So with full tunnel, what we're saying is any traffic to any destination should go over the tunnel first, regardless of where it's going with a split tunnel, we're defining a specific IP address block that should go over the TLS tunnel and everything else, connectivity to other destinations will just use the remote user's local network connectivity.

Now, if you have multiple users connecting at the same time, same time, there's also an option to enable client to client flow directly without you having to go through the VPC. So that's a fairly recent feature as well.

Ok. Let's zoom in on the authentication and authorization now and all of the options I'm gonna mention they're interchangeable. So you can decide which options you're gonna use and we'll start off with uh mutual TLS. So you can provide a client certificate to your remote user. As long as that certificate is valid. Uh the Client VPN will authenticate the user. You can use it on its own or you can combine it with other authentication methods. So you can use Active Directory or IAM to make your policy decisions.

And then with those two options, Active Directory and IAM that's where you have those granular authorization rules where you can say if the user is part of a particular group. In my example, here, it's engineering group. They're going to be allowed to get to a particular destination and the destination here is just an individual IP address, but this could be a whole network.

An additional function that Client VPN has is Lambda connection handler. And it's a very interesting feature. Lambda is a serverless environment where you can bring your own code and you can integrate that with Client VPN endpoint. So after the user authenticates, we will send a bunch of information to a predefined Lambda function that you control and you can do whatever you want with that information.

So here's an example of what uh the Lambda would see. And uh you could, for example, pull out the public IP address of the remote user and then check that against a geo database to see what country that user is coming from and then still block that user even if they successfully authenticate it. So it's like an extra gate that you can optionally add to your Client VPN.

Ok. Let's look at the final piece. So Client VPN endpoint association with the uh with the VPC. And we do recommend that you associate it with more than one Availability Zone for high availability. And the way the association happens is that you decide on which subnets you're going to associate with. And in those subnets, the Client VPN will provision Elastic Network Interfaces. EI think about them as just virtual NICs. And then all the traffic that's coming from the remote users, regardless of what IP address you assigned to those remote users will be source address, nted, effectively translated to the IP address of those network interfaces.

A side benefit of that is now you can have a security group, Security Group B in this example, wrapped around those network interfaces and then you can reference that security group on resources already in the VPC. So on my Security Group A, I'm saying I'm allowing HTTP traffic, but only from my Security Group B which would identify any traffic coming in from the Client VPN endpoint.

Another benefit of doing the NATing is that we can get the traffic to any destination as long as we can route to that destination. So not just the local VPC, but we can connect to a bunch of other destinations for other networking constructs. So other VPCs through Transit Gateway, Cloud One peering connection, as well as Private Link endpoints, we can also connect the resources on premise. So we can connect to your corporate data center as long as there's a network connectivity for something like site to site VPN or Direct Connect. Uh or even allow connectivity to the internet.

And if you want, you can deploy an additional firewall in the path. So I'm showing an example with AWS Network Firewall, but you can also use third party vendors deploy them in the path and then traffic going to those different destinations can be inspected before getting there.

Um and there's a different and there's an arrow missing over the period connection on purpose. That's something that's not supported.

Alright, from a logging perspective, Client VPN allows you to log information to CloudWatch. And if we have a look at an example of a log entry, uh it actually looks very similar to the information we're sending to that Lambda connection handler. So it's gonna have a lot of information about the user connecting. This is an example of a failure, someone failed to connect uh because the uh the authentication failed.

Ok. So moving on to application so more granular connectivity to where you're actually accessing a specific application layer rather than just giving access to the network. And we're going to start with SSH and RDP and I had to select one of the two, we didn't have enough time to cover both. So I picked SSH. Um just assume that RDP is also supported. Um and we can chat afterwards if you uh if you want to dive deeper into the RDP side.

Ok. So you might have seen this before. Uh when you connect to an instance in the console, uh you would see the screen telling you that there's a bunch of different options that you have to connect to your EC2 instance and we'll talk about all the first three. I again, didn't have enough time to talk about the EC2 Serial Console, but just know that this is an out of bound access to your EC2 instance. So even if you lock yourself out, you mess up security groups, knuckles, whatever you can't get to the instance anymore. For some reason, you can always use EC2 Serial Console as a out of bound backup access. Ok?

So we'll start off with the basics. We'll go over how SSH access looks like we'll talk about some of the challenges for SSH access. And then how those challenges might be solved by uh the two solutions we have.

So here we have an instance and a remote user that we need to SSH to our instance. So there's a number of things we need to do to make this work. Uh first of all, we have to assign a public IP address or Elastic IP address. For instance, we need to create an internet gateway that allows access to and from the internet. Uh we also have to set up routing. I'm not showing you the route tables, but just know that the route tables are there and you have to make sure they're correct.

And then we have to have a security group around our instance allowing traffic uh on over SSH from a particular IP address. So I'm saying here from the remote user as long as we know the IP address of the remote user. But if we don't know what that is, we might have to allow it from anywhere on the internet. And then SSH uses PKI. So there's going to be a private and public key that have to be a pair, private key is always hidden and the user only knows about it. Public key would go on to the instance. And as long as they match, uh the user will be able to establish the SSH session.

So here's an example access, the user will run an SSH command specify the private key that's been assigned to them, specify their user name and then the IP address of the destination instance they're connecting to. And if all is good, we'll be able to set up an SSH session to our destination.

So what are some of the challenges with this? First of all, the public and private key management, I've shown you a single user, single instance that's single keeper. Imagine you have hundreds of users, hundreds of instances. You have a constant management of those public and private keys. And on top of that, you should be rotating them on a regular basis. So actually the rotation piece, that's actually the hardest part of all of it.

Uh second of all, you have to set up a public path to and from the internet. So maybe you want your VPC to be completely isolated but to make SSH work, you have to have an internet gateway, you have to have a public IP address. And then from a security group perspective, you have to have that security group allowing traffic potentially from anywhere in the world.

So we're gonna have a look at two solutions. Amazon EC2 Instance Connect. Uh and then uh part of Systems Manager, Sessions Manager.

Ok. We'll start with EC2 Instance Connect and there's always going to be two options, one with an internet gateway. And then we also have an option without an internet gateway.

I'm gonna start on the one with internet gateway. So bare bones e two instance connect. Uh we still have an EC2 instance, we still have elastic IP address. We still have an internet gateway and we still have a security group that allows access from uh the remote user now. But this time instead of talking directly to the EC two instance, we're going to use the EC two instance connect service and that will talk to our instance over the public internet. And then the user is going to talk to our EC two instance connect service.

So the user will be using AWS C. So you wouldn't be using your SSH agent, you'd be using a WC to run two instance, connect commands. And you're saying here that you want to SSH into this particular instance ID now because it's using a WC, we have the ability to check if you have the appropriate policy to be able to connect to that instance. So there's a way for us to validate using identity and access management outside of the US if you're actually permitted to do this SSH connection.

And then on the fly, if you're permitted, we're going to generate temporary public and private keys. So you no longer have to worry about management of those public and private keys. They're going to be generated on the fly and they're only going to be temporary temporary. Again, if everything works correctly, the user will be able to set up a session using TLS actually if you notice there to the two instance connect and within that session, they'll, they'll establish an S stage session.

Uh easy to instance connect also supports browser access. So if you want to use your browser that's also available, just make sure that you update the security group to allow an additional range. Ok? If you want to zoom in and have a quick glimpse, don't worry about all the details in there, but this is just a quick, quick glimpse on how a policy might look like for this access.

So we're saying here that we're allowing anyone with this policy to connect to any instance. So it's instance forward slash star as long as it has a specific tag value. So our user will be able to connect to an instance with a particular tag and you can configure these policies however you want. So this is just a single example.

Now, if we want to get rid of the internet gateway, we can do that by using uh EC2 instance, connect endpoints. So instead of using an internet gateway, we'll have a private way to connect to the E EC2 instance, connect service. And that's gonna be an endpoint inside of EPC. You notice that the end point has a security group. So traffic is going to go from the service to the end point privately and then from the endpoint privately to C two instance.

And then because the endpoint is a security group we can again reference that security group on an instant security group to say I'm only allowing SSH as long as traffic comes in through this two instance. Endpoint connectivity looks the same. If you're using the C we will automatically detect that the end point exists. So you don't have to specify anything different. Just say I want to connect to an instance, we'll check the policy as long as you're allowed, we create the keys on the fly and then you'll be able to set up the session to your instance.

And then same goes for the browser. Uh from the endpoint perspective, there's a couple of things that you can set up here so you can set up and decide if you want to do IP preservation or not. So if you disable IP preservation, any traffic coming to your two instance will look as if it's coming from the IP address of the endpoint. If you enable IP preservation, we will actually preserve the real client IP address the public IP address of the remote user all the way to the two instance. So you'll be able to see that in the logs. Ok?

So that was easy to instance, connect, I wanna switch to sessions manager, which is part of the systems manager. So systems manager is a suite of services that you might already be using or you would be using for orchestration and management of your E two instances as well as virtual machines on premise as well as even other cloud providers. So you can do things like send commands or like in our example, we're going to talk about sessions manager, which is specifically used for remote access.

Now, for systems manager, you do have to deploy an agent on your EC2 instance or any virtual machine that, that you want to use it with. So that's something that you need to be aware of. Although with most EC2 instances that you would deploy, the agent is pre installed automatically the amazon linux ones. Ok.

So let's have a look at the architecture for sessions manager. We're gonna have our IC two instance, we have our internet gateway, we have our remote user and this time we're gonna be talking to sessions manager. And the interesting thing here is that it's not the sessions manager talking to the E two instance. It's the two instance that will do an outbound connection to the session manager and to be able to do that outbound connection, it needs to have the right permissions.

And that's done through assigning a systems manager role, SSM role, that role just gives permissions to the instance to be able to connect to the session manager service. And as long as it does a network path. So in this case, it's a public network path. It will need an internet gateway, it will need a public IP address to connect to the session manager service.

And then the so from a security group perspective, there's actually quite an interesting outcome here because because the two instance is doing an outbound connection, we don't need any inbound rules. So our inbound rules can be completely locked down. We don't have to have a single one and SSH is still going to work. Ok.

So our remote user will also use AWS C to connect this time, use AWS SSN to start a session to target instance. Uh we can again check them against the identity and access management policy to make sure are they actually allowed to connect to that instance? And then as long as they are, the TLS session is established, the keys are provisioned. All of that.

This approach also supports browser access. So very similar to to instance, connect, we have both options supported. Now, if we don't want to have an internet gateway, we can also use endpoints. In this scenario. This time we would use uh systems manager end points to allow the EC2 instance to talk to the session manager service completely privately without having to use an internet gateway without having to use a public IP address. But everything else still stays the same if we have a look at how the policy looks like.

Again, don't worry about it being very complex. I know this is a 200 level session, but this is just a glimpse of what you might be able to do. Uh in this scenario, I was saying, we're allowing whoever has this policy to start an SSM session to a particular instance. And there's one extra option I've added here as it's an optional thing that you can do is you can specify an SSM document.

So SSM document is a set of instructions that will be applied at the connection time to the user connecting to the instance. So here in this example, SSM document, we're saying as soon as someone connects, there's going to be a specific log path we're interested in and we want to immediately start tailing or effectively looking at what's appearing in that log path.

So let's look at an example how a remote user would use the policy. They would have to modify their SSM command to specify that they're using an SSM document and you can enforce the usage of the document or not. So if you always want everybody to use the document and someone doesn't include it, uh you can block access using just IM so everything is correct.

Um so the user establishes a session and then we immediately run the information in the policy in that SSM document and the user starts is gonna start seeing the logs entries being in the log se uh sessions manager also supports session activity logging. So you can send those logs either to a storage service or cloudwatch. And here is an example of a particular entry.

Uh so that's uh we can see that someone connected to an instance. Uh we can see what role whoever connected to it used and then what uh user they were running as and then below you can see the commands they run. So they decided to ping a public IP address and they got a successful response. So anything they would do in the console, you can log and send to cloudwatch or s3. Ok.

So we talked about EC2 instance connect and we talked about sessions manager. Uh there are some similarities here. So first of all, if you do not, if you don't want to use an agent, uh if you don't already have an agent, then E two instance connect is the way to go. It's a simple approach, you connect and you get access to any EC2 instance as long as it's running running linux on windows with session manager if you do need an agent. But if you already have that agent, you can connect to more OSs. We're adding MA OS as well as you can connect to things on AWS like two, but also resources in your on premise environment and with session manager. As you remember, you don't have to allow any inbound SSH access because the connection from the instance is only outbound.

Finally, both allow you to not worry about managing SSH keys and both support browser and CLI access uh and uh effectively checking identity against identity access management. Ok?

So I'm gonna move on to the application access use case and Shaven is going to dive into that.

Thanks Tom, thanks for talking about access to network and access to EC2 instance. And I will talk more about access to S TT P application. I'm Shuan Das. I'm a product manager in EC2 VPC team and I manage client VPN and the next product which is a W is verified access. We also call it EVA. So you might hear me saying EVA.

So as Tom said in the beginning, when you consider access to a resource, you have to consider three things. First was the resource. In this case, it is STT P application. The second thing is that what level of trust or verification you need to do for a user to allow them to access the application or resource. And third thing is that what is your audit criterias? Right?

So we will look at S TT P application through these lenses. These S TT P applications are developed by your engineering team using AWS sources like EC two VPC and they are S TT P applications such as IT help desk which each and every employee staff needs to access. Then there are sensitive financial application which only your finance team or executive needs to access. So you can see there is a wide spectrum of these applications. And as a security administrator, you need to have that fine grain control, who can access the application under what conditions. And second thing is that these applications can be hundreds and even thousands. So you want something which is easy to manage, which is easy to audit. And we'll, we'll touch upon that. We'll touch how easy it is to manage.

Since we said that it is built on AWS verified uh zero trust principles, which can mean different things to different people. So I just want to say what is our zero trust principles? The first thing is that we say that you should use apart from networking, you should also use non networking signals such as identity and device posture. And it also emphasizes that more number of signals you use. The better the security posture is the better the trust is before aligning the access.

And second thing it emphasizes is that continuous verification process. For example, let's say I want to access application one verified access will run the policy will check my identity device posture and then allow me access to the application moment later, I want to access application two. It will revalidated me, it will re verify against the policy that my administrator has written. Now, I want to again access application one even though few seconds earlier, a few minutes earlier, I was in the application but still the verification process will run in case something has changed. So that's the AWS zero trust principle. Use multiple signals, use non networking signals, do the continuous verification which gives you better security posture and verified access is built on that.

So zero trust is nothing new. Our customers have been implementing it for, for a while but it can get complicated and cumbersome and verified access solves that right.

So if you look you have applications, this STT P applications, hundreds and thousands of them, your developers are building them, these developers, they are integrating with their identity, with your identity team, with your identity service and then writing policy who can sign on to this application, then you have networking team who are managing VPN policies who can on board to the application to the network. Then with the help of IT team, you are deciding under what condition a device is compliant and when they can join the network.

So at the end of the day, you have at least three set of policies managed by three set of teams. And in case you want to roll out a new application or you want to make a policy change, it can take days and weeks, right?

So with verified access, what we have seen is that it's a single gateway for all your applications, you write a single set of policies. So the control goes to the security administrator, they define who under what condition can access the application. And we have seen customers rolling out new application or making policy changes just in a matter of minutes. Then they come up with a new application, put it behind a change policies and within a few minutes it is ready for their users and staffs zooming in on verified access so what happens is that the moment your users open their laptop and type the web domain name of the application on the browser. All S TT P request comes to this verified access gateway here.

We allow you to write policies and we pull data from third party providers, identity and device posture with, with that data with your policies. We decide that whether the user can connect to the application. If the policy says yes, users can connect. So then we connect the application to your uh we connect the request to your application. These policies are fine as we talked. So you can say that any employee, any staff can access IT help desk. But to access financial application, the user.