# SEC10-BP05 Preassegnazione dell'accesso
<a name="sec_incident_response_pre_provision_access"></a>

Verifica che il team di risposta agli incidenti disponga degli opportuni diritti di accesso allocati in AWS per ridurre i tempi necessari per l'analisi e il ripristino.

 **Anti-pattern comuni:** 
+  L'utilizzo dell'account root per la risposta agli incidenti. 
+  La modifica degli account utente esistenti. 
+  La manipolazione diretta delle autorizzazioni IAM quando si fornisce l'elevazione dei privilegi just-in-time. 

 **Livello di rischio associato se questa best practice non fosse adottata:** medio 

## Guida all'implementazione
<a name="implementation-guidance"></a>

AWS raccomanda di ridurre o eliminare, ove possibile, la dipendenza da credenziali di lunga durata, a favore delle credenziali temporanee e dei meccanismi di escalation dei privilegi *just-in-time* . Le credenziali di lunga durata sono soggette a rischi per la sicurezza e aumentano il sovraccarico operativo. Per la maggior parte delle attività di gestione, nonché per le attività di risposta agli incidenti, consigliamo di implementare [la federazione delle identità](https://docs.aws.amazon.com/identity/federation/) insieme [all'escalation temporanea per l'accesso amministrativo](https://aws.amazon.com/blogs/security/managing-temporary-elevated-access-to-your-aws-environment/). In questo modello, un utente richiede l'elevazione a un livello di privilegio superiore (come un ruolo di risposta agli incidenti) e, se è idoneo all'elevazione, la richiesta viene inviata al responsabile dell'approvazione. Se la richiesta viene approvata, l'utente riceve un set di credenziali [AWS temporanee](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html) che può utilizzare per eseguire le sue attività. Alla scadenza di queste credenziali, l'utente deve inviare una nuova richiesta di elevazione.

 Si consiglia l'uso dell'escalation temporanea dei privilegi nella maggior parte degli scenari di risposta agli incidenti. Il modo corretto per farlo è utilizzare [AWS Security Token Service](https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html) e [le policy di sessione](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session) per definire l'ambito di accesso. 

 Esistono scenari in cui le identità federate non sono disponibili, come nei casi di: 
+  Interruzione correlata a un gestore dell'identità digitale (IdP) compromesso. 
+  Configurazione errata o errore umano che causa l'interruzione del sistema di gestione dell'accesso federato. 
+  Attività dannose come un evento DDoS (Distributed Denial of Service) o indisponibilità del sistema. 

 Nei casi precedenti, si deve configurare un accesso di emergenza *di tipo break-glass* per consentire l'analisi e la tempestiva risoluzione degli incidenti. Ti consigliamo di utilizzare [un utente IAM con le autorizzazioni appropriate](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#lock-away-credentials) per eseguire le attività e accedere alle risorse AWS. Utilizza le credenziali root solo per le [attività che richiedono l'accesso come utente root](https://docs.aws.amazon.com/accounts/latest/reference/root-user-tasks.html). Per verificare che i team di risposta agli incidenti dispongano del corretto livello di accesso ad AWS e ad altri sistemi pertinenti, ti consigliamo di eseguire la pre-assegnazione di account utente dedicati. Gli account utente richiedono l'accesso con privilegi e devono essere rigorosamente controllati e monitorati. Gli account devono essere creati con il minor numero di privilegi richiesti per eseguire le attività e il livello di accesso deve essere basato sui playbook inclusi nel piano di gestione degli incidenti. 

 Utilizza utenti e ruoli specifici e dedicati come best practice. L'escalation temporanea dell'accesso di utenti o ruoli tramite l'aggiunta di policy IAM rende poco chiaro quale fosse l'accesso degli utenti durante l'incidente e rischia di non revocare i privilegi oggetto di escalation. 

 È importante rimuovere il maggior numero possibile di dipendenze per verificare che sia possibile ottenere l'accesso nel maggior numero possibile di scenari di errore. Per supportare questa esigenza, crea un playbook per verificare che gli utenti dei team di risposta agli incidenti vengano creati come utenti AWS Identity and Access Management in un account di sicurezza dedicato e non gestiti tramite una federazione esistente o una soluzione di autenticazione unica (SSO). Ogni singolo utente dei team di risposta deve avere il proprio account denominato. La configurazione dell'account deve applicare [una policy di password complesse](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_account-policy.html) e l'autenticazione a più fattori (MFA). Se i playbook di risposta agli incidenti richiedono solo l'accesso alla Console di gestione AWS, non è necessario che l'utente disponga di chiavi di accesso configurate né che sia esplicitamente autorizzato a creare chiavi di accesso. A tale scopo è possibile configurare le policy IAM o le policy di controllo dei servizi come menzionato in AWS Security Best Practices (Best practice di sicurezza AWS) per [le policy di controllo dei servizi AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html). Gli utenti non devono avere privilegi oltre la capacità di assumere i ruoli di risposta agli incidenti in altri account. 

 Durante un incidente potrebbe essere necessario concedere l'accesso ad altre persone interne o esterne per supportare le attività di analisi, correzione o ripristino. In questo caso, utilizza il meccanismo del playbook menzionato in precedenza e un processo per verificare che qualsiasi accesso aggiuntivo venga revocato immediatamente dopo il completamento dell'incidente. 

 Per verificare che l'uso dei ruoli di risposta agli incidenti possa essere adeguatamente monitorato e controllato, è essenziale che gli account utente IAM creati a tale scopo non siano condivisi tra le persone e che l'utente root Account AWS non venga utilizzato se [non per un'attività specifica](https://docs.aws.amazon.com/accounts/latest/reference/root-user-tasks.html). Se è richiesto l'utente root (ad esempio, l'accesso IAM a un account specifico non è disponibile), utilizza un processo separato con un playbook disponibile per verificare la disponibilità della password dell'utente root e del token MFA. 

 Per configurare le policy IAM per i ruoli di risposta agli incidenti, prendi in considerazione di usare [IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html) per generare le policy sulla base dei log AWS CloudTrail. In questo caso, concedi l'accesso come amministratore al ruolo di risposta agli incidenti per un account non di produzione ed esegui i playbook. Al termine, potrà essere creata una policy che consenta solo le azioni da intraprendere. Questa policy può quindi essere applicata a tutti i ruoli di risposta agli incidenti in tutti gli account. Puoi anche creare una policy IAM separata per ogni playbook per avere una gestione e un controllo più semplici. Esempi di playbook possono essere piani di risposta per ransomware, violazioni dei dati, perdita dell'accesso alla produzione e altri scenari. 

 Utilizza gli account utente di risposta agli incidenti per assumere i ruoli di risposta [IAM dedicati in altri Account AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html). Questi ruoli devono essere configurati in modo che possano essere assunti solo dagli utenti nell'account di sicurezza e la relazione di trust deve richiedere che il principale chiamante sia autenticato tramite MFA. I ruoli devono utilizzare policy IAM con ambito limitato per controllare l'accesso. Assicurati che tutte le richieste `AssumeRole` per questi ruoli vengano registrate in CloudTrail e notificate e che tutte le azioni intraprese utilizzando questi ruoli vengano registrate. 

 Ti consigliamo vivamente di nominare chiaramente gli account utente IAM e i ruoli IAM per trovarli facilmente nei log CloudTrail. Un esempio potrebbe essere quello di nominare gli account IAM `<ID_UTENTE>-BREAK-GLASS` e i ruoli IAM `RUOLO-BREAK-GLASS`. 

 [CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html) viene utilizzato per registrare l'attività API negli account AWS e deve essere utilizzato per [configurare gli avvisi sull'utilizzo dei ruoli di risposta agli incidenti](https://aws.amazon.com/blogs/security/how-to-receive-notifications-when-your-aws-accounts-root-access-keys-are-used/). Fai riferimento al post del blog sulla configurazione degli avvisi quando vengono utilizzate le chiavi root. Le istruzioni possono essere modificate per configurare il parametro [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) da filtro a filtro negli eventi `AssumeRole` correlati al ruolo IAM di risposta agli incidenti: 

```
{ $.eventName = "AssumeRole" && $.requestParameters.roleArn = "<ARN_RUOLO_DI_RISPOSTA_AGLI_INCIDENTI>" && $.userIdentity.invokedBy NOT EXISTS && $.eventType != "AwsServiceEvent" }
```

 Poiché è probabile che i ruoli di risposta agli incidenti abbiano un livello di accesso elevato, è importante che questi avvisi vengano inviati a un gruppo ampio e vengano gestiti tempestivamente. 

 Durante un incidente, è possibile che un membro del team di risposta richieda l'accesso a sistemi che non sono direttamente protetti da IAM, ad esempio istanze Amazon Elastic Compute Cloud, database Amazon Relational Database Service o piattaforme Software-as-a-service (SaaS). Anziché i protocolli nativi come SSH o RDP, ti consigliamo vivamente di utilizzare [AWS Systems Manager Session Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html) per l'accesso amministrativo completo alle istanze Amazon EC2. Questo accesso può essere monitorato utilizzando IAM, che è sicuro e controllato. Puoi anche automatizzare parti dei tuoi playbook utilizzando i documenti di [AWS Systems Manager Run Command](https://docs.aws.amazon.com/systems-manager/latest/userguide/execute-remote-commands.html)che possono ridurre gli errori dell'utente e migliorare i tempi di ripristino. Per l'accesso a database e strumenti di terze parti, ti consigliamo di archiviare le credenziali di accesso in Gestione dei segreti AWS e di concedere l'accesso ai ruoli degli utenti dei team di risposta agli incidenti. 

 Infine, la gestione degli account utente IAM di risposta agli incidenti deve essere aggiunta ai processi [degli utenti che si uniscono, si spostano o lasciano l'organizzazione](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/permissions-management.html) e deve rivista e testata periodicamente per verificare che sia consentito solo l'accesso previsto. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Managing temporary elevated access to your AWS environment (Gestione dell'accesso temporaneo con privilegi elevati all'ambiente AWS)](https://aws.amazon.com/blogs/security/managing-temporary-elevated-access-to-your-aws-environment/) 
+  [AWS Security Incident Response Guide (Guida alle risposte agli incidenti di sicurezza di AWS) ](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html)
+  [AWS Elastic Disaster Recovery](https://aws.amazon.com/disaster-recovery/) 
+  [Strumento di gestione degli incidenti AWS Systems Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/what-is-incident-manager.html) 
+  [Impostazione di una policy delle password dell'account per utenti IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_account-policy.html) 
+  [Utilizzo dell'autenticazione a più fattori (MFA) in AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html) 
+ [ Configuring Cross-Account Access with MFA (Configurazione dell'accesso multi-account con MFA) ](https://aws.amazon.com/blogs/security/how-do-i-protect-cross-account-access-using-mfa-2/)
+ [ Using IAM Access Analyzer to generate IAM policies (Utilizzo di IAM Access Analyzer per generare policy IAM) ](https://aws.amazon.com/blogs/security/use-iam-access-analyzer-to-generate-iam-policies-based-on-access-activity-found-in-your-organization-trail/)
+ [ Best Practices for AWS Organizations Service Control Policies in a Multi-Account Environment (Best practice per le policy di controllo dei servizi di AWS Organizations in un ambiente multi-account) ](https://aws.amazon.com/blogs/industries/best-practices-for-aws-organizations-service-control-policies-in-a-multi-account-environment/)
+ [ How to Receive Notifications When Your AWS Account’s Root Access Keys Are Used (Come ricevere le notifiche quando vengono utilizzate le chiavi di accesso root dell'account AWS) ](https://aws.amazon.com/blogs/security/how-to-receive-notifications-when-your-aws-accounts-root-access-keys-are-used/)
+ [ Create fine-grained session permissions using IAM managed policies (Creazione di autorizzazioni di sessione dettagliate utilizzando le policy gestite da IAM) ](https://aws.amazon.com/blogs/security/create-fine-grained-session-permissions-using-iam-managed-policies/)

 **Video correlati:** 
+ [ Automating Incident Response and ForensicsAWS](https://www.youtube.com/watch?v=f_EcwmmXkXk)
+  [DIY guide to runbooks, incident reports, and incident response](https://youtu.be/E1NaYN_fJUo) 
+ [ Prepare for and respond to security incidents in your AWS environment ](https://www.youtube.com/watch?v=8uiO0Z5meCs)

 **Esempi correlati:** 
+ [ Lab: AWS Account Setup and Root User (Laboratorio: configurazione dell'account AWS e dell'utente root) ](https://www.wellarchitectedlabs.com/security/300_labs/300_incident_response_playbook_with_jupyter-aws_iam/)
+ [ Lab: Incident Response with AWS Console and CLI (Laboratorio: risposta agli incidenti con la Console AWS e l'interfaccia della riga di comando) ](https://wellarchitectedlabs.com/security/300_labs/300_incident_response_with_aws_console_and_cli/)