Overview of Project ☁️

Scenario

A SaaS startup is moving its customer-facing application to AWS. During internal audits, the engineering team discovered that database credentials were hardcoded inside their Lambda functions and configuration files. Additionally, their RDS database was not encrypted, putting sensitive customer data at risk.

The company’s compliance team raised concerns about secrets exposure, unencrypted data, and lack of key rotation, all of which violate their internal security policies and upcoming regulatory requirements (e.g., SOC 2, GDPR).

Our Solution

We built a Secrets Management & Encryption System that ensures credentials and sensitive data are never exposed or stored insecurely. The system uses AWS Secrets Manager, KMS, and IAM to achieve secure, automated, and least-privilege data protection.

It enables the company to:

• Store and rotate database credentials automatically using AWS Secrets Manager.
• Encrypt the RDS database using a KMS Customer Managed Key (CMK).
• Fetch secrets dynamically from applications (e.g., Lambda) at runtime — without hardcoding.
• Enforce least-privilege IAM policies to restrict secret access.
• Validate that only authorized roles or users can retrieve credentials.

By implementing this, the startup now meets compliance requirements and ensures that even if code or infrastructure is compromised, secrets and data remain secure.

About This Project

In this project, you’ll learn how to combine Secrets Manager, KMS, and IAM to create a production-ready secret management and encryption workflow.

These concepts are critical because many real-world data breaches stem from hardcoded credentials or unencrypted storage.

As a Cloud Security Engineer, you’ll practice:

• Storing and rotating secrets securely in AWS Secrets Manager.
• Fetching credentials dynamically in a Lambda function.
• Encrypting an RDS database with a KMS CMK.
• Applying and testing least-privilege IAM roles and policies.
• Validating that both encryption and secret access meet compliance requirements.

By the end, you’ll have hands-on experience implementing enterprise-grade security controls used in regulated cloud environments.

Steps To Be Performed 👩‍💻

1. Create an encrypted RDS instance using a KMS Customer Managed Key (CMK).
2. Store database credentials securely in AWS Secrets Manager.
3. Enable automatic secret rotation using a Secrets Manager rotation Lambda.
4. Create a Lambda function (FetchDBSecretFunction) to fetch secrets and test RDS connection dynamically.
5. Attach IAM policies and roles for least-privilege access.
6. Test authorized and unauthorized access to validate proper restrictions.
7. Verify RDS encryption and confirm data protection in the AWS console.

Services Used 🛠

• AWS Secrets Manager → Secure credential storage and automatic rotation.
• AWS KMS (Key Management Service) → Encrypt RDS database using CMKs.
• AWS Lambda → Dynamically fetch secrets and connect to RDS securely.
• Amazon RDS (MySQL) → Encrypted database instance for secret retrieval.
• AWS IAM → Role-based least-privilege access control.
• Amazon CloudWatch → Monitor secret rotation and access activity.

Estimated Time & Cost ⚙️

• Estimated time: 2.5 - 3.5 hours
• Estimated cost: ~$1–$3 (mainly RDS instance runtime)

➡️ Architectural Diagram

This is the architectural diagram for the project:

➡️ Final Result

A secure, automated secrets management system where:

• Database credentials are stored and rotated automatically in Secrets Manager.
• The Lambda function connects to RDS without any hardcoded credentials.
• KMS CMKs encrypt all RDS data at rest.
• IAM roles ensure only authorized entities can access or decrypt secrets.
• Rotation and access logs are available for compliance auditing.

This project results in a fully secured, least-privilege AWS environment, foundational for compliant and production-grade architectures.