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

Problema del "confused deputy"

Con "confused deputy" si intende un problema di sicurezza in cui un'entità che non dispone dell’autorizzazione per eseguire una certa operazione può costringere un'entità con più privilegi a eseguire tale operazione. Per evitare che ciò accada, AWS fornisce strumenti che ti aiutano a proteggere il tuo account se fornisci a terzi (i cosiddetti cross-account) o ad altri AWS servizi (noti come cross-service) l'accesso alle risorse del tuo account.

A volte, potresti dover concedere a terzi l'accesso alle tue AWS risorse (accesso delegato). Ad esempio, supponiamo che tu decida di assumere una società terza chiamata Example Corp per monitorare Account AWS e ottimizzare i costi. Per tenere traccia delle spese giornaliere, Example Corp deve accedere alle tue AWS risorse. Example Corp ne monitora anche molte altre Account AWS per conto di altri clienti. Puoi utilizzare un ruolo IAM per stabilire una relazione di fiducia tra il tuo account Account AWS e quello di Example Corp. Un aspetto importante di questo scenario è l'ID esterno, informazioni facoltative che è possibile utilizzare in una policy di attendibilità del ruolo IAM per indicare chi può assumere il ruolo. La funzione principale dell'ID esterno è quella di risolvere e prevenire il problema del "confused deputy" (delegato confuso).

Nel frattempo AWS, l'impersonificazione tra servizi può portare al confuso problema del vice. 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.

Prevenzione del problema "confused deputy" tra account

Il seguente diagramma illustra il problema "confused deputy" tra account.

In questo scenario sono validi i requisiti riportati di seguito:

Ecco che cosa succede:

Questo è il modo in cui altri clienti possono ottenere l'accesso non autorizzato alle risorse di un utente, in questo caso dell'Utente A. Poiché il cliente Utente B è stato in grado di ingannare Example Corp e lo ha indotto ad agire involontariamente sulle risorse, Example Corp è ora un "confused deputy".

Example Corp può risolvere il problema "confused deputy" chiedendo di includere la condizione di verifica ExternalId nella policy di affidabilità del ruolo. Example Corp genera un valore ExternalId univoco per ogni cliente e lo utilizza nella sua richiesta per assumere il ruolo. Il valore ExternalId deve essere univoco tra i clienti di Example Corp e controllato da Example Corp, non dai suoi clienti. Questo è il motivo per cui i clienti lo ricevono da Example Corp e non lo creano in autonomia. In questo modo si evita che Example Corp si comporti in modo confuso e consenta l'accesso alle risorse di un altro account. AWS

In questo scenario, immagina che l'ID univoco di Example Corp per te sia 12345 e quello per l'altro cliente sia 67890. Questi ID sono semplificati per comodità in questo scenario. In genere, questi identificatori sono GUID. Supponendo che questi identificatori siano univoci tra i clienti di Example Corp, sono valori sensibili da utilizzare per l'ID esterno.

Example Corp ti fornisce il valore ID esterno 12345. È necessario aggiungere un elemento Condition alla policy di affidabilità del ruolo che richieda che il valore sts:ExternalId sia 12345, come segue:

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Principal": {
      "AWS": "Example Corp's AWS Account ID"
    },
    "Action": "sts:AssumeRole",
    "Condition": {
      "StringEquals": {
        "sts:ExternalId": "12345"
      }
    }
  }
}

L'elemento Condition di questa politica consente a Example Corp di assumere il ruolo solo quando la chiamata AssumeRole API include il valore ID esterno 12345. Example Corp si assicura che ogni volta che assume un ruolo per conto di un cliente, includa sempre il valore dell'ID esterno del cliente nella chiamata. AssumeRole Anche se un altro cliente fornisce a Example Corp il tuo ARN, non può controllare l'ID esterno che Example Corp include nella sua richiesta. AWS In questo modo è possibile evitare che un cliente non autorizzato acceda alle tue risorse.

Il diagramma seguente illustra tale processo.

L'ID esterno consente di impedire a qualsiasi altro cliente di ingannare Example Corp e indurre l'azienda ad accedere involontariamente alle risorse.

Prevenzione del problema "confused deputy" tra servizi

Si consiglia di utilizzare le chiavi di contesto delle condizioni globali aws:SourceArn, aws:SourceAccount, aws:SourceOrgID o aws:SourceOrgPaths nelle policy basate sulle risorse per limitare le autorizzazioni di un servizio nei confronti di una risorsa specifica. aws:SourceArnDa utilizzare per associare una sola risorsa all'accesso tra servizi. Utilizzato aws:SourceAccount per consentire che qualsiasi risorsa in quell'account venga associata all'utilizzo tra servizi. Utilizzato aws:SourceOrgID per consentire l'associazione di qualsiasi risorsa di qualsiasi account all'interno di un'organizzazione all'utilizzo tra servizi. Da utilizzare aws:SourceOrgPaths per associare qualsiasi risorsa proveniente dagli account all'interno di un AWS Organizations percorso all'utilizzo tra servizi. Per ulteriori informazioni sull’utilizzo e la conoscenza dei percorsi, consulta Comprendere il percorso dell’entità AWS Organizations.

Il modo più granulare per proteggersi dal problema "confused deputy" è quello di usare la chiave di contesto della condizione globale aws:SourceArn con l'ARN completo della risorsa nelle proprie policy basate sulle risorse. 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:servicename:*:123456789012:*.

Se il valore aws:SourceArn non contiene l'ID account, ad esempio un ARN di un bucket Amazon S3, è necessario utilizzare sia aws:SourceAccount che aws:SourceArn per limitare le autorizzazioni.

Per proteggersi dal problema "confused deputy" su larga scala, nelle policy basate sulle risorse utilizza la chiave di contesto della condizione globale aws:SourceOrgID o aws:SourceOrgPaths con l'ID dell'organizzazione o il percorso dell'organizzazione della risorsa. Quando aggiungi, rimuovi o sposti degli account all’interno dell’organizzazione, le policy che includono la chiave aws:SourceOrgID o aws:SourceOrgPaths includono automaticamente anche gli account corretti e non necessitano dell'aggiornamento manuale.

Per quanto riguarda le politiche di attendibilità dei non-service-linked ruoli, ogni servizio incluso nella politica di fiducia ha eseguito l'iam:PassRoleazione necessaria per verificare che il ruolo si trovi nello stesso account del servizio chiamante. Di conseguenza, l'utilizzo di aws:SourceAccount, aws:SourceOrgID o aws:SourceOrgPaths con tali policy di attendibilità non è necessario. L'utilizzo di aws:SourceArn in una politica di affidabilità consente di specificare le risorse di cui è possibile assumere un ruolo per conto, ad esempio una funzione Lambda ARN. Alcuni Servizi AWS utilizzano politiche di fiducia aws:SourceAccount e aws:SourceArn attendibilità per i ruoli appena creati, ma l'utilizzo delle chiavi non è necessario per i ruoli esistenti nel tuo account.

Prevenzione sostitutiva confusa tra diversi servizi per AWS Security Token Service

Molti AWS servizi richiedono l'utilizzo di ruoli per consentire al servizio di accedere alle risorse di un altro servizio per conto dell'utente. Un ruolo che un servizio assume per eseguire operazioni a tuo nome viene chiamato ruolo del servizio. Un ruolo richiede due policy: una policy di attendibilità del ruolo, che specifica il principale a cui è consentito assumere il ruolo, e una policy delle autorizzazioni, che specifica le operazioni da eseguire con il ruolo. Una policy di attendibilità del ruolo è l'unico tipo di policy basata sulle risorse in IAM. Altri Servizi AWS hanno politiche basate sulle risorse, come una policy sui bucket di Amazon S3.

Quando un servizio assume un ruolo per tuo conto, il principale del servizio deve essere autorizzato a svolgere l'operazione sts:AssumeRole nella policy di attendibilità del ruolo. Quando un servizio chiamasts:AssumeRole, AWS STS restituisce un set di credenziali di sicurezza temporanee che il responsabile del servizio utilizza per accedere alle risorse consentite dalla politica di autorizzazione del ruolo. Quando un servizio assume un ruolo nel tuo account, puoi includere le chiavi di contesto delle condizioni globali aws:SourceArn, aws:SourceAccount, aws:SourceOrgID o aws:SourceOrgPaths nella policy di attendibilità del ruolo per limitare l'accesso al ruolo solo alle richieste generate dalle risorse previste.

Ad esempio, in AWS Systems Manager Incident Manager, è necessario scegliere un ruolo per consentire a Incident Manager di eseguire un documento di automazione Systems Manager per conto dell'utente. Il documento di automazione può includere piani di risposta automatici per incidenti avviati da CloudWatch allarmi o eventi. EventBridge Nell'esempio seguente della policy di attendibilità del ruolo, è possibile utilizzare la chiave di condizione aws:SourceArn per limitare l'accesso al ruolo di servizio in base all'ARN del registro degli incidenti. Solo i registri degli incidenti creati dalla risorsa del piano di risposta myresponseplansono in grado di utilizzare questo ruolo.

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Principal": {
      "Service": "ssm-incidents.amazonaws.com"
    },
    "Action": "sts:AssumeRole",
    "Condition": {
      "ArnLike": {
        "aws:SourceArn": "arn:aws:ssm-incidents:*:111122223333:incident-record/myresponseplan/*"
      }
    }
  }
}