View a markdown version of this page

Cross-service prevenzione sostitutiva confusa - AWS IoT Core

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à.

Cross-service prevenzione sostitutiva confusa

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ò portare al confuso problema del vice. Cross-service l'imitazione può avvenire quando un servizio (il servizio chiamante) chiama 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 forniscono un altro servizio alla risorsa, consigliamo di utilizzare le chiavi di contesto della aws:SourceArn condizione aws: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. Per 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:* L'id della risorsa può essere il nome o l'ID della risorsa consentita o una dichiarazione jolly degli ID delle risorse consentiti. Assicurati che region corrisponda alla tua AWS IoT regione e all'ID del account-id tuo account cliente.

L'esempio seguente mostra come prevenire il problema confuso dei sostituti utilizzando aws:SourceArn le chiavi di contesto relative alla condizione aws:SourceAccount globale nella policy di fiducia dei AWS IoT ruoli. Per ulteriori esempi, consulta Esempi dettagliati di prevenzione sostitutiva confusa.

{ "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, è possibile che l'integrazione del servizio con AWS Security Token Service (STS) non supporti le chiavi di aws:SourceAccount contesto aws:SourceArn e.

Esempi dettagliati di prevenzione sostitutiva confusa

Questa sezione fornisce esempi dettagliati di come prevenire il problema della confusione dei sostituti utilizzando aws:SourceArn le chiavi di contesto relative alla condizione aws:SourceAccount globale nella politica di fiducia dei AWS IoT ruoli.

Provisioning del parco istanze

È possibile configurare il provisioning del parco veicoli utilizzando una risorsa modello di provisioning. Quando un modello di provisioning fa riferimento a un ruolo di provisioning, la policy di trust di quel ruolo può includere le aws:SourceArn chiavi di condizione e. aws:SourceAccount Queste chiavi limitano le risorse per le quali la configurazione può richiamare la richiesta. sts:AssumeRole

Il ruolo con la seguente politica di fiducia può essere assunto solo dal responsabile IoT (iot.amazonaws.com) per il modello di provisioning specificato nelSourceArn.

{ "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 provisioning just-in-time (JITP), è 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 politica di aws:SourceArn attendibilità del AWS IoT ruolo dipende da come si definisce il modello di provisioning.

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 inProvisioning del parco istanze.

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 politica di fiducia può essere assunto solo dal responsabile 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 le quali è possibile assumere il ruolo. Tuttavia, durante la chiamata iniziale a RegisterCAertificate per registrare il certificato CA, non è necessario specificare l'ARN del certificato CA nella condizione. aws:SourceArn

Per ovviare a questo problema, ad esempio per specificare la politica di attendibilità del ruolo di assegnazione allo specifico certificato CA registrato, puoi fare quanto segue: AWS IoT Core

Provider di credenziali

Per il provider di AWS IoT Core credenziali, usa lo stesso Account AWS che usi per creare l'alias di ruolo e specifica un'istruzione che corrisponda all'ARN della risorsa rolealias in. aws:SourceAccount aws:SourceArn Quando si crea un ruolo IAM da utilizzare con il provider di AWS IoT Core credenziali, è necessario includere nella aws:SourceArn condizione gli ARN di tutti gli alias di ruolo che potrebbero dover assumere il ruolo, autorizzando così la richiesta tra servizi. sts:AssumeRole

Il ruolo con la seguente politica di fiducia può essere assunto solo dal principale di AWS IoT Core credential provider (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à negata, anche se l'altro alias di 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" } } } ] }