Secure application access in AWS

The Security Pillar of the AWS Well-Architected Framework differentiates between human and machine identities. Both types of identities are provided with opportunities to securely access applications within the AWS ecosystem, each having certain similarities and distinct differences in their access methods.

Human identities refer to individuals such as employees, administrators, developers, or customers who interact with systems and services.

Machine identities, on the other hand, encompass applications, AWS services, or third-party services that communicate with AWS services.

Secure application access by human identities

The following are key concepts and best practices for secure applications access by humans:

For web and mobile applications that require user authentication, implement Amazon Cognito which provide sign-in, sing-up capability with federated authentication (social providers like Google, FaceBook, Amazon, Apple)

For other applications use AWS IAM, AWS IAM Identity Central or AWS Directory Service users assigned to groups with proper permissions (included in policies)

Implement the principle of least privilege, ensuring that users are granted only the granted only the permissions essential for their specific roles

AWS Idenity Central has options to access specified applications directly from single authentication portal in mutli account environment (SSO)

In multi-account environments, leverage roles that provide short-term access tokens for applications, enhancing security and access management.

Enforce Multi-Factor Authentication (MFA) for both Amazon Cognito and IAM services to enhance authentication security

Avoid granting public access to your RDS instances. Instead, position them within a private network and allow EC2 instances access as required on an as-needed basis

Secure application access by machine identities

The following are key concepts and best practices for secure applications access by other applications and machines:

Use AWS Identity and Access Management (IAM) roles (instead of users as with human entities) for applications running on AWS services like EC2, Lambda, or ECS. These roles provide temporary security credentials (short-term) that applications can use to make AWS API requests

If applications in different AWS accounts need to interact, use cross-account IAM roles for secure access

Deploy applications within an Amazon Virtual Private Cloud (VPC) for network isolation and Control traffic at the subnet level using Network Access Control Lists (NACLs) and at the instance level with Security Groups

Utilize Amazon API Gateway for managing, securing, and monitoring API traffic between applications

If your application requires internet access solely for communication with AWS services, opt for VPC endpoints instead of exposing your entire network to the public internet.

Ensure that databases, such as RDS instances, are not exposed to public access. Keep them confined within a private network and facilitate access through private subnets

Use AWS PrivateLink to privately connect services across different accounts, VPCs and third-party APIs from AWS marketplace, reducing the exposure of data to the public internet