Separation of Duties

Separation of Duties is a security and governance principle that distributes incompatible responsibilities across independent actors. The objective is not merely to create different job titles or accounts, but to prevent one actor from controlling every stage of a sensitive operation. For example, a developer may propose a production change, a separate reviewer may approve it, and an automated deployment role may execute it. The developer should not also be able to bypass approval or erase evidence of the deployment.

Cloud implementations combine organizational ownership with technical enforcement. Identity policies define which actions each role can perform, trust policies control who can assume those roles, and account boundaries separate workloads from security administration and audit storage. Engineers must evaluate effective access across all these layers. Two nominally separate roles do not provide meaningful separation if the same person can freely assume both, change their permissions, or impersonate the approval identity.

A common multi-account design separates organization governance, centralized security operations, workload administration, and log custody. The organization management account handles restricted governance tasks, while a dedicated security member account operates supported security services across workload accounts. A separate log archive account protects audit records from workload administrators. These account boundaries support separation, but their effectiveness depends on access policies and ownership arrangements.

In AWS, delegated administration allows a designated member account to perform supported organization-wide service administration without routinely using the AWS Organizations management account. For example, security personnel can administer Amazon GuardDuty or AWS Security Hub capabilities through a security account while application teams manage workloads in their own accounts. Delegation is service-specific: registering an account for one service does not make it the administrator of every security service. Configuration scope, regional behavior, member enrollment, and automatic enablement must be checked for each service.

Service control policies can reinforce this arrangement by limiting actions available in member accounts, such as attempts to disable required protections. They do not grant permissions, and they do not restrict principals in the organization's management account. Consequently, minimizing management-account access remains essential. Likewise, a delegated administrator has only the authority provided through the relevant service integration and applicable permissions, not unrestricted organization ownership.

Separation of Duties complements least privilege but is not identical to it. Least privilege limits each actor's permissions; separation addresses dangerous combinations of permissions and responsibilities. An identity with narrowly scoped approval and execution permissions may still violate separation if it can approve its own action. Some workflows therefore require independent approval or prevent the requester from serving as the approver.

The main trade-offs are additional coordination, account and role administration, and potentially slower emergency response. Automate routine policy deployment and access reviews, and define monitored, time-limited emergency access with independent post-event review. Test that administrators cannot bypass boundaries through role assumption, policy changes, deployment pipelines, or log deletion. Separation reduces single-actor risk, but does not eliminate collusion; protected audit evidence and independent review remain necessary.