Secure your application with AWS Verified Access
This article wants to explore one of the big new announcement of AWS ReInvent 2022 that was promoted to General availability in late April: AWS Verified Access.
Our purpose is to explain what is this service, which business and security needs its tackling and how to implement it on your AWS Organization
ZERO TRUST vs TRADITIONAL VPN
Before moving into the specifics of Verified Access we should take a look at what is a Zero Trust model.
It’s a security model that wants to move past network based security with traditional VPNs. The VPN model uses a us vs them approach, where you suppose that the danger, the enemy is outside. It establishes a perimeter around certain assets and assumes that anything that travels within the VPN can be trusted, often allowing access to all assets once you are authenticated to the VPN.
This model used to work great in the pre cloud world where people used to work mostly within offices, in which you have also physical security of the premises and the network architecture used to be centralized in a single data center. Resources were compartmentalized by zone of access and network segment.
In the post cloud world most organization have shifted towards a distributed architectures, with multiple data centers, private and public clouds. Employees may require access to multiple applications and services hosted in any point of this architecture making the concept of “zone” a little outdated.
Zero trust moves past the zonal trust and assumes that the attacker has already breached the perimeter. Zero Trust creates structures and policies that prevent exfiltration and preserves Confidentiality, Integrity, and Availability of data.
In order to do so it evaluates each request made by user/device against the defined policies that can be applied at different level of granularity, in Verified Access we will see that you can write group policy and app specific policies.
The identities operate therefore in an identity-aware network thus reducing attack surface area and remove unnecessary network connectivity to data.
Aside from security, which should still be the main driver in its adoption, Zero Trust can offer a better user experience. In this sense VPNs shortcomings were highlighted in the pandemic era once more. Covid brought the big shift to hybrid works schedule where personnel is no longer working within the office building but could be working from anywhere.
VPNs offer inherently slower performance as traffic has to be routed through a datacenter for encryption/decryption and the increase in bandwith requirements further show that scaling VPNs, while maintaining high level security, is hard and requires significant budget and dedicated personnel.
Zero trust is built for the cloud era, users can be at the office or at Starbucks their access to private apps is always simple and secure from the device and location they choose.
Zero Trust Network Access allows them to no longer be slowed down by the latency, increasing user experience and productivity.
AWS Verified Access
We briefly saw what is a zero trust model, now we can delve a little in the specific of the AWS offer and how it fits in the landscape.
AWS Verified Access is the service that signs the entrance of AWS in the zero trust market space, it provides required functionalities without much overhead and is integrated within the AWS ecosystem.
The service, to put it simply, implements an OIDC client in front of your endpoints, which can be enhanced with additional features in case you set it to evaluate device status as well.
AWS Verified Access evaluates each application request from your users and allows access based on:
- Trust data by the trust provider, be it AWS IAM identity center or a third party OIDC provider.
- Access policies defined in verified access at group level and at the application level.
- The default behaviour is to deny any access unless explicitly allowed by a policy, every access attempt is logged in order to allow for quick security incident response and audit requests
The following diagram provides a high-level overview of Verified Access. Users send requests to access an application. Verified Access evaluates the request against the access policy for the group and any application-specific endpoint policies. If access is allowed, the request is sent to the application through the endpoint.
Trust provider for Verified access can be of two type:
- Users providers: IAM or third party OIDC providers
- Device providers: it integrates with CrowdStrike and {Jamf} and requires a verified access browser extension to send device status information with http request to the endpoint
After receving the trust data the information are challenged against the verified permissions policies associated with the access group and the specific endpoint.
A policy can be defined at group level and overridden at app level, they are written in AWS policy language CEDAR. More information can be found Here.
What concerns our analysis is knowing how CEDAR works and what’s the structure of a statement (multiple statements are allowed in the same policy), which consists of three parts:
- EFFECT: Specify if it’s a permit or a deny
- SCOPE: Specify what is affected by this effect (action, resource, principal)
- CONDITION: Specify when the effect applies
In the case of Verified Access the Scope section must be kept undefined as policy refers to trust data in the condition clause.
It’s important to remember that Verified Access policy evaluates data that may or may not be present in a given context. If the data does not exist in a context it will result in a DENY, so be sure to structure correctly your policy and make use of the built-in operators “$\|$” to perform or operations in case you use multiple trust provider and have to reference different data.
Implementation of centralized AWS Verified Access
At this point we should have a clearer idea of what AWS Verified Access does and why should we evaluate its use.
It’s time to go through the step of setting up Verified Access in your security account, configure a verified access group with a first policy and share it with the account of the organization that may use it.
We assume that you already have an application on AWS that you can use as Verified Access endpoint that makes use of a public certificate uploaded on AWS ACM.
NOTE: Your load balancer should be configured as internal in order to be used as VA endpoint!
First you should configure your trust provider, name tag and description should help you identify the configuration you are setting up.
The policy_reference_name will be used later when working with policy.
In our example we are using IAM Identity Center as User trust provider as its the chosen authorization center in our company, future post may explore the device provider type and its interesting features.
Once the provider is created we can proceed with the Verified Access Instance creation to which we will attach the trust provider created in the previous step.
The next step we will be carrying in our centralized account is the creation of the Access Group.
We can create a policy at the group level that would challenge the trust data to ensure the user has the mail verified and belongs to the infrustructure group before allowing access. As we are using IAM Identity Center we can define the group with its ID
At this point we can proceed with sharing the Access Group, in our case with the whole Infrastructure Organizational Unit that would share the same permission policy (further specifics may be added at app level).
For the next step and final step we can move to the account that host the application we want to secure.
Creating the Verified Access Endpoint will associate our load balancer (but it could have been a network interface) with verified access group we just shared.
The configuration includes the application domain that would be used for reaching the application, the ACM certificate that validates the domain as well as details on the attachment.
Once the endpoint is created it will generate an endpoint domain that you should map as CNAME to your application domain, in our case compliance-dashboard.stormreply.com.
Now you can navigate to your domain and be expected to be redirected to IAM Identity Center for login.
Our walk-through ends here, don’t forget to clean up the resources you created for this test in order to not incur in unexpected billing charges : )
Conclusion
In conclusion, AWS Verified Access is a valid option to use in your Zero Trust journey when you have or plan to have important corporate workloads on the AWS cloud.
We showed how to implement a centralized instance and how to create and share an access group within your organization.
Verified Access is a good example of an AWS service that is built with a clear target and purpose and it’s well integrated into the AWS environment. As an example, you can add additional layers of protection associating an AWS WAF web ACL with the verified access instance and build a centralized logging for every authentication attempt by activating the logging.
Further information can be found at the following links:
Thanks for your time in reading this article.
