Aviso de fin de soporte: el 20 de mayo de 2026, AWS finalizará el soporte para AWS IoT Events. Después del 20 de mayo de 2026, ya no podrás acceder a la AWS IoT Events consola ni a AWS IoT Events los recursos. Para obtener más información, consulta [AWS IoT Events el fin del soporte](https://docs.aws.amazon.com/iotevents/latest/developerguide/iotevents-end-of-support.html).
Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
# Prevención policial confusa entre servicios para AWS IoT Events
**nota**
El AWS IoT Events servicio solo permite usar roles para iniciar acciones en la misma cuenta en la que se creó un recurso. Esto ayuda a evitar que un diputado confuso ataque AWS IoT Events.
Esta página le servirá de referencia para ver cómo funciona el confuso problema de los diputados y puede evitarse en caso de que el AWS IoT Events servicio permita el uso de recursos entre cuentas cruzadas.
El problema de la sustitución confusa es un problema de seguridad en el que una entidad que no tiene permiso para realizar una acción puede obligar a una entidad con más privilegios a realizar la acción. En AWS, la suplantación de identidad entre servicios puede provocar el confuso problema de un diputado.
La suplantación entre servicios puede producirse cuando un servicio (el *servicio que lleva a cabo las llamadas*) llama a otro servicio (el *servicio al que se llama*). El servicio que lleva a cabo las llamadas se puedes manipular para utilizar sus permisos a fin de actuar en función de los recursos de otro cliente de una manera en la que no debe tener permiso para acceder. Para evitarlo, AWS proporciona herramientas que le ayudan a proteger los datos de todos los servicios cuyos directores de servicio tengan acceso a los recursos de su cuenta.
Recomendamos utilizar las claves de contexto de condición [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount)global [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn)y las claves contextuales en las políticas de recursos para limitar los permisos que se AWS IoT Events otorgan a otro servicio al recurso. Si el valor de `aws:SourceArn` no contiene el ID de cuenta, como un ARN de bucket de Amazon S3, debe utilizar ambas claves de contexto de condición global para limitar los permisos. Si utiliza claves de contexto de condición global y el valor de `aws:SourceArn` contiene el ID de cuenta, el valor de `aws:SourceAccount` y la cuenta en el valor de `aws:SourceArn` deben utilizar el mismo ID de cuenta cuando se utiliza en la misma instrucción de política.
Utiliza `aws:SourceArn` si desea que solo se asocie un recurso al acceso entre servicios. Utiliza `aws:SourceAccount` si quiere permitir que cualquier recurso de esa cuenta se asocie al uso entre servicios. El valor de `aws:SourceArn` debe ser el modelo de detector o el modelo de alarma asociado a la solicitud `sts:AssumeRole`.
La forma más eficaz de protegerse contra el problema de la sustitución confusa es utilizar la clave de contexto de condición global de `aws:SourceArn` con el ARN completo del recurso. Si no conoce el ARN completo del recurso o si especifica varios recursos, utiliza la clave de condición de contexto global `aws:SourceArn` con comodines (`*`) para las partes desconocidas del ARN. Por ejemplo, `arn:aws:iotevents:*:123456789012:*`.
En los ejemplos siguientes se muestra cómo utilizar las claves de contexto de condición `aws:SourceAccount` global `aws:SourceArn` y las claves contextuales AWS IoT Events para evitar el confuso problema de los diputados.
**Topics**
+ [Ejemplo: acceso seguro a un modelo AWS IoT Events de detector](accessing-a-detector-model.md)
+ [Ejemplo: acceso seguro a un modelo AWS IoT Events de alarma](accessing-an-alarm-model.md)
+ [Ejemplo: acceder a un AWS IoT Events recurso en una región específica](accessing-resource-in-specified-region.md)
+ [Ejemplo: configurar las opciones de registro para AWS IoT Events](logging-options.md)
# Ejemplo: acceso seguro a un modelo AWS IoT Events de detector
En este ejemplo se muestra cómo crear una política de IAM que conceda acceso de forma segura a un modelo de detector específico en. AWS IoT Events La política utiliza condiciones para garantizar que solo la AWS cuenta y el AWS IoT Events servicio especificados puedan asumir la función, lo que añade un nivel adicional de seguridad. En este ejemplo, el rol solo puede acceder al modelo de detector mencionado*WindTurbine01*.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": [
"iotevents.amazonaws.com"
]
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "123456789012"
},
"ArnEquals": {
"aws:SourceArn": "arn:aws:iotevents:us-east-1:123456789012:detectorModel/WindTurbine01"
}
}
}
]
}
```
------
# Ejemplo: acceso seguro a un modelo AWS IoT Events de alarma
Este ejemplo demuestra cómo crear una política de IAM que permita acceder de forma segura AWS IoT Events a los modelos de alarma. La política utiliza condiciones para garantizar que solo la AWS cuenta y el AWS IoT Events servicio especificados puedan asumir la función.
En este ejemplo, el rol puede acceder a cualquier modelo de alarma de la AWS cuenta especificada, como lo indica el `*` comodín en el ARN del modelo de alarma. Las `aws:SourceArn` condiciones `aws:SourceAccount` y las dos funcionan juntas para evitar el confuso problema de los diputados.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": [
"iotevents.amazonaws.com"
]
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "123456789012"
},
"ArnEquals": {
"aws:SourceArn": "arn:aws:iotevents:us-east-1:123456789012:alarmModel/*"
}
}
}
]
}
```
------
# Ejemplo: acceder a un AWS IoT Events recurso en una región específica
En este ejemplo, se muestra cómo configurar un rol de IAM para acceder a AWS IoT Events los recursos de una AWS región específica. Al utilizar políticas de IAM específicas para cada región ARNs , puede restringir el acceso a AWS IoT Events los recursos en diferentes áreas geográficas. Este enfoque puede ayudar a mantener la seguridad y el cumplimiento en las implementaciones en varias regiones. La región de este ejemplo es. *us-east-1*
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": [
"iotevents.amazonaws.com"
]
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "123456789012"
},
"ArnEquals": {
"aws:SourceArn": "arn:aws:iotevents:us-east-1:123456789012:*"
}
}
}
]
}
```
------
# Ejemplo: configurar las opciones de registro para AWS IoT Events
El registro adecuado es importante para supervisar, depurar y auditar AWS IoT Events las aplicaciones. En esta sección se proporciona una descripción general de las opciones de registro disponibles en AWS IoT Events.
En este ejemplo, se muestra cómo configurar una función de IAM que AWS IoT Events permita registrar datos en los CloudWatch registros. El uso de caracteres comodín (`*`) en el ARN del recurso permite un registro completo en toda AWS IoT Events la infraestructura.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": [
"iotevents.amazonaws.com"
]
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "123456789012"
},
"ArnEquals": {
"aws:SourceArn": "arn:aws:iotevents:us-east-1:123456789012:*"
}
}
}
]
}
```
------