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à.
Aggiorna la soluzione
Importante
-
Aggiornamento alla versione 4.0.0 o successiva: la soluzione mantiene le impostazioni di riparazione automatica esistenti durante l'aggiornamento. Se si esegue l'aggiornamento dalla versione 2.x, la soluzione migra automaticamente le impostazioni di correzione automatica dalle regole della versione 2 alla nuova configurazione durante l'aggiornamento dello stack. EventBridge DynamoDB-backed I controlli per i quali avevi abilitato la correzione automatica nella v2 restano abilitati nella v4, mentre i controlli senza un equivalente v3+ vengono ignorati ed elencati nei log Amazon della funzione di migrazione AWS Lambda. CloudWatch Se stai effettuando l'aggiornamento dalla versione 3.x, le impostazioni di riparazione automatica sono già incluse nella configurazione e vengono mantenute invariate, quindi non è necessaria alcuna migrazione. DynamoDB-backed Se la migrazione rileva un errore per controllo o si interrompe prima della scrittura dei controlli, la funzione Lambda pubblica una notifica Amazon SNS su quello esistente.
SO0111-ASR-MigrationAutoRemediationSO0111-ASR_TopicPer ricevere tale notifica, devi avere un abbonamento confermato prima di iniziare l'aggiornamento dello stack v4.SO0111-ASR_TopicFare riferimento a Aggiornamento da v2.x a v4.0.0 o versioni successive. -
Aggiornamento alla versione 3.x dalla versione 2.x: Re-enable regole di correzione automatica manualmente nell'account Admin dopo l'aggiornamento dello stack. Fai riferimento a Abilita correzioni completamente automatiche.
-
Se utilizzi il
Reuse Orchestrator Log Groupparametro per conservare i log, assicurati che sia impostato correttamente durante l'aggiornamento dello stack per evitare la ricreazione dei gruppi di log o la perdita delle impostazioni di conservazione dei log. Fai riferimento a Implementare la soluzione. Se stai eseguendo un aggiornamento dello stack alla v2.3.0+ da una versione precedente, scegli «no»
Aggiornamento da versioni precedenti alla v1.4
Se hai già distribuito la soluzione prima della v1.4.x, disinstalla e installa la versione più recente:
-
Disinstalla la soluzione precedentemente distribuita. Fai riferimento a Disinstallare la soluzione.
-
Avvia il modello più recente. Fai riferimento a Distribuire la soluzione.
Nota
Se stai effettuando l'aggiornamento dalla versione 1.2.1 o precedente alla versione 1.3.0 o successiva, imposta su.
Reuse Orchestrator Log GroupNoSe stai reinstallando la versione 1.3.0 o successiva, puoi selezionare questa opzione.YesQuesta opzione consente di continuare ad accedere allo stesso gruppo di log per Orchestrator Step Functions.
Aggiornamento dalla versione 1.4 e successive
Se stai effettuando l'aggiornamento dalla v1.4.x, aggiorna tutti gli stack o come segue: StackSets
-
Aggiorna lo stack nell'account amministratore di Security Hub utilizzando il modello più recente. https://solutions-reference.s3.amazonaws.com/automated-security-response-on-aws/latest/automated-security-response-admin.template
-
In ogni account membro, aggiorna le autorizzazioni dal modello più recente.
-
In ogni account membro in tutte le regioni in cui è attualmente distribuito, aggiorna lo stack di membri dal modello più recente.
-
Se l'interfaccia utente Web è abilitata e hai aggiornato parametri come
TicketGenFunctionName, ad esempio, invalida la CloudFront cache per riflettere immediatamente le modifiche:aws cloudfront create-invalidation \ --distribution-id <distribution-id> \ --paths "/aws-exports.json"
Aggiornamento dalla versione 2.0.x
Se stai effettuando l'aggiornamento dalla v2.0.x, esegui prima l'aggiornamento alla v2.3.0. L'aggiornamento alla CloudFormation v2.1.0—2.1.1 non riesce.
L'aggiornamento dalla versione 2.1.4 o precedente
Se si esegue l'aggiornamento dalla v2.1.4 o precedente, è necessario eseguire l'aggiornamento alla v2.3.0 prima di eseguire l'aggiornamento a qualsiasi versione successiva alla v2.3.0. Altrimenti, l'operazione di aggiornamento dello stack fallirà. In alternativa, è possibile eliminare e ridistribuire gli stack della soluzione anziché eseguire un aggiornamento dello stack.
Aggiornamento da v2.x a v4.0.0 o successivo
A partire dalla versione 4.0.0, la soluzione mantiene le impostazioni di riparazione automatica durante l'aggiornamento dalla v2 alla v4. Nella versione 2, le regole Amazon per controllo memorizzavano lo stato di riparazione automatica. EventBridge Nella versione 3 e successive, la soluzione lo memorizza nella tabella Amazon DynamoDB di Remediation Configuration nell'account amministratore. Durante l'aggiornamento dello stack v4, una risorsa personalizzata analizza _AutoTrigger le regole v2 esistenti, traduce l'ID di controllo specifico di ciascuna regola nell'ID di controllo di sicurezza corrispondente e scrive i controlli precedentemente abilitati nella tabella DynamoDB.
La migrazione riguarda tutti e cinque i playbook v2:
-
SC(controlli di sicurezza di AWS Service-managed Security Hub): gli ID di controllo vengono scritti in DynamoDB senza modifiche. -
AFSBP(AWS Foundational Security Best Practices): gli ID di controllo vengono scritti in DynamoDB senza modifiche. -
NIST80053R5(NIST 800-53 Revision 5): gli ID di controllo vengono scritti in DynamoDB senza modifiche. -
PCI(PCI DSS v3.2.1): il prefisso iniziale viene rimosso (ad esempio, diventa).PCI.PCI.S3.5S3.5 -
CIS(CIS AWS Foundations Benchmark v1.2.0, v1.4.0 e v3.0.0): ogni ID di controllo CIS è associato al controllo di sicurezza a cui è destinato il documento di correzione SSM v2 a cui è destinato.
Risultati della migrazione:
-
I controlli migrati correttamente non richiedono alcuna azione: la correzione automatica è abilitata nella v4 nello stesso modo in cui lo erano nella v2.
-
I controlli ignorati dalla migrazione si dividono in due categorie: le regole CIS senza una correzione ASR nella v2 e i controlli v3+ non vengono forniti. I controlli ignorati sono elencati nei log Amazon della funzione AWS Lambda.
SO0111-ASR-MigrationAutoRemediationCloudWatch -
Se la migrazione rileva un errore per ogni controllo (ad esempio, un errore di limitazione transitorio durante l'aggiornamento di DynamoDB) o si interrompe prima che i controlli vengano scritti, pubblica una notifica Amazon SNS sull'argomento esistente.
SO0111-ASR-MigrationAutoRemediationSO0111-ASR_TopicIl corpo della notifica elenca gli ID di controllo interessati ed è preceduto da.[ASR v2 → v3/v4 migration] -
La risorsa personalizzata viene eseguita solo durante l'aggiornamento iniziale v3/v4 dello stack. Gli aggiornamenti successivi dello stack non eseguono nuovamente la migrazione.
Nota
Abbonati all'argomento SNS prima dell'aggiornamento. Le notifiche di errore di migrazione vengono pubblicate nell'argomento SO0111-ASR_Topic Amazon SNS esistente della soluzione. Se non disponi di un abbonamento confermato su quell'argomento prima dell'aggiornamento, la notifica di errore non ti arriva. In tal caso, l'errore viene visualizzato solo nei CloudWatch log Amazon della funzione SO0111-ASR-MigrationAutoRemediation AWS Lambda. Per sottoscrivere un endpoint, recupera l'argomento ARN da AWS Systems Manager Parameter Store all'indirizzo /Solutions/SO0111/SNS_Topic_ARN e aggiungi un abbonamento SNS (email, SQS, funzione AWS Lambda o qualsiasi altro protocollo supportato) prima di iniziare l'aggiornamento dello stack v4. Conferma eventuali sottoscrizioni e-mail tramite l'e-mail di conferma di AWS in modo che l'argomento sia pronto per la pubblicazione prima dell'esecuzione della migrazione.
Se la migrazione non è in grado di scrivere un controllo da correggere automaticamente nella v4, abilitalo manualmente nella tabella Remediation Configuration DynamoDB. Fai riferimento a Abilita correzioni completamente automatiche. Abilita correzioni completamente automatiche
