Dev.to Security 🔐 Cybersecurity Sat, 31 Oct 2026 21:50:17 +0000 👁 0 📖 7 min read

IAM Identity Center multi-Region con Identity Center directory: guía práctica con AWS CLI

Si tus usuarios viven en el directorio nativo de IAM Identity Center, desde julio de 2026 los podés replicar a otras regiones de AWS. En este post vamos directo a la práctica: todo el camino por AWS CLI, desde la KMS key

Si querés el contexto completo (qué se replica, qué no y por qué importa), lo escribí en este artículo de Medium.

Lo que vamos a armar

Este es el diagrama oficial de AWS para una arquitectura multi-Region con Identity Center. Fijate en dos cosas: la replicación de identidades de us-east-1 a us-west-2, y la KMS key multi-Region con su réplica en la región destino.

Diagrama oficial del AWS Big Data Blog, "Multi-Region identity-based access to Amazon Redshift and S3 Tables". En ese ejemplo la identidad viene de un IdP corporativo; con Identity Center directory, los usuarios se crean directamente en Identity Center y ese recuadro desaparece.

La parte analítica del diagrama (Redshift, Lake Formation) no la necesitamos. Lo que nos interesa es la columna de la izquierda: Identity Center, la KMS key y cómo ambos aparecen replicados en la otra región.

Antes de empezar

Chequeá esto o vas a chocar contra un error a mitad de camino:

Organization instance de IAM Identity Center (no funciona con account instances).
Identity source: Identity Center directory o IdP externo. Con Active Directory no está soportado.
Regiones soportadas: desde el 1 de octubre de 2026 el soporte se extendió a regiones opt-in, y a replicación dentro de GovCloud (US) y dentro de las regiones de China. Confirmá tu región primaria y la adicional en AWS Capabilities by Region.
Las apps de AWS que usás tienen que soportar Identity Center con customer managed key. Revisá la tabla de compatibilidad antes del paso 3.
Cuota: 6 regiones por instancia por defecto (se puede ampliar).

Con Identity Center directory no tenés que tocar ACS URLs ni ningún IdP externo. Ese paso existe solo para IdPs externos.

Paso 0: datos de tu instancia

aws sso-admin list-instances

De la salida guardá el ARN de la instancia:

export INSTANCE_ARN="arn:aws:sso:::instance/ssoins-1234567890abcdef"
export PRIMARY_REGION="us-east-1"
export DR_REGION="eu-west-1"

Paso 1: la key policy

La KMS key tiene que permitir que Identity Center e Identity Store la usen. AWS publica una baseline key policy; esta es la versión oficial, con los placeholders a reemplazar:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowIdentityCenterAdminAccounts",
      "Effect": "Allow",
      "Principal": {
        "AWS": [
          "arn:aws:iam::111122223333:root",
          "arn:aws:iam::444455556666:root"
        ]
      },
      "Action": "kms:*",
      "Resource": "*"
    },
    {
      "Sid": "AllowIdentityCenterAndIdentityStoreToDescribeKey",
      "Effect": "Allow",
      "Principal": {
        "Service": ["identitystore.amazonaws.com", "sso.amazonaws.com"]
      },
      "Action": "kms:DescribeKey",
      "Resource": "*",
      "Condition": {
        "StringEquals": { "aws:SourceAccount": "${aws:ResourceAccount}" }
      }
    },
    {
      "Sid": "AllowIdentityCenterAndIdentityStoreToUseKey",
      "Effect": "Allow",
      "Principal": {
        "Service": ["identitystore.amazonaws.com", "sso.amazonaws.com"]
      },
      "Action": [
        "kms:Decrypt",
        "kms:ReEncryptTo",
        "kms:ReEncryptFrom",
        "kms:GenerateDataKeyWithoutPlaintext"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": { "aws:SourceAccount": "${aws:ResourceAccount}" },
        "ForAnyValue:StringEquals": {
          "kms:EncryptionContextKeys": [
            "aws:sso:instance-arn",
            "aws:identitystore:identitystore-arn"
          ]
        }
      }
    },
    {
      "Sid": "AllowOrgPrincipalsViaIdentityCenterAndIdentityStore",
      "Effect": "Allow",
      "Principal": "*",
      "Action": "kms:Decrypt",
      "Resource": "*",
      "Condition": {
        "StringEquals": { "aws:PrincipalOrgID": "${aws:ResourceOrgID}" },
        "StringLike": {
          "kms:ViaService": ["sso.*.amazonaws.com", "identitystore.*.amazonaws.com"]
        },
        "ForAnyValue:StringEquals": {
          "kms:EncryptionContextKeys": [
            "aws:sso:instance-arn",
            "aws:identitystore:identitystore-arn"
          ]
        }
      }
    },
    {
      "Sid": "AllowManagedApps",
      "Effect": "Allow",
      "Principal": "*",
      "Action": "kms:Decrypt",
      "Resource": "*",
      "Condition": {
        "Bool": { "aws:PrincipalIsAWSService": "true" },
        "StringEquals": { "aws:SourceOrgID": "${aws:ResourceOrgID}" },
        "StringLike": {
          "kms:ViaService": ["identitystore.*.amazonaws.com", "sso.*.amazonaws.com"]
        },
        "ForAnyValue:StringEquals": {
          "kms:EncryptionContextKeys": [
            "aws:sso:instance-arn",
            "aws:identitystore:identitystore-arn"
          ]
        }
      }
    }
  ]
}

Guardala como key-policy.json y reemplazá:

111122223333: la cuenta de tu instancia de Identity Center (la management account de AWS Organizations).
444455556666: tu cuenta de administración delegada. Si no usás administración delegada, sacá ese principal.

Las variables ${aws:ResourceAccount} y ${aws:ResourceOrgID} van tal cual: las resuelve IAM.

Paso 2: crear la KMS key multi-Region

La key tiene que ser simétrica, de tipo "encrypt and decrypt", estar en la misma región que la instancia y en la misma management account. Y tiene que nacer multi-Region: una key single-Region no se puede convertir después.

aws kms create-key \
    --multi-region \
    --description "IAM Identity Center encryption at rest" \
    --policy file://key-policy.json \
    --region "$PRIMARY_REGION"

Las keys multi-Region tienen un ID que empieza con mrk-. Guardá el ARN:

export KEY_ARN="arn:aws:kms:us-east-1:111122223333:key/mrk-1234abcd12ab34cd56ef1234567890ab"

Paso 3: que Identity Center use tu key

Antes de este paso, revisá que las apps de AWS que usás soporten customer managed keys. Si alguna no lo soporta, no sigas.

aws sso-admin update-instance \
    --instance-arn "$INSTANCE_ARN" \
    --encryption-configuration \
        KeyType=CUSTOMER_MANAGED_KEY,KmsKeyArn="$KEY_ARN"

Dos cosas tranquilizadoras de la documentación: el cambio no afecta las sesiones activas, e Identity Center valida que puede cifrar y descifrar con la key. Si la policy está mal, te muestra el error y sigue usando la key anterior.

Y una que no lo es: si la key se borra, se deshabilita o la policy queda mal, ni tus usuarios ni tus admins van a poder usar Identity Center. Restringí quién puede deshabilitar o borrar la key, y tené un procedimiento de break-glass.

Paso 4: replicar la key a la región adicional

aws kms replicate-key \
    --key-id "$KEY_ARN" \
    --replica-region "$DR_REGION" \
    --policy file://key-policy.json \
    --region "$PRIMARY_REGION"

Uso la misma policy a propósito. AWS recomienda usar la misma policy en todas las réplicas para que la autorización sea consistente, y KMS no sincroniza las key policies entre regiones: si mañana cambiás la policy, la tenés que actualizar en cada región.

Paso 5: agregar la región en Identity Center

aws sso-admin add-region \
    --instance-arn "$INSTANCE_ARN" \
    --region-name "$DR_REGION"

Y consultá el estado hasta que figure ACTIVE:

aws sso-admin describe-region \
    --instance-arn "$INSTANCE_ARN" \
    --region-name "$DR_REGION"

La primera replicación tarda según el volumen de datos de tu instancia. Después, los cambios incrementales se replican en segundos en la mayoría de los casos.

Si preferís la consola: Settings → Management → Regions for IAM Identity Center → Add Region.

Captura oficial del AWS Security Blog: pestaña Management con la configuración de cifrado y las regiones.

Captura oficial del AWS Security Blog: replicación inicial en progreso.

Paso 6: probar el login en la región adicional

El portal de la región adicional tiene otra URL. Ni el d-xxxxxxxx.awsapps.com/start clásico ni tu custom alias existen ahí:

# IPv4, sin /start al final
https://ssoins-111111h2222j33pp.eu-west-1.portal.amazonaws.com

# Dual-stack, sin /start al final
https://ssoins-111111h2222j33pp.portal.eu-west-1.app.aws

La autorización de la CLI no se replica entre regiones, así que armá un perfil "DR" por cada perfil que ya tengas. En ~/.aws/config:

[sso-session corp-dr]
sso_start_url = https://ssoins-111111h2222j33pp.eu-west-1.portal.amazonaws.com
sso_region = eu-west-1

[profile prod-admin-dr]
sso_session = corp-dr
sso_account_id = 111122223333
sso_role_name = AdministratorAccess

Y probalo hoy, no el día del incidente:

aws sso login --profile prod-admin-dr
aws sts get-caller-identity --profile prod-admin-dr

Si el get-caller-identity te devuelve el rol esperado, el camino de failover funciona.

Lo que no vas a poder hacer desde la región adicional

Esto define tu runbook. Según la tabla oficial de APIs soportadas en regiones adicionales:

API	En regiones adicionales
Identity Store	Solo lectura
Identity Center	Lectura y escritura de aplicaciones; lectura de instancia, permission sets y asignaciones
OIDC	Todas las operaciones
Access Portal	Todas las operaciones
SCIM	Ninguna

En un failover, tu equipo entra con los permisos que ya estaban provisionados y replicados. No vas a poder crear usuarios ni asignar permission sets nuevos hasta que vuelva la primaria. Sí podés revocar sesiones desde la región adicional.

Checklist final

Key multi-Region creada con la baseline policy.
Identity Center usando la key (update-instance).
Key replicada con la misma policy.
Región agregada y en ACTIVE.
Allow-lists del firewall con los dominios del portal regional.
URL del portal regional comunicada al equipo.
Perfiles de CLI "DR" probados con sts get-caller-identity.
Break-glass definido y probado.

Fuentes

La explicación conceptual completa está en Medium. La versión en video corto está en YouTube, TikTok e Instagram, y el resumen en carrusel en LinkedIn.

━━━━━━━━━━━━━━━━━━━━
🟧 dev.luchops
Cloud & DevOps, explicado sin vueltas.

▸ Medium → medium.com/@lucianonicolasloyola
▸ YouTube → youtube.com/@dev.luchops
▸ TikTok / Instagram → @dev.luchops
━━━━━━━━━━━━━━━━━━━━

📰 Read the original article on Dev.to Security

Originally published by Dev.to Security. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.

← News 🔐 Cybersecurity 🏠 Home