DEV Community

Cover image for 🛡️ AWS IAM Access Analyzer — Parte 2/4
Terry Quispe Paniagua
Terry Quispe Paniagua

Posted on • Edited on

🛡️ AWS IAM Access Analyzer — Parte 2/4

#aws #iam #tutorial #cybersecurity

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:

  1. Frecuente en la práctica: los findings externos más comunes suelen involucrar buckets con políticas demasiado abiertas.
  2. 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.
  3. Finding detallado: muestra el recurso, el principal externo, cómo se compartió y el nivel de acceso.
  4. 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
Enter fullscreen mode Exit fullscreen mode

Menú de IAM en la consola de AWS con la opción Access Analyzer resaltada

Configuración del lab:

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

Formulario de creación de un External Access Analyzer con zona de confianza configurada como 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.

Lista de findings activos en External Access Analyzer con filtro Public access false aplicado

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>
Enter fullscreen mode Exit fullscreen mode

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"
        }
    }
}
Enter fullscreen mode Exit fullscreen mode

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.

Detalle de un finding de rol SSO gestionado por IAM Identity Center con nivel de acceso Write y Tagging

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
Enter fullscreen mode Exit fullscreen mode

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.

Detalle de un finding de rol IAM con trust cross-account hacia una cuenta externa

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
Enter fullscreen mode Exit fullscreen mode

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.

Detalle de un finding de federación SAML con proveedor GoogleWorkspace

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
Enter fullscreen mode Exit fullscreen mode

Detalle de un finding de rol IAM con trust policy hacia Cognito Identity

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"
    }
  }
}
Enter fullscreen mode Exit fullscreen mode

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.

Validación del rol cognito-testing con trust policy heredada hacia Cognito Identity Pools

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
Enter fullscreen mode Exit fullscreen mode

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.

Detalle de un finding de bucket S3 público con principal Todas las entidades principales

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
Enter fullscreen mode Exit fullscreen mode

Pantalla de creación de archive rule para archivar findings esperados de roles SSO

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

Resource contains "aws-reserved/sso.amazonaws.com/AWSReservedSSO_"
Enter fullscreen mode Exit fullscreen mode

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:

  1. Activar el analyzer.
  2. Revisar los findings.
  3. Separar accesos esperados de accesos no documentados.
  4. Archivar lo intencional.
  5. 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

Top comments (0)