DEV Community: Terry Quispe Paniagua

🛡️ AWS IAM Access Analyzer — Parte 4/4

Terry Quispe Paniagua — Sun, 16 Aug 2026 19:22:47 +0000

Después de probar External Access e Internal Access, me quedaba una tercera capacidad de IAM Access Analyzer por revisar: Unused Access.

La pregunta que quería responder era bastante simple:

¿Qué accesos sigo manteniendo aunque ya no se estén utilizando?

Pero había otra pregunta todavía más importante:

Si IAM ya muestra Last activity y datos de Last accessed, ¿por qué pagaría por otro analyzer?

Para responderlo configuré un analyzer real sobre una de mis cuentas, limité deliberadamente el scope para controlar el costo y lo dejé trabajando durante una semana.

El resultado fueron 18 findings sobre 17 principals, incluyendo roles completos sin uso, una contraseña de consola y, probablemente lo más interesante, permisos sin utilizar dentro de principals que no necesariamente estaban completamente inactivos.

Antes del lab: External vs Internal vs Unused Access

Las tres capacidades responden preguntas diferentes.

Analyzer	Pregunta principal	Qué analiza	Pricing
External Access	¿Quién puede acceder desde fuera de mi zona de confianza?	Recursos y resource-based policies	Sin cargo adicional
Internal Access	¿Qué principals internos pueden acceder a recursos específicos?	Permisos efectivos sobre recursos seleccionados	Por recurso monitoreado/mes/región
Unused Access	¿Qué roles, credenciales o permisos ya no se utilizan?	IAM users y roles	Por IAM user/role analizado/mes

AWS documenta estas tres capacidades por separado porque no realizan el mismo análisis. External busca exposición pública o cross-account; Internal calcula acceso interno a recursos seleccionados; Unused analiza actividad histórica de identidades y permisos.

El laboratorio

No quería activar el analyzer sobre todo sin controlar primero el costo.

La configuración quedó así:

Analyzer:       UnusedAccess-Lab
Type:           ACCOUNT_UNUSED_ACCESS
Scope:          Current account
Tracking period: 60 days

Exclusion tag:
UnusedAnalyzerExclude=true

Antes de crearlo etiqueté 30 roles que no quería incluir en este experimento.

Después de las exclusiones quedaron en scope:

16 IAM roles
 1 IAM user
-----------
17 principals

Los service-linked roles tampoco forman parte del análisis. Son roles de IAM creados y administrados por servicios de AWS para ejecutar acciones en tu cuenta en nombre de ese servicio. Normalmente utilizan la ruta /aws-service-role/.

Unused Access Analyzer no los evalúa, por lo que tampoco cuentan dentro del número de roles analizados.

El tracking period fue de 60 días.

Esto no significa que haya que crear el analyzer y esperar 60 días. IAM Access Analyzer utiliza la información de last accessed que IAM ya mantiene, por lo que puede generar findings usando actividad anterior a la creación del analyzer.

El período configurado funciona como el umbral para generar los findings: un role puede aparecer cuando lleva ese tiempo inactivo, mientras que un permiso, password o access key puede aparecer cuando supera ese período sin uso. Para los permisos, AWS especifica además que solo evalúa permisos de entidades IAM que hayan existido durante todo el tracking period.

AWS permite configurar entre 1 y 365 días.

¿Cuánto cuesta Unused Access Analyzer?

Esta parte conviene entenderla antes de activarlo sobre una organización completa.

AWS cobra actualmente:

$0.20 USD
por IAM user o IAM role analizado
por analyzer
por mes

No cobra por finding.

En este laboratorio dejé 17 principals dentro del análisis:

17 × $0.20 = $3.40 USD/mes

Ese era el costo teórico del scope que había definido.

Y esta diferencia es importante porque finalmente obtuve 18 findings, pero eso no significa:

18 × $0.20

La unidad de cobro es el principal analizado, no el número de findings que genera.

AWS cobra los analyzers de Internal y Unused Access una vez durante su configuración y, después, el primer día de cada mes calendario.

En este laboratorio activé UnusedAccess-Lab el 9 de agosto, por lo que el análisis inicial se cobró ese día. El siguiente ciclo de cobro no ocurre 30 días después, el 9 de septiembre, sino el 1 de septiembre para los principals que continúen dentro del análisis.

Por eso las exclusiones por tags pueden ser especialmente útiles. AWS permite excluir IAM users y roles mediante pares key=value; esos principals dejan de generar findings dentro de ese analyzer.

En mi caso utilicé:

UnusedAnalyzerExclude=true

Después de una semana: 18 findings

El resultado terminó así:

Finding type	Cantidad
`UnusedIAMRole`	14
`UnusedIAMUserPassword`	1
`UnusedPermission`	3
`UnusedIAMUserAccessKey`	0
Total	18

Los 18 findings corresponden a 17 principals porque un mismo principal puede generar más de un tipo de finding.

Eso ocurrió precisamente con el IAM user terraform.

Finding 1: un role realmente abandonado

Uno de los casos más simples fue:

Role:
ec2rolssm

Finding:
UnusedIAMRole

Last accessed:
2025-11-23 03:52:31 UTC

Con un tracking period de 60 días, no había mucha ambigüedad: el role llevaba muchísimo más tiempo sin actividad.

El analyzer generó:

findingType: UnusedIAMRole
status: ACTIVE

y mantuvo también el timestamp de su último acceso.

Este es probablemente el caso que cualquiera esperaría de un producto llamado Unused Access: encontrar roles que siguen existiendo aunque aparentemente ya nadie los use.

Pero este tampoco es el caso que justifica por sí solo pagar por el feature.

Para detectar algo así, IAM ya tiene información de último uso.

Lo interesante viene después.

Finding 2: también aparecieron roles de IAM Identity Center

Entre los findings apareció:

AWSReservedSSO_AWSAdministratorAccess_xxxxxxxxxxxxxxx

con:

Finding:
UnusedIAMRole

Last accessed:
2025-10-06 01:52:45 UTC

Es un role AWSReservedSSO_* generado por IAM Identity Center y también terminó identificado como unused.

No fue el único. Varios de los AWSReservedSSO_* que quedaron dentro del scope generaron findings.

Hay además una limitación relacionada: si un role de IAM Identity Center genera un finding de tipo UnusedPermission, AWS no soporta policy recommendations para ese tipo de role.

Finding 3: una contraseña que sigue existiendo pero ya no se usa

El único IAM user del experimento era:

terraform

y generó:

findingType:
UnusedIAMUserPassword

lastAccessed:
2026-05-03 15:50:22 UTC

Es decir: la contraseña de consola seguía asociada al IAM user, pero había superado ampliamente nuestra ventana de 60 días sin uso.

Este tipo de finding me parece más útil que revisar solamente roles.

Unused Access Analyzer también puede detectar:

Unused IAM roles
Unused IAM user passwords
Unused IAM user access keys
Unused permissions

En este lab no apareció ninguna access key unused, así que no voy a fabricar un ejemplo que no ocurrió.

Finding 4: acá está la diferencia real con `Last activity`

El mismo user terraform generó además:

findingType:
UnusedPermission

Y este finding es mucho más interesante.

El JSON devuelto por GetFindingV2 contenía 453 bloques unusedPermissionDetails y, dentro de ellos, 302 acciones individuales distribuidas en cinco servicios.

Es decir, el problema no era simplemente:

"este user nunca se usa"

El finding no estaba limitado a un solo servicio. Aparecían permisos no utilizados en una gran cantidad de servicios; entre ellos ACM, CloudFormation, IAM, Route 53 y muchos otros.

Para mostrar el comportamiento sin convertir esta sección en una lista enorme, tomemos ACM como ejemplo.

El finding registraba actividad reciente sobre el servicio:

serviceNamespace:
acm

lastAccessed:
2026-08-12

Pero dentro del mismo servicio aparecían acciones consideradas unused como:

acm:RequestCertificate
acm:ExportCertificate
acm:RenewCertificate
acm:ImportCertificate
acm:DeleteCertificate
...

Algo parecido ocurría con CloudFormation e IAM: el servicio podía tener actividad reciente mientras numerosas acciones concedidas seguían apareciendo dentro del análisis de permisos no utilizados.

Y ahí está para mí el punto más fuerte del feature:

Que un principal esté activo no significa que necesite todos los permisos que tiene.

Entonces, ¿qué aporta si IAM ya muestra `Last activity`?

IAM ya tiene esa información y no tiene sentido ignorarlo.

Por ejemplo, RoleLastUsed puede indicar:

Last used date
Region

para un role, con información disponible para los últimos 400 días.

IAM también dispone de datos de service last accessed y, para servicios soportados, información a nivel de acción.

De hecho, AWS documenta explícitamente que Unused Access Analyzer utiliza esa información de last accessed para generar sus findings.

Así que Unused Access Analyzer no tiene una fuente mágica de telemetría diferente.

La diferencia es operacional:

IAM	Unused Access Analyzer
Consulto un principal	Analiza principals a escala de cuenta u organización
Veo cuándo se usó un role	Genera `UnusedIAMRole`
Reviso manualmente credenciales	Detecta password/access key unused
Reviso Last Accessed	Genera findings de permisos unused
Investigación puntual	Monitoreo continuo
Datos	Findings gestionables

La forma corta de decirlo sería:

IAM te entrega la evidencia. Unused Access Analyzer convierte esa evidencia en un proceso continuo de detección.

Para cinco roles probablemente puedo hacer una revisión manual.

Para cientos o miles de roles y users distribuidos por una AWS Organization, la conversación cambia (y el costo también).

Algo que observé: los findings no aparecieron todos al mismo tiempo

El analyzer fue creado el:

2026-08-09

Los findings de roles y password aparecieron ese mismo día.

Sin embargo, los tres findings de UnusedPermission se crearon posteriormente, el:

2026-08-13

Cuatro días después.

Y al revisar el JSON una semana después todos habían sido reanalizados nuevamente el 16 de agosto.

AWS no proporciona un tiempo exacto para que todos los findings estén disponibles; su documentación simplemente advierte que después de crear o actualizar un analyzer puede tomar tiempo antes de que aparezcan.

Para una prueba rápida puedes mirar los primeros findings casi inmediatamente, pero para una auditoría yo no asumiría que la primera pantalla representa necesariamente todo el análisis final.

Limitaciones que conviene conocer

1. Unused no significa automáticamente innecesario.

Un role de DR, una cuenta break-glass (acceso de emergencia) o un proceso trimestral puede pasar 60 días sin utilizarse y seguir siendo necesario.

El tracking period tiene que corresponder con el ciclo real de uso de tus accesos.

2. El detalle action-level tiene límites.

AWS puede evaluar unused permissions a nivel de servicio ampliamente, pero el análisis a nivel de acción depende de los servicios y acciones para los que IAM dispone de action last accessed information.

3. Los service-linked roles no se analizan.

No generan findings de unused access y tampoco forman parte del total de roles analizados para pricing.

4. No todos mis findings trajeron el mismo nivel de detalle.

En el JSON hubo varios UnusedIAMRole donde:

"unusedIamRoleDetails": {}

sin un lastAccessed explícito.

Otros roles sí incluían la fecha.

Por eso no asumiría que cada finding tendrá exactamente la misma evidencia disponible.

Del finding a una policy de mínimo privilegio

Hasta aquí el analyzer ya había identificado qué permisos del principal no se estaban utilizando, pero el finding tenía otra funcionalidad interesante.

Al seleccionar un servicio, la consola abre un panel lateral con las acciones que no se han utilizado. Por ejemplo, para Certificate Manager aparecían 14 acciones sin uso.

Esto permite bajar del nivel:

Certificate Manager tiene permisos no utilizados

a acciones concretas como:

acm:DeleteCertificate
acm:ExportCertificate
acm:GetCertificate
acm:ImportCertificate
acm:RenewCertificate
acm:RequestCertificate
...

Pero el analyzer no se queda únicamente en mostrar el finding.

El IAM user terraform tenía asociadas estas tres policies:

backuppolicy
AdministratorAccess
putalternatecontact

En la sección Recommendations, Access Analyzer evaluó esas policies y mostró:

Existing policy          Recommended policy
--------------------------------------------------------
backuppolicy             None
AdministratorAccess      AdministratorAccess-recommended
putalternatecontact      None

Para backuppolicy y putalternatecontact no propuso una policy de reemplazo; la recomendación es retirar esas policies existentes. Para AdministratorAccess, en cambio, generó AdministratorAccess-recommended como policy de reemplazo.

Al abrir Preview policy, la consola permite comparar lado a lado la policy existente AdministratorAccess, que concede:

{
  "Effect": "Allow",
  "Action": "*",
  "Resource": "*"
}

con la policy recomendada, que contiene un conjunto mucho más reducido de permisos.

Esta recomendación puede utilizarse para sustituir AdministratorAccess por permisos más ajustados y aplicar el principio de mínimo privilegio.

Importante: Access Analyzer genera la recomendación, pero no reemplaza automáticamente la policy. AWS indica que primero debes crear y adjuntar la policy recomendada y después retirar la policy existente.

Aquí es donde Unused Access Analyzer aporta algo más que simplemente indicar cuándo se utilizó por última vez un principal: además de detectar permisos no utilizados, puede proponer cómo reducir las permissions policies existentes.

La policy recomendada debe revisarse antes de aplicarla. Un permiso que no se utilizó durante el período analizado puede seguir siendo necesario para una tarea menos frecuente.

¿Lo habilitaría en producción?

Depende de la escala.

Si solamente tengo unos pocos roles y quiero responder:

¿Cuándo se utilizó este role por última vez?

IAM ya me da información suficiente para hacer esa revisión manual.

Pero si quiero responder continuamente:

¿Qué roles llevan demasiado tiempo sin utilizarse?

¿Qué IAM users conservan passwords o access keys abandonadas?

¿Qué principals siguen activos pero tienen permisos que nunca utilizan?

¿Dónde tengo oportunidades de reducir privilegios?

entonces Unused Access Analyzer sí agrega una capa operacional útil.

En una organización grande no lo habilitaría sin pensar primero en el scope y en el costo.

La tarifa parece pequeña:

$0.20 / principal / mes

pero:

100 principals   = $20/mes
1,000 principals = $200/mes
10,000 principals = $2,000/mes

por analyzer.

Las exclusiones mediante tags existen precisamente para controlar qué principals quieres analizar. AWS incluso recomienda utilizar una estrategia de tagging y exclusiones como mecanismo de optimización de costos.

Conclusión

Este laboratorio empezó con una duda bastante válida:

¿Para qué pagar por Unused Access Analyzer si IAM ya muestra Last activity?

Después de revisar los findings, mi respuesta es que no compiten exactamente por lo mismo.

Si quiero investigar un role concreto, IAM ya tiene información muy útil.

Pero Unused Access Analyzer toma esa información y la convierte en un mecanismo continuo para encontrar roles abandonados, credenciales sin uso y, sobre todo, permisos sobrantes dentro de principals que todavía tienen actividad.

En mi caso, encontrar roles que no se utilizaban desde hacía meses era esperado.

Lo que aportó más información fue ver un principal con actividad sobre determinados servicios mientras seguía acumulando cientos de permisos que el analyzer identificaba como no utilizados.

Ahí es donde el feature empieza a tener sentido para least privilege.

Eso sí: unused no significa automáticamente removable.

El finding es el inicio de la revisión, no la autorización para borrar permisos a ciegas.

Y, como con los otros analyzers de esta serie, primero conviene tener claro qué pregunta quieres responder. External, Internal y Unused Access pueden vivir bajo IAM Access Analyzer, pero están mirando problemas de seguridad bastante diferentes.

Referencias

AWS #IAM #AccessAnalyzer #CloudSecurity #LeastPrivilege #AWSOrganizations #DevSecOps #IAMSecurity

AWS IAM Access Analyzer Internal Access: Effective Permissions, SCPs, RCPs, and an Unexpected Finding

Terry Quispe Paniagua — Sun, 26 Jul 2026 16:31:02 +0000

Real-world demo: effective permissions, SCPs, RCPs, and a comparison that did not go as expected

In the previous part, I explained the problem: in environments with multiple accounts, roles, and layered policies, figuring out who actually has access to a resource is not something you can answer by opening the console and reviewing a single IAM policy.

In this post, I go straight to the lab. I configured a scenario with two accounts inside the same AWS Organization, an S3 bucket in one account, several IAM roles in another, and multiple control layers affecting access: IAM, a bucket policy, an SCP, an RCP, and a permissions boundary attached to the administrator role.

The goal was not only to verify whether an action worked, but also to compare what was configured, what IAM Access Analyzer Internal Access reported, and what actually happened when the APIs were called.

⚠️ Cost note before you begin

IAM Access Analyzer External Access has no additional charge, but Internal Access Analyzer is a paid capability. AWS charges $9.00 USD per monitored resource, per analyzer, per Region, per month. This lab monitors only one S3 bucket, so the estimated cost was $9.00 USD/month while the analyzer remained active. If you enable it across multiple production resources, the cost scales linearly: 10 resources = $90 USD/month, and 38 resources across 5 accounts = $342 USD/month, as shown in the example on the official AWS pricing page.

Lab: validating cross-account access within the same AWS Organization using IAM Access Analyzer Internal Access

In this lab, I validated how IAM Access Analyzer Internal Access represents access from roles in one account to an S3 bucket located in another account within the same organization.

The scenario started with two roles:

RoleReadOnly
RoleAdmin

I then added two control roles to compare whether the way actions were declared affected the results:

RoleDiagnosticExplicitNoBoundary
RoleAdminWildcardNoBoundary

I also added three controls:

An SCP to block s3:DeleteObject and s3:DeleteObjectVersion
An RCP to block s3:PutObject
A permissions boundary attached to RoleAdmin

Architecture

AWS Organization
└── Lab OU
    ├── Account A — resource owner
    │   └── S3 bucket: demo-internal-aa-2026
    │
    └── Account B — principal owner
        ├── RoleReadOnly
        ├── RoleAdmin
        ├── RoleDiagnosticExplicitNoBoundary
        └── RoleAdminWildcardNoBoundary

Account A contains the S3 bucket, while Account B contains the roles that attempt to access it. Both accounts are inside the same OU, and both the SCP and the RCP were attached to that OU. The SCP limits the actions available to principals in the accounts under the OU, while the RCP limits access to resources in those accounts. In this lab, the ARN defined in the RCP restricts the deny to the bucket in Account A. The permissions boundary is attached directly to RoleAdmin.

The image above represents the first phase of the lab, when I was working only with RoleReadOnly and RoleAdmin. The other two roles were added later to make the comparison more controlled.

Objective

The lab validates seven things:

Which roles inside the organization appear as having access to the bucket.
Which actions the finding reports for each role.
How an SCP blocks an action even when IAM and the bucket policy allow it.
How an RCP blocks an action from the resource side.
How a permissions boundary limits the maximum permissions of a role.
What changes when actions are declared explicitly instead of using s3:*.
Whether the finding matches the actual API execution results.

Role	Configured permissions	Boundary
RoleReadOnly	ListBucket and GetObject	No
RoleAdmin	s3:*	Yes: limited to ListBucket, GetObject, PutObject, and DeleteObject
RoleAdminWildcardNoBoundary	s3:*	No
RoleDiagnosticExplicitNoBoundary	ListBucket, GetBucketPolicy, GetObject, PutObject, and DeleteObject	No

The SCP blocks s3:DeleteObject and s3:DeleteObjectVersion.

The RCP blocks s3:PutObject on the lab bucket.

Step 1: Create the roles in Account B

From CloudShell in Account B, define the environment variables:

export ACCOUNT_B_ID="<ACCOUNT_B_ID>"
export BUCKET_NAME="demo-internal-aa-2026" # example

Validate the current identity:

aws sts get-caller-identity

Next, create the trust policy that allows the roles to be assumed from within Account B:

cat > trust-account-b.json <<EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowAssumeRoleFromAccountB",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::$ACCOUNT_B_ID:root"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
EOF

Create the four roles:

for ROLE in \
  RoleReadOnly \
  RoleAdmin \
  RoleDiagnosticExplicitNoBoundary \
  RoleAdminWildcardNoBoundary
do
  aws iam create-role \
    --role-name "$ROLE" \
    --assume-role-policy-document file://trust-account-b.json
done

Step 2: Assign IAM permissions to the roles

RoleReadOnly — can only list and read:

cat > role-readonly-policy.json <<EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ListBucket",
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::$BUCKET_NAME"
    },
    {
      "Sid": "ReadObjects",
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::$BUCKET_NAME/*"
    }
  ]
}
EOF

aws iam put-role-policy \
  --role-name RoleReadOnly \
  --policy-name DemoBucketReadOnlyAccess \
  --policy-document file://role-readonly-policy.json

RoleAdmin — allows s3:* on the bucket and its objects:

cat > role-admin-policy.json <<EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AdminBucketAccess",
      "Effect": "Allow",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::$BUCKET_NAME",
        "arn:aws:s3:::$BUCKET_NAME/*"
      ]
    }
  ]
}
EOF

aws iam put-role-policy \
  --role-name RoleAdmin \
  --policy-name DemoBucketAdminAccess \
  --policy-document file://role-admin-policy.json

RoleDiagnosticExplicitNoBoundary

This role explicitly declares the actions I wanted to compare:

cat > role-diagnostic-explicit-policy.json <<EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DiagnosticBucketActions",
      "Effect": "Allow",
      "Action": [
        "s3:ListBucket",
        "s3:GetBucketPolicy"
      ],
      "Resource": "arn:aws:s3:::$BUCKET_NAME"
    },
    {
      "Sid": "DiagnosticObjectActions",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:DeleteObject"
      ],
      "Resource": "arn:aws:s3:::$BUCKET_NAME/*"
    }
  ]
}
EOF

aws iam put-role-policy \
  --role-name RoleDiagnosticExplicitNoBoundary \
  --policy-name DiagnosticExplicitNoBoundaryAccess \
  --policy-document file://role-diagnostic-explicit-policy.json

RoleAdminWildcardNoBoundary

This role keeps the wildcard and has no boundary:

cat > role-admin-wildcard-policy.json <<EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AdminWildcardBucketAccess",
      "Effect": "Allow",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::$BUCKET_NAME",
        "arn:aws:s3:::$BUCKET_NAME/*"
      ]
    }
  ]
}
EOF

aws iam put-role-policy \
  --role-name RoleAdminWildcardNoBoundary \
  --policy-name AdminWildcardNoBoundaryAccess \
  --policy-document file://role-admin-wildcard-policy.json

Step 2.1: Add a permissions boundary to RoleAdmin

In addition to its inline policy with s3:*, RoleAdmin has a permissions boundary.

The purpose was not to replace the SCP or the RCP. I wanted to add a layer that explicitly defined the maximum set of actions available to the role.

The boundary allows:

s3:ListBucket
s3:GetObject
s3:PutObject
s3:DeleteObject

For example, it does not allow:

s3:GetBucketPolicy
s3:GetBucketAcl
s3:GetBucketVersioning

cat > role-admin-boundary.json <<EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ListBucket",
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::$BUCKET_NAME"
    },
    {
      "Sid": "PowerUserObjects",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:DeleteObject"
      ],
      "Resource": "arn:aws:s3:::$BUCKET_NAME/*"
    }
  ]
}
EOF

aws iam create-policy \
  --policy-name boundary-adminuser \
  --policy-document file://role-admin-boundary.json

aws iam put-role-permissions-boundary \
  --role-name RoleAdmin \
  --permissions-boundary \
    "arn:aws:iam::$ACCOUNT_B_ID:policy/boundary-adminuser"

Validation:

aws iam get-role \
  --role-name RoleAdmin \
  --query 'Role.PermissionsBoundary' \
  --output json

Step 3: Configure the bucket policy in Account A

From CloudShell in Account A:

export ACCOUNT_B_ID="<ACCOUNT_B_ID>"
export BUCKET_NAME="demo-internal-aa-2026"

The bucket policy grants each role the same actions used in its identity policy:

cat > bucket-policy.json <<EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowReadOnlyListBucket",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::$ACCOUNT_B_ID:role/RoleReadOnly"
      },
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::$BUCKET_NAME"
    },
    {
      "Sid": "AllowReadOnlyGetObject",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::$ACCOUNT_B_ID:role/RoleReadOnly"
      },
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::$BUCKET_NAME/*"
    },
    {
      "Sid": "AllowAdminFullBucketAccess",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::$ACCOUNT_B_ID:role/RoleAdmin"
      },
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::$BUCKET_NAME",
        "arn:aws:s3:::$BUCKET_NAME/*"
      ]
    },
    {
      "Sid": "AllowAdminWildcardNoBoundaryFullBucketAccess",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::$ACCOUNT_B_ID:role/RoleAdminWildcardNoBoundary"
      },
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::$BUCKET_NAME",
        "arn:aws:s3:::$BUCKET_NAME/*"
      ]
    },
    {
      "Sid": "AllowDiagnosticExplicitNoBoundaryBucketAccess",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::$ACCOUNT_B_ID:role/RoleDiagnosticExplicitNoBoundary"
      },
      "Action": [
        "s3:ListBucket",
        "s3:GetBucketPolicy"
      ],
      "Resource": "arn:aws:s3:::$BUCKET_NAME"
    },
    {
      "Sid": "AllowDiagnosticExplicitNoBoundaryObjectAccess",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::$ACCOUNT_B_ID:role/RoleDiagnosticExplicitNoBoundary"
      },
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:DeleteObject"
      ],
      "Resource": "arn:aws:s3:::$BUCKET_NAME/*"
    }
  ]
}
EOF

aws s3api put-bucket-policy \
  --bucket "$BUCKET_NAME" \
  --policy file://bucket-policy.json

Validation:

aws s3api get-bucket-policy \
  --bucket "$BUCKET_NAME" \
  --query Policy \
  --output text |
jq .

The real account also contained an earlier entry for RolePowerUser. I did not use it in the final comparison because the four roles above already covered the cases I needed to isolate.

Step 4: Create the SCP in AWS Organizations

From the management account, or another account with AWS Organizations permissions, define the variables:

export BUCKET_NAME="demo-internal-aa-2026" # Bucket name set at the beginning
export OU_ID="<OU_ID>"
export SCP_NAME="DenyDeleteObjectDemoBucket"

The SCP denies object deletion on the lab bucket:

cat > deny-delete-demo-bucket-scp.json <<EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyDeleteObjectOnDemoBucket",
      "Effect": "Deny",
      "Action": [
        "s3:DeleteObject",
        "s3:DeleteObjectVersion"
      ],
      "Resource": "arn:aws:s3:::$BUCKET_NAME/*"
    }
  ]
}
EOF

Create the SCP and attach it to the OU that contains both Account A and Account B:

POLICY_ID=$(aws organizations create-policy \
  --name "$SCP_NAME" \
  --description "Deny object deletion on demo S3 bucket for IAM Access Analyzer lab" \
  --type SERVICE_CONTROL_POLICY \
  --content file://deny-delete-demo-bucket-scp.json \
  --query "Policy.PolicySummary.Id" \
  --output text)

echo "$POLICY_ID"

aws organizations attach-policy \
  --policy-id "$POLICY_ID" \
  --target-id "$OU_ID"

To validate that it was attached:

aws organizations list-policies-for-target \
  --target-id "$OU_ID" \
  --filter SERVICE_CONTROL_POLICY \
  --output table

Step 4.1: Add an RCP for the bucket

After testing the SCP, I extended the exercise with a Resource Control Policy (RCP) to block s3:PutObject directly on the lab bucket.

The purpose of this phase was no longer only to observe a deny from the principal side, but also to compare what happens when the deny comes from the resource side.

The RCP was configured as follows:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyPutObjectOnLabBucket",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::demo-internal-aa-2026/*"
    }
  ]
}

An important detail: in an RCP, the correct element is Principal with an uppercase P, and the permitted value for this type of policy is "*".

Create the policy and attach it to the OU that contains both the bucket account and the role account:

export OU_ID="<OU_ID>"

cat > deny-putobject-rcp.json <<EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyPutObjectOnLabBucket",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::demo-internal-aa-2026/*"
    }
  ]
}
EOF

RCP_ID=$(aws organizations create-policy \
  --name "DenyPutObjectOnLabBucketRCP" \
  --description "RCP to deny PutObject on the lab bucket" \
  --type RESOURCE_CONTROL_POLICY \
  --content file://deny-putobject-rcp.json \
  --query "Policy.PolicySummary.Id" \
  --output text)

echo "$RCP_ID"

aws organizations attach-policy \
  --policy-id "$RCP_ID" \
  --target-id "$OU_ID"

To validate that it was attached:

aws organizations list-policies-for-target \
  --target-id "$OU_ID" \
  --filter RESOURCE_CONTROL_POLICY \
  --output table

At this point, the lab looked like this:

SCP → blocks DeleteObject and DeleteObjectVersion
RCP → blocks PutObject
Permissions boundary → limits the maximum permissions of RoleAdmin

This created a useful comparison because I was no longer testing a single organizational control layer, but several of them at the same time.

Step 5: Create the IAM Access Analyzer Internal Access analyzer

From the console:

IAM > Access Analyzer > Analyzer settings > Create analyzer

Configuration:

Analysis:      Resource analysis - Internal access
Zone of trust: Entire organization
Resource:      arn:aws:s3:::demo-internal-aa-2026

An important detail: for S3, the resource must be the bucket ARN.

Correct:

arn:aws:s3:::demo-internal-aa-2026

Object ARNs with prefixes or wildcards are not supported as monitored resources in Internal Access Analyzer. Only the bucket ARN without a path is supported.

After creating the analyzer, wait until the first findings appear. For the final comparison, allow enough time for reanalysis, as explained later in the article.

Before testing: a quick summary of what each layer does

If you read the previous post, this table provides a quick summary of the scope of each mechanism in this lab:

Layer	What it controls	Main scope	In this lab
IAM policy	What the user or role can attempt to do	Principal	Defines the base permissions of the four roles
Bucket policy	Which principals can access the bucket	Resource	Enables cross-account access from Account B
SCP	Maximum permissions available to principals in member accounts	Account / OU / organization	Blocks `DeleteObject` and `DeleteObjectVersion`
RCP	Maximum permissions available on resources in member accounts	Resource in member account / OU / organization	Blocks `PutObject` on the bucket
Permissions boundary	Maximum permissions an IAM principal can have	IAM principal	Limits `RoleAdmin`; does not allow `GetBucketPolicy`

A concise way to read it is:

IAM defines what the role attempts to do
The bucket policy opens the cross-account access path
The SCP limits permissions from the principal side
The RCP limits permissions from the resource side
The boundary limits the principal's maximum permissions

Step 6: Test access by assuming the roles

From CloudShell in Account B:

export ACCOUNT_B_ID="<ACCOUNT_B_ID>"
export BUCKET_NAME="demo-internal-aa-2026"
export PREFIX="aa-lab"

Define functions to manage credentials and assume roles more easily:

clear_role() {
  unset AWS_ACCESS_KEY_ID
  unset AWS_SECRET_ACCESS_KEY
  unset AWS_SESSION_TOKEN
  unset AWS_SECURITY_TOKEN
}

assume_role() {
  ROLE_NAME="$1"
  clear_role
  CREDS=$(aws sts assume-role \
    --role-arn "arn:aws:iam::$ACCOUNT_B_ID:role/$ROLE_NAME" \
    --role-session-name "lab-$ROLE_NAME" \
    --output json)
  export AWS_ACCESS_KEY_ID=$(echo "$CREDS" | jq -r '.Credentials.AccessKeyId')
  export AWS_SECRET_ACCESS_KEY=$(echo "$CREDS" | jq -r '.Credentials.SecretAccessKey')
  export AWS_SESSION_TOKEN=$(echo "$CREDS" | jq -r '.Credentials.SessionToken')
  echo "Assuming role: $ROLE_NAME"
  aws sts get-caller-identity
}

Test with `RoleReadOnly`

assume_role RoleReadOnly

aws s3 ls "s3://$BUCKET_NAME/$PREFIX/"

aws s3 cp "s3://$BUCKET_NAME/$PREFIX/seed.txt" readonly-seed.txt
cat readonly-seed.txt

echo "test readonly put" > readonly-put.txt
aws s3 cp readonly-put.txt "s3://$BUCKET_NAME/$PREFIX/readonly-put.txt"

Observed result: PutObject fails with AccessDenied because of the RCP.

aws s3 rm "s3://$BUCKET_NAME/$PREFIX/seed.txt"

Observed result: DeleteObject fails with AccessDenied because of the IAM identity-based policy.

Test with `RoleAdmin`

assume_role RoleAdmin

aws s3 ls "s3://$BUCKET_NAME/$PREFIX/"

aws s3 cp "s3://$BUCKET_NAME/$PREFIX/seed.txt" admin-seed.txt
cat admin-seed.txt

echo "test admin put" > admin-put.txt
aws s3 cp admin-put.txt "s3://$BUCKET_NAME/$PREFIX/admin-put.txt"

Observed result: PutObject fails with AccessDenied because of the RCP.

aws s3 rm "s3://$BUCKET_NAME/$PREFIX/seed.txt"

Observed result: DeleteObject fails with AccessDenied because of the SCP.

Specific test to validate the permissions boundary

To check how the boundary appeared in the denial message, I executed an action that:

RoleAdmin would otherwise have through s3:*
The bucket policy also allows
Was not being blocked by the SCP or the RCP
But the permissions boundary does not allow

The selected action was:

assume_role RoleAdmin
aws s3api get-bucket-policy --bucket "$BUCKET_NAME"

This produced the missing evidence: the AccessDenied message states that RoleAdmin is not authorized to perform s3:GetBucketPolicy because no permissions boundary allows that action.

The AccessDenied message explicitly stated that no permissions boundary allowed s3:GetBucketPolicy, confirming that the boundary participated in the evaluation.

Additional tests: explicit actions compared with `s3:*`

To better isolate the behavior of the finding, I added two roles without permissions boundaries:

RoleDiagnosticExplicitNoBoundary, with the actions declared individually.
RoleAdminWildcardNoBoundary, with s3:*.

Both roles had access granted by their identity policies and the bucket policy, and both were subject to the same SCP and RCP.

RoleDiagnosticExplicitNoBoundary was allowed to perform GetBucketPolicy, GetObject, PutObject, DeleteObject, and ListBucket. However, its finding showed only:

s3:GetBucketPolicy
s3:GetObject
s3:ListBucket

In other words, PutObject and DeleteObject did not appear, which matched what I expected after applying the RCP and the SCP.

By contrast, RoleAdminWildcardNoBoundary had s3:*, and its finding retained a broad list of actions, including:

s3:PutObject
s3:DeleteObject
s3:DeleteObjectVersion

This happened even though the same finding showed the RCP and SCP restrictions as APPLIED.

The screenshots show that the finding for RoleAdminWildcardNoBoundary retains PutObject, DeleteObject, and DeleteObjectVersion, even though the SCP and RCP restrictions appear as applied.

To validate the actual access, I assumed both roles and ran the four main operations.

In both cases:

ListBucket and GetObject were allowed.
PutObject returned AccessDenied because of an explicit deny in the RCP.
DeleteObject returned AccessDenied because of an explicit deny in the SCP.

Role	Permission declaration	Expected result	Observed finding	Runtime
`RoleDiagnosticExplicitNoBoundary`	Explicit actions	No Put or Delete	Does not show Put or Delete	List and Get allowed; Put denied by RCP and Delete denied by SCP
`RoleAdminWildcardNoBoundary`	`s3:*`	No Put, Delete, or DeleteObjectVersion	Retains those actions	List and Get allowed; Put denied by RCP and Delete denied by SCP

The comparison shows an observable difference between the two findings. It does not determine the internal cause of the behavior by itself, but it does make it possible to compare what the analyzer reported with the actual API results.

View the findings in IAM Access Analyzer

With the roles created and the analyzer active, the next step is to review what IAM Access Analyzer detected for the bucket.

In the IAM console, under Access Analyzer, you can see all active analyzers. In this lab, the relevant one is the internal access analyzer.

When you open the analyzer and select the bucket, a list of findings appears. An important detail is that you will not see only the lab roles. You may also see internal roles from the bucket owner's account, such as administrative roles, AWS IAM Identity Center (SSO) roles, or service roles.

If you expected to find only the four roles created for the lab, this is where you realize that another factor must be considered: the analyzer shows effective access to the resource, not only the principals you manually added to the lab's bucket policy.

This is one of the key points of the scenario: principals in the bucket owner's account do not need to be explicitly named in the bucket policy to have access. If a role or user in the owning account already has permissions through its own IAM identity policy, it can still access the bucket. AWS documents this behavior for S3 here: Granting access to an IAM principal in the same account does not require updating the bucket policy.

The bucket policy becomes necessary when you want to enable cross-account access, as is the case with the lab roles.

What the findings list shows

In the summary view, these are the most useful columns:

Field	Meaning
Finding ID	Unique identifier for the finding
Resource	The analyzed bucket
Resource owner account	The account that owns the bucket
Principal	The role or principal that has access
Condition	Whether access depends on a condition
Shared through	The layer that creates the access path, such as a bucket policy or bucket ACL
Access level	General action categories: Read, List, Write, Permissions, and Tagging
RCP restriction	Whether the analyzer considered a Resource Control Policy
SCP restriction	Whether the analyzer considered a Service Control Policy
Status	Whether the finding is active or archived

Two columns deserve special attention in this lab:

SCP restriction = Applied
RCP restriction = Applied

This does not necessarily mean that a specific action such as s3:DeleteObject or s3:PutObject disappeared from the list. It does mean that those layers were considered during the evaluation.

View the details of a finding

The summary list is useful, but the real value appears when you open the details of each finding.

For RoleReadOnly, the result is straightforward:

Principal: Account B / RoleReadOnly
Principal account: Account B
Shared through: Bucket policy
Access reported by the finding:
- Read → s3:GetObject
- List → s3:ListBucket

The finding does not show only broad categories. It directly shows the actions the analyzer is reporting for that principal on the bucket.

What this demonstrates about the SCP, RCP, and permissions boundary

This is where one of the most interesting parts of the exercise appeared.

At first, I only had RoleReadOnly and RoleAdmin, but I later added two roles to improve the comparison:

RoleDiagnosticExplicitNoBoundary, with the actions declared individually.
RoleAdminWildcardNoBoundary, with s3:* and no permissions boundary.

All four roles were subject to the same SCP and RCP, but their findings were not presented in exactly the same way.

Role	Configuration	Observed finding	Runtime result
`RoleReadOnly`	`GetObject` and `ListBucket`	Shows `GetObject` and `ListBucket`	Read allowed; write and delete denied
`RoleDiagnosticExplicitNoBoundary`	Get, Put, Delete, List, and GetBucketPolicy declared explicitly	Does not show `PutObject` or `DeleteObject`	List and Get allowed; Put denied by RCP and Delete denied by SCP
`RoleAdmin`	`s3:*` limited by a permissions boundary	Shows only `GetObject` and `ListBucket`	Put denied by RCP, Delete by SCP, and GetBucketPolicy by boundary
`RoleAdminWildcardNoBoundary`	`s3:*` without a permissions boundary	Retains `PutObject`, `DeleteObject`, and `DeleteObjectVersion`	List and Get allowed; Put denied by RCP and Delete denied by SCP

Using the four main lab operations as the reference point—ListBucket, GetObject, PutObject, and DeleteObject—the findings for the first three cases matched the action set I expected after considering the different policy layers.

The difference appeared with RoleAdminWildcardNoBoundary. Its finding continued to include actions that the runtime tests confirmed were denied:

PutObject returned AccessDenied because of an explicit deny in the RCP.
DeleteObject returned AccessDenied because of an explicit deny in the SCP.

At the same time, both restrictions appeared in the findings as:

resourceControlPolicyRestriction: APPLIED
serviceControlPolicyRestriction: APPLIED

For the complete test set, I waited at least 24 hours after making the changes before reviewing the findings again. I also used get-finding-v2 to confirm that the results had been reanalyzed.

This prevented me from comparing findings that might still have been waiting for an update.

This does not mean that the SCP or the RCP failed. The runtime tests show exactly the opposite: both policies blocked the operations.

What I can document is a difference between the actions reported by the finding and the actions the role could actually perform in this specific scenario.

My final interpretation of the lab is therefore:

The finding is very useful for identifying principals, access paths, and reported actions on the resource.
The SCP and RCP columns indicate whether those layers participated in the evaluation.
When you need to validate a specific API, a runtime test remains important evidence.
If the finding and runtime results do not match, review IAM, the bucket policy, the boundary, the SCP, and the RCP directly, and confirm that the analyzer had enough time to update before drawing a conclusion.

I am not attempting to determine the internal cause of this difference from the outside or to generalize the result to every service or configuration. The goal is to document the configuration and evidence in a reproducible way.

The official reference used to interpret the APPLIED fields is: InternalAccessDetails – AWS IAM Access Analyzer API

Why other roles appear in addition to the lab roles

The findings may also include internal roles such as federated administrators, Control Tower roles, and service roles from the account that owns the bucket.

This does not mean that the lab's bucket policy granted access to all of them.

It means that the bucket is also accessible to internal principals in the resource owner's account, and Access Analyzer displays them because its job is not to show only the cross-account access created for the exercise. It shows the total effective access within the analyzer's scope.

Put another way:

Account A owns the bucket.
Account B contains the four roles used in the lab.

The lab roles explain the cross-account scenario.

The other findings show intra-account access from roles that already exist in Account A and have permissions through other layers in the environment.

This is already easy to lose track of in a small lab. Now imagine the same problem in a real organization with tens or hundreds of accounts, thousands of roles, federated SSO roles, service roles, Control Tower roles, managed policies, inline policies, bucket policies, ACLs, SCPs, RCPs, permissions boundaries, and many resources beyond a single bucket. At that point, answering “who can actually access what?” stops being a manual policy review and becomes a problem of correlating multiple permission layers.

That is the core difficulty: effective access does not live in a single policy. It comes from the combination of identity policies, resource policies, intra-account permissions, cross-account permissions, and organizational restrictions. If you review only a bucket policy, you may think you understand access to the resource, while actually missing internal principals in the same account, inherited roles, service roles, or access paths that remain valid through other mechanisms. The more accounts, roles, and resources you add, the harder it becomes to distinguish between expected access, inherited access, indirect access, and access that represents real risk.

That is why tools such as IAM Access Analyzer become valuable at scale: not because they replace understanding IAM, but because they help reduce operational complexity when you are no longer looking at four lab roles, but at hundreds or thousands of identities with cross-account permissions over many resources.

What the Archive button does

Archiving a finding does not modify access or change any policies. It only changes how that result is managed inside the analyzer.

When you archive a finding:

It no longer appears among active findings.
It remains available as an archived finding.
You can use archive rules to automatically archive new findings that match defined criteria.
When creating a rule, you can choose to apply it only to new findings or also archive existing active findings.

If the access path disappears, the finding moves to Resolved. If the path changes significantly, Access Analyzer may resolve the previous finding and generate a new one.

Lab results

Role	ListBucket	GetObject	PutObject	DeleteObject
`RoleReadOnly`	✅ Allowed	✅ Allowed	❌ RCP	❌ IAM
`RoleAdmin`	✅ Allowed	✅ Allowed	❌ RCP	❌ SCP
`RoleDiagnosticExplicitNoBoundary`	✅ Allowed	✅ Allowed	❌ RCP	❌ SCP
`RoleAdminWildcardNoBoundary`	✅ Allowed	✅ Allowed	❌ RCP	❌ SCP

The table includes only API calls that were actually executed. The findings comparison is covered in the previous section.

What this lab demonstrates

For a cross-account action to work in this scenario, the following conditions must be met:

An identity policy on the role in Account B must allow the action.
A bucket policy in Account A must grant that action to the external role.
No explicit deny applicable to that action and resource can exist.
If the role has a permissions boundary, the action must be included within its maximum allowed permissions.

This does not mean that SCPs or RCPs cannot exist. Both exist in this lab, but they block specific operations: the SCP blocks DeleteObject and DeleteObjectVersion, while the RCP blocks PutObject. The remaining actions continue to be available according to the other applicable policies.

The first part of the lab demonstrates this with the SCP: the role has IAM permission, the bucket policy also grants it, but the organizational explicit deny wins.

The RCP extension reinforces the same idea from the resource side: even when an access path exists, an organizational control can still block the operation at runtime.

The GetBucketPolicy test adds a third important lesson: a permissions boundary can also act as a limiting layer and can be explicitly identified in an AccessDenied message.

The lab therefore demonstrates more than the deny itself. It also shows something more useful in production: you need to understand how to read the finding and interpret runtime errors without assuming that one is a perfect mirror of the other.

Before enabling it in production: pricing

This is something that very few tutorials mention, and it is worth understanding before enabling the feature in production.

IAM Access Analyzer Internal Access is not free for effective-permissions analysis.

Some practical considerations:

Do not enable it for every resource by default. Start with buckets that contain sensitive or regulated data.
Use tags to identify critical resources—for example, DataClassification: Confidential—and limit the analyzer's scope to those resources.
It makes the most sense for specific high-risk resources: buckets containing PCI data, security log repositories, cross-account shared buckets, DynamoDB tables, RDS database snapshots, and RDS cluster snapshots.
For the remaining resources, IAM Access Advisor can help prioritize periodic manual reviews and reduce the number of resources for which Internal Access Analyzer needs to be enabled.

The concrete recommendation is to first define what qualifies as a critical resource in your organization, apply data-classification tags, and use Access Analyzer Internal Access only for that subset—not for everything.

Practical note: if you were thinking of enabling it briefly and then deleting it, be careful. In my case, the charge appeared on the same day I enabled it and reflected the full monthly unit for the monitored resource. That alone is a reason to plan the experiment carefully before enabling it.

I would add another recommendation based on what happened in this lab: before enabling it for critical resources, understand exactly which questions you want it to answer.

If your question is “who can reach this resource, and through which access path?”, the analyzer provides substantial value.
If your question is “was this specific API effectively blocked by this organizational or identity control layer?”, you will probably also want a runtime validation to avoid surprises when interpreting the finding.

Red Team perspective

Access Analyzer is not useful only for defensive teams, but this section requires some context.

A user or role needs permissions to query the analyzer and its findings. In addition, calls made through the console or the IAM Access Analyzer APIs are recorded in AWS CloudTrail.

It is therefore incorrect to assume that any compromised role in a member account can query the organizational analyzer, or that using it would be invisible.

In an authorized internal Red Team engagement, an identity that already has access to the analyzer could use the findings to:

Review access paths without directly calling the target resource.
Prioritize relevant cross-account relationships.
Compare reported access with executable access.
Evaluate the impact of SCPs, RCPs, and permissions boundaries.

What Access Analyzer shows—and what it does not

To make it clear:

✅ Which identities have access to a specific resource

✅ Which layers participated in the evaluation, including IAM, resource policies, SCPs, and RCPs

✅ Exportable findings for audit evidence

✅ Centralized organization-wide visibility from the account that manages the analyzer

The lab also made the following points much clearer to me:

⚠️ I would not always use it as the only evidence that a specific API has disappeared from effective access simply because an SCP or RCP blocks it at runtime

⚠️ The AccessDenied message may not always show every layer that could be contributing to the denial

⚠️ For specific denials caused by an organizational control or a permissions boundary, it is useful to complement the analysis with a controlled runtime test

Conclusion

The question that started this series was:

Who can actually access your AWS resources?

After this lab, the practical answer remains that you cannot determine it by reviewing a single policy.

IAM Access Analyzer Internal Access provides value by identifying principals, actions, and access paths for critical resources. It also centralizes results at the organization level and makes the findings available through an API.

The lab also produced a specific observation. Using the four main operations as the reference point, the finding matched the expected action set in three controlled cases. For the role with s3:* and no permissions boundary, the finding continued to show PutObject, DeleteObject, and DeleteObjectVersion, even though the restrictions appeared as APPLIED. Runtime tests confirmed that the RCP denied PutObject and the SCP denied DeleteObject.

I will not speculate about the exact cause. What I can do is document the configuration, findings, and runtime tests so that the result can be reproduced.

Because Internal Access Analyzer is a paid capability, I also recommend thinking carefully about the questions you want to answer before enabling it. If you need to identify who can access a critical bucket and through which path, it can be especially useful. But if you only need to validate a specific API, a policy review and a controlled runtime test may be enough.

The cost is calculated per monitored resource, per analyzer, and per Region. Enabling it without first defining the scope can therefore result in a larger-than-expected charge. In production, I would start with genuinely critical resources, such as buckets containing sensitive data, security logs, or resources shared across accounts, and expand the scope only when there is a clear need.

For me, the most useful interpretation of the exercise is:

Use the analyzer to gain visibility.
Understand what each field means.
Validate critical APIs when you need a specific answer.
Define the scope before enabling it.
Avoid interpreting a single screen without reviewing the other permission layers.

💡 Have you found unexpected access while analyzing your resources? That is often the moment when tools like this go from “interesting” to “necessary.”

🛡️ AWS IAM Access Analyzer — Parte 3/4

Terry Quispe Paniagua — Sun, 26 Jul 2026 16:16:17 +0000

Demo real: permisos efectivos, SCPs, RCPs y una comparación que no salió como esperaba

En la parte anterior expliqué el problema: en entornos con múltiples cuentas, roles y políticas en capas, saber quién tiene acceso real a un recurso no es algo que puedas responder abriendo la consola y revisando una IAM policy. Si todavía no leíste la primera parte, te recomiendo empezar por ahí.

En este post voy directo al laboratorio. Configuré un escenario con dos cuentas dentro de la misma AWS Organization, un bucket S3 en una cuenta, varios roles IAM en otra y distintas capas de control sobre el acceso: IAM, bucket policy, SCP, RCP y un permissions boundary sobre el rol administrador.

El objetivo no fue solo comprobar si una acción funcionaba o no, sino comparar qué estaba configurado, qué reportaba IAM Access Analyzer Internal Access y qué ocurría realmente al ejecutar las APIs.

⚠️ Nota sobre costos antes de empezar

IAM Access Analyzer External Access no tiene costo adicional, pero Internal Access Analyzer sí es una capacidad pagada. AWS cobra $9.00 USD por recurso monitoreado, por analizador y por región, al mes. En este lab solo se monitorea un bucket S3, así que el costo estimado fue $9.00 USD/mes mientras el analizador estuvo activo. Si lo habilitas sobre múltiples recursos en producción, el costo escala linealmente: 10 recursos = $90 USD/mes, 38 recursos en 5 cuentas = $342 USD/mes (ejemplo publicado en la página oficial de precios de AWS).

Lab: validando acceso cross-account dentro de la misma AWS Organization con IAM Access Analyzer Internal Access

En este laboratorio validé cómo IAM Access Analyzer Internal Access representa el acceso de roles ubicados en una cuenta hacia un bucket S3 ubicado en otra cuenta de la misma organización.

El escenario empezó con dos roles:

RoleReadOnly
RoleAdmin

Después añadí dos roles de control para comparar si la forma de declarar las acciones influía en el resultado:

RoleDiagnosticExplicitNoBoundary
RoleAdminWildcardNoBoundary

También añadí tres controles:

SCP para bloquear s3:DeleteObject y s3:DeleteObjectVersion
RCP para bloquear s3:PutObject
Permissions boundary sobre RoleAdmin

Arquitectura

AWS Organization
└── OU del laboratorio
    ├── Cuenta A — propietaria del recurso
    │   └── Bucket S3: demo-internal-aa-2026
    │
    └── Cuenta B — propietaria de los principals
        ├── RoleReadOnly
        ├── RoleAdmin
        ├── RoleDiagnosticExplicitNoBoundary
        └── RoleAdminWildcardNoBoundary

La Cuenta A contiene el bucket S3 y la Cuenta B contiene los roles que intentarán acceder a él. Ambas cuentas están dentro de la misma OU, y tanto la SCP como la RCP se adjuntaron a esa OU. La SCP limita las acciones disponibles para los principals de las cuentas que contiene, mientras que la RCP limita el acceso sobre sus recursos; en este lab, el ARN definido en la RCP restringe el deny al bucket de la Cuenta A. El permissions boundary se adjunta directamente a RoleAdmin.

La imagen anterior corresponde a la primera fase del laboratorio, cuando todavía trabajaba únicamente con RoleReadOnly y RoleAdmin. Los otros dos roles se añadieron después para controlar mejor la comparación.

Objetivo

El laboratorio comprueba siete cosas:

Qué roles dentro de la organización aparecen con acceso al bucket.
Qué acciones reporta el finding para cada rol.
Cómo una SCP bloquea una acción aunque IAM y la bucket policy la permitan.
Cómo una RCP bloquea una acción desde el lado del recurso.
Cómo un permissions boundary limita el máximo permiso de un rol.
Qué cambia al declarar acciones explícitas frente a utilizar s3:*.
Si el resultado del finding coincide con la ejecución real de las APIs.

Rol	Permiso configurado	Boundary
RoleReadOnly	ListBucket y GetObject	No
RoleAdmin	s3:*	Sí: limita a ListBucket, GetObject, PutObject y DeleteObject
RoleAdminWildcardNoBoundary	s3:*	No
RoleDiagnosticExplicitNoBoundary	ListBucket, GetBucketPolicy, GetObject, PutObject y DeleteObject	No

La SCP bloquea s3:DeleteObject y s3:DeleteObjectVersion.

La RCP bloquea s3:PutObject sobre el bucket del lab.

Paso 1: Crear los roles en la Cuenta B

Desde CloudShell en la Cuenta B, se definen las variables de entorno:

export ACCOUNT_B_ID="<ACCOUNT_B_ID>"
export BUCKET_NAME="demo-internal-aa-2026" # ejemplo

Se valida la identidad actual:

aws sts get-caller-identity

Luego se crea la trust policy para permitir asumir los roles desde la misma Cuenta B:

cat > trust-account-b.json <<EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowAssumeRoleFromAccountB",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::$ACCOUNT_B_ID:root"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
EOF

Se crean los cuatro roles:

for ROLE in \
  RoleReadOnly \
  RoleAdmin \
  RoleDiagnosticExplicitNoBoundary \
  RoleAdminWildcardNoBoundary
do
  aws iam create-role \
    --role-name "$ROLE" \
    --assume-role-policy-document file://trust-account-b.json
done

Paso 2: Asignar permisos IAM a los roles

RoleReadOnly — solo puede listar y leer:

cat > role-readonly-policy.json <<EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ListBucket",
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::$BUCKET_NAME"
    },
    {
      "Sid": "ReadObjects",
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::$BUCKET_NAME/*"
    }
  ]
}
EOF

aws iam put-role-policy \
  --role-name RoleReadOnly \
  --policy-name DemoBucketReadOnlyAccess \
  --policy-document file://role-readonly-policy.json

RoleAdmin — Permite s3:* sobre el bucket y sus objetos:

cat > role-admin-policy.json <<EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AdminBucketAccess",
      "Effect": "Allow",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::$BUCKET_NAME",
        "arn:aws:s3:::$BUCKET_NAME/*"
      ]
    }
  ]
}
EOF

aws iam put-role-policy \
  --role-name RoleAdmin \
  --policy-name DemoBucketAdminAccess \
  --policy-document file://role-admin-policy.json

RoleDiagnosticExplicitNoBoundary

Este rol declara de manera explícita las acciones que me interesaba comparar:

cat > role-diagnostic-explicit-policy.json <<EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DiagnosticBucketActions",
      "Effect": "Allow",
      "Action": [
        "s3:ListBucket",
        "s3:GetBucketPolicy"
      ],
      "Resource": "arn:aws:s3:::$BUCKET_NAME"
    },
    {
      "Sid": "DiagnosticObjectActions",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:DeleteObject"
      ],
      "Resource": "arn:aws:s3:::$BUCKET_NAME/*"
    }
  ]
}
EOF

aws iam put-role-policy \
  --role-name RoleDiagnosticExplicitNoBoundary \
  --policy-name DiagnosticExplicitNoBoundaryAccess \
  --policy-document file://role-diagnostic-explicit-policy.json

RoleAdminWildcardNoBoundary

Este rol mantiene el wildcard y no tiene boundary:

cat > role-admin-wildcard-policy.json <<EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AdminWildcardBucketAccess",
      "Effect": "Allow",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::$BUCKET_NAME",
        "arn:aws:s3:::$BUCKET_NAME/*"
      ]
    }
  ]
}
EOF

aws iam put-role-policy \
  --role-name RoleAdminWildcardNoBoundary \
  --policy-name AdminWildcardNoBoundaryAccess \
  --policy-document file://role-admin-wildcard-policy.json

Paso 2.1: Añadir permissions boundary a RoleAdmin

Además de su inline policy con s3:*, RoleAdmin tiene un permissions boundary.

La idea no fue reemplazar la SCP ni la RCP. Quería añadir una capa que materializara un conjunto explícito de acciones máximas para ese rol.

El boundary permite:

s3:ListBucket
s3:GetObject
s3:PutObject
s3:DeleteObject

No permite, por ejemplo:

s3:GetBucketPolicy
s3:GetBucketAcl
s3:GetBucketVersioning

cat > role-admin-boundary.json <<EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ListBucket",
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::$BUCKET_NAME"
    },
    {
      "Sid": "PowerUserObjects",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:DeleteObject"
      ],
      "Resource": "arn:aws:s3:::$BUCKET_NAME/*"
    }
  ]
}
EOF

aws iam create-policy \
  --policy-name boundary-adminuser \
  --policy-document file://role-admin-boundary.json

aws iam put-role-permissions-boundary \
  --role-name RoleAdmin \
  --permissions-boundary \
    "arn:aws:iam::$ACCOUNT_B_ID:policy/boundary-adminuser"

Validación:

aws iam get-role \
  --role-name RoleAdmin \
  --query 'Role.PermissionsBoundary' \
  --output json

Paso 3: Configurar la bucket policy en la Cuenta A

Desde CloudShell en la Cuenta A:

export ACCOUNT_B_ID="<ACCOUNT_B_ID>"
export BUCKET_NAME="demo-internal-aa-2026"

La bucket policy concede a cada rol las mismas acciones utilizadas en su identity policy:

cat > bucket-policy.json <<EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowReadOnlyListBucket",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::$ACCOUNT_B_ID:role/RoleReadOnly"
      },
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::$BUCKET_NAME"
    },
    {
      "Sid": "AllowReadOnlyGetObject",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::$ACCOUNT_B_ID:role/RoleReadOnly"
      },
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::$BUCKET_NAME/*"
    },
    {
      "Sid": "AllowAdminFullBucketAccess",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::$ACCOUNT_B_ID:role/RoleAdmin"
      },
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::$BUCKET_NAME",
        "arn:aws:s3:::$BUCKET_NAME/*"
      ]
    },
    {
      "Sid": "AllowAdminWildcardNoBoundaryFullBucketAccess",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::$ACCOUNT_B_ID:role/RoleAdminWildcardNoBoundary"
      },
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::$BUCKET_NAME",
        "arn:aws:s3:::$BUCKET_NAME/*"
      ]
    },
    {
      "Sid": "AllowDiagnosticExplicitNoBoundaryBucketAccess",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::$ACCOUNT_B_ID:role/RoleDiagnosticExplicitNoBoundary"
      },
      "Action": [
        "s3:ListBucket",
        "s3:GetBucketPolicy"
      ],
      "Resource": "arn:aws:s3:::$BUCKET_NAME"
    },
    {
      "Sid": "AllowDiagnosticExplicitNoBoundaryObjectAccess",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::$ACCOUNT_B_ID:role/RoleDiagnosticExplicitNoBoundary"
      },
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:DeleteObject"
      ],
      "Resource": "arn:aws:s3:::$BUCKET_NAME/*"
    }
  ]
}
EOF

aws s3api put-bucket-policy \
  --bucket "$BUCKET_NAME" \
  --policy file://bucket-policy.json

Validación:

aws s3api get-bucket-policy \
  --bucket "$BUCKET_NAME" \
  --query Policy \
  --output text |
jq .

En la cuenta real también quedó una entrada anterior para RolePowerUser. No la utilicé en la comparación final porque los cuatro roles anteriores ya cubrían los casos que necesitaba aislar.

Paso 4: Crear la SCP en AWS Organizations

Desde la management account (o una con permisos de Organizations), se crean las variables:

export BUCKET_NAME="demo-internal-aa-2026" # Nombre del bucket seteado al inicio
export OU_ID="<OU_ID>"
export SCP_NAME="DenyDeleteObjectDemoBucket"

La SCP niega el borrado de objetos sobre el bucket del lab:

cat > deny-delete-demo-bucket-scp.json <<EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyDeleteObjectOnDemoBucket",
      "Effect": "Deny",
      "Action": [
        "s3:DeleteObject",
        "s3:DeleteObjectVersion"
      ],
      "Resource": "arn:aws:s3:::$BUCKET_NAME/*"
    }
  ]
}
EOF

Se crea la SCP y se adjunta a la OU, donde viven tanto la Cuenta A como la Cuenta B:

POLICY_ID=$(aws organizations create-policy \
  --name "$SCP_NAME" \
  --description "Deny object deletion on demo S3 bucket for IAM Access Analyzer lab" \
  --type SERVICE_CONTROL_POLICY \
  --content file://deny-delete-demo-bucket-scp.json \
  --query "Policy.PolicySummary.Id" \
  --output text)

echo "$POLICY_ID"

aws organizations attach-policy \
  --policy-id "$POLICY_ID" \
  --target-id "$OU_ID"

Para validar que quedó adjunta:

aws organizations list-policies-for-target \
  --target-id "$OU_ID" \
  --filter SERVICE_CONTROL_POLICY \
  --output table

Paso 4.1: Añadir una RCP sobre el bucket

Después de probar la SCP, amplié el ejercicio con una Resource Control Policy (RCP) para bloquear s3:PutObject directamente sobre el bucket del lab.

La intención de esta fase ya no era solo ver un deny desde el lado del principal, sino comparar qué pasa cuando el deny viene del lado del recurso.

La RCP quedó así:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyPutObjectOnLabBucket",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::demo-internal-aa-2026/*"
    }
  ]
}

Un detalle importante: en RCP el elemento correcto es Principal con mayúscula, y el valor permitido para este tipo de policy es "*".

Se creó la policy y se adjuntó a la OU, donde viven tanto la cuenta del bucket como la cuenta de los roles:

export OU_ID="<OU_ID>"

cat > deny-putobject-rcp.json <<EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyPutObjectOnLabBucket",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::demo-internal-aa-2026/*"
    }
  ]
}
EOF

RCP_ID=$(aws organizations create-policy \
  --name "DenyPutObjectOnLabBucketRCP" \
  --description "RCP to deny PutObject on the lab bucket" \
  --type RESOURCE_CONTROL_POLICY \
  --content file://deny-putobject-rcp.json \
  --query "Policy.PolicySummary.Id" \
  --output text)

echo "$RCP_ID"

aws organizations attach-policy \
  --policy-id "$RCP_ID" \
  --target-id "$OU_ID"

Para validar que quedó adjunta:

aws organizations list-policies-for-target \
  --target-id "$OU_ID" \
  --filter RESOURCE_CONTROL_POLICY \
  --output table

Con esto, el laboratorio quedó así:

SCP → bloquea DeleteObject y DeleteObjectVersion
RCP → bloquea PutObject
Permissions boundary → limita el máximo permiso de RoleAdmin

Y eso dejó una comparación bastante útil porque ya no estaba probando una sola capa organizacional, sino varias a la vez.

Paso 5: Crear el IAM Access Analyzer Internal Access

Desde la consola:

IAM > Access Analyzer > Analyzer settings > Create analyzer

Configuración:

Analysis:     Resource analysis - Internal access
Zone of trust: Entire organization
Recurso:      arn:aws:s3:::demo-internal-aa-2026

Un detalle importante: para S3, el recurso debe ser el ARN del bucket.

Correcto:

arn:aws:s3:::demo-internal-aa-2026

Los object ARNs con prefijos o wildcards no están soportados como recurso monitoreado en Internal Access Analyzer. Solo el ARN del bucket sin ruta.

Después de crear el analizador, esperar hasta que aparezcan los primeros findings. Para realizar la comparación final conviene dejar tiempo suficiente para el reanálisis, como se explica más adelante.

Antes de las pruebas: resumen rápido de qué hace cada capa

Si vienes del post anterior, esta tabla resume rápido el alcance de cada mecanismo en este lab:

Capa	Qué controla	Alcance principal	En este lab
IAM policy	Lo que el usuario o rol puede intentar hacer	Principal	Define los permisos base de los cuatro roles
Bucket policy	Qué principals pueden acceder al bucket	Recurso	Habilita el acceso cross-account desde la Cuenta B
SCP	Máximo permiso disponible para principals en cuentas miembro	Cuenta / OU / organización	Bloquea `DeleteObject` y `DeleteObjectVersion`
RCP	Máximo permiso disponible sobre recursos en cuentas miembro	Recurso en cuenta miembro / OU / organización	Bloquea `PutObject` sobre el bucket
Permissions boundary	Máximo permiso que puede tener un principal IAM	Principal IAM	Limita a `RoleAdmin`; no permite `GetBucketPolicy`

La forma corta de leerlo es esta:

IAM dice qué intenta hacer el rol
bucket policy abre el camino cross-account
SCP limita desde el lado del principal
RCP limita desde el lado del recurso
boundary limita el máximo permiso del principal

Paso 6: Probar acceso asumiendo los roles

Desde CloudShell en la Cuenta B:

export ACCOUNT_B_ID="<ACCOUNT_B_ID>"
export BUCKET_NAME="demo-internal-aa-2026"
export PREFIX="aa-lab"

Se definen funciones para manejar las credenciales y asumir roles fácilmente:

clear_role() {
  unset AWS_ACCESS_KEY_ID
  unset AWS_SECRET_ACCESS_KEY
  unset AWS_SESSION_TOKEN
  unset AWS_SECURITY_TOKEN
}

assume_role() {
  ROLE_NAME="$1"
  clear_role
  CREDS=$(aws sts assume-role \
    --role-arn "arn:aws:iam::$ACCOUNT_B_ID:role/$ROLE_NAME" \
    --role-session-name "lab-$ROLE_NAME" \
    --output json)
  export AWS_ACCESS_KEY_ID=$(echo "$CREDS" | jq -r '.Credentials.AccessKeyId')
  export AWS_SECRET_ACCESS_KEY=$(echo "$CREDS" | jq -r '.Credentials.SecretAccessKey')
  export AWS_SESSION_TOKEN=$(echo "$CREDS" | jq -r '.Credentials.SessionToken')
  echo "Asumiendo rol: $ROLE_NAME"
  aws sts get-caller-identity
}

Prueba con `RoleReadOnly`

assume_role RoleReadOnly

aws s3 ls "s3://$BUCKET_NAME/$PREFIX/"

aws s3 cp "s3://$BUCKET_NAME/$PREFIX/seed.txt" readonly-seed.txt
cat readonly-seed.txt

echo "test readonly put" > readonly-put.txt
aws s3 cp readonly-put.txt "s3://$BUCKET_NAME/$PREFIX/readonly-put.txt"

Resultado observado: PutObject falla con AccessDenied por RCP.

aws s3 rm "s3://$BUCKET_NAME/$PREFIX/seed.txt"

Resultado observado: DeleteObject falla con AccessDenied por IAM / identity-based policy.

Prueba con `RoleAdmin`

assume_role RoleAdmin

aws s3 ls "s3://$BUCKET_NAME/$PREFIX/"

aws s3 cp "s3://$BUCKET_NAME/$PREFIX/seed.txt" admin-seed.txt
cat admin-seed.txt

echo "test admin put" > admin-put.txt
aws s3 cp admin-put.txt "s3://$BUCKET_NAME/$PREFIX/admin-put.txt"

Resultado observado: PutObject falla con AccessDenied por RCP.

aws s3 rm "s3://$BUCKET_NAME/$PREFIX/seed.txt"

Resultado observado: DeleteObject falla con AccessDenied por SCP.

Prueba específica para validar el permissions boundary

Para comprobar cómo aparecía el boundary en el mensaje de denegación, ejecuté una acción que:

RoleAdmin sí tendría por s3:*
la bucket policy también permite
no estaba siendo bloqueada por SCP ni por RCP
pero el permissions boundary no permite

La acción elegida fue:

assume_role RoleAdmin
aws s3api get-bucket-policy --bucket "$BUCKET_NAME"

Y ahí sí apareció la evidencia que faltaba: el AccessDenied indica que RoleAdmin no está autorizado para **s3:GetBucketPolicy** porque ningún permissions boundary permite esa acción.

El mensaje de AccessDenied señaló expresamente que ningún permissions boundary permitía s3:GetBucketPolicy, por lo que confirmó que el boundary participó en la evaluación.

Pruebas adicionales: acciones explícitas frente a `s3:*`

Para aislar mejor el comportamiento del finding, añadí dos roles sin permissions boundary:

RoleDiagnosticExplicitNoBoundary, con las acciones declaradas individualmente.
RoleAdminWildcardNoBoundary, con s3:*.

Ambos tenían acceso concedido tanto por su identity policy como por la bucket policy, y estaban sujetos a la misma SCP y RCP.

RoleDiagnosticExplicitNoBoundary tenía permitidos GetBucketPolicy, GetObject, PutObject, DeleteObject y ListBucket. Sin embargo, su finding mostró únicamente:

s3:GetBucketPolicy
s3:GetObject
s3:ListBucket

Es decir, PutObject y DeleteObject no aparecieron, tal como esperaba después de aplicar la RCP y la SCP.

En cambio, RoleAdminWildcardNoBoundary tenía s3:* y su finding mantuvo una lista amplia de acciones, incluyendo:

s3:PutObject
s3:DeleteObject
s3:DeleteObjectVersion

Esto ocurrió aunque el mismo finding mostraba las restricciones RCP y SCP como APPLIED.

En la captura se observa que el finding de RoleAdminWildcardNoBoundary conserva PutObject, DeleteObject y DeleteObjectVersion, aunque las restricciones SCP y RCP aparecen como aplicadas.

Para comprobar el acceso real, asumí ambos roles y ejecuté las cuatro operaciones principales.

En los dos casos:

ListBucket y GetObject fueron permitidos.
PutObject devolvió AccessDenied por un explicit deny de la RCP.
DeleteObject devolvió AccessDenied por un explicit deny de la SCP.

Rol	Forma de declarar permisos	Resultado esperado	Finding observado	Runtime
`RoleDiagnosticExplicitNoBoundary`	Acciones explícitas	Sin Put ni Delete	No muestra Put ni Delete	List y Get permitidos; Put denegado por RCP y Delete por SCP
`RoleAdminWildcardNoBoundary`	`s3:*`	Sin Put, Delete ni DeleteObjectVersion	Conserva esas acciones	List y Get permitidos; Put denegado por RCP y Delete por SCP

La comparación muestra una diferencia observable entre ambos findings. No determina por sí sola la causa interna del comportamiento, pero sí permite contrastar lo reportado por el analyzer con el resultado real de las APIs.

Ver los findings en IAM Access Analyzer

Con los roles ya creados y el analizador activo, el siguiente paso es revisar qué detectó IAM Access Analyzer sobre el bucket.

En la consola de IAM, dentro de Access Analyzer, puedes ver todos los analizadores activos. En este lab, el que interesa es el de internal access.

Al entrar al analizador y seleccionar el bucket, aparece una lista de findings. Y aquí viene un detalle importante: no vas a ver solo los roles del laboratorio. También pueden aparecer roles internos de la misma cuenta dueña del bucket, como roles administrativos, roles de AWS IAM Identity Center (SSO) o service roles.

Si esperabas encontrar únicamente los cuatro roles creados para el laboratorio, aquí es donde te das cuenta de que olvidaste considerar algo más: el analizador muestra acceso efectivo al recurso, no solo lo que agregaste manualmente en la bucket policy del lab.

Y acá está una de las claves del escenario: los principals de la misma cuenta del bucket no necesitan estar expresamente nombrados en la bucket policy para tener acceso. Si un rol o usuario de la cuenta propietaria ya tiene permisos por su propia IAM identity policy, puede acceder igual. AWS lo documenta de forma explícita para S3 aquí: Granting access to an IAM principal in the same account does not require updating the bucket policy.

La bucket policy se vuelve realmente obligatoria cuando quieres habilitar acceso cross-account, como sí pasa con los roles del laboratorio.

Qué muestra la lista de findings

En la vista resumida, estas son las columnas más útiles:

Campo	Qué significa
ID de resultado	Identificador único del finding
Recurso	El bucket analizado
Cuenta del propietario del recurso	La cuenta dueña del bucket
Entidad principal	El rol o principal que tiene acceso
Condición	Si el acceso depende de alguna condición
Compartido a través de	Qué capa origina el acceso, por ejemplo bucket policy o bucket ACL
Nivel de acceso	Categorías generales de acciones: Read, List, Write, Permissions, Tagging
Restricción RCP	Si el analizador consideró una Resource Control Policy
Restricción SCP	Si el analizador consideró una Service Control Policy
Estado	Si el finding sigue activo o fue archivado

Dos columnas valen especial atención en este lab:

Restricción SCP = Aplicado
Restricción RCP = Aplicado

Eso no significa por sí solo que una acción específica como s3:DeleteObject o s3:PutObject haya desaparecido de la lista. Lo que sí significa es que esas capas fueron consideradas en la evaluación.

Ver el detalle de un finding

La lista resumida ayuda, pero el valor real aparece cuando entras al detalle de cada finding.

En el caso de RoleReadOnly, el resultado es bastante limpio:

Principal: Account B / RoleReadOnly
Cuenta del principal: Account B
Compartido a través de: Política del bucket
Acceso reportado por el finding:
- Read → s3:GetObject
- List → s3:ListBucket

Ese finding ya no muestra solo categorías amplias. Muestra directamente las acciones que el analizador está reportando para ese principal sobre el bucket.

Qué demuestra esto sobre la SCP, la RCP y el permissions boundary

Acá apareció una de las partes más interesantes del ejercicio.

Al comienzo solo tenía RoleReadOnly y RoleAdmin, pero después añadí dos roles para comparar mejor el resultado:

RoleDiagnosticExplicitNoBoundary, con las acciones declaradas individualmente.
RoleAdminWildcardNoBoundary, con s3:* y sin permissions boundary.

Los cuatro roles estaban sujetos a la misma SCP y RCP, pero los findings no se presentaron exactamente igual.

Rol	Configuración	Finding observado	Resultado runtime
`RoleReadOnly`	`GetObject` y `ListBucket`	Muestra `GetObject` y `ListBucket`	Lectura permitida; escritura y borrado denegados
`RoleDiagnosticExplicitNoBoundary`	Get, Put, Delete, List y GetBucketPolicy declarados explícitamente	No muestra `PutObject` ni `DeleteObject`	List y Get permitidos; Put denegado por RCP y Delete por SCP
`RoleAdmin`	`s3:*` limitado por un permissions boundary	Muestra únicamente `GetObject` y `ListBucket`	Put denegado por RCP, Delete por SCP y GetBucketPolicy por boundary
`RoleAdminWildcardNoBoundary`	`s3:*` sin permissions boundary	Mantiene `PutObject`, `DeleteObject` y `DeleteObjectVersion`	List y Get permitidos; Put denegado por RCP y Delete por SCP

Tomando como referencia las cuatro operaciones principales del laboratorio (ListBucket, GetObject, PutObject y DeleteObject), en los tres primeros casos el finding coincidió con el conjunto de acciones que esperaba después de considerar las distintas capas.

La diferencia apareció con RoleAdminWildcardNoBoundary. Su finding seguía incluyendo acciones que las pruebas runtime confirmaron como denegadas:

PutObject devolvió AccessDenied por un explicit deny de la RCP.
DeleteObject devolvió AccessDenied por un explicit deny de la SCP.

Además, en los findings las dos restricciones aparecían como:

resourceControlPolicyRestriction: APPLIED
serviceControlPolicyRestriction: APPLIED

Para todo el set de pruebas, después de completar los cambios esperé al menos 24 horas antes de volver a revisar los findings. También confirmé mediante get-finding-v2 que los resultados habían sido reanalizados.

De esta manera evité comparar findings que todavía pudieran estar pendientes de actualización.

Esto no significa que la SCP o la RCP hayan fallado. Las pruebas runtime muestran precisamente lo contrario: ambas políticas bloquearon las operaciones.

Lo que sí puedo documentar es una diferencia entre las acciones reportadas por el finding y las acciones que el rol pudo ejecutar realmente en este escenario específico.

Por eso, mi lectura final del laboratorio es esta:

El finding es muy útil para identificar principals, rutas de acceso y acciones reportadas sobre el recurso.
Las columnas SCP y RCP permiten saber si esas capas participaron en la evaluación.
Cuando necesitas validar una API concreta, la prueba runtime sigue siendo una evidencia importante.
Si el finding y runtime no coinciden, conviene revisar directamente IAM, bucket policy, boundary, SCP, RCP y confirmar que el analyzer tuvo tiempo suficiente para actualizarse antes de sacar una conclusión.

No intento determinar desde fuera cuál es la causa interna de esta diferencia ni generalizar el resultado a todos los servicios o configuraciones. El objetivo es dejar la configuración y la evidencia del laboratorio de forma reproducible.

La referencia oficial utilizada para interpretar los campos APPLIED es: InternalAccessDetails – AWS IAM Access Analyzer API

Por qué aparecen otros roles aparte de los del lab

También aparecen findings para roles internos como administradores federados, roles de Control Tower y service roles de la propia cuenta propietaria del bucket.

Eso no significa que la bucket policy del lab les haya dado acceso a todos ellos.

Lo que significa es que el bucket también es accesible por principals internos de la misma cuenta propietaria del recurso, y Access Analyzer los muestra porque su trabajo no es enseñarte solo el acceso cross-account del ejercicio, sino el acceso efectivo total dentro del alcance del analizador.

Dicho de otra forma:

Account A es la cuenta dueña del bucket.
Account B es la cuenta donde viven los cuatro roles utilizados en el laboratorio.

Los roles del lab explican el escenario cross-account.

Los otros findings muestran acceso intra-account de roles que ya existen en Account A y que tienen permisos por otras capas del entorno.

En un laboratorio pequeño esto ya se vuelve fácil de perder de vista. Ahora imagina el mismo problema en una organización real con decenas o cientos de cuentas, miles de roles, roles federados de SSO, service roles, roles de Control Tower, políticas administradas, inline policies, bucket policies, ACLs, SCPs, RCPs, permissions boundaries y además múltiples recursos aparte de un solo bucket. En ese punto, responder “quién puede acceder realmente a qué” deja de ser una revisión manual y pasa a ser un problema de correlación entre varias capas de permisos.

Y esa es precisamente la complicación: el acceso efectivo no vive en una sola policy. Sale de la combinación de identity policies, resource policies, permisos intra-account, permisos cross-account y restricciones organizacionales. Si revisas solo una bucket policy, puedes pensar que entiendes el acceso del recurso, pero en realidad te puedes estar perdiendo principals internos de la misma cuenta, roles heredados del entorno, service roles o accesos que siguen siendo válidos por otras rutas. Mientras más cuentas, roles y recursos agregas, más difícil se vuelve distinguir entre acceso esperado, acceso heredado, acceso indirecto y acceso realmente riesgoso.

Por eso herramientas como IAM Access Analyzer toman valor en escenarios grandes: no porque reemplacen entender IAM, sino porque ayudan a reducir la complejidad operativa cuando ya no estás mirando cuatro roles de laboratorio, sino cientos o miles de identidades con permisos cruzados sobre muchos recursos.

El botón Archivar: para qué sirve

Archivar un finding no modifica el acceso ni cambia las policies. Solo cambia la forma en que administras ese resultado dentro del analyzer.

Cuando archivas un finding:

deja de mostrarse entre los findings activos;
permanece disponible como archivado;
puedes utilizar archive rules para archivar automáticamente nuevos findings que coincidan con criterios definidos;
al crear una regla puedes elegir aplicarla solo a nuevos findings o también archivar findings activos existentes.

Si desaparece la ruta de acceso, el finding pasa a Resolved. Si la ruta cambia de forma relevante, Access Analyzer puede resolver el finding anterior y generar uno nuevo.

Resultados del laboratorio

Rol	ListBucket	GetObject	PutObject	DeleteObject
`RoleReadOnly`	✅ Permitido	✅ Permitido	❌ RCP	❌ IAM
`RoleAdmin`	✅ Permitido	✅ Permitido	❌ RCP	❌ SCP
`RoleDiagnosticExplicitNoBoundary`	✅ Permitido	✅ Permitido	❌ RCP	❌ SCP
`RoleAdminWildcardNoBoundary`	✅ Permitido	✅ Permitido	❌ RCP	❌ SCP

La tabla muestra únicamente las llamadas realmente ejecutadas. La comparación de los findings se encuentra en la sección anterior.

Qué demuestra este lab

Para que una acción cross-account funcione en este escenario se necesitan estas condiciones:

Una identity policy en el rol de la Cuenta B que permita la acción.
Una bucket policy en la Cuenta A que conceda esa acción al rol externo.
Que no exista un explicit deny aplicable a esa acción y a ese recurso.
Si el rol tiene un permissions boundary, que la acción esté incluida dentro de su máximo permitido.

Esto no significa que no puedan existir SCP o RCP. En este laboratorio existen ambas, pero bloquean operaciones concretas: la SCP bloquea DeleteObject y DeleteObjectVersion, mientras que la RCP bloquea PutObject. Las demás acciones continúan disponibles según las otras policies aplicables.

La primera parte del lab muestra esto con SCP: el rol tiene permiso IAM, la bucket policy también se lo da, pero el explicit deny organizacional gana.

La ampliación con RCP refuerza la misma idea desde el lado del recurso: aunque la ruta de acceso exista, el control organizacional sigue pudiendo cortar la operación en runtime.

Y la prueba con GetBucketPolicy añade una tercera lección importante: un permissions boundary también puede participar como capa limitante y aparecer expresamente identificado en el mensaje de AccessDenied.

Lo importante es que el lab no solo muestra el deny, sino también algo más útil para producción: te obliga a entender cómo leer el finding y cómo interpretar los errores runtime sin asumir que uno de los dos es un espejo perfecto del otro.

Antes de habilitarlo en producción: el pricing

Acá hay algo que casi ningún tutorial menciona y que conviene saber antes de habilitar esto en producción.

IAM Access Analyzer Internal Access no es gratuito para el análisis de permisos efectivos.

Algunas consideraciones prácticas:

No lo habilites sobre todos los recursos por default. Empieza por los buckets que contengan datos sensibles o regulados.
Usa etiquetas para identificar recursos críticos (DataClassification: Confidential, por ejemplo) y limita el scope del analizador a esos recursos.
Tiene más sentido en recursos específicos de alto riesgo: buckets con datos PCI, repositorios de logs de seguridad, buckets compartidos cross-account, tablas de DynamoDB, snapshots de bases de datos RDS y snapshots de clústeres RDS.
Para el resto, IAM Access Advisor puede ayudar a priorizar una revisión manual periódica y reducir el número de recursos sobre los que necesitas habilitar Internal Access Analyzer.

La recomendación concreta: define primero qué es un recurso crítico en tu organización, aplica tags de clasificación de datos, y usa Access Analyzer Internal Access solo sobre ese subconjunto. No sobre todo.

Nota práctica: si pensaste en activarlo un momento y luego borrarlo, ojo: en mi caso el cobro se reflejó el mismo día que lo activé y por la unidad mensual completa del recurso monitoreado. Eso ya de por sí te obliga a pensar mejor el experimento antes de habilitarlo.

Y acá sumaría otra recomendación basada en lo que me pasó en este lab: antes de habilitarlo sobre recursos críticos, entiende bien qué tipo de preguntas quieres responder con él.

Si tu pregunta es “quién puede llegar a este recurso y por qué camino”, el analyzer te aporta muchísimo.
Si tu pregunta es “esta API exacta quedó efectivamente bloqueada por esta capa organizacional o de identidad”, entonces probablemente también vas a querer hacer validación runtime para no llevarte sorpresas al interpretar el finding.

Perspectiva Red Team

Access Analyzer no es solamente útil para equipos defensivos, pero esta parte necesita contexto.

Un usuario o rol necesita permisos para consultar el analyzer y sus findings. Además, las llamadas realizadas desde la consola o mediante las APIs de IAM Access Analyzer se registran en AWS CloudTrail.

Por tanto, no es correcto asumir que cualquier rol comprometido en una cuenta miembro puede consultar el analyzer organizacional o que su uso sea invisible.

En un ejercicio Red Team interno y autorizado, una identidad que ya tenga acceso al analyzer podría utilizar los findings para:

Revisar rutas de acceso sin llamar directamente al recurso objetivo.
Priorizar relaciones cross-account relevantes.
Comparar acceso reportado frente a acceso ejecutable.
Evaluar el impacto de SCP, RCP y permissions boundaries.

Lo que Access Analyzer muestra (y lo que no)

Para dejarlo claro:

✅ Qué identidades tienen acceso a un recurso específico

✅ Qué capas participaron en la evaluación, incluyendo IAM, resource policies, SCPs y RCPs

✅ Findings exportables para evidencia de auditoría

✅ Visibilidad centralizada a escala de organización desde la cuenta que administra el analyzer

Y también algo que este lab me dejó mucho más claro:

⚠️ No siempre lo usaría como única evidencia para afirmar que una API concreta desapareció del acceso efectivo solo porque una SCP o una RCP la bloquean en runtime

⚠️ El mensaje de AccessDenied no siempre te va a mostrar todas las capas que podrían estar contribuyendo a la denegación

⚠️ Para denegaciones puntuales por capa organizacional o por boundary, conviene complementar con una prueba runtime controlada

Conclusión

La pregunta con la que empezó esta serie era:

¿Quién puede acceder realmente a tus recursos en AWS?

Después de este lab, la respuesta práctica sigue siendo que no puedes resolverlo revisando una sola policy.

IAM Access Analyzer Internal Access aporta valor para descubrir principals, acciones y rutas de acceso sobre recursos críticos. También permite centralizar los resultados a nivel organizacional y consultar los findings mediante API.

El laboratorio dejó además una observación concreta: tomando como referencia las cuatro operaciones principales, en tres casos controlados el finding coincidió con el conjunto de acciones esperado. En el rol con s3:* sin permissions boundary, el finding siguió mostrando PutObject, DeleteObject y DeleteObjectVersion, aunque las restricciones aparecían como APPLIED. Las pruebas runtime confirmaron que PutObject era denegado por la RCP y DeleteObject por la SCP.

No voy a especular sobre la causa exacta. Lo que sí puedo hacer es dejar la configuración, los findings y las pruebas runtime para que el resultado sea reproducible.

Y debido a que Internal Access Analyzer es una capacidad pagada, también recomiendo pensar bien qué preguntas quieres responder antes de habilitarlo. Si buscas identificar quién puede acceder a un bucket crítico y por qué ruta, resulta especialmente útil. Pero si solo necesitas validar una API puntual, quizá una revisión de policies y una prueba runtime controlada sean suficientes.

El costo se calcula por recurso monitoreado, por analyzer y por región, así que habilitarlo sin definir previamente el alcance puede terminar generando un gasto mayor al esperado. En producción empezaría por recursos realmente críticos, como buckets con datos sensibles, logs de seguridad o recursos compartidos entre cuentas, y ampliaría el alcance solo cuando exista una necesidad clara.

Para mí, esa es la lectura más útil del ejercicio:

usa el analyzer para ganar visibilidad;
entiende qué significa cada campo;
valida las APIs críticas cuando necesites una respuesta puntual;
define el alcance antes de activarlo;
evita interpretar una sola pantalla sin revisar las demás capas.

💡 ¿Encontraste algún acceso que no esperabas al analizar tus recursos? Ese suele ser el momento en que este tipo de herramientas pasan de “interesante” a “necesaria”.

🔗 Si llegaste directo aquí, te recomiendo leer la Parte 1 primero para entender el contexto.

📌 Y si quieres el contexto de SCPs, RCPs y boundaries desde cero, tengo un post anterior donde explico cada tipo de política con ejemplos concretos.

AWS #CloudSecurity #IAM #AccessAnalyzer #SCPs #RCPs #PermissionsBoundary #CloudGovernance #AWSOrganizations #LeastPrivilege #RedTeam

🛡️ AWS IAM Access Analyzer — Parte 2/4

Terry Quispe Paniagua — Fri, 03 Jul 2026 00:46:28 +0000

External Access: el analizador sin costo adicional que deberías tener activo en todas tus cuentas

En AWS, el acceso no depende de una sola policy. Entre identity policies, resource-based policies, trust policies, SCPs, RCPs, boundaries y configuraciones por servicio, saber si un recurso está expuesto puede volverse confuso rápido.

Antes de entrar al análisis de permisos efectivos internos, conviene empezar por el analyzer más básico y más urgente: External Access Analyzer.

Este post es sobre ese primer baseline: detectar recursos que están accesibles desde fuera de tu zona de confianza. No tiene costo adicional por recurso analizado, se habilita por región y cubre automáticamente los recursos soportados en esa región. Su objetivo es detectar algo muy concreto: recursos accesibles desde fuera de la zona de confianza que defines.

¿Qué hace exactamente el External Access Analyzer?

El External Access Analyzer genera findings cuando detecta que un recurso dentro de tu zona de confianza puede ser accedido por un principal externo. Esa zona de confianza puede ser una cuenta individual o toda una AWS Organization.

Lo que evalúa depende del tipo de recurso soportado. En términos prácticos, revisa políticas o configuraciones como:

bucket policies y ACLs de S3
trust policies de roles IAM
key policies y grants de KMS
queue policies de SQS
topic policies de SNS
function policies de Lambda
resource policies de Secrets Manager, ECR, EFS, DynamoDB, entre otros

Si la policy de un recurso tiene un Principal: "*", una cuenta externa, un usuario federado externo o una condición que permite acceso fuera de tu zona de confianza, el analizador puede generar un finding.

Qué tipos de acceso externo detecta

Tipo de acceso	Ejemplo	Finding generado
Acceso público	`"Principal": "*"` sin condición restrictiva	✅ Sí
Acceso cross-account a otra cuenta de la misma org	ARN de cuenta en la misma organización	Solo si la zona de trust es la cuenta individual
Acceso cross-account fuera de la org	ARN de cuenta externa	✅ Sí
Acceso restringido por organización	`Condition: { "aws:PrincipalOrgID": "o-xxxx" }`	Normalmente no, si la zona de trust es esa organización
Acceso mediante federación externa	SAML/OIDC con IdP externo o federado	✅ Sí, si queda fuera de la zona de confianza

La diferencia entre configurar la zona de confianza como cuenta versus organización importa bastante.

Si la defines como organización, los accesos cross-account dentro de la misma AWS Organization no generan findings porque se consideran internos a la zona de confianza. Si la defines como cuenta, cualquier acceso cross-account, incluso desde una cuenta hermana de la misma organización, puede generar finding.

Por qué este analizador importa antes que cualquier otro

El Internal Access Analyzer tiene costo porque se cobra por recurso monitoreado. El Unused Access Analyzer también tiene costo porque se cobra por rol o usuario analizado. External Access Analyzer, en cambio, no tiene costo adicional y cubre automáticamente los recursos soportados de la región donde se habilita.

El problema que detecta es frecuente y de alto impacto:

bucket S3 con "Principal": "*" que alguien abrió para una prueba y nunca cerró
rol IAM con trust policy que confía en una cuenta externa que ya no existe como partner
clave KMS accesible desde otra cuenta por una integración que ya fue migrada
secret de Secrets Manager con resource policy demasiado permisiva
rol con trust policy heredada hacia Cognito Identity Pools

Estos recursos no necesariamente generan alarmas operacionales. La aplicación puede seguir funcionando normal. Nadie lo nota. El analizador los detecta porque observa la configuración de acceso, no porque espere a que ocurra un incidente.

Recurso recomendado para generar findings útiles

💡 Si quieres ver findings reales sin mucha configuración, este es el recurso más directo:

Crea un bucket S3 con una bucket policy que permita acceso desde una cuenta externa o desde "*". El analizador lo detecta y genera un finding con información como recurso, principal externo, origen del acceso y nivel de acceso.

Por qué S3 es un buen candidato para un lab:

Frecuente en la práctica: los findings externos más comunes suelen involucrar buckets con políticas demasiado abiertas.
Finding rápido: para S3, los cambios en bucket policy o ACL suelen reflejarse dentro de aproximadamente 30 minutos. Otros cambios, como Block Public Access a nivel de cuenta, pueden tardar más.
Finding detallado: muestra el recurso, el principal externo, cómo se compartió y el nivel de acceso.
Fácil de limpiar: eliminar o corregir la bucket policy resuelve el finding.

En la práctica, sin embargo, activar el analizador en un entorno real con AWS IAM Identity Center ya puede generar decenas de findings sin necesidad de crear un recurso de prueba. Eso fue exactamente lo que pasó aquí.

External Access Analyzer en acción: lo que encuentras en un entorno real

Configuración del analizador

El External Access Analyzer se crea desde la consola de IAM:

IAM > Access Analyzer > Analyzers > Create analyzer

Configuración del lab:

Nombre:        demo-external-access-analyzer
Tipo:          External Access Analysis
Zona de trust: AWS Organization

Un detalle importante: el analizador opera por región. Si tienes recursos en us-east-1 y us-east-2, necesitas un analizador en cada región donde quieras monitorear acceso externo. La zona de trust se define a nivel del analizador; si eliges la organización entera, los findings se calculan respecto a ese límite.

Lo que encontré al activarlo: 39 findings activos

No hizo falta crear ningún recurso de prueba. En cuanto el analizador quedó activo, apareció una lista larga de findings activos.

Al inicio tenía aplicado el filtro Public access = false, por eso veía 38 findings. Al quitar ese filtro apareció un finding adicional: un bucket S3 con acceso público (Public access = true). Por eso el total real del analizador era de 39 findings.

La mayoría correspondían a roles IAM relacionados con IAM Identity Center y federación, pero también apareció un bucket S3 con acceso externo. Esa mezcla fue útil porque mostró dos tipos de exposición:

trust policies en roles IAM
resource policies en S3

Esto es importante porque External Access Analyzer no se limita a roles. Su objetivo es detectar recursos soportados que están accesibles desde fuera de la zona de confianza definida para el analizador.

Grupo 1 — Roles SSO: federación esperada, pero no se archiva a ciegas

La mayoría de los findings corresponden a roles con nombres del tipo:

aws-reserved/sso.amazonaws.com/AWSReservedSSO_AdministratorAccess_<sufijo>
aws-reserved/sso.amazonaws.com/AWSReservedSSO_AWSReadOnlyAccess_<sufijo>
aws-reserved/sso.amazonaws.com/AWSReservedSSO_AWSPowerUserAccess_<sufijo>
aws-reserved/sso.amazonaws.com/AWSReservedSSO_AWSOrganizationsFullAccess_<sufijo>

Estos roles los crea AWS IAM Identity Center automáticamente en las cuentas donde asignas permission sets. Su trust policy permite que usuarios federados los asuman a través del SAML provider (en este caso yo tengo configurado cloud identity de google) asociado a IAM Identity Center:

{
  "Effect": "Allow",
  "Principal": {
    "Federated": "arn:aws:iam::<cuenta>:saml-provider/AWSSSO_<id>_DO_NOT_DELETE"
  },
    "Action": [
        "sts:AssumeRoleWithSAML",
        "sts:TagSession"
            ],
    "Condition": {
        "StringEquals": {
            "SAML:aud": "https://signin.aws.amazon.com/saml"
        }
    }
}

El analizador los marca porque, desde la perspectiva de External Access Analyzer, existe un principal federado que puede asumir el rol. En entornos con IAM Identity Center esto suele ser esperado y forma parte del funcionamiento normal de SSO.

En mi caso, la revisión sería:

confirmar que el permission set corresponde al acceso esperado
confirmar que la cuenta donde aparece el rol es la correcta
confirmar que los usuarios o grupos asignados siguen vigentes
confirmar que los permission sets administrativos están donde realmente deben estar

Si todo eso está correcto, estos findings son buenos candidatos para archive rule.

El nivel de acceso que muestra el analizador para estos roles es Write, Tagging, porque el finding está mirando la trust policy del rol: quién puede asumirlo. No está mostrando los permisos efectivos que tendrá la sesión después de asumir el rol.

Dicho de otra forma, en External Access Analyzer un finding sobre un IAM Role responde principalmente a esta pregunta:

¿Quién puede asumir este rol desde fuera de mi zona de confianza?

No responde directamente:

¿Qué puede hacer ese rol una vez asumido?

Grupo 2 — Roles con trust cross-account hacia una cuenta externa

Cuatro findings corresponden a roles con nombres como SSOSAdmin-Asumed, SSOCores-Asumed, SSOArchitech-Asumed y SSOGov-Asumed. Todos tienen el mismo tipo de principal: una cuenta de AWS que no es parte de la organización definida como zona de trust.

Entidad principal: Cuenta de AWS → <cuenta-externa>
Compartido a través de: Trust policy del rol
Nivel de acceso: Write

A diferencia de los roles SSO, aquí el trust es directo hacia una cuenta AWS específica. En este contexto, “cuenta externa” no significa una cuenta desconocida, sino una cuenta fuera de la AWS Organization definida como zona de confianza. En mi caso, ese cross-account fue creado adrede desde otra organización para el lab.

Aun así, el finding es útil porque recuerda algo importante: cuando la zona de trust es la organización, cualquier trust hacia una cuenta fuera de esa organización queda marcado como acceso externo.

La revisión práctica aquí no es “¿quién creó esto?”, sino:

¿este trust cross-account todavía se necesita?
¿la cuenta externa sigue siendo la correcta?
¿el rol tiene permisos acordes al caso de uso?
¿conviene agregar condiciones como sts:ExternalId, aws:PrincipalArn u otra restricción?
¿está documentado que esta cuenta externa puede asumir el rol?

Importante: aunque el rol tenga AdministratorAccess, el finding no muestra AdministratorAccess como acción. External Access Analyzer está evaluando la trust policy del rol, por eso muestra sts:AssumeRole.

El finding responde:

¿quién puede asumir este rol desde fuera de mi zona de confianza?

No responde directamente:

¿qué permisos tendrá esa sesión después de asumirlo?

Para medir el impacto real, hay que revisar también las policies adjuntas al rol. Si el rol confiado por una cuenta externa tiene AdministratorAccess, entonces el finding es más sensible, aunque en la consola solo aparezca sts:AssumeRole.

Grupo 3 — Federación con Google Workspace: SAML externo personalizado

Un finding apunta al rol SSOTestSamlWorkspace, con trust configurado hacia un SAML provider GoogleWorkspace:

Entidad principal: Usuario federado → arn:aws:iam::<cuenta>:saml-provider/GoogleWorkspace
Compartido a través de: Trust policy del rol
Nivel de acceso: Write

Este caso es diferente a los roles AWSReservedSSO_* gestionados por IAM Identity Center. Aquí la confianza está puesta directamente en un SAML provider personalizado.

En mi caso, este rol existe porque uso Google Workspace / Cloud Identity como parte del flujo de federación para entrar a AWS. El analyzer no está diciendo “esto está mal”; está diciendo “este proveedor federado puede asumir este rol”.

Y eso es justo lo valioso: aunque uno mismo lo haya creado, el analyzer lo pone sobre la mesa para decidir si sigue siendo necesario, si debe documentarse mejor, si debe restringirse más o si ya toca borrarlo.

Dicho en simple: gracias, analyzer, por recordarme que este camino de acceso sigue vivo.

Grupo 4 — Cognito: un rol que quedó vivo después de una prueba

Entre todos los findings, hay uno que tiene una naturaleza diferente al resto:

Recurso:    service-role/cognito-testing
Principal:  cognito-identity.amazonaws.com
Condición:  us-east-1:<id-del-pool>  ← pool de Cognito
Nivel:      Write
Tipo:       Público de Cognito

Este finding no venía de un Cognito User Pool, sino de una trust policy de IAM asociada a Cognito Identity Pools. La diferencia importa: el User Pool autentica usuarios, mientras que el Identity Pool puede entregar credenciales temporales de AWS mediante roles IAM.

En mi caso, esto venía de una prueba antigua. En algún momento creé un Identity Pool, luego lo eliminé, pero el rol cognito-testing quedó vivo con esta trust policy:

{
  "Effect": "Allow",
  "Principal": {
    "Federated": "cognito-identity.amazonaws.com"
  },
  "Action": "sts:AssumeRoleWithWebIdentity",
  "Condition": {
    "StringEquals": {
      "cognito-identity.amazonaws.com:aud": "<id-del-pool>"
    },
    "ForAnyValue:StringLike": {
      "cognito-identity.amazonaws.com:amr": "unauthenticated"
    }
  }
}

La conclusión no es que actualmente exista un Identity Pool público activo, porque al revisar la cuenta ya no había Identity Pools en esa región. La conclusión correcta es que quedó un rol IAM con una trust policy heredada de una prueba anterior.

Y justamente ahí está el valor del analyzer: no solo encuentra exposiciones activas evidentes, también te recuerda configuraciones viejas que quedaron dando vueltas.

Gracias, analyzer. Me olvidé de borrar el rol.

Grupo 5 — Bucket S3 con acceso público

Al quitar el filtro Public access = false, apareció un finding adicional sobre un bucket S3:

Recurso: demo-api-gw-s3-cors-555
Tipo:    S3 Bucket
Principal externo: Todas las entidades principales
Acceso público: true
Nivel de acceso: Write, Permissions, Tagging, Read, List
Compartido a través de: Política del bucket

Este bucket fue parte de una prueba de API Gateway + S3/CORS. Justamente por eso el finding es útil: no necesariamente es un recurso productivo comprometido, pero sí es una exposición real que quedó visible para revisión.

A diferencia de los roles SSO, aquí no hablamos de una trust policy de IAM. Hablamos de una bucket policy que permite acceso a todas las entidades principales.

Este finding merece remediación prioritaria porque combina dos señales fuertes:

el principal externo es público
el nivel de acceso incluye más que lectura

En mi caso, como era una prueba, la decisión correcta es simple: corregir la bucket policy, activar/verificar Block Public Access o eliminar el bucket si ya no se necesita.

Categorización práctica de los findings

Con este volumen de findings, la primera tarea es categorizarlos para saber qué revisar primero:

Categoría	Ejemplo	Acción recomendada
Roles SSO gestionados por AWS	`AWSReservedSSO_*` con SAML provider `DO_NOT_DELETE`	Validar permission set, cuenta y asignaciones; luego archivar con archive rule si es esperado
Roles custom con trust cross-account	`SSOSAdmin-Asumed` confiando en cuenta externa	Revisar si el acceso sigue vigente, documentado y justificado
Roles con SAML provider externo personalizado	`SSOTestSamlWorkspace` con GoogleWorkspace	Revisar si el provider y el rol siguen activos
Rol con trust heredada hacia Cognito	`cognito-testing` con `amr = unauthenticated` en la trust policy	Validar si el Identity Pool sigue existiendo; si no existe, eliminar o limpiar el rol
Bucket S3 público	`demo-api-gw-s3-cors-555` con principal público	Revisar bucket policy, Block Public Access y necesidad real de exposición pública

El orden de prioridad no depende solo del volumen. Los roles SSO pueden ser muchos, pero suelen ser esperados si IAM Identity Center está bien gobernado. En cambio, un bucket S3 público con permisos amplios o un rol con una trust policy heredada hacia Cognito pueden representar una superficie de exposición mucho más concreta.

Archive Rules: reducir el ruido esperado

Con decenas de findings de roles SSO esperados, crear una Archive Rule es lo más eficiente. Las archive rules sirven para archivar automáticamente nuevos findings que coincidan con un patrón. Para findings existentes, puedes revisarlos y archivarlos manualmente, o aplicar la regla cuando corresponda desde el flujo de revisión.

Se crean desde:

IAM > Access Analyzer > Analyzers > [tu analizador] > Archive rules > Create rule

Para los roles SSO, una condición útil es filtrar por el nombre del recurso:

Resource contains "aws-reserved/sso.amazonaws.com/AWSReservedSSO_"

Eso ayuda a archivar automáticamente los nuevos findings asociados a roles gestionados por IAM Identity Center, sin mezclar findings más sensibles como buckets públicos, roles custom con trust cross-account, SAML providers externos personalizados o Cognito.

Las condiciones disponibles para los filtros dependen de la consola/API, pero normalmente puedes filtrar por campos como:

Resource
Principal
Access level
Is public
Principal type

Importante: una archive rule no debe usarse para ocultar findings sin revisión. Primero se valida que el patrón sea esperado; recién después se automatiza el archivado.

Recursos soportados por External Access Analyzer

El analizador no solo cubre roles IAM. Estos son los tipos de recursos que puede analizar para external access:

Recurso	Qué evalúa
S3 Buckets	Bucket policy, ACLs, access points asociados y Multi-Region Access Points
S3 Directory Buckets	Directory bucket policy
IAM Roles	Trust policy
KMS Keys	Key policy y grants
Lambda Functions and Layers	Resource-based policies
SQS Queues	Queue policy
SNS Topics	Topic policy
Secrets Manager	Resource policy
ECR Repositories	Repository policy
EFS File Systems	File system policy
EBS Volume Snapshots	Snapshot sharing permissions
RDS DB Snapshots	Snapshot sharing permissions
RDS DB Cluster Snapshots	Snapshot sharing permissions
DynamoDB Streams	Resource policy
DynamoDB Tables	Resource policy

En este lab, la mayoría de findings fueron sobre roles IAM porque el entorno tenía muchos roles SSO y roles con trust policies hacia identidades externas. Sin embargo, también apareció un bucket S3 público. En entornos donde existan claves KMS compartidas, secretos con resource policies externas, colas SQS compartidas o snapshots públicos, el analizador también puede generar findings de esos tipos.

Qué hacer con un finding: Archive vs. remediar

Cuando un finding aparece, tienes dos caminos:

1. Si el acceso es intencional:

Haz clic en Archive. El finding pasa a estado Archived y queda fuera de la vista activa. También puedes crear archive rules para que findings similares se archiven automáticamente después de haber validado que ese patrón es esperado.

2. Si el acceso no es intencional:

Modifica o elimina la política o configuración que abre el acceso. En cuanto el recurso deja de tener acceso externo, el finding pasa a estado Resolved.

Archivar no es remediar. Archivar significa: “este acceso fue revisado y es intencional”. Si el acceso no debería existir, lo correcto no es archivarlo; lo correcto es corregir la policy.

External Access vs. Internal Access: cuándo usar cada uno

Antes de pasar al siguiente post, vale la pena separar ambos conceptos.

External Access Analyzer e Internal Access Analyzer pertenecen a IAM Access Analyzer, pero responden preguntas distintas. External mira hacia fuera: recursos accesibles desde fuera de la zona de confianza. Internal mira hacia dentro: identidades internas que tienen acceso a recursos seleccionados.

Criterio	External Access Analyzer	Internal Access Analyzer
Pregunta que responde	¿Qué recursos están accesibles desde fuera de mi zona de confianza?	¿Qué identidades internas tienen acceso a recursos críticos seleccionados?
Zona de confianza	Cuenta o AWS Organization	Cuenta o AWS Organization
Tipo de exposición	Acceso público o cross-account externo	Acceso interno dentro de la cuenta u organización
Qué analiza principalmente	Resource-based policies, trust policies, ACLs o grants según el tipo de recurso	Permisos efectivos sobre recursos específicos seleccionados
Ejemplos de recursos	Roles IAM, buckets S3, KMS keys, Lambda, SQS, SNS, Secrets Manager, ECR, EFS, snapshots, DynamoDB, entre otros recursos soportados	Recursos específicos que seleccionas para análisis interno
Cobertura	Recursos soportados en la región donde el analyzer está activo	Solo los recursos que seleccionas explícitamente
Costo	Sin costo adicional	Pagado por recurso monitoreado, por analyzer y por región
SCP/RCP	No es su objetivo principal como cálculo de permiso efectivo; se enfoca en exposición externa desde políticas de recurso, trust policies, ACLs o grants	Sí entra en el modelo de análisis de permiso efectivo, aunque la interpretación del action list requiere cuidado
Mejor uso	Baseline permanente para detectar exposición pública o externa	Auditoría específica de acceso interno sobre recursos sensibles
Recomendación práctica	Activarlo en todas las cuentas y regiones relevantes	Usarlo con criterio sobre recursos críticos por costo y alcance

La forma corta de verlo es esta:

External Access Analyzer sirve para detectar exposición hacia fuera.
Internal Access Analyzer sirve para revisar acceso interno sobre recursos críticos.
External debería ser baseline.
Internal debería usarse selectivamente donde realmente necesitas análisis de acceso efectivo.

Perspectiva de seguridad: por qué los findings deben revisarse antes de archivarse

External Access Analyzer también es útil desde una perspectiva de evaluación de seguridad.

Un usuario o rol con permisos suficientes para consultar Access Analyzer podría usar los findings como un mapa rápido de recursos expuestos externamente: buckets con acceso público, roles con trust policies hacia cuentas externas, proveedores SAML externos o configuraciones de Cognito que permitan identidades no autenticadas.

Eso no significa que cualquier finding sea automáticamente crítico. Significa que cada finding representa una ruta de acceso que existe y que merece clasificación.

Desde el lado defensivo, la prioridad es llegar antes:

Activar el analyzer.
Revisar los findings.
Separar accesos esperados de accesos no documentados.
Archivar lo intencional.
Remediar lo que no debería existir.

Los findings sin revisar son el problema real. Un bucket público intencional, documentado y monitoreado no tiene el mismo peso que un bucket público creado para una prueba y olvidado. Lo mismo aplica para roles federados, trusts cross-account o pools de Cognito.

En este lab, la mayoría de findings eran esperados por IAM Identity Center, pero el bucket S3 público y el rol con trust heredada hacia Cognito merecían revisión separada. Esa es precisamente la utilidad del analyzer: no reemplaza el criterio del equipo de seguridad, pero reduce mucho el tiempo necesario para encontrar qué revisar primero.

Lo que demuestra este lab

Activar el analizador en un entorno real con IAM Identity Center puede generar hallazgos desde los primeros minutos, sin necesidad de crear recursos de prueba. Eso ya dice algo: hay rutas de acceso que merecen revisión y que no siempre son visibles si solo revisas manualmente cada cuenta o cada policy.

Lo que vale de este analizador no es que reemplace el criterio del equipo de seguridad. Su valor está en que es continuo y automático: revisa los recursos soportados y genera findings cuando detecta acceso público o externo respecto a tu zona de confianza.

En términos prácticos:

✅ Sin costo adicional
✅ Cobertura automática de recursos soportados en la región donde se habilita
✅ Findings con detalle de recurso, principal, tipo de acceso y acciones reportadas
✅ Archive rules para reducir ruido esperado, como roles SSO gestionados por IAM Identity Center
✅ Estado Resolved cuando el acceso externo deja de existir

Y la lección más importante del lab: el volumen de findings no es el indicador principal de riesgo.

En mi caso, con el filtro Public access = false veía 38 findings. Al quitarlo, apareció un bucket S3 público y el total subió a 39. La mayoría eran roles SSO esperados, pero el bucket S3 público y el rol con trust heredada hacia Cognito merecían revisión separada. Ese es precisamente el punto: el analyzer no solo te muestra cuántos findings tienes, sino cuáles debes clasificar primero.

Conclusión

Si tienes una cuenta de AWS y no tienes External Access Analyzer activo, es uno de los primeros controles que habilitaría. No tiene costo adicional, se activa en minutos y te da visibilidad sobre accesos que normalmente no generan una alerta operacional por sí solos.

Lo que pasó en este lab es representativo de muchos entornos con IAM Identity Center: aparece un volumen alto de findings esperados, especialmente por roles SSO, pero entre ellos puede haber uno o dos findings que sí merecen atención inmediata.

La habilidad no está solo en activar el analyzer. La habilidad está en clasificar rápido:

qué es esperado
qué debe archivarse
qué debe documentarse
qué debe corregirse

En el siguiente post cubro Internal Access Analyzer: cómo analizar acceso interno efectivo sobre un recurso crítico, cómo se cruzan IAM policies, bucket policies y SCPs, y por qué no basta con revisar una sola policy.

💡 ¿Cuántos findings aparecen cuando activas el analizador por primera vez en tu entorno? El número suele ser una sorpresa — y la mayoría son esperados, pero entre ellos casi siempre hay algo que merece atención.

🔗 Si llegaste directo aquí, te recomiendo leer la Parte 1 para el contexto base. En la Parte 3 veremos Internal Access Analyzer con un lab de permisos efectivos, SCPs y acceso cross-account interno.

AWS #CloudSecurity #IAM #AccessAnalyzer #IAMIdentityCenter #SSO #CognitoSecurity #ExternalAccess #CloudGovernance #AWSOrganizations #LeastPrivilege

Referencias

AWS IAM Documentation — What is IAM Access Analyzer?
https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html
AWS IAM Documentation — IAM Access Analyzer supported resource types for external and internal access
https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-resources.html
AWS IAM Documentation — Create an IAM Access Analyzer external access analyzer
https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-create-external.html
AWS IAM Documentation — IAM Access Analyzer findings
https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-findings.html
AWS IAM Documentation — Archive rules
https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-archive-rules.html
AWS Pricing — IAM Access Analyzer pricing
https://aws.amazon.com/iam/access-analyzer/pricing/
AWS S3 Documentation — Reviewing bucket access using IAM Access Analyzer for S3
https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-analyzer.html
AWS S3 Documentation — Blocking public access to your Amazon S3 storage
https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-control-block-public-access.html

🛡️AWS IAM Access Analyzer — Parte 1/4

Terry Quispe Paniagua — Sun, 21 Jun 2026 01:14:43 +0000

¿Quién puede acceder realmente a tus recursos en AWS?

En el post anterior hablamos de SCPs, RCPs y IAM Policies. Si no lo leíste, te recomiendo empezar por ahí porque este post construye sobre eso.

Hoy quiero hacerte una pregunta incómoda:

"¿Puedes decirme, ahora mismo, qué identidades tienen acceso efectivo a este bucket S3?"

No el acceso que pensaste que configuraste. El acceso real, considerando todas las políticas en juego.

Si tardas más de 30 segundos en responder, este post es para ti.

El problema con el acceso en AWS

Cuando tienes una sola cuenta y cuatro usuarios, responder esa pregunta es fácil. Abres la consola, revisas las políticas y listo.

Pero hay una diferencia importante entre dos cosas que suelen confundirse:

Acceso esperado: lo que crees que configuraste, suponiendo que sea correcto.
Acceso efectivo: lo que AWS realmente permite después de evaluar todas las políticas

La brecha entre estas dos cosas es donde vive la mayoría de los incidentes de seguridad en AWS. No son ataques sofisticados. Son configuraciones que alguien dio por buenas porque "la IAM policy dice que sí" — sin considerar el resto de las capas.

En el mundo real, un entorno AWS medianamente serio se parece más a esto:

10, 20, 50 o más cuentas dentro de una AWS Organization
Decenas de roles que se asumen entre cuentas - en algunas ocasiones he visto miles -.
SCPs aplicadas a nivel de OU que limitan lo que pueden hacer las identidades.
RCPs que controlan quién puede acceder a tus recursos desde fuera.
Resource-based policies en S3, KMS, SQS, SNS, etc.
Permission Boundaries en algunos roles.
Trust policies que definen quién puede asumir cada rol.

Y ahí es donde la cosa se complica de verdad.

¿Qué determina realmente el acceso efectivo?

Cuando AWS evalúa si una acción está permitida, no se queda solo con la IAM policy que ves en el rol o usuario. Revisa todas las capas que aplican a esa solicitud y parte de una regla muy simple: si no hay un Allow, el acceso está denegado; y si aparece un Deny explícito, ese Deny gana siempre.

Dicho de forma simple, en una sola cuenta la evaluación se puede entender así:

¿Existe un Deny explícito aplicable?
    └── Sí → DENEGADO. Fin.
    └── No → continuar

¿Existe algún Allow válido?
    └── Puede venir de una IAM policy o de una resource-based policy
    └── Si no existe → DENEGADO

¿Hay algún límite que recorte ese permiso?
    └── SCP
    └── RCP
    └── Permission Boundary
    └── Session Policy

Si hay Allow y ningún límite lo bloquea → PERMITIDO

La parte importante es esta: IAM policies y resource-based policies pueden conceder permisos, pero SCPs, RCPs, Permission Boundaries y Session Policies funcionan más como límites. No agregan permisos por sí solos; más bien definen hasta dónde puede llegar un permiso que ya existe.

Resumido de forma práctica:

Acceso efectivo =
    permiso concedido
  - denies explícitos
  - límites organizacionales
  - boundaries o session policies aplicables

Si cualquiera de estas capas dice "No", la acción está bloqueada. No importa que las demás capas parezcan permitirlo. Este es el punto que la gente entiende en teoría pero subestima en la práctica. En cross-account hay matices adicionales, porque AWS evalúa tanto la cuenta del principal como la cuenta donde vive el recurso. Pero la idea base se mantiene: cualquier deny explícito aplicable bloquea la acción. Puedes revisar el flujo de evaluación en:

El problema a escala: con múltiples cuentas, cientos o miles de roles, innumerables recursos, varias OUs con diferentes SCPs y RCPs, hacer este análisis a mano para cada recurso crítico es inviable. Y si no lo haces, no sabes realmente qué acceso tienen tus identidades.

Tres escenarios donde el acceso falla aunque "debería" funcionar

Estos son los casos que más se repiten. Si has trabajado en entornos con Organizations, probablemente reconoces alguno.

Escenario 1: El admin que no puede hacer nada

Un usuario tiene la política AdministratorAccess en su cuenta. Intenta crear un bucket S3 en sa-east-1 y le da error de acceso denegado. No cambió nada. Todo funcionaba ayer.

Lo que pasó: alguien en el equipo de plataforma aplicó una SCP a nivel de OU que restringe la creación de recursos a us-east-1 únicamente - algo muy habitual y recomendado -. El admin ve un AccessDenied, pero también el motivo por el cual, ya que en el detalle de error se indica que la acción está vetada por una SCP - a veces no es tan detallado -.

La SCP es un límite máximo. AdministratorAccess dice "puede hacer todo", pero si la SCP dice "solo en us-east-1", el resultado es "puede hacer todo, solo en us-east-1".

Ejemplo: Eliminación de objeto con restricción por SCP

Ejemplo: Eliminación de objeto por CLI

Escenario 2: El bucket "público" que no lo es

Un desarrollador configura un bucket S3 con una bucket policy que permite s3:GetObject a "Principal": "*". Desde su cuenta local, el acceso funciona. Pero desde una cuenta externa de un proveedor, el acceso falla.

Lo que pasó: hay una RCP a nivel de organización que exige que cualquier acceso a recursos de S3 venga de un principal con aws:PrincipalOrgID igual al ID de la organización. El "*" de la bucket policy no se limita a sí mismo — la RCP sí lo limita desde afuera.

La RCP actúa sobre el recurso sin importar lo que diga la bucket policy. El desarrollador configuró el acceso "correctamente" según lo que entiende de S3, pero la capa organizacional lo restringe silenciosamente.

Escenario 3: El rol cross-account que IAM permite pero S3 no

Un rol en la Cuenta B tiene una IAM policy que permite s3:GetObject sobre el bucket arn:aws:s3:::datos-criticos/*. El equipo valida la policy, todo se ve bien. Pero cuando el rol intenta acceder al bucket, falla.

Lo que pasó: la bucket policy en la Cuenta A (donde vive el bucket) no lista el rol de Cuenta B como Principal permitido. En acceso cross-account, tanto la IAM policy del rol como la resource-based policy del recurso deben permitir la acción de forma explícita. Una sola no alcanza.

Este es uno de los errores más comunes con acceso cross-account: el equipo de Cuenta B configura sus políticas IAM perfectamente y asume que eso es suficiente. No lo es.

¿Qué es IAM Access Analyzer y qué tipos existen?

IAM Access Analyzer es el servicio de AWS que ayuda a identificar y revisar accesos sobre recursos e identidades. En vez de revisar políticas manualmente y cruzar capas en tu cabeza — lo que puede ser propenso a errores y muy complicado — , el analizador lo hace por ti y genera findings — hallazgos sobre accesos que merecen revisión.

Hay tres tipos de analizador, y es importante no confundirlos porque resuelven problemas distintos:

Tipo	¿Qué detecta?	¿Tiene costo?	¿Cuándo usarlo?
External Access	Recursos accesibles desde fuera de tu zona de confianza (otra cuenta, internet)	Sin costo adicional	Siempre. Es el punto de partida en cualquier cuenta
Internal Access	Qué principals dentro de tu org tienen acceso a recursos específicos, con permisos efectivos	Pagado ($9 USD/recurso/región/mes)	Recursos críticos: buckets, RDS o cluster snapshots, DynamoDB etc.
Unused Access	Roles y usuarios con permisos concedidos que no han sido utilizados	Pagado ($0.20 USD/rol o usuario/mes)	Revisiones de least privilege, limpieza de accesos obsoletos

La confusión más común es querer usar Internal Access para detectar accesos externos. No hace eso. Para eso existe External Access, que además es gratuito.

La novedad relevante que cubre esta serie es Internal Access, una de las capacidades más recientes de IAM Access Analyzer, que permite analizar el permiso efectivo considerando SCPs, RCPs y resource policies en conjunto.

¿Por qué importa esto para seguridad?

Auditorías y cumplimiento (PCI-DSS, ISO 27001, SOC 2)
En una auditoría, alguien va a pedirte evidencia de quién tiene acceso a tus datos sensibles. Access Analyzer te da eso en formato exportable, con el detalle de qué acciones puede realizar cada identidad. En vez de revisar cien políticas a mano, tienes un reporte automatizado.

Least privilege de verdad
Es fácil escribir "aplicamos least privilege" en un documento de arquitectura. Es difícil demostrarlo. Con análisis de permisos efectivos puedes ver exactamente qué permisos tiene cada identidad sobre cada recurso, y limpiar lo que sobra. No lo que crees que sobra — lo que el analizador te muestra que sobra.

Detección de configuraciones erróneas antes de que las encuentre alguien más
Un rol con "Resource": "*" donde debería tener un ARN específico. Una bucket policy que alguien amplió para una prueba y nunca revirtió. Un acceso cross-account que quedó abierto después de una migración. Estos hallazgos no generan alertas operacionales — el sistema funciona, el acceso existe, y nadie lo nota hasta que hay un incidente o una auditoría.

Esta serie da para más

Mientras armaba este post me di cuenta de que IAM Access Analyzer no se puede explicar bien en una sola publicación sin hacerlo pesado - la verdad los conceptos de acceso en cloud son pesados si no se aterrizan correctamente.

Por eso voy a separar la serie en tres partes mas una cuarta parte opcional como bonus con mcp: External Access, Internal Access y Unused Access. En cada una veremos el concepto, un caso práctico y un pequeño lab con evidencias, para aterrizarlo mejor y no quedarnos solo en la teoría.

ADVERTENCIA.
Algunos de los labs tendrán costos por lo que les pido precaución, lean antes y tengan controlado sus recursos.

¿Qué viene en la Parte 2?

En el siguiente post vamos al laboratorio. Vamos a:

Configurar un analizador Internal Access a nivel de organización
Crear tres roles con distintos niveles de acceso en una cuenta y un bucket en otra
Agregar una SCP que bloquea una acción aunque IAM y la bucket policy la permitan
Ver los findings de Access Analyzer y validar con CLI que el permiso efectivo es exactamente lo que el analizador reporta

💡 Reflexión: ¿Alguna vez encontraste un rol con más acceso del que debería tener, después de creer que todo estaba bien configurado? Es más común de lo que parece — y casi siempre la diferencia está entre el acceso esperado y el acceso efectivo.

🔜 Parte 2: Lab completo de IAM Access Analyzer Internal Access con SCPs, cross-account y validación por CLI.

AWS #CloudSecurity #IAM #AccessAnalyzer #AWSCommunityBuilder #CloudGovernance #AWSOrganizations

Referencias

🛡️ Entendiendo las Service Control Policies (SCPs) en AWS Organizations

Terry Quispe Paniagua — Tue, 02 Dec 2025 03:47:50 +0000

1. Introducción

¿Qué problema resuelven las SCPs?

Las SCPs, a diferencia de los permisos de IAM, no otorgan permisos, sino que los restringen. Popularmente llamados "guardrails" o "barandillas", son una herramienta clave para la gobernanza de AWS, así como también para fijar los lineamientos de seguridad y cumplimiento de la empresa.

Antes de proseguir debemos entender unos conceptos previos:

IAM Policy

Es un tipo de política de IAM que permite otorgar permisos a los usuarios y roles de AWS.

AWS Organizations

AWS Organizations es un servicio que permite administrar y gestionar de forma centralizada múltiples cuentas de AWS. Con Organizations puedes:

Crear y gestionar cuentas de AWS (Account Management)
Centralizar los costos de las cuentas de AWS (Billing)
Gestionar los permisos de las cuentas de AWS junto a IAM Identity Center (Identity and Access Management)
Aplicar políticas de seguridad a las cuentas de AWS (SCPs)
Habilitar servicios multicuentas (Multi-account)
Agrupar cuentas por Unidades Organizativas (Jerarquía de organización)
Auditar entorno multicuentas (Audit)
Compartir recursos en múltiples cuentas (Resource sharing)
Automatizar aprovisionamiento de múltiples cuentas mediante CloudFormation (Multi-account)

2. Service Control Policies (SCPs)

Es un tipo de política de AWS Organizations que permite restringir los permisos de las cuentas de AWS que pertenecen a la organización. Esta es una característica de AWS Organizations; existen otras políticas, pero nos centraremos en el tipo de servicio.

Estructura de una SCP

La estructura de una SCP es la siguiente:

Elementos principales de una SCP:

Elemento	¿Qué hace?
Statement	Es el contenedor principal de una política. Puedes tener varios statements en una SCP (cuidado: hay un límite de caracteres).
Effect	Define si el statement permite (`Allow`) o bloquea (`Deny`) acciones. Nota: `Allow` no permite condicionales.
Action	Especifica qué acciones de AWS se permiten o bloquean (ej: `s3:PutObject`).
Resource	Indica a qué recursos de AWS aplica la política (ej: un bucket específico).
Condition	(Opcional) Agrega condiciones para que el statement aplique solo en ciertos casos.
NotAction	Lo opuesto a `Action`: especifica acciones que quedan exentas de la SCP.
NotResource	Lo opuesto a `Resource`: especifica recursos que quedan exentos de la SCP.
Sid	(Opcional) Un nombre amigable para identificar el statement.
Version	Define la versión del lenguaje de políticas (siempre usa `"2012-10-17"`).

Comportamiento de una SCP

Para entender mejor cómo funcionan las SCPs, podemos agrupar sus comportamientos en cuatro categorías clave:

1. Principios Básicos

Naturaleza: No otorgan permisos, solo los restringen.
Evaluación: Un permiso solo se ejecuta si existe una política IAM que lo permita y una SCP que lo permita o no lo deniegue, en el caso de evaluación IAM y SCP. La evaluación final se encuentra en la documentación oficial de AWS.

2. Alcance: ¿A quién afecta?

Cuentas Miembro: Las SCPs restringen los permisos de todos los usuarios y roles, incluido el usuario root.
Administradores Delegados: Sí están afectados, ya que residen en cuentas miembro.
Excepción Clave: La Cuenta de Administración (Management Account) NO se ve afectada por las SCPs.

3. Interacción con otras Políticas

IAM Deny: Siempre tiene prioridad sobre cualquier SCP.
SCP Deny: Bloquea la acción explícitamente, incluso si IAM otorga AdministratorAccess.
Permission Boundaries: La evaluación final requiere: IAM Allow + SCP Allow + Boundary Allow.

4. Excepciones Técnicas

Service-Linked Roles: No se pueden restringir con SCPs, ya que son necesarios para que los servicios de AWS funcionen correctamente.
Resource-Based Policies: No se ven afectadas por SCPs; los accesos externos a recursos (como un bucket S3) siguen funcionando si la política del recurso lo permite.
Usuarios Externos: No se ven afectados, incluso si acceden a recursos dentro de una cuenta restringida.

¿Dónde se aplican las SCPs?

En AWS Organizations, las SCPs se aplican a las cuentas de AWS que pertenecen a la organización y también a las unidades organizativas. Una unidad organizativa es como un folder donde puedes agrupar cuentas de AWS.

A continuación una vista de una jerarquía de organización en AWS Organizations:

Componentes de una jerarquía de organización:

Cuenta raíz (Root): Es la cuenta principal de la organización, generalmente la cuenta de AWS que se creó al crear la organización. Importante: Aplicar una SCP a la cuenta raíz afecta a todas las cuentas de la organización sin excepción (mucho cuidado con esto).
Unidades organizativas (OUs): Son como folders donde puedes agrupar cuentas de AWS. Aplicar una SCP a una OU afecta a todas las cuentas que pertenecen a la OU.
Cuentas: Son las cuentas de AWS que pertenecen a la organización. Aplicar una SCP a una cuenta afecta solo a esa cuenta.

Nota: Las SCPs pueden aplicarse a múltiples cuentas por su característica de herencia.

3. Laboratorio: Creación de SCPs

Costo del laboratorio: $0

⚠️ Advertencia: Nunca debes aplicar una SCP a la cuenta productiva ni a un entorno con cuentas productivas. Siempre usa cuentas de prueba para validar el funcionamiento de la SCP antes de aplicarlo en múltiples cuentas.

A. Armando el laboratorio para probar SCPs

🔐 Requisitos previos

Tener una cuenta AWS principal (payer) desde la cual crearás la Organización.
Tener acceso administrativo a esa cuenta.
No necesitas método de pago adicional para la segunda cuenta.

✅ Paso 1: Crear una Organización en AWS (si aún no está creada)

1.1. Ingresa a la cuenta administradora (payer/root) de AWS.

1.2. Ve al servicio AWS Organizations.

1.3. Si todavía no tienes una organización:

Haz clic en Create Organization.
Confirmar creación de la organización.

🎉 Ahora tienes la capacidad de usar SCPs.

✅ Paso 2: Crear una Unidad Organizativa (OU) para pruebas

Las OU te ayudarán a aislar y probar SCPs sin afectar nada productivo o importante.

2.1. En AWS Organizations, ve a AWS accounts.

2.2. Selecciona la OU raíz (root) y haz clic en Actions.

2.3. Clic en Create new organizational unit (OU).

2.4. Pon un nombre claro (ej: lab-scp-test) y acepta.

✅ Paso 3: Crear una cuenta miembro dentro de la OU

Crearás una segunda cuenta AWS desde la cuenta administradora. Esta cuenta será tu "cuenta de pruebas" donde validarás las SCPs.

3.1. Desde AWS Organizations, ve a AWS Accounts → Add an AWS account → Create an AWS account.

3.2. Rellena:

Account name: lab-scp-member (o el nombre de tu elección, puedes cambiar el nombre a futuro)
Email address: Te aconsejo usar tu correo con el que creaste la cuenta administradora, pero con un alias de la siguiente manera:
```
 <tuemail_sin_@gmail.com>+labscp@gmail.com
```
Ejemplo: Si tu correo es pepito@gmail.com, tu segunda cuenta deberá ser: pepito+labscp@gmail.com

3.3. Clic en Create an AWS account.

✅ Paso 4: Mover la cuenta a la OU creada

4.1. Selecciona la cuenta, clic en Actions → Move AWS account.

4.2. Elige la OU creada.

4.3. Clic en Move AWS account.

🔹 Configuración inicial de la cuenta miembro

AWS enviará un correo para activar la cuenta. Necesitarás entrar a la cuenta para probar las SCPs. Para el primer ingreso lo harás con la cuenta root (podrías generar un ingreso mediante IAM Identity Center, pero se verá en otro artículo) y harás un reset de contraseña. Procura seguir las buenas prácticas de seguridad colocando MFA y una contraseña fuerte.

Adicionalmente, necesitarás crear un usuario IAM con permisos de administrador, solo con propósitos de prueba, ya que no usaremos la root.

Guía para crear un usuario IAM: https://docs.aws.amazon.com/es_es/IAM/latest/UserGuide/id_users_create.html

Luego de crear el usuario IAM, procederás a ingresar a la cuenta miembro con el usuario IAM creado para realizar las pruebas de SCPs. Recuerda: es solo para pruebas. Las SCPs solo se adjuntarán y crearán en la cuenta administradora de la organización; no podrás ver la organización desde la cuenta miembro.

B. Creación de SCPs

✅ Paso 1: Acceder a AWS Organizations

1.1. Desde la consola de AWS, busca y selecciona Organizations.

1.2. Asegúrate de estar en la cuenta raíz de la organización o en una cuenta con permisos de administración de la organización.

✅ Paso 2: Crear la SCP

2.1. En el menú lateral, selecciona Policies → Service control policies.

2.2. Haz clic en Create policy.

2.3. Ingresa un nombre y descripción para tu política.

2.4. Define el contenido de la política en formato JSON (ver ejemplos más adelante).

C. Vincular política SCP a una OU o cuenta

✅ Paso 1: Vincular SCP a la OU de pruebas

1.1. En AWS Organizations → AWS accounts, selecciona la OU objetivo, cuenta o folder raíz.

1.2. Haz clic en Policies → Service control policies → Attach.

1.3. Selecciona la SCP creada y haz clic en Attach policy.

D. Prueba de SCP

1.1. Ve a la cuenta miembro (cuenta de pruebas).

1.2. Accede con el usuario IAM creado.

1.3. Intenta realizar la acción que se definió en la SCP.

4. Ejemplos de SCP para control de recursos en AWS

Nos basamos en una organización con estructura de OUs y cuentas de prueba, donde puedes aplicar estas SCPs para validar su funcionamiento.

Ejemplo de jerarquía organizativa:

Root
└── OU: <root-ou>
    ├── Development
    │   ├── Sandbox Dev 01 (Cuenta)
    │   └── <deepracer-aft1> (Cuenta)
    ├── Management
    │   └── Administrator (Cuenta de administración)
    ├── Network
    │   └── Networking (Cuenta)
    └── Security
        ├── Audit (Cuenta)
        └── Log Archive (Cuenta)

Nota: Estas SCPs se pueden aplicar a la OU raíz, a una OU específica o a cuentas individuales, según el alcance que necesites. Recuerda que las denegaciones prevalecen y no se aplican a la cuenta administradora.

1️⃣ Denegar creación de buckets S3

Evita que cualquier cuenta cree buckets S3:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DenyS3BucketCreation",
            "Effect": "Deny",
            "Action": "s3:CreateBucket",
            "Resource": "*"
        }
    ]
}

Aplicación: Colocar en la OU raíz para afectar a todas las cuentas de prueba, bloqueando la creación de buckets S3.

2️⃣ Restringir regiones de despliegue en las cuentas de Development

Evita que se utilicen regiones distintas a la permitida, dejando accesibles solo ciertos servicios esenciales:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Deny",
            "NotAction": [
                "budgets:*",
                "cloudfront:*",
                "config:*",
                "ec2:DescribeRegions",
                "ec2:DescribeTransitGateways",
                "ec2:DescribeVpnGateways",
                "iam:*",
                "networkmanager:*",
                "organizations:*",
                "route53:*",
                "s3:*",
                "shield:*",
                "sts:*",
                "support:*",
                "trustedadvisor:*",
                "waf:*"
            ],
            "Resource": "*",
            "Condition": {
                "StringNotEquals": {
                    "aws:RequestedRegion": [
                        "${REGION_NAME}"
                    ]
                }
            }
        }
    ]
}

Reemplaza ${REGION_NAME} por la región autorizada (ejemplo: "us-east-1").

Aplicación: Útil para controlar costos y garantizar que recursos solo se desplieguen en regiones aprobadas. Dado que mencionan el alcance hacia las cuentas Development se vinculara a la OU Development que es el folder de esas cuentas.

descripcion: En este caso se uso de NotAction para no afectar ciertos servicios de alcanza global, en este caso servicios como budgets, cloudfront, config, iam, networkmanager, organizations, route53, s3, shield, sts, support, trustedadvisor, waf no se veran afectados pero los demas si.

3️⃣ Restringir tipos de instancias RDS

Evita que se creen instancias RDS que no correspondan a un tipo aprobado:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DenyUnapprovedRDSTypes",
            "Effect": "Deny",
            "Action": "rds:CreateDBInstance",
            "Resource": "*",
            "Condition": {
                "StringNotEquals": {
                    "rds:DatabaseClass": "${INSTANCEDBTYPE}"
                }
            }
        }
    ]
}

Reemplaza ${INSTANCEDBTYPE} por el tipo de instancia aprobado (ejemplo: "db.t3.medium").

Aplicación: Garantiza estándares de arquitectura y control de costos en RDS.

4️⃣ Denegar escritura en buckets S3 fuera de la organización

Evita que cualquier cuenta escriba en buckets S3 que no pertenezcan a la organización:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DenyS3WritesToUnauthorizedBuckets",
            "Effect": "Deny",
            "Action": [
                "s3:Put*"
            ],
            "Resource": "*",
            "Condition": {
                "StringNotEquals": {
                    "aws:ResourceOrgID": "[O-XXXXX]"
                }
            }
        }
    ]
}

Reemplaza [O-XXXXX] por el ID de tu organización.

Aplicación: Útil para prevenir que los datos se escriban fuera de los buckets gestionados por tu organización, reforzando la seguridad y gobernanza de S3.

5. SCPs que toda cuenta debería tener

No existen SCPs que toda cuenta debería tener de forma universal, ya que cada organización tiene sus propias necesidades y requisitos. Sin embargo, bajo un modelo de seguridad básico, considero que las cuentas deberían tener al menos las siguientes SCPs:

🔐 5.1. Denegar la utilización de cuentas ROOT

Descripción: Evita que se realicen acciones críticas usando la cuenta raíz de AWS.

Beneficio: Protege la cuenta administrativa principal de accesos accidentales o maliciosos.

🚪 5.2. Denegar la acción de salir de la organización

Descripción: Impide que las cuentas miembros abandonen la organización.

Beneficio: Mantiene la gobernanza centralizada y evita pérdidas de control sobre cuentas.

👤 5.3. Denegar acciones en IAM que no sean usuarios y roles específicos

Descripción: Restringe la creación o modificación de políticas, roles y permisos que no estén permitidos.

Beneficio: Evita escalación de privilegios no controlada y mantiene la seguridad de la identidad.

🌍 5.4. Denegar regiones no utilizadas en la organización

Descripción: Bloquea la creación de recursos fuera de las regiones aprobadas.

Beneficio: Controla costos y asegura consistencia operativa en regiones autorizadas.

📝 5.5. Denegar borrado y modificación de registros específicos

Descripción: Protege logs críticos de CloudTrail, Config u otros registros importantes.

Beneficio: Garantiza trazabilidad y cumplimiento normativo.

🗄️ 5.6. Denegar borrado de buckets donde se guardan registros de auditoría

Descripción: Impide que se eliminen buckets S3 usados para almacenar logs de auditoría.

Beneficio: Asegura la integridad de los registros y evidencia de auditoría.

💰 5.7. Denegar servicios con alto coste no útiles para la organización

Descripción: Bloquea servicios como Redshift, SageMaker u otros que no estén aprobados.

Beneficio: Evita gastos innecesarios y recursos no autorizados.

Aunque muchas de estas SCPs están enfocadas principalmente en gobernanza y control, también actúan como capas adicionales de seguridad, creando barreras que protegen la organización de errores, mal uso o accesos no deseados.

6. Conclusión

Las Service Control Policies (SCPs) son una herramienta fundamental para establecer guardrails de seguridad, cumplimiento y gobernanza en AWS Organizations. A través de este artículo hemos aprendido:

Qué son las SCPs y cómo se diferencian de las políticas IAM tradicionales
Cómo funcionan y a quién afectan dentro de la organización
Dónde aplicarlas en la jerarquía organizativa
Cómo crear un laboratorio de pruebas sin costo para validar SCPs
Ejemplos prácticos de políticas comunes para controlar recursos
Recomendaciones básicas de SCPs que toda organización debería considerar

Recuerda siempre probar tus SCPs en entornos de prueba antes de aplicarlas en producción, ya que una política mal configurada puede bloquear operaciones críticas. Las SCPs son restrictivas por naturaleza: no otorgan permisos, solo los limitan.

Con una implementación cuidadosa, las SCPs te permitirán mantener el control centralizado de tu entorno multi-cuenta, reducir riesgos de seguridad y optimizar costos operativos.

7. Bonus RedTeam

Hemos hablado bastante de SCPs, pero ahora comprendes que tan importante es la management account para controlar todo el entorno. Si alguien tiene acceso no autorizado a la management account es lo mas peligroso que puede pasar, como recordaras estan excentas de las SCPs y puedes tomar acciones en las cuentas miembros desde crearlas, cerrarlas o expulsarlas de la organización. AWS organizations no es solo politicas de organización, es un servicio que integra muchos otro servicio de seguridad que veremos mas adelante.

8. Pregunta de reflexión final

¿Qué tan seguro crees que es tu entorno multi-cuenta? ¿Qué medidas adicionales consideras importantes para mejorar la seguridad de tu organización?

🚀 ¡Ahora es tu turno de implementar SCPs en tu organización!

9. Documentación y Referencias

AWS Policy Deep Dive

Terry Quispe Paniagua — Sun, 23 Nov 2025 23:37:11 +0000

Parte 1: ¿Crees que tus datos están seguros solo con IAM? Hablemos de SCPs y RCPs.

🛡️ La seguridad en la nube requiere una estrategia de defensa en profundidad. 🛡️
Cuando empecé en AWS, pensaba que con IAM bastaba. Pero al profundizar, me di cuenta de la importancia de capas adicionales como las SCPs y RCPs.

Entender la diferencia entre Identidad, Recurso y Control Organizacional es vital para proteger nuestros entornos. No es solo "dar permisos", es saber dónde aplicarlos para garantizar el menor privilegio y la máxima seguridad.

Aquí les comparto mi guía mental para no perderse y saber identificar cuando podemos o debemos usar cada una de estas.

1️⃣ Identity-based Policies (IAM Policies)

👉 El "Quién puede hacer qué" Son las más comunes. Se adjuntan a Usuarios, Grupos o Roles.
📝 Ejemplo: Un usuario de operaciones necesita iniciar o detener instancias EC2s, pero no puede crear, terminar ni modificar instancias.

Acción: Crear una Policy que permita ec2:StartInstances y ec2:StopInstances en la tabla de "Productos".
Resultado: Si intenta modificar o eliminar la instancia, AWS le dice "No".

2️⃣ Resource-based Policies

👉 El "Quién puede tocar ESTO" Aquí la regla vive en el recurso mismo (S3 Bucket, SQS, KMS Key), no en el usuario. Son vitales para accesos Cross-Account pero no restringidos a ellos. 📝 Ejemplo: Tienes un Bucket S3 de logs centralizados.

Acción: Colocas una Bucket Policy que dice: "Permitir s3:PutObject a la cuenta de Producción (Account B)".
Resultado: La cuenta B puede escribir logs ahí sin tener un usuario creado en tu cuenta de logs.

3️⃣ Service Control Policies (SCPs)

👉 Las "Reglas de la Casa" (Límites de Identidad, popularmente guardrail o barandilla de seguridad) Aquí es donde muchos se confunden. Las SCPs NO dan permisos. Solo definen el máximo permiso posible. Si la SCP dice "No", no importa si tienes AdminAccess, es un "No". 📝 Ejemplo: Seguridad Compliance.

Acción: Aplicas una SCP en la raíz de tu Organización que niega ec2:RunInstances en cualquier región que no sea us-east-1.

- Resultado: Aunque seas Admin, si intentas levantar un servidor en Tokyo, fallará.

Resource Control Policies (RCPs)

👉 El "Perímetro de Datos" (Límites de Recurso) Funcionan como las SCPs, pero enfocadas en restringir el acceso a tus recursos, sin importar quién sea el que llama (incluso si es externo). 📝 Ejemplo: Data Perimeter estricto.

Acción: Creas una RCP que dice: "Nuestros Buckets S3 solo pueden ser accedidos por Principals que pertenezcan a nuestra Organización (PrincipalOrgID)".
Resultado: Si alguien configura por error un Bucket como "Público" o intenta darle acceso a una cuenta externa de un proveedor, la RCP lo bloquea automáticamente. Ideal para prevenir ataques de exfiltración de datos

Resumen

Tipo de Política	Se aplica a...	Función Principal	¿Cuándo usarlo?
IAM Policy	Usuario/Rol/Grupo	Otorgar permisos	Para otorgar permisos a usuarios, grupos o roles
Resource Policy	S3, SQS, etc.	Otorgar acceso (incluso externo)	Para definir quien puede acceder a un recurso
SCP	Cuenta AWS (excepto cuenta administradora de la organización), Unidades Org	Restringir permisos máximos (Identidad)	Para establecer límites máximos sobre las identidades
RCP	Recursos de la Org, excepto recursos de la cuenta administradora de la organización	Restringir acceso máximo (Recurso)	Para establecer límites máximos sobre sobre quien accede a tus datos

🔥 Bonus: Perspectiva Red Team

Entender IAM, SCPs y RCPs no solo es vital para proteger tu cuenta y organización, también es un componente clave para reducir la superficie de ataque.

Por ejemplo:

Escenario de Red Team: un atacante intenta asumir roles o crear usuarios para escalar privilegios.
SCPs bloquean el movimiento lateral: aunque tenga AdminAccess en una cuenta hija, no podrá ejecutar acciones prohibidas por la SCP a nivel de Organización (ej: organizations:LeaveOrganization, iam:CreateUser).
RCPs evitan exfiltración de datos: un bucket mal configurado no permite accesos de cuentas externas aunque el atacante tenga privilegios en otra parte.
Conclusión: conocer y aplicar correctamente estas políticas es como poner murallas antes de que alguien llegue al nucleo de tu entorno.

💡 Pregunta de reflexión: ¿por qué es un riesgo crítico desplegar recursos productivos o mantener usuarios activos operando directamente en la cuenta administradora de la organización o también llamado Payer Account?

🔜 En el próximo post: Profundizaremos en las SCPs, cuales son las SCPs mas relevantes que toda cuenta debería tener y cómo configurarlas correctamente para dormir tranquilos.

DEV Community: Terry Quispe Paniagua

🛡️ AWS IAM Access Analyzer — Parte 4/4

Antes del lab: External vs Internal vs Unused Access

El laboratorio

¿Cuánto cuesta Unused Access Analyzer?

Después de una semana: 18 findings

Finding 1: un role realmente abandonado

Finding 2: también aparecieron roles de IAM Identity Center

Finding 3: una contraseña que sigue existiendo pero ya no se usa

Finding 4: acá está la diferencia real con Last activity

Entonces, ¿qué aporta si IAM ya muestra Last activity?

Algo que observé: los findings no aparecieron todos al mismo tiempo

Limitaciones que conviene conocer

Del finding a una policy de mínimo privilegio

¿Lo habilitaría en producción?

Conclusión

Referencias

AWS #IAM #AccessAnalyzer #CloudSecurity #LeastPrivilege #AWSOrganizations #DevSecOps #IAMSecurity

AWS IAM Access Analyzer Internal Access: Effective Permissions, SCPs, RCPs, and an Unexpected Finding

Real-world demo: effective permissions, SCPs, RCPs, and a comparison that did not go as expected

Lab: validating cross-account access within the same AWS Organization using IAM Access Analyzer Internal Access

Architecture

Objective

Step 1: Create the roles in Account B

Step 2: Assign IAM permissions to the roles

Step 2.1: Add a permissions boundary to RoleAdmin

Step 3: Configure the bucket policy in Account A

Step 4: Create the SCP in AWS Organizations

Step 4.1: Add an RCP for the bucket

Step 5: Create the IAM Access Analyzer Internal Access analyzer

Before testing: a quick summary of what each layer does

Step 6: Test access by assuming the roles

Test with RoleReadOnly

Test with RoleAdmin

Specific test to validate the permissions boundary

Additional tests: explicit actions compared with s3:*

View the findings in IAM Access Analyzer

What the findings list shows

View the details of a finding

What this demonstrates about the SCP, RCP, and permissions boundary

Why other roles appear in addition to the lab roles

What the Archive button does

Lab results

What this lab demonstrates

Before enabling it in production: pricing

Red Team perspective

What Access Analyzer shows—and what it does not

Conclusion

🛡️ AWS IAM Access Analyzer — Parte 3/4

Demo real: permisos efectivos, SCPs, RCPs y una comparación que no salió como esperaba

Lab: validando acceso cross-account dentro de la misma AWS Organization con IAM Access Analyzer Internal Access

Arquitectura

Objetivo

Paso 1: Crear los roles en la Cuenta B

Paso 2: Asignar permisos IAM a los roles

Paso 2.1: Añadir permissions boundary a RoleAdmin

Paso 3: Configurar la bucket policy en la Cuenta A

En la cuenta real también quedó una entrada anterior para RolePowerUser. No la utilicé en la comparación final porque los cuatro roles anteriores ya cubrían los casos que necesitaba aislar.

Paso 4: Crear la SCP en AWS Organizations

Paso 4.1: Añadir una RCP sobre el bucket

Paso 5: Crear el IAM Access Analyzer Internal Access

Antes de las pruebas: resumen rápido de qué hace cada capa

Paso 6: Probar acceso asumiendo los roles

Prueba con RoleReadOnly

Prueba con RoleAdmin

Prueba específica para validar el permissions boundary

Pruebas adicionales: acciones explícitas frente a s3:*

Ver los findings en IAM Access Analyzer

Qué muestra la lista de findings

Ver el detalle de un finding

Qué demuestra esto sobre la SCP, la RCP y el permissions boundary

Por qué aparecen otros roles aparte de los del lab

El botón Archivar: para qué sirve

Resultados del laboratorio

Qué demuestra este lab

Antes de habilitarlo en producción: el pricing

Perspectiva Red Team

Lo que Access Analyzer muestra (y lo que no)

Conclusión

AWS #CloudSecurity #IAM #AccessAnalyzer #SCPs #RCPs #PermissionsBoundary #CloudGovernance #AWSOrganizations #LeastPrivilege #RedTeam

Finding 4: acá está la diferencia real con `Last activity`

Entonces, ¿qué aporta si IAM ya muestra `Last activity`?

Test with `RoleReadOnly`

Test with `RoleAdmin`

Additional tests: explicit actions compared with `s3:*`

En la cuenta real también quedó una entrada anterior para `RolePowerUser`. No la utilicé en la comparación final porque los cuatro roles anteriores ya cubrían los casos que necesitaba aislar.

Prueba con `RoleReadOnly`

Prueba con `RoleAdmin`

Pruebas adicionales: acciones explícitas frente a `s3:*`