Let's start with a scenario. It's a Monday morning, and we begin the week by connecting to our VPN. We can then access our emails, Teams channels, log in to the AWS console, etc. Just a typical Monday morning, right? An hour passes, and the connection is lost. "Well, I must have been disconnected from the VPN...," I'm sure that phrase sounds familiar to you.
Yes, the VPN, this tool that everyone uses. But what if I told you that it was no longer useful using AWS ? Imagine a world where we could securely connect to our applications without going through a heavy client? What if, on top of that, we applied the principle of zero trust? And even further, if we could put restrictions on the type of device we use to connect and the geographic location?
This is now possible. AWS announced its new AWS Verified Access service a few months ago, and today I will try to break it down for you.
VPN, what is it and why does everyone use it?
A VPN (Virtual Private Network) is a service that routes a user's web traffic to an internet destination via a secure remote server. This remote, secure server acts as an intermediary between the user and the internet network.
The operation of a VPN is not very complicated (unless you really get into the details).
source : https://blog.360totalsecurity.com/en/how-vpn-works/
During VPN activation, a connection to the VPN server is established. All incoming and outgoing data from your device then passes through an encrypted tunnel via a process of encapsulation. Encryption secures the connection by making your traffic unreadable. Data is effectively indecipherable - except for those who possess the encryption key.
No company wants unrestricted access to their internal applications. The https protocol is not sufficient here, so an additional layer of security is desired. Moreover, when someone now arrives on the Internet, the IP address of the person using the VPN will not be their ownIP address. Indeed, the person's request goes through the VPN server, so there has been a change of IP address indicating that the person went through the VPN.
It is therefore possible to restrict access to our applications by limiting incoming IP addresses to that of the VPN server(s).
We can see that having a VPN today is super interesting. However, there are still some disadvantages. Indeed, once connected to the VPN, it is much easier to harm an infrastructure, although there are still safeguards, but not always (authentication via user/password or via an SSO). If a malicious person manages to intrude on one of your servers, what about the rest?
In addition, it is quite annoying to have to start your VPN client all the time, connect to it. Not to mention the moment when this VPN no longer works or randomly disconnects (session timeout on the server side, any network issue, etc).
The solution offered by AWS: Verified Access.
Verified Access works by evaluating access requests against access policies attached to either an application or an application group. If all access policies are met, the user's request is accepted and sent to the application through a Verified Access-managed access point.
The notable difference between Verified Access and a VPN is that each request is evaluated independently against access policies defined by the security team.
Verified Access is composed of several components. Here is a diagram from the service's documentation that describes a high-level view of the service :
Verified Access instance (1) - An instance that evaluates application requests and authorizes or denies access based on defined security criteria.
Verified Access endpoint (2) - Each endpoint represents an application. There are two possible endpoint types: a Load Balancer or an Elastic Network Interface (ENI).
Verified Access group (3) - A collection of Verified Access endpoints. It is recommended to group applications with similar security criteria into a single group. For example, applications for marketing in a marketing group.
Access Policies (4) - A set of access policies defined by the client that determines whether access to an application is granted or denied. This can be a combination of things like the identity of the user trying to access the application, the properties of the device they are using (OS, browsers, updates, etc.), the location of the person, etc. An access policy can be assigned to a group to encompass a set of applications and, then a policy can be applied to a specific application within that group for more granularity.
Trust Providers (5) - A service that handles user identity (such as IAM identity center, for example, or your on-premises identity provider) or device security compliance. AWS works with its own services, of course, but also with third-party services (including you, possibly as an IdP) and others, notably for metadata related to device compliance. It is mandatory to have a Trust Provider attached to a Verified Access instance to use the service.
Trust data (6) - The data that passes between the Trust Provider and AWS Verified Access. This data can be an email address, an IP address, the browser used, your location, etc.
Verified Access will then confront this data with the access policies defined by the user when it receives an access request for an application.
For the rest of the article, I would like to dig into four important points from the perspective of a company that wants to migrate to AWS Verified Access: Access Policies, Trust Providers, Monitoring, and Security. Since VPNs are already often in place in companies, we would like to know how to integrate what already exists with the service. Additionally, a few lines are also necessary on how to write access policies, their formalism, as well as monitoring and security.
It is true that I have not even talked about infrastructure management. You create a Verified Access Instance, and then what? Well, afterwards, AWS takes care of everything behind the scenes. It is a managed service, which is why I will not discuss this topic.
You only pay for what you consume. As for the endpoints, I will not dwell on them. AWS manages the redirection to your application from the service. A CNAME will be created by AWS internally to redirect the endpoint to your application if the request is authorized.
Trust Providers: How to Migrate Legacy?
We have seen that a trust provider is mandatory to use the Verified Access service. This trust provider can take two forms: one for user identity (Identity Provider, IdP for short) or one for managing the devices used to access our applications (computers, tablets, smartphones, etc.).
Let's focus first on the identity of the users, as it is often the most relevant to us.
Three different cases may exist when it comes to user identity to use the Verified Access service:
You already use IAM Identity Center (successor to AWS Single Sign-on) and use this service as an IdP. You just need to connect IAM Identity Center with Verified Access and you're good to go.
You don't use IAM Identity Center and already have an on-prem IdP. It's simple, you'll need to create your space under IAM Identity Center. You can then easily connect the service with your on-prem IdP. It's also possible to use an Active Directory as an IdP. You just need to connect Verified Access with IAM Identity Center, and you're good to go.
You don't want to use the IAM Identity Center service and already have an on-prem IdP? No problem, if this IdP is compatible with the OpenID Connect (OIDC) protocol, you can directly connect the Verified Access service with your on-prem IdP via the OIDC protocol. It requires a bit of configuration, but it's possible.
What about support management now?
Verified Access allows support management using external services. At the time of writing this article, 2 services are supported: Jamf and CrowdStrike.
This list will likely expand, as a highlight of the service AWS wanted to emphasize at Re:Invent (https://www.youtube.com/watch?v=Kkxn-bAIlnI) is that they want to make it an "open" service. That is, to integrate as many reliable external solutions as possible, as this need is often raised with AWS. We will revisit this later, but the monitoring section is filled with integration with external solutions used everywhere.
Access Policies, what do they look like?
The access policies used in the Verified Access service are written in AWS's proprietary language: Cedar (https://www.cedarpolicy.com/).
Even before seeing examples of access policies, it is important to note that if you create an application and start using Verified Access, the default rule is the Zero Trust Policy: everything is denied by default. Similar to the principle of least privilege in IAM policies, we want our users to only have access to what they need and nothing more. We do not want someone to escalate certain privileges because we have overly permissive access policies.
Now that the basics are laid out, it's time to discover how an access policy written in Cedar is structured.
Effect - Allows or denies access based on the policy that follows.
Scope - Specifies the principal, actions, and resources that the policy applies to.
Condition clause - Specifies the context in which the effects apply.
It is important to note that in the context of access policies, the scope field should always be left blank. All that we are interested in is in the "condition clause" part, where we have access to the user's identity and the support they are using.
We end up with an access policy that looks like this:
permit(principal,action,resource)
when{
context.<policy-reference-name>.<attribute> &&
context.<policy-reference-name>.<attribute2>
};
We notice the possibility of using operators, here is the list of those available:
!, ==, !=, <, <=, >, >=, in, &&, ||, .exists(), has, like, .contains(), .containsAll(), .containsAny()
If one wishes to access certain information, particularly about the support used by the user, it is necessary for the user to have a browser extension to transmit the information to Verified Access. However, for any information related to the user's identity, there is no need for this browser extension.
Let's see what we can do through two examples taken from the AWS documentation.
permit(principal,action,resource)
when {
context.identity.groups.contains("finance") &&
context.identity.email_verified == true &&
ip(context.http_request.client_ip).isInRange(ip("10.0.0.0/8"))
};
Here, we access the interesting data using the keyword "context". It is important to note that anything added to the "http_request" field will always be present. It contains certain information about the HTTP request such as the client's IP address, the HTTP method used, etc. (documentation on this subject can be found here: https://docs.aws.amazon.com/verified-access/latest/ug/trust-data-default-context.html).
The "identity" field allows us to know that the data comes from the IAM Identity Center service (and thus, that you are using it as an IdP). If you are not using this IdP, the documentation does not mention how to retrieve the fields (except for services that manage supports such as Jamf and CrowdStrike).
Returning to our example, we see that we will verify that the person's group (retrieved through IAM Identity Center) is indeed the "finance" group, then ensure that the email they are using is verified, and finally, that their IP address is in the range 10.0.0.0/8. If all this information is evaluated positively, the person's request will be accepted (thanks to the "permit" keyword at the top).
permit(principal,action,resource)
when {
context.crwd.assessment.overall > 50
&& context.jamf.risk == "LOW"
};
Second example which is actually a combination of two examples from the documentation. Here, we see the use of the keywords "crwd" and "jamf". These correspond to the two third-party services authorized by AWS for support management.
The first one is CrowdStrike, characterized by the keyword "crwd". In this example, we will verify that the overall rating of the support used is greater than 50. For the second one, which is none other than Jamf, characterized by "jamf", we will verify that the risk associated with the support is equal to "LOW".
We can see that the service allows for a large part of what businesses want in terms of options to secure access to their applications.
How do we monitor all of this? And what about security?
There is still a very important point that we have not yet discussed. Let's talk about monitoring and security. As a VPN is often a bottleneck and the gateway for all traffic to the internal network of a company, it is necessary that it be well monitored with a hermetic security.
For security, all data at rest is encrypted by KMS with a key held and managed by the service itself. We can use CloudTrail to audit the use of the service. For data in transit, the service uses TLS 1.2 for encryption.
As for traffic between multiple networks, it is possible to configure Verified Access to restrict access to specific resources in a Virtual Private Cloud (VPC). It is also possible to restrict access to portions of the network based on the user's group.
Let's now talk about monitoring. In August 2022, AWS released the Open Cybersecurity Schema Framework (OCSF). In collaboration with various industry players, they defined a standard log schema to enable those who produce logs to have the same view as those who consume them. AWS Verified Access currently uses this log format to allow for simplified integration with globally recognized monitoring services, including the following list of partner solutions (at present):
- Datadog
- IBM
- netskope
- new relic
- RAPID7
- sumo logic
- Trellix
- Splunk
How much does it cost?
Certainly, one of the sensitive issues concerning this service is its price. The bill is divided into two parts: hourly charges for each application, and data that has passed through during the use of the service.
The hourly price of the service per application, in the Ireland region (eu-west-1), amounts to $0.31/hour per application up to 148,800 hours per application (which corresponds to approximately 200 applications per month, running all the time). The rate is lower for hours per application above 148,800 and costs $0.23/hour thereafter.
Processed data costs $0.02/GB.
If we take an example with 210 applications that process 1 GB of data each for 31 days, we arrive at the following calculation:
148,800 * 0.31 + 7,400 * 0.23 + 1 * 210 * 0.02 = $47,834.2
To conclude,
To add a personal opinion about this service, I think it is a super useful service. I believe there is a good chance that this kind of service will replace the VPN solutions we currently know. Given the complexity of maintaining a VPN today, there is a big gain to be had here (because yes, when the VPN goes down, it's a big part of the day's revenue that goes up in smoke for many companies with the democratization of teleworking). Here, the VPN is managed by AWS, we no longer have to worry about its robustness. In addition, the access policy part seems to be very user-friendly, it is much easier to centralize policies and manage access to them using IAM. So, of course, all these advantages come with a cost.
Can we say that the VPN is no longer useful? Not really. Indeed, some use cases will still be relevant, I think. What about SSH access to a database (a very good alternative being AWS SSM with the session manager if the resource is on AWS)? Access to a NAS? The service doesn't seem to be made for that yet. It remains to be seen what the future holds.
If you are interested in setting up this service, I found this article to be very well detailed: https://medium.com/@chaim_sanders/a-visual-guide-to-setting-up-aws-verified-access-1333466f7222
Top comments (0)