Analisador de Políticas IAM

AWS IAM Policy Security Analysis

AWS Identity and Access Management (IAM) policies are JSON documents that define who can do what on which resources in your AWS account. A single misconfigured policy statement can grant an attacker unrestricted access to every service, every resource, and every action in your infrastructure. IAM policy analysis is the practice of systematically examining these JSON documents to detect security violations: wildcard actions (*), wildcard resources (*), missing condition constraints, overly broad service permissions, privilege escalation paths, and violations of the principle of least privilege. Unlike runtime monitoring that detects abuse after it happens, static policy analysis catches dangerous permissions before they are ever attached to a user, role, or group.

The complexity of IAM policies grows exponentially with account size. A typical production AWS account contains dozens of custom policies, each with multiple statements combining Allow and Deny effects across hundreds of possible actions. Understanding the effective permissions granted by overlapping policies — considering statement evaluation logic, implicit denies, explicit denies, condition keys, and resource-level constraints — exceeds what manual review can reliably catch. Automated analysis evaluates every statement against known risk patterns, flags overly permissive configurations, identifies missing deny statements for sensitive operations, and rates findings by severity based on the blast radius of potential exploitation. This shifts IAM security from reactive incident response to proactive policy hardening.

Common IAM Policy Security Issues

Certain patterns in IAM policy documents represent well-known security risks that appear repeatedly across AWS accounts regardless of organization size or maturity:

• Wildcard actions ("Action": "*"): Granting all actions on a service or across all services gives the principal unrestricted capabilities. A compromised credential with "Action": "*" can create new admin users, delete CloudTrail logs, exfiltrate S3 data, launch EC2 instances for cryptomining, and modify security groups — the maximum possible blast radius from a single leaked key. Even service-scoped wildcards like "Action": "s3:*" grant dangerous permissions including s3:DeleteBucket and s3:PutBucketPolicy.
• Wildcard resources ("Resource": "*"): Even when actions are specific, applying them to all resources removes the containment boundary. A policy granting "s3:GetObject" on "Resource": "*" allows reading every object in every bucket — including backups, credentials, and customer data. Resource ARN constraints are the primary mechanism for limiting blast radius within a service.
• Missing condition constraints: Policies without Condition blocks grant permissions unconditionally. High-privilege actions like iam:CreateUser, sts:AssumeRole, or kms:Decrypt should require conditions such as aws:MultiFactorAuthPresent, aws:SourceIp, or aws:PrincipalOrgID to enforce defense in depth beyond the principal's identity.
• Privilege escalation paths: Certain action combinations allow a principal to elevate their own permissions. A user with iam:CreatePolicyVersion can write a new version of their own policy granting "Action": "*". Similarly, iam:AttachUserPolicy, iam:PutUserPolicy, lambda:CreateFunction combined with iam:PassRole, and sts:AssumeRole on overly permissive roles all create escalation vectors that transform limited access into administrative control.
• Missing deny statements: AWS IAM uses a default-deny model where explicit Allow statements grant access. However, relying solely on Allow statements without explicit Deny creates fragile security boundaries. Deny statements for sensitive operations like iam:DeactivateMFADevice, organizations:LeaveOrganization, or cloudtrail:StopLogging provide guardrails that survive policy modifications and prevent accidental permission expansion.

Least Privilege Analysis Techniques

The principle of least privilege dictates that every identity should have only the minimum permissions required to perform its intended function. Analyzing policies for least privilege violations requires evaluating multiple dimensions of each statement:

• Action granularity scoring: Each AWS service exposes specific actions at different granularity levels. The analyzer scores statements based on how broad their action grants are — "s3:*" scores highest risk (all 100+ S3 actions), while "s3:GetObject" scores minimal risk (single read action). Actions are categorized by access level: List, Read, Write, Permissions Management, and Tagging. Write and Permissions Management actions carry higher risk weights than Read or List actions.
• Resource scope evaluation: The analyzer examines ARN patterns in the Resource field to determine containment scope. A resource of "arn:aws:s3:::*" applies to all buckets (account-wide), while "arn:aws:s3:::my-app-data/uploads/*" restricts to a specific prefix in a specific bucket. Broader resource scopes receive higher risk scores, particularly when combined with write or delete actions.
• Condition constraint analysis: The presence and strength of condition keys significantly affects the effective risk of a statement. Conditions like aws:SourceVpc, aws:SourceIp, aws:MultiFactorAuthPresent, and aws:PrincipalOrgID add layers of restriction that reduce exploitability. The analyzer identifies high-privilege statements lacking appropriate conditions and recommends specific condition keys based on the actions involved.
• Cross-statement interaction: A policy's effective permissions emerge from the interaction of all its statements. An Allow statement granting broad access may be partially mitigated by a Deny statement restricting specific resources or actions. The analyzer evaluates the net effective permissions considering statement order, explicit denies overriding allows, and the interaction between identity-based and resource-based policies.
• Unused permission detection: When CloudTrail access logs are available, the analyzer can compare granted permissions against actually-used actions over a time window. Actions granted but never invoked in 90 days represent permission bloat — attack surface that provides no operational value and should be removed to shrink the policy to its minimum effective set.

Severity Rating and Remediation

Not all policy findings carry equal risk. The analyzer classifies each finding by severity based on the exploitability of the misconfiguration and the blast radius if exploited:

• Critical: Findings that grant unrestricted administrative access or enable immediate privilege escalation. Examples: "Action": "*", "Resource": "*" on any principal, iam:CreatePolicyVersion without resource constraint, or sts:AssumeRole on "Resource": "*". Remediation: immediately scope actions and resources to the minimum required set, add MFA conditions for administrative actions.
• High: Findings that grant broad access within a service or enable data exfiltration. Examples: "s3:*" on all buckets, "kms:*" on all keys, or write access to IAM without explicit deny guardrails. Remediation: replace service wildcards with specific action lists, constrain resources to known ARNs, add condition keys for network or organization boundaries.
• Medium: Findings that violate least privilege without immediate exploitation risk. Examples: read access broader than needed, missing conditions on non-administrative actions, or deprecated action usage. Remediation: refine resource ARNs to specific prefixes, add conditions for defense in depth, replace deprecated actions with current equivalents.
• Low: Findings that represent best practice deviations without direct security impact. Examples: policies without descriptions, unused condition keys, or redundant statements. Remediation: add documentation, clean up redundant statements, consolidate overlapping policies for maintainability.

Each finding includes a specific remediation recommendation with a corrected policy snippet showing the minimum-privilege alternative. The analyzer explains what the current statement grants, why it is risky, and exactly how to narrow it while maintaining the intended functionality.

IAM Policy Evaluation Logic

Understanding how AWS evaluates IAM policies is essential for interpreting analysis results. The evaluation follows a deterministic order that governs whether a request is allowed or denied:

• Default deny: Every request starts as implicitly denied. Without an explicit Allow statement matching the action, resource, and conditions, the request is rejected. This means an empty policy grants zero permissions — security by default.
• Explicit deny overrides: If any applicable policy contains an explicit Deny statement matching the request, the request is denied regardless of any Allow statements in any other policy. This makes Deny statements powerful guardrails — they cannot be overridden by permissions granted elsewhere, making them the strongest tool for creating permission boundaries.
• Allow evaluation: If no explicit Deny matches and at least one Allow statement matches the request's action, resource, and conditions, the request proceeds. The Allow can come from identity-based policies (attached to the principal), resource-based policies (attached to the target resource), permission boundaries, session policies, or service control policies.
• Condition evaluation: Condition blocks are evaluated as part of statement matching. All condition keys within a single condition block must be satisfied (AND logic), while multiple values for a single key use OR logic. If a condition references a key that is not present in the request context, the condition evaluates to false and the statement does not match — this can cause unexpected access denials for service-to-service calls that lack certain context keys.
• Cross-account considerations: For cross-account access, both the source account (identity-based policy) and the target account (resource-based policy) must allow the action. The analyzer identifies statements granting cross-account access via aws:PrincipalAccount or principal ARNs from external accounts, flagging these for additional review as they expand the trust boundary beyond the organization.

Code Examples

Overly Permissive Policy vs Least-Privilege Alternative

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "OverlyPermissive",
      "Effect": "Allow",
      "Action": "*",
      "Resource": "*"
    }
  ]
}

// ─── Analysis Findings ───────────────────────────────
// [CRITICAL] Wildcard actions: grants ALL actions across ALL services
// [CRITICAL] Wildcard resource: applies to every resource in the account
// [HIGH] No condition constraints: no MFA, IP, or org restrictions
// [HIGH] Privilege escalation: can create admin users, modify own policies
// [MEDIUM] No deny guardrails: no explicit deny for destructive operations

// ─── Remediated Least-Privilege Policy ───────────────

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowSpecificS3Access",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::my-app-uploads",
        "arn:aws:s3:::my-app-uploads/*"
      ],
      "Condition": {
        "StringEquals": {
          "aws:PrincipalOrgID": "o-exampleorgid"
        },
        "IpAddress": {
          "aws:SourceIp": "10.0.0.0/16"
        }
      }
    },
    {
      "Sid": "AllowCloudWatchLogs",
      "Effect": "Allow",
      "Action": [
        "logs:CreateLogGroup",
        "logs:CreateLogStream",
        "logs:PutLogEvents"
      ],
      "Resource": "arn:aws:logs:us-east-1:123456789012:log-group:/app/my-service:*"
    },
    {
      "Sid": "DenyDestructiveActions",
      "Effect": "Deny",
      "Action": [
        "iam:DeactivateMFADevice",
        "organizations:LeaveOrganization",
        "cloudtrail:StopLogging",
        "cloudtrail:DeleteTrail"
      ],
      "Resource": "*"
    }
  ]
}

Standards & Specifications

• AWS IAM Policy Reference — Official AWS documentation covering IAM policy syntax, elements, variables, and evaluation logic
• IAM Policy Evaluation Logic — Detailed explanation of how AWS evaluates policies including cross-account access, permission boundaries, and SCPs
• IAM Actions, Resources, and Condition Keys — Complete reference of all AWS service actions, resource ARN formats, and available condition context keys
• AWS IAM Best Practices — AWS-recommended practices for least privilege, MFA enforcement, credential rotation, and policy management