SecureCart's Journey

SecureCart is a cloud-native e-commerce platform built on AWS, designed to provide a secure, scalable, and high-performing shopping experience. Given the nature of e-commerce, SecureCart must protect customer data, prevent unauthorized access, and enforce strict security controls across its AWS infrastructure.

As SecureCart operates in a multi-account AWS environment, its security strategy aligns with Task Statement 1.1: Design Secure Access to AWS Resources, ensuring that access to AWS services is properly controlled, managed, and monitored.

Step 1: Define Access Requirements

Identify User & Service Access Needs

• Who needs access?

  • Developers → Need access to deploy and troubleshoot services.

  • Security Team → Requires full visibility but limited write permissions.

  • Application Services → Require controlled access to AWS resources (S3, RDS, etc.).

  • Third-Party Vendors → Need temporary, scoped access.

• What AWS resources need access control?

  • Compute (ECS, Lambda, EC2)

  • Storage (S3, EBS)

  • Databases (RDS, DynamoDB)

  • IAM & Security Controls (CloudTrail, GuardDuty, Config)

• Multi-Account Structure in AWS Organizations

  • Management Account → Governance & Security Controls.

  • Workload Accounts → Separate accounts for Dev, Staging, Production.

  • Security & Logging Account → Centralized logging, IAM monitoring, and threat detection.

---

Step 2: Establish Secure Identity and Access Management

Centralizing Identity with AWS Identity Center (SSO)

• AWS Identity Center (formerly SSO) for centralized authentication and access control.

• Federated access via Azure AD/Okta using SAML 2.0 or OIDC to allow seamless sign-in.

• Role-Based Access Control (RBAC) using IAM roles mapped to Identity Center permission sets.

• Enforce MFA for all users and assign role-based access (RBAC) to AWS accounts.

• Use Case: A developer logs in via Okta, assumes a role in AWS Identity Center, and gets read-only access to non-prod environments.

IAM Policies and Resource Policies

• IAM Policies (Identity-Based Policies) manage permissions at the user, group, or role level.

• Resource Policies are attached directly to AWS resources like S3, SNS, and SQS, controlling who can access them.

• Use Case: A Lambda function needs to access an S3 bucket—IAM policy grants it permissions, while the S3 resource policy ensures only Lambda can read its data.

• Use Case: A third-party service publishes messages to an SNS topic—a resource policy allows only the external AWS account to send messages.

Implementing IAM Role-Based Access

• No IAM users → Use IAM roles with temporary credentials.

• Principle of Least Privilege (PoLP) → Define custom IAM policies with only required permissions.

• IAM permission boundaries to restrict max permissions developers can grant themselves.

• IAM Access Analyzer to monitor unintended public access.

Applying Security Best Practices

• Follow the principle of least privilege—grant only the permissions required for a specific task.

• Use Service Control Policies (SCPs) in AWS Organizations to enforce security boundaries.

• Enable IAM Access Analyzer to detect overly permissive IAM policies.

• Use Case: To prevent developers from accidentally deleting production resources, SCPs block destructive actions in production accounts.

• Use Case: A CI/CD pipeline requires temporary permissions to deploy an application, so it assumes an IAM role with limited deployment access.

Leveraging IAM Tools for Enhanced Security

• IAM Access Analyzer: Detects misconfigured policies and alerts for excessive permissions.

• AWS Organizations SCPs: Enforces security guardrails across multiple accounts.

• IAM Credential Reports: Helps audit IAM users and identify stale access keys.

• IAM Policy Simulator: Tests and validates IAM policies before applying them to prevent misconfigurations.

---

Step 3: Enforcing Governance with AWS Organizations

Structuring AWS Organizations for Security & Governance

• Organizational Units (OUs) for different environments:

  • SecurityOU: Security & compliance enforcement.

  • WorkloadsOU: Dev, Staging, and Production workload accounts.

  • SharedServicesOU: Centralized CI/CD, logging, networking.

Applying Service Control Policies (SCPs) for Security Boundaries

• Prevent root user access with an SCP.

• Restrict usage of specific services (e.g., disallow Internet Gateway creation outside networking accounts).

• Enforce encryption for S3, RDS, and EBS with SCPs.

• Restrict AWS Region usage to comply with data residency laws.

Implementing IAM Permission Boundaries to Prevent Privilege Escalation

• Permission Boundaries define the maximum permissions an IAM role or user can be granted, preventing privilege escalation.

• Use case: Restricting a developer’s permissions, ensuring they can only assume specific roles without exceeding organizational limits.

• Use Case: Allowing teams to create IAM roles but preventing them from granting admin-level permissions.