Identity is the new perimeter

The previous lesson traced a line between what a cloud provider secures and what the customer must. On the customer’s side, one item does more work than any other: identity — who is allowed to sign in, and what they can then do. A traditional office network had a wall and a locked door; a cloud account has a login form, reachable from anywhere on earth, at any hour. Securing that login is most of what “security in the cloud” means in practice.

How accounts actually get taken over

Account takeover rarely involves an attacker breaking a cloud provider’s systems. It typically follows the credential-theft pattern from the threat-modelling course in this university: a password reused from a breached, unrelated service, or a convincing phishing page that simply asks for the login directly. Once an attacker has valid credentials, most cloud services have no way to distinguish them from the real account owner — which is exactly why the single control CISA highlights above all others is multi-factor authentication (MFA).

MFA, and why not all forms are equal

CISA states plainly that “users who enable MFA are significantly less likely to get hacked”, because a stolen password alone stops being enough. But CISA also ranks the available forms of MFA by how well they resist phishing, and the ranking matters: “the only widely available phishing-resistant authentication is FIDO/WebAuthn authentication” — the standard behind passkeys and hardware security keys, covered in the cryptography course. A text-message code is, in CISA’s words, still much better than no second factor, but it can be intercepted or relayed by a sufficiently motivated attacker; app-based push notifications with number matching sit in between. For a cloud account holding anything sensitive, turning on the strongest MFA option that account offers is the single highest-value step in this lesson.

OAuth: the permissions you grant to other apps

Every time you click “continue with Google” or connect a scheduling tool to your calendar, you are using OAuth, described by the standard’s own documentation as “the industry-standard protocol for authorization”. Its useful property is that the third-party app never sees your password — you log in directly with your provider, then approve a specific, limited set of permissions, called scopes, for that app. Its risk is exactly that permission grant: a scheduling app that only needs to read your calendar’s free/busy times may ask for, and be routinely granted, permission to read and send email as you. Each connected app is a standing grant of access that persists until someone revokes it, which is why the last lesson in this course covers reviewing that list, not just setting it up correctly once.

Leaked keys: OAuth’s less visible cousin

Automated tools and integrations often authenticate with an API key rather than a human login — a long string that functions like a password but is not typed by a person and often is not protected by MFA at all. These keys end up exposed more often than most people expect: pasted into a support ticket, committed accidentally to a code repository, left in a configuration file shared more broadly than intended. Treating an API key with the same caution as a password — never sharing it in plain text, rotating it if it may have been exposed, and limiting what it is allowed to do — closes a gap that MFA, built for human logins, does not cover.