14.3 Delegated Administrator Architecture & Root User Governance

14.3 Delegated Administrator Architecture & Root User Governance

A cardinal rule of enterprise cloud security is the separation of administrative duties. The AWS Organizations Management account holds ultimate authority over organizational structure, consolidated billing, and account membership. Granting security operations personnel day-to-day access to the Management account introduces catastrophic blast radius risks: a single compromised credential or operational error could sever organization-wide networking, detach governance policies, or alter billing relationships.

AWS resolves this challenge through the Delegated Administrator framework, allowing organizations to assign operational management of individual AWS security services to dedicated member accounts. Concurrently, strict Root User Governance guarantees that emergency credentials remain hardened, audited, and strictly confined to authorized break-glass scenarios.

---

The Delegated Administrator Model & Blast Radius Isolation

The Delegated Administrator model decouples organizational ownership from day-to-day security operations. The Management account retains sole authority to designate which member account administers each service, but operational engineering and monitoring take place entirely within dedicated security accounts.

Loading diagram...

Dedicated Account Separation

AWS architectural best practices mandate two dedicated security-related accounts in the Core OU:

1. Security Tooling Account (Delegated Administrator): The active operational account used by the SecOps team. It hosts the delegated administrator roles for automated threat detection, vulnerability scanning, data classification, and centralized firewall management.
2. Log Archive Account: The passive repository account. It holds the read-only, air-gapped S3 buckets receiving CloudTrail logs, AWS Config history, and VPC Flow Logs. Security analysts have read-only access to investigate forensic data without possessing permissions to modify logging infrastructure.

---

Service-by-Service Delegated Administration

Each major AWS security service supports delegated administration, enabling centralized policy deployment and finding aggregation across all accounts and regions.

---

AWS Firewall Manager Prerequisites & Policy Enforcement

AWS Firewall Manager is a frequent focus on the AWS Certified Security – Specialty exam because it has strict, mandatory prerequisites that must be satisfied before any policy can be created:

1. Organizations All Features: The organization must be configured with All Features enabled (Consolidated Billing only is insufficient).
2. Designated Delegated Administrator: The Management account must designate a member account (typically the Security Tooling account) as the Firewall Manager administrator via the Organizations or Firewall Manager console.
3. AWS Config Active Everywhere: AWS Config must be enabled and actively recording all resources across all member accounts and in all regions where Firewall Manager policies will apply. Firewall Manager relies directly on AWS Config to discover resources, evaluate compliance, and execute remediation actions.

Loading diagram...

If AWS Config is disabled in even one member account or region, Firewall Manager cannot evaluate or protect resources in that scope.

---

Root User Governance & Hardening

The AWS account root user has unrestricted, irrevocable access to all resources and APIs within an account. Root user credentials bypass all IAM permission boundaries and cannot be restricted by IAM policies within that account.

Management Account Root User Hardening

Because the Management account root user is also immune to Service Control Policies, its compromise represents the ultimate organizational catastrophe. Strict hardening mandates:

1. Zero Long-Term Access Keys: Never create access keys for the root user. If root access keys exist, delete them immediately. Programmatic API access must be restricted to IAM roles.
2. Hardware Multi-Factor Authentication (FIDO2): Protect the root user with physical, hardware-based MFA devices (such as FIDO2 WebAuthn security keys or hardware TOTP tokens). Register multiple hardware security keys to ensure backup redundancy.
3. Physical Vaulting & Dual-Custody: The complex, randomly generated root password and physical hardware tokens must be stored in separate, geographically distributed physical safes requiring dual-custody authorization (two distinct keyholders must be present to access the credentials).
4. No Routine Operational Usage: The root user must never be used for day-to-day administrative tasks. All administrative activities must be performed by federated identities assuming privileged IAM roles.

Member Account Root User Protection via SCPs

Unlike the Management account, member account root users are fully subject to Service Control Policies. Organizations can neutralize member account root user access using an explicit Deny SCP attached at the organization root:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyMemberAccountRootExecution",
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringLike": {
          "aws:PrincipalArn": [
            "arn:aws:iam::*:root"
          ]
        }
      }
    }
  ]
}

Exam Tip: The condition "StringLike": {"aws:PrincipalArn": ["arn:aws:iam::*:root"]} matches the root user identity of member accounts. Attaching this SCP prevents anyone from logging in as a member account root user and performing API actions, effectively shutting down root account exploitation across member accounts.

Centralized Root Access for Member Accounts (IAM)

Organizations no longer need to store root passwords and MFA devices for hundreds of member accounts. Centralized root access is an IAM feature (not IAM Identity Center). After you enable trusted access for IAM in Organizations and turn on root credentials management and privileged root actions in member accounts:

• The management account, or a member account designated as the IAM delegated administrator, can delete member accounts' root credentials (password, access keys, signing certificates, MFA); new accounts are created without root credentials.
• For the few tasks that require root, such as unlocking an S3 bucket or SQS queue policy that denies everyone, an administrator calls sts:AssumeRoot with a task policy (for example S3UnlockBucketPolicy). The session is short-lived (15 minutes at most), scoped to that task, and logged in CloudTrail.

---

Break-Glass Emergency Protocols

A Break-Glass Procedure is a documented, auditable protocol for gaining emergency administrative access during catastrophic events, such as when corporate identity federation fails, the single sign-on (SSO) directory is unreachable, or administrative IAM roles have been corrupted.

Loading diagram...

Architectural Requirements for Break-Glass Access

1. Dual-Custody Retrieval: Accessing emergency credentials requires two authorized individuals (e.g., CISO and Lead Architect), each holding one half of the password or separate keys to the physical safe.
2. Time-Bound Sessions: Emergency roles must enforce a maximum session duration (e.g., 1 hour) using temporary security credentials.
3. Isolated Identity: Maintain a dedicated emergency IAM role within member accounts that trusts a dedicated break-glass role in the Security Tooling account, avoiding reliance on corporate Active Directory or Okta pipelines.
4. High-Priority Immediate Alerting: Any invocation of emergency credentials must trigger instantaneous, high-priority alerts to the entire security leadership team.

---

Real-Time Root Activity Detection & Alerting

Because root user access represents extreme privilege, every root login or API invocation must trigger real-time detection and alerting.

EventBridge Real-Time Root Detection Rule

Amazon EventBridge evaluates AWS CloudTrail management events in near real time. The following event pattern captures any API call executed by a root user across the organization:

{
  "detail-type": [
    "AWS API Call via CloudTrail",
    "AWS Console Sign In via CloudTrail"
  ],
  "detail": {
    "userIdentity": {
      "type": ["Root"]
    }
  }
}

When matched, EventBridge immediately routes the payload to an Amazon SNS topic connected to PagerDuty or SOC analyst endpoints and invokes an AWS Lambda function to capture forensic context or lock down unauthorized sessions.

CloudWatch Metric Filter on CloudTrail Logs

For defense-in-depth, security teams also deploy an Amazon CloudWatch Logs Metric Filter on the centralized CloudTrail log group:

{ $.userIdentity.type = "Root" && $.userIdentity.invokedBy NOT EXISTS && $.eventType != "AwsServiceEvent" }

This filter increments a CloudWatch metric whenever a real human or external script executes an API call using root credentials, excluding automated internal AWS service tasks. A CloudWatch alarm set to threshold > 0 triggers immediate incident response.

---

Specialty Exam Traps & Architectural Pitfalls

1. Attempting to Manage Security Services from the Management Account: Delegating administration to a dedicated member account is an AWS core security standard. Running Security Hub or GuardDuty directly from the Management account violates the principle of least privilege and increases organizational blast radius.
2. Overlooking AWS Config as a Firewall Manager Blocker: You cannot successfully deploy AWS Firewall Manager policies if AWS Config is not recording resources in the target accounts and regions. If an exam scenario asks why Firewall Manager fails to apply security group policies in a member account, verify whether AWS Config is running.
3. Assuming SCPs Protect the Management Account Root User: SCPs have zero effect on the Management account root user. The only defenses are eliminating access keys, hardware MFA, vaulting, and continuous CloudTrail/EventBridge monitoring.
4. Failing to Automate Detective Protection in New Accounts: Delegated administrators for GuardDuty and Security Hub provide an Auto-Enable setting. If auto-enable is not turned on, new accounts vended through Account Factory will remain unprotected until manually enrolled.