Cloud Security Basics: The Shared Responsibility Model and Common Mistakes
Introduction
Moving to the cloud does not move all security responsibility to the provider. Providers secure their infrastructure, and you secure how you use it. Most cloud breaches come from customer misconfiguration, not from provider failures. This lesson explains the shared responsibility model and the habits that prevent the most common problems.
Prerequisites
- The cloud fundamentals lesson
Step-by-Step Guide
Step 1: Understand the shared responsibility model
The provider is responsible for security of the cloud: physical data centers, hardware, and the core services. You are responsible for security in the cloud: your data, who can access it, how services are configured, and your operating systems and applications where you manage them. The more managed the service, the more the provider handles, but identity, data, and configuration always remain yours.
Step 2: Put identity first
Protect accounts with multi-factor authentication, especially the powerful root or global administrator account, and avoid using that account for daily work. Give people and applications only the permissions they need (least privilege), prefer short-lived credentials and role-based access over long-lived keys, and never put access keys in source code or public repositories.
Step 3: Keep the network closed by default
Allow only the traffic you need. Do not expose management ports such as SSH or remote desktop to the whole internet, put databases in private networks with no public address, and use security groups or firewall rules that name specific sources. Review rules periodically, because temporary openings tend to become permanent.
Step 4: Protect the data
Encrypt data at rest and in transit, which most services support with a setting rather than code. Keep storage private unless public access is a deliberate decision, and use the provider's controls that block accidental public exposure. Back up important data and test restoring it.
Step 5: Log, monitor, and alert
Turn on audit logging for account activity, send logs somewhere that attackers cannot easily erase, and alert on risky events such as root logins, new access keys, and policy changes. You cannot respond to what you cannot see.
Quick cloud security checklist
- MFA on every human account, strongest on admin/root
- No access keys in code, chat, or screenshots
- Least-privilege roles instead of broad admin rights
- No public storage unless intentional and reviewed
- No SSH/RDP open to the whole internet
- Encryption on, backups tested
- Audit logs on, alerts for root/admin activityFAQs
- What is the most common cloud security mistake?
- Misconfiguration: publicly exposed storage, overly broad permissions, and leaked credentials. Careful defaults, reviews, and automated checks prevent most of them.
- If I use fully managed services, am I off the hook?
- No. Even with SaaS you still control who has accounts, how they sign in, and what data is stored. Those parts are always the customer's responsibility.
Summary
The provider secures the platform and you secure your use of it. Lock down identity with MFA and least privilege, keep networks and storage private by default, encrypt and back up data, and log and alert on important events.
Related tutorials
- Google Cloud Storage Basics: Buckets, Objects, and Access Control
- Google Cloud Getting Started: Projects, IAM, and the gcloud CLI
- Azure Blob Storage Basics: Accounts, Containers, and Secure Access
- Azure Getting Started: Subscriptions, Resource Groups, and the Azure CLI
- Amazon S3 Basics: Buckets, Objects, Versioning, and Safe Sharing
Comments
Log in or create a free account to join the discussion.