Core Concepts of AWS Cloud Security

The shared responsibility model

AWS divides security between itself and the customer along a line that moves depending on the service.

AWS is responsible for security of the cloud

• The physical facilities, hardware and networking
• The virtualisation layer and the software that runs the managed services
• The global infrastructure: Regions, Availability Zones and edge locations

The customer is responsible for security in the cloud

• Customer data — its classification, its encryption, and who may reach it
• Platform, applications and identity and access management
• Operating system, network and firewall configuration
• Client-side and server-side encryption, and protection of traffic in transit

The line moves with the service model. On EC2 the customer patches the operating system; on Lambda or DynamoDB, AWS does. What never moves is the customer’s responsibility for their own data and their own identities.

Least privilege

Every identity and every service should hold the minimum permissions its job requires, for the shortest time it requires them.

• Grant specific actions on specific resources, not * on *
• Prefer temporary credentials to permanent ones — roles rather than access keys
• Avoid long-lived access keys entirely where a role will do, which is nearly everywhere
• Review granted permissions against what is actually used; IAM service last accessed data and IAM Access Analyzer both make this concrete
• Treat every exception as an exception, with an owner and a review date

The identity framework

Four questions, in order, decide whether a request succeeds.

	Question	Mechanism
Identity	Who are you?	IAM users and roles, the root user, temporary security credentials — held by people, services or devices
Authentication	Can you prove it?	Passwords with MFA, access keys, client-side certificates, an assertion from a federated identity provider
Authorization	Are you allowed to do this?	IAM identity-based and resource-based policies, evaluated together with SCPs, RCPs, permissions boundaries and session policies
Trust	Does something I trust vouch for you?	Role trust policies, SAML-based federation, OIDC federation, cross-account roles

A typical federated request runs: the identity requests access; an identity broker authenticates it against the identity store, possibly through a federated provider; the broker calls AWS STS; STS returns temporary credentials scoped to a role; the caller uses those credentials, and every subsequent authorization decision is made against the role’s policies.

Network security

Protecting the VPC is the other half of the problem, and it starts from the assumption that someone will try:

• Malicious traffic will be sent at any public endpoint
• Web applications will be targeted by DDoS attacks
• Anything reachable will be scanned

The layered controls — security groups, network ACLs, AWS Network Firewall, AWS WAF and AWS Shield — are covered in Network security.

Planning for failure

The useful assumption is not that controls will hold but that some of them will not.

• Passwords will be stolen
• Static access keys will be leaked, usually into a source repository
• Resources will be exposed by mistake
• Someone will act on a phishing message

Design accordingly.

Reduce the chance

• Enforce MFA everywhere, and remove long-lived access keys
• Federate human access through IAM Identity Center so credentials are short-lived
• Keep public endpoints to the minimum and put them behind managed protection

Limit the damage

• Separate workloads into separate accounts, so a compromise has a boundary
• Encrypt data at rest and in transit, and control the keys
• Monitor continuously — GuardDuty for behaviour, AWS Config for configuration, CloudTrail for who did what
• Send logs to an account the workload accounts cannot write to

Be able to respond

• Know in advance how to revoke a session, disable a principal and isolate an instance
• Rehearse it, so the first attempt is not during an incident