View a markdown version of this page

Atualizar a solução - Resposta de segurança automatizada na AWS

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-MigrationAutoRemediation Lambda publicará uma notificação do Amazon SNS para o existente. SO0111-ASR_Topic Para receber essa notificação, você precisa ter uma assinatura confirmada SO0111-ASR_Topic antes 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 Group parâ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:

  1. Desinstale a solução implantada anteriormente. Consulte Desinstalar a solução.

  2. 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 Group No Se 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

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

  2. Em cada conta de membro, atualize as permissões do modelo mais recente.

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

  4. Se a interface de usuário da Web estiver ativada e você tiver atualizado parâmetros comoTicketGenFunctionName, 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) — o PCI. prefixo principal é removido (por exemplo, se torna). PCI.S3.5 S3.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-MigrationAutoRemediation AWS 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-MigrationAutoRemediation publica uma notificação do Amazon SNS no tópico existente. SO0111-ASR_Topic O 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.