Skip to main content
← All controls
AC-6 / AC-6(1) / AC-6(2) / A.9.2.3 / CIS-5.4 NIST SP 800-53 Rev 5

Do you enforce least privilege for cloud roles (no wildcard / *:* policies)?

Demonstrate that cloud IAM roles and policies are configured without wildcard or overly permissive grants, enforce minimum necessary privileges aligned to functional requirements, and are subject to periodic review and enforcement mechanisms.

Description

What this control does

This control requires that all cloud identity and access management (IAM) roles, policies, and service principals be configured with the minimum permissions necessary to perform their intended functions, explicitly prohibiting the use of wildcard permissions (e.g., '*:*', 'Action: *', 'Resource: *') that grant broad or unrestricted access. Implementation involves defining granular permissions based on job functions, applying resource-level restrictions, and systematically reviewing policies to eliminate overly permissive grants. Enforcing least privilege in cloud environments reduces the blast radius of compromised credentials, limits lateral movement, and ensures accountability through traceable, scoped permissions.

Control objective

What auditing this proves

Demonstrate that cloud IAM roles and policies are configured without wildcard or overly permissive grants, enforce minimum necessary privileges aligned to functional requirements, and are subject to periodic review and enforcement mechanisms.

Associated risks

Risks this control addresses

  • Attackers who compromise a single credential with wildcard permissions gain unrestricted access to all cloud resources, enabling data exfiltration, resource destruction, or persistent backdoor installation across the entire environment
  • Insider threats or negligent users with excessive privileges can intentionally or accidentally modify critical infrastructure, delete production data, or disable security controls without technical barriers
  • Lateral movement across cloud services and accounts becomes trivial when roles possess broad permissions, allowing adversaries to escalate from low-value to high-value targets without detection
  • Compliance violations occur when audit trails cannot distinguish legitimate from unauthorized actions due to shared overly permissive roles, undermining forensic investigations and regulatory evidence requirements
  • Service account or automation credential compromise results in widespread impact as automated processes with wildcard permissions can be weaponized to modify infrastructure, access secrets, or alter logging configurations
  • Credential stuffing or phishing attacks yield disproportionate returns for attackers when stolen credentials carry administrative-level wildcard permissions, increasing the organization's attack surface value
  • Privilege creep accumulates over time as temporary wildcard grants become permanent, creating technical debt that prevents effective access governance and increases the likelihood of policy violation

Testing procedure

How an auditor verifies this control

  1. Obtain a complete inventory of all IAM roles, policies, service principals, and managed identities across all cloud subscriptions, accounts, and tenants in scope
  2. Export policy documents for all custom IAM policies, inline policies attached to roles, and resource-based policies from cloud infrastructure resources
  3. Search exported policy documents programmatically and manually for wildcard characters in Action, Resource, Principal, or NotAction fields, including '*', '*:*', and service-specific wildcards like 's3:*' or 'Microsoft.*/*'
  4. For each identified wildcard policy, document the role or principal to which it is attached, the business justification on record, the date of last review, and the scope of resources affected
  5. Select a representative sample of roles spanning administrative, application, automation, and end-user categories, and compare assigned permissions against documented job functions or service requirements to assess proportionality
  6. Review access logs and CloudTrail/Azure Activity Log/GCP Audit Logs for sampled roles over the past 90 days to identify permissions granted but never exercised, indicating over-provisioning
  7. Interview identity and access management personnel to verify the existence of a formal least privilege policy, approval workflow for permission grants, and scheduled review cadence for cloud roles
  8. Test enforcement mechanisms by attempting to create a new IAM policy with wildcard permissions through the management console or API to verify whether preventive controls (e.g., policy validators, service control policies, Azure Policy) block or flag the action
Evidence required Collect exported IAM policy JSON/XML documents from all cloud providers showing Action, Resource, and Principal definitions; screenshots or query results from cloud security posture management (CSPM) tools or native compliance dashboards highlighting wildcard usage; access review reports with approval records and remediation tracking; CloudTrail, Azure Monitor, or GCP logging exports showing actual permission utilization over 90 days; documented least privilege policy and role definition standards; and test results from attempting to create non-compliant wildcard policies demonstrating preventive control efficacy.
Pass criteria No IAM roles, policies, or service principals in production environments contain wildcard permissions for Action or Resource fields except where formally documented, approved by security leadership, scoped to read-only operations or non-sensitive resources, reviewed at least quarterly, and compensating detective controls are demonstrably active.