# Copy of Securing Access Across Multiple AWS Accounts

In a multi-account AWS environment, organizations must secure access across multiple AWS accounts while maintaining centralized control, scalability, and security best practices. AWS provides several mechanisms to achieve this, including IAM Identity Center (AWS SSO), IAM Roles with AWS STS, and AWS Organizations' SCPs.

This study guide covers how SecureCart secures multi-account access using role-based access control (RBAC), permission sets, and IAM roles to enforce least privilege access across multiple AWS accounts.

***

## **Multi-Account Setup**

Organizations, including SecureCart, adopt a multi-account AWS strategy to:

* Improve security isolation between workloads.
* Enable fine-grained access control for different teams.
* Enforce least privilege access across accounts.
* Centralize authentication and access management.

***

### **Common AWS Multi-Account Access Models**

| **Access Model**                    | **Best Used For**                                            | **Key AWS Services**                   |
| ----------------------------------- | ------------------------------------------------------------ | -------------------------------------- |
| **IAM Identity Center (AWS SSO)**   | Centralized authentication & access across multiple accounts | IAM Identity Center, AWS Organizations |
| **Cross-Account IAM Roles**         | Granting permissions across accounts without IAM Users       | IAM Roles, AWS STS                     |
| **Service Control Policies (SCPs)** | Restricting what accounts can do (Guardrails)                | AWS Organizations, SCPs                |
| **Resource-based Policies**         | Granting access to AWS resources across accounts             | S3, KMS, Lambda, SNS                   |

**Best Practice:** Use IAM Identity Center for user authentication and IAM Roles for service-to-service access.

***

## **IAM Identity Center for Multi-Account Access**

**AWS IAM Identity Center (SSO)** provides

* **Centralized authentication** across multiple AWS accounts.
* **Federated login** with corporate identity providers (Okta, Azure AD, etc.).
* **Role-based access via Permission Sets.**

**Why SecureCart Uses IAM Identity Center Instead of IAM Users**

* Eliminates the need for multiple IAM Users.
* Provides a single sign-on (SSO) experience for all AWS accounts.
* Integrates with corporate identity providers (Okta, Azure AD) for authentication.

***

## **How SecureCart Implements IAM Identity Center**

* Step 1: Enable IAM Identity Center in AWS Organizations
* Step 2: Create IAM Identity Center Groups for SecureCart
  * `SecureCart-Developers`
  * `SecureCart-Security`
  * `SecureCart-Finance`
* Step 3: Users are added to the groups
* Step 4: Define Permission Sets Based on Roles
  * A Permission Set defines what users can do in AWS accounts
* Step 4: Assign IAM Identity Center Groups to AWS Accounts and Select the Permission 
  * IAM Identity Center now provisions IAM Roles in AWS accounts for the SecureCart Developers Group.
  * When assigned to a Group, IAM Identity Center automatically creates an IAM Role in each account.

***

## **Cross-Account IAM Roles for Services**

Cross-Account IAM Roles allow AWS services in one AWS account to access resources in another AWS account securely.

**Scenario:** SecureCart’s CI/CD Pipeline Deploying Across AWS Accounts

**Requirement:** SecureCart’s CI/CD pipeline in the DevOps AWS account needs to deploy applications to the Production AWS account.<br>

**Solution:**

* &#x20;Create an **IAM Role in the Production Account** that allows DevOps to assume it.
* SecureCart’s CI/CD pipeline **assumes this IAM Role using AWS STS**.
* Now, the DevOps account can securely deploy applications in Production without hardcoded credentials.

***

## &#x20;**IAM Identity Center (AWS SSO) Use Case: Cross-Account Role Access**

SecureCart **manages multiple AWS accounts** (Dev, Staging, Prod). Instead of creating IAM Users in each account, SecureCart **uses IAM Identity Center (AWS SSO) to manage cross-account access**.

✅ **IAM Identity Center Assignments:**

| **User Group**          | **AWS Account** | **Permission Set (IAM Role)** |
| ----------------------- | --------------- | ----------------------------- |
| `SecureCart-Developers` | `Dev`           | `AdministratorAccess`         |
| `SecureCart-Developers` | `Staging`       | `PowerUserAccess`             |
| `SecureCart-Developers` | `Production`    | `ReadOnlyAccess`              |
| `SecureCart-Ops`        | `All Accounts`  | `AdministratorAccess`         |
| `SecureCart-Support`    | `Production`    | `ReadOnlyAccess`              |

📌 **Impact:**\
✅ **Users log in via IAM Identity Center (AWS SSO) and assume the correct IAM Role automatically.**\
✅ **No need for IAM Users or long-term credentials.**

***

## **📌 Key Takeaways for SecureCart**

🔹 **RBAC ensures that access is granted based on job roles.**\
🔹 **IAM Roles replace IAM Users, reducing security risks.**\
🔹 **Temporary credentials eliminate hardcoded access keys.**\
🔹 **AWS STS enables secure, time-limited access for external users.**\
🔹 **IAM Identity Center centralizes access across multiple AWS accounts.**

## **Enforcing Guardrails with Service Control Policies (SCPs)**

Service Control Policies (SCPs) are organization-wide policies that help enforce governance and security controls across multiple AWS accounts in an AWS Organizations setup.

**Key Characteristics of SCPs**

* SCPs do not grant permissions but instead restrict actions that IAM Roles, IAM Users, and AWS Root Users can perform.
* SCPs apply at the AWS Organizations level, meaning they affect all IAM identities (users, roles, and groups) in an account.
* SCPs can be applied to AWS Accounts, Organizational Units (OUs), or the Root Organization.
* SCPs do not override IAM permissions, but they act as guardrails to prevent unauthorized actions.

Think of SCPs as a "deny by default" framework that ensures certain actions are always blocked—even if an IAM policy allows them.

* **SCPs restrict what AWS accounts can do** (even if an IAM Role has permissions).
* **Best Practice:** SecureCart uses **SCPs to block high-risk actions**.

**Example SCP: Deny Deletion of IAM Roles**

```json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "iam:DeleteRole",
      "Resource": "*"
    }
  ]
}
```

Now, no one in SecureCart's AWS accounts can delete IAM Roles—even if their IAM Role allows it.

### **How SCPs Work with AWS Organizations & IAM**

* SCPs are attached to AWS Organizations' Root, OUs, or AWS Accounts.
* They do NOT grant permissions—only restrict actions.
* If an SCP explicitly denies an action, IAM Users and Roles in the account cannot perform it, even if an IAM Policy allows it.

**SCP vs. IAM Policies**

| **Feature**                    | **Service Control Policies (SCPs)**                         | **IAM Policies**                        |
| ------------------------------ | ----------------------------------------------------------- | --------------------------------------- |
| **Applies To**                 | AWS Accounts, Organizational Units (OUs), Root Organization | Individual IAM Users, Groups, and Roles |
| **Grants Permissions?**        | ❌ No                                                        | ✅ Yes                                   |
| **Restricts Actions?**         | ✅ Yes                                                       | ✅ Yes                                   |
| **Overrides IAM Permissions?** | ✅ Yes (Denies take precedence)                              | ❌ No                                    |
| **Used For**                   | Organizational-wide security control                        | Assigning permissions to users & roles  |

**Best Practice:** Use **SCPs for high-level security enforcement** and **IAM Policies for detailed permissions.**

***

## **SCP Use Cases in SecureCart**

SecureCart uses SCPs to enforce **security, compliance, and governance controls** across multiple AWS accounts.

* **Example 1: Deny Root User Access to All Accounts**
  * **Why?** Prevent security risks by ensuring the Root User cannot perform any action.
  * **Result:** Even if the Root User tries to create IAM Users or change policies, they are blocked
* **Example 2: Prevent Developers from Modifying IAM Policies**
  * **Why?** Developers should not modify IAM Roles or Policies, even if they have broad permissions.
  * **Result:** Developers cannot change IAM permissions, even if an IAM Role grants them access.
* **Example 3: Require All AWS Accounts to Enable Security Services**
  * **Why?** Ensure that AWS Security Hub, GuardDuty, and AWS Config remain enabled for compliance.
  * **Result:** No one can disable security monitoring in SecureCart AWS accounts.

***

### **How SecureCart Implements SCPs Across OUs**

SecureCart applies SCPs **at the Organizational Unit (OU) level** to enforce best practices.

📌 **SecureCart AWS Organizations SCPs by OU**

| **OU Name**           | **SCP Applied**                                          |
| --------------------- | -------------------------------------------------------- |
| **Security OU**       | Prevent disabling GuardDuty & Security Hub               |
| **Workloads OU**      | Restrict developers from modifying IAM policies          |
| **Infrastructure OU** | Deny creation of new VPCs outside the networking account |
| **Sandbox OU**        | Block access to production resources                     |

**Result:** SCPs prevent misconfigurations and enforce compliance across all AWS accounts.

***

### **SCP Best Practices**

* &#x20;**Apply SCPs at the OU Level**, not the account level, for better scalability.
* **Use SCPs to enforce security & compliance**, not for day-to-day permission management (use IAM for that).
* **Test SCPs in a non-production OU before applying them org-wide.**
* **Combine IAM Identity Center (AWS SSO) with SCPs** for a secure and scalable multi-account architecture.

AWS SCPs help SecureCart enforce organization-wide security while IAM Identity Center manages user access.

***

## **Summary: How SCPs Improve Security in Multi-Account AWS Environments**

| **Feature**                   | **SCP Use Case**                            | **SecureCart Example**                |
| ----------------------------- | ------------------------------------------- | ------------------------------------- |
| **Prevent Root User Access**  | Block all root account actions              | Root users cannot modify resources    |
| **Restrict IAM Permissions**  | Stop unauthorized IAM policy changes        | Developers cannot modify IAM          |
| **Enforce Security Services** | Require GuardDuty, Security Hub, AWS Config | Security tools remain enabled         |
| **Control Network Changes**   | Prevent accidental VPC creation             | Only the networking team manages VPCs |
| **Limit Billing Access**      | Block non-finance users from AWS Billing    | Only finance can manage AWS Budgets   |

**SCPs enforce security guardrails without replacing IAM permissions.**

***

## **How SecureCart Secures Multi-Account Access**

| **Security Mechanism**                       | **Purpose**                                          | **AWS Services Used**                  |
| -------------------------------------------- | ---------------------------------------------------- | -------------------------------------- |
| IAM Identity Center (SSO)                    | Centralized user authentication & access management  | IAM Identity Center, AWS Organizations |
| IAM Identity Center Groups & Permission Sets | Assign permissions to users in multiple AWS accounts | IAM Identity Center, IAM Roles         |
| Cross-Account IAM Roles                      | Grant services access across accounts securely       | IAM Roles, AWS STS                     |
| Service Control Policies (SCPs)              | Restrict actions across AWS accounts                 | AWS Organizations, SCPs                |


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://awsinpractice.itassist.com/study-group/aws-certified-solutions-architect-associate/domain-1-design-secure-architectures/copy-of-task-statement-1.1-design-secure-access-to-aws-resources/copy-of-securing-access-across-multiple-aws-accounts.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.