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à.
SEC10-BP05 Accesso preliminare alla fornitura
Verifica che i soccorritori dispongano in anticipo dell'accesso corretto AWS per ridurre il tempo necessario dalle indagini fino al ripristino.
Anti-pattern comuni:
-
Utilizzo dell'account root per la risposta agli incidenti.
-
Modifica degli account utente esistenti.
-
Manipolazione diretta delle autorizzazioni quando si fornisce l'IAMelevazione dei privilegi. just-in-time
Livello di rischio associato se questa best practice non fosse adottata: medio
Guida all'implementazione
AWS raccomanda di ridurre o eliminare la dipendenza da credenziali di lunga durata laddove possibile, a favore di credenziali temporanee e 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 quelle di risposta agli incidenti, si consiglia di implementare la federazione delle identità
Si consiglia l'uso dell'escalation temporanea dei privilegi nella maggior parte degli scenari di risposta agli incidenti. Il modo corretto per eseguire questa operazione prevede l'utilizzo di AWS Security Token Service e policy di sessione per definire l'ambito dell'accesso.
Esistono scenari in cui le identità federate non sono disponibili, come nei seguenti casi:
-
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 Distributed Denial of Service (DDoS) o l'indisponibilità del sistema.
Nei casi precedenti, occorre configurare l'accesso di emergenza break glass in modo da consentire l'indagine e la risoluzione tempestiva degli incidenti. Si consiglia di utilizzare un utente, un gruppo o un ruolo con le autorizzazioni appropriate per eseguire attività e accedere alle risorse. AWS Ricorri all'utente root solo per le attività che richiedono le credenziali dell'utente root. Per verificare che chi risponde agli incidenti disponga del livello di accesso corretto AWS e ad altri sistemi pertinenti, consigliamo di predisporre account dedicati. Gli account richiedono l'accesso con privilegi e devono essere rigorosamente controllati e monitorati. Gli account vanno 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.
Ricorri a utenti e ruoli specifici e dedicati come best practice. L'aumento temporaneo dell'accesso di utenti o ruoli attraverso l'aggiunta di IAM policy rende poco chiaro quale accesso avessero gli utenti durante l'incidente e rischia di non revocare i privilegi aumentati.
È importante rimuovere il maggior numero possibile di dipendenze per verificare che sia possibile ottenere l'accesso nel maggior numero possibile di scenari di errore. A tal fine, create un playbook per verificare che gli utenti che rispondono agli incidenti vengano creati come utenti in un account di sicurezza dedicato e non siano gestiti tramite alcuna soluzione Federation o Single Sign-on () esistente. SSO Ogni singola persona che interviene dopo un incidente deve avere il proprio account denominato. La configurazione dell'account deve applicare una politica di password avanzata e un'autenticazione a più fattori (). MFA Se i playbook di risposta agli incidenti richiedono solo l'accesso a AWS Management Console, l'utente non dovrebbe avere le chiavi di accesso configurate e dovrebbe essere esplicitamente impedito di creare chiavi di accesso. Questo può essere configurato con IAM policy o policy di controllo del servizio (SCPs) come indicato nelle AWS Security Best Practices for. AWS Organizations SCPs Gli utenti non devono disporre di privilegi oltre alla 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 la revoca immediata di qualsiasi accesso aggiuntivo immediatamente dopo la risoluzione dell'incidente.
Per verificare che l'uso dei ruoli di risposta agli incidenti possa essere monitorato e verificato correttamente, è essenziale che gli IAM account creati a tale scopo non siano condivisi tra individui e che non vengano utilizzati a meno che non siano necessari per un'attività specifica. Utente root dell'account AWS Se è richiesto l'utente root (ad esempio, IAM l'accesso a un account specifico non è disponibile), utilizzate un processo separato con un playbook disponibile per verificare la disponibilità delle credenziali e del token di accesso dell'utente root. MFA
Per configurare IAM le politiche per i ruoli di risposta agli incidenti, prendi in considerazione l'utilizzo di IAMAccess Analyzer per generare politiche basate sui log. AWS CloudTrail In questo caso, concedi l'accesso come amministratore al ruolo di risposta agli incidenti per un account non di produzione e segui i playbook. Al termine, potrà essere creata una policy che consenta solo le azioni da intraprendere. Questa policy potrà quindi essere applicata a tutti i ruoli di risposta agli incidenti in tutti gli account. Potresti voler creare una IAM policy separata per ogni playbook per consentire 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 di risposta agli incidenti per assumere IAMruoli dedicati alla risposta agli incidenti in altri. Account AWS Questi ruoli devono essere configurati in modo che possano essere assunti solo dagli utenti dell'account di sicurezza e la relazione di fiducia deve richiedere che il principale chiamante si sia autenticato utilizzando. MFA I ruoli devono utilizzare politiche ristrette per controllare l'accesso. IAM Assicurati che tutte le AssumeRole richieste per questi ruoli siano registrate CloudTrail e avvisate e che tutte le azioni intraprese utilizzando questi ruoli vengano registrate.
Si raccomanda vivamente che sia gli IAM account che i IAM ruoli abbiano nomi chiari per consentirne la facile individuazione nei log. CloudTrail Un esempio potrebbe essere quello di assegnare un nome agli IAM account <USER_ID>-BREAK-GLASSBREAK-GLASS-ROLE.
CloudTrailviene utilizzato per registrare le API attività negli AWS account e deve essere utilizzato per configurare gli avvisi sull'utilizzo dei ruoli di risposta agli incidentiAssumeRole eventi relativi al IAM ruolo di risposta agli incidenti:
{ $.eventName = "AssumeRole" && $.requestParameters.roleArn = "<INCIDENT_RESPONSE_ROLE_ARN>" && $.userIdentity.invokedBy NOT EXISTS && $.eventType != "AwsServiceEvent" }
Vista la probabilità che i ruoli di risposta agli incidenti abbiano un livello di accesso elevato, è importante che questi avvisi vengano inviati a un gruppo ampio e gestiti tempestivamente.
Durante un incidente, è possibile che un soccorritore richieda l'accesso a sistemi che non sono protetti direttamente da. IAM Queste potrebbero includere istanze Amazon Elastic Compute Cloud, database Amazon Relational Database Service o piattaforme ( software-as-a-serviceSaaS). Si consiglia vivamente di utilizzare, anziché utilizzare protocolli nativi come SSH orRDP, AWS Systems Manager Session Managerper tutti gli accessi amministrativi alle EC2 istanze di Amazon. Questo accesso può essere controllato utilizzandoIAM, che è sicuro e verificato. È inoltre possibile automatizzare parti dei playbook mediante i documenti AWS Systems Manager Run Command, in modo da ridurre gli errori degli utenti e migliorare i tempi di ripristino. Per l'accesso ai database e agli strumenti di terze parti, consigliamo di archiviare le credenziali di accesso AWS Secrets Manager e di concedere l'accesso ai ruoli di soccorritore agli incidenti.
Infine, la gestione degli IAM account di risposta agli incidenti deve essere aggiunta ai processi Joiners, Movers e Leavers e rivista e testata periodicamente per verificare che sia consentito solo l'accesso previsto.
Risorse
Documenti correlati:
Video correlati:
Esempi correlati:
