

Avviso di fine del supporto: il 20 maggio 2026, AWS terminerà il supporto per AWS IoT Events. Dopo il 20 maggio 2026, non potrai più accedere alla AWS IoT Events console o AWS IoT Events alle risorse. Per ulteriori informazioni, consulta [AWS IoT Events Fine del supporto](https://docs.aws.amazon.com/iotevents/latest/developerguide/iotevents-end-of-support.html).

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

# Prevenzione sostitutiva confusa tra diversi servizi per AWS IoT Events
<a name="cross-service-confused-deputy-prevention"></a>

**Nota**  
Il AWS IoT Events servizio consente di utilizzare i ruoli solo per avviare azioni nello stesso account in cui è stata creata una risorsa. Questo aiuta a prevenire un attacco confuso da parte di un vicesceriffo AWS IoT Events.
Questa pagina serve come riferimento per vedere come funziona il problema del confuso dei vicesceriffi e può essere evitata nel caso in cui nel AWS IoT Events servizio fossero consentite risorse multiaccount.

Il problema confused deputy è un problema di sicurezza in cui un’entità che non dispone dell’autorizzazione per eseguire un’azione può costringere un’entità maggiormente privilegiata a eseguire l’azione. Nel AWS, l'impersonificazione tra servizi può causare il problema del sostituto confuso.

La rappresentazione tra servizi può verificarsi quando un servizio (il *servizio chiamante*) effettua una chiamata a un altro servizio (il *servizio chiamato*). Il servizio chiamante può essere manipolato per utilizzare le proprie autorizzazioni e agire sulle risorse di un altro cliente, a cui normalmente non avrebbe accesso. Per evitare che ciò accada, AWS mette a disposizione strumenti che consentono di proteggere i dati relativi a tutti i servizi con responsabili del servizio a cui è stato concesso l'accesso alle risorse del vostro account. 

Ti consigliamo di utilizzare [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)le chiavi di contesto della condizione [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)globale nelle politiche delle risorse per limitare le autorizzazioni che AWS IoT Events forniscono un altro servizio alla risorsa. Se il valore `aws:SourceArn` non contiene l'ID account, ad esempio un ARN di un bucket Amazon S3, è necessario utilizzare entrambe le chiavi di contesto delle condizioni globali per limitare le autorizzazioni. Se si utilizzano entrambe le chiavi di contesto delle condizioni globali e il valore `aws:SourceArn` contiene l'ID account, il valore `aws:SourceAccount` e l’account nel valore `aws:SourceArn` deve utilizzare lo stesso ID account nella stessa dichiarazione di policy. 

 Utilizzare `aws:SourceArn` se si desidera consentire l'associazione di una sola risorsa all'accesso tra servizi. Utilizzare `aws:SourceAccount` se si desidera consentire l’associazione di qualsiasi risorsa in tale account all’uso tra servizi. Il valore di `aws:SourceArn` deve essere il modello di rilevatore o il modello di allarme associato alla `sts:AssumeRole` richiesta.

Il modo più efficace per proteggersi dal problema "confused deputy" è quello di usare la chiave di contesto della condizione globale `aws:SourceArn` con l’ARN completo della risorsa. Se non si conosce l’ARN completo della risorsa o si scelgono più risorse, è necessario utilizzare la chiave di contesto della condizione globale `aws:SourceArn` con caratteri jolly (`*`) per le parti sconosciute dell’ARN. Ad esempio, `arn:aws:iotevents:*:123456789012:*`. 

Gli esempi seguenti mostrano come utilizzare le chiavi di contesto `aws:SourceArn` e `aws:SourceAccount` global condition AWS IoT Events per prevenire il confuso problema del vice.

**Topics**
+ [Esempio: accesso sicuro a un modello di AWS IoT Events rilevatore](accessing-a-detector-model.md)
+ [Esempio: accesso sicuro a un modello di AWS IoT Events allarme](accessing-an-alarm-model.md)
+ [Esempio: accedere a una AWS IoT Events risorsa in una regione specificata](accessing-resource-in-specified-region.md)
+ [Esempio: configura le opzioni di registrazione per AWS IoT Events](logging-options.md)

# Esempio: accesso sicuro a un modello di AWS IoT Events rilevatore
<a name="accessing-a-detector-model"></a>

Questo esempio dimostra come creare una policy IAM che conceda in modo sicuro l'accesso a uno specifico modello di rilevatore in. AWS IoT Events La policy utilizza condizioni per garantire che solo l' AWS account e il AWS IoT Events servizio specificati possano assumere il ruolo, aggiungendo un ulteriore livello di sicurezza. In questo esempio, il ruolo può accedere solo al modello di rilevatore denominato*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"
                }
            }
        }
    ]
}
```

------

# Esempio: accesso sicuro a un modello di AWS IoT Events allarme
<a name="accessing-an-alarm-model"></a>

Questo esempio dimostra come creare una policy IAM che consenta di accedere in modo sicuro AWS IoT Events ai modelli di allarme. La policy utilizza condizioni per garantire che solo l' AWS account e il AWS IoT Events servizio specificati possano assumere il ruolo.

In questo esempio, il ruolo può accedere a qualsiasi modello di allarme all'interno dell' AWS account specificato, come indicato dalla `*` wildcard nel modello di allarme ARN. Le `aws:SourceArn` condizioni `aws:SourceAccount` and interagiscono per prevenire il confuso problema del vicesceriffo.

------
#### [ 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/*"
                }
            }
        }
    ]
}
```

------

# Esempio: accedere a una AWS IoT Events risorsa in una regione specificata
<a name="accessing-resource-in-specified-region"></a>

Questo esempio dimostra come configurare un ruolo IAM per accedere alle AWS IoT Events risorse in una AWS regione specifica. Utilizzando politiche IAM specifiche per regione ARNs , puoi limitare l'accesso alle AWS IoT Events risorse in diverse aree geografiche. Questo approccio può aiutare a mantenere la sicurezza e la conformità nelle implementazioni multiregionali. La regione in questo esempio è. *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:*"
                }
            }
        }
    ]
}
```

------

# Esempio: configura le opzioni di registrazione per AWS IoT Events
<a name="logging-options"></a>

Una registrazione corretta è importante per il monitoraggio, il debug e il controllo delle applicazioni. AWS IoT Events Questa sezione fornisce una panoramica delle opzioni di registrazione disponibili in. AWS IoT Events

Questo esempio dimostra come configurare un ruolo IAM che AWS IoT Events consenta di registrare i dati nei registri. CloudWatch L'uso di wildcard (`*`) nella risorsa ARN consente una registrazione completa su tutta l'infrastruttura. AWS IoT Events 

------
#### [ 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:*"
                }
            }
        }
    ]
}
```

------