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

# Pré-requisitos para suporte de instância do Amazon EC2
<a name="prereq-runtime-monitoring-ec2-support"></a>

Esta seção inclui os pré-requisitos para monitorar o comportamento de runtime das instâncias do Amazon EC2. Depois que esses pré-requisitos forem atendidos, consulte [Habilitando o GuardDuty monitoramento de tempo](runtime-monitoring-configuration.md).

**Topics**
+ [Tornar as instâncias do EC2 gerenciadas por SSM (somente para configuração automatizada de agentes)](#ssm-managed-prereq-ec2)
+ [Validação dos requisitos de arquitetura](#validating-architecture-req-ec2)
+ [Validando a política de controle de serviço da sua organização em um ambiente de várias contas](#validate-organization-scp-ec2)
+ [Ao usar a configuração de agente automatizado](#runtime-ec2-prereq-automated-agent)
+ [Limite de CPU e memória para o GuardDuty agente](#ec2-cpu-memory-limits-gdu-agent)
+ [Próxima etapa](#next-step-after-prereq-ec2)

## Tornar as instâncias do EC2 gerenciadas por SSM (somente para configuração automatizada de agentes)
<a name="ssm-managed-prereq-ec2"></a>

GuardDuty usa AWS Systems Manager (SSM) para implantar, instalar e gerenciar automaticamente o agente de segurança em suas instâncias. Se você planeja instalar e gerenciar manualmente o GuardDuty agente, o SSM não é necessário. 

Para gerenciar suas instâncias do Amazon EC2 com o Systems Manager, consulte [Configurando o Systems Manager para instâncias do Amazon EC2](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-setting-up-ec2.html) no *Guia do usuário do AWS Systems Manager *.

## Validação dos requisitos de arquitetura
<a name="validating-architecture-req-ec2"></a>

A arquitetura da distribuição do sistema operacional pode afetar o comportamento do agente de GuardDuty segurança. Você deve atender aos seguintes requisitos para usar o Monitoramento de runtime para instâncias do Amazon EC2:
+ O suporte do kernel inclui `eBPF`, `Tracepoints` e `Kprobe`. Para arquiteturas de CPU, o Runtime Monitoring suporta AMD64 (`x64`) e ARM64 (Graviton2 e superior). [1](#runtime-monitoring-ec2-graviton-2-support)

  A tabela a seguir mostra a distribuição do sistema operacional que foi verificada para oferecer suporte ao agente GuardDuty de segurança para instâncias do Amazon EC2.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/guardduty/latest/ug/prereq-runtime-monitoring-ec2-support.html)

  1. <a name="runtime-monitoring-ec2-graviton-2-support"></a>O Monitoramento de Runtime para recursos do Amazon EC2 não é compatível com a instância Graviton de primeira geração, como os tipos de instância A1.

  1. <a name="runtime-monitoring-ec2-os-support"></a>Suporte para vários sistemas operacionais - GuardDuty verificou o suporte do Runtime Monitoring para a distribuição operacional listada na tabela anterior. Embora o agente GuardDuty de segurança possa ser executado em sistemas operacionais não listados na tabela anterior, a GuardDuty equipe não pode garantir o valor de segurança esperado.

  1. <a name="runtime-monitoring-ec2-kernel-version-required-flag"></a>Para qualquer versão do kernel, você deve definir o sinalizador `CONFIG_DEBUG_INFO_BTF` como `y` (isto é, *verdadeiro*). Isso é necessário para que o agente GuardDuty de segurança possa ser executado conforme o esperado.

  1. <a name="runtime-monitoring-ec2-kernel-5-10"></a>Para as versões 5.10 e anteriores do kernel, o agente GuardDuty de segurança usa memória bloqueada na RAM (`RLIMIT_MEMLOCK`) para funcionar conforme o esperado. Se o `RLIMIT_MEMLOCK` valor do seu sistema estiver definido como muito baixo, GuardDuty recomenda definir limites rígidos e flexíveis para pelo menos 32 MB. Para obter informações sobre como verificar e modificar o valor de `RLIMIT_MEMLOCK` padrão, consulte [Visualização e atualização de valores de `RLIMIT_MEMLOCK`](#runtime-monitoring-ec2-modify-rlimit-memlock).

  1. <a name="runtime-monitoring-ec2-ubuntu-noble-agent-version"></a>Para o Ubuntu 24.04, as versões 6.13 e 6.14 do kernel oferecem suporte somente às versões do agente EC2 1.9.2 e superiores.
+ Requisitos adicionais - Somente se você tiver o Amazon ECS/Amazon EC2

  Para o Amazon ECS/Amazon EC2, recomendamos que você use a versão mais recente otimizada para Amazon ECS AMIs (datada de 29 de setembro de 2023 ou posterior) ou use a versão v1.77.0 do agente Amazon ECS. 

### Visualização e atualização de valores de `RLIMIT_MEMLOCK`
<a name="runtime-monitoring-ec2-modify-rlimit-memlock"></a>

Quando o `RLIMIT_MEMLOCK` limite do seu sistema é definido como muito baixo, o agente de GuardDuty segurança pode não funcionar conforme projetado. GuardDuty recomenda que os limites rígidos e flexíveis sejam de pelo menos 32 MB. Se você não atualizar os limites, não GuardDuty conseguirá monitorar os eventos de tempo de execução do seu recurso. Quando `RLIMIT_MEMLOCK` está acima dos limites mínimos estabelecidos, torna-se opcional que você atualize esses limites.

Você pode modificar o `RLIMIT_MEMLOCK` valor padrão antes ou depois de instalar o agente GuardDuty de segurança. 

**Para visualizar valores `RLIMIT_MEMLOCK`**

1. Executar `ps aux | grep guardduty`. Isso exibirá o ID do processo (`pid`).

1. Copie o ID do processo (`pid`) da saída do comando anterior.

1. Execute `grep "Max locked memory" /proc/pid/limits` após substituir o `pid` pelo ID do processo copiado da etapa anterior.

   Isso exibirá a memória máxima bloqueada para executar o agente GuardDuty de segurança.

**Para atualizar valores `RLIMIT_MEMLOCK`**

1. Se o arquivo `/etc/systemd/system.conf.d/NUMBER-limits.conf` existir, comente a linha de `DefaultLimitMEMLOCK` desse arquivo. Esse arquivo define um `RLIMIT_MEMLOCK` padrão com alta prioridade, que substitui suas configurações no arquivo `/etc/systemd/system.conf`.

1. Abra o arquivo `/etc/systemd/system.conf` e remova o comentário da linha com `#DefaultLimitMEMLOCK=`.

1. Atualize o valor padrão fornecendo limites de `RLIMIT_MEMLOCK` rígidos e flexíveis de pelo menos 32 MB. A atualização deve ter a seguinte aparência: `DefaultLimitMEMLOCK=32M:32M`. O formato é `soft-limit:hard-limit`.

1. Executar `sudo reboot`.

## Validando a política de controle de serviço da sua organização em um ambiente de várias contas
<a name="validate-organization-scp-ec2"></a>

Se você configurou uma política de controle de serviços (SCP) para gerenciar permissões na sua organização, confirme se o limite de permissões permite a ação `guardduty:SendSecurityTelemetry`. É necessário para oferecer suporte GuardDuty ao Runtime Monitoring em diferentes tipos de recursos.

Se você for uma conta de membro, conecte-se com o administrador delegado associado. Para obter informações sobre o gerenciamento SCPs de sua organização, consulte [Políticas de controle de serviços (SCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html).

## Ao usar a configuração de agente automatizado
<a name="runtime-ec2-prereq-automated-agent"></a>

Para [Usar a configuração de agente automatizado (recomendado)](how-runtime-monitoring-works-ec2.md#use-automated-agent-config-ec2) isso, você Conta da AWS deve atender aos seguintes pré-requisitos:
+ Ao usar tags de inclusão com configuração automática de agentes, GuardDuty para criar uma associação SSM para uma nova instância, certifique-se de que a nova instância seja gerenciada por SSM e apareça no **Fleet Manager** no [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)console.
+ Ao usar tags de exclusão com configuração de agente automatizado:
  + Adicione a `false` tag`GuardDutyManaged`: antes de configurar o agente GuardDuty automatizado para sua conta.

    Certifique-se de adicionar a tag de exclusão às instâncias do Amazon EC2 antes de iniciá-las. Depois de habilitar a configuração automatizada do agente para o Amazon EC2, qualquer instância do EC2 que seja executada sem uma tag de exclusão será coberta GuardDuty pela configuração automática do agente.
  + Habilite a configuração **Permitir tags nos metadados** para suas instâncias. Essa configuração é necessária porque GuardDuty precisa ler a tag de exclusão do serviço de metadados da instância (IMDS) para determinar se ela deve excluir a instância da instalação do agente. Para obter mais informações, consulte [Habilitar o acesso a tags em metadados da instância](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/work-with-tags-in-IMDS.html#allow-access-to-tags-in-IMDS) no *Guia do usuário do Amazon EC2*.

## Limite de CPU e memória para o GuardDuty agente
<a name="ec2-cpu-memory-limits-gdu-agent"></a>

**Limite da CPU**  
O limite máximo de CPU para o agente GuardDuty de segurança associado às instâncias do Amazon EC2 é de 10% do total de núcleos de vCPU. Por exemplo, se sua instância do EC2 tiver 4 núcleos de vCPU, o agente de segurança poderá usar, no máximo, 40% do total disponível de 400%.

**Limite de memória**  
Da memória associada à sua instância do Amazon EC2, há uma memória limitada que o agente de GuardDuty segurança pode usar.   
A tabela a seguir mostra o limite de memória.      
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/guardduty/latest/ug/prereq-runtime-monitoring-ec2-support.html)

## Próxima etapa
<a name="next-step-after-prereq-ec2"></a>

A próxima etapa é configurar o Monitoramento de runtime e também gerenciar o agente de segurança (automática ou manualmente).