30.1 The Shared Responsibility Model
Quick answer: the short, self-contained version of this lesson is the guide What Is Cloud Security? Beginner’s Guide.
AWS explains cloud security with the Shared Responsibility Model:
| AWS is responsible for ("security of the cloud") | You are responsible for ("security in the cloud") |
|---|---|
| Data centres, physical security, guards | IAM users, passwords, MFA, access keys |
| Hardware, network cables, hypervisor | Security groups and network design |
| The managed service software itself | OS patching on EC2 (sudo yum update) |
| Global infrastructure availability | Encryption choices, S3 bucket permissions |
| Your application code (OWASP, Chapter 29) |
The line moves with the service. On EC2 you patch the OS; on RDS AWS patches the database engine but you still control who can connect; on S3 AWS runs storage but you decide whether a bucket is public.
Ravindra Bagale's Tip
Students think "It's on AWS, so it's safe." Wrong! AWS doesn't make your bucket public – you do. If you read the news about cloud breaches, the cause is usually misconfiguration, not AWS being hacked. Take care of your own side yourself.
Ravindra Bagale's Tip – मराठी
Students ना वाटते "AWS वर आहे म्हणजे safe आहे". चूक! AWS तुमचा bucket public करत नाही – तुम्ही करता. Cloud breach च्या बातम्या वाचल्या तर बहुतेक वेळा कारण misconfiguration असते, AWS hack नाही. तुमची बाजू तुम्हीच सांभाळा.
Ravindra Bagale's Tip – हिंदी
Students को लगता है "AWS पर है मतलब safe है". गलत! AWS आपका bucket public नहीं करता – आप करते हो. Cloud breach की खबरें पढ़ो तो ज़्यादातर वजह misconfiguration होती है, AWS hack नहीं. अपनी तरफ़ की ज़िम्मेदारी खुद संभालो.
Practice task
For your reels app (EC2 + S3 + RDS from Chapter 16), make a two-column table: list five things AWS secures and five things you must secure yourself.
Real incident: IDCF Cloud (Japan) – ransomware hits a SoftBank cloud region used by 495 companies and local governments (Oct 2026)
1. What happened
On 7 October 2026 at about 3:40 AM Japan time, IDC Frontier (a SoftBank Group subsidiary) said a ransomware attack disrupted East Japan Region 1 of its IDCF Cloud service – an infrastructure-as-a-service platform that rents virtual servers, storage and networking in Japanese data centres. The company confirmed a third-party ransomware attack caused the outage and said it was still investigating the exact cause and full scope. About 495 companies and local governments that use that cloud region were affected. After detecting the attack, IDC Frontier isolated and shut down the impacted systems so the compromise would not spread, started closing the intrusion path, and turned off customer access to management consoles for all regions until those consoles were checked as safe. Before customers were locked out, screenshots showed a message from the threat actor claiming a very fast breach of that region and claiming they had encrypted databases, reached hypervisors, sealed virtual-machine disks and wiped snapshots. Treat those size claims as attacker claims only – the company has not verified them in public. Separately, seafood group Nissui said its logistics unit had an outage tied to suspected unauthorised access at a third-party data centre; whether that is linked to IDCF Cloud is not confirmed. Educational framing only.
2. How the hack happened (public reporting only – high-level)
- A third party reached IDCF Cloud's East Japan Region 1 infrastructure (the exact first entry path is still under investigation and not published).
- The disruption hit the shared cloud layer that many customer virtual servers, databases and networking depend on – one region problem, many tenants affected.
- The company shut down and isolated that region to stop spread, which is why customer systems in that cluster went offline together.
- Customer management consoles for every region were locked until security checks finished – so even tenants in other regions could not use the admin panel for a time.
- The attacker claimed (not company-confirmed) deep impact on databases, hypervisors, VM disks and snapshots – the teaching point is that snapshots on the same compromised plane are not a safe recovery plan.
- Recovery work focused on finding and blocking the intrusion route and verifying other regions before opening consoles again.
3. How to stop it / defend (this lesson: Shared Responsibility)
- Remember both sides of the model: the cloud provider secures the data centre, hardware and hypervisor ("of the cloud"); you still secure IAM, network rules, encryption and your app ("in the cloud"). When the provider's region is hit, your apps in that region can still go down – plan for that.
- Do not put every critical workload in one region or one provider account. Keep a tested failover or warm standby in another region (or another provider) for systems that must stay up.
- Backups the region ransomware cannot wipe: keep at least one copy offline, immutable, or in a separate account/region with different credentials – same lesson as Code Spaces later in this chapter.
- Break-glass access: a separate recovery identity and an offline runbook for "cloud console locked / region down", so you are not stuck when the provider freezes consoles.
- Monitor provider status and your own alarms: subscribe to the provider's status page, and alert on sudden mass VM/disk failures and unusual admin activity (Chapter 30.5 detection tools).
- Contracts and DR drills: know what the provider's SLA covers, practise restoring from your own backups, and never assume "it is in the cloud so it is safe."
4. How to take care so it won't happen again (checklist)
- [ ] Draw your Shared Responsibility table for each service you use (EC2, RDS, S3, and any other cloud) and mark what fails if the provider region fails.
- [ ] List which apps must survive a single-region outage; for each, write the failover region or backup provider.
- [ ] Confirm one backup copy lives outside the same cloud account/region credentials, and write the date of the last successful restore test.
- [ ] Keep a printed or offline "region down / console locked" checklist with break-glass contacts.
- [ ] Turn on billing and health alarms; subscribe to the provider status feed.
- [ ] India students: many Indian SaaS and government workloads run on one cloud region – the same multi-region and offline-backup checklist applies; report major incidents to CERT-In within the required time (see Ch.34).
Source: BleepingComputer, Bill Toulas, "Ransomware attack disrupts Japan's IDCF Cloud used by govt clients", 8 October 2026; IDC Frontier / IDCF Cloud public incident announcement quoted therein (attack start 7 October 2026 ~03:40 JST; 495 companies and local governments affected).
Check if you're safe: Website Security Checklist