On premises, the perimeter is a firewall you can point at. In the cloud, the perimeter is a login. That shift changes almost everything about how you defend an environment.
This post walks through the ideas that matter most: who’s responsible for what, why identity is the real perimeter, and how a misconfigured identity leaves a trail in the logs you can go find.
The shared responsibility model
Every major cloud provider splits security into two halves. The provider secures the cloud itself: the data centers, the hardware, the network, and the hypervisor. You secure what you put in it: your identities, your data, your configurations and who can reach them.
Where the line sits depends on the service. With a virtual machine, you’re patching the operating system. With a managed database or a serverless function, the provider handles more and you handle less, but identity, access and data are always yours. Read how AWS and Microsoft each draw it.
A lot of cloud incidents don’t start with a clever exploit. They start on the customer’s side of that line, with an identity that has more access than it needs or a setting nobody checked.
Identity is the perimeter
Identity and Access Management, or IAM, decides who can do what to which resource. The vocabulary changes a little between AWS, Azure and Google Cloud. The ideas don’t.
- Identity: a person or a workload that can sign in. Users, groups, service accounts, roles.
- Role: a set of permissions an identity can take on, often temporarily.
- Policy: the document that grants or denies permissions. Read one closely enough and you’ll know exactly what an identity can do.
- Least privilege: give each identity only the permissions it needs, and nothing it might need someday.
- Long-lived credentials: access keys that never expire. They’re convenient, and they’re a common way in when one leaks into a code repository or a laptop backup.
Five misconfigurations worth recognizing
- A storage bucket or blob container readable by anyone on the internet.
- A role or policy that grants administrator-level access with a wildcard where a specific permission belongs.
- The root or global admin account used day to day, or left without MFA.
- Access keys that are years old and still active.
- Audit logging turned off, or turned on and never looked at.
The logs that catch it
Every provider records who did what through its control plane: AWS CloudTrail, the Azure Activity Log, and Google Cloud Audit Logs. When a permission changes, a key gets created, or a bucket goes public, there’s an event for it. Part of cloud security is knowing which events matter and making sure somebody gets told when they happen.
Try this: if a stranger got one of your access keys, what’s the first API call they’d make, and would anyone notice?
Practice without running up a bill
- Use the free tiers, and set a budget alert the day you open an account. Tear down what you build when you’re done.
- Work through flAWS, a free set of challenges built on common AWS mistakes. You don’t need an account of your own to play.
- Read the permissions on everything you deploy, even in a lab. That habit is most of the job.
Where this path leads
Cloud Security is one of the six career paths on Chrysalus. The roles are cloud security engineer and DevSecOps, and the credentials on this path include AWS and Azure security certifications and ISC2’s CCSP. The provider fundamentals exams are where most people start.
- Not sure cloud is your lane? Take the free career path assessment.
- Prep for the certs: AWS Cloud Practitioner, Azure Fundamentals (AZ-900) and CCSP.
- Browse every Cover6 course.
See it live with Cover6 Community
We cover this live in the Cover6 Community session Cloud Security Fundamentals: IAM to Detection on Wednesday, October 21 at 6:00 PM ET, streaming to the DMV, Atlanta and South Florida chapters at once. We’ll misconfigure an identity on purpose in a lab account we own, then go find the trail it left in the logs. Planning to attend? Use this post as your read-ahead. RSVP on Meetup or watch on YouTube. The replay gets added here afterward.