Configurazione dell'accesso alle API protetto da MFA

Con le policy IAM, è possibile specificare le operazioni API che un utente è autorizzato a chiamare. In alcuni casi, è consigliabile implementare un livello di sicurezza aggiuntivo, richiedendo agli utenti di eseguire la multi-factor authentication (MFA) in AWS prima di eseguire 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'azione distruttiva come TerminateInstances e assicurarti che gli utenti possano eseguire tale azione solo se si autenticano con un dispositivo AWS MFA.

Panoramica

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

1. L'amministratore configura un dispositivo AWS MFA per ogni utente che deve effettuare richieste API che richiedono l'autenticazione MFA. Questo processo viene descritto in Abilitazione dei dispositivi MFA per gli utenti in AWS.

2. L'amministratore crea politiche per gli utenti che includono un Condition elemento che verifica se l'utente si è autenticato con un dispositivo AWS MFA.

3. L'utente richiama una delle operazioni AWS STS API che supportano i parametri MFA AssumeRoleo GetSessionToken, a seconda dello scenario per la protezione MFA, come spiegato più avanti. 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 l'autorizzazione AWS fallisce, restituisce un messaggio di errore di accesso negato (come accade per qualsiasi accesso non autorizzato). Con le politiche API protette da MFA, AWS nega l'accesso alle operazioni API specificate nelle politiche se l'utente tenta di richiamare 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 politica, gli utenti Account AWS specificati nell'Principalelemento (sostituendo ACCOUNT-B-ID con un Account AWS ID valido) possono assumere il ruolo a cui è associata questa politica. ma solo se si sono autenticati tramite MFA.

{
  "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 AWS chiavi di contesto della condizione globale, Operatori di condizione numerici e Operatore di condizione per verificare la presenza di chiavi di condizione .

Scegliendo tra GetSessionToken e AssumeRole

AWS STS fornisce due operazioni API che consentono agli utenti di trasmettere 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:

• Chiama le operazioni API che accedono alle risorse nello Account AWS stesso modo in cui l'utente IAM effettua la richiesta. Tieni presente che le credenziali temporanee di una GetSessionToken richiesta possono accedere alle operazioni IAM e AWS STS API solo se includi 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 IAM o API. 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.

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 utilizzare 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 da utilizzare AWS con i servizi, quindi non possono AWS accedere alle risorse controllate dalla MFA. Vedi il punto successivo.

• Altre operazioni AWS STS API che restituiscono credenziali temporanee non supportano l'MFA. Per AssumeRoleWithWebIdentity eAssumeRoleWithSAML, l'utente è autenticato da un provider esterno e AWS non può determinare se tale provider abbia 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 Account AWS a un altro utente di accedere alle risorse del tuo account, la sicurezza delle tue risorse dipende dalla configurazione dell'account fidato (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 di accedere alle tue AWS risorse che richiedono l'autenticazione a più fattori, devi assicurarti che il proprietario dell'account fidato segua le migliori pratiche 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 di fiducia A, Anaya crea un ruolo IAM denominato CrossAccountRole e imposta come principale nella politica di fiducia del ruolo l'ID dell'account B. La politica di fiducia concede l'autorizzazione all'azione. AWS STS AssumeRole Anaya aggiunge inoltre una condizione MFA alla policy di trust, come nell'esempio seguente.

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

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

3. Nell'account attendibile B, l'amministratore si assicura che l'utente IAM Richard sia configurato con un dispositivo AWS MFA 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.

   {
     "Version": "2012-10-17",
     "Statement": [{
       "Effect": "Allow",
       "Action": ["sts:AssumeRole"],
       "Resource": ["arn:aws:iam::ACCOUNT-A-ID: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 chiamaAssumeRole, AWS determina se dispone di credenziali valide, incluso il requisito per l'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 AssumeRole Chiamate con autenticazione MFA.

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

In questo scenario, dovresti assicurarti che un tuo utente Account AWS possa accedere alle operazioni API sensibili solo quando l'utente è autenticato utilizzando un dispositivo AWS MFA.

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 sia configurata con un dispositivo AWS MFA e che Sofía 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.

   {
     "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 GetSessionToken Chiamate con 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. Vuoi assicurarti che tutti gli utenti Account AWS che accedono alla risorsa siano autenticati 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 che si trovano in diversi ambienti Account AWS, 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.

   {
     "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 GetSessionToken Chiamate con 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.