Visualizador de Políticas IAM

AWS IAM Policy Visualization

AWS IAM policy documents are JSON structures that define permissions — who can perform which actions on which resources under what conditions. While the JSON format is machine-readable, complex policies with multiple statements, conditional logic, nested principals, and overlapping resource patterns quickly become difficult for humans to parse mentally. A policy visualizer transforms these raw JSON documents into structured, readable layouts that map each statement to its effective permissions, making it immediately clear what a policy allows or denies without manually tracing through nested arrays and wildcard patterns.

IAM policy visualization is essential for documentation, onboarding, security reviews, and compliance audits. When a new team member needs to understand what permissions a service role has, reading a 200-line JSON policy is far less effective than viewing a structured breakdown showing "this role can read objects from these three S3 buckets, write logs to CloudWatch, and invoke these specific Lambda functions — but only when requests originate from the VPC." Visualizing policies transforms abstract JSON into concrete, actionable understanding of access boundaries, helping teams document their permission architecture and communicate security posture clearly across engineering, security, and compliance stakeholders.

Understanding IAM Policy Structure

Every IAM policy document follows a defined structure specified by AWS. Understanding each component is the foundation for meaningful visualization. A policy contains one or more statements, and each statement is an independent permission rule with its own effect, actions, resources, and optional conditions:

• Version: The policy language version — always "2012-10-17" for current policies. This determines which policy grammar features are available, including condition operators and policy variables.
• Statement: An array of individual permission rules. Each statement is self-contained and evaluated independently. The visualizer presents each statement as a distinct card or row, making it clear that permissions are additive (unless explicitly denied).
• Effect: Either "Allow" or "Deny". The visualizer uses color-coding to immediately distinguish allow statements (green) from deny statements (red), making the overall permission posture scannable at a glance.
• Principal: Who the statement applies to — an AWS account, IAM user, role, federated user, or service. Resource-based policies (S3 bucket policies, SQS queue policies) use principals to specify who can access the resource. Identity-based policies attached to users/roles implicitly target the attached entity.
• Action: The specific API operations being allowed or denied. Actions follow the format service:Operation (e.g., s3:GetObject, ec2:DescribeInstances). Wildcards like s3:Get* match multiple actions. The visualizer expands common wildcard patterns to show which operations are actually covered.
• Resource: The ARN(s) specifying which resources the actions apply to. Resources can be specific (arn:aws:s3:::my-bucket/reports/*) or broad (* meaning all resources). The visualizer highlights resource scope to indicate how targeted or broad each permission grant is.
• Condition: Optional constraints that must be true for the statement to take effect. Conditions can restrict by source IP, time of day, MFA status, encryption requirements, VPC origin, and dozens of other context keys. The visualizer renders conditions as human-readable rules: "Only when MFA is present" or "Only from IP range 10.0.0.0/16."

Visual Mapping: From JSON to Readable Permissions

The core value of policy visualization is transforming nested JSON into a layout that answers the fundamental access question: who can do what, on which resources, under what conditions? The visualizer maps each statement to a structured representation:

• Statement cards: Each policy statement is rendered as an independent card with a clear header showing its effect (Allow/Deny) and an optional Sid (statement identifier) as the card title. This makes it easy to reference specific permissions in discussions: "Look at statement AllowS3ReadAccess — it grants broader access than we intended."
• Action grouping by service: When a statement contains actions from multiple AWS services, the visualizer groups them by service prefix. Instead of showing a flat list of 15 actions, it presents "S3: GetObject, PutObject, ListBucket" and "CloudWatch: PutMetricData, GetMetricStatistics" as separate groups, making it clear which services the statement touches.
• Resource scope indicators: Resources are displayed with visual indicators showing their scope. A specific resource ARN appears with a narrow scope icon, while "Resource": "*" shows a broad scope warning. Partial wildcards like arn:aws:s3:::logs-* display with an intermediate scope indicator.
• Condition rendering: Conditions are the most complex part of IAM policies to read in raw JSON. The visualizer translates condition blocks into natural language: {"StringEquals": {"aws:RequestedRegion": "us-east-1"}} becomes "Region must be us-east-1." Compound conditions with multiple keys are rendered as bulleted lists showing all constraints that must be satisfied.
• Multi-statement interaction: When multiple statements in a policy apply to the same resource or service, the visualizer highlights potential overlaps and the effective permission. An explicit Deny always overrides an Allow, and the visualization makes this precedence clear by showing deny statements with higher visual priority.

This structured visualization enables developers to perform quick permission reviews, compare policies side by side, and generate documentation that non-technical stakeholders can understand during compliance audits or access reviews.

Common Policy Patterns and Their Visual Representation

Certain policy patterns appear frequently across AWS environments. Understanding how the visualizer represents these patterns helps teams quickly identify the intent behind a policy:

• Least privilege read-only: Policies granting only Get*, List*, and Describe* actions on specific resources. The visualizer marks these as "Read-Only" patterns, showing that no write, delete, or administrative actions are permitted.
• Service-linked roles: Policies that allow a specific AWS service (principal like lambda.amazonaws.com) to assume the role and perform actions. The visualizer shows the trust relationship and the permissions chain: "Lambda service can assume this role → role can read from DynamoDB table X."
• Cross-account access: Policies with principals from different AWS accounts (arn:aws:iam::123456789012:root). The visualizer highlights cross-account grants with a distinct indicator, as these represent trust boundaries extending outside the organization.
• IP-restricted access: Policies with aws:SourceIp conditions limiting access to specific CIDR ranges. The visualizer displays the allowed IP ranges prominently, making it clear that the permissions only apply from designated network locations.
• MFA-required operations: Sensitive operations gated behind "Bool": {"aws:MultiFactorAuthPresent": "true"}. The visualizer shows an MFA badge on these statements, indicating that multi-factor authentication is mandatory before the permissions take effect.
• Deny with exceptions: Explicit deny statements combined with StringNotEquals or ArnNotLike conditions create "deny everything except" patterns. The visualizer renders these as "Denied unless" rules, clearly showing the exception criteria.

Use Cases for Policy Visualization

Policy visualization serves multiple audiences and workflows across the software development lifecycle:

• Security reviews: During pull requests that modify IAM policies, reviewers can paste the proposed policy into the visualizer to quickly assess what permissions are being granted without mentally parsing JSON. This reduces review time and catches overly broad permissions that might slip through in raw JSON form.
• Documentation and runbooks: Teams can generate visual permission breakdowns for their service roles and include them in architecture documentation. When an incident requires understanding what a compromised role can access, a visual map is immediately actionable — no JSON parsing under time pressure.
• Compliance audits: Auditors reviewing access controls benefit from structured permission views rather than raw policy JSON. The visualizer presents information in the format auditors expect: who has access, to what, under what constraints — mapped directly to compliance control objectives.
• Onboarding and knowledge transfer: New team members understanding an existing permission architecture can use visualized policies to build mental models of how services interact and what boundaries exist, without needing deep IAM expertise to read complex condition blocks and nested resource patterns.
• Policy comparison: When migrating from a legacy policy to a least-privilege version, visualizing both side by side clearly shows which permissions are being removed, added, or modified — making the migration impact explicit and reviewable.

Code Examples

Complex IAM Policy Document with Multiple Statements

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowS3ReadAccess",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:GetObjectVersion",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::production-data-bucket",
        "arn:aws:s3:::production-data-bucket/*"
      ],
      "Condition": {
        "StringEquals": {
          "aws:RequestedRegion": "us-east-1"
        },
        "Bool": {
          "aws:SecureTransport": "true"
        }
      }
    },
    {
      "Sid": "AllowCloudWatchLogging",
      "Effect": "Allow",
      "Action": [
        "logs:CreateLogGroup",
        "logs:CreateLogStream",
        "logs:PutLogEvents"
      ],
      "Resource": "arn:aws:logs:us-east-1:123456789012:log-group:/app/production/*"
    },
    {
      "Sid": "AllowLambdaInvocation",
      "Effect": "Allow",
      "Action": "lambda:InvokeFunction",
      "Resource": [
        "arn:aws:lambda:us-east-1:123456789012:function:process-orders",
        "arn:aws:lambda:us-east-1:123456789012:function:send-notifications"
      ]
    },
    {
      "Sid": "DenyDeleteOperations",
      "Effect": "Deny",
      "Action": [
        "s3:DeleteObject",
        "s3:DeleteBucket",
        "dynamodb:DeleteTable",
        "rds:DeleteDBInstance"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotLike": {
          "aws:PrincipalArn": "arn:aws:iam::123456789012:role/AdminRole"
        }
      }
    },
    {
      "Sid": "RequireMFAForSensitiveActions",
      "Effect": "Deny",
      "Action": [
        "iam:CreateUser",
        "iam:DeleteUser",
        "iam:AttachRolePolicy",
        "iam:PutRolePolicy"
      ],
      "Resource": "*",
      "Condition": {
        "BoolIfExists": {
          "aws:MultiFactorAuthPresent": "false"
        }
      }
    }
  ]
}

Output:

Visual Breakdown:
┌─────────────────────────────────────────────────────┐
│ ✅ ALLOW — AllowS3ReadAccess                        │
│ Actions: s3:GetObject, s3:GetObjectVersion,         │
│          s3:ListBucket                              │
│ Resources: production-data-bucket (bucket + objects)│
│ Conditions:                                         │
│   • Region must be us-east-1                        │
│   • Transport must be HTTPS (SecureTransport)       │
├─────────────────────────────────────────────────────┤
│ ✅ ALLOW — AllowCloudWatchLogging                   │
│ Actions: logs:CreateLogGroup, CreateLogStream,      │
│          PutLogEvents                               │
│ Resources: /app/production/* log groups (us-east-1) │
├─────────────────────────────────────────────────────┤
│ ✅ ALLOW — AllowLambdaInvocation                    │
│ Actions: lambda:InvokeFunction                      │
│ Resources: process-orders, send-notifications       │
├─────────────────────────────────────────────────────┤
│ 🚫 DENY — DenyDeleteOperations                     │
│ Actions: s3:DeleteObject, s3:DeleteBucket,          │
│          dynamodb:DeleteTable, rds:DeleteDBInstance  │
│ Resources: * (ALL resources)                        │
│ Conditions:                                         │
│   • Unless principal is AdminRole                   │
├─────────────────────────────────────────────────────┤
│ 🚫 DENY — RequireMFAForSensitiveActions            │
│ Actions: iam:CreateUser, DeleteUser,                │
│          AttachRolePolicy, PutRolePolicy            │
│ Resources: * (ALL resources)                        │
│ Conditions:                                         │
│   • When MFA is NOT present                         │
└─────────────────────────────────────────────────────┘

Standards & Specifications

• AWS IAM Policy Reference — Official AWS documentation covering policy JSON structure, elements, grammar, and evaluation logic
• IAM JSON Policy Elements Reference — Detailed reference for each policy element: Version, Statement, Effect, Principal, Action, Resource, and Condition
• IAM Policy Evaluation Logic — How AWS evaluates policies when a request is made — deny overrides, implicit deny, and explicit allow determination
• AWS Global Condition Context Keys — Complete list of condition keys available in all AWS services including aws:SourceIp, aws:MultiFactorAuthPresent, and aws:RequestedRegion