Introduction

Cloud breaches rarely happen because of sophisticated zero-days. Most incidents stem from misconfigurations, excessive permissions, or external factors.

If you're running workloads in Amazon Web Services (AWS), the good news is that (most of the time) you can significantly improve your security posture in under an hour.

In this blog we'll be going through five high-impact, low-effort actions you can take today to instantly make your AWS account more secure.

1. Turn on MFA Everywhere (Especially for Root)

"They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." ~ Benjamin Franklin

Turning on MFA is perhaps one of the easiest things that many times, we don't ever bother doing, but do we really want our AWS auth creds to be the single point of failure for our entire infrastructure? The root account has unlimited power. If it's compromised, your entire cloud environment is at risk.

What to do:

Enable MFA on the root account
Require MFA for all IAM users
Prefer hardware or virtual MFA over SMS

How to check root MFA

Go to:

AWS Console → IAM → Account settings

Or via CLI:

aws iam get-account-summary

Look for:

"AccountMFAEnabled": 1

If it’s 0, fix this immediately.

2. Remove or Lock Down Unused IAM Users & Access Keys

Old IAM users and long-lived access keys are one of the most common entry points for attackers.

What to do:

Delete unused IAM users
Rotate old access keys
Disable access keys that haven’t been used in 90+ days
Move toward role-based access (IAM Roles instead of IAM Users)

List access keys:

aws iam list-access-keys --user-name <username>

Check last usage:

aws iam get-access-key-last-used --access-key-id <key-id>

If you see keys that haven’t been used in months — remove them.

3. Block Public Access to S3 (Account-Wide)

Misconfigured S3 buckets have exposed millions of records over the years.

Even if you think you don’t have public buckets, verify it.

What to do:

Enable Block Public Access at the account level.

S3 → Block Public Access settings (for account)

Make sure all four options are enabled:

Block public ACLs
Ignore public ACLs
Block public bucket policies
Restrict public bucket policies

CLI:

aws s3control put-public-access-block \
  --account-id <account-id> \
  --public-access-block-configuration \
  BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true

This alone prevents a massive class of data exposure risks.

4. Enable CloudTrail in All Regions

If you’re not logging, you’re blind.

AWS CloudTrail records API activity across your account — which is critical for:

Incident response
Detecting suspicious activity
Compliance requirements

What to do:

Ensure CloudTrail is enabled
Enable it in all regions
Send logs to a secure S3 bucket
Enable log file validation

CLI:

aws cloudtrail describe-trails

Look for:

IsMultiRegionTrail: true
LogFileValidationEnabled: true

If not, create or update your trail.

Without CloudTrail, you won’t know what happened after a breach.

5. Restrict Security Groups (Kill 0.0.0.0/0 Where It’s Not Needed)

One of the most dangerous configurations in AWS:

0.0.0.0/0 → Port 22 (SSH)
0.0.0.0/0 → Port 3389 (RDP)
0.0.0.0/0 → Database ports (3306, 5432)

This means anyone on the internet can try to connect.

What to do:

Remove public SSH/RDP access
Use a bastion host or AWS SSM Session Manager
Restrict access to known IP ranges
Review inbound rules across all security groups

Find overly permissive rules:

aws ec2 describe-security-groups \
  --query "SecurityGroups[*].IpPermissions[*].IpRanges[*].CidrIp"

Look for:

0.0.0.0/0

If you see it on sensitive ports, fix it immediately.

Bonus: Turn On AWS Security Hub

If you want centralized visibility across misconfigurations, enable AWS Security Hub.

It aggregates findings from:

IAM
S3
EC2
CloudTrail
GuardDuty
And more

But here’s the catch: native tools show alerts — they don’t always give you continuous context, risk prioritization, or attack path analysis.

That’s where a modern CNAPP like Nulink Security fits in.

Why This Isn’t Enough (And What Mature Teams Do Next)

These five steps dramatically reduce risk. But they don’t solve:

Cross-account visibility
Identity-to-resource attack paths
Over-permissioned roles
Lateral movement detection
Continuous misconfiguration drift
Multi-cloud posture management

As environments scale, security must move from reactive checks to continuous cloud posture management.

That’s exactly what Nulink Security’s CNAPP is designed to provide:

Continuous misconfiguration detection
Identity risk analysis
Runtime visibility
Attack path mapping
Automated remediation workflows

Alt text

Discover Our Latest Blog Posts

5 Quick Things You Can Do in Your AWS Account to Become Instantly More Secure