Accesso sicuro alle API con MFA - AWS Identity and Access Management
PanoramicaScenario: Protezione MFA per la delega tra accountScenario: Protezione MFA per l'accesso alle operazioni API nell'account correnteScenario: Protezione MFA per le risorse che hanno policy basate su risorse

Accesso sicuro alle API con MFA

Con le policy IAM, è possibile specificare le operazioni API che un utente è autorizzato a chiamare. È possibile applicare una sicurezza aggiuntiva richiedendo agli utenti di eseguire l'autenticazione a più fattori (MFA) prima di consentire l'esecuzione di operazioni particolarmente sensibili.

Potrebbe ad esempio esserci una policy che permette a un utente di eseguire le operazioni RunInstances, DescribeInstances e StopInstances di Amazon EC2. Ma potresti voler limitare un'operazione distruttiva come TerminateInstances e fare in modo che gli utenti possano eseguire tale operazione solo se eseguono l'autenticazione con un dispositivo MFA AWS.

Panoramica

L'aggiunta della protezione MFA alle operazioni API prevede le operazioni seguenti:

  1. L'amministratore configura un dispositivo MFA AWS per ogni utente che deve effettuare richieste API che richiedono l'autenticazione MFA. Per ulteriori informazioni, consulta Autenticazione a più fattori di AWS in IAM.

  2. L'amministratore crea policy per gli utenti che includono un elemento Condition che controlla se l'utente ha eseguito l'autenticazione con un dispositivo MFA AWS.

  3. L'utente chiama una delle operazioni API AWS STS che supportano i parametri MFA AssumeRole o GetSessionToken. Durante la chiamata, l'utente include l'ID dispositivo per il dispositivo associato all'utente. L'utente include anche la password una tantum a tempo (TOTP) generata dal dispositivo. In entrambi i casi, l'utente ottiene le credenziali di sicurezza temporanee che può quindi usare per effettuare richieste aggiuntive in AWS.

    Nota

    La protezione MFA per le operazioni API di un servizio è disponibile solo se il servizio supporta le credenziali di sicurezza temporanee. Per un elenco di questi servizi, consulta Utilizzo di credenziali di sicurezza temporanee per accedere ad AWS.

Se si verifica un errore di autorizzazione, AWS restituisce un messaggio di errore di accesso negato (come accade per i casi di accesso non autorizzato). Una volta implementate le policy per le API protette da MFA, AWS nega l'accesso alle operazioni API specificate nelle policy se l'utente cerca di chiamare un'operazione API senza un'autenticazione MFA valida. L'operazione viene rifiutata anche se il timestamp della richiesta di operazione API è al di fuori dell'intervallo consentito specificato nella policy. L'utente deve essere autenticato di nuovo con MFA richiedendo nuove credenziali di sicurezza temporanee con un codice MFA e il numero di serie del dispositivo.

Policy IAM con condizioni MFA

Le policy con condizioni MFA possono essere collegate a:

  • Un utente o un gruppo IAM

  • Una risorsa, ad esempio un bucket Amazon S3, una coda Amazon SQS o un argomento Amazon SNS

  • La policy di attendibilità di un ruolo IAM che può essere assunto da un utente

Puoi usare una condizione MFA in una policy per controllare le proprietà seguenti:

  • Esistenza: per verificare semplicemente che l'utente abbia eseguito l'autenticazione con MFA, controlla che la chiave aws:MultiFactorAuthPresent sia True in una condizione Bool. La chiave è presente solo quando l'utente esegue l'autenticazione con credenziali a breve termine. Le credenziali a lungo termine, ad esempio le chiavi di accesso, non includono questa chiave.

  • Durata: se desideri concedere l'accesso solo per un periodo di tempo specificato dopo l'autenticazione MFA, usa una condizione di tipo numerico per confrontare la validità della chiave aws:MultiFactorAuthAge con un valore (ad esempio 3.600 secondi). Ricordati che la chiave aws:MultiFactorAuthAge non è presente se non è stata usata l'autenticazione MFA.

L'esempio seguente mostra la policy di attendibilità di un ruolo IAM che include una condizione MFA da testare per verificare l'esistenza dell'autenticazione MFA. Con questa policy, gli utenti dall'Account AWS specificato nell'elemento Principal (sostituisci ACCOUNT-B-ID con un ID Account AWS valido) possono assumere il ruolo a cui la policy è collegata. ma solo se si sono autenticati tramite MFA.

JSON
{
  "Version":"2012-10-17",		 	 	 
  "Statement": {
    "Effect": "Allow",
    "Principal": {"AWS": "ACCOUNT-B-ID"},
    "Action": "sts:AssumeRole",
    "Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}}
  }
}

Per ulteriori informazioni sui tipi di condizioni per MFA, consulta AWSChiavi di contesto della condizione globale di , Operatori di condizione numerici e Operatore di condizione per verificare la presenza di chiavi di condizione .

Scelta tra GetSessionToken e AssumeRole

AWS STS fornisce due operazioni API che consentono agli utenti di passare le informazioni MFA: GetSessionToken e AssumeRole. L'operazione API che l'utente chiama per ottenere le credenziali di sicurezza temporanee dipende dallo scenario applicabile tra quelli descritti di seguito.

Usa GetSessionToken per gli scenari seguenti:

  • Chiamata alle operazioni API che accedono alle risorse nello stesso Account AWS dell'utente IAM che effettua la richiesta. Le credenziali temporanee di una richiesta GetSessionToken permettono di accedere alle operazioni IAM e dell'API AWS STS solo se si includono le informazioni MFA nella richiesta di credenziali. Poiché le credenziali temporanee restituite da GetSessionToken includono le informazioni MFA, puoi verificare l'MFA nelle singole operazioni API effettuate tramite le credenziali.

  • Accesso alle risorse protette con policy basate su risorse che includono una condizione MFA.

Lo scopo dell'operazione GetSessionToken è autenticare l'utente tramite MFA. Non è possibile utilizzare le policy per controllare le operazioni di autenticazione.

Usa AssumeRole per gli scenari seguenti:

  • Chiamata alle operazioni API che accedono alle risorse nello stesso Account AWS o in un account diverso. Le chiamate API possono includere qualsiasi API IAM o AWS STS. Per proteggere l'accesso, l'autenticazione MFA viene applicata quando l'utente assume il ruolo. Le credenziali temporanee restituite da AssumeRole non includono le informazioni MFA nel contesto, quindi non puoi verificare l'MFA nelle singole operazioni API. Per questo motivo, è necessario usare GetSessionToken per limitare l'accesso alle risorse protette da policy basate su risorse.

Nota

Quando l'utente IAM accede con MFA, i log AWS CloudTrail conterranno informazioni MFA. Se l'utente IAM assume un ruolo IAM, CloudTrail registrerà anche mfaAuthenticated: true negli attributi sessionContext per le operazioni eseguite utilizzando il ruolo assunto. Tuttavia, la registrazione di CloudTrail è separata da quella richiesta da IAM quando le chiamate API vengono effettuate con le credenziali del ruolo assunto. Per ulteriori informazioni, consulta l'argomento Elemento CloudTrail userIdentity.

Le informazioni su come implementare questi scenari vengono fornite più avanti in questo documento.

Considerazioni importanti sull'accesso alle API protetto da MFA

È importante comprendere i seguenti aspetti della protezione MFA per le operazioni API:

  • La protezione MFA è disponibile solo con le credenziali di sicurezza temporanee, che è possibile ottenere con AssumeRole o GetSessionToken.

  • Non è possibile usare l'accesso alle API protetto da MFA con credenziali Utente root dell'account AWS.

  • Non è possibile usare l'accesso alle API protetto da MFA con chiavi di sicurezza U2F.

  • Agli utenti federati non può essere assegnato un dispositivo MFA per l'uso con i servizi AWS, pertanto non possono accedere alle risorse AWS controllate da MFA. Vedi il punto successivo.

  • Altre operazioni API di AWS STS che restituiscono credenziali temporanee non supportano l'MFA. Per AssumeRoleWithWebIdentity e AssumeRoleWithSAML, l'utente viene autenticato da un provider esterno e AWS non è in grado di determinare se tale provider ha richiesto l'autenticazione MFA. Per GetFederationToken, l'autenticazione MFA non è necessariamente associata a un utente specifico.

  • Analogamente, le credenziali a lungo termine (chiavi di accesso dell'utente IAM e chiavi di accesso dell'utente root) non possono essere usate con l'accesso alle API protetto da MFA perché non scadono.

  • È possibile chiamare AssumeRole e GetSessionToken anche senza informazioni MFA. In tal caso, il chiamante riceve le credenziali di sicurezza temporanee, ma le informazioni di sessione per tali credenziali temporanee non indicano che l'utente ha eseguito l'autenticazione con MFA.

  • Per stabilire la protezione MFA per le operazioni API, aggiungi condizioni MFA alle policy. Una policy deve includere la chiave di condizione aws:MultiFactorAuthPresent per implementare l'uso dell'MFA. Per la delega tra più account, la policy di attendibilità del ruolo deve includere la chiave di condizione.

  • Quando consenti a un altro Account AWS di accedere alle risorse nel tuo account, la sicurezza delle risorse dipende dalla configurazione dell'account attendibile, ovvero l'altro account (non il tuo). Questo vale anche quando è richiesta la multi-factor authentication. Qualsiasi identità nell'account attendibile che dispone dell'autorizzazione per creare dispositivi MFA virtuali può creare un'attestazione MFA per soddisfare tale parte della policy di affidabilità del ruolo. Prima di consentire ai membri di un altro account l'accesso alle tue risorse AWS che richiedono la multi-factor authentication, assicurati che il proprietario dell'account attendibile segua le best practice di sicurezza. Ad esempio, l'account attendibile deve limitare l'accesso alle operazioni API sensibili, ad esempio le operazioni API di gestione dei dispositivi MFA, a identità attendibili specifiche.

  • Se una policy include una condizione MFA, una richiesta viene negata se gli utenti non sono stati autenticati tramite MFA oppure se forniscono una password TOTP o un identificatore di dispositivo MFA non valido.

Scenario: Protezione MFA per la delega tra account

In questo scenario desideri delegare l'accesso agli utenti IAM in un altro account, ma solo se gli utenti sono autenticati con un dispositivo MFA AWS. Per ulteriori informazioni sulla delega tra più account, consulta Termini e concetti dei ruoli.

Immagina di avere un account A (l'account che determina l'attendibilità, proprietario della risorsa a cui è necessario accedere), con l'utente IAM Anaya, che ha l'autorizzazione di amministratore. Anaya desidera concedere l'accesso all'utente Richard nell'account B (l'account attendibile), ma vuole assicurarsi che Richard sia autenticato con MFA prima di poter assumere il ruolo.

  1. Nell'account A che determina l'attendibilità, Anaya crea un ruolo IAM denominato CrossAccountRole e imposta il principale nella policy di attendibilità del ruolo sull'ID dell'account B. La policy di attendibilità concede l'autorizzazione per l'operazione AWS STS AssumeRole. Anaya aggiunge inoltre una condizione MFA alla policy di trust, come nell'esempio seguente.

    JSON
    {
  "Version":"2012-10-17",		 	 	 
  "Statement": {
    "Effect": "Allow",
    "Principal": {"AWS": "ACCOUNT-B-ID"},
    "Action": "sts:AssumeRole",
    "Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}}
  }
}

  2. Anaya aggiunge una policy di autorizzazione al ruolo che specifica le attività consentite per il ruolo. La policy di autorizzazione per un ruolo con protezione MFA è uguale a qualsiasi altra policy di autorizzazione di un ruolo. L'esempio seguente mostra la policy aggiunta al ruolo da Anaya, che consente a un utente ipotetico di eseguire qualsiasi operazione Amazon DynamoDB sulla tabella Books nell'account A. Questa policy consente anche l'operazione dynamodb:ListTables, necessaria per eseguire operazioni nella console.

    Nota

    La policy di autorizzazione non include una condizione MFA. È importante comprendere che l'autenticazione MFA viene usata solo per determinare se un utente può assumere tale ruolo. Una volta che l'utente ha assunto il ruolo, non vengono svolti ulteriori controlli MFA.

    JSON
    {
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "TableActions",
            "Effect": "Allow",
            "Action": "dynamodb:*",
            "Resource": "arn:aws:dynamodb:*:111122223333:table/Books"
        },
        {
            "Sid": "ListTables",
            "Effect": "Allow",
            "Action": "dynamodb:ListTables",
            "Resource": "*"
        }
    ]
}

  3. Nell'account attendibile B, l'amministratore verifica che l'utente IAM Richard sia configurato con un dispositivo MFA AWS e che conosca l'ID del dispositivo. ovvero il numero di serie se si tratta di un dispositivo MFA hardware o l'ARN del dispositivo se si tratta di un dispositivo MFA virtuale.

  4. Nell'account B, l'amministratore collega all'utente Richard (o un gruppo di cui è membro) la policy seguente, che gli permette di chiamare l'operazione AssumeRole. La risorsa è impostata sull'ARN del ruolo creato da Anaya nella fase 1. Osserva che questa policy non contiene una condizione MFA.

    JSON
    {
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "sts:AssumeRole"
            ],
            "Resource": [
                "arn:aws:iam::111122223333:role/CrossAccountRole"
            ]
        }
    ]
}

  5. Nell'account B, Richard (o un'applicazione che Richard sta eseguendo) chiama AssumeRole. La chiamata dell'API include l'ARN del ruolo da assumere (arn:aws:iam::ACCOUNT-A-ID:role/CrossAccountRole), l'ID del dispositivo MFA e la password TOTP corrente che Richard ottiene dal suo dispositivo.

    Quando Richard chiama AssumeRole, AWS determina se egli dispone di credenziali valide, incluso il requisito per MFA. In caso affermativo, Richard assume correttamente il ruolo e può eseguire qualsiasi operazione DynamoDB sulla tabella denominata Books nell'account A usando le credenziali temporanee del ruolo.

    Per un esempio di programma che chiama AssumeRole, consulta Chiamata di AssumeRole con l'autenticazione MFA.

Scenario: Protezione MFA per l'accesso alle operazioni API nell'account corrente

In questo scenario devi assicurarti che un utente nel tuo Account AWS possa accedere alle operazioni API sensibili solo quando viene autenticato con un dispositivo MFA AWS.

Immagina di avere un account A che contiene un gruppo di sviluppatori che devono usare le istanze EC2. In genere, gli sviluppatori possono usare le istanze, ma non hanno le autorizzazioni per le operazioni ec2:StopInstances e ec2:TerminateInstances. È opportuno limitare queste operazioni privilegiate "distruttive" a pochi utenti attendibili, quindi aggiungi la protezione MFA alla policy che permette queste operazioni Amazon EC2 sensibili.

In questo scenario, uno degli utenti attendibili è Sofía. L'utente Anaya è un amministratore nell'account A.

  1. Anaya si assicura che Sofía venga configurata con un dispositivo MFA AWS e che conosca l'ID del dispositivo. ovvero il numero di serie se si tratta di un dispositivo MFA hardware o l'ARN del dispositivo se si tratta di un dispositivo MFA virtuale.

  2. Anaya crea un gruppo denominato EC2-Admins e aggiunge l'utente Sofía al gruppo.

  3. Anaya collega la policy seguente al gruppo EC2-Admins. Questa policy concede agli utenti l'autorizzazione per chiamare le operazioni StopInstances e TerminateInstances di Amazon EC2 solo se l'utente ha eseguito l'autenticazione tramite MFA.

    JSON
    {
  "Version":"2012-10-17",		 	 	 
  "Statement": [{
    "Effect": "Allow",
    "Action": [
      "ec2:StopInstances",
      "ec2:TerminateInstances"
    ],
    "Resource": ["*"],
    "Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}}
  }]
}
  4. Nota

    Per rendere effettiva questa policy, gli utenti devono prima disconnettersi e quindi accedere nuovamente.

    Se l'utente Sofía deve arrestare o terminare un'istanza Amazon EC2, l'utente o un'applicazione da lei eseguita, chiama GetSessionToken. Questa operazione API passa l'ID o del dispositivo MFA e la password TOTP corrente che Sofía ottiene dal suo dispositivo.

  5. L'utente Sofía (o un'applicazione che Sofía sta usando) usa le credenziali temporanee fornite da GetSessionToken per chiamare l'operazione StopInstances o TerminateInstances di Amazon EC2.

    Per un esempio di programma che chiama GetSessionToken, consulta Chiamata di GetSessionToken con l'autenticazione MFA più avanti in questo documento.

Scenario: Protezione MFA per le risorse che hanno policy basate su risorse

In questo scenario, sei il proprietario di un bucket S3, una coda SQS o un argomento SNS. Devi accertarti che qualsiasi utente di qualsiasi Account AWS che accede alla risorsa sia autenticato da un dispositivo MFA AWS.

Questo scenario illustra un modo per fornire la protezione MFA per più account senza richiedere agli utenti di assumere prima un ruolo. In tal caso, l'utente può accedere alla risorsa se vengono soddisfatte tre condizioni: l'utente deve essere autenticato mediante MFA, essere in grado di ottenere credenziali di sicurezza temporanee da GetSessionToken ed essere in un account ritenuto attendibile dalla policy della risorsa.

Immagina di avere l'account A e di creare un bucket S3. Desideri concedere l'accesso a questo bucket agli utenti con Account AWS diversi, ma solo se tali utenti sono autenticati con MFA.

In questo scenario, l'utente Anaya è un amministratore nell'account A. L'utente Nikhil è un utente IAM nell'account C.

  1. Nell'account A, Anaya crea un bucket denominato Account-A-bucket.

  2. Anaya aggiunge la policy del bucket al bucket. La policy permette a qualsiasi utente in un account A, un account B o un account C di eseguire le operazioni PutObject e DeleteObject di Amazon S3 nel bucket. La policy include una condizione MFA.

    JSON
    {
  "Version":"2012-10-17",		 	 	 
  "Statement": [{
    "Effect": "Allow",
    "Principal": {"AWS": [
      "ACCOUNT-A-ID",
      "ACCOUNT-B-ID",
      "ACCOUNT-C-ID"
    ]},
    "Action": [
      "s3:PutObject",
      "s3:DeleteObject"
    ],
    "Resource": ["arn:aws:s3:::ACCOUNT-A-BUCKET-NAME/*"],
    "Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}}
  }]
}
    Nota

    Amazon S3 offre la funzionalità Cancellazione MFA solo per l'accesso all'account root. Puoi abilitare la funzionalità Cancellazione MFA di Amazon S3 quando imposti lo stato del controllo delle versioni del bucket. La funzionalità Cancellazione MFA di Amazon S3 non può essere applicata a un utente IAM e viene gestita indipendentemente dall'accesso alle API protetto da MFA. Un utente IAM con l'autorizzazione per eliminare un bucket non può eliminare un bucket quando la funzionalità Cancellazione MFA di Amazon S3 è abilitata. Per ulteriori informazioni sulla funzionalità Cancellazione MFA di Amazon S3, consulta Cancellazione MFA.

  3. Nell'account C, un amministratore verifica che l'utente Nikhil sia configurato con un dispositivo MFA AWS e che conosca l'ID del dispositivo. ovvero il numero di serie se si tratta di un dispositivo MFA hardware o l'ARN del dispositivo se si tratta di un dispositivo MFA virtuale.

  4. Nell'account C, Nikhil (o un'applicazione che lui sta eseguendo) chiama GetSessionToken. La chiamata include l'ID o l'ARN del dispositivo MFA e la password TOTP corrente che Nikhil ottiene dal suo dispositivo.

  5. Nikhil (o un'applicazione che lui sta usando) usa le credenziali temporanee restituite da GetSessionToken per chiamare l'operazione PutObject di Amazon S3 per caricare un file in Account-A-bucket.

    Per un esempio di programma che chiama GetSessionToken, consulta Chiamata di GetSessionToken con l'autenticazione MFA più avanti in questo documento.

    Nota

    Le credenziali temporanee che AssumeRole restituisce non funzionano in questo caso. Anche se l'utente è in grado di fornire informazioni MFA per assumere un ruolo, le credenziali temporanee restituite da AssumeRole non includono le informazioni MFA. Queste informazione sono necessarie per soddisfare la condizione MFA nella policy.