I’ve officially started my deep dive into DevSecOps. Before I write a single line of application code or launch a server, I need to secure my base. In the cloud, Identity is the new Perimeter. If your identity management is weak, your entire infrastructure is vulnerable.
The "Root" Problem
When I first created my AWS account, I had the Root User. This user is a "God Mode" account—it can delete everything and has no restrictions.
Rule #1 of DevSecOps: Never use the Root user for daily tasks. It’s like carrying the master key to a skyscraper on your keychain while walking through a crowded city. If you lose it, you lose the building.
🛠️ What I Did: The Hardening Checklist
1. MFA Everywhere
Multi-Factor Authentication (MFA) is not optional. I enabled a virtual MFA (Google Authenticator) for my Root account immediately. Even if my password leaks, a hacker can't get in without my physical phone.
2. Created the "Daily Driver" (IAM Admin)
I created a specialized IAM user named devsecops-admin. Instead of giving it "God Mode," I:
- Created a User Group called
Administrators. - Attached the
AdministratorAccesspolicy to the Group, not the user (Best practice!). - Added my user to that group.
3. Set a Custom Account Alias
Nobody wants to remember a 12-digit AWS Account ID. I created an alias so my login page is professional: https://[my-custom-name].signin.aws.amazon.com/console
4. The "Nuclear" Option: Deleted Root Access Keys
I checked my Root user's security credentials and ensured there were zero active Access Keys. If you have keys for your Root user, delete them now. Use IAM roles or users for CLI access instead.
💡 Key Takeaway
Security isn't something you "add" at the end of a project; it starts with how you log in. By shifting security to the very first step (Identity), I’ve already reduced my account's risk by 90%.
Next Step: Lesson 2 — Hardening the Linux OS and launching my first secure EC2 instance.
Top comments (0)