sdlc.dev

AWS fundamentals path · Ground rules · Topic 2 of 18

The shared responsibility model

Not started

AWS describes security as shared: AWS is responsible for security **of** the cloud, and the customer for security **in** the cloud. AWS runs the buildings, the servers, the network between them and the virtualisation layer, and gets them audited. Everything you create on top (accounts, users, roles, network rules, operating systems, application code and data) is configured by you, and the outcome is yours.

Why it matters: Most AWS security incidents are not AWS being breached. They are customers leaving a bucket public, a key in a repository or a port open, which is on the customer's side of the line.

  1. 1Of the cloud versus in the cloud

    AWS is responsible for the facilities, hardware, network and virtualisation. You are responsible for your data, identities, configuration and code.

  2. 2The line moves with the service

    On EC2 you patch the operating system. On Lambda or DynamoDB, AWS does, and your share shrinks to code, data and permissions.

  3. 3Configuration is always yours

    However managed the service, who can access it, whether it is encrypted and whether it is exposed to the internet are your decisions.

1

How it works

The explanation, with examples you can run.

Where the line sits

ServiceAWS takes care ofYou still own
EC2Hardware, hypervisor, physical networkGuest OS and patches, software, security groups, IAM roles, data, encryption choices
RDSDatabase engine installation, patching (in your maintenance window), backups if enabledNetwork exposure, database users, parameter choices, enabling encryption and Multi-AZ
LambdaOS, runtime patching, scalingFunction code and its dependencies, the execution role, environment secrets, the data
S3, DynamoDBEverything about storage and durabilityBucket and table policies, who may read and write, encryption keys you manage, retention

The more managed the service, the less you have to patch, but one row never disappears: identity, network exposure and data. AWS cannot know whether a bucket is meant to be public or a role is meant to be powerful.

What usually goes wrong

  • Long-lived access keys in source code, CI logs or laptops. Prefer roles with temporary credentials for workloads, and single sign-on for people.
  • Public by mistake: a bucket policy or ACL that grants "Principal": "*", a security group open to 0.0.0.0/0 on a database port, or a snapshot shared publicly. S3 Block Public Access is on by default for new buckets; turning it off should be rare and deliberate.
  • Over-broad permissions: "Action": "*" on "Resource": "*" for an application that needs three actions on one table.
  • Unpatched instances that nobody owns, especially ones created by hand for a test and forgotten.
  • No logging: without CloudTrail (API activity) and service logs, you cannot tell afterwards what happened.

Making it concrete

Write down, per service you use, which of the items above your team owns, and check them automatically. AWS Config rules, Security Hub and IAM Access Analyzer can flag public buckets, unused permissions and missing encryption. Treat the findings like failing tests, not like advice. The rest of this path keeps returning to this line: each building block has settings that only you can get right.

2

Check yourself

3 questions. Get them all right to finish this topic.

  1. 1.An attacker reads data from an S3 bucket whose policy allowed public reads. Whose side of the model failed?
  2. 2.Who patches the guest operating system on an EC2 instance?
  3. 3.Which change moves the most responsibility to AWS?

0 of 3 right so far. Get all three to finish this topic.

Go deeper