View a markdown version of this page

Cross-service confusa prevenzione sostitutiva - AWS IoT Core
Esempi dettagliati di prevenzione confusa

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 confusa prevenzione sostitutiva

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 intersettoriale può portare al confuso problema del sostituto. Cross-service l'impersonificazione può verificarsi 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 assegnano un altro servizio alla risorsa, consigliamo di utilizzare le chiavi di contesto aws:SourceArne le chiavi di contesto della condizione aws:SourceAccountglobale 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 degli ID delle risorse consentiti. 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.

{
   "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

È possibile configurare il provisioning della flotta 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 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 policy di aws:SourceArn attendibilità dei AWS IoT ruoli dipende dalla modalità di definizione del 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 policy di fiducia può essere assunto solo dal principale IoT (iot.amazonaws.com) per il certificato CA specificato inSourceArn.

{
   "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 chiamata iniziale a RegisterCacertificate per registrare il certificato CA, non si avrebbe l'ARN del certificato CA da specificare nella condizione. aws:SourceArn

Per ovviare a questo problema, ad esempio per specificare la policy di attendibilità del ruolo di provisioning per lo specifico certificato CA con AWS IoT Core cui è registrato, puoi fare quanto segue:

  • Innanzitutto, chiamate RegisterCacertificate senza fornire il parametro. RegistrationConfig

  • Dopo aver registrato il certificato CA AWS IoT Core, chiamate UpdateCAertificate su di esso.

    Nella chiamata UpdateCAertificate, fornite RegistrationConfig una policy che includa la policy di trust 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, 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 si crea un ruolo IAM da utilizzare con un 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 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"
        }
      }
    }
  ]
}