# Delegación temporal de IAM para socios de AWS
## Descripción general
La delegación temporal de IAM permite a los clientes de AWS incorporar o integrar sin problemas los productos de los socios de AWS en su entorno de AWS mediante flujos de trabajo guiados e interactivos. Los clientes pueden conceder a los socios de AWS acceso temporal limitado para configurar los servicios de AWS necesarios, lo que reduce los problemas de incorporación y acelera el tiempo de obtención de valor.
La delegación temporal de IAM permite a los socios lo siguiente:
+ Optimizar la incorporación de clientes con el aprovisionamiento automatizado de recursos
+ Reducir la complejidad de la integración al eliminar los pasos de configuración manual
+ Generar confianza mediante permisos transparentes y aprobados por el cliente
+ Habilitar operaciones continuas con patrones de acceso a largo plazo utilizando límites de permisos
## Funcionamiento
1. *El socio crea una solicitud de delegación*: los socios crean una solicitud en la que especifican los permisos que necesitan y durante cuánto tiempo.
1. *El cliente la revisa en la Consola de AWS*: el cliente ve exactamente qué permisos solicita el socio y por qué.
1. *El cliente la aprueba*: el cliente aprueba la solicitud y libera un token de intercambio. El token se envía al socio en relación con este tema de SNS específico.
1. *El socio recibe credenciales temporales*: los socios intercambian el token por credenciales temporales de AWS.
1. *El socio configura los recursos*: los socios utilizan las credenciales para configurar los recursos necesarios en la cuenta del cliente.
## Calificación de los socios
Para calificar para la integración de la delegación temporal, el socio debe cumplir con los siguientes requisitos:
+ *Participación en ISV Accelerate*: debe estar inscrito en el programa [ISV Accelerate (ISVA)](https://aws.amazon.com/partners/programs/isv-accelerate/).
+ *Publicación de AWS Marketplace*: su producto debe estar publicado en AWS Marketplace con la insignia “Implementado en AWS”.
## Proceso de incorporación
Complete los siguientes pasos para integrar la delegación temporal en su producto:
1. *Paso 1: Revisar los requisitos*
Revise esta documentación para comprender los requisitos de calificación y complete el siguiente cuestionario para socios.
1. *Paso 2: Enviar la solicitud de incorporación*
Envíe un correo electrónico a aws-iam-partner-onboarding@amazon.com o póngase en contacto con su representante de AWS. Incluya el cuestionario para socios completado con todos los campos obligatorios de la siguiente tabla.
1. *Paso 3: Validación y revisión de AWS*
AWS:
+ Validará que cumple con los criterios de calificación.
+ Revisará las plantillas de políticas y los límites de permisos.
+ Proporcionará comentarios sobre los artefactos enviados.
1. *Paso 4: Refinar las políticas*
Responda a los comentarios de AWS y envíe plantillas de políticas actualizadas o límites de permisos según sea necesario.
1. *Paso 5: Completar el registro*
Tras la aprobación, AWS:
+ Habilitará el acceso a la API para las cuentas especificadas.
+ Compartirá los ARN de su plantilla de política y el límite de permisos (si corresponde).
Recibirá una confirmación cuando se complete la incorporación. A continuación, podrá acceder a las API de delegación temporal, CreateDelegationRequest y GetDelegatedAccessToken, desde sus cuentas registradas y empezar a integrar los flujos de trabajo de las solicitudes de delegación en su producto.
## Cuestionario para socios
En la siguiente tabla se muestra la información necesaria para la incorporación de los socios:
| Información | Descripción | Obligatorio |
| --- | --- | --- |
| ID de cuenta del Centro de socios | ID de su cuenta de AWS registrada en el [Centro de socios de AWS](https://partnercentral.awspartner.com/partnercentral2/s/login). | Sí |
| PartnerId | ID de socio proporcionado por el [Centro de socios de AWS](https://partnercentral.awspartner.com/partnercentral2/s/login). | No |
| ID de producto de AWS Marketplace | ID de su producto proporcionado por el [Centro de socios de AWS](https://partnercentral.awspartner.com/partnercentral2/s/login). | Sí |
| ID de cuentas de AWS | Lista de los ID de sus cuentas de AWS que desea utilizar para llamar a las API de delegación temporal. Esto debería incluir sus cuentas de producción y de no producción/prueba. | Sí |
| Nombre del socio | Este nombre se muestra a los clientes en la Consola de administración de AWS cuando revisan su solicitud de delegación temporal. | Sí |
| Correos electrónicos de contacto | Una o varias direcciones de correo electrónico que podemos utilizar para ponernos en contacto con usted acerca de su integración. | Sí |
| Dominio del solicitante | Su dominio (por ejemplo, www.ejemplo.com). | Sí |
| Descripción de integración | Breve descripción del caso de uso que quiere abordar con esta característica. Puede incluir enlaces de referencia a su documentación u otro material público. | Sí |
| Diagrama de arquitectura | Diagrama de arquitectura que ilustra los casos de uso de la integración. | No |
| Plantilla de política | Debe registrar al menos una plantilla de políticas para esta característica. La plantilla de política define los permisos temporales que desea solicitar en las cuentas de AWS de los clientes. Para obtener más información, consulte la sección Plantilla de política. | Sí |
| Nombre de la plantilla de política | Nombre de la plantilla de política que desea registrar. | Sí |
| Límite de permisos | Si desea crear roles de IAM en las cuentas de los clientes mediante permisos temporales, debe registrar un límite de permisos en IAM. Los límites de permisos se adjuntarán a los roles de IAM que cree para limitar los permisos máximos del rol. Puede usar determinadas políticas administradas de AWS como límite de permisos o registrar un nuevo límite de permisos personalizado (JSON). Para obtener más información, consulte la sección Límites de permisos. | No |
| Nombre del límite de permisos | Nombre de su límite de permisos. El formato es arn:aws:iam::partner:policy/permission\$1boundary//\$1. El nombre de la política debe incluir la fecha de creación como sufijo. El nombre no se puede actualizar una vez creado el límite de permisos. Si utiliza una política administrada de AWS existente, proporcione el ARN de la política administrada en su lugar. | No |
| Descripción del límite de permisos | Descripción de su límite de permisos. La descripción no se puede actualizar una vez creado el límite de permisos. | No |
# Descripción de la integración
Tras completar el proceso de incorporación, puede crear su integración con la delegación temporal de IAM. Una integración completa suele implicar tres categorías principales de trabajo:
## 1. Diseño del flujo de trabajo y la experiencia de usuario
Cree una experiencia de frontend en la aplicación del socio que guíe a los clientes a través del flujo de trabajo de la delegación temporal. La aplicación del socio debe:
+ Presentar un flujo claro de incorporación o configuración en el que los clientes puedan conceder acceso temporal. Etiquete esta acción de forma clara, como “Implementar con delegación temporal de IAM”.
+ Redirigir a los clientes a la Consola de administración de AWS para revisar y aprobar la solicitud de delegación mediante el enlace de la consola devuelto por la API CreateDelegationRequest
+ Proporcionar los mensajes adecuados sobre los permisos que se solicitan y por qué. Los clientes pueden ver este mensaje en la página de detalles de la solicitud de delegación.
+ Gestionar la devolución del cliente a su aplicación una vez que haya completado la aprobación en AWS.
## 2. Integración de la API
Utilice las API de delegación temporal de IAM para enviar y administrar las solicitudes de delegación. Cuando sus cuentas de AWS estén registradas, podrá acceder a las siguientes API:
+ *IAM CreateDelegationRequest*: crea una solicitud de delegación para la cuenta de AWS de un cliente. Esta API devuelve un enlace de la consola al que redirige a los clientes para que revisen y aprueben la solicitud.
+ *AWS STS GetDelegatedAccessToken*: recupera las credenciales temporales de AWS después de que un cliente apruebe su solicitud de delegación. Utilice estas credenciales para llevar a cabo acciones en la cuenta del cliente.
Su integración debe gestionar todo el ciclo de vida de las solicitudes de delegación, incluida la creación de las solicitudes, la supervisión de su estado y la recuperación de las credenciales temporales una vez aprobadas.
## 3. Configuración y orquestación de los recursos
Cuando obtenga las credenciales temporales, orqueste los flujos de trabajo necesarios para configurar los recursos en la cuenta de AWS del cliente. Esto puede incluir lo siguiente:
+ Llamar directamente a las API de servicios de AWS para crear y configurar recursos
+ Implementar la infraestructura mediante plantillas de AWS CloudFormation
+ Crear roles de IAM para el acceso continuo (requiere usar límites de permisos)
Su lógica de orquestación debe ser idempotente y gestionar los errores sin problemas, ya que es posible que los clientes tengan que volver a intentarlo o modificar sus aprobaciones de delegación.
# Descripción de los permisos
Como parte del proceso de incorporación de características, tendrá que registrar en IAM las políticas que definan los permisos que desea solicitar en las cuentas de AWS de los clientes. El proceso de registro proporciona una experiencia más coherente a los clientes y ayuda a evitar las dificultades habituales en la creación de políticas.
Durante el registro, AWS evalúa sus políticas comparándolas con un conjunto de validaciones. Estas validaciones tienen por objeto estandarizar el formato y la estructura de las políticas y proporcionar protecciones básicas contra los antipatrones conocidos. Las validaciones también reducen el riesgo de escalada de privilegios, el acceso entre cuentas no deseado y el acceso generalizado a recursos de gran valor de las cuentas de los clientes.
## Tipos de permisos
AWS considerará dos categorías de permisos: temporales y a largo plazo.
### Permisos temporales
Los permisos temporales limitan los permisos asignados a cualquier sesión de acceso delegado temporal. Los permisos temporales se describen en las plantillas de políticas que se aplican a la sesión delegada. Las plantillas admiten los parámetros que se proporcionan al crear una solicitud de delegación. A continuación, los valores de estos parámetros se enlazan a la sesión. Los permisos temporales funcionan de la misma manera que las políticas de sesión disponibles en AWS STS en la actualidad: las políticas limitan la capacidad del usuario subyacente, pero no otorgan ningún acceso adicional. Para obtener más información, consulte la documentación de AWS STS sobre las políticas de sesión.
### Permisos a largo plazo
Los permisos a largo plazo limitan los permisos de cualquier rol que se cree o administre mediante el acceso temporal. Los permisos a largo plazo se implementan como límites de permisos de IAM. Puede enviar uno o más límites de permisos a AWS como parte de la incorporación. Tras la aprobación, AWS le compartirá el ARN de una política al que podrá hacer referencia en sus políticas.
Estas políticas de límites tienen dos características importantes. En primer lugar, son inmutables. Si desea actualizar los permisos, puede registrar un nuevo límite de permisos. A continuación, puede adjuntar el nuevo límite de permisos a los roles de sus clientes; para ello, envíe una nueva solicitud de delegación. En segundo lugar, las políticas no tienen plantillas. Dado que la misma política de límites se comparte a nivel mundial, no pueden modificarse según el cliente.
**importante**
Los límites de permisos tienen un límite de tamaño máximo de 6144 caracteres.
**nota**
Si desea actualizar un límite de permisos o una plantilla de política, póngase en contacto con IAM en aws-iam-partner-onboarding@amazon.com. Una vez registrado el nuevo límite de permisos, puede enviar una solicitud de delegación a los clientes para que actualicen el rol de IAM y adjunten el límite de permisos recién registrado. Consulte la sección Ejemplos para obtener más información.
## Caso de uso de ejemplo: carga de trabajo de procesamiento de datos
Pensemos en un proveedor de productos que ejecuta una carga de trabajo de procesamiento de datos en las cuentas de los clientes. El proveedor necesita configurar la infraestructura durante la incorporación inicial, pero también requiere acceso continuo para gestionar la carga de trabajo.
*Permisos temporales (para la configuración inicial):*
+ Crear instancias de Amazon EC2, VPC y grupos de seguridad
+ Crear un bucket de Amazon S3 para los datos procesados
+ Crear un rol de IAM para las operaciones en curso
+ Adjuntar un límite de permisos al rol de IAM
*Permisos a largo plazo (rol de IAM con límite de permisos para las operaciones en curso):*
+ Iniciar y detener instancias de Amazon EC2 para ejecutar trabajos de procesamiento
+ Leer los datos de entrada de un bucket de Amazon S3
+ Escribir los resultados procesados en un bucket de Amazon S3
Los permisos temporales se utilizan una vez durante la incorporación para configurar la infraestructura. El rol de IAM creado durante este proceso tiene un límite de permisos que limita sus permisos máximos solo a las operaciones necesarias para la administración continua de la carga de trabajo. Esto garantiza que, incluso si se modifican las políticas del rol, no pueda superar los permisos definidos en el límite.
# Directrices de evaluación de políticas
AWS evaluará las políticas enviadas en función de un conjunto de directrices. Las mismas directrices de evaluación se aplican tanto a las plantillas de políticas como a los límites de permisos, con pequeñas diferencias cuando procede.
A efectos de la evaluación, separamos los servicios en grupos distintos. La distinción más importante es para los servicios sensibles a la seguridad, que administran el acceso, las credenciales y las claves. Las políticas que otorgan acceso a estos servicios deben centrarse estrictamente en el trabajo que se está llevando a cabo. Entre los servicios sensibles a la seguridad se incluyen los siguientes: AWS Identity and Access Management (IAM), AWS Key Management Service (KMS), AWS Resource Access Manager (RAM), AWS IAM Identity Center, AWS Organizations y AWS Secrets Manager.
Una distinción secundaria son los servicios que pueden acceder a los datos más allá de los límites de las cuentas. Las políticas de estos servicios deben incluir protecciones para evitar el acceso entre cuentas no intencionado.
## Validaciones comunes
Todas las instrucciones de políticas deben seguir estas directrices:
+ Todas las instrucciones deben incluir los campos Effect, Action (o NotAction), Resource y Condition en ese orden.
+ Todas las acciones de una sola instrucción deben estar ordenadas alfabéticamente.
+ Todos los ARN incluidos en la política deben seguir la sintaxis definida en la documentación pública para los servicios pertinentes.
+ Los campos NotAction solo se pueden usar en las instrucciones Deny.
+ Las acciones de las instrucciones Allow deben incluir un código de servicio. No se permiten caracteres comodín genéricos (“\$1”).
## Restricciones de los servicios sensibles a la seguridad
Las siguientes restricciones se aplican a los servicios sensibles a la seguridad mencionados anteriormente:
+ Las acciones de las instrucciones Allow deben ser más específicas que las de [service]:\$1.
+ Las acciones de las instrucciones Allow para las plantillas de políticas de acceso temporal no deben contener caracteres comodín.
+ Las acciones sensibles, como iam:PassRole o iam:CreateServiceLinkedRole, requieren un ámbito adicional, como recursos específicos o comprobaciones condicionales. Estas acciones son:
+ Transferencia de roles de IAM
+ Acciones de modificación de roles de IAM
+ Acciones de modificación de políticas de IAM
+ Operaciones criptográficas o de escritura de AWS KMS
+ Operaciones de uso compartido o escritura de AWS RAM
+ Operaciones de AWS Secrets Manager para recuperar o modificar secretos o modificar políticas de recursos
+ Otras acciones pueden utilizar un recurso comodín, como iam:ListUsers o iam:GetPolicy.
+ Las acciones que administran credenciales, como iam:CreateAccessKey, están bloqueadas.
## Restricciones específicas de IAM
En el caso de IAM:
+ Solo se permiten operaciones de escritura limitadas para los roles y las políticas de IAM. No puede solicitar permisos en otros recursos de IAM, como usuarios, grupos y certificados.
+ Las acciones de asociación de políticas o de administración de políticas insertadas se limitan a los roles con un límite de permisos. Los límites de permisos deben proporcionarlos los socios o figurar en una lista de políticas administradas de AWS permitidas. Las políticas administradas de AWS pueden permitirse si no conceden permisos administrativos o con privilegios elevados. Por ejemplo, las políticas administradas de AWS para funciones de trabajo específicas o la política SecurityAudit pueden ser aceptables. AWS revisará cada política administrada de AWS caso por caso durante el proceso de incorporación.
+ La administración de políticas solo está permitida para las políticas con una ruta específica del socio: arn:aws:iam::@\$1AccountId\$1:policy/partner\$1domain.com/[feature]\$1.
+ Las etiquetas solo se pueden aplicar durante la creación de los recursos y solo para los roles y las políticas.
+ Las comprobaciones de iam:PassRole deben coincidir con un nombre o un prefijo de ruta específicos.
## Restricciones específicas de AWS STS
Para AWS STS:
+ sts:AssumeRole debe estar limitado al ARN de un rol específico, el prefijo de ARN de un rol, o estar limitado a un conjunto de cuentas o ID de organización/unidad organizativa.
## Restricciones de IAM Identity Center
En el caso de AWS IAM Identity Center, se bloquean las siguientes acciones:
+ Todas las acciones relacionadas con la administración de permisos (por ejemplo, sso:AttachCustomerManagedPolicyReferenceToPermissionSet).
+ Modificaciones de usuarios, grupos y membresías para el Almacén de identidades de AWS.
+ Administración de etiquetas.
## Restricciones de AWS Organizations
En el caso de AWS Organizations, solo se permitirán acciones de lectura.
## Validaciones adicionales específicas de los servicios
+ Las acciones que adquieren secretos o credenciales, como glue:GetConnection o redshift:GetClusterCredentials, deben tener condiciones que coincidan con los ARN completos, los prefijos de ARN o las etiquetas.
+ En el caso de Amazon Redshift: redshift:GetClusterCredentials solo se permite en el nombre de una base de datos específica y redshift:GetClusterCredentialsWithIAM solo se permite en el nombre de un grupo de trabajo específico.
**nota**
Al administrar los recursos de IAM de la cuenta, se recomienda utilizar una ruta que indique su nombre, por ejemplo: arn:aws:iam::111122223333:role/partner.com/rolename. Esto ayudará a diferenciar los recursos asociados a su integración y facilitará a los clientes la detección, la auditoría y el análisis.
## Requisitos de acceso entre cuentas
Las instrucciones que puedan permitir el acceso entre cuentas deben incluir al menos uno de los siguientes elementos:
+ Una condición que especifique la cuenta o la organización del recurso (por ejemplo, que aws:ResourceOrgId coincida con uno o más valores esperados).
+ Un campo Resource que incluya una cuenta específica (por ejemplo, arn:aws:sqs:\$1:111122223333:\$1).
+ Un campo Resource que incluya una cuenta no comodín y el nombre completo de un recurso (por ejemplo, arn:aws:s3:::full-bucket-name).
**nota**
El acceso entre cuentas es una funcionalidad sensible que requiere una justificación empresarial clara. AWS estudiará detenidamente la necesidad del acceso entre cuentas durante el proceso de incorporación.
# Plantillas de política de
Las plantillas de políticas son un nuevo constructo de IAM diseñado para definir los permisos temporales que los socios solicitan en las cuentas de los clientes. Al igual que las política de IAM habituales, definen los permisos mediante instrucciones con los elementos Effect, Action, Resource y Condition. La diferencia clave es que las plantillas de políticas incluyen parámetros (como @\$1bucketName\$1) que se sustituyen por valores reales al crear una solicitud de delegación.
## Cómo funcionan las plantillas de políticas
Como parte del proceso de incorporación, registra sus plantillas de políticas en AWS. AWS asigna a cada plantilla un ARN único al que hace referencia al crear las solicitudes de delegación.
Al crear una solicitud de delegación, especifica lo siguiente:
+ El ARN de la plantilla de política
+ Los valores de los parámetros que se van a sustituir en la plantilla
AWS combina la plantilla con los valores de los parámetros para generar una política de IAM estándar. Los clientes revisan esta política renderizada final al aprobar su solicitud de delegación y comprueban exactamente qué permisos se van a conceder.
**nota**
La política renderizada final tiene un límite de tamaño máximo de 2048 caracteres.
A continuación, se muestra un ejemplo sencillo en el que se explica cómo funciona la sustitución de las plantillas.
Plantilla de política:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject"
],
"Resource": "arn:aws:s3:::@{bucketName}/*"
}
]
}
```
Parámetros proporcionados en la solicitud de delegación:
```
{
"Name": "bucketName",
"Values": ["customer-data-bucket"],
"Type": "String"
}
```
Política renderizada final (lo que ven los clientes):
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject"
],
"Resource": "arn:aws:s3:::customer-data-bucket/*"
}
]
}
```
## Sintaxis de las plantillas
Las plantillas de políticas utilizan dos características clave para ofrecer flexibilidad: la sustitución de parámetros y las instrucciones condicionales. La sustitución de parámetros le permite definir marcadores de posición en la plantilla que se sustituyen por valores reales al crear una solicitud de delegación. Las instrucciones condicionales permiten incluir o excluir instrucciones de política completas en función de los valores de los parámetros.
### Sustitución y tipos de parámetros
Utilice la sintaxis @\$1parameterName\$1 para definir los parámetros de la plantilla de política. Al crear una solicitud de delegación, debe especificar el tipo de cada parámetro.
#### Cadena
Un valor único que se sustituye directamente en la plantilla.
Plantilla:
```
"Resource": "arn:aws:s3:::@{bucketName}/*"
```
Parámetros:
```
{
"Name": "bucketName",
"Values": ["my-bucket"],
"Type": "String"
}
```
Resultado renderizado:
```
"Resource": "arn:aws:s3:::my-bucket/*"
```
#### StringList
Múltiples valores que generan varias entradas de recursos. Cuando se usa un parámetro StringList en el ARN de un recurso, se expande para crear entradas de recursos independientes para cada valor.
Plantilla:
```
"Resource": "arn:aws:s3:::@{bucketNames}/*"
```
Parámetros:
```
{
"Name": "bucketNames",
"Values": ["bucket-1", "bucket-2"],
"Type": "StringList"
}
```
Resultado renderizado:
```
"Resource": [
"arn:aws:s3:::bucket-1/*",
"arn:aws:s3:::bucket-2/*"
]
```
#### Comportamiento de productos cruzados
Cuando se utilizan varios parámetros en el ARN del mismo recurso, los parámetros StringList crean un producto cruzado de todas las combinaciones.
Plantilla:
```
"Resource": "arn:aws:s3:::@{bucketNames}/@{prefix}/*"
```
Parámetros:
```
[
{
"Name": "bucketNames",
"Values": ["bucket-1", "bucket-2"],
"Type": "StringList"
},
{
"Name": "prefix",
"Values": ["data"],
"Type": "String"
}
]
```
Resultado renderizado:
```
"Resource": [
"arn:aws:s3:::bucket-1/data/*",
"arn:aws:s3:::bucket-2/data/*"
]
```
### Instrucciones condicionales
Use la directiva @Enabled para incluir o excluir condicionalmente instrucciones completas en función de los valores de los parámetros.
Sintaxis:
+ @Enabled: "parameterName": incluya la instrucción cuando el valor del parámetro sea “True”.
+ @Enabled: "\$1parameterName": incluya la instrucción cuando el valor del parámetro NO sea “True” (negación).
Plantilla:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["s3:GetObject"],
"Resource": "*"
},
{
"@Enabled": "ENABLE_S3_WRITE",
"Effect": "Allow",
"Action": ["s3:PutObject"],
"Resource": "arn:aws:s3:::@{bucketName}/*"
}
]
}
```
Parámetros (cuando ENABLE\$1S3\$1WRITE es “True”):
```
[
{
"Name": "bucketName",
"Values": ["my-bucket"],
"Type": "String"
},
{
"Name": "ENABLE_S3_WRITE",
"Values": ["True"],
"Type": "String"
}
]
```
Resultado renderizado:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["s3:GetObject"],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": ["s3:PutObject"],
"Resource": "arn:aws:s3:::my-bucket/*"
}
]
}
```
Parámetros (cuando ENABLE\$1S3\$1WRITE es “False”):
```
[
{
"Name": "bucketName",
"Values": ["my-bucket"],
"Type": "String"
},
{
"Name": "ENABLE_S3_WRITE",
"Values": ["False"],
"Type": "String"
}
]
```
Resultado renderizado:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["s3:GetObject"],
"Resource": "*"
}
]
}
```
Cuando ENABLE\$1S3\$1WRITE se establece en “True”, se incluye la instrucción condicional. Si se establece en “False”, la instrucción se excluye de la política renderizada.
## Ejemplos adicionales
En los siguientes ejemplos se muestran los patrones comunes de uso de plantillas de políticas en la delegación temporal. Se centran en crear roles de IAM con límites de permisos para el acceso a largo plazo y muestran diferentes estrategias para limitar los permisos a recursos específicos. En estos ejemplos se ilustra cómo equilibrar la flexibilidad con la seguridad mediante técnicas como los prefijos de ARN, el etiquetado de recursos y las actualizaciones de límites de permisos.
### Ejemplo 1: Concesión de acceso a largo plazo a recursos específicos
El siguiente límite de permisos se presenta como “SQSAccessorBoundary” para “partner.com”:
```
{
"Effect": "Allow",
"Action": [
"sqs:DeleteMessage",
"sqs:ReceiveMessage",
"sqs:SendMessage"
],
"Resource": "arn:aws:sqs:*:*:*",
"Condition": {
"StringEquals": {
"aws:ResourceAccount": "${aws:PrincipalAccount}"
}
}
}
```
**nota**
Esto incluye una condición de misma cuenta para evitar conceder acceso a las colas de otras cuentas con políticas de recursos abiertas. No se puede incluir una referencia directa al ID de cuenta del cliente porque el límite lo comparten todos los clientes y no se puede establecer una plantilla.
Como se trata de la primera versión de esta política, su ARN es arn:aws:iam::partner:policy/permissions-boundary/partner.com/SQSAccessorBoundary\$12025\$101\$115
Se envía la siguiente plantilla de política para los permisos de acceso temporal:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"sqs:ListQueues"
],
"Resource": "arn:aws:sqs:*:*:*"
},
{
"Effect": "Allow",
"Action": [
"iam:CreateRole",
"iam:PutRolePermissionsBoundary",
"iam:PutRolePolicy"
],
"Resource": "arn:aws:iam::@{AccountId}:role/partner.com/SQSAccessor",
"Condition": {
"StringEquals": {
"iam:PermissionsBoundary": "arn:aws:iam::partner:policy/permissions-boundary/partner.com/SQSAccessorBoundary_2025_01_15"
}
}
}
]
}
```
### Ejemplo 2: Uso de prefijos de ARN
El límite de permisos puede especificar el prefijo de ARN de un recurso para limitar el acceso:
```
"Resource": "arn:aws:sqs:*:@{AccountId}:PartnerPrefix*"
```
Esto limita el acceso solo a los recursos con ese prefijo, lo que reduce el alcance de los recursos accesibles.
### Ejemplo 3: Uso de etiquetas para el control de acceso de los recursos
Puede etiquetar los recursos durante el acceso delegado temporal y confiar en esas etiquetas para el control de acceso a largo plazo.
Límite de permisos que permite el acceso a los recursos etiquetados:
```
{
"Effect": "Allow",
"Action": [
"sqs:DeleteMessage",
"sqs:ReceiveMessage",
"sqs:SendMessage"
],
"Resource": "arn:aws:sqs:*:*:*",
"Condition": {
"Null": {
"aws:ResourceTag/ManagedByPartnerDotCom": "false"
},
"StringEquals": {
"aws:ResourceAccount": "${aws:PrincipalAccount}"
}
}
}
```
Plantilla de política para etiquetar las nuevas colas al crearlas:
```
{
"Effect": "Allow",
"Action": [
"sqs:CreateQueue",
"sqs:TagQueue"
],
"Resource": "arn:aws:sqs:*:*:*",
"Condition": {
"Null": {
"aws:RequestTag/ManagedByPartnerDotCom": "false"
}
}
}
```
Plantilla de política para etiquetar las colas preexistentes y crear el rol:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"sqs:TagQueue"
],
"Resource": "arn:aws:sqs:*:@{AccountId}:@{QueueName}",
"Condition": {
"ForAllValues:StringEquals": {
"aws:TagKeys": "ManagedByPartnerDotCom"
}
}
},
{
"Effect": "Allow",
"Action": [
"iam:CreateRole",
"iam:PutRolePermissionsBoundary",
"iam:PutRolePolicy"
],
"Resource": "arn:aws:iam::@{AccountId}:role/partner.com/SQSAccessor",
"Condition": {
"StringEquals": {
"iam:PermissionsBoundary": "arn:aws:iam::partner:policy/permissions-boundary/partner.com/SQSAccessorBoundary_2025_01_15"
}
}
}
]
}
```
Este enfoque permite a los clientes confirmar de forma explícita a qué recursos específicos se puede acceder a largo plazo.
### Ejemplo 4: Actualización del límite de permisos
Para actualizar un límite de permisos, registre una nueva versión con un sufijo de fecha nuevo y solicite permiso para sustituirlo.
Límite de permisos actualizado con permiso adicional:
```
{
"Effect": "Allow",
"Action": [
"sqs:DeleteMessage",
"sqs:PurgeQueue",
"sqs:ReceiveMessage",
"sqs:SendMessage"
],
"Resource": "arn:aws:sqs:*:*:*",
"Condition": {
"StringEquals": {
"aws:ResourceAccount": "${aws:PrincipalAccount}"
}
}
}
```
Como segunda versión, esta política tiene el ARN arn:aws:iam::partner:policy/permissions-boundary/partner.com/SQSAccessorBoundary\$12025\$101\$120
Plantilla de política para actualizar el límite de permisos del rol existente:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"iam:PutRolePermissionsBoundary"
],
"Resource": "arn:aws:iam::@{AccountId}:role/partner.com/SQSAccessor",
"Condition": {
"StringEquals": {
"iam:PermissionsBoundary": "arn:aws:iam::partner:policy/permissions-boundary/partner.com/SQSAccessorBoundary_2025_01_20"
}
}
}
]
}
```
Los clientes deben aprobar esta solicitud de delegación para actualizar el límite de permisos del rol existente.
# Creación de una integración
## Descripción del ciclo de vida de una solicitud
Antes de crear la integración, es importante entender cómo avanzan las solicitudes de delegación desde su creación hasta su finalización.
### Estados de las solicitudes
Una solicitud de delegación pasa por los siguientes estados:
| Estado | Descripción |
| --- | --- |
| Sin asignar | Solicitud creada, pero aún no asociada a ninguna cuenta de cliente ni entidad principal de IAM. Es posible que la solicitud se haya creado sin especificar una cuenta de destino o con un ID de cuenta de destino, pero el propietario de la cuenta aún no la reclamó. |
| Asignada | Solicitud asociada a una cuenta de cliente y pendiente de revisión. |
| Aprobación pendiente | El cliente reenvió la solicitud a un administrador para su aprobación. |
| Aceptada | El cliente aprobó la solicitud, pero el token de intercambio aún no se liberó. |
| Finalizada | El token de intercambio se liberó al proveedor del producto. El periodo de delegación (validez del token de intercambio) comienza cuando la solicitud alcanza el estado Finalizada. |
| Rechazada | Solicitud rechazada por el cliente. |
| Vencido | Solicitud vencida debido a inactividad o a que se agotó el tiempo de espera. |
### Transiciones de los estados
*Flujo normal (ruta de aprobación)*
+ Sin asignar → Asignada: el cliente asocia la solicitud a su cuenta.
+ Asignada → Aceptada O Asignada → Aprobación pendiente: el cliente aprueba la solicitud directamente O la reenvía al administrador para que la revise.
+ Aprobación pendiente → Aceptada: el administrador aprueba la solicitud.
+ Aceptada → Finalizada: el cliente libera el token de intercambio.
*Ruta de rechazo*
+ Asignada → Rechazada: el cliente rechaza la solicitud.
+ Aprobación pendiente → Rechazada: el administrador rechaza la solicitud.
+ Aceptada → Rechazada: el cliente revoca la aprobación antes de liberar el token.
*Ruta de vencimiento*
Las solicitudes vencen automáticamente si no se lleva a cabo ninguna acción en el plazo especificado:
+ Sin asignar → Vencida (1 día)
+ Asignada → Vencida (7 día)
+ Aprobación pendiente → Vencida (7 días)
+ Aceptada → Vencida (7 día)
+ Rechazada → Vencida (7 día)
+ Finalizada → Vencida (7 días)
*Estados terminales*
Los siguientes estados son terminales (no hay más transiciones):
+ Finalizada: se envió el token de intercambio.
+ Rechazada: se denegó la solicitud.
+ Vencida: se agotó el tiempo de espera de la solicitud o finalizó el periodo de delegación.
Las solicitudes vencidas se eliminan finalmente del sistema una vez finalizado el periodo de retención.
### Administración de los estados de las solicitudes de delegación en su aplicación
Como socio, debe hacer un seguimiento de los estados de las solicitudes de delegación en su sistema y mostrarlos a sus clientes. Cuando reciba notificaciones de SNS sobre cambios de estado, almacene estas actualizaciones en su backend y refléjelas en la interfaz de usuario dirigida al cliente. Preste especial atención al estado Aprobación pendiente; cuando un cliente reenvía una solicitud a un administrador para que la revise, AWS le envía una notificación de aprobación pendiente. Las solicitudes pueden permanecer en este estado durante un máximo de 7 días mientras esperan una acción del administrador. Durante este tiempo, muestre a los clientes que su solicitud está pendiente de aprobación del administrador en tu aplicación. Considere la posibilidad de proporcionar un enlace profundo a la Consola de AWS donde los clientes puedan comprobar el estado de la solicitud o hacer un seguimiento con su administrador. Para una buena experiencia de integración, es importante gestionar correctamente la máquina de estados de su backend y mostrar a los clientes la información de estado correcta en cada etapa.
![\[alt text not found\]](http://docs.aws.amazon.com/es_es/IAM/latest/UserGuide/images/delegation-states.png)
## Configuración de notificaciones
IAM utiliza Amazon Simple Notification Service (SNS) para comunicarle los cambios de estado de las solicitudes de delegación. Al crear una solicitud de delegación, debe proporcionar el ARN de un tema de SNS de su cuenta de AWS registrada. IAM publicará mensajes en este tema sobre eventos importantes, como cuando los clientes aprueben o rechacen las solicitudes y cuando el token de intercambio esté listo.
**nota**
Los temas de SNS no pueden estar en las regiones de AWS registradas. Su tema de SNS debe estar en una región de AWS que esté habilitada de forma predeterminada. Para ver una lista de las regiones registradas, consulte Administración de regiones de AWS en la Guía de administración de cuentas de AWS.
### Configuración de temas de SNS
Para recibir notificaciones de solicitudes de delegación, debe configurar su tema de SNS para conceder permisos de IAM a fin de publicar mensajes en él. Agregue la siguiente instrucción de política a la política del tema de SNS.
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowIAMServiceToPublish",
"Effect": "Allow",
"Principal": {
"Service": "iam.amazonaws.com"
},
"Action": "SNS:Publish",
"Resource": "arn:aws:sns:REGION:ACCOUNT-ID:TOPIC-NAME"
}
]
}
```
**importante**
El tema de SNS debe estar en una de sus cuentas de AWS registradas. IAM no aceptará temas de SNS de otras cuentas. Si la política del tema no está configurada correctamente, no recibirá notificaciones de cambio de estado ni el token de intercambio.
### Tipos de notificaciones
IAM envía dos tipos de notificaciones:
*Notificaciones de StateChange*
Se envía cuando una solicitud de delegación pasa a un nuevo estado (Asignada, Pendiente de aprobación, Aceptada, Finalizada, Rechazada o Vencida).
*Notificaciones de ExchangeToken*
Se envía cuando un cliente libera el token de delegación (estado Finalizada). Esta notificación incluye el token de intercambio que necesita para obtener las credenciales.
### Estados de las notificaciones
Recibirá notificaciones de los siguientes estados de las solicitudes de delegación:
| Estado | Tipo de notificación | Descripción |
| --- | --- | --- |
| ASIGNADA | Cambio de estado | La solicitud se asoció a una cuenta de cliente. |
| APROBACIÓN PENDIENTE | Cambio de estado | El cliente reenvió la solicitud a un administrador para su aprobación. |
| ACEPTADA | Cambio de estado | El cliente aprobó la solicitud, pero el token de intercambio aún no se liberó. |
| FINALIZADA | Cambio de estado | El cliente liberó el token de intercambio. |
| FINALIZADA | ExchangeToken | Esta notificación contiene el token de intercambio. |
| REJECTED | Cambio de estado | El cliente rechazó la solicitud. |
| EXPIRED | Cambio de estado | La solicitud venció antes de completarse. |
### Formato de los mensajes de notificación
IAM publica notificaciones de SNS estándar. La información de la solicitud de delegación se incluye en el campo Message en forma de cadena JSON.
*Campos comunes (todas las notificaciones)*
| Campo | Tipo | Descripción |
| --- | --- | --- |
| Tipo | Cadena | “StateChange” o “ExchangeToken”. |
| RequestId | Cadena | ID de la solicitud de delegación de IAM. |
| RequestorWorkflowId | Cadena | ID del flujo de trabajo que proporcionó al crear la solicitud. |
| Estado | Cadena | Estado actual de la solicitud. |
| OwnerAccountId | Cadena | ID de la cuenta de AWS del cliente. |
| UpdatedAt | Cadena | Marca de tiempo del momento en que se cambió el estado (formato ISO 8601). |
*Campos adicionales (solo notificaciones de ExchangeToken)*
| Campo | Tipo | Descripción |
| --- | --- | --- |
| ExchangeToken | Cadena | Token que se va a intercambiar por credenciales mediante la API GetDelegatedAccessToken de AWS STS. |
| ExpiresAt | Cadena | Momento en que vence el acceso delegado (formato ISO 8601). |
### Notificaciones de ejemplo
*Notificación de StateChange*
```
{
"Type": "Notification",
"MessageId": "61ee8ad4-6eec-56b5-8f3d-eba57556aa13",
"TopicArn": "arn:aws:sns:us-east-1:123456789012:partner-notifications",
"Message": "{\"RequestorWorkflowId\":\"workflow-12345\",\"Type\":\"StateChange\",\"RequestId\":\"dr-abc123\",\"State\":\"ACCEPTED\",\"OwnerAccountId\":\"111122223333\",\"UpdatedAt\":\"2025-01-15T10:30:00.123Z\"}",
"Timestamp": "2025-01-15T10:30:00.456Z",
"SignatureVersion": "1",
"Signature": "...",
"SigningCertURL": "...",
"UnsubscribeURL": "..."
}
```
*Notificación de ExchangeToken*
```
{
"Type": "Notification",
"MessageId": "e44e5435-c72c-5333-aba3-354406782f5b",
"TopicArn": "arn:aws:sns:us-east-1:123456789012:partner-notifications",
"Message": "{\"RequestId\":\"dr-abc123\",\"RequestorWorkflowId\":\"workflow-12345\",\"State\":\"FINALIZED\",\"OwnerAccountId\":\"111122223333\",\"ExchangeToken\":\"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...\",\"ExpiresAt\":\"2025-01-15T18:30:00.123Z\",\"UpdatedAt\":\"2025-01-15T10:30:00.456Z\",\"Type\":\"ExchangeToken\"}",
"Timestamp": "2025-01-15T10:30:00.789Z",
"SignatureVersion": "1",
"Signature": "...",
"SigningCertURL": "...",
"UnsubscribeURL": "..."
}
```
## Tokens de intercambio
IAM emite un token de intercambio cuando un cliente acepta y finaliza una solicitud de delegación. El proveedor del producto utiliza este token de intercambio para llamar a la API GetDelegatedAccessToken de AWS AWS STS y obtener credenciales temporales de AWS con los permisos aprobados por los clientes. El token de intercambio en sí no otorga acceso a sus recursos de AWS; debe intercambiarse por credenciales reales a través de AWS STS.
El token de intercambio solo lo puede canjear la cuenta del proveedor del producto que creó la solicitud de delegación. La cuenta solicitante está incrustada en el token, lo que garantiza que solo el proveedor del producto autorizado pueda obtener las credenciales para acceder a la cuenta del cliente.
### Duración del acceso
El periodo de delegación comienza cuando el cliente libera el token de intercambio, no cuando el proveedor del producto lo canjea. Una vez que el cliente libere el token:
+ El proveedor del producto recibe el token mediante una notificación de SNS.
+ Puede intercambiarlo inmediatamente por credenciales.
+ Las credenciales caducan en: hora de liberación \$1 duración aprobada.
+ El proveedor del producto puede intercambiar el token varias veces antes de que venza para obtener credenciales nuevas si es necesario.
### Varios canjes
Los proveedores de productos pueden intercambiar el token varias veces durante el periodo de validez para obtener credenciales nuevas. Sin embargo, todas las credenciales obtenidas del mismo token de intercambio caducan al mismo tiempo, según el momento en que se haya liberado el token.
Ejemplo: Si aprueba una solicitud de delegación de 2 horas y libera el token a las 10:00 h:
| Hora de liberación del token | Hora de intercambio del token | Vencimiento de la credencial | Tiempo de uso |
| --- | --- | --- | --- |
| 10:00 am | 10:00 am | 12:00 pm | 2 horas |
| 10:00 am | 10:20 a. m. | 12:00 pm | 1 hora y 40 minutos |
| 10:00 am | 11:40 a. m. | 12:00 pm | 20 minutos |
| 10:00 am | 12:10 pm | Error (token vencido) | 0 minutos |
Como se muestra en la tabla, intercambiar el token más adelante en el periodo de validez reduce el tiempo de uso para el proveedor del producto.