Cloud service providers should have well-defined processes for allowing customers to participate in granting privileged access to high-risk roles, where applicable. Privileged access should be restricted based on least privilege and need-to-know. Rigorous approval, logging, and monitoring controls are essential for preventing abuse of admin powers.

Where did this come from?

This control comes from the CSA Cloud Controls Matrix v4.0.10 released on 2023-09-26. You can download the full CCM spreadsheet here. The CCM provides a comprehensive set of security controls that are relevant for cloud computing. For related AWS best practices, check out the AWS Identity and Access Management User Guide.

Who should care?

• Cloud security architects designing IAM controls for privileged access
• DevOps engineers implementing least privilege for admin accounts
• Compliance officers assessing risk of insider threats from overprivileged users

What is the risk?

Allowing unrestricted privileged access significantly increases the blast radius if an admin account is compromised by an attacker or malicious insider. A bad actor with "god mode" could steal sensitive data, install malware, disrupt systems, and cause major damage. Lack of oversight and logging of privileged actions makes it difficult to detect abuse. Even well-meaning admins can cause unintended harm if granted excessive powers.

What's the care factor?

Restricting and monitoring privileged access should be a top priority, especially for high-risk roles that can impact critical systems, customer data, and business operations. Major security incidents often involve compromised admin credentials, so tightly controlling privileged access is crucial. However, don't severely hamper productivity either - find the right balance between security and efficiency.

When is it relevant?

This control applies whenever users need elevated privileges beyond a standard user account. Common scenarios include:

• Sysadmins managing production infrastructure
• Security analysts investigating incidents
• Developers deploying code to sensitive environments
• Database admins handling customer PII
• Vendors remotely accessing internal systems for support

The control is less relevant for:

• Low-risk dev/test environments with no sensitive data
• Non-privileged user accounts
• Fully automated processes with no human access

What are the trade-offs?

Implementing least privilege and approval workflows for privileged access requires significant effort to define roles, map permissions, integrate with ticketing systems, etc. Productivity may be impacted if approval processes are too rigid or restrictive. Admins may be tempted to share accounts to bypass controls. Detailed logging of privileged actions consumes storage and compute for SIEM analysis. Legacy systems may not support granular privileges.

How to make it happen?

1. Inventory all human and machine identities needing privileged access
2. Define least privilege roles in IAM mapped to job functions
3. Eliminate any unneeded or unused privileged accounts
4. Integrate privileged access requests with ticketing system for approval workflows
5. Require MFA for all privileged user access
6. Restrict privileged access to specific IP ranges where possible
7. Log all privileged commands to CloudTrail, OS, and app audit logs
8. Feed privileged activity logs into SIEM for automated analysis and alerting
9. Monitor and alert on creation of new privileged accounts
10. Regularly review and right-size permissions for privileged accounts
11. Implement just-in-time privilege elevation and time-bound access

For AWS specifics, use IAM Roles and Policies to define least privilege. Integrate with SAML/OIDC providers for approval flows. Enable CloudTrail logging. Use AWS Certificate Manager for MFA. Monitor meta-events with CloudWatch. Analyze logs with Amazon Detective/GuardDuty.

What are some gotchas?

• Complex applications may require privileged access to many services - avoid granting blanket *.* permissions
• EC2 instances need an IAM Instance Profile with permissions to access APIs, not IAM User keys
• S3 Access Points can help restrict privileged access to specific VPC/prefixes
• IAM Roles/Policies have a 6,144 character size limit
• Service Control Policies can help restrict privileged access at the AWS Organization level

Not all AWS services support granular IAM permissions - refer to AWS documentation for each service.

What are the alternatives?

• Use AWS SSO Permission Sets to manage privileged access across accounts
• Consider AWS Session Manager for secure admin access to EC2 without SSH keys
• Terraform IAM Modules can help define reusable least privilege roles
• Privileged Access Management (PAM) tools like CyberArk or BeyondTrust can streamline enterprise approval workflows

Explore Further

• CIS Benchmark 1.2 recommends logging all root account use
• CIS Benchmark 1.19 recommends IAM Access Analyzer to find overprivileged IAM policies
• AWS re:Inforce 2022 SEC316 session on right-sizing IAM permissions
• Using AWS IAM Access Analyzer to review permissions