Gabe Bidot

When I first launched CyberLab, I wanted to keep things simple. A lightweight setup with Next.js, Supabase, and Vercel gave me a safe space to explore vulnerabilities and learn by doing. But security in the cloud doesn't live in simple environments. Enterprises run workloads across dozens of services, with hundreds of settings that can go wrong. If I wanted to learn how to secure those environments, I needed to get closer to the real thing. That's where Amazon Web Services (AWS) and Terraform came in.

Why AWS and Terraform?

Amazon Web Services (AWS) is the backbone of modern infrastructure. Nearly every company I work with is running some part of their stack in AWS, and the security challenges scale with the complexity. I wanted CyberLab to reflect that reality, not just a toy example.

Terraform became the natural choice for deployment. Writing infrastructure as code forces you to be explicit, repeatable, and auditable. Clicking through the AWS console might get you started, but you won't learn how infrastructure behaves under version control, or how small missteps in code can open big security holes. With Terraform, every decision I made became part of a tracked history — both the good choices and the mistakes.

Building the Vault

The first major addition to CyberLab was an Amazon Simple Storage Service (Amazon S3) vault. The goal was to simulate how enterprises use S3 to store backups that need to be resilient against ransomware or insider mistakes.

I focused on four key areas:

1. Versioning

Versioning ensures that even if a file is overwritten or deleted, older versions remain available. Without versioning, a single compromised account could delete every backup in seconds.
In practice, this gave me a way to test how data "rollbacks" could save a system from an incident.

2. Object Lock

Object Lock takes the protection further by enforcing immutability. When it's enabled, data can't be altered or deleted for a set retention period.
This matters because ransomware doesn't just encrypt production data — it often targets backups too. Without immutability, an attacker can wipe out the very thing you'd rely on to recover. With Object Lock, I essentially created a write-once-read-many policy that even administrator credentials can't bypass.

3. Encryption with AWS Key Management Service (KMS)

I enabled server-side encryption using AWS KMS to ensure every object stored in S3 was encrypted by default.
What stood out to me wasn't just turning it on, but understanding the role keys play in security. A poorly managed key is as dangerous as leaving your data unencrypted. I started experimenting with policies around key rotation and access, which highlighted how easy it is to unintentionally grant broad permissions.

4. IAM Policies

With Terraform, defining IAM roles and policies is as simple as a few lines of code. That's both a blessing and a curse. It's far too easy to copy a resource policy from the internet and paste it without realizing it grants way more access than needed.
I learned quickly that "least privilege" is more than a principle you read about — it's something you enforce line by line. Each overly broad role I caught became a reminder of how attackers exploit misconfigurations, not zero-day exploits, to get in.

What I Learned

Expanding CyberLab into AWS with Terraform taught me that security is a process, not a switch you flip. Enabling a feature like Object Lock or KMS encryption isn't difficult. The real challenge is designing an environment where those settings work together, and then resisting the urge to take shortcuts when Terraform makes the insecure path easier.

What stuck with me most was how clear the risks became once I saw them in action. Reading about S3 best practices is one thing. Actually creating an S3 bucket without versioning, uploading files, and then realizing how easy it would be to lose them permanently is another. That's the kind of lesson that stays with you.

The Road Ahead

With a secure vault in place, the next step was visibility. How do I know if my Terraform configuration still has hidden flaws? How do I catch overly broad IAM permissions before they become dangerous? CyberLab needed tooling to surface those issues, which is where the next phase of the project began.

Ready to explore? Check out CyberLab and see the hands-on security learning platform in action. Remember: it's for educational and research purposes only!