3.3.1.5. Security by Design and Least Privilege

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

Least-Privilege Design and Evidence-Based Right-Sizing:

• Policy design: Name the specific actions and the specific resource ARNs, add conditions where possible (for example scope an EBS snapshot permission to one volume ARN), and avoid Resource: "*", service:* and broad managed policies (AmazonEC2FullAccess, PowerUserAccess) for a workload. Deliver permissions through a role (an EC2 instance profile, a task role) so credentials are temporary; a long-term access key in a config file is never the answer, even with manual rotation.
• "IAM Access Analyzer": External access findings show resources (S3 buckets, IAM roles, KMS keys, SQS queues and others) shared outside the account or organization, including public or untrusted cross-account S3 exposure. Unused access findings list roles, users, keys and permissions never used (organization-wide when the analyzer is created at the organization level). Policy generation builds a least-privilege policy from a role's or user's "CloudTrail" activity (up to 90 days). IAM access advisor (last-accessed information) shows which services, and for some services which actions, a principal used and when; "CloudTrail" event history (90 days of management events, no trail needed) can be filtered by the role to list the API calls it actually made. "Config" rules, "GuardDuty" and "Trusted Advisor" do not show which granted permissions are unused.

⚠️ 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?