# 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.