3.3.1.5. Security by Design and Least Privilege

💡 First Principle: Integrating security considerations from the earliest stages of design, and ensuring every entity (human or machine) has only the bare minimum permissions required for its function, creates inherently secure systems.

Scenario: A development team frequently creates new AWS resources (e.g., "S3 buckets", "EC2 instances") for testing. The security team needs to ensure these resources are created with appropriate security configurations (e.g., encryption enabled, no public access) from the start, and that developers only have the minimum necessary permissions.

"Security by Design" means proactively building security into every architectural decision, rather than retrofitting it later.

• Shifting Left: Bring security considerations earlier into the development and design lifecycle (e.g., using security scans in "CI/CD", threat modeling during architecture reviews).
• Defense in Depth: Implement multiple layers of security controls (network, host, application, data, identity) so that if one layer is breached, others prevent or detect the intrusion.
• Principle of Least Privilege: Granting only the permissions required to perform a specific task, and nothing more.
  • Practical Relevance: Apply to "IAM users", roles, and resource policies. Review permissions regularly to remove unnecessary access. This limits the blast radius if an identity is compromised.
• Separation of Duties: Ensure no single person has control over all critical steps of a process. For example, the person deploying code should not be the only one able to approve it.
• Automation of Security Controls: Use "IaC" to define security policies (e.g., "CloudFormation" for "SGs", "NACLs", "IAM roles") and automate security monitoring (e.g., "Config Rules", "GuardDuty").
• Secure Defaults: Configure services with the most secure defaults (e.g., "S3 buckets" private by default, encryption enabled).

Visual: Security by Design & Least Privilege Workflow

Loading diagram...

⚠️ Common Pitfall: Delaying security reviews until just before deployment. At this late stage, fixing fundamental architectural security flaws is difficult, expensive, and can delay launch.

Key Trade-Offs:

• Developer Freedom vs. Security Guardrails: The goal is not to block developers, but to guide them toward secure choices by providing pre-approved, secure templates (e.g., via "Service Catalog") and automated checks that provide fast feedback.

Reflection Question: How would you apply the "Security by Design" principle and the "Principle of Least Privilege" using "IAM policies", "AWS Config Rules", and potentially "AWS Service Catalog" to guide developers towards secure defaults and limit their actions when creating new AWS resources for testing, specifically ensuring encryption and no public access from the start?