CSA CCM IAM-09
Segregation of Privileged Access Roles

The Segregation of Privileged Access Roles control from the CSA CCM provides guidance on separating duties and access for privileged users. By implementing distinct roles for administrative functions like managing data access, encryption keys, and logging, organizations can reduce the risk of unauthorized access or malicious activity from privileged accounts. Regularly reviewing and enforcing these processes helps ensure privileged access remains properly restricted.

Where did this come from?

This control comes from the CSA Cloud Controls Matrix v4.0.10 released on 2023-09-26. You can find more details and download the latest version of the CCM at https://cloudsecurityalliance.org/artifacts/cloud-controls-matrix-v4.

The CCM provides a framework of cloud-focused security controls mapped to leading standards, regulations, and best practices. It is a great resource for organizations looking to assess their cloud security posture against industry standards.

For additional guidance on implementing least privilege and segregating duties with AWS IAM, check out:

Who should care?

  • Cloud Security Architects designing IAM policies and roles
  • Cloud Engineers implementing privileged access management
  • IT Managers overseeing access reviews and enforcement
  • Compliance Officers validating segregation of duties controls
  • Auditors assessing privileged access processes and procedures

What is the risk?

Failing to properly segregate privileged access roles introduces several risks:

  • Abuse of privileged access - Admins with excessive permissions could intentionally or accidentally expose sensitive data, modify/delete critical resources, or cover their tracks.
  • Undetected malicious activity - Without separating who can access data vs logging and monitoring, a rogue admin could more easily hide malicious actions.
  • Non-compliance with regulations - Many standards like PCI DSS, HIPAA, SOC 2, etc. require duty segregation as part of privileged access management.

Implementing this control can significantly reduce the risk of privileged access being abused or going undetected. It can also help satisfy compliance requirements around restricting and monitoring admin access.

What's the care factor?

For organizations operating in regulated industries or dealing with sensitive data, implementing segregation of privileged access roles is often mandatory, not optional. Failure to comply could lead to failed audits, data breaches, fines, and reputation damage.

Even if not strictly required, all organizations should still care about segregating privileged duties as a security best practice. Restricting admin permissions is a core tenant of least privilege and a strong defense against many prevalent threats. For the relatively low overhead of defining and enforcing separation of duties, it delivers significant risk reduction benefits.

When is it relevant?

Segregation of privileged access roles is most relevant when:

  • Privileged/administrative users exist (which should be almost always)
  • Sensitive data or mission-critical systems are involved
  • Industry or regulatory compliance standards apply
  • Multiple individuals perform privileged functions
  • Admin access spans across production and non-prod environments

It may be less relevant for:

  • Very small teams where people wear many hats
  • Simpler, lower-risk workloads
  • Situations where duties are already inherently separated

However, As a general rule, it's better to implement segregation of duties proactively as a preventative control rather than reactively after an incident has occurred.

What are the trade offs?

Segregating privileged access does require some additional overhead, such as:

  • More time spent defining roles, policies, and processes up front
  • Increased complexity of IAM configuration and management
  • Less flexibility and agility for admins in their daily duties
  • Potentially more roles/accounts to provision and manage over time
  • Productivity impact of admins having to switch between accounts

There's always a balance between security and usability. The goal should be implementing just enough separation of duties to manage risk while minimizing friction to the business. Leveraging tools like AWS IAM Permission Boundaries and AWS Organizations SCPs can help make management more scalable.

How to make it happen?

Here's how you can implement segregation of privileged access roles in an AWS environment:

  1. Define privileged functions - Identify which admin duties exist in your environment such as AWS management console access, direct data/database access, encryption key management, logging and monitoring, etc.
  2. Map duties to IAM permissions - Determine which AWS API actions and resources map to each type of privileged function. For example, data access may use s3:GetObject, rds:ExecuteSql, etc. while logging uses cloudtrail:LookupEvents and logs:FilterLogEvents.
  3. Create separate IAM roles - Create distinct IAM roles for each category of privileged function using the permissions identified above. For example, create an AdminDataAccess, AdminKeyManagement, and AdminLoggingAccess role. Attach IAM policies to each role granting only the permissions it needs.
  4. Configure roles for least privilege - Tighten the scope of access in each role to the smallest set of resources and conditions required using policy conditions like aws:SourceIp, aws:PrincipalOrgPaths, and aws:MultiFactorAuthPresent.
  5. Assign IAM roles to users/groups - Assign the privileged IAM roles to the appropriate IAM users and groups following least privilege. Regularly review membership to ensure only those who need access have it.
  6. Enforce cross-account separation - For added isolation, you can delegate privileged functions to separate AWS accounts using cross-account IAM roles and switchrole access. For example, use a central logging or key management account distinct from production.
  7. Implement IAM boundaries and SCPs - Use IAM Permission Boundaries and Service Control Policies to enforce guardrails on privileged roles, like preventing privilege escalation or restricting access to specific accounts.
  8. Monitor and review usage - Enable CloudTrail logging and CloudWatch alarms to monitor usage of privileged roles for unusual activity. Perform access reviews at least quarterly to revoke any unused or unnecessary permissions.

What are some gotchas?

A few things to watch out for when segregating privileged access roles:

  • IAM policy combinations - Be careful not to unintentionally grant more access than needed when combining IAM policies. Use policy conditions and deny statements to restrict combinations.
  • Service-linked roles - Some AWS services require specific permissions that may span multiple APIs. For example, AWS Lambda requires a mix of IAM, CloudWatch, and S3 permissions. Consider using AWS managed policies for service roles.
  • Key management permissions - Carefully control permissions for KMS key management, especially actions like kms:ScheduleKeyDeletion and kms:DeleteAlias which could lead to unrecoverable data.
  • STS assume role permissions - To allow users to assume separate privileged roles, you'll need to grant sts:AssumeRole permission. But be careful not to allow users to escalate their own permissions by assuming unintended roles.
  • Trust policies for cross-account access - When delegating admin access cross-account, you'll need to configure the trust policy on the IAM role in the trusting account to allow access from the trusted account.

What are the alternatives?

Some alternatives and complimentary approaches to segregating IAM roles include:

  • Using AWS SSO for centralized access - AWS SSO lets you centrally manage access to multiple AWS accounts and business applications. You can use AWS SSO permission sets to enforce separation of duties across accounts.
  • Applying SCPs for guardrails - AWS Organizations Service Control Policies can restrict what IAM principals can do in an account. You can use deny statements to prevent admins from granting themselves excessive permissions.
  • Implementing AWS Serverless services - Using managed services like AWS Lambda, AWS Systems Manager, and AWS Config can reduce the need for privileged access to servers and instances. This limits the scope of admin access.
  • Leveraging third-party PAM tools - Tools like CyberArk, BeyondTrust, and Delinea offer privileged access management solutions that can help manage and monitor privileged sessions across multiple cloud and on-prem environments.

Explore Further

Blog

Learn cloud security with our research blog