Your AWS Account Has Security Holes. Here's How to Find Them Fast

I never went hunting for security problems in my own AWS account. Liberra told me first. It told me: an open port, a public S3 bucket, a bucket sitting without versioning turned on, and MFA missing on my IAM setup. Four things, all real, all things I should have caught myself.

There was no oh-no moment. It was an oh-thank-you moment. That's what a security check should feel like. Not a scramble after something's already gone wrong, just being told, plainly, what's open and why it matters.

The holes that actually bite small accounts

The most common one is a security group with port 22 (SSH) or a database port open to 0.0.0.0/0. That string means open to the entire internet, not just your laptop or your office. Anyone, anywhere, can attempt a connection. It usually happens because someone opened it wide to get unblocked while setting things up, and never closed it back. Check it under EC2, Security Groups, look at the inbound rules, and see which ones list 0.0.0.0/0 as the source.

Public S3 buckets are next, and they're rarely intentional. S3 permissions live in two places, bucket policies and ACLs (access control lists), and the two can disagree with each other in ways that are genuinely confusing even once you know what you're doing. A policy written for one file can end up covering the whole bucket. Check the Permissions tab on any bucket in the S3 console, specifically Block Public Access and the bucket policy itself.

IAM users without MFA (multi-factor authentication) are a quieter risk. A password alone protects an account. A password plus a code from your phone protects it a lot more, because a leaked password stops being enough on its own. Check this under IAM, Users, the MFA column shows you who has it turned on and who doesn't.

Access keys that haven't been rotated in years are the kind of thing nobody remembers exists. A key made for a one-time script, years ago, can still be active today, still valid, still able to do whatever it was given permission to do. IAM, Users, Security credentials shows you the age of every key.

CloudTrail not enabled means there's no record of who did what in your account. CloudTrail is AWS's log of every action taken, by a person or by a script. Without it, if something goes wrong, you're guessing instead of checking. It costs close to nothing to turn on. Check it under CloudTrail, Trails.

S3 versioning off means there's no undo. Overwrite a file or delete it by mistake and it's gone, no history to pull it back from. Versioning keeps every version of an object so a mistake stays reversible instead of becoming permanent. It's a checkbox in the same Properties tab on the bucket.

Ask, don't hunt

This is where Liberra fits in. Your account is indexed, security findings included, so asking "any security issues?" gets you an answer from what it already knows, instantly. No clicking through every security group, every bucket, every IAM user one at a time. Reads are free, no approval needed, and it explains why something is risky in plain English instead of dropping a raw alert on you and walking off.

Fixing something is different. Any change waits for your approval before it runs, and the risky ones, opening a port to the world, making a bucket public, ask again every single time, even if you already said yes to something else earlier in the conversation. Deletes are blocked outright, in the code, not as a setting you could switch off. That part stays on you, in the console, on purpose.

Founder, Liberra AI