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 del confused deputy tra servizi
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. Inoltre AWS, l'impersonificazione tra servizi può causare il confuso problema del vicesceriffo. 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 ciò, AWS fornisce alcuni strumenti che consentono di proteggere i dati per tutti i servizi che dispongono di principali del servizio a cui è stato consentito l’accesso alle risorse del tuo account.
Per limitare le autorizzazioni che AWS IoT assegnano un altro servizio alla risorsa, consigliamo di utilizzare le chiavi di contesto [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)e 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. Se si utilizzano entrambe le chiavi di contesto delle condizioni globali, il valore `aws:SourceAccount` e l’account nel valore `aws:SourceArn` devono utilizzare lo stesso ID account nella stessa istruzione di policy.
Il modo più efficace per proteggersi dal problema "confused deputy" è quello di usare la chiave di contesto della condizione globale `aws:SourceArn` con l'Amazon Resource Name (ARN) completo della risorsa. Perché AWS IoT, è `aws:SourceArn` necessario rispettare il formato: `arn:aws:iot:region:account-id:resource-type/resource-id` per le autorizzazioni specifiche delle risorse o. `arn:aws:iot:region:account-id:*` Il resource-id può essere il nome o l'ID della risorsa consentita o una dichiarazione con caratteri jolly della risorsa consentita. IDs Assicurati che corrisponda alla tua AWS IoT regione e che *region* corrisponda all'ID del *account-id* tuo account cliente.
L'esempio seguente mostra come prevenire il problema confuso del vicesceriffo utilizzando le chiavi del contesto `aws:SourceArn` e della condizione `aws:SourceAccount` globale nella politica di fiducia dei AWS IoT ruoli. Per ulteriori esempi, consulta [Esempi dettagliati di prevenzione confusa](#cross-service-confused-deputy-prevention-examples).
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Principal":{
"Service":"iot.amazonaws.com"
},
"Action":"sts:AssumeRole",
"Condition":{
"StringEquals":{
"aws:SourceAccount":"123456789012"
},
"ArnLike":{
"aws:SourceArn":"arn:aws:iot:us-east-1:123456789012:*"
}
}
}
]
}
```
**Nota**
Se si verificano errori di negazione dell'accesso, può essere dovuto al fatto che l'integrazione del servizio con AWS Security Token Service (STS) non supporta le chiavi `aws:SourceArn` e di `aws:SourceAccount` contesto.
## Esempi dettagliati di prevenzione confusa
**Questa sezione fornisce esempi dettagliati di come prevenire il problema confuso dei vicesceriffi utilizzando `aws:SourceArn` le chiavi relative al contesto della condizione `aws:SourceAccount` globale nella politica di fiducia nei AWS IoT ruoli.**
+ [Provisioning del parco istanze](#cross-service-confused-deputy-prevention-fleet-provision)
+ [JITP](#cross-service-confused-deputy-prevention-JITP)
+ [Fornitore di credenziali](#cross-service-confused-deputy-prevention-credential-provider)
### Provisioning del parco istanze
È possibile configurare il [provisioning della flotta](https://docs.aws.amazon.com/iot/latest/developerguide/iot-provision.html) utilizzando una risorsa modello di provisioning. Quando un modello di provisioning fa riferimento a un ruolo di provisioning, la policy di attendibilità di quel ruolo può includere le `aws:SourceArn` chiavi e condition. `aws:SourceAccount` Queste chiavi limitano le risorse per le quali la configurazione può richiamare la richiesta. `sts:AssumeRole`
Il ruolo con la seguente policy di trust può essere assunto solo dal principale IoT (`iot.amazonaws.com`) per il modello di provisioning specificato in. `SourceArn`
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Principal":{
"Service":"iot.amazonaws.com"
},
"Action":"sts:AssumeRole",
"Condition":{
"StringEquals":{
"aws:SourceAccount":"123456789012"
},
"ArnLike":{
"aws:SourceArn":"arn:aws:iot:us-east-1:123456789012:provisioningtemplate/example_template"
}
}
}
]
}
```
### JITP
Nel [just-in-time provisioning (JITP)](https://docs.aws.amazon.com//iot/latest/developerguide/jit-provisioning.html), è possibile utilizzare il modello di provisioning come risorsa separata dalla CA o definire il corpo del modello e il ruolo come parte della configurazione del certificato CA. Il valore della policy di `aws:SourceArn` attendibilità del AWS IoT ruolo dipende da come si definisce il modello di provisioning.
#### Definizione del modello di provisioning come risorsa separata
Se si definisce il modello di provisioning come risorsa separata, il valore di `aws:SourceArn` può essere. `"arn:aws:iot:region:account-id:provisioningtemplate/example_template"` È possibile utilizzare lo stesso esempio di policy in[Provisioning del parco istanze](#cross-service-confused-deputy-prevention-fleet-provision).
#### Definizione di un modello di provisioning in un certificato CA
Se si definisce il modello di provisioning all'interno di una risorsa di certificato CA, il valore di `aws:SourceArn` può essere `"arn:aws:iot:region:account-id:cacert/cert_id"` o. `"arn:aws:iot:region:account-id:cacert/*"` È possibile utilizzare un carattere jolly quando l'identificatore della risorsa, ad esempio l'ID di un certificato CA, è sconosciuto al momento della creazione.
Il ruolo con la seguente policy di fiducia può essere assunto solo dal principale IoT (`iot.amazonaws.com`) per il certificato CA specificato in`SourceArn`.
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Principal":{
"Service":"iot.amazonaws.com"
},
"Action":"sts:AssumeRole",
"Condition":{
"StringEquals":{
"aws:SourceAccount":"123456789012"
},
"ArnLike":{
"aws:SourceArn":"arn:aws:iot:us-east-1:123456789012:cacert/8ecde6884f3d87b1125ba31ac3fcb13d7016de7f57cc904fe1cb97c6ae98196e"
}
}
}
]
}
```
Quando si crea un certificato CA, è possibile fare riferimento a un ruolo di provisioning nella configurazione di registrazione. La politica di fiducia del ruolo di provisioning può essere utilizzata `aws:SourceArn` per limitare le risorse per cui il ruolo può essere assunto. [Tuttavia, durante la CACertificate chiamata iniziale di Register per registrare il certificato CA, non avresti l'ARN del certificato CA da specificare nella `aws:SourceArn` condizione.](https://docs.aws.amazon.com/iot/latest/apireference/API_RegisterCACertificate.html)
Per ovviare a questo problema, ad esempio per specificare la policy di attendibilità del ruolo di provisioning per lo specifico certificato CA con cui è registrato AWS IoT Core, puoi fare quanto segue:
+ Innanzitutto, chiama [Register CACertificate](https://docs.aws.amazon.com/iot/latest/apireference/API_RegisterCACertificate.html) senza fornire il `RegistrationConfig` parametro.
+ Dopo aver registrato il certificato CA AWS IoT Core, chiama [Update CACertificate](https://docs.aws.amazon.com/iot/latest/apireference/API_UpdateCACertificate.html) su di esso.
Nella CACertificate chiamata Update, fornisci una policy `RegistrationConfig` che includa la policy di attendibilità del ruolo di provisioning `aws:SourceArn` impostata sull'ARN del certificato CA appena registrato.
### Fornitore di credenziali
Per il [provider di AWS IoT Core credenziali](https://docs.aws.amazon.com//iot/latest/developerguide/authorizing-direct-aws.html), usa lo stesso Account AWS che usi per creare l'alias del ruolo in `aws:SourceAccount` e specifica un'istruzione che corrisponda all'ARN della risorsa del tipo di risorsa rolealias in. `aws:SourceArn` Quando crei un ruolo IAM da utilizzare con il provider di AWS IoT Core credenziali, devi includere nella `aws:SourceArn` condizione gli alias ARNs di ruolo che potrebbero dover assumere il ruolo, autorizzando così la richiesta interservizio. `sts:AssumeRole`
Il ruolo con la seguente politica di fiducia può essere assunto solo dal principale fornitore di AWS IoT Core credenziali (`credentials.iot.amazonaws.com`) per il RoleAlias specificato in. `SourceArn` Se un principale tenta di recuperare le credenziali per un alias di ruolo diverso da quello specificato nella `aws:SourceArn` condizione, la richiesta verrà rifiutata, anche se l'altro alias del ruolo fa riferimento allo stesso ruolo IAM.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "credentials.iot.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "123456789012"
},
"ArnLike": {
"aws:SourceArn": "arn:aws:iot:us-east-1:123456789012:rolealias/example_rolealias"
}
}
}
]
}
```