10.3 Multi-Account Security: Organizations, SCPs & Identity Center

10.3 Multi-Account Security: Organizations, SCPs & Identity Center

CloudOps Blueprint Focus: The AWS Certified CloudOps Engineer – Associate (SOA-C03) exam tests your ability to govern multi-account AWS environments using AWS Organizations, establish organizational guardrails via Service Control Policies (SCPs), deploy hardened SCP patterns that protect security infrastructure and enforce regional restrictions, and centralize workforce identity and single sign-on using IAM Identity Center.

Multi-Account Architecture: Management Account & OU Hierarchy

Operating enterprise workloads in a single AWS account creates severe blast-radius risks, shared service limit bottlenecks, and complex audit boundaries. Modern cloud operations enforce a multi-account architecture managed through AWS Organizations.

Account Roles: Management vs. Member Accounts

• Management Account: The root anchor of the AWS Organization. Manages consolidated billing, account creation, SCP authoring, and cross-account delegations. Operational Rule: Application workloads, public endpoints, and production databases must never run in the management account.
• Member Accounts: Dedicated accounts that contain workloads or platform services, subject to organizational policies.

Organizational Unit (OU) Hierarchy

Organizational Units (OUs) group accounts into logical containers to apply shared governance hierarchically (nestable up to 5 levels deep):

• Core / Base OU: Houses foundational shared services, including the Log Archive Account (immutable centralized CloudTrail and VPC logs) and the Security Tooling Account (delegated administrator for GuardDuty, Security Hub, and IAM Access Analyzer).
• Workloads OU: Hosts business services, segmented into Production (strict compliance and immutable change control) and Non-Production (development and testing) child OUs.
• Sandbox OU: Isolated accounts for developer prototyping with no connectivity to internal corporate networks.

Consolidated Billing

Consolidated billing rolls all member account charges into a single invoice. It delivers automatic volume pricing discounts on tiered services (S3 storage and KMS requests) and allows Savings Plans and Reserved Instances purchased in one account to cover matching usage across all member accounts.

---

Service Control Policies (SCPs): Guardrails & Evaluation Mechanics

Service Control Policies (SCPs) are JSON guardrails attached to the Root, OUs, or individual accounts that establish the maximum allowable permissions across member accounts.

Core SCP Evaluation Principles

1. SCPs Never Grant Permissions: SCPs define permission boundaries. An account principal must still be granted explicit access by an identity-based or resource-based policy.
2. Effective Permissions are an Intersection: An action is permitted only if it is explicitly allowed at each hierarchical level (Root -> Parent OU -> Child OU -> Account) and never denied by an SCP.
3. Management Account Immunity: The management account is completely exempt from all SCPs. SCPs never restrict management account root, users, or roles.
4. Member Account Scope: Within member accounts, SCPs govern all IAM users, all IAM roles, and the account root user.
5. Service-Linked Role Exemption: SCPs do not affect service-linked roles, ensuring internal AWS service workflows (e.g., Auto Scaling, ELB) are never disrupted.

Allow-List vs. Deny-List Strategy

• Allow-List Strategy: Removing the default FullAWSAccess SCP from the Root requires explicitly listing every approved action. This strategy is operationally brittle because new AWS service launches remain blocked until SCPs are updated.
• Deny-List Strategy (Recommended): Retains FullAWSAccess at all levels and attaches custom SCPs containing explicit Deny statements. Because explicit denies override all allows, this approach enforces strict guardrails without impeding standard service adoption.

---

Essential CloudOps SCP Patterns

Production environments employ standardized SCP patterns to enforce non-negotiable security guardrails:

1. Protecting Security & Audit Telemetry

Prevents member accounts from disabling CloudTrail logging, deleting trails, or stopping AWS Config recorders:

{
  "Effect": "Deny",
  "Action": [
    "cloudtrail:StopLogging",
    "cloudtrail:DeleteTrail",
    "cloudtrail:UpdateTrail",
    "config:DeleteConfigRule",
    "config:StopConfigurationRecorder"
  ],
  "Resource": "*"
}

2. Preventing Member Accounts from Leaving the Organization

Blocks unauthorized disconnection by denying organizations:LeaveOrganization.

3. Restricting Allowed AWS Regions (Geo-Fencing)

Restricts resource provisioning strictly to approved operating regions (e.g., us-east-1 and us-west-2). It uses NotAction to exempt global services that lack regional endpoints:

{
  "Effect": "Deny",
  "NotAction": [
    "iam:*",
    "organizations:*",
    "route53:*",
    "cloudfront:*",
    "sts:*",
    "support:*"
  ],
  "Resource": "*",
  "Condition": {
    "StringNotEquals": {
      "aws:RequestedRegion": ["us-east-1", "us-west-2"]
    }
  }
}

4. Enforcing IMDSv2 on EC2 Launches

Mitigates SSRF vulnerabilities by denying ec2:RunInstances when ec2:MetadataHttpTokens is not set to required.

5. Denying Root User Actions in Member Accounts

Denies API operations executed by member account root credentials using Condition: {"ArnLike": {"aws:PrincipalArn": "arn:aws:iam::*:root"}}.

---

IAM Identity Center: Centralized Workforce Access & Federation

Managing individual IAM users across 50+ member accounts leads to credential sprawl and delayed deprovisioning. AWS IAM Identity Center (successor to AWS Single Sign-On / AWS SSO) centralizes workforce access.

External Identity Provider (IdP) Federation

• SAML 2.0: Federates with corporate identity providers (Microsoft Entra ID, Okta, Ping Identity, Google Workspace) for single sign-on using existing corporate credentials and MFA.
• SCIM (System for Cross-domain Identity Management): Automates user and group synchronization. When an employee is offboarded in Okta or Entra ID, SCIM instantly removes their identity from AWS IAM Identity Center, revoking access across all AWS accounts simultaneously.

Permission Sets & Multi-Account Role Provisioning

A Permission Set defines an access profile bundling AWS managed policies, customer managed policies, or inline policies, along with session durations (15 minutes to 12 hours). When an administrator assigns a Permission Set to a user or group in a target account:

• IAM Identity Center automatically provisions a corresponding IAM role in that member account prefixed with AWSReservedSSO_*.
• Trust policies and role lifecycles are managed transparently by Identity Center.

User Experience & CLI Access

Employees log into a centralized AWS access portal (https://my-company.awsapps.com/start) displaying all authorized accounts and permission sets. Developers using the AWS CLI v2 authenticate using aws sso login, which retrieves and caches temporary STS credentials without storing long-term access keys on local machines.