Lesson 4 of 4 · 8 min
Hardening your cloud accounts
A short, repeatable review: who is signed in, what apps can reach your account, whether your backups exist, and whether you would notice if something went wrong.
The previous three lessons in this course covered who is responsible for what, why identity is the real perimeter, and what happens to your data once it is stored. This lesson turns that into a short, periodic review — the kind of maintenance a small organisation can realistically keep up, rather than a one-time setup that quietly goes stale.
Review active sessions and devices
Every major account provider keeps a list of devices and sessions currently signed in, and a log of recent activity. Reviewing it periodically answers a simple question: is anyone in this account besides the people who should be? An unfamiliar device, a sign-in from an unexpected location, or a session that never signed out on a device you no longer own are all worth acting on immediately — ending the session and changing the password. This directly follows from the identity lesson earlier in this course: a stolen password only stays useful to an attacker for as long as the resulting session goes unnoticed.
Review third-party app access
The identity lesson also covered OAuth: every “continue with” connection or calendar integration is a standing grant of access that persists until revoked. Most providers list every connected app under an account’s security or privacy settings, showing what each one was granted — read email, manage calendar, access files — often for a service you tried once years ago and forgot about. A repeated occasional prune of this list, removing anything unused or unrecognised, shrinks the number of ways into an account without touching the password at all.
Confirm backups actually exist, and where
A cloud account failure — a lockout, a mistaken deletion, a service outage — is itself a risk the shared-responsibility lesson placed on the customer’s side of the line. The GitHub-published cloud security guide this lesson cross-checks against lists “backups, tested recovery” among the core resilience practices it recommends, alongside routine credential rotation and access reviews; this lines up with the equivalent guidance major providers publish for their own customers. For an individual or small organisation, that translates into two concrete habits: know where your backup actually lives (a second cloud service, an encrypted external drive, or both), and actually test restoring from it occasionally, since a backup nobody has opened is only a hope, not a plan.
Turn on logging and alerts where they exist
Most consumer and small-business cloud accounts offer some form of security notification — an email or push alert for a new sign-in, a password change, or a new device added. These are usually opt-in or buried in settings rather than defaults. Turning them on costs nothing and directly shortens the gap between an account being compromised and someone noticing, which is often the single biggest factor in how much damage an intrusion does.
| Review this | What you are checking for | Where this connects in this course |
|---|---|---|
| Active sessions and devices | A sign-in you do not recognise | Identity is the perimeter — a live unnoticed session is an open door |
| Third-party app access (OAuth) | A permission grant you no longer need or never meant to give | The same standing-access risk covered in the identity lesson |
| Backups | Whether one exists, where, and whether it has ever been tested | The customer-side resilience responsibility from the shared-responsibility lesson |
| Logging and alerts | Whether you would actually be notified of a suspicious sign-in or change | Shortens the time between compromise and detection |
Making this a habit, not a one-time task
None of these four checks takes more than a few minutes individually, and none of them requires a security background. What makes them effective is repetition: a quarterly pass through sessions, connected apps, backup status, and alert settings catches the slow accumulation of forgotten access that a single setup session never will. This closes the loop this course opened with the shared responsibility model: the provider secures the infrastructure once and maintains it continuously; the customer’s side of that same bargain is a habit, not a task to finish.
Key takeaways
- Periodically review active sessions and signed-in devices, and end anything unfamiliar immediately.
- Review and prune third-party app access (OAuth connections); each one is a standing grant that outlives the reason it was created.
- Confirm backups exist, know where they live, and test restoring from them occasionally rather than assuming they work.
- Turn on security notifications for new sign-ins, password changes, and new devices — they shorten the gap between compromise and detection.
- These reviews work as a repeated habit, not a one-time setup; forgotten access accumulates quietly between reviews.
Check yourself
1. Why is it worth periodically reviewing active sessions and signed-in devices on a cloud account?
- It improves the account’s storage quota
- It reveals whether an unauthorised session is currently active, which can be ended before more damage occurs — Right.
- It is required by law for all accounts
- It permanently blocks all future sign-in attempts
An unnoticed active session gives an attacker continued access even after a password is changed elsewhere; reviewing sessions catches this.
2. Why should third-party app access (OAuth connections) be reviewed periodically rather than set once?
- OAuth grants automatically expire after a day
- Each connected app is a standing grant of access that persists until manually revoked, and can be forgotten over time — Right.
- Reviewing it is required to keep the account active
- Third-party apps cannot access any account data
A permission granted years ago to a now-unused app remains active until someone revokes it, so periodic review is the only way to catch and remove it.
3. What makes a backup meaningfully useful, beyond simply existing?
- It should never be tested, to avoid corrupting it
- It should be tested by actually restoring from it occasionally — Right.
- It only needs to exist on the same device as the original data
- Backups are unnecessary if the cloud provider encrypts data at rest
A backup that has never been restored from is unverified; testing the restore process confirms it will actually work when needed.
Do it with FireAI
Put this lesson into practice on your own Mac.
- Find out where an app sends data, on the World map — See exactly which company and country one app is quietly talking to.
- Rules: app, website, domain, IP or a range, forever or until you restart — Write a rule as precise as one address or as broad as an entire domain.
- The Threats page: what looks wrong, and why — See the handful of connections worth your attention, instead of scrolling through thousands.
Sources
- CISA: More than a Password (Multi-Factor Authentication)
- AWS: Shared Responsibility Model
- hacrex: Cloud Security Best Practices (secondary reference, cross-checked against official provider documentation)
Put it into practice on your Mac
Try every feature free for 17 days, no card needed.