I was on a pentest last week, and on the surface, everything looked solid. Firewalls were up, the EDR (Endpoint Detection and Response) was catching almost everything, and getting in from the outside seemed nearly impossible. But the truth is, most of the time you don't even need to kick the door down—someone has usually left the key under the mat.
This "key" issue, or Identity Management (IAM), is often the softest spot in cybersecurity, yet for some reason, it’s always the last thing companies worry about.
I see this all the time: companies spend millions on security infrastructure, but then a developer—just trying to get things done quickly—writes a script with hardcoded AWS keys. Suddenly, that million-dollar investment is worth zero. Identity management isn't just about usernames and passwords. It’s about who gets access to what, for how long, and under what conditions. And honestly, I can count the number of companies that actually get this right on one hand.
Disasters That Start With "It's Only Temporary"
I remember during one pentest, I managed to get into a Jenkins server. Initially, my permissions were pretty restricted. But then I found it: a system admin had hardcoded their own privileged account into an automation script months ago to "debug" a problem. They probably told themselves, "I'll delete this once I'm done," but that day never came.
This is what we call "Identity Sprawl." These are the identities that grow uncontrollably, get forgotten, and are never tracked. If you’re giving a user more permissions than they need "just in case," you’re essentially building a highway for an attacker. In Red Team ops, our favorite thing is to compromise a low-level user and use their unnecessary "read" or "list" permissions to map out the entire network.
In the Cloud, Identity Is the New Network
We used to have this mindset of "I'm inside the internal network, so I'm safe." Those days are over. Now, everything revolves around Identity. If you’re using AWS, Azure, or Google Cloud, your IAM rules are just as critical as your firewall rules. Leaving an S3 bucket open to the public is a mistake, but having an IAM role with "AdministratorAccess" attached to a service that only needs to read one file is a total disaster.
Here’s something you really need to watch out for: Service Accounts. We’ve mostly figured out how to protect human accounts with MFA (Multi-Factor Authentication). But what about "machine identities" that apps use to talk to each other? They don't have MFA. They usually sit somewhere as a hardcoded token in a config.yaml or as an environment variable.
For example, look at this simple Python snippet. I still see stuff like this way too often:
import boto3
# WHAT YOU SHOULD NOT DO:
# These keys will eventually leak somewhere (GitHub, log files, etc.)
ACCESS_KEY = "AKIAXXXXXXXXXXXX"
SECRET_KEY = "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"
client = boto3.client(
's3',
aws_access_key_id=ACCESS_KEY,
aws_secret_access_key=SECRET_KEY
)
def download_data():
# We are downloading sensitive data...
pass
The fix isn't complicated, but it requires a change in habits. Use IAM Roles, use temporary tokens, and for heaven's sake, follow the principle of least privilege. If a service only needs to upload a file, don't give it permission to delete the entire bucket.
I'm still learning new ways these things can break every day, but one thing is clear: if you don't manage your identities, someone else will eventually do it for you. And you won't like how they do it.