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
- Manage, retrieve, and rotate database credentials, API keys, and other secrets throughout their lifecycle using AWS Secrets Manager
- Secure application endpoints with AWS WAF (Web Application Firewall) to protect against common web exploits
- Encrypt data in transit between applications using TLS
- Use AWS KMS for managing encryption keys
References
The Security Pillar of the AWS Well-Architected Framework
Security best practices in IAM
Manage identities
Providing secure access to your applications
VPC Networking – AWS PrivateLink Features – Amazon Web Services