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.

Solution:

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

---

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

{
  "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

• 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