As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
Atualizar a solução
Importante
-
Atualização para a versão 4.0.0 ou posterior: a solução preserva suas configurações de correção automática existentes durante a atualização. Se você estiver fazendo o upgrade da v2.x, a solução migra automaticamente as configurações de correção automática das EventBridge regras da v2 para a nova configuração durante a atualização da pilha. DynamoDB-backed Os controles para os quais você tinha a remediação automática habilitada na v2 permanecem habilitados na v4, e os controles sem um equivalente na v3+ são ignorados e listados nos registros da Amazon da função de migração do AWS Lambda. CloudWatch Se você estiver fazendo o upgrade da v3.x, suas configurações de correção automática já residem na DynamoDB-backed configuração e permanecem inalteradas, portanto, nenhuma migração é necessária. Se a migração encontrar uma falha por controle ou for interrompida antes que qualquer controle seja gravado, a função
SO0111-ASR-MigrationAutoRemediationLambda publicará uma notificação do Amazon SNS para o existente.SO0111-ASR_TopicPara receber essa notificação, você precisa ter uma assinatura confirmadaSO0111-ASR_Topicantes de iniciar a atualização da pilha v4. Consulte Atualização da v2.x para a v4.0.0 ou posterior. -
Atualização da v2.x para a v3.x: regras de correção Re-enable automatizadas manualmente na conta de administrador após a atualização da pilha. Consulte Habilitar correções totalmente automatizadas.
-
Se você estiver usando o
Reuse Orchestrator Log Groupparâmetro para reter registros, certifique-se de que ele esteja configurado adequadamente durante a atualização da pilha para evitar a recriação do grupo de registros ou a perda das configurações de retenção de registros. Consulte Implantar a solução. Se você estiver realizando uma atualização de pilha para v2.3.0+ de uma versão anterior, escolha “não”
Atualização de versões anteriores à v1.4
Se você já implantou a solução antes da v1.4.x, desinstale e instale a versão mais recente:
-
Desinstale a solução implantada anteriormente. Consulte Desinstalar a solução.
-
Inicie o modelo mais recente. Consulte Implantar a solução.
nota
Se você estiver atualizando da v1.2.1 ou anterior para a v1.3.0 ou posterior, defina como.
Reuse Orchestrator Log GroupNoSe você estiver reinstalando a v1.3.0 ou posterior, poderá selecionar essa opçãoYes. Essa opção permite que você continue fazendo login no mesmo grupo de registros para as funções do Orchestrator Step.
Atualizando da v1.4 e posterior
Se você estiver atualizando da v1.4.x, atualize todas as pilhas ou faça o seguinte: StackSets
-
Atualize a pilha na conta de administrador do Security Hub usando o modelo https://solutions-reference.s3.amazonaws.com/automated-security-response-on-aws/latest/automated-security-response-admin.template
mais recente. -
Em cada conta de membro, atualize as permissões do modelo mais recente.
-
Em cada conta de membro em todas as regiões em que está atualmente implantada, atualize a pilha de membros usando o modelo mais recente.
-
Se a interface de usuário da Web estiver ativada e você tiver atualizado parâmetros como
TicketGenFunctionName, invalide o CloudFront cache para refletir as alterações imediatamente:aws cloudfront create-invalidation \ --distribution-id <distribution-id> \ --paths "/aws-exports.json"
Atualizando a partir da v2.0.x
Se você estiver atualizando da v2.0.x, atualize primeiro para a v2.3.0. A atualização para v2.1.0—2.1.1 falha em. CloudFormation
Atualizando da v2.1.4 ou anterior
Se você estiver atualizando da v2.1.4 ou anterior, deverá atualizar para a v2.3.0 antes de atualizar para qualquer versão superior à v2.3.0. Caso contrário, a operação de atualização da pilha falhará. Como alternativa, você pode excluir e reimplantar as pilhas da solução em vez de realizar uma atualização da pilha.
Atualização da v2.x para a v4.0.0 ou posterior
A partir da v4.0.0, a solução preserva suas configurações de remediação automática durante o upgrade de v2 para v4. Na v2, as EventBridge regras da Amazon por controle armazenavam o estado de correção automática. Na versão 3 e posterior, a solução o armazena na tabela de configuração de remediação do Amazon DynamoDB na conta de administrador. Durante a atualização da pilha v4, um recurso personalizado verifica suas _AutoTrigger regras v2 existentes, traduz o ID de controle específico de cada regra para o ID de controle de segurança correspondente e grava os controles habilitados anteriormente na tabela do DynamoDB.
A migração abrange todos os cinco playbooks v2:
-
SC(Controles de segurança do AWS Service-managed Security Hub) — os IDs de controle são gravados no DynamoDB inalterados. -
AFSBP(Melhores práticas de segurança do AWS Foundational) — os IDs de controle são gravados no DynamoDB inalterados. -
NIST80053R5(NIST 800-53 Revisão 5) — os IDs de controle são gravados no DynamoDB inalterados. -
PCI(PCI DSS v3.2.1) — oPCI.prefixo principal é removido (por exemplo, se torna).PCI.S3.5S3.5 -
CIS(CIS AWS Foundations Benchmark v1.2.0, v1.4.0 e v3.0.0) — cada ID de controle do CIS é mapeado para o controle de segurança visado pelo documento de remediação v2 SSM.
Resultados da migração:
-
Os controles migrados com sucesso não precisam de nenhuma ação — eles têm a remediação automática ativada na v4 da mesma forma que na v2.
-
Os controles que a migração ignora se enquadram em duas categorias: as regras do CIS sem uma correção de ASR na v2 e os controles v3+ não são fornecidos. Os controles ignorados estão listados nos registros da Amazon da função
SO0111-ASR-MigrationAutoRemediationAWS Lambda. CloudWatch -
Se a migração encontrar uma falha por controle (por exemplo, um erro transitório de limitação durante a atualização do DynamoDB) ou for abortada antes que qualquer controle seja gravado,
SO0111-ASR-MigrationAutoRemediationpublica uma notificação do Amazon SNS no tópico existente.SO0111-ASR_TopicO corpo da notificação lista os IDs de controle afetados e tem como prefixo.[ASR v2 → v3/v4 migration] -
O recurso personalizado só é executado durante a atualização inicial da v3/v4 pilha. As atualizações subsequentes da pilha não executam a migração novamente.
nota
Assine o tópico SNS antes de fazer o upgrade. As notificações de falha de migração são publicadas no tópico existente do SO0111-ASR_Topic Amazon SNS da solução. Se você não tiver uma assinatura confirmada sobre esse tópico antes da atualização, a notificação de falha não chegará até você. Nesse caso, você só vê a falha nos CloudWatch logs da Amazon da função SO0111-ASR-MigrationAutoRemediation AWS Lambda. Para assinar um endpoint, recupere o ARN do tópico no AWS Systems Manager Parameter Store em /Solutions/SO0111/SNS_Topic_ARN e adicione uma assinatura do SNS (e-mail, SQS, função AWS Lambda ou qualquer outro protocolo compatível) antes de iniciar a atualização da pilha v4. Confirme todas as assinaturas de e-mail por meio do e-mail de confirmação da AWS para que o tópico esteja pronto para ser entregue antes que a migração seja executada.
Se a migração não conseguir gravar um controle que você deseja remediar automaticamente na v4, ative-o manualmente na tabela de configuração de remediação do DynamoDB. Consulte Habilitar correções totalmente automatizadas.