Cloud security: the shared responsibility model and securing AWS and Azure accounts

Moving to the cloud does not hand security to someone else. It splits it. The provider secures the infrastructure; the customer secures what they put on it and who can reach it. Most cloud incidents happen on the customer’s side of that line: a storage bucket left public, an access key committed to a code repository, an administrator account without multi-factor authentication. This lesson gives the high-level picture; the course Understanding cloud security goes deeper.

The shared responsibility model

Amazon Web Services summarizes the split as security “of” the cloud versus security “in” the cloud. AWS is responsible for the physical data centers, hardware, networking and the virtualization layer. The customer is responsible for their data, identities and access management, operating systems and applications they run, network settings such as firewall rules, and encryption choices. Microsoft describes the same model for Azure, with one important nuance: the split moves depending on the service type.

Five controls that prevent most account compromises

1. Lock away the root or global administrator. AWS advises not using the root user for everyday tasks, enabling multi-factor authentication on it, and not creating access keys for it. Azure’s Global Administrator deserves the same treatment.
2. Require phishing-resistant multi-factor authentication for every human account, starting with administrators. Hardware security keys and passkeys resist phishing far better than text-message codes.
3. Apply least privilege. Give each person and each service only the permissions they need, and review them. Over-permissioned roles turn one stolen credential into a full takeover.
4. Prefer short-lived credentials to long-lived access keys. Keys that never expire end up in code repositories, laptops and chat messages.
5. Turn on logging and alerts (AWS CloudTrail, Azure activity logs) and actually look at them. You cannot respond to what you never recorded.

The classic mistakes

The same misconfigurations appear again and again in incident reports: storage buckets or blob containers readable by anyone on the internet, databases exposed with default settings, security groups that allow administrative access from any address, and secrets committed to public code. The US Cybersecurity and Infrastructure Security Agency (CISA) publishes a Cloud Security Technical Reference Architecture to help organizations structure these controls. The module on DevSecOps covers how teams catch such mistakes automatically before they reach production.

Your laptop is part of the cloud perimeter

Cloud accounts are often reached from ordinary laptops, and that is where attackers aim: a stolen browser session cookie or a command-line access key on a developer’s machine can be worth more than any exploit. Protecting the endpoint, keeping it updated, limiting which apps may connect where, is part of cloud security, not separate from it.

A ten-minute self-check for a small account

• Can you name every person and service that has administrator rights? If not, list them and remove anyone who no longer needs access.
• Does every human account, especially the root or global admin, use multi-factor authentication?
• Are any storage buckets, containers or databases reachable from the whole internet? Check each one deliberately.
• Are there access keys older than you can remember? Rotate or delete them.
• Is audit logging turned on, and does an alert reach a person when something important changes?
• Do you have a backup of critical data that the same credentials cannot delete?

None of these checks needs a specialist tool, and each one closes a door that attackers routinely try. Repeat the list every few months and whenever someone joins or leaves the team, because permissions and keys pile up quietly over time, and an account nobody remembers is an account nobody watches.