7.1.4. Centralized Security Service Management
First Principle: Security services must be enabled consistently across all accounts and Regions, managed from a central point, and monitored for gaps. Delegated administrator accounts enable this without using the sensitive management account.
Delegated Administrator Pattern:
- Designate a security account as the delegated administrator for each security service
- The delegated admin can manage the service across all organization accounts
- No need to use the management account for day-to-day security operations
Services Supporting Delegated Admin:
| Service | What the Admin Manages |
|---|---|
| GuardDuty | Threat detection across all accounts/Regions |
| Security Hub | Finding aggregation and security standards |
| Inspector | Vulnerability scanning across all accounts |
| Macie | Sensitive data discovery across all accounts |
| Config | Compliance rules and aggregation |
| Firewall Manager | WAF, SG, and Network Firewall policies |
| Detective | Investigation across all accounts |
Implementation:
- Create a dedicated Security account
- Register it as delegated administrator for each service
- Enable auto-enable for new accounts (so new accounts automatically get security services)
- Configure cross-Region aggregation where supported
⚠️ Exam Trap: Each service has its own delegated admin registration. You can (and should) use the same Security account for all, but each service must be registered individually.
Scenario: The security team manages GuardDuty, Security Hub, and Inspector from a dedicated Security account. When a new team creates an AWS account via Account Factory, all three services are automatically enabled and the Security account gains visibility immediately.
Reflection Question: Why is the delegated administrator model preferred over managing security services from the management account?
