Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Scan for outdated or missing drivers - takes under a minute3Repair Windows errors before they cause bigger problemsImplement segregation of duties (SoD) on AWS by separating responsibilities across accounts and teams, assigning each person narrowly scoped temporary access, limiting that access with organization-level guardrails, and protecting audit logs from the people whose actions they record. AWS Control Tower can standardize account provisioning and baseline controls, but it does not by itself ensure that duties are separated: you must review role assignments, trust relationships, exceptions, and evidence access.
What segregation of duties means on AWS
SoD reduces the risk that one person can perform and conceal a sensitive action, or combine incompatible responsibilities without independent review. For example, the person who deploys a production change should not also be the only person able to approve it and alter or delete the records used to audit it.
On AWS, this is a layered design rather than a single setting. Account boundaries divide environments and responsibilities; workforce identities and roles determine who can enter them; policies constrain what each role can do; and independently protected logs let reviewers investigate activity.
Start with accounts, organizational units, and ownership
Use AWS Organizations to arrange accounts into organizational units (OUs) that reflect meaningful boundaries. Separate production from non-production, and consider distinct accounts for security tooling, centralized logging, shared services, and sandboxes. The goal is to let different teams administer different duties without relying on one account’s IAM policies to separate every responsibility.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
#1 Best Overall
Keep the organization-management account tightly controlled. Where supported, delegate security-service administration to a security tooling account. Give compliance reviewers access to audit artifacts without granting them workload-administration rights. Define account owners and operational responsibilities explicitly; an account boundary is useful only if its access and exceptions preserve that boundary.
Define roles around incompatible duties
Before creating permission sets, identify sensitive tasks and decide which should not be held by the same person without independent approval. A practical starting model is:
| Role or persona | Typical responsibility | SoD boundary to preserve |
|---|---|---|
| Platform administrator | Operate shared infrastructure and account baselines | Should not be the sole approver of changes to its own access controls or audit evidence |
| Security operator | Investigate alerts and administer delegated security services | Separate investigation from the ability to alter protected central logs where feasible |
| Deployment role | Deploy approved application or infrastructure changes | Limit production deployment rights to the required accounts and actions; provide independent change approval through the organization’s workflow |
| Read-only auditor | Inspect configurations and audit artifacts | Do not combine review access with workload write permissions |
| Break-glass responder | Handle exceptional urgent access | Make use exceptional, attributable, and subject to independent review |
This is a design example, not a mandatory AWS role catalog. Adjust it to the services, teams, and risks in your environment. The key is to identify combinations that create a conflict, then control those combinations through distinct identities, approvals, and review.
Use IAM Identity Center for workforce access
Federate workforce identities into AWS IAM Identity Center and assign separate permission sets for each duty. Common starting points include platform administration, security operations, deployment, read-only audit, and break-glass response. Require MFA and use temporary role sessions rather than standing human IAM-user credentials. Where available, connect identity lifecycle processes so access can be adjusted when a person changes roles or leaves.
Free tools Windows power users keep installed
One-click scans. No signup required.
Rank #3
Permission sets should grant only the actions required for a role, in the accounts where that role needs them. Review assignments as well as policy content: a sound permission set does not preserve SoD if the same person receives incompatible permission sets or can assume another role with broader access.
Combine permission grants with organization guardrails
Identity policies and permission sets grant actions to a role, subject to the maximum permissions allowed by applicable controls. Service control policies (SCPs) and, where applicable, resource control policies (RCPs) set organization-level limits; they do not grant permissions. AWS recommends SCPs as permissions guardrails across IAM users and roles in an organization. A role still needs an identity-based grant for an action that the guardrails permit.
Use these layers together:
- Organization guardrails: Set boundaries for actions that must not be available in affected accounts or resources, regardless of a role’s identity policy.
- Role policies: Grant each duty only the necessary actions and resources.
- Controlled policy changes: Require peer review and independent approval for changes to guardrails, permission sets, trust policies, and other access controls.
Evaluate exceptions explicitly. A guardrail does not prove that a person cannot combine duties if that person can change the guardrail, assume an unrestricted role, or use an exception path.
Use Control Tower for repeatable governance, not as a substitute for SoD design
AWS describes Control Tower as a way to set up and govern a multi-account AWS environment using prescriptive best practices. It combines AWS Organizations, Service Catalog, and IAM Identity Center, and provides a landing zone, Account Factory, and preventive, detective, and proactive controls. It can help standardize account creation and baseline governance.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Best Value
Control Tower does not decide which duties are incompatible in your organization or automatically validate every assignment and exception. Review account ownership, permission-set assignments, role trust policies, break-glass access, policy changes, and drift. A hand-built Organizations design may offer more direct tailoring but requires your team to build and operate its own provisioning and governance processes. Choose based on the repeatability, flexibility, control coverage, exception handling, logging integration, operating effort, and skills your team needs; neither approach removes the need for access review.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Protect logs and build an independent review path
Create organization-wide AWS CloudTrail trails and protect the destination from workload administrators. CloudTrail records API activity, including the actor, request, time, source, and operation, supporting detection and investigation. It does not prevent an action or, on its own, prove that an action was impossible. Review IAM, STS, IAM Identity Center, Organizations, Control Tower, and relevant service events; correlate Identity Center identifiers with workforce identities so activity can be attributed to a person.
Separate the people who administer audit assessments from those who review evidence. AWS Audit Manager supports separating administrator and reviewer personas through different IAM policies. Map custom controls to supported CloudTrail management and global-service events. Audit Manager does not use CloudTrail data events or CloudTrail Insights events as evidence sources, so do not assume those event types will populate an assessment.
How to implement and verify the design
- Map duties and conflicts. List sensitive operations, who performs them, who approves them, and who can review evidence. Identify combinations that would let one person authorize, execute, and conceal an action.
- Design account boundaries. Organize production, non-production, security tooling, logging, shared services, and sandbox responsibilities into accounts and OUs appropriate to your organization.
- Assign workforce access. Federate people through IAM Identity Center, require MFA, use temporary sessions, and assign separate job-based permission sets to the appropriate accounts.
- Set and review guardrails. Apply suitable SCPs and, where relevant, RCPs. Review identity policies, trust relationships, exception paths, and who can change each control. Require independent review for sensitive access-policy changes.
- Centralize and protect audit records. Configure organization-wide CloudTrail logging and restrict workload administrators from changing or deleting the central log destination.
- Test both permissions and evidence. Confirm that intended roles can perform required work and that prohibited combinations are constrained. Verify that logs identify the actor and operation, that reviewers can access the evidence, and that exceptions receive independent scrutiny.
- Reassess access and drift. Review assignments, policies, trust relationships, and guardrail exceptions when roles change and on a defined recurring schedule. Investigate differences between the intended design and deployed controls.
What to show an auditor
Evidence should connect the policy intent to actual assignments and recorded activity. A useful review package can include:
- The account and OU structure, with owners and documented responsibility boundaries.
- Current permission-set assignments, identity policies, relevant trust policies, and organization guardrails, including approved exceptions.
- Records of independent approval for sensitive access changes and the process for break-glass use.
- CloudTrail configuration and evidence that the central log destination is protected from workload administrators.
- Sampled CloudTrail management events correlated to workforce identities, plus review records showing who examined them and how exceptions were handled.
- Audit Manager assessment configuration and evidence mappings, with the administrator and reviewer roles distinguished.
Evidence supports an auditor’s assessment; it is not a guarantee of compliance. The applicable control requirements and the evidence they demand depend on the audit framework and your organization’s implementation.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
