AWS Verified Access — Seamless & Safe Access to Private Applications without VPN

Problem Statement

Corporate users frequently access applications from various locations, leading to traffic over untrusted networks out of IT admins’ control. This expands the attack surface for malicious actors. As a solution, IT admins require better visibility and control for user access to AWS and IT resources. This includes conditional access based on a user’s identity and the security state of their device.

Solution

AWS has introduced ‘Verified Access’, now available for any identity provider. IAM admins can provide secure access to private AWS applications from any location, eliminating the need for a VPN. This new feature requires no significant modifications to the existing IT infrastructure.

What Is AWS Verified Access?

AWS Verified Access is a feature that ensures secure access to private apps hosted on AWS without requiring a VPN. It assesses each access request in real-time based on various security signals such as identity and location. It then grants appropriate access based on the app’s security policy, enhancing the organization’s security. Verified Access is based on Zero Trust principles, allowing teams to create policies for private app access. This improves security, simplifies policy enforcement, and provides a seamless user experience without a VPN.



Connecting Azure Active Directory with AWS Verified Access as Trusted Providers.



Customers are increasingly using Azure Active-Directory as their main identity provider due to its comprehensive set of features for identity, access, and device management. This simplifies the configuration, monitoring, and security of AWS services. The recent integration of Azure Active-Directory with AWS Verified Access offers additional benefits and capabilities:

Secure distributed users by granting access using multiple security signals like identity, location, and device security status.
Manage private application access by defining access policies and able to onboard new applications quickly.
Build detailed policies using security data such as device and software security status to define a user’s access to each application.
Accelerate troubleshooting time by providing visibility to each access request and logging all requested data.
AWS Verified Access provides secure access to applications by evaluating each access request and granting access only to trusted users.
Customers can group applications with similar security needs using Verified Access.
Customers also have the option to use human-readable and easy-to-configure policies to govern access.

Customers have the ability to set up custom access policies for each application in a group with Verified Access. It facilitates the use of Azure Active-Directory as an Identity Provider either through AWS IAM Identity Center (the new version of AWS SSO) or via the OpenID Connect protocol which Azure Active-Directory also supports.

Step 1:- Configure the Trust Providers

Log into AWS IAM Identity Center management console
Enable IAM Identity Center
If necessary, create a new AWS organization
Choose your identity source under “Recommended setup steps”
Change “Identity Source”
Select “External identity provider”
Download metadata file from the “Service provider metadata” section

Step 2:- Configure SAML integration in Azure Active Directory

Step 3:- Configure SAML integration in Azure Active Directory

Navigate back to AWS IAM Identity Center management console.
Click on ‘Choose file’ in the Identity provider metadata section.
Upload the Azure Active directory metadata file.
Click ‘Next: Review’.
Type ‘ACCEPT’ in the text box to change your identity source.
Confirm by clicking on ‘Change identity source’.

Configure Verified Access
Creating a Verified Access setup is a four-step process as listed below:
Create Verified Access Trust provider
Create Verified Access Instance
Create Verified Access Group
Create Verified Access Endpoint

Prerequisite:-
Must have an AWS account
Setup of Amazon VPC required
Installation of a web server on your EC2 instance
An internal ALB needed
Must have a public domain available for creating a hostname to access the application
A public TLS/SSL certificate imported into or created with ACM is required
The certificate name must match with the hostname used for AVA

Step 1:- Create Verified Access Trust provider



Step 2:- Create Verified Access Instance



Step 3:- Create Verified Access Group
Implement policy at a granular level as per necessity.
Refer the link to create cedar-policy — https://www.cedarpolicy.com/en/aws-verified-access



Step 4:- Create Verified Access Endpoint

Each endpoint has its own DNS name and TLS certificate.
Verified Access Group should be selected from the one created earlier.
Input a DNS name for the application.
Select the public TLS certificate for Domain certificate ARN.
Attachment type should be set to ‘VPC’.
Choose necessary security groups for the endpoint.
Enter a custom identifier for the Endpoint domain prefix to prepend endpoint’s DNS name.
For Endpoint type, select ‘Load balancer’ and define Protocol, Port, Load balancer ARN and subnets.
HTTPS load balancers can use either self-signed or public TLS certificates.






After the creation of the Endpoint, its public DNS name should be visible in the details section.



For your application domain, construct a CNAME record by utilizing this public DNS name combined with the Verified Access endpoint.
Evaluating the Solution Configuration
Browse the domain which is defined in Verified access



2. The process redirects towards Azure Active Directory for authentication.



3. Upon successful completion of a two-factor authentication, proceed with accessing the application.