# Shared Responsibility Model and Resource Protection

> Chapter 5 of the Courseiva AWS-SYSOPS-ASSOCIATE curriculum — https://courseiva.com/learn/aws-sysops-associate/shared-responsibility-and-resource-protection

**Official objective:** 5.2 — Implement and manage resource access controls and data protection

## Introduction

If you do not know exactly who is responsible for what in the cloud, you can accidentally leave the digital front door wide open, leading to a data breach that costs your company millions. This is why the Shared Responsibility Model is the single most important security concept to understand for the AWS Certified SysOps Administrator exam. It defines the clear division of security duties between you (the customer) and AWS (the provider), so nothing slips through the cracks.

## The House Party Security Analogy

A house with a backyard for a party. You, as the homeowner, have invited guests over for a barbecue. The security of the event is a shared task between you and a professional security company you have hired.

The security company is responsible for the perimeter fence, the lock on the front gate, and the alarm system that detects if someone tries to climb over. They handle the street outside and the neighbourhood watch. They ensure no one breaks into the garden shed. This is like the cloud provider's responsibility: securing the physical hardware, the network, and the data centres where your stuff is stored.

But you, the homeowner, are responsible for the rest. You lock the back door of the house so guests don’t wander inside. You keep the barbecue supervised so nothing catches fire. You decide who gets the Wi-Fi password and who does not. If a guest breaks a window, you call the repair person. You manage who has keys to the house, and you make sure you change the lock after a guest who was a bit too curious leaves. This is your responsibility: protecting the data, managing who can access what, and keeping your own applications and configurations secure.

The security company cannot be blamed if you leave the back door wide open. You cannot be blamed if the neighbourhood power grid fails and the alarm system shuts down. Both sides must do their part, but the boundary between them is clear. In cloud computing, this boundary is defined by the 'Shared Responsibility Model'.

## Core explanation

The Shared Responsibility Model is AWS's way of drawing a line in the sand. It answers the question: 'Who is responsible for what security task when I use cloud services?' The short answer is: AWS is responsible for the security 'of' the cloud, and you are responsible for security 'in' the cloud.

Let's break that down.

'Security of the cloud' means AWS looks after everything they own and operate. This includes the physical data centres: the buildings, the cooling systems, the power supply, the servers, the networking cables, and the hypervisor (the software that creates and runs virtual machines). AWS also secures the global infrastructure: their regions, availability zones, and edge locations. If someone tries to physically break into an AWS data centre, AWS deals with that. If a power surge fries a server, AWS replaces it. You never think about that.

'Security in the cloud' means you look after everything you control inside AWS. This is where the exam really focuses. Your responsibilities include:\
- Your customer data: you must encrypt it, back it up, and control who sees it.\
- Your operating systems: if you run an EC2 instance (a virtual server), you must patch its operating system, install security updates, and configure firewalls.\
- Your firewall and network configurations: AWS gives you tools like Security Groups (virtual firewalls for your instances) and Network Access Control Lists (NACLs, which are firewalls for your subnets). You have to set them up correctly.\
- Identity and Access Management (IAM): you create users, groups, roles, and permissions. You decide who can launch instances, who can delete data, and who can access storage.\
- Your applications: the code you write and run is your responsibility to secure.\

The model changes depending on which AWS service you use. For example, with Amazon EC2 (Infrastructure as a Service, or IaaS), AWS handles the physical hardware and hypervisor, but you do everything else. With Amazon RDS (Relational Database Service, a managed database service), AWS takes on more: they manage the operating system patching and database software updates, but you are still responsible for managing access to the database and securing your data inside it. With Amazon S3 (Simple Storage Service), AWS is responsible for securing the underlying storage infrastructure, but you are responsible for the bucket policies, access controls, and encryption settings that protect your objects.

Why does this model exist? Before cloud computing, companies ran their own data centres. They were responsible for everything: buying servers, patching them, locking the doors, and managing the network. The cloud shifted some of that burden to the provider, but not all of it. The model was created so that both sides know exactly what they must do, avoiding the assumption that 'it is all the cloud provider's problem' — that is a dangerous myth.

For the SOA-C02 exam, you must memorise the specific boundary for each service type. The exam writers love to test this by listing security tasks and asking you to identify who is responsible. They also test your understanding of 'resource protection': the set of tools and practices you use to fulfil your part of the model. Key AWS services for resource protection include IAM (users, groups, roles, policies), AWS KMS (Key Management Service for encryption keys), AWS CloudTrail (for auditing who did what), and AWS Config (for monitoring configuration changes).

In summary, the Shared Responsibility Model is not a suggestion — it is the framework that defines accountability. Miss it, and you create security gaps. Master it, and you know exactly where to focus your protection efforts.

## Real-world context

Imagine you are the new SysOps Administrator at 'BrightCo', an online retailer that uses AWS. Your boss says, 'We had a security incident last month — a developer accidentally deleted a production database. I want to make sure it never happens again.' Your job is to apply the Shared Responsibility Model and implement resource protection.

First, you log into the AWS Management Console. You notice that every employee in the company is using the same root user account (the master account owner). That is a massive violation of your responsibilities under the model. Your first step is to create separate IAM users for each person. You assign them permissions using IAM policies — for example, the developer who deleted the database had full access to RDS, which was unnecessary. You change that to read-only access for developers, and full access only for senior DBAs.

Next, you look at the S3 buckets holding customer order data. You find one bucket that is publicly accessible — anyone on the internet can read it. This is a clear failure of resource protection. You immediately apply a bucket policy that blocks public access. You also enable S3 server-side encryption and require that all uploads use encryption.

You then set up AWS CloudTrail to log every API call made in the account. Now, if someone tries to make a change, you will see exactly who did it, when, and from where. You also enable Amazon GuardDuty, a threat detection service that monitors for malicious activity.

Finally, you write a standard operating procedure that lists every team member's responsibility: developers must follow the principle of least privilege (only give the permissions needed to do the job), the database team must enable automated backups, and managers must review IAM permissions every quarter. You present this to your team: 'AWS secures the data centres, but we own our users, our data, and our configurations. This is our part of the model.'

A few weeks later, a new intern tries to delete an S3 bucket but cannot — because the IAM policy you wrote explicitly denies that action. The incident is prevented, not because AWS stopped it, but because you implemented your side of the shared responsibility correctly.

## Exam focus

The SOA-C02 exam tests the Shared Responsibility Model and Resource Protection heavily, especially in the 'Security and Compliance' domain (which is about 15-20% of the exam). Here is exactly what you need to know.

Expect scenario-based questions. The exam will describe a situation: 'A company uses Amazon EC2 and Amazon RDS. Who is responsible for patching the guest operating system on the EC2 instance?' The answer is 'the customer'. The trap is that the question might include RDS, where AWS patches the OS, so candidates who confuse services will get it wrong.

Key exam topics:\
- The exact boundary for each service: IaaS (EC2) vs PaaS (RDS, Elastic Beanstalk) vs SaaS (Amazon WorkSpaces). For IaaS, you manage more. For SaaS, AWS manages almost everything.\
- 'Resource protection' tools: IAM policies (identity-based and resource-based), S3 bucket policies and Access Control Lists (ACLs), Security Groups (stateful firewalls), Network ACLs (stateless firewalls), and AWS KMS for encryption key management.\
- The principle of least privilege: this appears in almost every exam. Remember the exact phrasing: 'grant only the permissions required to perform a task'.\
- Encryption in transit (TLS/SSL) vs at rest (S3 SSE-S3, SSE-KMS, or client-side encryption). The exam asks you to choose the right encryption option for a compliance requirement.\
- Shared Responsibility in a hybrid scenario: when using AWS Direct Connect or VPN, you are responsible for the customer gateway, and AWS is responsible for the AWS side of the connection.\

Common traps the exam sets:\
1. 'AWS is responsible for all security.' Wrong — that is a misconception the exam loves to test.\
2. 'If I use a managed service like RDS, I do not need to worry about access control.' Wrong — you still control who can connect to the database.\
3. 'IAM users are the only way to control access.' Wrong — IAM roles, groups, and resource-based policies also control access.\
4. 'Encryption is always enabled by default.' Not true — you must enable it for most services.\

Key definitions to memorise:\
- Shared Responsibility Model: divides security responsibilities between AWS and the customer.\
- IAM (Identity and Access Management): service for managing users, groups, roles, and permissions.\
- KMS (Key Management Service): managed service for creating and controlling encryption keys.\
- Security Group: virtual firewall at the instance level, stateful.\
- NACL (Network Access Control List): virtual firewall at the subnet level, stateless.\
- CloudTrail: logs API activity for auditing.\
- GuardDuty: threat detection service.\

Memorise the six key customer responsibilities: managing users, managing data, patching guest OS (for EC2), configuring firewalls, encrypting data, and managing applications. The exam will give you a list of tasks and ask you to identify which are the customer's responsibility.

## Step by step

1. **Identify Your Service Type** — Before you can know what you are responsible for, determine whether you are using IaaS (e.g., EC2), PaaS (e.g., RDS), or SaaS (e.g., WorkSpaces). This tells you where the boundary lies in the Shared Responsibility Model.
2. **Set Up IAM Users and Groups** — Create individual IAM users for every person who needs access. Place them into groups based on job function (e.g., Developers, DBAs). Assign permissions to the groups using IAM policies. This prevents using the root user and implements least privilege.
3. **Configure Network Firewalls** — Use Security Groups to control traffic to and from your EC2 instances (stateful, allow-only rules). Use NACLs to control traffic at the subnet level (stateless, allow and deny rules). Layer them so that even if one is misconfigured, the other provides protection.
4. **Enable Data Protection (Encryption and Backups)** — Encrypt data at rest using AWS KMS (S3, EBS volumes, RDS). Enable encryption in transit by using HTTPS or TLS. Configure automated backups for databases and versioning for S3. This is your responsibility under the model.
5. **Set Up Monitoring and Auditing** — Enable CloudTrail to log all API calls. Set up CloudWatch alarms for suspicious activity (e.g., unauthorised API calls). Enable GuardDuty for threat detection. These tools let you see what is happening in your account and prove compliance with security policies.
6. **Review and Update Regularly** — Schedule quarterly reviews of IAM permissions, Security Group rules, and encryption settings. Remove unused users and tighten overly permissive policies. The Shared Responsibility Model assumes ongoing attention, not a one-time setup.

## Comparisons

### Security Group vs Network ACL (NACL)

**Security Group:**
- Works at the instance level (ec2)
- Stateful: return traffic is automatically allowed
- Only supports allow rules

**Network ACL (NACL):**
- Works at the subnet level
- Stateless: return traffic must be explicitly allowed
- Supports both allow and deny rules

### IAM User vs IAM Role

**IAM User:**
- Has long-term credentials (password, access keys)
- Used for humans (developers, admins)
- Directly attached to a person

**IAM Role:**
- Has temporary credentials (assumed)
- Used for AWS services or federated users
- Assumed by an entity (e.g., EC2 instance)

### AWS Responsibility (IaaS) vs Customer Responsibility (IaaS)

**AWS Responsibility (IaaS):**
- Securing physical data centres
- Managing the hypervisor
- Replacing failed hardware

**Customer Responsibility (IaaS):**
- Patching the guest operating system
- Configuring Security Groups and NACLs
- Managing IAM users and permissions

### Encryption at Rest vs Encryption in Transit

**Encryption at Rest:**
- Data stored on disk is encrypted
- Commonly uses SSE-S3, SSE-KMS, or CSE
- Must be enabled per service

**Encryption in Transit:**
- Data moving between systems is encrypted
- Uses TLS/SSL protocols
- Often enabled via HTTPS or VPN connections

### Root User vs IAM Admin User

**Root User:**
- Has full, unrestricted access to everything
- Cannot be limited by IAM policies
- Should only be used for account-level tasks

**IAM Admin User:**
- Has permissions defined by IAM policies
- Can be restricted to specific services or actions
- Used for day-to-day administration

## Common misconceptions

- **Misconception:** AWS is responsible for securing everything, including my data. **Reality:** AWS secures the infrastructure, but you are responsible for securing your data, access policies, and applications. (Beginners assume 'cloud' means 'someone else handles all security', but the model clearly divides duties.)
- **Misconception:** If I use a fully managed service like Amazon RDS, I do not need to change any default settings. **Reality:** Even with managed services, you must configure access controls, encryption, and backup settings yourself. (People confuse 'managed' with 'fully secured out of the box', but defaults are often insecure.)
- **Misconception:** IAM users and root user are basically the same thing. **Reality:** The root user has unrestricted access and should never be used for daily tasks. IAM users have limited, controlled permissions. (Many beginners only know about the root account they created and think it is the normal way to log in.)
- **Misconception:** Security Groups and NACLs do the same thing. **Reality:** Security Groups operate at the instance level and are stateful. NACLs operate at the subnet level and are stateless. They have different rules and use cases. (Both act as firewalls, so beginners lump them together, but the exam tests their distinct behaviours.)
- **Misconception:** Once I set up IAM users, I do not need to review them again. **Reality:** Access rights must be reviewed regularly (e.g., quarterly) to remove unused users and revoke unnecessary permissions. (Static security is not real security; people forget that cloud environments constantly change.)
- **Misconception:** The Shared Responsibility Model is the same for all cloud providers and all services. **Reality:** The model is specific to each service type and each provider. AWS's model differs slightly from Azure's or Google's. (Beginners often generalise from one provider to another, but the exam tests AWS-specific boundaries.)

## Key takeaways

- AWS is responsible for security 'of' the cloud; you are responsible for security 'in' the cloud.
- The exact division of responsibility changes depending on whether you use IaaS, PaaS, or SaaS services.
- Always apply the principle of least privilege: grant only the specific permissions needed for a task and nothing more.
- Security Groups are stateful firewalls at the instance level; NACLs are stateless firewalls at the subnet level.
- You must enable encryption yourself for most AWS services; it is not on by default.
- CloudTrail, GuardDuty, and AWS Config are essential tools for auditing and monitoring your side of the shared responsibility.
- Never use the root user for everyday tasks; create IAM users with limited permissions instead.
- Managed services reduce your operational burden but do not remove your responsibility for data access and configuration.

## FAQ

**What is the Shared Responsibility Model in AWS?**

It is the division of security duties between AWS (who secures the infrastructure) and you (who secures your data, access, and configurations). You can find it in the official AWS documentation.

**Who is responsible for patching the operating system on an EC2 instance?**

You are. AWS patches the hypervisor, but the guest operating system on your EC2 instance is your responsibility.

**Does AWS encrypt my data by default?**

No, for most services. You must enable encryption manually. For example, Amazon S3 has server-side encryption options you need to turn on.

**What is the difference between a Security Group and a NACL?**

A Security Group is stateful and works at the instance level. A NACL is stateless and works at the subnet level. You use both together for defence in depth.

**Can I use the root user for daily admin tasks?**

No. The root user has full, unrestricted access and should only be used for account-level activities like changing your account settings. Create IAM users with limited permissions for daily work.

**What happens if I ignore my responsibilities under the Shared Responsibility Model?**

You create security gaps that can lead to data breaches, accidental deletions, or compliance failures. AWS will not be held liable for your misconfigurations.

---

Interactive version with quiz and diagrams: https://courseiva.com/learn/aws-sysops-associate/shared-responsibility-and-resource-protection