

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

# Prerequisiti per abilitare il monitoraggio del runtime
<a name="runtime-monitoring-prerequisites"></a>

Per abilitare il Runtime Monitoring e gestire il GuardDuty security agent, è necessario soddisfare i prerequisiti per ogni tipo di risorsa che si desidera monitorare per il rilevamento delle minacce. Ogni tipo di risorsa presenta prerequisiti diversi. Ad esempio, GuardDuty supporta diverse distribuzioni del sistema operativo in base al tipo di risorsa.

Se desideri monitorare solo le risorse Amazon EC2, devi rispettare i prerequisiti per le istanze Amazon EC2. Se in un secondo momento scegli di monitorare le risorse Amazon EKS, devi rispettare i prerequisiti specifici dei cluster Amazon EKS.

Le seguenti sezioni includono i prerequisiti in base al tipo di risorsa.

**Topics**
+ [Prerequisiti per il supporto delle istanze Amazon EC2](prereq-runtime-monitoring-ec2-support.md)
+ [Prerequisiti per il AWS Fargate supporto (solo Amazon ECS)](prereq-runtime-monitoring-ecs-support.md)
+ [Prerequisiti per il supporto dei cluster Amazon EKS](prereq-runtime-monitoring-eks-support.md)

# Prerequisiti per il supporto delle istanze Amazon EC2
<a name="prereq-runtime-monitoring-ec2-support"></a>

Questa sezione include i prerequisiti per il monitoraggio del comportamento di runtime delle istanze Amazon EC2. Una volta soddisfatti questi prerequisiti, consulta. [Abilitazione del monitoraggio del GuardDuty runtime](runtime-monitoring-configuration.md)

**Topics**
+ [Rendi le istanze EC2 gestite tramite SSM (solo per la configurazione automatica degli agenti)](#ssm-managed-prereq-ec2)
+ [Convalida i requisiti architettonici](#validating-architecture-req-ec2)
+ [Convalida della politica di controllo dei servizi della tua organizzazione in un ambiente con più account](#validate-organization-scp-ec2)
+ [Quando si utilizza la configurazione automatica degli agenti](#runtime-ec2-prereq-automated-agent)
+ [Limite di CPU e memoria per l'agente GuardDuty](#ec2-cpu-memory-limits-gdu-agent)
+ [Approfondimenti](#next-step-after-prereq-ec2)

## Rendi le istanze EC2 gestite tramite SSM (solo per la configurazione automatica degli agenti)
<a name="ssm-managed-prereq-ec2"></a>

GuardDuty utilizza AWS Systems Manager (SSM) per distribuire, installare e gestire automaticamente il security agent sulle tue istanze. Se si prevede di installare e gestire manualmente l' GuardDuty agente, l'SSM non è necessario. 

*Per gestire le istanze Amazon EC2 con Systems Manager, consulta [Configurazione delle istanze di Systems Manager per Amazon EC2 nella Guida per l'](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-setting-up-ec2.html)utente.AWS Systems Manager *

## Convalida i requisiti architettonici
<a name="validating-architecture-req-ec2"></a>

L'architettura della distribuzione del sistema operativo potrebbe influire sul comportamento del GuardDuty Security Agent. È necessario soddisfare i seguenti requisiti prima di utilizzare Runtime Monitoring per le istanze Amazon EC2:
+ Il supporto del kernel include `eBPF` e. `Tracepoints` `Kprobe` Per le architetture CPU, Runtime Monitoring supporta AMD64 (`x64`) e ARM64 (Graviton2 e versioni successive). [1](#runtime-monitoring-ec2-graviton-2-support)

  La tabella seguente mostra la distribuzione del sistema operativo che è stata verificata per supportare l'agente GuardDuty di sicurezza per le istanze Amazon EC2.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/guardduty/latest/ug/prereq-runtime-monitoring-ec2-support.html)

  1. <a name="runtime-monitoring-ec2-graviton-2-support"></a>Il monitoraggio del runtime per le risorse Amazon EC2 non supporta le istanze Graviton di prima generazione come i tipi di istanze A1.

  1. <a name="runtime-monitoring-ec2-os-support"></a>Supporto per vari sistemi operativi: GuardDuty ha verificato il supporto del Runtime Monitoring per la distribuzione operativa elencata nella tabella precedente. Sebbene il GuardDuty security agent possa funzionare su sistemi operativi non elencati nella tabella precedente, il GuardDuty team non può garantire il valore di sicurezza previsto.

  1. <a name="runtime-monitoring-ec2-kernel-version-required-flag"></a>Per qualsiasi versione del kernel, è necessario impostare il `CONFIG_DEBUG_INFO_BTF` flag su `y` (che significa *true*). Ciò è necessario per consentire al GuardDuty Security Agent di funzionare come previsto.

  1. <a name="runtime-monitoring-ec2-kernel-5-10"></a>Per le versioni del kernel 5.10 e precedenti, il GuardDuty security agent utilizza la memoria bloccata nella RAM (`RLIMIT_MEMLOCK`) per funzionare come previsto. Se il `RLIMIT_MEMLOCK` valore del sistema è impostato su un valore troppo basso, si GuardDuty consiglia di impostare i limiti rigidi e morbidi su almeno 32 MB. Per informazioni sulla verifica e la modifica del `RLIMIT_MEMLOCK` valore predefinito, vedere. [Visualizzazione e aggiornamento dei valori `RLIMIT_MEMLOCK`](#runtime-monitoring-ec2-modify-rlimit-memlock)

  1. <a name="runtime-monitoring-ec2-ubuntu-noble-agent-version"></a>Per Ubuntu 24.04, le versioni del kernel 6.13 e 6.14 supportano solo le versioni dell'agente EC2 1.9.2 e successive.
+ Requisiti aggiuntivi: solo se disponi di Amazon ECS/Amazon EC2

  Per Amazon ECS/Amazon EC2, ti consigliamo di utilizzare la versione più recente ottimizzata per Amazon ECS AMIs (datata 29 settembre 2023 o successiva) o di utilizzare la versione dell'agente Amazon ECS v1.77.0. 

### Visualizzazione e aggiornamento dei valori `RLIMIT_MEMLOCK`
<a name="runtime-monitoring-ec2-modify-rlimit-memlock"></a>

Quando il `RLIMIT_MEMLOCK` limite del sistema è troppo basso, il GuardDuty Security Agent potrebbe non funzionare come previsto. GuardDuty raccomanda che sia i limiti rigidi che quelli flessibili siano di almeno 32 MB. Se non aggiorni i limiti, non GuardDuty sarà possibile monitorare gli eventi di runtime della risorsa. Quando `RLIMIT_MEMLOCK` supera i limiti minimi indicati, l'aggiornamento di tali limiti diventa facoltativo.

È possibile modificare il `RLIMIT_MEMLOCK` valore predefinito prima o dopo l'installazione del GuardDuty Security Agent. 

**Per visualizzare `RLIMIT_MEMLOCK` i valori**

1. Esegui `ps aux | grep guardduty`. Questo produrrà l'ID del processo (`pid`).

1. Copia l'ID del processo (`pid`) dall'output del comando precedente.

1. Esegui `grep "Max locked memory" /proc/pid/limits` dopo averlo sostituito `pid` con l'ID di processo copiato dal passaggio precedente.

   Verrà visualizzata la quantità massima di memoria bloccata per l'esecuzione del GuardDuty Security Agent.

**Per aggiornare `RLIMIT_MEMLOCK` i valori**

1. Se il `/etc/systemd/system.conf.d/NUMBER-limits.conf` file esiste, commenta la riga `DefaultLimitMEMLOCK` di questo file. Questo file imposta un valore predefinito `RLIMIT_MEMLOCK` con priorità alta, che sovrascrive le impostazioni nel `/etc/systemd/system.conf` file.

1. Apri il `/etc/systemd/system.conf` file e decommenta la riga che contiene. `#DefaultLimitMEMLOCK=`

1. Aggiorna il valore predefinito fornendo `RLIMIT_MEMLOCK` limiti rigidi e flessibili di almeno 32 MB. L'aggiornamento dovrebbe assomigliare a questo:`DefaultLimitMEMLOCK=32M:32M`. Il formato è `soft-limit:hard-limit`.

1. Esegui `sudo reboot`.

## Convalida della politica di controllo dei servizi della tua organizzazione in un ambiente con più account
<a name="validate-organization-scp-ec2"></a>

Se hai impostato una policy di controllo dei servizi (SCP) per gestire le autorizzazioni nella tua organizzazione, verifica che il limite delle autorizzazioni consenta l'azione. `guardduty:SendSecurityTelemetry` È necessario per supportare il monitoraggio del runtime GuardDuty su diversi tipi di risorse.

Se sei un account membro, connettiti con l'amministratore delegato associato. Per informazioni sulla gestione SCPs dell'organizzazione, consulta [le politiche di controllo del servizio (SCPs).](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)

## Quando si utilizza la configurazione automatica degli agenti
<a name="runtime-ec2-prereq-automated-agent"></a>

Per [Utilizza la configurazione automatica degli agenti (scelta consigliata)](how-runtime-monitoring-works-ec2.md#use-automated-agent-config-ec2) farlo, Account AWS è necessario soddisfare i seguenti prerequisiti:
+ Quando utilizzi tag di inclusione con configurazione automatica degli agenti, per GuardDuty creare un'associazione SSM per una nuova istanza, assicurati che la nuova istanza sia gestita tramite SSM e venga visualizzata in **Fleet Manager nella console**. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)
+ Quando si utilizzano i tag di esclusione con la configurazione automatica degli agenti:
  + Aggiungi il `false` tag`GuardDutyManaged`: prima di configurare l'agente GuardDuty automatico per il tuo account.

    Assicurati di aggiungere il tag di esclusione alle istanze Amazon EC2 prima di avviarle. Dopo aver abilitato la configurazione automatizzata degli agenti per Amazon EC2, qualsiasi istanza EC2 che viene avviata senza un tag di esclusione sarà coperta dalla configurazione automatizzata dell'agente. GuardDuty 
  + Abilita l'opzione **Consenti tag nelle impostazioni dei metadati** per le tue istanze. Questa impostazione è necessaria perché GuardDuty deve leggere il tag di esclusione dall'Instance Metadata Service (IMDS) per determinare se escludere l'istanza dall'installazione dell'agente. Per ulteriori informazioni, consulta [Abilita l'accesso ai tag nei metadati dell'istanza nella Guida](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/work-with-tags-in-IMDS.html#allow-access-to-tags-in-IMDS) per l'utente di *Amazon EC2*.

## Limite di CPU e memoria per l'agente GuardDuty
<a name="ec2-cpu-memory-limits-gdu-agent"></a>

**Limite della CPU**  
Il limite massimo di CPU per il GuardDuty security agent associato alle istanze Amazon EC2 è pari al 10% dei core vCPU totali. Ad esempio, se l'istanza EC2 ha 4 core vCPU, il security agent può utilizzare al massimo il 40 percento del 400 percento totale disponibile.

**Memory limit (Limite memoria)**  
Dalla memoria associata all'istanza Amazon EC2, c'è una memoria limitata che il GuardDuty security agent può utilizzare.   
La tabella seguente mostra il limite di memoria.      
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/guardduty/latest/ug/prereq-runtime-monitoring-ec2-support.html)

## Approfondimenti
<a name="next-step-after-prereq-ec2"></a>

Il passaggio successivo consiste nella configurazione del Runtime Monitoring e nella gestione del security agent (automaticamente o manualmente).

# Prerequisiti per il AWS Fargate supporto (solo Amazon ECS)
<a name="prereq-runtime-monitoring-ecs-support"></a>

Questa sezione include i prerequisiti per il monitoraggio del comportamento di runtime delle risorse Fargate-Amazon ECS. Una volta soddisfatti questi prerequisiti, vedere. [Abilitazione del monitoraggio del GuardDuty runtime](runtime-monitoring-configuration.md)

**Topics**
+ [Convalida dei requisiti relativi all'architettura](#validating-architecture-req-ecs)
+ [Prerequisiti per l'accesso all'immagine del contenitore](#before-enable-runtime-monitoring-ecs)
+ [Convalida della politica di controllo dei servizi dell'organizzazione in un ambiente con più account](#validate-organization-scp-ecs)
+ [Convalida delle autorizzazioni dei ruoli e del limite delle autorizzazioni delle policy](#guardduty-runtime-monitoring-ecs-permission-boundary)
+ [Limiti di CPU e di memoria](#ecs-runtime-agent-cpu-memory-limits)

## Convalida dei requisiti relativi all'architettura
<a name="validating-architecture-req-ecs"></a>

La piattaforma utilizzata può influire sul modo GuardDuty in cui il GuardDuty Security Agent supporta la ricezione degli eventi di runtime dai cluster Amazon ECS. Devi confermare di utilizzare una delle piattaforme verificate.

**Considerazioni iniziali:**  
La AWS Fargate piattaforma per i tuoi cluster Amazon ECS deve essere Linux. La versione della piattaforma corrispondente deve essere almeno`1.4.0`, o. `LATEST` Per ulteriori informazioni sulle versioni della piattaforma, consulta le versioni della [piattaforma Linux](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/platform-linux-fargate.html) nella *Amazon Elastic Container Service Developer Guide*.  
Le versioni della piattaforma Windows non sono ancora supportate. 

### Piattaforme verificate
<a name="ecs-verified-platforms-gdu-agent"></a>

La distribuzione del sistema operativo e l'architettura della CPU influiscono sul supporto fornito dal GuardDuty security agent. La tabella seguente mostra la configurazione verificata per la distribuzione del GuardDuty security agent e la configurazione del Runtime Monitoring.


| distribuzione del sistema operativo **[1](#runtime-monitoring-ecs-os-support)**  | Supporto del kernel | Architettura CPU x64 () AMD64 | Architettura CPU Graviton () ARM64 | 
| --- | --- | --- | --- | 
| Linux | eBPF, Tracepoints, Kprobe | Supportata | Supportata | <a name="runtime-monitoring-ecs-os-support"></a>

1 Supporto per vari sistemi operativi: GuardDuty ha verificato il supporto del Runtime Monitoring per la distribuzione operativa elencata nella tabella precedente. Sebbene il GuardDuty security agent possa funzionare su sistemi operativi non elencati nella tabella precedente, il GuardDuty team non può garantire il valore di sicurezza previsto.

## Prerequisiti per l'accesso all'immagine del contenitore
<a name="before-enable-runtime-monitoring-ecs"></a>

I seguenti prerequisiti consentono di accedere all'immagine del contenitore GuardDuty sidecar dal repository Amazon ECR.

### Requisiti per le autorizzazioni
<a name="ecs-runtime-permissions-requirements"></a>

Il ruolo di esecuzione dell'attività richiede determinate autorizzazioni Amazon Elastic Container Registry (Amazon ECR) per scaricare l'immagine del contenitore GuardDuty del Security Agent:

```
...
      "ecr:GetAuthorizationToken",
      "ecr:BatchCheckLayerAvailability",
      "ecr:GetDownloadUrlForLayer",
      "ecr:BatchGetImage",
...
```

Per limitare ulteriormente le autorizzazioni di Amazon ECR, puoi aggiungere l'URI del repository Amazon ECR che ospita l'agente di GuardDuty sicurezza per (solo AWS Fargate Amazon ECS). Per ulteriori informazioni, consulta [Agente di hosting del repository Amazon ECR GuardDuty](runtime-monitoring-ecr-repository-gdu-agent.md).

Puoi utilizzare la policy ECSTask ExecutionRolePolicy gestita da [Amazon](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_execution_IAM_role.html) o aggiungere le autorizzazioni di cui sopra alla tua `TaskExecutionRole` politica.

### Configurazione della definizione dell'attività
<a name="ecs-runtime-task-definition"></a>

Quando crei o aggiorni i servizi Amazon ECS, devi fornire informazioni sulla sottorete nella definizione dell'attività:

L'esecuzione di [CreateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateService.html)e [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html) APIs nell'*Amazon Elastic Container Service API Reference* richiede il trasferimento delle informazioni sulla sottorete. Per ulteriori informazioni, consulta le [definizioni delle attività di Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definitions.html) nella *Amazon Elastic Container Service Developer Guide*.

### Requisiti di connessione di rete
<a name="ecs-runtime-network-requirements"></a>

È necessario garantire la connettività di rete per scaricare l'immagine del GuardDuty contenitore da Amazon ECR. Questo requisito è specifico GuardDuty perché utilizza Amazon ECR per ospitare il suo agente di sicurezza. A seconda della configurazione di rete, è necessario implementare una delle seguenti opzioni:

**Opzione 1: utilizzo dell'accesso alla rete pubblica (se disponibile)**  
Se le attività di Fargate vengono eseguite in sottoreti con accesso a Internet in uscita, non è richiesta alcuna configurazione di rete aggiuntiva.

**Opzione 2: utilizzo degli endpoint Amazon VPC (per sottoreti private)**  
Se le attività Fargate vengono eseguite in sottoreti private senza accesso a Internet, è necessario configurare gli endpoint VPC per ECR per garantire che l'URI del repository ECR che ospita il security agent sia accessibile dalla rete. GuardDuty Senza questi endpoint, le attività nelle sottoreti private non possono scaricare l'immagine del contenitore. GuardDuty   
*Per le istruzioni sulla configurazione degli endpoint VPC, consulta Create [the VPC endpoint for Amazon ECR nella Amazon](https://docs.aws.amazon.com/AmazonECR/latest/userguide/vpc-endpoints.html#ecr-setting-up-vpc-create) Elastic Container Registry User Guide.*

Per informazioni su come abilitare Fargate a scaricare il GuardDuty contenitore, consulta Using [Amazon ECR images with Amazon ECS nella Amazon](https://docs.aws.amazon.com/AmazonECR/latest/userguide/ECR_on_ECS.html) *Elastic Container* Registry User Guide.

### Configurazione del gruppo di sicurezza
<a name="ecs-runtime-security-group-requirements"></a>

Le immagini dei GuardDuty container sono in Amazon ECR e richiedono l'accesso ad Amazon S3. Questo requisito è specifico per il download di immagini di container da Amazon ECR. Per le attività con accesso limitato alla rete, è necessario configurare i gruppi di sicurezza per consentire l'accesso a S3.

Aggiungi una regola in uscita nel tuo gruppo di sicurezza che consenta il traffico verso l'[elenco dei prefissi gestiti di S3 (`pl-xxxxxxxx`)](https://docs.aws.amazon.com/vpc/latest/privatelink/gateway-endpoints.html#gateway-endpoint-security) sulla porta 443. Per aggiungere una regola in uscita, consulta [Configura le regole dei gruppi di sicurezza](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-security-group-rules.html) nella *Amazon VPC* User Guide.

Per visualizzare gli elenchi di prefissi AWS-managed nella console o descriverli utilizzando AWS Command Line Interface (AWS CLI), consulta [AWS-managed prefix lists nella](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-aws-managed-prefix-lists.html) Amazon *VPC* User Guide.

## Convalida della politica di controllo dei servizi dell'organizzazione in un ambiente con più account
<a name="validate-organization-scp-ecs"></a>

Questa sezione spiega come convalidare le impostazioni della policy di controllo del servizio (SCP) per garantire che il Runtime Monitoring funzioni come previsto in tutta l'organizzazione.

Se avete impostato una o più politiche di controllo del servizio per gestire le autorizzazioni nella vostra organizzazione, dovete verificare che l'azione non venga negata. `guardduty:SendSecurityTelemetry` *Per informazioni su come SCPs funziona, consulta la [valutazione SCP](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_evaluation.html) nella Guida per l'utente.AWS Organizations *

Se sei un account membro, connettiti con l'amministratore delegato associato. Per informazioni sulla gestione SCPs dell'organizzazione, consulta [le politiche di controllo del servizio (SCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) nella *Guida per l'AWS Organizations utente*.

Esegui i passaggi seguenti per tutto SCPs ciò che hai configurato nel tuo ambiente multi-account:

**La convalida non `guardduty:SendSecurityTelemetry` è negata in SCP**

1. Accedi alla console Organizations all'indirizzo [https://console.aws.amazon.com/organizations/](https://console.aws.amazon.com/organizations/). Devi accedere come ruolo IAM o accedere come utente root [(scelta non consigliata)](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#lock-away-credentials) nell'account di gestione dell'organizzazione.

1. Nel riquadro di navigazione a sinistra, seleziona **Policies (Policy)**. Quindi, in **Tipi di policy supportati**, seleziona **Service control policies**.

1. Nella pagina **Criteri di controllo del servizio**, scegli il nome della politica che desideri convalidare.

1. Nella pagina dei dettagli della politica, visualizza il **contenuto** di questa politica. Assicurati che non neghi l'`guardduty:SendSecurityTelemetry`azione.

   La seguente politica SCP è un esempio di come *non negare* l'azione: `guardduty:SendSecurityTelemetry`

------
#### [ JSON ]

****  

   ```
   {
       "Version":"2012-10-17",		 	 	 
       "Statement": [
           {
       "Effect": "Allow",
               "Action": [           
                   "guardduty:SendSecurityTelemetry"
               ],
               "Resource": "*"
           }
       ]
   }
   ```

------

   Se la tua politica nega questa azione, devi aggiornare la politica. Per ulteriori informazioni, consulta [Aggiornamento di una policy di controllo dei servizi](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_policies_update.html#update_policy) nella *Guida per l'utente di AWS Organizations *.

## Convalida delle autorizzazioni dei ruoli e del limite delle autorizzazioni delle policy
<a name="guardduty-runtime-monitoring-ecs-permission-boundary"></a>

**Utilizza i seguenti passaggi per verificare che i limiti delle autorizzazioni associati al ruolo e alla relativa politica non influiscano sull'azione di restrizione.** `guardduty:SendSecurityTelemetry`

**Per visualizzare i limiti delle autorizzazioni per i ruoli e la relativa politica**

1. Accedi Console di gestione AWS e apri la console IAM all'indirizzo. [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)

1. Nel riquadro di navigazione a sinistra, in **Gestione degli accessi**, scegli **Ruoli**.

1. Nella pagina **Ruoli**, seleziona il ruolo *`TaskExecutionRole`* che potresti aver creato.

1. Nella pagina del ruolo selezionato, nella scheda **Autorizzazioni**, espandi il nome della policy associata a questo ruolo. Quindi, verifica che questa politica non preveda restrizioni. `guardduty:SendSecurityTelemetry`

1. Se il **limite delle autorizzazioni** è impostato, espandi questa sezione. Quindi, espandi ogni politica per verificare che non limiti l'azione`guardduty:SendSecurityTelemetry`. La politica dovrebbe apparire simile a questa[Example SCP policy](#ecs-runtime-scp-not-deny-policy-example).

   Se necessario, esegui una delle seguenti azioni:
   + Per modificare la politica, seleziona **Modifica**. Nella pagina **Modifica le autorizzazioni** per questa politica, aggiorna la politica nell'**editor delle politiche**. Assicurati che lo schema JSON rimanga valido. Quindi, seleziona **Successivo**. Quindi, puoi rivedere e salvare le modifiche.
   + **Per modificare questo limite di autorizzazioni e scegliere un altro limite, scegli Cambia limite.**
   + **Per rimuovere questo limite di autorizzazioni, scegli Rimuovi limite.**

   *Per informazioni sulla gestione delle policy, consulta Policies [and permissions AWS Identity and Access Management nella](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) IAM User Guide.*

## Limiti di CPU e di memoria
<a name="ecs-runtime-agent-cpu-memory-limits"></a>

Nella definizione dell'attività Fargate, è necessario specificare il valore della CPU e della memoria a livello di attività. La tabella seguente mostra le combinazioni valide di valori di CPU e memoria a livello di task e il limite massimo di memoria del GuardDuty Security Agent corrispondente per il contenitore. GuardDuty 

[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/guardduty/latest/ug/prereq-runtime-monitoring-ecs-support.html)

Dopo aver abilitato il Runtime Monitoring e verificato che lo stato di copertura del cluster sia **integro**, puoi configurare e visualizzare le metriche di Container Insight. Per ulteriori informazioni, consulta [Configurazione del monitoraggio sul cluster Amazon ECS](runtime-monitoring-setting-cpu-mem-monitoring.md#ecs-runtime-cpu-memory-monitoring-agent).

Il passaggio successivo consiste nel configurare Runtime Monitoring e configurare anche il security agent.

# Prerequisiti per il supporto dei cluster Amazon EKS
<a name="prereq-runtime-monitoring-eks-support"></a>

Questa sezione include i prerequisiti per il monitoraggio del comportamento di runtime delle risorse Amazon EKS. Questi prerequisiti sono fondamentali affinché l' GuardDuty agente funzioni come previsto. Una volta soddisfatti questi prerequisiti, consultate [Abilitazione del monitoraggio del GuardDuty runtime](runtime-monitoring-configuration.md) per iniziare a monitorare le vostre risorse.

## Support per le funzionalità di Amazon EKS
<a name="runtime-monitoring-eks-feature-support"></a>

Runtime Monitoring **supporta** i cluster Amazon EKS in esecuzione su istanze Amazon EC2 e Amazon EKS Auto Mode.

Runtime Monitoring **non supporta** i cluster Amazon EKS con Amazon EKS Hybrid Nodes e quelli in AWS Fargate esecuzione.

Per informazioni su queste funzionalità di Amazon EKS, consulta [Cos'è Amazon EKS?](https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html) nella **Guida per l'utente di Amazon EKS**.

## Convalida dei requisiti relativi all'architettura
<a name="eksrunmon-supported-platform-concepts"></a>

La piattaforma utilizzata può influire sul modo GuardDuty in cui GuardDuty Security Agent supporta la ricezione degli eventi di runtime dai cluster EKS. Devi confermare di utilizzare una delle piattaforme verificate. Se gestisci l' GuardDuty agente manualmente, assicurati che la versione di Kubernetes supporti la versione dell' GuardDuty agente attualmente in uso. 

### Piattaforme verificate
<a name="eksrunmon-verified-platform"></a>

La distribuzione del sistema operativo, la versione del kernel e l'architettura della CPU influiscono sul supporto fornito dal security agent. GuardDuty Il supporto del kernel include `eBPF` e`Tracepoints`. `Kprobe` Per le architetture CPU, Runtime Monitoring supporta AMD64 (`x64`) e ARM64 (Graviton2 e versioni successive). [1](#runtime-monitoring-eks-graviton-2-support)

La tabella seguente mostra la configurazione verificata per l'implementazione del GuardDuty security agent e la configurazione di EKS Runtime Monitoring.


| distribuzione del sistema operativo **[2](#runtime-monitoring-eks-os-support)** | Versione del kernel **[3](#runtime-monitoring-eks-kernel-version-required-flag)** | Versione di Kubernetes supportata | 
| --- | --- | --- | 
|  Portabottiglie  | 5.4, 5.10, 5.15, 6.1 [4](#v6.1-kernel-dns-findings-unsupported-eks) | v1.23 - v1.35 | 
|  Ubuntu  | 5.4, 5.10, 5.15, 6.1 [4](#v6.1-kernel-dns-findings-unsupported-eks) | v1.21 - v1.35 | 
|  Amazon Linux 2  | 5.4, 5.10, 5.15, 6.1 [4](#v6.1-kernel-dns-findings-unsupported-eks) | v1.21 - v1.35 | 
|  Amazon Linux 2023 *[5](#runtime-eks-al2023-support-v1.6.0)*  | 5.4, 5.10, 5.15, 6.1 [4](#v6.1-kernel-dns-findings-unsupported-eks) | v1.21 - v1.35 | 
|  RedHat 9.4  | 5,14 [4](#v6.1-kernel-dns-findings-unsupported-eks) | v1.21 - v1.35 | 
|  Fedora 34  | 5.11, 5,17 | v1.21 - v1.35 | 
|  Fedora 40  | 6.8 | v1.28 - v1.35 | 
|  Fedora 41  | 6.12 | v1.28 - v1.35 | 
|  CentOS Stream 9  | 5.14 | v1.21 - v1.35 | 

1. <a name="runtime-monitoring-eks-graviton-2-support"></a>Il monitoraggio del runtime per i cluster Amazon EKS non supporta le istanze Graviton di prima generazione come i tipi di istanze A1.

1. <a name="runtime-monitoring-eks-os-support"></a>Supporto per vari sistemi operativi: GuardDuty ha verificato il supporto del Runtime Monitoring per la distribuzione operativa elencata nella tabella precedente. Sebbene il GuardDuty security agent possa funzionare su sistemi operativi non elencati nella tabella precedente, il GuardDuty team non può garantire il valore di sicurezza previsto.

1. <a name="runtime-monitoring-eks-kernel-version-required-flag"></a>Per qualsiasi versione del kernel, è necessario impostare il `CONFIG_DEBUG_INFO_BTF` flag su `y` (che significa *true*). Ciò è necessario per consentire al GuardDuty Security Agent di funzionare come previsto.

1. <a name="v6.1-kernel-dns-findings-unsupported-eks"></a>Attualmente, con la versione Kernel`6.1`, non è GuardDuty possibile generare dati [GuardDuty Tipi di risultati del monitoraggio del runtime](findings-runtime-monitoring.md) correlati a. [Eventi del Domain Name System (DNS)](runtime-monitoring-collected-events.md#eks-runtime-dns-events)

1. <a name="runtime-eks-al2023-support-v1.6.0"></a>Il monitoraggio del runtime è supportato AL2023 con il rilascio del GuardDuty security agent v1.6.0 e versioni successive. Per ulteriori informazioni, consulta [GuardDuty versioni degli agenti di sicurezza per le risorse Amazon EKS](runtime-monitoring-agent-release-history.md#eks-runtime-monitoring-agent-release-history).

#### Versioni di Kubernetes supportate dal security agent GuardDuty
<a name="gdu-agent-supported-k8-version"></a>

La tabella seguente mostra le versioni di Kubernetes per i cluster EKS supportate dal Security Agent. GuardDuty 


| Versione dell'agente di GuardDuty sicurezza aggiuntivo Amazon EKS | Versione di Kubernetes | 
| --- | --- | 
|  v1.12.1 (più recente - v1.12.1-eksbuild.2)  |  1,28 - 1,35  | 
|  v1.11.0 (più recente - v1.11.0-eksbuild.4)  |  1,28 - 1,34  | 
|  v1.10.0 (più recente - v1.10.0-eksbuild.2)  |  1.21 - 1.33  | 
|  v1.9.0 (più recente - v1.9.0-eksbuild.2) v1.8.1 (più recente - v1.8.1-eksbuild.2)  |  1,21 - 1,32  | 
|  versione 1.7.1 v1.7.0 v1.6.1  |  1,21 - 1,31  | 
|  v1.6.0 v1.5.0 v1.4.1 v1.4.0 v1.3.1  |  1,21 - 1,29  | 
|  v1.3.0 v1.2.0  |  1,21 - 1,28  | 
|  v1.1.0  |  1,21 - 1,26  | 
|  v1.0.0  |  1,21 - 1,25  | 

Alcune versioni del GuardDuty Security Agent raggiungeranno la fine del supporto standard. 

Per informazioni sulle versioni di rilascio dell'agente, vedere. [GuardDuty versioni degli agenti di sicurezza per le risorse Amazon EKS](runtime-monitoring-agent-release-history.md#eks-runtime-monitoring-agent-release-history)

### Limiti di CPU e di memoria
<a name="eks-runtime-agent-limits"></a>

La tabella seguente mostra i limiti di CPU e memoria per il componente aggiuntivo Amazon EKS per GuardDuty (`aws-guardduty-agent`).


| Parametro | Limite minimo | Limite massimo | 
| --- | --- | --- | 
| CPU | 200 m | 1000 m | 
| Memoria | 256 Mi | 1024 Mi | 

Quando utilizzi il componente aggiuntivo Amazon EKS versione 1.5.0 o successiva, GuardDuty offre la possibilità di configurare lo schema del componente aggiuntivo per i valori di CPU e memoria. Per informazioni sull'intervallo configurabile, consulta. [Parametri e valori configurabili](guardduty-configure-security-agent-eks-addon.md#gdu-eks-addon-configure-parameters-values)

Dopo aver abilitato il monitoraggio del runtime EKS e valutato lo stato di copertura dei cluster EKS, puoi configurare e visualizzare i parametri di Container Insights. Per ulteriori informazioni, consulta [Configurazione del monitoraggio della CPU e della memoria](runtime-monitoring-setting-cpu-mem-monitoring.md).

## Convalida della politica di controllo dei servizi dell'organizzazione
<a name="validate-organization-scp-eks"></a>

Se hai impostato una policy di controllo dei servizi (SCP) per gestire le autorizzazioni nella tua organizzazione, verifica che il limite delle autorizzazioni non sia restrittivo. `guardduty:SendSecurityTelemetry` È necessario per supportare il monitoraggio del runtime GuardDuty su diversi tipi di risorse.

Se sei un account membro, connettiti con l'amministratore delegato associato. Per informazioni sulla gestione SCPs dell'organizzazione, consulta [le politiche di controllo del servizio (SCPs).](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)