Lesson 03 — AWS Organizations Assessment

Learning Objectives

By the end of this lesson, you will be able to:

Understand AWS Organizations architecture.
Explain the benefits of multi-account AWS environments.
Assess AWS Organizational Units (OUs).
Review Service Control Policies (SCPs).
Understand delegated administration.
Assess cross-account trust relationships.
Identify organization-wide attack paths.
Perform enterprise AWS Organizations security reviews.

Introduction

Large enterprises rarely operate from a single AWS account.

Instead, they organize workloads across multiple AWS accounts using AWS Organizations.

This approach improves:

Security
Governance
Billing
Compliance
Operational management
Least privilege

However, poorly designed AWS Organizations can introduce organization-wide attack paths that allow attackers to move between accounts.

Understanding AWS Organizations is therefore a critical skill for Cloud Penetration Testers.

Enterprise Scenario

CloudNova Technologies has been engaged by FinSecure Bank Ltd to assess its enterprise AWS environment.

The organization operates:

42 AWS Accounts
8 Business Units
5 AWS Regions
Amazon EKS
CI/CD Pipelines
Shared Networking
Shared Logging
Security Operations Centre (SOC)

Your task is to determine whether the AWS Organization has been securely designed and whether attackers could compromise multiple AWS accounts.

What is AWS Organizations?

AWS Organizations is a service used to centrally manage multiple AWS accounts.

It provides:

Centralized governance
Consolidated billing
Organization-wide policies
Account management
Delegated administration

Large organizations often use AWS Organizations to separate production, development and security environments.

Typical AWS Organization Structure

AWS Organization

│

├── Root

│
├── Security OU
│     ├── Security Account
│     ├── Log Archive
│
├── Infrastructure OU
│     ├── Shared Services
│     ├── Networking
│
├── Production OU
│     ├── Prod Account 1
│     ├── Prod Account 2
│
├── Development OU
│     ├── Dev Account 1
│     ├── Dev Account 2
│
└── Sandbox OU
      ├── Testing
      ├── Research

This structure limits the blast radius of security incidents.

Core Components

AWS Organizations consists of:

Organization Root
Organizational Units (OUs)
Member Accounts
Management Account
Service Control Policies (SCPs)
Delegated Administrators
Cross-Account IAM Roles

Each component should be assessed during an enterprise security review.

Management Account

The Management Account (formerly Master Account):

Creates new AWS accounts.
Manages billing.
Applies Service Control Policies.
Controls organization settings.
Delegates administrative permissions.

Compromise of this account can affect every AWS account within the organization.

Organizational Units (OUs)

Organizational Units group AWS accounts with similar business or security requirements.

Example:

Production OU

↓

Banking

↓

Payments

↓

Insurance

↓

Loans

Benefits include:

Central policy management
Easier governance
Improved compliance
Separation of duties

Service Control Policies (SCPs)

Service Control Policies define the maximum permissions that AWS accounts can use.

Unlike IAM policies, SCPs do not grant permissions.

Instead, they restrict what IAM identities are allowed to do.

Example:

IAM Policy

↓

Allows EC2

↓

SCP

↓

Blocks EC2

↓

Final Result

↓

Access Denied

SCPs act as organization-wide guardrails.

Example SCP

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

This SCP prevents IAM administrative actions, even if an IAM policy allows them.

Delegated Administration

Large organizations often delegate management responsibilities.

Examples include:

AWS Security Hub
Amazon GuardDuty
AWS Config
IAM Identity Center
Amazon Inspector

Delegated administration reduces reliance on the Management Account while maintaining centralized governance.

Cross-Account Access

Enterprise workloads frequently require controlled access between AWS accounts.

Example:

Development Account

↓

AssumeRole

↓

Production Account

↓

Read-Only Role

Cross-account access should always follow the principle of least privilege.

Cross-Account Trust Relationships

A typical trust relationship:

{
  "Principal": {
    "AWS": "arn:aws:iam::111122223333:root"
  },
  "Action": "sts:AssumeRole"
}

Review:

Trusted accounts
External principals
Wildcard principals
Conditions
Session duration

Improper trust relationships can enable lateral movement across accounts.

Enterprise Attack Surface

Cloud penetration testers should review:

Management Account
Member Accounts
SCPs
IAM Roles
Cross-Account Roles
Shared Services
Central Logging
Security Accounts
Shared Networking

Every account may become part of an attack path.

AWS Organizations Attack Path

Compromised Developer Account

↓

AssumeRole

↓

Shared Services Account

↓

Administrator Role

↓

Production Account

↓

Sensitive Customer Data

Weak cross-account trust can enable organization-wide compromise.

Common Misconfigurations

Frequently observed issues include:

Excessive cross-account trust
Missing Service Control Policies
Administrator roles shared across accounts
Weak OU design
Unrestricted delegated administration
Shared administrator credentials
Inconsistent IAM standards
Missing logging accounts
Lack of centralized security services

Enterprise Assessment Methodology

Professional consultants typically follow this process.

Identify Organization

↓

Review OUs

↓

Review SCPs

↓

Review Management Account

↓

Review Member Accounts

↓

Assess Cross-Account Roles

↓

Assess Delegated Administration

↓

Identify Attack Paths

↓

Document Findings

This ensures that governance and security controls are assessed consistently.

Security Best Practices

Enterprise AWS Organizations should implement:

Dedicated Security Account
Dedicated Log Archive Account
Least Privilege IAM
Organization-wide SCPs
MFA for administrators
Centralized CloudTrail
AWS Config Aggregators
GuardDuty Organization Integration
Security Hub Integration
Centralized Incident Response

Common Findings

Enterprise assessments often identify:

Management account without MFA
Missing SCPs
Wildcard cross-account trust
Administrator roles shared across accounts
Inconsistent IAM permissions
Unprotected Security Account
Disabled CloudTrail in member accounts
Excessive delegated administrator permissions

Enterprise Architecture Example

Management Account

│

├── Security Account

│      ├── GuardDuty

│      ├── Security Hub

│      ├── CloudTrail

│

├── Shared Services

│

├── Networking

│

├── Development

│

├── Testing

│

└── Production

This design supports centralized governance while reducing organizational risk.

Best Practices

Separate production and development accounts.
Protect the Management Account with MFA and least privilege.
Use SCPs to enforce organization-wide guardrails.
Limit cross-account trust relationships.
Centralize logging and security monitoring.
Regularly review delegated administrator permissions.
Audit organization-wide IAM roles and policies.

Common Mistakes

Avoid:

Using the Management Account for daily administration.
Allowing unrestricted AssumeRole access.
Applying overly broad SCP exceptions.
Sharing administrator roles across business units.
Failing to centralize security logging.
Granting excessive delegated administration permissions.
Creating unnecessary cross-account trust relationships.

Knowledge Check

1. What is the primary purpose of AWS Organizations?

Answer: AWS Organizations enables centralized governance, account management, consolidated billing and organization-wide security policy enforcement across multiple AWS accounts.

2. Do Service Control Policies grant permissions?

Answer: No. Service Control Policies define the maximum permissions available to AWS accounts. They restrict permissions but do not grant them.

3. Why is the Management Account considered a high-value target?

Answer: The Management Account controls the AWS Organization, including account creation, Service Control Policies and organization-wide administration. Compromise of this account can affect every member account.

4. Why should cross-account trust relationships be reviewed during an assessment?

Answer: Weak or overly permissive trust relationships can enable attackers to move laterally between AWS accounts and escalate privileges across the organization.

5. Why are dedicated Security and Log Archive accounts recommended?

Answer: Dedicated accounts centralize security services, protect audit logs, improve governance and reduce the impact of compromise within individual workload accounts.

Key Takeaways

AWS Organizations is the foundation of enterprise AWS governance.
Multi-account architectures improve security when properly designed.
Service Control Policies provide organization-wide guardrails.
Cross-account trust relationships must be carefully reviewed to prevent lateral movement.
Enterprise AWS assessments should evaluate governance, architecture and attack paths in addition to individual AWS services.

What’s Next?

In the next lesson, you will explore Amazon VPC Enumeration, learning how attackers and cloud penetration testers map AWS networking, identify internet-facing resources, review Security Groups, Route Tables, Network ACLs and uncover network-based attack paths.

➡️ Next Lesson: Lesson 04 — Amazon VPC Enumeration