SEC03-BP03 Stabilire un processo di accesso di emergenza - Pilastro della sicurezza
Guida all'implementazione Risorse

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à.

SEC03-BP03 Stabilire un processo di accesso di emergenza

Crea un processo che consenta l'accesso di emergenza ai tuoi carichi di lavoro nell'improbabile eventualità che si verifichi un problema con il tuo gestore dell'identità digitale centralizzato.

Devi progettare processi per diverse modalità di guasto che potrebbero causare un evento di emergenza. Ad esempio, in circostanze normali, gli utenti della forza lavoro si federano al cloud utilizzando un provider di identità centralizzato (SEC02-BP04) per gestire i propri carichi di lavoro. Tuttavia, se il tuo gestore dell'identità digitale centralizzato riscontra un errore o la configurazione per la federazione nel cloud subisce modifiche, gli utenti della tua forza lavoro potrebbero non essere in grado di federarsi nel cloud. Un processo di accesso di emergenza consente agli amministratori autorizzati di accedere alle risorse cloud tramite mezzi alternativi (come una forma alternativa di federazione o l'accesso diretto degli utenti) per risolvere problemi relativi alla configurazione della federazione o ai carichi di lavoro. Si ricorre al processo di accesso di emergenza fino al ripristino del normale meccanismo di federazione.

Risultato desiderato:

  • Hai definito e documentato le modalità di guasto che costituiscono un'emergenza: considera le circostanze normali e i sistemi da cui dipendono gli utenti per gestire i loro carichi di lavoro. Prendi in considerazione quali guasti possono interessare ciascuna di queste dipendenze e causare una situazione di emergenza. Potresti trovare utili le domande e le best practice del pilastro dell'affidabilità per individuare le modalità di errore e progettare sistemi più resilienti al fine di ridurre al minimo la probabilità di guasti.

  • Hai documentato i passaggi da seguire per confermare che un guasto costituisce un'emergenza. Ad esempio, puoi richiedere agli amministratori di identità di controllare lo stato dei gestori delle identità digitali primari e di standby e, se entrambi non sono disponibili, dichiarare un evento di emergenza per guasto del gestore dell'identità digitale.

  • È stato definito un processo di accesso di emergenza specifico per ogni tipo di modalità di emergenza o di guasto. Essere specifici può ridurre la tentazione da parte degli utenti di abusare di un processo generale per tutti i tipi di emergenze. I processi di accesso di emergenza illustrano le circostanze in cui ciascun processo va o non va utilizzato e indicano processi alternativi applicabili.

  • I tuoi processi sono ben documentati con istruzioni e playbook dettagliati, facili da mettere in pratica in modo rapido ed efficiente. Ricorda che un evento di emergenza può essere un momento stressante per i tuoi utenti, che potrebbero essere sotto pressione per motivi di tempo, quindi progetta il tuo processo in modo che sia il più semplice possibile.

Anti-pattern comuni:

  • Non si dispone di procedure di accesso di emergenza ben documentate e collaudate. Gli utenti non sono preparati per un'emergenza e seguono processi improvvisati quando si verifica un evento di emergenza.

  • I processi di accesso di emergenza dipendono dagli stessi sistemi (come un gestore dell'identità digitale centralizzato) dei normali meccanismi di accesso. Ciò significa che il guasto di un sistema di questo tipo può influire sui normali meccanismi di accesso e di emergenza e compromettere la capacità di ripristino dall'errore.

  • I processi di accesso di emergenza vengono utilizzati in situazioni non di emergenza. Ad esempio, gli utenti utilizzano spesso in modo improprio i processi di accesso di emergenza poiché trovano più facile apportare modifiche direttamente piuttosto che inviarle tramite una pipeline.

  • I processi di accesso di emergenza non generano log sufficienti per effettuare l'audit dei processi oppure i log non vengono monitorati per segnalare un potenziale uso improprio dei processi.

Vantaggi dell'adozione di questa best practice:

  • Grazie a processi di accesso di emergenza ben documentati e collaudati, puoi ridurre il tempo impiegato dagli utenti per rispondere a un evento di emergenza e risolverlo. Ciò può comportare una riduzione dei tempi di inattività e una maggiore disponibilità dei servizi forniti ai clienti.

  • È possibile tenere traccia di ogni richiesta di accesso di emergenza e rilevare e segnalare i casi di tentativi non autorizzati di uso improprio del processo per eventi non di emergenza.

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

Guida all'implementazione

Questa sezione fornisce indicazioni per la creazione di processi di accesso di emergenza per diverse modalità di errore relative ai carichi di lavoro distribuiti AWS, a partire da linee guida comuni che si applicano a tutte le modalità di errore e seguite da linee guida specifiche basate sul tipo di modalità di errore.

Linee guida comuni per tutte le modalità di errore

Nella progettazione di un processo di accesso di emergenza per una modalità di errore, tieni presente quanto segue:

  • Documenta prerequisiti e presupposti del processo: quando il processo deve e non deve essere utilizzato. Aiuta a descrivere in dettaglio la modalità di errore e a documentare le ipotesi, come lo stato di altri sistemi correlati. Ad esempio, il processo per la Failure Mode 2 presuppone che il provider di identità sia disponibile, ma la configurazione attivata AWS sia stata modificata o sia scaduta.

  • Precrea le risorse necessarie per il processo di accesso di emergenza (SEC10-BP05). Ad esempio, precrea l'accesso di emergenza Account AWS con IAM utenti e ruoli e i ruoli tra account in tutti gli account del carico di lavoroIAM. Ciò assicura che queste risorse siano pronte e disponibili quando si verifica un evento di emergenza. Creando prima le risorse, non si ha alcuna dipendenza dal piano di AWS controllo APIs (utilizzato per creare e modificare AWS le risorse) che potrebbe non essere disponibile in caso di emergenza. Inoltre, precreando IAM le risorse, non è necessario tenere conto dei potenziali ritardi dovuti all'eventuale coerenza.

  • Includi i processi di accesso di emergenza come parte dei tuoi piani di gestione degli incidenti (SEC10-BP02). Documenta le modalità in cui si tiene traccia degli eventi di emergenza e come questi vengono comunicati ad altri membri dell'organizzazione, come i team di pari livello, la leadership e, se applicabile, esternamente ai clienti e ai partner aziendali.

  • Definisci il processo di richiesta di accesso di emergenza nel tuo sistema di flusso di lavoro esistente, se ne hai uno, per le richieste di assistenza. In genere, tali sistemi di flusso di lavoro consentono di creare moduli di acquisizione per raccogliere informazioni sulla richiesta, tenere traccia della richiesta in ogni fase del flusso di lavoro e aggiungere passaggi di approvazione automatici e manuali. Collega ciascuna richiesta a un evento di emergenza corrispondente tracciato nel tuo sistema di gestione degli incidenti. Disporre di un sistema uniforme per gli accessi di emergenza consente di tenere traccia di tali richieste in un unico sistema, analizzare le tendenze di utilizzo e migliorare i processi.

  • Verifica che i processi di accesso di emergenza possano essere avviati solo da utenti autorizzati e richiedano l'approvazione di colleghi o manager dell'utente, a seconda dei casi. Il processo di approvazione deve funzionare in modo efficacie sia all'interno sia al di fuori dell'orario lavorativo. Definisci in che modo le richieste di approvazione possono essere eseguite da approvatori secondari, qualora gli approvatori principali non fossero disponibili, e come vengono inoltrate lungo la catena di gestione fino all'approvazione.

  • Verifica che il processo generi log di audit ed eventi dettagliati per i tentativi riusciti e non andati a buon fine di ottenere l'accesso di emergenza. Monitora sia il processo di richiesta sia il meccanismo di accesso di emergenza per rilevare usi impropri o accessi non autorizzati. Metti in correlazione l'attività con gli eventi di emergenza in corso dal tuo sistema di gestione degli incidenti e segnala i casi in cui le azioni si verificano al di fuori dei periodi di tempo previsti. Ad esempio, devi monitorare e inviare avvisi in merito ad attività nell' Account AWS di accesso di emergenza, poiché non dovrebbe mai essere utilizzato per le normali operazioni.

  • Testa periodicamente i processi di accesso di emergenza per verificare che i passaggi siano chiari e garantire il livello di accesso corretto in modo rapido ed efficiente. I processi di accesso di emergenza devono essere testati nell'ambito delle simulazioni di risposta agli incidenti (SEC10-BP07) e dei test di disaster recovery (-BP03). REL13

Modalità di errore 1: il provider di identità utilizzato per la federazione non è disponibile AWS

Come descritto in SEC02-BP04 Affidati a un provider di identità centralizzato, ti consigliamo di affidarti a un provider di identità centralizzato per federare la forza lavoro a cui concedere l'accesso agli utenti. Account AWSÈ possibile eseguire la federazione tra più membri AWS dell'organizzazione utilizzando IAM Identity Center Account AWS oppure è possibile eseguire la federazione per uso individuale. Account AWS IAM In entrambi i casi, gli utenti della forza lavoro si autenticano con il gestore dell'identità digitale centralizzato prima di essere reindirizzati a un endpoint di accesso AWS per l'autenticazione unica.

Nell'improbabile eventualità che il gestore dell'identità digitale centralizzato non sia disponibile, gli utenti della tua forza lavoro non possono federarsi per accedere agli Account AWS o gestire i propri carichi di lavoro. In questo caso di emergenza, puoi fornire una procedura di accesso di emergenza a cui un piccolo gruppo di amministratori può accedere per Account AWS eseguire attività critiche che non possono attendere che i provider di identità centralizzati tornino online. Ad esempio, il tuo provider di identità non è disponibile per 4 ore e durante quel periodo devi modificare i limiti superiori di un gruppo Amazon EC2 Auto Scaling in un account di produzione per gestire un picco imprevisto nel traffico dei clienti. Gli amministratori di emergenza devono seguire la procedura di accesso di emergenza per accedere alla produzione specifica Account AWS e apportare le modifiche necessarie.

Il processo di accesso di emergenza si basa su un accesso di emergenza precreato Account AWS che viene utilizzato esclusivamente per l'accesso di emergenza e dispone di AWS risorse (come IAM ruoli e IAM utenti) per supportare il processo di accesso di emergenza. Durante le normali operazioni, nessuno deve accedere all'account di accesso di emergenza ed è necessario monitorare e fornire avvisi riguardo a usi impropri di questo account (per maggiori dettagli, vedi la sezione precedente Linee guida comuni).

L'account per l'accesso di emergenza dispone di IAM ruoli di accesso di emergenza con autorizzazioni per assumere ruoli tra account diversi in quelli Account AWS che richiedono l'accesso di emergenza. Questi IAM ruoli sono precreati e configurati con politiche di fiducia che considerano attendibili i ruoli dell'account di emergenza. IAM

Per il processo di accesso di emergenza è possibile utilizzare uno dei seguenti approcci:

  • È possibile precreare un set di IAMutenti per gli amministratori di emergenza nell'account di accesso di emergenza con password e token complessi associati. MFA Questi IAM utenti dispongono delle autorizzazioni per assumere i IAM ruoli che consentono quindi l'accesso da più account all'area in cui è richiesto l' Account AWS accesso di emergenza. Ti consigliamo di creare il minor numero possibile di utenti di questo tipo e di assegnare ogni utente a un unico amministratore di emergenza. Durante un'emergenza, un utente amministratore di emergenza accede all'account di accesso di emergenza utilizzando la propria password e il codice MFA token, passa al IAM ruolo di accesso di emergenza nell'account di emergenza e infine passa al IAM ruolo di accesso di emergenza nell'account del carico di lavoro per eseguire l'azione di modifica di emergenza. Il vantaggio di questo approccio è che ogni IAM utente viene assegnato a un amministratore di emergenza ed è possibile sapere quale utente ha effettuato l'accesso esaminando gli eventi. CloudTrail Lo svantaggio è che è necessario mantenere più IAM utenti con le password e i token di lunga durata associati. MFA

  • È possibile utilizzare l'utente Account AWS root per l'accesso di emergenza per accedere all'account di accesso di emergenza, assumere il IAM ruolo di accesso di emergenza e assumere il ruolo multiaccount nell'account del carico di lavoro. Ti consigliamo di impostare una password sicura e più MFA token per l'utente root. Consigliamo inoltre di archiviare la password e i MFA token in un archivio di credenziali aziendali sicuro che applichi un'autenticazione e un'autorizzazione avanzate. È necessario proteggere i fattori di reimpostazione della password e del MFA token: imposta l'indirizzo e-mail dell'account in una lista di distribuzione e-mail monitorata dagli amministratori della sicurezza del cloud e il numero di telefono dell'account su un numero di telefono condiviso monitorato anche dagli amministratori della sicurezza. Il vantaggio di questo approccio è l'esistenza di un solo set di credenziali utente root da gestire. Lo svantaggio è che, trattandosi di un utente condiviso, più amministratori hanno la possibilità di accedere come utente root. Controlla gli eventi del log del tuo vault aziendale per identificare quale amministratore ha utilizzato la password dell'utente root.

Modalità di errore 2: la configurazione del provider di identità attiva AWS è stata modificata o è scaduta

Per consentire agli utenti della forza lavoro di effettuare la federazione Account AWS, è possibile configurare l'IAMIdentity Center con un provider di identità esterno o creare un IAM provider di identità (SEC02-BP04). In genere, li configuri importando un documento di SAML XML metadati fornito dal tuo provider di identità. Il XML documento di metadati include un certificato X.509 corrispondente a una chiave privata utilizzata dal provider di identità per firmare le proprie asserzioni. SAML

Queste configurazioni sul AWS lato -possono essere modificate o eliminate per errore da un amministratore. In un altro scenario, il certificato X.509 importato in AWS potrebbe scadere e i nuovi metadati XML con un nuovo certificato non sono ancora stati importati in. AWS Entrambi gli scenari possono interrompere la federazione degli utenti della forza lavoro, con conseguente emergenza. AWS

In un caso di emergenza di questo tipo, puoi fornire agli amministratori delle identità l'accesso AWS a cui risolvere i problemi di federazione. Ad esempio, l'amministratore delle identità utilizza la procedura di accesso di emergenza per accedere all'accesso di emergenza Account AWS, passa a un ruolo nell'account amministratore dell'Identity Center e aggiorna la configurazione del provider di identità esterno importando il XML documento di SAML metadati più recente dal provider di identità per riattivare la federazione. Una volta ristabilita la federazione, gli utenti della forza lavoro continuano a utilizzare il normale processo operativo per federare l'accesso ai propri account di carico di lavoro.

È possibile seguire gli approcci illustrati nella sezione precedente Modalità di errore 1 per creare un processo di accesso di emergenza. Puoi concedere le autorizzazioni con il privilegio minimo agli amministratori delle identità per accedere solo all'account amministratore di Centro identità ed eseguire azioni in Centro identità in quell'account.

Modalità di errore 3: blocco del Centro identità

Nell'improbabile eventualità di un IAM Identity Center o di un' Regione AWS interruzione, ti consigliamo di configurare una configurazione da utilizzare per fornire un accesso temporaneo a. AWS Management Console

Il processo di accesso di emergenza utilizza la federazione diretta dal provider di identità IAM a un account di emergenza. Per informazioni dettagliate sul processo e sulle considerazioni di progettazione, consulta Set up emergency access to the AWS Management Console.

Passaggi dell'implementazione

Passaggi comuni per tutte le modalità di errore

  • Creane uno Account AWS dedicato ai processi di accesso di emergenza. Precrea le IAM risorse necessarie nell'account, ad esempio IAM ruoli o IAM utenti e, facoltativamente, gli IAM Identity Provider. Inoltre, crea in anticipo IAM ruoli interaccount nel carico di lavoro con relazioni di fiducia Account AWS con i IAM ruoli corrispondenti nell'account per l'accesso di emergenza. Puoi utilizzare AWS CloudFormation StackSets with AWS Organizations per creare tali risorse negli account dei membri della tua organizzazione.

  • Crea politiche di controllo del AWS Organizations servizio (SCPs) per negare l'eliminazione e la modifica dei IAM ruoli tra account diversi nel membro. Account AWS

  • Abilita CloudTrail l'accesso di emergenza Account AWS e invia gli eventi del percorso a un bucket S3 centrale nella tua raccolta di log. Account AWS Se lo utilizzi AWS Control Tower per configurare e gestire il tuo ambiente AWS multi-account, ogni account che crei utilizzando AWS Control Tower o a cui ti registri AWS Control Tower è CloudTrail abilitato per impostazione predefinita e inviato a un bucket S3 in un archivio di log dedicato. Account AWS

  • Monitora l'attività dell'account con accesso di emergenza creando EventBridge regole che corrispondano all'accesso alla console e all'APIattività dei ruoli di emergenza. IAM Invia notifiche al tuo centro operativo di sicurezza quando si verificano attività al di fuori di un evento di emergenza in corso e di cui hai traccia nel tuo sistema di gestione degli incidenti.

Passaggi aggiuntivi per la modalità di errore 1: il provider di identità utilizzato per la federazione non AWS è disponibile e la modalità di errore 2: la configurazione del provider di identità attiva AWS è stata modificata o è scaduta

  • Crea preliminarmente le risorse in base al meccanismo scelto per l'accesso di emergenza:

    • Utilizzo IAM degli utenti: precrea gli IAM utenti con password complesse e dispositivi associati. MFA

    • Utilizzando l'utente utente root dell'account di emergenza: configura l'utente root con una password sicura e archivia la password nel tuo vault di credenziali aziendali. Associa più MFA dispositivi fisici all'utente root e archivia i dispositivi in posizioni a cui possono accedere rapidamente i membri del team di amministrazione delle emergenze.

Passaggi aggiuntivi per la Modalità di errore 3: blocco del Centro identità

  • Come descritto in dettaglio in Configurazione dell'accesso di emergenza AWS Management Console, in caso di accesso di emergenza Account AWS, crea un provider di IAM identità per consentire la SAML federazione diretta dal tuo provider di identità.

  • Crea gruppi operativi di emergenza nel tuo IdP senza membri.

  • Crea IAM ruoli corrispondenti ai gruppi operativi di emergenza nell'account per l'accesso di emergenza.

Risorse

Best practice Well-Architected correlate:

Documenti correlati:

Video correlati:

Esempi correlati: