SEC10-BP05 Preassegnazione dell'accesso

Verifica che le persone che intervengono dopo un incidente dispongano degli opportuni diritti di accesso allocati in AWS, così da ridurre i tempi necessari per l'analisi e il ripristino.

Anti-pattern comuni:

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

Guida all'implementazione

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 quelle di risposta agli incidenti, si consiglia di implementare la federazione delle identità insieme all'escalation temporanea per l'accesso amministrativo. 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. In caso di approvazione della richiesta, l'utente riceve una serie di credenziali AWS temporanee, utilizzabili per completare le proprie attività. Alla scadenza di tali 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 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:

Nei casi precedenti, occorre configurare l'accesso di emergenza break glass in modo da consentire l'indagine e la risoluzione tempestiva degli incidenti. È consigliabile ricorrere a utenti, gruppi o ruoli con le autorizzazioni opportune per l'esecuzione delle attività e l'accesso alle risorse AWS. Ricorri all'utente root solo per le attività che richiedono le credenziali dell'utente root. Per verificare che le persone che intervengono dopo un incidente dispongano del corretto livello di accesso ad AWS e ad altri sistemi pertinenti, ti consigliamo di eseguire la preallocazione di 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'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 si rischia la mancata revoca dei 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. A supporto di ciò, crea un playbook per verificare che gli utenti di risposta agli incidenti vengano creati come utenti in un account di sicurezza dedicato e non gestiti tramite una federazione esistente o una soluzione di autenticazione Single Sign-On (SSO) Ogni singola persona che interviene dopo un incidente deve avere il proprio account denominato. La configurazione dell'account deve applicare una policy delle password complesse e l'autenticazione a più fattori (MFA). Se i playbook di risposta agli incidenti richiedono solo l'accesso al AWS Management Console, non è necessario che l'utente disponga di chiavi di accesso configurate né che sia esplicitamente autorizzato a creare chiavi di accesso. Questo può essere configurato con policy IAM o policy di controllo dei servizi come menzionato nelle best practice di sicurezza di AWS per le AWS Organizations SCP. 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 adeguatamente monitorato e sottoposto ad audit, è essenziale che gli account IAM creati a tale scopo non siano condivisi tra le persone e che non si faccia ricorso all'Utente root dell'account AWS, salvo che non sia necessario per un'attività specifica. 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à delle credenziali di accesso dell'utente root e del token MFA.

Per configurare le policy IAM per i ruoli di risposta agli incidenti, prendi in considerazione l'utilizzo di IAM Access Analyzer per generare policy basate su 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. Puoi anche creare una policy IAM separata per ciascun playbook per semplificare gestione e audit. 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 i ruoli IAM dedicati di risposta agli incidenti in altri Account AWS. 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 denominare in modo chiaro gli account IAM e i ruoli IAM per trovarli facilmente nei log di CloudTrail. Un esempio potrebbe essere quello di denominare gli account IAM <USER_ID>-BREAK-GLASS e i ruoli IAM BREAK-GLASS-ROLE.

CloudTrail consente di creare log dell'attività delle API negli account AWS e va utilizzato per configurare gli avvisi sull'utilizzo dei ruoli di risposta agli incidenti. Fai riferimento al post del blog sulla configurazione degli avvisi quando vengono utilizzate le chiavi root. È possibile modificare le istruzioni in modo da configurare la metrica da filtro a filtro di Amazon CloudWatch sugli eventi AssumeRole relativi al ruolo IAM 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 membro del team di risposta richieda l'accesso a sistemi non direttamente protetti da IAM, ad esempio istanze Amazon Elastic Compute Cloud, database del servizio Amazon Relational Database o piattaforme Software-as-a-Service (SaaS). Si consiglia di utilizzare AWS Systems Manager Session Manager, anziché protocolli nativi come SSH o RDP per tutti gli accessi amministrativi alle istanze di Amazon EC2. Questo accesso può essere monitorato utilizzando IAM, che è sicuro e controllato. È 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 a database e strumenti di terze parti, ti consigliamo di archiviare le credenziali di accesso in AWS Secrets Manager e di concedere l'accesso ai ruoli delle persone che intervengono dopo gli incidenti.

Infine, la gestione degli account IAM per la risposta agli incidenti dovrebbe essere aggiunta ai processi degli utenti che si uniscono, si spostano o lasciano l'organizzazione e va riesaminata e testata periodicamente per verificare che sia consentito solo l'accesso previsto.

Risorse

Documenti correlati:

Video correlati:

Esempi correlati: