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á. # Corrigindo as descobertas de GuardDuty segurança detectadas GuardDuty A Amazon gera [descobertas](guardduty_findings.md) que indicam possíveis descobertas de segurança associadas à detecção GuardDuty básica de ameaças e planos de proteção dedicados. As seções a seguir descrevem as etapas de correção recomendadas para qualquer uma das situações. Caso ocorram cenários alternativos de correção, eles serão descritos nas descrições para cada tipo de descoberta. Para acessar as informações completas sobre um tipo de descoberta selecione-a na [tabela Tipos de descobertas ativas](guardduty_finding-types-active.md). **Topics** + [Como corrigir uma instância do Amazon EC2 potencialmente comprometida](compromised-ec2.md) + [Como corrigir um bucket do S3 possivelmente comprometido](compromised-s3.md) + [Como corrigir um objeto do S3 possivelmente malicioso](compromised-s3object-malware-protection-gdu.md) + [Corrigindo um snapshot do EBS potencialmente comprometido](compromised-snapshot.md) + [Remediando uma AMI do EC2 potencialmente comprometida](compromised-ami.md) + [Corrigindo um ponto de recuperação EC2 potencialmente comprometido](compromised-ec2-recoverypoint.md) + [Corrigindo um ponto de recuperação S3 potencialmente comprometido](compromised-s3-recoverypoint.md) + [Como corrigir um cluster do ECS possivelmente comprometido](compromised-ecs.md) + [Corrigindo credenciais potencialmente comprometidas AWS](compromised-creds.md) + [Como corrigir um contêiner autônomo possivelmente comprometido](remediate-compromised-standalone-container.md) + [Como corrigir as descobertas da Proteção do EKS](guardduty-remediate-kubernetes.md) + [Como corrigir as descobertas do Monitoramento de runtime](guardduty-remediate-runtime-monitoring.md) + [Corrigir um banco de dados possivelmente comprometido](guardduty-remediate-compromised-database-rds.md) + [Correção de uma função do Lambda comprometida](remediate-lambda-protection-finding-types.md) # Como corrigir uma instância do Amazon EC2 potencialmente comprometida **Quando GuardDuty gerar [tipos de descoberta que indicam recursos potencialmente comprometidos do Amazon EC2](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-active.html#findings-table), **seu** recurso será Instância.** Os possíveis tipos de descoberta podem ser[Tipos de descoberta do EC2](guardduty_finding-types-ec2.md),[GuardDuty Tipos de descoberta de monitoramento de tempo de execução](findings-runtime-monitoring.md), ou [Tipos de descoberta da Proteção contra malware para EC2](findings-malware-protection.md). Caso o comportamento que causou a descoberta seja esperado em seu ambiente, considere usar o [Regras de supressão](findings_suppression-rule.md). Execute as seguintes etapas para corrigir a instância possivelmente comprometida do Amazon EC2: 1. **Identifique a instância possivelmente comprometida do Amazon EC2** Verifique se há malwares na instância possivelmente comprometida e remova todos aqueles que forem descobertos. Use a [Análise de malware sob demanda em GuardDuty](on-demand-malware-scan.md) para identificar um malware na instância EC2 possivelmente comprometida ou verifique o [AWS Marketplace](https://aws.amazon.com/marketplace) para conferir se há produtos parceiros úteis para identificar e remover malware. 1. **Isole a instância possivelmente comprometida do Amazon EC2** Se possível, use as etapas a seguir para isolar a instância possivelmente comprometida: 1. Crie um grupo de segurança de **isolamento** específico. Um grupo de segurança de isolamento só deve ter acesso para entrada e saída de endereços IP específicos. Certifique-se de que não haja nenhuma regra de entrada ou saída que permita o tráfego para `0.0.0.0/0 (0-65535)`. 1. Associe o grupo de segurança **Isolamento** a essa instância. 1. Remova todas as associações de grupos de segurança, exceto o recém-criado grupo de segurança **Isolamento**, da instância possivelmente comprometida. **nota** As conexões rastreadas existentes não serão encerradas como resultado da alteração dos grupos de segurança - somente o tráfego futuro será efetivamente bloqueado pelo novo grupo de segurança. Para obter informações sobre como bloquear mais tráfego de conexões suspeitas existentes, consulte [Aplicar NACLs com base na rede IoCs para evitar mais tráfego](https://github.com/aws-samples/aws-customer-playbook-framework/blob/main/docs/Ransom_Response_EC2_Linux.md#enforce-nacls-based-on-network-iocs-to-prevent-further-traffic) no *Manual de Resposta a Incidentes*. 1. **Identifique a origem da atividade suspeita** Se for detectado um malware, com base no tipo de descoberta em sua conta, identifique e interrompa a atividade potencialmente não autorizada em sua instância do EC2. Isso pode exigir medidas como fechar todas as portas abertas, alterar as políticas de acesso e atualizar aplicações para corrigir as vulnerabilidades. Caso não consiga identificar e interromper atividades não autorizadas em sua instância do EC2 possivelmente comprometida, recomendamos encerrar a instância do EC2 comprometida e substituí-la por uma nova instância, caso necessário. Veja a seguir os recursos adicionais para proteger suas instâncias do EC2: + Seções Segurança e Rede em [Melhores práticas do Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-best-practices.html). + [Grupos de segurança do Amazon EC2 para instâncias do Linux](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html). + [Segurança no Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-security.html) + [Dicas para proteger as instâncias do EC2 (Linux)](https://aws.amazon.com/articles/tips-for-securing-your-ec2-instance/). + [AWS melhores práticas de segurança](https://aws.amazon.com//architecture/security-identity-compliance/) + [AWS Guia técnico de resposta a incidentes de segurança](https://docs.aws.amazon.com/security-ir/latest/userguide/security-incident-response-guide.html). 1. **Navegar AWS re:Post** Navegue [AWS re:Post](https://repost.aws/)para obter mais assistência. 1. **Envie uma solicitação de suporte técnico** Caso seja assinante do pacote Premium Support, envie uma solicitação de [suporte técnico](https://console.aws.amazon.com/support/home#/case/create?issueType=technical). # Como corrigir um bucket do S3 possivelmente comprometido Quando GuardDuty gerado[GuardDuty Tipos de descoberta do S3 Protection](guardduty_finding-types-s3.md), indica que seus buckets do Amazon S3 foram comprometidos. Caso o comportamento que causou a descoberta fosse esperado em seu ambiente, considere criar[Regras de supressão](findings_suppression-rule.md). Se esse comportamento não era esperado, siga estas etapas recomendadas para corrigir um bucket Amazon S3 potencialmente comprometido em seu ambiente: AWS 1. **Identifique o recurso do S3 possivelmente comprometido.** Uma GuardDuty descoberta para o S3 listará o bucket do S3 associado, seu Amazon Resource Name (ARN) e seu proprietário nos detalhes da descoberta. 1. **Identifique a origem da atividade suspeita e a chamada de API usada.** A chamada de API usada será listada como `API` nos detalhes da descoberta. A origem será uma entidade principal do IAM (um perfil, um usuário ou uma conta do IAM) e os detalhes de identificação serão listados na descoberta. Dependendo do tipo de origem, o endereço IP remoto ou as informações do domínio de origem estarão disponíveis e poderão ajudar a avaliar se a origem foi autorizada. Caso a descoberta envolva credenciais de uma instância do Amazon EC2, os detalhes desse recurso também serão incluídos. 1. **Determine se a origem da chamada foi autorizada a acessar o recurso identificado. ** Por exemplo, considere o seguinte: + Caso um usuário do IAM esteja envolvido, é possível que suas credenciais tenham sido possivelmente comprometidas? Para obter mais informações, consulte [Corrigindo credenciais potencialmente comprometidas AWS](compromised-creds.md). + Caso uma API tenha sido invocada a partir de uma entidade principal que não tenha histórico anterior de invocação desse tipo de API, essa fonte precisa de permissões de acesso para essa operação? É possível restringir ainda mais as permissões do bucket? + Se o acesso foi visto a partir do **nome de usuário** `ANONYMOUS_PRINCIPAL` com o **tipo de usuário** `AWSAccount`, isso indica que o bucket é público e foi acessado. Esse bucket deveria ser público? Se a resposta for não, revise as recomendações de segurança abaixo a fim de encontrar soluções alternativas para compartilhar recursos do S3. + Se o acesso foi feito por meio de uma chamada `PreflightRequest` bem-sucedida vista do **nome de usuário** `ANONYMOUS_PRINCIPAL` com o **tipo de usuário** `AWSAccount`, isso indica que o bucket tem uma política de compartilhamento de recursos de origem cruzada (CORS) definida. Esse bucket deve ter uma política de CORS? Se a resposta for não, certifique-se de que o bucket não esteja designado como público por engano e analise as recomendações de segurança abaixo a fim de encontrar soluções alternativas para compartilhar recursos do S3. Para obter mais informações sobre o CORS, consulte [Usar o compartilhamento de recursos de origem cruzada (CORS)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/cors.html) no guia do usuário do S3. 1. **Determine se o bucket do S3 contém dados confidenciais.** Use o [Amazon Macie](https://docs.aws.amazon.com/macie/latest/user/what-is-macie.html) para determinar se o bucket do S3 contém dados confidenciais, como informações de identificação pessoal (PII), dados financeiros ou credenciais. Se a descoberta automatizada de dados confidenciais estiver habilitada para sua conta do Macie, revise os detalhes do bucket do S3 a fim de entender melhor o conteúdo do bucket do S3. Se esse atributo estiver desabilitado em sua conta do Macie, recomendamos habilitá-lo para agilizar sua avaliação. Outra alternativa é criar e executar um trabalho de descoberta de dados confidenciais para inspecionar os objetos do bucket do S3 em busca de dados confidenciais. Para obter mais informações, consulte [Discovering sensitive data with Amazon Macie](https://docs.aws.amazon.com/macie/latest/user/data-classification.html). A descoberta pode ser ignorada se o acesso foi autorizado. O [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/)console permite que você configure regras para suprimir totalmente as descobertas individuais, para que elas não apareçam mais. Para obter mais informações, consulte [Regras de supressão em GuardDuty](findings_suppression-rule.md). Ao determinar que seus dados do S3 foram expostos ou acessados por uma parte não autorizada, analise as seguintes recomendações de segurança do S3 para reforçar as permissões e restringir o acesso. As soluções de correção apropriadas serão determinadas pelas necessidades de seu ambiente específico. ## Recomendações com base em necessidades específicas de acesso a buckets do S3 **A lista a seguir fornece recomendações com base nas necessidades específicas de acesso ao bucket do Amazon S3:** + Para limitar o acesso público ao uso de dados do S3 de forma centralizada, bloqueie o acesso público do S3. As configurações de bloqueio de acesso público podem ser ativadas para pontos de acesso, buckets e AWS contas por meio de quatro configurações diferentes para controlar a granularidade do acesso. Para obter mais informações, consulte [Bloquear configurações de acesso público](https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-control-block-public-access.html#access-control-block-public-access-options) no *Guia do usuário do Amazon S3*. + AWS As políticas de acesso podem ser usadas para controlar como os usuários do IAM podem acessar seus recursos ou como seus buckets podem ser acessados. Para obter mais informações, consulte [Usar políticas de bucket e políticas de usuário](https://docs.aws.amazon.com/AmazonS3/latest/userguide/security_iam_service-with-iam.html) no *Guia do usuário do Amazon S3*. Além disso, você pode usar endpoints da nuvem privada virtual (VPC) com políticas de bucket do S3 para restringir o acesso a endpoints da VPC específicos. Para obter mais informações, consulte [Controlar o acesso a partir de endpoints da VPC com políticas de bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-bucket-policies-vpc-endpoint.html) no *Guia do usuário do Amazon S3*. + Para permitir que entidades confiáveis fora de sua conta acessem temporariamente os objetos do S3, é possível criar um URL pré-assinado por meio do S3. Esse acesso é criado com as credenciais da sua conta e, dependendo das credenciais usadas, pode durar de 6 horas a 7 dias. Para obter mais informações, consulte [Como usar objetos pré-assinados URLs para baixar e carregar objetos](https://docs.aws.amazon.com/AmazonS3/latest/userguide/using-presigned-url.html) no Guia do *usuário do Amazon S3*. + Para os casos de uso que exigem o compartilhamento de objetos do S3 entre diferentes origens, use os Pontos de Acesso S3 para criar conjuntos de permissões que restringem o acesso somente aos que estão em sua rede privada. Para obter mais informações, consulte [Gerenciar o acesso a conjunto de dados compartilhados com pontos de acesso](https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-points.html) no *Guia do usuário do Amazon S3*. + *Para conceder acesso seguro aos seus recursos do S3 para outras AWS contas, você pode usar uma lista de controle de acesso (ACL). Para obter mais informações, consulte Visão geral da [lista de controle de acesso (ACL) no Guia do usuário do](https://docs.aws.amazon.com/AmazonS3/latest/userguide/acl-overview.html) Amazon S3.* Para obter mais informações sobre as opções de segurança do S3, consulte [Práticas recomendadas de segurança para o Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/security-best-practices.html) no *Guia do usuário do Amazon S3*. # Como corrigir um objeto do S3 possivelmente malicioso Quando GuardDuty gerado[Tipo de descoberta da Proteção contra malware para S3](gdu-malware-protection-s3-finding-types.md), indica que um objeto recém-carregado em seu bucket do Amazon S3 contém malware. O tipo de recurso é um **S3Object**. Use as seguintes etapas recomendadas para corrigir a descoberta gerada: 1. Identifique o objeto S3 potencialmente malicioso verificando o **S3 ObjectDetails** associado à descoberta. 1. Isole o objeto do S3 afetado. Se você ativou a marcação no momento da ativação do Malware Protection for S3 para o bucket Amazon S3 associado GuardDuty , deve ter atribuído **uma** tag maliciosa a esse objeto. Use o controle de acesso baseado em tags (TBAC) para restringir o acesso a esse objeto do S3. Para obter mais informações, consulte [Usando controle de acesso baseado em tags (TBAC)](tag-based-access-s3-malware-protection.md). Outra alternativa é que, caso não precise mais desse objeto, também é possível optar por excluí-lo ou movê-lo para um bucket do S3 isolado. Para obter informações sobre considerações para a exclusão de um objeto do S3, consulte [Exclusão de objetos](https://docs.aws.amazon.com/AmazonS3/latest/userguide/DeletingObjects.html) no *Guia do usuário do Amazon S3*. # Corrigindo um snapshot do EBS potencialmente comprometido Quando GuardDuty gera uma MaliciousFile execução:EC2/\$1 Tipo de descoberta de snapshot, indica que um malware foi detectado em um snapshot do Amazon EBS. Execute as etapas a seguir para corrigir o snapshot potencialmente comprometido: 1. **Identifique o snapshot potencialmente comprometido** 1. Identifique o snapshot potencialmente comprometido. A GuardDuty descoberta de um snapshot do EBS listará o ID do snapshot afetado, seu Amazon Resource Name (ARN) e os detalhes da verificação de malware associados nos detalhes da descoberta. 1. Analise os detalhes do ponto de recuperação usando o seguinte comando: ``` aws backup describe-recovery-point —backup-vault-name 021345abcdef6789 —recovery-point-arn "arn:aws:ec2:us-east-1::snapshot/snap-abcdef01234567890" ``` 1. **Restrinja o acesso ao snapshot comprometido** Revise e modifique as políticas de acesso ao cofre de backup para restringir o acesso ao ponto de recuperação e suspender quaisquer trabalhos de restauração automatizados que possam usar esse instantâneo. 1. Revise as permissões de compartilhamento atuais: ``` aws ec2 describe-snapshot-attribute --snapshot-id snap-abcdef01234567890 --attribute createVolumePermission ``` 1. Remova o acesso específico à conta: ``` aws ec2 modify-snapshot-attribute --snapshot-id snap-abcdef01234567890 --attribute createVolumePermission --operation-type remove --user-ids 111122223333 ``` 1. [Para obter mais opções de CLI, consulte a documentação da CLImodify-snapshot-attribute .](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-snapshot-attribute.html) 1. **Tome medidas de remediação** + Antes de prosseguir com a exclusão, certifique-se de ter identificado todas as dependências e de ter backups adequados, se necessário. # Remediando uma AMI do EC2 potencialmente comprometida Quando GuardDuty gera uma MaliciousFile execução:EC2/\$1 Tipo de descoberta da AMI, indica que o malware foi detectado em uma Amazon Machine Image (AMI). Execute as etapas a seguir para corrigir a AMI potencialmente comprometida: 1. **Identifique a AMI potencialmente comprometida** 1. Uma GuardDuty descoberta para AMIs listará o ID da AMI afetado, seu Amazon Resource Name (ARN) e os detalhes da verificação de malware associada nos detalhes da descoberta. 1. Analise a imagem de origem da AMI: ``` aws ec2 describe-images --image-ids ami-021345abcdef6789 ``` 1. **Restrinja o acesso aos recursos comprometidos** 1. Revise e modifique as políticas de acesso ao cofre de backup para restringir o acesso ao ponto de recuperação e suspender quaisquer trabalhos de restauração automatizados que possam usar esse ponto de recuperação. 1. Remover permissões das permissões da AMI de origem Primeiro, visualize as permissões existentes: ``` aws ec2 describe-image-attribute --image-id ami-abcdef01234567890 --attribute launchPermission ``` Em seguida, remova as permissões individuais: ``` aws ec2 modify-image-attribute --image-id ami-abcdef01234567890 --launch-permission '{"Remove":[{"UserId":"111122223333"}]}' ``` Para opções adicionais de CLI, consulte [Compartilhar uma AMI com contas específicas - Amazon Elastic Compute Cloud](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/sharingamis-explicit.html#unsharing-an-ami) 1. Se a origem for uma instância do EC2, consulte: [Remediando uma instância potencialmente comprometida do Amazon EC2](https://docs.aws.amazon.com/guardduty/latest/ug/compromised-ec2.html). 1. **Tome medidas de remediação** + Antes de prosseguir com a exclusão, certifique-se de ter identificado todas as dependências e de ter backups adequados, se necessário. # Corrigindo um ponto de recuperação EC2 potencialmente comprometido Quando GuardDuty gera uma MaliciousFile execução:EC2/\$1 RecoveryPoint tipo de descoberta, indica que o malware foi detectado em um recurso de Backup do EC2 Recovery Point. Execute as etapas a seguir para corrigir o ponto de recuperação potencialmente comprometido: 1. **Identifique o ponto de recuperação EC2 potencialmente comprometido** 1. Uma GuardDuty descoberta do EC2 Recovery Point listará seu Amazon Resource Name (ARN) e os detalhes da verificação de malware associada nos detalhes da descoberta: ``` aws backup describe-recovery-point --backup-vault-name 021345abcdef6789 --recovery-point-arn "arn:aws:backup:us-east-1:111122223333:recovery-point:a1b2c3d4-5678-90ab-cdef-EXAMPLE11111" ``` 1. Revise os detalhes da recuperação para procurar a imagem de origem: ``` aws backup get-recovery-point-restore-metadata --backup-vault-name 021345abcdef6789 --recovery-point-arn "arn:aws:backup:us-east-1:111122223333:recovery-point:a1b2c3d4-5678-90ab-cdef-EXAMPLE11111" ``` 1. **Restrinja o acesso aos recursos comprometidos** + Revise e modifique as políticas de acesso ao cofre de backup para restringir o acesso ao ponto de recuperação e suspender quaisquer trabalhos de restauração automatizados que possam usar esse ponto de recuperação. Se seu ambiente usa marcação de recursos, marque o ponto de recuperação adequadamente para indicar que ele está sob investigação e considere pausar os backups agendados, se necessário. Exemplo: *aws backup tag-resource -—resource-arn arn:aws:backup:us-east-1:111122223333:recovery-point:a1b2c3d4-5678-90ab-cdef-EXAMPLE11111 -—tags Investigation=Malware,DoNotDelete=True* 1. **Tome medidas de remediação** + Antes de prosseguir com a exclusão, certifique-se de ter identificado todas as dependências e de ter backups adequados, se necessário. # Corrigindo um ponto de recuperação S3 potencialmente comprometido Quando GuardDuty gera uma MaliciousFile Execução:S3/\$1 RecoveryPoint tipo de descoberta, indica que o malware foi detectado em um recurso de Backup do S3 Recovery Point. Execute as etapas a seguir para corrigir o ponto de recuperação potencialmente comprometido: 1. **Identifique o ponto de recuperação S3 potencialmente comprometido** 1. Uma GuardDuty descoberta dos pontos de recuperação do S3 listará o ARN do ponto de recuperação afetado, o nome do cofre de backup e os detalhes da verificação de malware associada nos detalhes da descoberta. 1. Analise os detalhes do ponto de recuperação: ``` aws backup describe-recovery-point --backup-vault-name 021345abcdef6789 --recovery-point-arn arn:aws:backup:us-east-1:123456789012:recovery-point:abcdef01234567890 ``` 1. **Restrinja o acesso aos recursos comprometidos** + Revise e modifique as políticas de acesso ao cofre de backup para restringir o acesso ao ponto de recuperação e suspender quaisquer trabalhos de restauração automatizados que possam usar esse ponto de recuperação. Se seu ambiente usa marcação de recursos, marque o ponto de recuperação adequadamente para indicar que ele está sob investigação e considere pausar os backups agendados, se necessário. Exemplo: ``` aws backup tag-resource —resource-arn arn:aws:backup:us-east-1:111122223333:recovery-point:abcdef01234567890 —tags Investigation=Malware,DoNotDelete=True ``` Para obter detalhes adicionais, consulte: Referência de comandos da [CLI tag-resource](https://docs.aws.amazon.com/cli/latest/reference/backup/tag-resource.html) 1. **Tome medidas de remediação** + Antes de prosseguir com a exclusão, certifique-se de ter identificado todas as dependências e de ter backups adequados, se necessário. # Como corrigir um cluster do ECS possivelmente comprometido A descoberta de um cluster ECS potencialmente comprometido indica que atividades suspeitas ou maliciosas foram detectadas em seu ambiente Amazon ECS. Isso pode incluir acesso não autorizado, execução de malware ou outro comportamento malicioso que coloque em risco as cargas de trabalho do contêiner. Siga estas etapas para corrigir um cluster Amazon ECS potencialmente comprometido: 1. **Identifique o cluster ECS potencialmente comprometido e a ameaça detectada (descobertas)** Os detalhes do cluster ECS afetado estão listados no painel de detalhes da GuardDuty descoberta. 1. **Avalie a origem da ameaça/malware** Verifique se há malware nas imagens do contêiner. Se um malware for detectado, revise a imagem do contêiner que está sendo usada. Use [https://docs.aws.amazon.com//AmazonECS/latest/APIReference/API_ListTasks.html](https://docs.aws.amazon.com//AmazonECS/latest/APIReference/API_ListTasks.html)para identificar todas as outras tarefas em execução que usam a mesma imagem potencialmente comprometida. 1. **Isole as tarefas afetadas** Pare a ameaça bloqueando todo o tráfego de rede (tanto de entrada quanto de saída) para as tarefas afetadas. Esse isolamento de rede ajuda a evitar ataques contínuos, cortando todas as conexões com a tarefa comprometida. **Observação**: Se você determinar que essa descoberta foi acionada pela expected/legitimate atividade em seu ambiente, você pode configurar uma regra de supressão para evitar que descobertas semelhantes apareçam. Para obter informações adicionais, consulte [Regras de supressão em GuardDuty](findings_suppression-rule.md). # Corrigindo credenciais potencialmente comprometidas AWS Quando GuardDuty gerado[Tipos de descobertas do IAM](guardduty_finding-types-iam.md), indica que suas AWS credenciais foram comprometidas. O tipo de **recurso** potencialmente comprometido é **AccessKey**. Para corrigir credenciais potencialmente comprometidas em seu AWS ambiente, execute as seguintes etapas: 1. **Identifique a entidade do IAM possivelmente comprometida e a chamada de API usada.** A chamada de API usada será listada como `API` nos detalhes da descoberta. A entidade do IAM (um usuário ou um perfil do IAM) e as respectivas informações de identificação serão listadas na seção **Recurso** dos detalhes de uma descoberta. O tipo de entidade do IAM envolvida pode ser determinado pelo campo **Tipo de usuário**, o nome da entidade do IAM estará no campo **Nome de usuário**. O tipo de entidade do IAM envolvida na descoberta também pode ser determinado pelo **ID de chave de acesso** usado. Para chaves que começam com `AKIA`: Esse tipo de chave é uma credencial de longo prazo gerenciada pelo cliente associada a um usuário do IAM ou Usuário raiz da conta da AWS. Para obter informações sobre como gerenciar chaves de acesso para usuários do IAM, consulte [Gerenciamento de chaves de acesso de usuários do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html). Para chaves que começam com `ASIA`: Esse tipo de chave é uma credencial temporária de curto prazo gerada pelo AWS Security Token Service. Essas chaves existem por pouco tempo e não podem ser visualizadas nem gerenciadas no AWS Management Console. As funções do IAM sempre usarão AWS STS credenciais, mas elas também podem ser geradas para usuários do IAM. Para obter mais informações, AWS STS consulte [IAM: Credenciais de segurança temporárias](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html#sts-introduction). Se um perfil tiver sido usado, o campo **Nome de usuário** conterá informações sobre o nome do perfil usado. Você pode determinar como a chave foi solicitada AWS CloudTrail examinando o `sessionIssuer` elemento da entrada de CloudTrail registro. Para obter mais informações, consulte [IAM e AWS STS informações em CloudTrail](https://docs.aws.amazon.com/IAM/latest/UserGuide/cloudtrail-integration.html#iam-info-in-cloudtrail). 1. **Revise as permissões para a entidade do IAM.** Abra o console do IAM. Dependendo do tipo de entidade usada, selecione a guia **Usuários** ou **Funções** e localize a entidade afetada digitando o nome identificado no campo de pesquisa. Use as guias **Permissão** e **Consultor de acesso** para revisar permissões efetivas para essa entidade. 1. **Determine se as credenciais da entidade do IAM foram usadas legitimamente.** Entre em contato com o usuário das credenciais para determinar se a atividade foi intencional. Por exemplo, descubra se o usuário fez o seguinte: + Invocou a operação de API que foi listada na descoberta GuardDuty + Invocou a operação da API no horário indicado na descoberta do GuardDuty + Invocou a operação da API do endereço IP que foi listado na descoberta do GuardDuty Se essa atividade for um uso legítimo das AWS credenciais, você poderá ignorar a GuardDuty descoberta. O [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/)console permite que você configure regras para suprimir totalmente as descobertas individuais, para que elas não apareçam mais. Para obter mais informações, consulte [Regras de supressão em GuardDuty](findings_suppression-rule.md). Se não for possível confirmar se essa atividade é um uso legítimo, isso pode indicar um comprometimento da chave de acesso específica, das credenciais de login do usuário do IAM ou, possivelmente, de toda a Conta da AWS. Se você suspeitar que suas credenciais foram comprometidas, revise as informações em [Meu Conta da AWS pode estar comprometido](https://repost.aws/knowledge-center/potential-account-compromise) para corrigir esse problema. # Como corrigir um contêiner autônomo possivelmente comprometido Quando GuardDuty gera [tipos de descoberta que indicam um contêiner potencialmente comprometido](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-active.html#findings-table), seu **tipo de recurso** será **Contêiner**. Caso o comportamento que causou a descoberta seja esperado em seu ambiente, considere usar [Regras de supressão](findings_suppression-rule.md). Para corrigir credenciais potencialmente comprometidas em seu AWS ambiente, execute as seguintes etapas: 1. **Isole o contêiner possivelmente comprometido** As etapas a seguir vão ajudar a identificar o workload do contêiner possivelmente malicioso: + Abra o GuardDuty console em [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/). + Na página **Descobertas**, escolha a respectiva descoberta para visualizar o painel de descobertas. + No painel de descobertas, na seção **Recursos afetados**, é possível ver o **ID** e o **Nome** do contêiner. Isole esse contêiner de outras workloads do contêiner. 1. **Pause o contêiner** Suspenda todos os processos no contêiner. Para obter informações sobre como congelar seu contêiner, consulte [Pausar um contêiner](https://docs.docker.com/engine/api/v1.35/#tag/Container/operation/ContainerPause). **Interrompa o contêiner**. Se a etapa acima não funcionar e o contêiner não pausar, interrompa a execução do contêiner. Se você ativou o [Retenção de snapshots](malware-protection-customizations.md#mp-snapshots-retention) recurso, GuardDuty reterá os instantâneos de seus volumes do EBS que contêm malware. Para obter informações sobre como interromper o contêiner, consulte [Interromper um contêiner](https://docs.docker.com/engine/api/v1.35/#tag/Container). 1. **Avaliar a presença de malware** Verifique se o malware estava na imagem do contêiner. A descoberta pode ser ignorada se o acesso foi autorizado. O [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/)console permite que você configure regras para suprimir totalmente as descobertas individuais, para que elas não apareçam mais. O GuardDuty console permite que você configure regras para suprimir totalmente as descobertas individuais, para que elas não apareçam mais. Para obter mais informações, consulte [Regras de supressão em GuardDuty](findings_suppression-rule.md). # Como corrigir as descobertas da Proteção do EKS GuardDuty A Amazon gera [descobertas](guardduty_findings.md) que indicam possíveis problemas de segurança do Kubernetes quando o EKS Protection está ativado em sua conta. Para obter mais informações, consulte [Proteção do EKS](kubernetes-protection.md). As seções a seguir descrevem as etapas de correção recomendadas para qualquer uma das situações. As ações de remediação específicas são descritas na entrada desse tipo específico de descoberta. Para acessar as informações completas sobre um tipo de descoberta selecione-a na [tabela Tipos de descobertas ativas](guardduty_finding-types-active.md). Se algum dos tipos de descoberta damproteção EKS tiver sido gerado com inesperadamente, considere adicionar [Regras de supressão em GuardDuty](findings_suppression-rule.md) para evitar futuros alertas. Diferentes tipos de ataques e problemas de configuração podem desencadear as descobertas do GuardDuty EKS Protection. Este guia ajuda você a identificar as principais causas das GuardDuty descobertas em seu cluster e descreve as diretrizes de remediação apropriadas. A seguir estão as principais causas que levaram às descobertas do GuardDuty Kubernetes: + [Possíveis problemas de configuração](#compromised-kubernetes-config) + [Como corrigir usuários do Kubernetes possivelmente comprometidos](#compromised-kubernetes-user) + [Como corrigir pods do Kubernetes possivelmente comprometidos](#compromised-kubernetes-pod) + [Como corrigir pods do Kubernetes potencialmente comprometidos](#compromised-kubernetes-node) + [Como corrigir imagens de contêiner possivelmente comprometidas](#compromised-kubernetes-image) **nota** Antes da versão 1.14 do Kubernetes, o `system:unauthenticated` grupo era associado e por padrão. `system:discovery` `system:basic-user` **ClusterRoles** Isso pode permitir o acesso não intencional de usuários anônimos. As atualizações de cluster não revogam essas permissões, o que significa que, mesmo que você tenha atualizado seu cluster para a versão 1.14 ou posterior, essas permissões ainda podem estar em vigor. Recomendamos que você desassocie essas permissões do grupo `system:unauthenticated`. Para obter mais informações sobre como remover essas permissões, consulte [Proteger clusters do Amazon EKS com práticas recomendadas](https://docs.aws.amazon.com/eks/latest/userguide/security-best-practices.html) no **Guia do usuário do Amazon EKS**. ## Possíveis problemas de configuração Se uma descoberta indicar um problema de configuração, consulte a seção de correção dessa descoberta para obter orientação sobre como resolver esse problema específico. Para obter mais informações, consulte os tipos de descoberta a seguir que indicam problemas de configuração: + [Policy:Kubernetes/AnonymousAccessGranted](guardduty-finding-types-eks-audit-logs.md#policy-kubernetes-anonymousaccessgranted) + [Policy:Kubernetes/ExposedDashboard](guardduty-finding-types-eks-audit-logs.md#policy-kubernetes-exposeddashboard) + [Policy:Kubernetes/AdminAccessToDefaultServiceAccount](guardduty-finding-types-eks-audit-logs.md#policy-kubernetes-adminaccesstodefaultserviceaccount) + [Policy:Kubernetes/KubeflowDashboardExposed](guardduty-finding-types-eks-audit-logs.md#policy-kubernetes-kubeflowdashboardexposed) + Qualquer descoberta que termine em **SuccessfulAnonymousAccess** ## Como corrigir usuários do Kubernetes possivelmente comprometidos Uma GuardDuty descoberta pode indicar um usuário comprometido do Kubernetes quando um usuário identificado na descoberta executou uma ação inesperada da API. Você pode identificar o usuário na seção de **detalhes do usuário do Kubernetes** de um detalhe da descoberta no console ou no `resource.kubernetesDetails.kubernetesUserDetails` do JSON das descobertas. Esses detalhes do usuário incluem `user name`, `uid` e os grupos do Kubernetes aos quais o usuário pertence. Se o usuário estava acessando a workload usando uma entidade do IAM, você pode usar a seção `Access Key details` para identificar os detalhes de um usuário ou perfil do IAM. Consulte os seguintes tipos de usuário e suas diretrizes de correção. **nota** Você pode usar o Amazon Detective para investigar melhor o perfil do IAM ou o usuário identificado na descoberta. Ao visualizar os detalhes da descoberta no GuardDuty console, escolha **Investigar em Detective**. Em seguida, selecione AWS usuário ou função nos itens listados para investigá-lo em Detective. **Administrador integrado do Kubernetes**: o usuário padrão atribuído pelo Amazon EKS à identidade do IAM que criou o cluster. Esse tipo de usuário é identificado pelo nome do usuário `kubernetes-admin`. **Para revogar o acesso de um administrador integrado do Kubernetes:** + Identifique o `userType` da seção `Access Key details`. + Se o `userType` é **Perfil** e o perfil pertencer a um perfil de instância do EC2: + Identifique essa instância e siga as instruções em [Como corrigir uma instância do Amazon EC2 potencialmente comprometida](compromised-ec2.md). + Se `userType` for **Usuário** ou for uma **Função** que foi assumida por um usuário: 1. [Gire a chave de acesso](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_credentials_access-keys.html#Using_RotateAccessKey) desse usuário. 1. Alterne todos os segredos aos quais o usuário teve acesso. 1. Revise as informações em [Meu Conta da AWS pode estar comprometido](https://repost.aws/knowledge-center/potential-account-compromise) para obter mais detalhes. **Usuário autenticado pelo OIDC**: um usuário recebeu acesso por meio de um provedor do OIDC. Normalmente, um usuário do OIDC tem um endereço de e-mail como nome de usuário. Você pode verificar se o cluster usa o OIDC com o seguinte comando: `aws eks list-identity-provider-configs --cluster-name your-cluster-name ` **Para revogar o acesso de um usuário autenticado pelo OIDC:** 1. Alterne as credenciais desse usuário no provedor OIDC. 1. Alterne todos os segredos aos quais o usuário teve acesso. **AWS-Auth ConfigMap defined user — Um usuário do** IAM que recebeu acesso por meio de um AWS-auth. ConfigMap Para obter mais informações, consulte [Gerenciar usuários ou perfis do IAM para seu cluster](https://docs.aws.amazon.com/eks/latest/userguide/add-user-role.html) no **Guia do usuário do Amazon EKS**. É possível revisar as permissões usando este comando: `kubectl edit configmaps aws-auth --namespace kube-system` **Para revogar o acesso de um AWS ConfigMap usuário:** 1. Use o comando a seguir para abrir ConfigMap o. ``` kubectl edit configmaps aws-auth --namespace kube-system ``` 1. Identifique a função ou a entrada do usuário na seção **MapRoles** ou **MapUsers** com o mesmo nome de usuário relatado na seção de detalhes do usuário do Kubernetes da sua descoberta. GuardDuty Veja o exemplo a seguir, em que o usuário administrador foi identificado em uma descoberta. ``` apiVersion: v1 data: mapRoles: | - rolearn: arn:aws:iam::444455556666:role/eksctl-my-cluster-nodegroup-standard-wo-NodeInstanceRole-1WP3NUE3O6UCF user name: system:node:EC2_PrivateDNSName groups: - system:bootstrappers - system:nodes mapUsers: | - userarn: arn:aws:iam::123456789012:user/admin username: admin groups: - system:masters - userarn: arn:aws:iam::111122223333:user/ops-user username: ops-user groups: - system:masters ``` 1. Remova esse usuário do ConfigMap. Veja o exemplo a seguir em que o usuário administrador foi removido. ``` apiVersion: v1 data: mapRoles: | - rolearn: arn:aws:iam::111122223333:role/eksctl-my-cluster-nodegroup-standard-wo-NodeInstanceRole-1WP3NUE3O6UCF username: system:node:{{EC2PrivateDNSName}} groups: - system:bootstrappers - system:nodes mapUsers: | - userarn: arn:aws:iam::111122223333:user/ops-user username: ops-user groups: - system:masters ``` 1. Se `userType` for **Usuário** ou for uma **Função** que foi assumida por um usuário: 1. [Gire a chave de acesso](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_credentials_access-keys.html#Using_RotateAccessKey) desse usuário. 1. Alterne todos os segredos aos quais o usuário teve acesso. 1. Revise as informações em [Minha AWS conta pode estar comprometida](https://aws.amazon.com//premiumsupport/knowledge-center/potential-account-compromise/) para obter mais detalhes. Se a descoberta não tiver uma seção `resource.accessKeyDetails`, o usuário é uma conta de serviço do Kubernetes. **Conta de serviço**: a conta de serviço fornece uma identidade para pods e pode ser identificada por um nome de usuário com o seguinte formato: `system:serviceaccount:namespace:service_account_name`. **Para revogar o acesso a uma conta de serviço:** 1. Alterne as credenciais da conta de serviço. 1. Revise a orientação sobre comprometimento de pods na seção a seguir. ## Como corrigir pods do Kubernetes possivelmente comprometidos Quando GuardDuty especifica detalhes de um pod ou recurso de carga de trabalho dentro da `resource.kubernetesDetails.kubernetesWorkloadDetails` seção, esse pod ou recurso de carga de trabalho foi potencialmente comprometido. Uma GuardDuty descoberta pode indicar que um único pod foi comprometido ou que vários pods foram comprometidos por meio de um recurso de nível superior. Consulte os seguintes cenários de comprometimento para obter orientação sobre como identificar o pod ou os pods que foram comprometidos. **Comprometimento de pods individuais** Se o campo `type` dentro da seção `resource.kubernetesDetails.kubernetesWorkloadDetails` for **pods**, a descoberta identifica um único pod. O campo de nome é o `name` dos pods e o campo `namespace` é seu namespace. Para informações sobre como identificar o nó de processamento que executa os pods, consulte [Identificar o nó de processamento e pods ofensivos](https://docs.aws.amazon.com/eks/latest/best-practices/incident-response-and-forensics.html#_identify_the_offending_pod_and_worker_node) no *Guia de práticas recomendadas do Amazon EKS*. **Pods comprometidos por meio de recursos de workload** Se o campo `type` dentro da seção `resource.kubernetesDetails.kubernetesWorkloadDetails` identificar um **Recurso de workload**, como um `Deployment`, é provável que todos os pods desse recurso de workload tenham sido comprometidos. Para obter informações sobre como identificar todos os pods do recurso de workload e os nós nos quais estão sendo executados, consulte [Identificar os nós de processamento e pods ofensivos usando o nome de workload](https://docs.aws.amazon.com/eks/latest/best-practices/incident-response-and-forensics.html#_identify_the_offending_pods_and_worker_nodes_using_workload_name) no *Guia de práticas recomendadas do Amazon EKS*. **Pods comprometidos por meio da conta de serviço** Se uma GuardDuty descoberta identificar uma conta de serviço na `resource.kubernetesDetails.kubernetesUserDetails` seção, é provável que os pods que usam a conta de serviço identificada estejam comprometidos. O nome de usuário relatado por uma descoberta é uma conta de serviço se tiver o seguinte formato: `system:serviceaccount:namespace:service_account_name`. Para obter informações sobre como identificar todos os pods usando a conta de serviço e os nós nos quais estão sendo executados, consulte [Identificar os nós de processamento e pods ofensivos usando o nome da conta de serviço](https://docs.aws.amazon.com/eks/latest/best-practices/incident-response-and-forensics.html#_identify_the_offending_pods_and_worker_nodes_using_service_account_name) no *Guia de práticas recomendadas do Amazon EKS*. Depois de identificar todos os pods comprometidos e os nós em que eles estão sendo executados, consulte [Isolar o pod criando uma política de rede que negue todo o tráfego de entrada e saída do pod](https://docs.aws.amazon.com/eks/latest/best-practices/incident-response-and-forensics.html#_isolate_the_pod_by_creating_a_network_policy_that_denies_all_ingress_and_egress_traffic_to_the_pod) no *Guia de práticas recomendadas do Amazon EKS*. **Para corrigir um pod possivelmente comprometido:** 1. Identifique a vulnerabilidade que comprometeu os pods. 1. Implemente a correção para essa vulnerabilidade e inicie novos pods de substituição. 1. Exclua os pods vulneráveis. Para obter mais informações, consulte [Reimplantar o recurso de workload ou o pod comprometido](https://docs.aws.amazon.com/eks/latest/best-practices/incident-response-and-forensics.html#_redeploy_compromised_pod_or_workload_resource) no *Guia de práticas recomendadas do Amazon EKS*. Se o node de trabalho tiver recebido uma função do IAM que permite que os pods tenham acesso a outros AWS recursos, remova essas funções da instância para evitar mais danos causados pelo ataque. Da mesma forma, se o pod tiver recebido uma função do IAM, avalie se você pode remover com segurança as políticas do IAM da função sem afetar outras workloads. ## Como corrigir imagens de contêiner possivelmente comprometidas Quando uma GuardDuty descoberta indica um comprometimento do pod, a imagem usada para iniciar o pod pode ser potencialmente maliciosa ou estar comprometida. GuardDuty as descobertas identificam a imagem do contêiner dentro do `resource.kubernetesDetails.kubernetesWorkloadDetails.containers.image` campo. Você pode determinar se a imagem é mal-intencionada examinando-a em busca de malware. **Para corrigir uma imagem de contêiner potencialmente comprometida:** 1. Pare de usar a imagem imediatamente e remova-a do seu repositório de imagens. 1. Identifique todos os pods usando a imagem possivelmente comprometida. Para obter mais informações, consulte [Identificar nós de processamento e pods com imagens comprometidas ou vulneráveis](https://docs.aws.amazon.com/eks/latest/best-practices/incident-response-and-forensics.html#_identify_pods_with_vulnerable_or_compromised_images_and_worker_nodes) no *Guia de práticas recomendadas do Amazon EKS*. 1. Isole os pods potencialmente comprometidos, alterne as credenciais e colete dados para análise. Para obter mais informações, consulte [Isolar o pod criando uma política de rede que negue todo o tráfego de entrada e saída para o pod](https://docs.aws.amazon.com/eks/latest/best-practices/incident-response-and-forensics.html#_isolate_the_pod_by_creating_a_network_policy_that_denies_all_ingress_and_egress_traffic_to_the_pod) no *Guia de práticas recomendadas do Amazon EKS*. 1. Identifique todos os pods usando a imagem potencialmente comprometida. ## Como corrigir pods do Kubernetes potencialmente comprometidos Uma GuardDuty descoberta pode indicar um comprometimento do nó se o usuário identificado na descoberta representar a identidade do nó ou se a descoberta indicar o uso de um contêiner privilegiado. A identidade do usuário é um nó de processamento se o campo **nome de usuário** tiver o seguinte formato: `system:node:node name`. Por exemplo, .`system:node:ip-192-168-3-201.ec2.internal` Isso indica que o adversário obteve acesso ao nó e está usando as credenciais do nó para se comunicar com o endpoint da API do Kubernetes. Uma descoberta indica o uso de um contêiner privilegiado se um ou mais dos contêineres listados na descoberta tiver o campo de descoberta `resource.kubernetesDetails.kubernetesWorkloadDetails.containers.securityContext.privileged` definido como `True`. **Para corrigir um nó possivelmente comprometido:** 1. Isole o pod comprometido, alterne as credenciais e colete dados para análise. Para obter mais informações, consulte [Isolar o pod criando uma política de rede que negue todo o tráfego de entrada e saída para o pod](https://docs.aws.amazon.com/eks/latest/best-practices/incident-response-and-forensics.html#_isolate_the_pod_by_creating_a_network_policy_that_denies_all_ingress_and_egress_traffic_to_the_pod) no *Guia de práticas recomendadas do Amazon EKS*. 1. Identifique as contas de serviço usadas por todos os pods em execução no nó potencialmente comprometido. Revise suas permissões e alterne as contas de serviço, se necessário. 1. Encerre o nó possivelmente comprometido. # Como corrigir as descobertas do Monitoramento de runtime Quando você ativa o Runtime Monitoring para sua conta, a Amazon GuardDuty pode gerar informações [GuardDuty Tipos de descoberta de monitoramento de tempo de execução](findings-runtime-monitoring.md) que indicam possíveis problemas de segurança em seu AWS ambiente. Os possíveis problemas de segurança indicam uma instância do Amazon EC2 comprometida, carga de trabalho de contêiner, um cluster do Amazon EKS ou um conjunto de credenciais comprometidas em seu ambiente. AWS O atendente de segurança monitora eventos de runtime para vários tipos de recursos. Para identificar o recurso potencialmente comprometido, visualize o **tipo de recurso** nos detalhes da descoberta gerados no GuardDuty console. A seção a seguir descreve as etapas de correção recomendadas para qualquer tipo de recurso. ------ #### [ Instance ] Se o **Tipo de recurso** nos detalhes da descoberta for **Instância**, isso indica que uma instância do EC2 ou um nó do EKS está potencialmente comprometida. + Para corrigir um nó EKS comprometido, consulte [Como corrigir pods do Kubernetes potencialmente comprometidos](guardduty-remediate-kubernetes.md#compromised-kubernetes-node). + Para corrigir uma instância do EC2 comprometida, consulte [Como corrigir uma instância do Amazon EC2 potencialmente comprometida](compromised-ec2.md). ------ #### [ EKSCluster ] Se o **tipo de recurso** nos detalhes da descoberta for **EKSCluster**, isso indica que um pod ou um contêiner dentro de um cluster EKS está potencialmente comprometido. + Para corrigir um pod comprometido, consulte [Como corrigir pods do Kubernetes possivelmente comprometidos](guardduty-remediate-kubernetes.md#compromised-kubernetes-pod). + Para corrigir uma imagem de contêiner comprometida, consulte [Como corrigir imagens de contêiner possivelmente comprometidas](guardduty-remediate-kubernetes.md#compromised-kubernetes-image). ------ #### [ ECSCluster ] Se o **tipo de recurso** nos detalhes da descoberta for **ECSCluster**, isso indica que uma tarefa do ECS ou um contêiner dentro de uma tarefa do ECS está potencialmente comprometido. 1. **Identifique o cluster do ECS afetado.** A descoberta do GuardDuty Runtime Monitoring fornece os detalhes do cluster ECS no painel de detalhes da descoberta ou na `resource.ecsClusterDetails` seção do JSON de descoberta. 1. **Identificar a tarefa do ECS afetada** A descoberta do GuardDuty Runtime Monitoring fornece os detalhes da tarefa do ECS no painel de detalhes da descoberta ou na `resource.ecsClusterDetails.taskDetails` seção do JSON de descoberta. 1. **Isolar a tarefa afetada** Isole a tarefa afetada negando todo o tráfego de entrada e saída dessa tarefa. Uma regra para negar todo o tráfego pode ajudar a interromper um ataque em andamento, cortando todas as conexões com a tarefa. 1. **Corrigir a tarefa comprometida** 1. Identifique a vulnerabilidade que comprometeu a tarefa. 1. Implemente a correção dessa vulnerabilidade e inicie nova tarefa de substituição. 1. Parar a tarefa vulnerável. ------ #### [ Container ] Se o **Tipo de recurso** nos detalhes da descoberta for **Contêiner**, isso indica que um contêiner autônomo está potencialmente comprometido. + Para corrigir, consulte [Como corrigir um contêiner autônomo possivelmente comprometido](remediate-compromised-standalone-container.md). + Se a descoberta for gerada em vários contêineres usando a mesma imagem de contêiner, consulte [Como corrigir imagens de contêiner possivelmente comprometidas](guardduty-remediate-kubernetes.md#compromised-kubernetes-image). + Se o contêiner acessou o host EC2 subjacente, suas credenciais de instância associadas podem ter sido comprometidas. Para obter mais informações, consulte [Corrigindo credenciais potencialmente comprometidas AWS](compromised-creds.md). + Se um ator potencialmente mal-intencionado acessou o nó EKS subjacente ou uma instância do EC2, consulte a correção recomendada nas guias *EKSCluster*e *Instância*. ------ ## Como corrigir imagens de contêiner comprometidas Quando uma GuardDuty descoberta indica um comprometimento da tarefa, a imagem usada para iniciar a tarefa pode ser maliciosa ou estar comprometida. GuardDuty as descobertas identificam a imagem do contêiner dentro do `resource.ecsClusterDetails.taskDetails.containers.image` campo. Você pode determinar se a imagem é mal-intencionada examinando-a em busca de malware. **Para corrigir uma imagem de contêiner comprometida** 1. Pare de usar a imagem imediatamente e remova-a do seu repositório de imagens. 1. Identificar todas as tarefas que estão usando essa imagem. 1. Interromper todas as tarefas que estão usando a imagem comprometida. Atualizar suas configurações de tarefas para que parem de usar a imagem comprometida. # Corrigir um banco de dados possivelmente comprometido GuardDuty gerados [Tipos de descoberta da Proteção do RDS](findings-rds-protection.md) que indicam um comportamento de login potencialmente suspeito e anômalo [Bancos de dados compatíveis](rds-protection.md#rds-pro-supported-db) após a ativação. [Proteção do RDS](rds-protection.md) Usando a atividade de login do RDS, GuardDuty analisa e traça perfis de ameaças identificando padrões incomuns nas tentativas de login. **nota** Você pode acessar as informações completas sobre um tipo de descoberta selecionando-o na [GuardDuty tipos de descoberta ativa](guardduty_finding-types-active.md#findings-table). Siga estas etapas recomendadas para corrigir um banco de dados Amazon Aurora potencialmente comprometido em seu ambiente. AWS **Topics** + [Corrigir um banco de dados potencialmente comprometido com eventos de login bem-sucedidos](#gd-compromised-db-successful-attempt) + [Corrigindo um banco de dados potencialmente comprometido com eventos de login falhados](#gd-compromised-db-failed-attempt) + [Corrigir remediar credenciais potencialmente comprometidas](#gd-rds-database-compromised-credentials) + [Restringir o acesso à rede](#gd-rds-database-restrict-network-access) ## Corrigir um banco de dados potencialmente comprometido com eventos de login bem-sucedidos As etapas recomendadas a seguir podem ajudar você a corrigir um banco de dados Aurora potencialmente comprometido que apresenta um comportamento incomum relacionado a eventos de login bem-sucedidos. 1. **Identifique o banco de dados e o usuário afetados.** A GuardDuty descoberta gerada fornece o nome do banco de dados afetado e os detalhes do usuário correspondentes. Para obter mais informações, consulte [Detalhes da descoberta](guardduty_findings-summary.md). 1. **Confirme se esse comportamento é esperado ou inesperado.** A lista a seguir especifica possíveis cenários que podem ter causado GuardDuty a geração de uma descoberta: + Um usuário que faz login em seu banco de dados após um longo período de tempo. + Um usuário que faz login em seu banco de dados ocasionalmente, por exemplo, um analista financeiro que faz login a cada trimestre. + Um agente potencialmente suspeito envolvido em uma tentativa bem-sucedida de login pode comprometer o banco de dados. 1. **Comece esta etapa se o comportamento for inesperado.** 1. **Restringir acesso ao banco** Restrinja o acesso ao banco de dados para as contas suspeitas e a origem dessa atividade de login. Para obter mais informações, consulte [Corrigir remediar credenciais potencialmente comprometidas](#gd-rds-database-compromised-credentials) e [Restringir o acesso à rede](#gd-rds-database-restrict-network-access). 1. **Avalie o impacto e determine quais informações foram acessadas.** + Se disponíveis, revise os registros de auditoria para identificar as informações que podem ter sido acessadas. Para obter mais informações, consulte [Monitorar eventos, logs e streams em um cluster de banco de dados do Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/CHAP_Monitor_Logs_Events.html) no *Guia do usuário do Amazon Aurora*. + Determine se alguma informação confidencial ou protegida foi acessada ou modificada. ## Corrigindo um banco de dados potencialmente comprometido com eventos de login falhados As etapas recomendadas a seguir podem ajudar você a corrigir um banco de dados Aurora potencialmente comprometido que apresenta um comportamento incomum relacionado a eventos de login com falha. 1. **Identifique o banco de dados e o usuário afetados.** A GuardDuty descoberta gerada fornece o nome do banco de dados afetado e os detalhes do usuário correspondentes. Para obter mais informações, consulte [Detalhes da descoberta](guardduty_findings-summary.md). 1. **Identifique a origem das tentativas de login malsucedidas.** A GuardDuty descoberta gerada fornece o **endereço IP** e a **organização ASN** (se for uma conexão pública) na seção **Ator** do painel de descoberta. Um Autonomous System (AS – Sistema autônomo) é um grupo de um ou mais prefixos de IP (listas de endereços de IP acessíveis em uma rede) executados por uma ou mais operadoras de rede que mantêm uma política de roteamento única e claramente definida. Os operadores de rede precisam de Números de Sistema Autônomo (ASNs) para controlar o roteamento em suas redes e trocar informações de roteamento com outros provedores de serviços de Internet ()ISPs. 1. **Confirme se esse comportamento é inesperado.** Examine se essa atividade representa uma tentativa de obter acesso não autorizado adicional ao banco de dados da seguinte forma: + Se a fonte for interna, verifique se uma aplicação está configurado incorretamente e está tentando se conectar repetidamente. + Se for um ator externo, examine se o banco de dados correspondente está voltado para o público ou está mal configurado, permitindo que possíveis agentes mal-intencionados usem nomes de usuários comuns com força bruta. 1. **Comece esta etapa se o comportamento for inesperado.** 1. **Restringir acesso ao banco** Restrinja o acesso ao banco de dados para as contas suspeitas e a origem dessa atividade de login. Para obter mais informações, consulte [Corrigir remediar credenciais potencialmente comprometidas](#gd-rds-database-compromised-credentials) e [Restringir o acesso à rede](#gd-rds-database-restrict-network-access). 1. **Faça uma análise da causa raiz e determine as etapas que potencialmente levaram a essa atividade.** Configure um alerta para ser notificado quando uma atividade modifica uma política de rede e cria um estado inseguro. Para obter mais informações, consulte [Políticas de firewall no AWS Network Firewall](https://docs.aws.amazon.com/network-firewall/latest/developerguide/firewall-policies.html) no *Guia do desenvolvedor do AWS Network Firewall *. ## Corrigir remediar credenciais potencialmente comprometidas Uma GuardDuty descoberta pode indicar que as credenciais do usuário de um banco de dados afetado foram comprometidas quando o usuário identificado na descoberta executou uma operação inesperada no banco de dados. Você pode identificar o usuário na seção de **detalhes do usuário do RDS DB** no painel de descoberta no console ou no `resource.rdsDbUserDetails` do JSON das descobertas. Esses detalhes do usuário incluem nome de usuário, aplicativo usado, banco de dados acessado, versão SSL e método de autenticação. + Para revogar o acesso ou alternar senhas de usuários específicos envolvidos na descoberta, consulte [Segurança com o Amazon Aurora MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Security.html) ou [Segurança com o Amazon Aurora PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Security.html) no *Guia do usuário do Amazon Aurora*. + Use AWS Secrets Manager para armazenar com segurança e alternar automaticamente os segredos dos bancos de dados do Amazon Relational Database Service (RDS). Para obter mais informações, consulte [Tutoriais do AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/tutorials.html), no *Guia do usuário do AWS Secrets Manager *. + Use a autenticação do banco de dados do IAM para gerenciar o acesso dos usuários do banco de dados sem a necessidade de senhas. Para obter mais informações, consulte [Autenticação de banco de dados do IAM](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/UsingWithRDS.IAMDBAuth.html) no *Guia do usuário do Amazon Aurora.* Para obter mais informações, consulte [Práticas recomendadas de segurança do Amazon Relational Database Service](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_BestPractices.Security.html) no *Guia do usuário do Amazon RDS*. ## Restringir o acesso à rede Uma GuardDuty descoberta pode indicar que um banco de dados está acessível além de seus aplicativos ou da Virtual Private Cloud (VPC). Se o endereço IP remoto na descoberta for uma fonte de conexão inesperada, audite os grupos de segurança. Uma lista de grupos de segurança anexados ao banco de dados está disponível em **Grupos de segurança** no [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)console ou no JSON `resource.rdsDbInstanceDetails.dbSecurityGroups` das descobertas. Para obter mais informações sobre a configuração de grupos de segurança, consulte [Controlar acesso com grupos de segurança](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.RDSSecurityGroups.html) no *Guia do usuário do Amazon RDS*. Se você estiver usando um firewall, restrinja o acesso à rede ao banco de dados reconfigurando as Listas de Controle de Acesso à Rede ()NACLs. Para obter mais informações, consulte [Firewalls no AWS Network Firewall](https://docs.aws.amazon.com/network-firewall/latest/developerguide/firewalls.html) no *Guia do desenvolvedor do AWS Network Firewall *. # Correção de uma função do Lambda comprometida Quando GuardDuty gerada[Tipos de descoberta da Proteção do Lambda](lambda-protection-finding-types.md), sua função Lambda pode ser comprometida. Se a atividade que causou GuardDuty a geração dessa descoberta era esperada, você pode considerar usar[Regras de supressão](findings_suppression-rule.md). Recomendamos concluir as etapas a seguir para corrigir uma função do Lambda comprometida. **Para corrigir as descobertas da Proteção do Lambda** 1. **Identifique a versão da função Lambda potencialmente comprometida**. Uma GuardDuty descoberta para o Lambda Protection fornece o nome, o Amazon Resource Name (ARN), a versão da função e o ID da revisão associados à função Lambda listada nos detalhes da descoberta. 1. **Identifique a origem da atividade suspeita**. 1. Analise o código associado à versão da função do Lambda envolvida na descoberta. 1. Analise as bibliotecas e camadas importadas da versão da função do Lambda envolvida na descoberta. 1. Se você ativou [AWS Lambda as funções de digitalização com o Amazon Inspector](https://docs.aws.amazon.com/inspector/latest/user/scanning-lambda.html), revise as descobertas do [Amazon Inspector](https://docs.aws.amazon.com/inspector/latest/user/findings-understanding-locating-analyzing.html) associadas à função Lambda envolvida na descoberta. 1. Analise os AWS CloudTrail registros para identificar o principal que causou a atualização da função e garantir que a atividade foi autorizada ou esperada. 1. **Corrija a função do Lambda potencialmente comprometida**. 1. Desabilite os acionadores de execução da função do Lambda envolvida na descoberta. Para obter mais informações, consulte [DeleteFunctionEventInvokeConfig](https://docs.aws.amazon.com/lambda/latest/dg/API_DeleteFunctionEventInvokeConfig.html). 1. Revise o código do Lambda e atualize as importações de bibliotecas e as [camadas da função do Lambda](https://docs.aws.amazon.com/lambda/latest/dg/chapter-layers.html) para remover as bibliotecas e camadas potencialmente suspeitas. 1. Mitigue as descobertas do Amazon Inspector relacionadas à função do Lambda envolvida na descoberta.