Correzione dei risultati di Security Health Analytics

Questa pagina fornisce un elenco di guide di riferimento e tecniche per correggere i risultati di Security Health Analytics utilizzando Security Command Center.

Per visualizzare o modificare i risultati e per accedere alle risorse o modificarle, devi disporre di ruoli Identity and Access Management (IAM) adeguati. Google Cloud Se riscontri errori di autorizzazione quando accedi a Security Command Center nella consoleGoogle Cloud , chiedi assistenza all'amministratore e, per informazioni sui ruoli, consulta Controllo dell'accesso. Per risolvere gli errori delle risorse, leggi la documentazione relativa ai prodotti interessati.

Correzione di Security Health Analytics

Questa sezione include le istruzioni di correzione per tutti i risultati di Security Health Analytics.

Per trovare i tipi mappati ai benchmark CIS, le indicazioni per la correzione provengono dal Center for Internet Security (CIS), se non diversamente specificato. Per ulteriori informazioni, vedi Rilevatori e conformità.

Disattivazione automatica dei risultati

Dopo aver risolto un problema di vulnerabilità o di configurazione errata, Security Health Analytics imposta automaticamente lo stato del problema su INACTIVE la volta successiva che esegue la scansione per il problema. Se disattivi un rilevatore in Security Health Analytics, lo stato di tutti i risultati generati da quel rilevatore viene impostato su INACTIVE. Il tempo necessario a Security Health Analytics per impostare un risultato corretto su INACTIVE dipende da quando viene corretto il risultato e dalla pianificazione della scansione che lo rileva.

Security Health Analytics imposta anche lo stato di un risultato su INACTIVE quando una scansione rileva che la risorsa interessata dal risultato è stata eliminata. Se vuoi rimuovere una scoperta per una risorsa eliminata dalla visualizzazione mentre aspetti che Security Health Analytics rilevi che la risorsa è stata eliminata, puoi disattivare la scoperta. Per disattivare un risultato, consulta Disattivazione dei risultati in Security Command Center.

Non utilizzare la disattivazione per nascondere i risultati corretti per le risorse esistenti. Se il problema si ripresenta e Security Health Analytics ripristina lo stato ACTIVE del risultato, potresti non visualizzare il risultato riattivato, perché i risultati disattivati vengono esclusi da qualsiasi query sui risultati che specifica NOT mute="MUTED", ad esempio la query sui risultati predefinita.

Per informazioni sugli intervalli di analisi, vedi Tipi di analisi di Security Health Analytics.

Access Transparency disabled

Nome della categoria nell'API: ACCESS_TRANSPARENCY_DISABLED

I log di Access Transparency quando i Google Cloud dipendenti accedono ai progetti della tua organizzazione per fornire assistenza. Attiva Access Transparency per registrare chi di Google Cloud accede alle tue informazioni, quando e perché. Per ulteriori informazioni, consulta Access Transparency.

Per attivare Access Transparency in un progetto, quest'ultimo deve essere associato a un account di fatturazione.

Ruoli obbligatori

Per ottenere le autorizzazioni necessarie per eseguire questa attività, chiedi all'amministratore di concederti il ruolo IAM Amministratore Access Transparency (roles/axt.admin) a livello di organizzazione. Per saperne di più sulla concessione dei ruoli, consulta Gestire l'accesso.

Questo ruolo predefinito contiene le autorizzazioni axt.labels.get e axt.labels.set, necessarie per eseguire questa attività. Potresti anche ottenere queste autorizzazioni con un ruolo personalizzato o altri ruoli predefiniti.

Passaggi per correggere l'errore

Per risolvere questo problema, completa i seguenti passaggi:

  1. Controlla le autorizzazioni a livello di organizzazione:

    1. Vai alla pagina Identity and Access Management nella consoleGoogle Cloud .

      Vai a Identity and Access Management

    2. Se richiesto, seleziona l'organizzazione Google Cloud nel menu del selettore.

  2. Seleziona un progetto Google Cloud qualsiasi all'interno dell'organizzazione utilizzando il menu del selettore.

    Access Transparency viene configurato nella pagina di un progetto Google Cloud , ma è abilitato per l'intera organizzazione.

  3. Vai alla pagina IAM e amministrazione > Impostazioni.

  4. Fai clic su Abilita Access Transparency.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

AlloyDB auto backup disabled

Nome della categoria nell'API: ALLOYDB_AUTO_BACKUP_DISABLED

Un cluster AlloyDB per PostgreSQL non ha i backup automatici abilitati.

Per evitare perdite di dati, attiva i backup automatici per il cluster. Per saperne di più, consulta Configurare backup automatici aggiuntivi.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina dei cluster AlloyDB per PostgreSQL nella Google Cloud console.

    Vai ai cluster AlloyDB per PostgreSQL

  2. Fai clic su un cluster nella colonna Nome risorsa.

  3. Fai clic su Protezione dei dati.

  4. Nella sezione Policy di backup automatico, fai clic su Modifica nella riga Backup automatici.

  5. Seleziona la casella di controllo Backup automatici.

  6. Fai clic su Aggiorna.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

AlloyDB backups disabled

Nome della categoria nell'API: ALLOYDB_BACKUPS_DISABLED

Un cluster AlloyDB per PostgreSQL non ha abilitato backup automatici o continui.

Per evitare perdite di dati, attiva i backup automatici o continui per il cluster. Per maggiori informazioni, vedi Configurare backup aggiuntivi.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina dei cluster AlloyDB per PostgreSQL nella Google Cloud console.

    Vai ai cluster AlloyDB per PostgreSQL

  2. Nella colonna Nome risorsa, fai clic sul nome del cluster identificato nel risultato.

  3. Fai clic su Protezione dei dati.

  4. Configura una policy di backup.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

AlloyDB CMEK disabled

Nome della categoria nell'API: ALLOYDB_CMEK_DISABLED

Un cluster AlloyDB non utilizza le chiavi di crittografia gestite dal cliente (CMEK).

Con CMEK, le chiavi che crei e gestisci in Cloud KMS criptano le chiavi che Google utilizza per criptare i tuoi dati, offrendoti un maggiore controllo sull'accesso ai tuoi dati. Per maggiori informazioni, consulta la pagina Informazioni su CMEK. Le chiavi di crittografia gestite dal cliente comportano costi aggiuntivi correlati a Cloud KMS.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina dei cluster AlloyDB per PostgreSQL nella Google Cloud console.

    Vai ai cluster AlloyDB per PostgreSQL

  2. Nella colonna Nome risorsa, fai clic sul nome del cluster identificato nel risultato.

  3. Fai clic su Crea backup. Imposta un ID di backup.

  4. Fai clic su Crea.

  5. Nella sezione Backup/Ripristino, fai clic su Ripristina accanto alla voce ID backup che hai scelto.

  6. Imposta un nuovo ID cluster e una nuova rete.

  7. Fai clic su Opzioni di crittografia avanzate. Seleziona la CMEK con cui vuoi criptare il nuovo cluster.

  8. Fai clic su Ripristina.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

AlloyDB log min error statement severity

Nome della categoria nell'API: ALLOYDB_LOG_MIN_ERROR_STATEMENT_SEVERITY

Un'istanza AlloyDB per PostgreSQL non ha il flag di database log_min_error_statement impostato su error o su un altro valore consigliato.

Il flag log_min_error_statement controlla se le istruzioni SQL che causano condizioni di errore vengono registrate nei log del server. Vengono registrate le istruzioni SQL con il livello di gravità specificato o superiore. Più elevata è la gravità, minore è il numero di messaggi registrati. Se è impostato su un livello di gravità troppo elevato, i messaggi di errore potrebbero non essere registrati.

Per maggiori informazioni, consulta la pagina Configurazione dei flag di database.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina dei cluster AlloyDB per PostgreSQL nella Google Cloud console.

    Vai ai cluster AlloyDB per PostgreSQL

  2. Fai clic sul cluster nella colonna Nome risorsa.

  3. Nella sezione Istanze nel cluster, fai clic su Modifica per l'istanza.

  4. Fai clic su Opzioni di configurazione avanzate.

  5. Nella sezione Flag, imposta il flag di database log_min_error_statement su uno dei seguenti valori consigliati, in base al criterio di logging della tua organizzazione.

    • debug5
    • debug4
    • debug3
    • debug2
    • debug1
    • info
    • notice
    • warning
    • error

  6. Fai clic su Aggiorna istanza.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

AlloyDB log min messages

Nome della categoria nell'API: ALLOYDB_LOG_MIN_MESSAGES

Un'istanza AlloyDB per PostgreSQL non ha il flag di database log_min_messages impostato almeno su warning.

Il flag log_min_messages controlla quali livelli di messaggi vengono registrati nei log del server. Più elevata è la gravità, minore è il numero di messaggi registrati. L'impostazione di una soglia troppo bassa può comportare un aumento della dimensione e della durata dell'archiviazione dei log, il che complica l'individuazione di errori effettivi.

Per maggiori informazioni, consulta la pagina Configurazione dei flag di database.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina dei cluster AlloyDB per PostgreSQL nella Google Cloud console.

    Vai ai cluster AlloyDB per PostgreSQL

  2. Fai clic sul cluster nella colonna Nome risorsa.

  3. Nella sezione Istanze nel cluster, fai clic su Modifica per l'istanza.

  4. Fai clic su Opzioni di configurazione avanzate.

  5. Nella sezione Flag, imposta il flag di database log_min_messages su uno dei seguenti valori consigliati, in base al criterio di logging della tua organizzazione.

    • debug5
    • debug4
    • debug3
    • debug2
    • debug1
    • info
    • notice
    • warning

  6. Fai clic su Aggiorna istanza.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

AlloyDB log error verbosity

Nome della categoria nell'API: ALLOYDB_LOG_ERROR_VERBOSITY

Un'istanza AlloyDB per PostgreSQL non ha il flag di database log_error_verbosity impostato su default o su un altro valore meno restrittivo.

Il flag log_error_verbosity controlla la quantità di dettagli nei messaggi registrati. Maggiore è il livello di dettaglio, maggiori saranno i dettagli registrati nei messaggi. Ti consigliamo di impostare questo flag su default o su un altro valore meno restrittivo.

Per maggiori informazioni, consulta la pagina Configurazione dei flag di database.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina dei cluster AlloyDB per PostgreSQL nella Google Cloud console.

    Vai ai cluster AlloyDB per PostgreSQL

  2. Fai clic sul cluster nella colonna Nome risorsa.

  3. Nella sezione Istanze nel cluster, fai clic su Modifica per l'istanza.

  4. Fai clic su Opzioni di configurazione avanzate.

  5. Nella sezione Flag, imposta il flag di database log_error_verbosity su uno dei seguenti valori consigliati, in base al criterio di logging della tua organizzazione.

    • default
    • verbose

  6. Fai clic su Aggiorna istanza.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

AlloyDB Public IP

Nome della categoria nell'API: ALLOYDB_PUBLIC_IP

Un'istanza di database AlloyDB per PostgreSQL ha un indirizzo IP pubblico.

Per ridurre la superficie di attacco della tua organizzazione, utilizza indirizzi IP privati anziché pubblici. Gli indirizzi IP privati offrono maggiore sicurezza di rete e minore latenza per l'applicazione.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina dei cluster AlloyDB per PostgreSQL nella Google Cloud console.

    Vai ai cluster AlloyDB per PostgreSQL

  2. Nella colonna Nome risorsa, fai clic sul nome del cluster identificato nel risultato.

  3. Nella sezione Istanze nel cluster, fai clic su Modifica per l'istanza.

  4. Nella sezione Connettività, deseleziona la casella Abilita IP pubblico.

  5. Fai clic su Aggiorna istanza.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

AlloyDB SSL not enforced

Nome della categoria nell'API: ALLOYDB_SSL_NOT_ENFORCED

Un'istanza del database AlloyDB per PostgreSQL non richiede che tutte le connessioni in entrata utilizzino SSL.

Per evitare fughe di dati sensibili in transito tramite comunicazioni non criptate, tutte le connessioni in entrata nell'istanza del database AlloyDB devono utilizzare SSL. Scopri di più sulla configurazione di SSL/TLS.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina dei cluster AlloyDB per PostgreSQL nella Google Cloud console.

    Vai ai cluster AlloyDB per PostgreSQL

  2. Nella colonna Nome risorsa, fai clic sul nome del cluster identificato nel risultato.

  3. Nella sezione Istanze nel cluster, fai clic su Modifica per l'istanza.

  4. Nella sezione Sicurezza di rete, fai clic sulla casella Richiedi crittografia SSL.

  5. Fai clic su Aggiorna istanza.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Admin service account

Nome della categoria nell'API: ADMIN_SERVICE_ACCOUNT

Un account di servizio nella tua organizzazione o nel tuo progetto ha privilegi di Amministratore, Proprietario o Editor assegnati. Questi ruoli dispongono di autorizzazioni ampie e non devono essere assegnati agli account di servizio. Per scoprire di più sui service account e sui ruoli disponibili, consulta Service account.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Policy IAM nella console Google Cloud .

    Vai alla policy IAM

  2. Per ogni entità identificata nel risultato:

    1. Fai clic su Modifica entità accanto all'entità.
    2. Per rimuovere le autorizzazioni, fai clic su Elimina ruolo accanto al ruolo.
    3. Fai clic su Salva.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Alpha cluster enabled

Nome della categoria nell'API: ALPHA_CLUSTER_ENABLED

Le funzionalità del cluster alpha sono abilitate per un cluster Google Kubernetes Engine (GKE).

I cluster alpha consentono agli early adopter di sperimentare con carichi di lavoro che utilizzano nuove funzionalità prima che vengano rilasciate al pubblico. I cluster alpha dispongono di tutte le funzionalità dell'API GKE abilitate, ma non sono coperti dallo SLA di GKE, non ricevono aggiornamenti di sicurezza, hanno l'upgrade automatico dei nodi e la riparazione automatica dei nodi disabilitati e non possono essere sottoposti ad upgrade. Inoltre, vengono eliminati automaticamente dopo 30 giorni.

Per risolvere questo problema, completa i seguenti passaggi:

I cluster alpha non possono essere disabilitati. Devi creare un nuovo cluster con le funzionalità alpha disattivate.

  1. Vai alla pagina Cluster Kubernetes nella console Google Cloud .

    Vai ai cluster Kubernetes

  2. Fai clic su Crea.

  3. Seleziona Configura accanto al tipo di cluster che vuoi creare.

  4. Nella scheda Funzionalità, assicurati che l'opzione Abilita le funzionalità alpha di Kubernetes in questo cluster sia disattivata.

  5. Fai clic su Crea.

  6. Per spostare i carichi di lavoro nel nuovo cluster, consulta Migrazione dei carichi di lavoro in tipi di macchine diversi.

  7. Per eliminare il cluster originale, consulta Eliminare un cluster.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

API key APIs unrestricted

Nome della categoria nell'API: API_KEY_APIS_UNRESTRICTED

Le chiavi API vengono utilizzate in modo troppo ampio.

Le chiavi API senza restrizioni non sono sicure perché possono essere recuperate dai dispositivi su cui sono archiviate o possono essere visualizzate pubblicamente, ad esempio da un browser. In conformità al principio del privilegio minimo, configura le chiavi API in modo che chiamino solo le API richieste dall'applicazione. Per maggiori informazioni, vedi Applicare le limitazioni relative alle chiavi API.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Chiavi API nella console Google Cloud .

    Vai a Chiavi API

  2. Per ogni chiave API:

    1. Nella sezione Chiavi API, nella riga di ciascuna chiave API per cui devi limitare le API, fai clic su Azioni.
    2. Dal menu Azioni, fai clic su Modifica chiave API. Viene visualizzata la pagina Modifica chiave API.
    3. Nella sezione Restrizioni delle API, seleziona Limita API. Viene visualizzato il menu a discesa Seleziona API.
    4. Nell'elenco a discesa Seleziona API, seleziona le API da autorizzare.
    5. Fai clic su Salva. Potrebbero essere necessari fino a cinque minuti prima che le impostazioni diventino effettive.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

API key apps unrestricted

Nome della categoria nell'API: API_KEY_APPS_UNRESTRICTED

Esistono chiavi API utilizzate senza restrizioni, che consentono l'utilizzo da parte di qualsiasi app non attendibile.

Le chiavi API senza restrizioni non sono sicure perché è possibile recuperarle su dispositivi in cui la chiave viene archiviata o può essere visualizzata pubblicamente, ad esempio da un browser. In conformità al principio del privilegio minimo, limita l'utilizzo delle chiavi API a host, referrer HTTP e app attendibili. Per maggiori informazioni, vedi Applicare le limitazioni relative alle chiavi API.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Chiavi API nella console Google Cloud .

    Vai a Chiavi API

  2. Per ogni chiave API:

    1. Nella sezione Chiavi API, nella riga di ciascuna chiave API per cui devi limitare le applicazioni, fai clic su Azioni.
    2. Dal menu Azioni, fai clic su Modifica chiave API. Viene visualizzata la pagina Modifica chiave API.
    3. Nella pagina Modifica chiave API, seleziona una categoria di limitazione nella sezione Restrizioni delle applicazioni. Puoi impostare una limitazione delle applicazioni per ogni chiave.
    4. Nel campo Aggiungi un elemento visualizzato quando selezioni una restrizione, fai clic su Aggiungi un elemento per aggiungere restrizioni in base alle esigenze della tua applicazione.
    5. Una volta terminata l'aggiunta degli elementi, fai clic su Fine.
    6. Fai clic su Salva.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

API key exists

Nome della categoria nell'API: API_KEY_EXISTS

Un progetto utilizza chiavi API anziché l'autenticazione standard.

Le chiavi API sono meno sicure di altri metodi di autenticazione perché sono semplici stringhe criptate e facili da scoprire e utilizzare da parte di altri. È possibile recuperarle su dispositivi in cui la chiave viene archiviata o può essere visualizzata pubblicamente, ad esempio da un browser. Inoltre, le chiavi API non identificano in modo univoco gli utenti o le applicazioni che effettuano richieste. In alternativa, puoi utilizzare un flusso di autenticazione standard, con service account o account utente.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Assicurati che le tue applicazioni siano configurate con una forma di autenticazione alternativa.

  2. Vai alla pagina Credenziali API nella console Google Cloud .

    Vai a Credenziali API

  3. Nella sezione Chiavi API della riga di ciascuna chiave API che devi eliminare, fai clic su Azioni.

  4. Dal menu Azioni, fai clic su Elimina chiave API.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

API key not rotated

Nome della categoria nell'API: API_KEY_NOT_ROTATED

Una chiave API non è stata ruotata per più di 90 giorni.

Le chiavi API non scadono, per cui una chiave trafugata può essere utilizzata per un tempo illimitato a meno che il proprietario del progetto non esegua la revoca o la rotazione. La rotazione frequente delle chiavi API riduce l'intervallo di tempo durante il quale è possibile utilizzare una chiave API trafugata per accedere ai dati su un account compromesso o terminato. Ruota le chiavi API almeno ogni 90 giorni. Per saperne di più, consulta le best practice per la gestione delle chiavi API.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Chiavi API nella console Google Cloud .

    Vai a Chiavi API

  2. Per ogni chiave API:

    1. Nella sezione Chiavi API, nella riga di ciascuna chiave API che devi ruotare, fai clic su Azioni.
    2. Dal menu Azioni, fai clic su Modifica chiave API. Viene visualizzata la pagina Modifica chiave API.
    3. Nella pagina Modifica chiave API, se la data nel campo Data di creazione è precedente a 90 giorni, fai clic su Ruota chiave. Viene generata una nuova chiave.
    4. (Facoltativo) Modifica il nome della chiave API.
    5. Fai clic su Crea.
    6. Aggiorna le tue applicazioni in modo che utilizzino la nuova chiave.
    7. Dopo aver aggiornato le applicazioni, torna alla pagina Modifica chiave API e fai clic su Elimina la chiave precedente per eliminare la vecchia chiave. La vecchia chiave non verrà eliminata automaticamente.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Audit config not monitored

Nome della categoria nell'API: AUDIT_CONFIG_NOT_MONITORED

Le metriche di log e gli avvisi non sono configurati per monitorare le modifiche alla configurazione di controllo.

Cloud Logging produce log di accesso ai dati e alle attività di amministrazione che consentono analisi di sicurezza, monitoraggio delle modifiche delle risorse e controllo di conformità. Il monitoraggio delle modifiche alla configurazione dell'audit assicura che tutte le attività nel progetto possano essere controllate in qualsiasi momento. Per ulteriori informazioni, consulta Panoramica delle metriche basate su log.

A seconda della quantità di informazioni, i costi di Cloud Monitoring possono essere significativi. Per comprendere l'utilizzo del servizio e i relativi costi, consulta Prezzi di Google Cloud Observability.

Per le attivazioni a livello di progetto del livello Security Command Center Premium, questo risultato è disponibile solo se il livello Standard è abilitato nell'organizzazione principale.

Per correggere questo risultato, crea metriche, se necessario, e criteri di avviso:

Crea metrica

  1. Vai alla pagina Metriche basate su log nella console Google Cloud .

    Vai a Metriche basate su log

  2. Fai clic su Crea metrica.

  3. In Tipo di metrica, seleziona Contatore.

  4. In Dettagli:

    1. Imposta un Nome metrica di log.
    2. Aggiungi una descrizione.
    3. Imposta Unità su 1.

  5. In Selezione dei filtri, copia e incolla il testo seguente nella casella Crea filtro, sostituendo il testo esistente, se necessario: 

      protoPayload.methodName="SetIamPolicy"
  AND protoPayload.serviceData.policyDelta.auditConfigDeltas:*

  6. Fai clic su Crea metrica. Viene visualizzata una conferma.

Crea policy di avviso

  1. Nella console Google Cloud , vai alla pagina Metriche basate su log:

    Vai a Metriche basate su log

    Se utilizzi la barra di ricerca per trovare questa pagina, seleziona il risultato con il sottotitolo Logging.

  2. Nella sezione Metriche definite dall'utente, seleziona la metrica che hai creato nella sezione precedente.

  3. Fai clic su Altro , quindi su Crea avviso da metrica.

    Si apre la finestra di dialogo Nuova condizione con le opzioni di metrica e trasformazione dei dati precompilate.

  4. Fai clic su Avanti.
    1. Rivedi le impostazioni precompilate. Potresti voler modificare il valore di soglia.
    2. Fai clic su Nome condizione e inserisci un nome per la condizione.
  5. Fai clic su Avanti.

  6. Per aggiungere notifiche al tuo criterio di avviso, fai clic su Canali di notifica. Nella finestra di dialogo, seleziona uno o più canali di notifica dal menu e fai clic su Ok.

    Per ricevere una notifica quando gli incidenti vengono aperti e chiusi, seleziona Notifica alla chiusura dell'incidente. Per impostazione predefinita, le notifiche vengono inviate solo quando vengono aperti incidenti.

  7. (Facoltativo) Aggiorna la Durata chiusura automatica incidenti. Questo campo determina quando Monitoring chiude gli incidenti in assenza di dati delle metriche.
  8. (Facoltativo) Fai clic su Documentazione e aggiungi tutte le informazioni che vuoi includere in un messaggio di notifica.
  9. Fai clic su Nome avviso e inserisci un nome per il criterio di avviso.
  10. Fai clic su Crea criterio.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Audit logging disabled

Nome della categoria nell'API: AUDIT_LOGGING_DISABLED

Questo risultato non è disponibile per le attivazioni a livello di progetto.

L'audit logging è disattivato per uno o più servizi Google Cloud oppure una o più entità sono esenti dall'audit logging dell'accesso ai dati.

Abilita Cloud Logging per tutti i servizi per tenere traccia di tutte le attività di amministrazione e dell'accesso in lettura/scrittura ai dati utente. A seconda della quantità di informazioni, i costi di Cloud Logging possono essere significativi. Per comprendere il tuo utilizzo del servizio e il relativo costo, consulta Prezzi di Google Cloud Observability.

Se alcune entità sono esenti dalla registrazione degli audit log di accesso ai dati nella configurazione predefinita degli audit log di accesso ai dati o nelle configurazioni di registrazione per i singoli servizi, rimuovi l'esenzione.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Configurazione predefinita degli audit log di accesso ai dati nella consoleGoogle Cloud .

    Vai alla configurazione predefinita

  2. Nella scheda Tipi di log, attiva la registrazione degli audit log di accesso ai dati nella configurazione predefinita:

    1. Seleziona Lettura amministratore, Lettura dati e Scrittura dati.
    2. Fai clic su Salva.

  3. Nella scheda Entità esenti, rimuovi tutti gli utenti esenti dalla configurazione predefinita:

    1. Rimuovi ogni entità elencata facendo clic su Elimina accanto a ogni nome.
    2. Fai clic su Salva.

  4. Vai alla pagina Audit log.

    Vai agli audit log

  5. Rimuovi le entità esenti dalle configurazioni degli audit log di accesso ai dati dei singoli servizi.

    1. In Configurazione degli audit log di accesso ai dati, fai clic sul servizio per ciascun servizio che mostra un'entità esente. Si apre un riquadro di configurazione dell'audit log per il servizio.
    2. Nella scheda Entità esenti, rimuovi tutte le entità esenti facendo clic su Elimina accanto a ogni nome.
    3. Fai clic su Salva.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Auto backup disabled

Nome della categoria nell'API: AUTO_BACKUP_DISABLED

Un database Cloud SQL non ha i backup automatici abilitati.

Per evitare perdite di dati, attiva i backup automatici per le tue istanze SQL. Per ulteriori informazioni, consulta Creazione e gestione dei backup on demand e automatici.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Nella console Google Cloud , vai alla pagina Istanze Cloud SQL.

    Vai a Istanze

  2. Fai clic sul nome dell'istanza.

  3. Fai clic su Backup.

  4. Accanto a Impostazioni, fai clic su Modifica.

  5. Seleziona la casella di controllo Backup giornalieri automatici.

  6. (Facoltativo) Nella casella Numero di giorni, inserisci il numero di giorni di backup che vuoi conservare.

  7. (Facoltativo) Nell'elenco Finestra di backup, seleziona la finestra temporale in cui eseguire i backup.

  8. Fai clic su Salva.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Auto repair disabled

Nome della categoria nell'API: AUTO_REPAIR_DISABLED

La funzionalità di riparazione automatica di un cluster Google Kubernetes Engine (GKE), che mantiene i nodi in uno stato integro e in esecuzione, è disattivata.

Se abiliti questa funzionalità, GKE esegue controlli periodici dello stato di integrità di ciascun nodo nel tuo cluster. Se un nodo non supera controlli di integrità consecutivi per un periodo di tempo prolungato, GKE avvia un processo di riparazione per quel nodo. Per saperne di più, consulta Nodi con riparazione automatica.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Cluster Kubernetes nella console Google Cloud .

    Vai ai cluster Kubernetes

  2. Fai clic sulla scheda Nodi.

  3. Per ogni node pool:

    1. Fai clic sul nome del pool di nodi per passare alla pagina dei dettagli.
    2. Fai clic su Modifica.
    3. In Gestione, seleziona Abilita riparazione automatica.
    4. Fai clic su Salva.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Auto upgrade disabled

Nome della categoria nell'API: AUTO_UPGRADE_DISABLED

La funzionalità di upgrade automatico di un cluster GKE, che mantiene i cluster e i pool di nodi sull'ultima versione stabile di Kubernetes, è disabilitata.

Per ulteriori informazioni, consulta Upgrade automatico dei nodi.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Cluster Kubernetes nella console Google Cloud .

    Vai ai cluster Kubernetes

  2. Nell'elenco dei cluster, fai clic sul nome del cluster.

  3. Fai clic sulla scheda Nodi.

  4. Per ogni node pool:

    1. Fai clic sul nome del pool di nodi per passare alla pagina dei dettagli.
    2. Fai clic su Modifica.
    3. In Gestione, seleziona Abilita upgrade automatico.
    4. Fai clic su Salva.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

BigQuery table CMEK disabled

Nome della categoria nell'API: BIGQUERY_TABLE_CMEK_DISABLED

Una tabella BigQuery non è configurata per utilizzare una chiave di crittografia gestita dal cliente (CMEK).

Con CMEK, le chiavi che crei e gestisci in Cloud KMS criptano le chiavi utilizzate Google Cloud per criptare i tuoi dati, offrendoti un maggiore controllo sull'accesso ai tuoi dati. Per ulteriori informazioni, consulta Protezione dei dati con le chiavi Cloud KMS.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Crea una tabella protetta da Cloud Key Management Service.
  2. Copia la tabella nella nuova tabella abilitata per CMEK.
  3. Elimina la tabella originale.

Per impostare una chiave CMEK predefinita che cripta tutte le nuove tabelle in un set di dati, vedi Impostare una chiave predefinita per un set di dati.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Binary authorization disabled

Nome della categoria nell'API: BINARY_AUTHORIZATION_DISABLED

Autorizzazione binaria è disattivata su un cluster GKE.

Autorizzazione binaria include una funzionalità facoltativa che protegge la sicurezza della catena di fornitura consentendo il deployment nel cluster solo di immagini container firmate da autorità attendibili durante il processo di sviluppo. Se applichi il deployment basato sulla firma, puoi controllare più strettamente l'ambiente dei container assicurando che solo le immagini verificate possano essere sottoposte a deployment.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Cluster Kubernetes nella console Google Cloud .

    Vai ai cluster Kubernetes

  2. Nella sezione Sicurezza, fai clic su Modifica nella riga Autorizzazione binaria.

    Se la configurazione del cluster è stata cambiata di recente, il pulsante di modifica potrebbe essere disabilitato. Se non riesci a modificare le impostazioni del cluster, attendi alcuni minuti e riprova.

  3. Nella finestra di dialogo, seleziona Attiva Autorizzazione binaria.

  4. Fai clic su Salva modifiche.

  5. Vai alla pagina di configurazione dell'autorizzazione binaria.

    Vai all'autorizzazione binaria

  6. Assicurati che sia configurata una policy che richiede attestatori e che la regola predefinita del progetto non sia configurata su Consenti tutte le immagini. Per maggiori informazioni, vedi Configurazione per GKE.

    Per garantire che le immagini che violano la policy possano essere sottoposte a deployment e le violazioni vengano registrate inCloud Audit Logsd, puoi attivare la modalità di prova.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Bucket CMEK disabled

Nome della categoria nell'API: BUCKET_CMEK_DISABLED

Un bucket non è criptato con chiavi di crittografia gestite dal cliente (CMEK).

L'impostazione di una chiave CMEK predefinita in un bucket offre un maggiore controllo sull'accesso ai tuoi dati. Per saperne di più, vedi Chiavi di crittografia gestite dal cliente.

Per risolvere questo problema, utilizza CMEK con un bucket seguendo la guida Utilizzo delle chiavi di crittografia gestite dal cliente. Le chiavi CMEK comportano costi aggiuntivi correlati a Cloud KMS.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Bucket IAM not monitored

Nome della categoria nell'API: BUCKET_IAM_NOT_MONITORED

Le metriche di log e gli avvisi non sono configurati per monitorare le modifiche alle autorizzazioni IAM di Cloud Storage.

Il monitoraggio delle modifiche alle autorizzazioni dei bucket Cloud Storage ti aiuta a identificare gli utenti con privilegi in eccesso o le attività sospette. Per ulteriori informazioni, consulta Panoramica delle metriche basate su log.

A seconda della quantità di informazioni, i costi di Cloud Monitoring possono essere significativi. Per comprendere l'utilizzo del servizio e i relativi costi, consulta Prezzi di Google Cloud Observability.

Per le attivazioni a livello di progetto del livello Security Command Center Premium, questo risultato è disponibile solo se il livello Standard è abilitato nell'organizzazione principale.

Per risolvere questo problema, completa i seguenti passaggi:

Crea metrica

  1. Vai alla pagina Metriche basate su log nella console Google Cloud .

    Vai a Metriche basate su log

  2. Fai clic su Crea metrica.

  3. In Tipo di metrica, seleziona Contatore.

  4. In Dettagli:

    1. Imposta un Nome metrica di log.
    2. Aggiungi una descrizione.
    3. Imposta Unità su 1.

  5. In Selezione dei filtri, copia e incolla il testo seguente nella casella Crea filtro, sostituendo il testo esistente, se necessario: 

      resource.type=gcs_bucket
  AND protoPayload.methodName="storage.setIamPermissions"

  6. Fai clic su Crea metrica. Viene visualizzata una conferma.

Crea policy di avviso

  1. Nella console Google Cloud , vai alla pagina Metriche basate su log:

    Vai a Metriche basate su log

    Se utilizzi la barra di ricerca per trovare questa pagina, seleziona il risultato con il sottotitolo Logging.

  2. Nella sezione Metriche definite dall'utente, seleziona la metrica che hai creato nella sezione precedente.

  3. Fai clic su Altro , quindi su Crea avviso da metrica.

    Si apre la finestra di dialogo Nuova condizione con le opzioni di metrica e trasformazione dei dati precompilate.

  4. Fai clic su Avanti.
    1. Rivedi le impostazioni precompilate. Potresti voler modificare il valore di soglia.
    2. Fai clic su Nome condizione e inserisci un nome per la condizione.
  5. Fai clic su Avanti.

  6. Per aggiungere notifiche al tuo criterio di avviso, fai clic su Canali di notifica. Nella finestra di dialogo, seleziona uno o più canali di notifica dal menu e fai clic su Ok.

    Per ricevere una notifica quando gli incidenti vengono aperti e chiusi, seleziona Notifica alla chiusura dell'incidente. Per impostazione predefinita, le notifiche vengono inviate solo quando vengono aperti incidenti.

  7. (Facoltativo) Aggiorna la Durata chiusura automatica incidenti. Questo campo determina quando Monitoring chiude gli incidenti in assenza di dati delle metriche.
  8. (Facoltativo) Fai clic su Documentazione e aggiungi tutte le informazioni che vuoi includere in un messaggio di notifica.
  9. Fai clic su Nome avviso e inserisci un nome per il criterio di avviso.
  10. Fai clic su Crea criterio.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Bucket logging disabled

Nome della categoria nell'API: BUCKET_LOGGING_DISABLED

Esiste un bucket di archiviazione senza logging abilitato.

Per semplificare l'analisi dei problemi di sicurezza e il monitoraggio del consumo dello spazio di archiviazione, abilita i log degli accessi e le informazioni sullo spazio di archiviazione per i bucket Cloud Storage. I log degli accessi forniscono informazioni per tutte le richieste effettuate per un bucket specificato, mentre quelli relativi allo spazio di archiviazione forniscono informazioni sul consumo di spazio di archiviazione in tale bucket.

Per risolvere questo problema, configura il logging per il bucket indicato dal risultato di Security Health Analytics completando la guida su log di utilizzo e log di archiviazione.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Bucket policy only disabled

Nome della categoria nell'API: BUCKET_POLICY_ONLY_DISABLED

L'accesso uniforme a livello di bucket, precedentemente chiamato Solo criterio bucket, non è configurato.

L'accesso uniforme a livello di bucket semplifica il controllo dell'accesso al bucket disattivando le autorizzazioni a livello di oggetto (ACL). Quando sono attive, soltanto le autorizzazioni IAM a livello di bucket garantiscono l'accesso al bucket e agli oggetti che contiene. Per saperne di più, consulta Accesso uniforme a livello di bucket.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Browser Cloud Storage nella consoleGoogle Cloud .

    Vai a Browser Cloud Storage

  2. Nell'elenco dei bucket, fai clic sul nome del bucket che ti interessa.

  3. Fai clic sulla scheda Configuration (Configurazione).

  4. In Autorizzazioni, nella riga relativa al Controllo dell'accesso, fai clic su Modifica modello di controllo dell'accesso dell'accesso.

  5. Nella finestra di dialogo, seleziona Uniforme.

  6. Fai clic su Salva.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Cloud Asset API disabled

Nome della categoria nell'API: CLOUD_ASSET_API_DISABLED

Il servizio Cloud Asset Inventory non è abilitato per il progetto.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Libreria API nella console Google Cloud .

    Vai alla libreria API

  2. Cerca Cloud Asset Inventory.

  3. Seleziona il risultato per il servizio API Cloud Asset.

  4. Assicurati che sia visualizzata l'opzione API abilitata.

Cluster logging disabled

Nome della categoria nell'API: CLUSTER_LOGGING_DISABLED

Il logging non è abilitato per un cluster GKE.

Per semplificare l'analisi dei problemi di sicurezza e il monitoraggio dell'utilizzo, abilita Cloud Logging nei cluster.

A seconda della quantità di informazioni, i costi di Cloud Logging possono essere significativi. Per comprendere il tuo utilizzo del servizio e il relativo costo, consulta Prezzi di Google Cloud Observability.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Cluster Kubernetes nella console Google Cloud .

    Vai ai cluster Kubernetes

  2. Seleziona il cluster elencato nel risultato di Security Health Analytics.

  3. Fai clic su Modifica.

    Se la configurazione del cluster è stata cambiata di recente, il pulsante di modifica potrebbe essere disabilitato. Se non riesci a modificare le impostazioni del cluster, attendi alcuni minuti e riprova.

  4. Nell'elenco a discesa Stackdriver Logging legacy o Stackdriver Kubernetes Engine Monitoring, seleziona Abilitato.

    Queste opzioni non sono compatibili. Assicurati di utilizzare Stackdriver Kubernetes Engine Monitoring da solo oppure Stackdriver Logging legacy con Stackdriver Monitoring legacy.

  5. Fai clic su Salva.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Cluster monitoring disabled

Nome della categoria nell'API: CLUSTER_MONITORING_DISABLED

Il monitoraggio è disabilitato sui cluster GKE.

Per semplificare l'analisi dei problemi di sicurezza e il monitoraggio dell'utilizzo, abilita Cloud Monitoring nei cluster.

A seconda della quantità di informazioni, i costi di Cloud Monitoring possono essere significativi. Per comprendere l'utilizzo del servizio e i relativi costi, consulta Prezzi di Google Cloud Observability.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Cluster Kubernetes nella console Google Cloud .

    Vai ai cluster Kubernetes

  2. Seleziona il cluster elencato nel risultato di Security Health Analytics.

  3. Fai clic su Modifica.

    Se la configurazione del cluster è stata cambiata di recente, il pulsante di modifica potrebbe essere disabilitato. Se non riesci a modificare le impostazioni del cluster, attendi alcuni minuti e poi riprova.

  4. Nell'elenco a discesa Stackdriver Monitoring legacy o Stackdriver Kubernetes Engine Monitoring, seleziona Abilitato.

    Queste opzioni non sono compatibili. Assicurati di utilizzare Stackdriver Kubernetes Engine Monitoring da solo oppure Stackdriver Monitoring legacy con Stackdriver Logging legacy.

  5. Fai clic su Salva.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Cluster private Google access disabled

Nome della categoria nell'API: CLUSTER_PRIVATE_GOOGLE_ACCESS_DISABLED

Gli host del cluster non sono configurati per utilizzare solo indirizzi IP interni privati per accedere alle API di Google.

L'accesso privato Google consente alle istanze di macchine virtuali (VM) con soli indirizzi IP interni privati di raggiungere gli indirizzi IP pubblici delle API e dei servizi Google. Per ulteriori informazioni, consulta Configurare l'accesso privato Google.

Per le attivazioni a livello di progetto del livello Security Command Center Premium, questo risultato è disponibile solo se il livello Standard è abilitato nell'organizzazione principale.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Reti Virtual Private Cloud nella console Google Cloud .

    Vai a Reti VPC

  2. Nell'elenco delle reti, fai clic sul nome della rete che preferisci.

  3. Nella pagina Dettagli rete VPC, fai clic sulla scheda Subnet.

  4. Nell'elenco delle subnet, fai clic sul nome della subnet associata al cluster Kubernetes nel risultato.

  5. Nella pagina Dettagli subnet, fai clic su Modifica.

  6. Nella sezione Accesso privato Google, seleziona On.

  7. Fai clic su Salva.

  8. Per rimuovere gli IP pubblici (esterni) dalle istanze VM il cui unico traffico esterno è verso le API di Google, consulta Annullamento dell'assegnazione di un indirizzo IP esterno statico.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Cluster secrets encryption disabled

Nome della categoria nell'API: CLUSTER_SECRETS_ENCRYPTION_DISABLED

La crittografia dei secret a livello di applicazione è disattivata su un cluster GKE.

La crittografia dei secret a livello di applicazione garantisce che i secret di GKE siano criptati utilizzando le chiavi Cloud KMS. La funzionalità fornisce un ulteriore livello di sicurezza per i dati sensibili, come secret definiti dall'utente e secret necessari per il funzionamento del cluster, ad esempio le chiavi dei account di servizio, che sono tutte archiviate in etcd.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Chiavi Cloud KMS nella console Google Cloud .

    Vai alle chiavi Cloud KMS

  2. Controlla le chiavi delle tue applicazioni o crea una chiave di crittografia del database (DEK). Per maggiori informazioni, consulta Creazione di una chiave Cloud KMS.

  3. Vai alla pagina Cluster Kubernetes.

    Vai ai cluster Kubernetes

  4. Seleziona il cluster nel risultato.

  5. In Sicurezza, nel campo Crittografia dei secret a livello di applicazione, fai clic su Modifica crittografia dei secret a livello di applicazione.

  6. Seleziona la casella di controllo Abilita la crittografia dei secret a livello di applicazione, quindi scegli la DEK che hai creato.

  7. Fai clic su Salva modifiche.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Cluster shielded nodes disabled

Nome della categoria nell'API: CLUSTER_SHIELDED_NODES_DISABLED

I nodi GKE schermati non sono abilitati per un cluster.

Senza nodi GKE schermati, gli utenti malintenzionati possono sfruttare una vulnerabilità in un pod per esfiltrare le credenziali di bootstrap e impersonare i nodi nel cluster. La vulnerabilità può consentire agli utenti malintenzionati di accedere ai secret del cluster.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Cluster Kubernetes nella console Google Cloud .

    Vai ai cluster Kubernetes

  2. Seleziona il cluster nel risultato.

  3. In Sicurezza, nel campo Nodi GKE schermati, fai clic su Modifica nodi GKE schermati.

  4. Seleziona la casella di controllo Abilita Shielded GKE Nodes.

  5. Fai clic su Salva modifiche.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Compute project wide SSH keys allowed

Nome della categoria nell'API: COMPUTE_PROJECT_WIDE_SSH_KEYS_ALLOWED

Vengono utilizzate chiavi SSH a livello di progetto, che consentono l'accesso a tutte le istanze del progetto.

L'utilizzo di chiavi SSH a livello di progetto semplifica la gestione delle chiavi SSH, ma, se compromesse, costituisce un rischio per la sicurezza che può interessare tutte le istanze di un progetto. Devi utilizzare chiavi SSH specifiche dell'istanza, che limitano la superficie di attacco se le chiavi SSH sono compromesse. Per saperne di più, consulta Gestione delle chiavi SSH nei metadati.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Istanze VM nella console Google Cloud .

    Vai a Istanze VM

  2. Nell'elenco delle istanze, fai clic sul nome dell'istanza nel risultato.

  3. Nella pagina Dettagli istanza VM, fai clic su Modifica.

  4. In Chiavi SSH, seleziona Blocca chiavi SSH a livello di progetto.

  5. Fai clic su Salva.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Compute Secure Boot disabled

Nome della categoria nell'API: COMPUTE_SECURE_BOOT_DISABLED

Una Shielded VM non ha l'avvio protetto abilitato.

L'uso dell'avvio protetto aiuta a proteggere le tue macchine virtuali da rootkit e bootkit. Compute Engine non abilita Avvio protetto per impostazione predefinita perché alcuni driver non firmati e software di basso livello non sono compatibili. Se la tua VM non utilizza software incompatibile e viene avviata con Avvio protetto abilitato, Google consiglia di utilizzare Avvio protetto. Se utilizzi moduli di terze parti con driver Nvidia, assicurati che siano compatibili con Avvio protetto prima di abilitarlo.

Per ulteriori informazioni, vedi Avvio protetto.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Istanze VM nella console Google Cloud .

    Vai a Istanze VM

  2. Nell'elenco delle istanze, fai clic sul nome dell'istanza nel risultato.

  3. Nella pagina Dettagli istanza VM, fai clic su Arresta.

  4. Dopo l'arresto dell'istanza, fai clic su Modifica.

  5. Nella sezione Shielded VM, seleziona Attiva Avvio protetto.

  6. Fai clic su Salva.

  7. Fai clic su Avvia per avviare l'istanza.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Compute serial ports enabled

Nome della categoria nell'API: COMPUTE_SERIAL_PORTS_ENABLED

Le porte seriali sono abilitate per un'istanza, consentendo le connessioni alla console seriale dell'istanza.

Se abiliti la console seriale interattiva su un'istanza, i client possono tentare di connettersi a questa istanza da qualsiasi indirizzo IP. Pertanto, il supporto della console seriale interattiva deve essere disabilitato. Per saperne di più, consulta la sezione Attivare l'accesso per un progetto.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Istanze VM nella console Google Cloud .

    Vai a Istanze VM

  2. Nell'elenco delle istanze, fai clic sul nome dell'istanza nel risultato.

  3. Nella pagina Dettagli istanza VM, fai clic su Modifica.

  4. Nella sezione Accesso remoto, deseleziona Abilita connessione a porte seriali.

  5. Fai clic su Salva.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Confidential Computing disabled

Nome della categoria nell'API: CONFIDENTIAL_COMPUTING_DISABLED

Su un'istanza Compute Engine non è abilitato Confidential Computing.

Confidential Computing aggiunge un terzo pilastro all'intero processo della crittografia end-to-end mediante la crittografia dei dati in uso. Grazie agli ambienti di esecuzione riservati offerti da Confidential Computing e AMD Secure Encrypted Virtualization (SEV), Google Cloud mantiene criptati in memoria il codice sensibile e gli altri dati durante l'elaborazione.

Confidential Computing può essere abilitato solo quando viene creata un'istanza. Pertanto, devi eliminare l'istanza corrente e crearne una nuova.

Per saperne di più, consulta Confidential VM e Compute Engine.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Istanze VM nella console Google Cloud .

    Vai a Istanze VM

  2. Nell'elenco delle istanze, fai clic sul nome dell'istanza nel risultato.

  3. Nella pagina Dettagli istanza VM, fai clic su Elimina.

  4. Crea una Confidential VM utilizzando la console Google Cloud .

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

COS not used

Nome della categoria nell'API: COS_NOT_USED

Le VM Compute Engine non utilizzano Container-Optimized OS, che è progettato per eseguire i container Docker in modo sicuro. Google Cloud

Container-Optimized OS è il sistema operativo consigliato da Google per ospitare ed eseguire container su Google Cloud. Le dimensioni ridotte di OS minimizzano i rischi per la sicurezza e, allo stesso tempo, gli aggiornamenti automatici applicano patch alle vulnerabilità di sicurezza con tempestività. Per saperne di più, consulta Panoramica di Container-Optimized OS.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Cluster Kubernetes nella console Google Cloud .

    Vai ai cluster Kubernetes

  2. Nell'elenco dei cluster, fai clic sul nome del cluster nel risultato.

  3. Fai clic sulla scheda Nodi.

  4. Per ogni node pool:

    1. Fai clic sul nome del pool di nodi per passare alla pagina dei dettagli.
    2. Fai clic su Modifica .
    3. In Nodi -> Tipo di immagine, fai clic su Cambia.
    4. Seleziona Container-Optimized OS e poi fai clic su Cambia.
    5. Fai clic su Salva.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Custom role not monitored

Nome della categoria nell'API: CUSTOM_ROLE_NOT_MONITORED

Le metriche di log e gli avvisi non sono configurati per monitorare le modifiche ai ruoli personalizzati.

IAM fornisce ruoli predefiniti e personalizzati che consentono l'accesso a risorse Google Cloud specifiche. Il monitoraggio delle attività di creazione, eliminazione e aggiornamento dei ruoli ti consente di identificare i ruoli con privilegi in eccesso nelle fasi iniziali. Per ulteriori informazioni, consulta Panoramica delle metriche basate su log.

A seconda della quantità di informazioni, i costi di Cloud Monitoring possono essere significativi. Per comprendere l'utilizzo del servizio e i relativi costi, consulta Prezzi di Google Cloud Observability.

Per le attivazioni a livello di progetto del livello Security Command Center Premium, questo risultato è disponibile solo se il livello Standard è abilitato nell'organizzazione principale.

Per risolvere questo problema, completa i seguenti passaggi:

Crea metrica

  1. Vai alla pagina Metriche basate su log nella console Google Cloud .

    Vai a Metriche basate su log

  2. Fai clic su Crea metrica.

  3. In Tipo di metrica, seleziona Contatore.

  4. In Dettagli:

    1. Imposta un Nome metrica di log.
    2. Aggiungi una descrizione.
    3. Imposta Unità su 1.

  5. In Selezione dei filtri, copia e incolla il testo seguente nella casella Crea filtro, sostituendo il testo esistente, se necessario: 

      resource.type="iam_role"
  AND (protoPayload.methodName="google.iam.admin.v1.CreateRole"
  OR protoPayload.methodName="google.iam.admin.v1.DeleteRole"
  OR protoPayload.methodName="google.iam.admin.v1.UpdateRole")

  6. Fai clic su Crea metrica. Viene visualizzata una conferma.

Crea policy di avviso

  1. Nella console Google Cloud , vai alla pagina Metriche basate su log:

    Vai a Metriche basate su log

    Se utilizzi la barra di ricerca per trovare questa pagina, seleziona il risultato con il sottotitolo Logging.

  2. Nella sezione Metriche definite dall'utente, seleziona la metrica che hai creato nella sezione precedente.

  3. Fai clic su Altro , quindi su Crea avviso da metrica.

    Si apre la finestra di dialogo Nuova condizione con le opzioni di metrica e trasformazione dei dati precompilate.

  4. Fai clic su Avanti.
    1. Rivedi le impostazioni precompilate. Potresti voler modificare il valore di soglia.
    2. Fai clic su Nome condizione e inserisci un nome per la condizione.
  5. Fai clic su Avanti.

  6. Per aggiungere notifiche al tuo criterio di avviso, fai clic su Canali di notifica. Nella finestra di dialogo, seleziona uno o più canali di notifica dal menu e fai clic su Ok.

    Per ricevere una notifica quando gli incidenti vengono aperti e chiusi, seleziona Notifica alla chiusura dell'incidente. Per impostazione predefinita, le notifiche vengono inviate solo quando vengono aperti incidenti.

  7. (Facoltativo) Aggiorna la Durata chiusura automatica incidenti. Questo campo determina quando Monitoring chiude gli incidenti in assenza di dati delle metriche.
  8. (Facoltativo) Fai clic su Documentazione e aggiungi tutte le informazioni che vuoi includere in un messaggio di notifica.
  9. Fai clic su Nome avviso e inserisci un nome per il criterio di avviso.
  10. Fai clic su Crea criterio.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Dataproc CMEK disabled

Nome della categoria nell'API: DATAPROC_CMEK_DISABLED

È stato creato un cluster Dataproc senza una configurazione CMEK di crittografia. Con CMEK, le chiavi che crei e gestisci in Cloud Key Management Service criptano le chiavi che Google Cloud utilizza per criptare i tuoi dati, offrendoti un maggiore controllo sull'accesso ai tuoi dati.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Cluster Dataproc nella console Google Cloud .

    Vai ai cluster Dataproc

  2. Seleziona il progetto e fai clic su Crea cluster.

  3. Nella sezione Gestisci sicurezza, fai clic su Crittografia e seleziona Chiave gestita dal cliente.

  4. Seleziona una chiave gestita dal cliente dall'elenco.

    Se non hai una chiave gestita dal cliente, devi crearne una da utilizzare. Per saperne di più, vedi Chiavi di crittografia gestite dal cliente.

  5. Assicurati che alla chiave KMS selezionata sia assegnato il ruolo Autore crittografia/decrittografia CryptoKey Cloud KMS all'account di servizio Dataproc Cluster ("serviceAccount:service-project_number@compute-system.iam.gserviceaccount.com").

  6. Una volta creato il cluster, esegui la migrazione di tutti i workload dal cluster precedente a quello nuovo.

  7. Vai ai cluster Dataproc e seleziona il tuo progetto.

  8. Seleziona il cluster precedente e fai clic su Elimina cluster.

  9. Ripeti tutti i passaggi precedenti per gli altri cluster Dataproc disponibili nel progetto selezionato.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Dataproc image outdated

Nome della categoria nell'API: DATAPROC_IMAGE_OUTDATED

È stato creato un cluster Dataproc utilizzando una versione dell'immagine Dataproc interessata dalle vulnerabilità di sicurezza nell'utilità Apache Log4j 2 (CVE-2021-44228 e CVE-2021-45046).

Questo rilevatore trova le vulnerabilità controllando se il campo softwareConfig.imageVersion nella proprietà config di un Cluster ha una delle seguenti versioni interessate:

  • Versioni dell'immagine precedenti alla 1.3.95.
  • Versioni immagine secondarie precedenti a 1.4.77, 1.5.53 e 2.0.27.

Il numero di versione di un'immagine Dataproc personalizzata può essere ignorato manualmente. Considera i seguenti scenari:

  • È possibile modificare la versione di un'immagine personalizzata interessata per farla sembrare non interessata. In questo caso, questo rilevatore non genera un risultato.
  • È possibile sostituire la versione di un'immagine personalizzata non interessata con una nota per avere la vulnerabilità. In questo caso, questo rilevatore emette un risultato falso positivo. Per eliminare questi falsi positivi, puoi disattivarli.

Per risolvere questo problema, ricrea e aggiorna il cluster interessato.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Dataset CMEK disabled

Nome della categoria nell'API: DATASET_CMEK_DISABLED

Un set di dati BigQuery non è configurato per utilizzare una chiave di crittografia gestita dal cliente (CMEK) predefinita.

Con CMEK, le chiavi che crei e gestisci in Cloud KMS criptano le chiavi utilizzate Google Cloud per criptare i tuoi dati, offrendoti un maggiore controllo sull'accesso ai tuoi dati. Per ulteriori informazioni, consulta Protezione dei dati con le chiavi Cloud KMS.

Per risolvere questo problema, completa i seguenti passaggi:

Non puoi scambiare una tabella in loco tra le crittografie predefinite e la crittografia CMEK. Per impostare una chiave CMEK predefinita con cui criptare tutte le nuove tabelle nel set di dati, segui le istruzioni per impostare una chiave predefinita per il set di dati.

L'impostazione di una chiave predefinita non viene eseguita nuovamente la crittografia retroattiva delle tabelle attualmente nel set di dati con una nuova chiave. Per utilizzare CMEK per i dati esistenti:

  1. Crea un nuovo set di dati.
  2. Imposta una chiave CMEK predefinita sul set di dati che hai creato.
  3. Per copiare le tabelle nel set di dati abilitato per CMEK, segui le istruzioni per copiare una tabella.
  4. Dopo aver copiato correttamente i dati, elimina i set di dati originali.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Default network

Nome della categoria nell'API: DEFAULT_NETWORK

La rete predefinita esiste in un progetto.

Le reti predefinite hanno creato automaticamente regole firewall e configurazioni di rete che potrebbero non essere sicure. Per saperne di più, consulta la sezione Rete predefinita.

Per le attivazioni a livello di progetto del livello Security Command Center Premium, questo risultato è disponibile solo se il livello Standard è abilitato nell'organizzazione principale.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Reti VPC nella console Google Cloud .

    Vai a Reti VPC

  2. Nell'elenco delle reti, fai clic sul nome della rete predefinita.

  3. Nella pagina Dettagli rete VPC, fai clic su Elimina rete VPC.

  4. Per creare una nuova rete con regole firewall personalizzate, consulta la sezione sulla creazione di reti.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Default service account used

Nome della categoria nell'API: DEFAULT_SERVICE_ACCOUNT_USED

Un'istanza Compute Engine è configurata per utilizzare il account di servizio predefinito.

Il account di servizio predefinito di Compute Engine ha il ruolo Editor nel progetto, che consente l'accesso in lettura e scrittura alla maggior parte dei servizi Google Cloud . Per difenderti da escalation dei privilegi e accessi non autorizzati, non utilizzare il account di servizio predefinito di Compute Engine. Crea invece un nuovo account di servizio e assegna solo le autorizzazioni necessarie per la tua istanza. Per informazioni su ruoli e autorizzazioni, consulta Controllo dell'accesso.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Istanze VM nella console Google Cloud .

    Vai a Istanze VM

  2. Seleziona l'istanza correlata al risultato di Security Health Analytics.

  3. Nella pagina Dettagli istanza che viene caricata, fai clic su Arresta.

  4. Dopo l'arresto dell'istanza, fai clic su Modifica.

  5. Nella sezione Service account, seleziona un account di servizio diverso da quello predefinito di Compute Engine. Prima potrebbe essere necessario creare un nuovo account di servizio. Per informazioni su ruoli e autorizzazioni IAM, consulta Controllo dell'accesso.

  6. Fai clic su Salva. La nuova configurazione viene visualizzata nella pagina Dettagli istanza.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Disk CMEK disabled

Nome della categoria nell'API: DISK_CMEK_DISABLED

I dischi di questa VM non sono criptati con chiavi di crittografia gestite dal cliente (CMEK).

Con CMEK, le chiavi che crei e gestisci in Cloud KMS criptano le chiavi che Google Cloud utilizza per criptare i tuoi dati, offrendoti un maggiore controllo sull'accesso ai tuoi dati. Per ulteriori informazioni, consulta Protezione delle risorse con le chiavi Cloud KMS.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Dischi Compute Engine nella consoleGoogle Cloud .

    Vai a Dischi Compute Engine

  2. Nell'elenco dei dischi, fai clic sul nome del disco indicato nel risultato.

  3. Nella pagina Gestisci disco, fai clic su Elimina.

  4. Per creare un nuovo disco con CMEK abilitata, consulta Criptare un nuovo disco permanente con le tue chiavi. Le chiavi CMEK comportano costi aggiuntivi correlati a Cloud KMS.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Disk CSEK disabled

Nome della categoria nell'API: DISK_CSEK_DISABLED

I dischi di questa VM non sono criptati con chiavi di crittografia fornite dal cliente (CSEK). I dischi per le VM critiche devono essere criptati con CSEK.

Se fornisci le tue chiavi di crittografia, Compute Engine le utilizza per proteggere le chiavi generate da Google utilizzate per criptare e decriptare i tuoi dati. Per maggiori informazioni, vedi Chiavi di crittografia fornite dal cliente. Le chiavi CSEK comportano costi aggiuntivi correlati a Cloud KMS.

Per risolvere questo problema, completa i seguenti passaggi:

Elimina e crea disco

Puoi criptare solo nuovi dischi permanenti con la tua chiave. Non puoi criptare i dischi permanenti esistenti con la tua chiave.

  1. Vai alla pagina Dischi Compute Engine nella consoleGoogle Cloud .

    Vai a Dischi Compute Engine

  2. Nell'elenco dei dischi, fai clic sul nome del disco indicato nel risultato.

  3. Nella pagina Gestisci disco, fai clic su Elimina.

  4. Per creare un nuovo disco con CSEK abilitata, vedi Cripta i dischi con chiavi di crittografia fornite dal cliente.

  5. Completa i passaggi rimanenti per attivare il rilevatore.

Attiva il rilevatore

  1. Vai alla pagina Asset di Security Command Center nella consoleGoogle Cloud .

    Vai ad Asset

  2. Nella sezione Tipo di risorsa del riquadro Filtri rapidi, seleziona compute.Disk.

    Se non vedi compute.Disk, fai clic su Visualizza altro, inserisci Disk nel campo di ricerca e poi fai clic su Applica.

    Il riquadro Risultati si aggiorna per mostrare solo le istanze del tipo di risorsa compute.Disk.

  3. Nella colonna Nome visualizzato, seleziona la casella accanto al nome del disco che vuoi utilizzare con CSEK, quindi fai clic su Imposta indicatori di sicurezza.

  4. Nella finestra di dialogo, fai clic su Aggiungi segno.

  5. Nel campo chiave, inserisci enforce_customer_supplied_disk_encryption_keys e nel campo valore, inserisci true.

  6. Fai clic su Salva.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

DNS logging disabled

Nome della categoria nell'API: DNS_LOGGING_DISABLED

Il monitoraggio dei log di Cloud DNS offre visibilità sui nomi DNS richiesti dai client all'interno della rete VPC. Questi log possono essere monitorati per verificare la presenza di nomi di dominio anomali ed essere valutati in base alla threat intelligence. Ti consigliamo di abilitare il logging DNS per le reti VPC.

A seconda della quantità di informazioni, i costi di logging di Cloud DNS possono essere significativi. Per comprendere l'utilizzo del servizio e il relativo costo, consulta Prezzi di Google Cloud Observability: Cloud Logging.

Per le attivazioni a livello di progetto del livello Security Command Center Premium, questo risultato è disponibile solo se il livello Standard è abilitato nell'organizzazione principale.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Reti VPC nella console Google Cloud .

    Vai a Reti VPC

  2. Nell'elenco delle reti, fai clic sul nome della rete VPC.

  3. Crea un nuovo criterio del server (se non ne esiste uno) o modifica un criterio esistente:

    • Se la rete non dispone di un criterio per il server DNS, completa i seguenti passaggi:

      1. Fai clic su Modifica.
      2. Nel campo Policy del server DNS, fai clic su Crea una nuova policy del server.
      3. Inserisci un nome per il nuovo criterio del server.
      4. Imposta Log su On.
      5. Fai clic su Salva.

    • Se la rete dispone di una policy del server DNS, completa i seguenti passaggi:

      1. Nel campo Policy del server DNS, fai clic sul nome della policy DNS.
      2. Fai clic su Modifica criterio.
      3. Imposta Log su On.
      4. Fai clic su Salva.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

DNSSEC disabled

Nome della categoria nell'API: DNSSEC_DISABLED

Le Domain Name System Security Extensions (DNSSEC) sono disattivate per le zone Cloud DNS.

DNSSEC convalida le risposte DNS e mitiga i rischi, come la compromissione DNS e gli attacchi person in the middle, mediante la firma crittografica dei record DNS. Ti consigliamo di attivare DNSSEC. Per saperne di più, consulta la panoramica delle estensioni DNSSEC (Domain Name System Security Extensions).

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Cloud DNS nella console Google Cloud .

    Vai alle reti Cloud DNS

  2. Individua la riga con la zona DNS indicata nel risultato.

  3. Fai clic sull'impostazione DNSSEC nella riga e poi, nella sezione DNSSEC, seleziona On.

  4. Esamina la finestra di dialogo visualizzata. Se le impostazioni sono corrette, fai clic su Attiva.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Effectively Anonymous Users Granted GKE Cluster Access

Nome della categoria nell'API: GKE_PRIVILEGE_ESCALATION_DEFAULT_USERS_GROUPS

Qualcuno ha creato un'associazione RBAC che fa riferimento a uno dei seguenti utenti o gruppi:

  • system:anonymous
  • system:authenticated
  • system:unauthenticated

Questi utenti e gruppi sono effettivamente anonimi e non devono essere utilizzati in RoleBinding o ClusterRoleBinding. Per maggiori dettagli, vedi Evitare ruoli e gruppi predefiniti.

Per risolvere questo problema, applica i seguenti passaggi alle risorse interessate:

  1. Apri il manifest per ogni ClusterRoleBinding o RoleBinding interessato.
  2. Imposta i seguenti campi con restrizioni su uno dei valori consentiti.

Campi con limitazioni

  • subjects[*].name

Valori consentiti

  • Qualsiasi gruppo, utente o service account che non includa system:anonymous, system:authenticated o system:unauthenticated.

Egress deny rule not set

Nome della categoria nell'API: EGRESS_DENY_RULE_NOT_SET

Su un firewall non è impostata una regola di negazione per il traffico in uscita.

Un firewall che nega tutto il traffico di rete in uscita impedisce qualsiasi connessione di rete in uscita indesiderata, ad eccezione di quelle autorizzate esplicitamente da altri firewall. Per ulteriori informazioni, vedi Scenari di uscita.

Per le attivazioni a livello di progetto del livello Security Command Center Premium, questo risultato è disponibile solo se il livello Standard è abilitato nell'organizzazione principale.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Firewall nella console Google Cloud .

    Vai a Firewall

  2. Fai clic su Crea regola firewall.

  3. Assegna un nome al firewall e, facoltativamente, una descrizione.

  4. In Direzione del traffico, seleziona In uscita.

  5. Nella sezione Azione in caso di corrispondenza, seleziona Nega.

  6. Nel menu a discesa Destinazioni, seleziona Tutte le istanze nella rete.

  7. Nel menu a discesa Filtro di destinazione, seleziona Intervalli IP, quindi digita 0.0.0.0/0 nella casella Intervalli IP di destinazione.

  8. In Protocolli e porte, seleziona Nega tutto.

  9. Fai clic su Disattiva regola e poi, in Applicazione, seleziona Attivata.

  10. Fai clic su Crea.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Essential contacts not configured

Nome della categoria nell'API: ESSENTIAL_CONTACTS_NOT_CONFIGURED

La tua organizzazione non ha designato una persona o un gruppo per ricevere notifiche da Google Cloud in merito a eventi importanti come attacchi, vulnerabilità e incidenti di dati all'interno della tua organizzazione Google Cloud . Ti consigliamo di designare come contatto essenziale una o più persone o gruppi della tua organizzazione aziendale.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Contatti fondamentali nella console Google Cloud .

    Vai alla pagina Contatti fondamentali.

  2. Assicurati che l'organizzazione venga visualizzata nel selettore di risorse nella parte superiore della pagina. Il selettore di risorse indica il progetto, la cartella o l'organizzazione per cui stai gestendo i contatti.

  3. Fai clic su +Aggiungi contatto. Si apre il riquadro Aggiungi un contatto.

  4. Nei campi Email e Conferma email, inserisci l'indirizzo email del contatto.

  5. Nella sezione Categorie di notifica, seleziona le categorie di notifica per cui il contatto deve ricevere le comunicazioni. Assicurati di aver configurato gli indirizzi email appropriati per ognuna delle seguenti categorie di notifica:

    1. Legale
    2. Sicurezza
    3. Sospensione
    4. Tecnico

  6. Fai clic su Salva.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Firewall not monitored

Nome della categoria nell'API: FIREWALL_NOT_MONITORED

Le metriche di log e gli avvisi non sono configurati per monitorare le modifiche alle regole del firewall di rete VPC.

Il monitoraggio degli eventi di creazione e aggiornamento delle regole firewall ti consente di ricavare insight sulle modifiche dell'accesso alla rete e può aiutarti a rilevare rapidamente le attività sospette. Per maggiori informazioni, consulta la panoramica delle metriche basate su log.

A seconda della quantità di informazioni, i costi di Cloud Monitoring possono essere significativi. Per comprendere l'utilizzo del servizio e i relativi costi, consulta Prezzi di Google Cloud Observability.

Per le attivazioni a livello di progetto del livello Security Command Center Premium, questo risultato è disponibile solo se il livello Standard è abilitato nell'organizzazione principale.

Per risolvere questo problema, completa i seguenti passaggi:

Crea metrica

  1. Vai alla pagina Metriche basate su log nella console Google Cloud .

    Vai a Metriche basate su log

  2. Fai clic su Crea metrica.

  3. In Tipo di metrica, seleziona Contatore.

  4. In Dettagli:

    1. Imposta un Nome metrica di log.
    2. Aggiungi una descrizione.
    3. Imposta Unità su 1.

  5. In Selezione dei filtri, copia e incolla il testo seguente nella casella Crea filtro, sostituendo il testo esistente, se necessario: 

      resource.type="gce_firewall_rule"
  AND (protoPayload.methodName:"compute.firewalls.insert"
  OR protoPayload.methodName:"compute.firewalls.patch"
  OR protoPayload.methodName:"compute.firewalls.delete")

  6. Fai clic su Crea metrica. Viene visualizzata una conferma.

Crea policy di avviso

  1. Nella console Google Cloud , vai alla pagina Metriche basate su log:

    Vai a Metriche basate su log

    Se utilizzi la barra di ricerca per trovare questa pagina, seleziona il risultato con il sottotitolo Logging.

  2. Nella sezione Metriche definite dall'utente, seleziona la metrica che hai creato nella sezione precedente.

  3. Fai clic su Altro , quindi su Crea avviso da metrica.

    Si apre la finestra di dialogo Nuova condizione con le opzioni di metrica e trasformazione dei dati precompilate.

  4. Fai clic su Avanti.
    1. Rivedi le impostazioni precompilate. Potresti voler modificare il valore di soglia.
    2. Fai clic su Nome condizione e inserisci un nome per la condizione.
  5. Fai clic su Avanti.

  6. Per aggiungere notifiche al tuo criterio di avviso, fai clic su Canali di notifica. Nella finestra di dialogo, seleziona uno o più canali di notifica dal menu e fai clic su Ok.

    Per ricevere una notifica quando gli incidenti vengono aperti e chiusi, seleziona Notifica alla chiusura dell'incidente. Per impostazione predefinita, le notifiche vengono inviate solo quando vengono aperti incidenti.

  7. (Facoltativo) Aggiorna la Durata chiusura automatica incidenti. Questo campo determina quando Monitoring chiude gli incidenti in assenza di dati delle metriche.
  8. (Facoltativo) Fai clic su Documentazione e aggiungi tutte le informazioni che vuoi includere in un messaggio di notifica.
  9. Fai clic su Nome avviso e inserisci un nome per il criterio di avviso.
  10. Fai clic su Crea criterio.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Firewall rule logging disabled

Nome della categoria nell'API: FIREWALL_RULE_LOGGING_DISABLED

Il logging delle regole firewall è disattivato.

Il logging delle regole firewall consente di controllare, verificare e analizzare gli effetti delle regole firewall. Può essere utile per controllare l'accesso alla rete o per avvisare preventivamente che la rete viene utilizzata in un modo non approvato. Il costo dei log può essere significativo. Per saperne di più sul logging delle regole firewall e sui relativi costi, consulta Utilizzo del logging delle regole firewall.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Firewall nella console Google Cloud .

    Vai a Firewall

  2. Nell'elenco delle regole firewall, fai clic sul nome della regola firewall che ti interessa.

  3. Fai clic su Modifica.

  4. In Log, seleziona On.

  5. Fai clic su Salva.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Flow logs disabled

Nome della categoria nell'API: FLOW_LOGS_DISABLED

Esiste una subnet VPC con i log di flusso disabilitati.

I log di flusso VPC registrano un campione di flussi di rete inviati e ricevuti dalle istanze VM. Questi log possono essere utilizzati per monitoraggio della rete, analisi forense, analisi della sicurezza in tempo reale e ottimizzazione delle spese. Per ulteriori informazioni sui log di flusso e sui relativi costi, consulta Utilizzo dei log di flusso VPC.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Reti VPC nella consoleGoogle Cloud .

    Vai a Reti VPC

  2. Nell'elenco delle reti, fai clic sul nome della rete che preferisci.

  3. Nella pagina Dettagli rete VPC, fai clic sulla scheda Subnet.

  4. Nell'elenco delle subnet, fai clic sul nome della subnet indicato nel risultato.

  5. Nella pagina Dettagli subnet, fai clic su Modifica.

  6. Nella sezione Log di flusso, seleziona Attivati.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Nome della categoria nell'API: VPC_FLOW_LOGS_SETTINGS_NOT_RECOMMENDED

Nella configurazione di una subnet in una rete VPC, il servizio Log di flusso VPC è disattivato o non è configurato in base ai suggerimenti di CIS Benchmark 1.3. I log di flusso VPC registrano un campione di flussi di rete inviati e ricevuti dalle istanze VM, che può essere utilizzato per rilevare minacce.

Per saperne di più sui log di flusso VPC e sui relativi costi, consulta Utilizzo dei log di flusso VPC.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Reti VPC nella consoleGoogle Cloud .

    Vai a Reti VPC

  2. Nell'elenco delle reti, fai clic sul nome della rete.

  3. Nella pagina Dettagli rete VPC, fai clic sulla scheda Subnet.

  4. Nell'elenco delle subnet, fai clic sul nome della subnet indicato nel risultato.

  5. Nella pagina Dettagli subnet, fai clic su Modifica.

  6. Nella sezione Log di flusso, seleziona Attivati.

    1. Facoltativamente, modifica la configurazione dei log facendo clic sul pulsante Configura log per espandere la scheda. CIS Benchmarks consiglia le seguenti impostazioni:
      1. Imposta Intervallo di aggregazione su 5 sec.
      2. Per la casella di controllo Campi aggiuntivi, seleziona l'opzione Includi metadati.
      3. Imposta la frequenza di campionamento su 100%.
      4. Fai clic sul pulsante SALVA.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Full API access

Nome della categoria nell'API: FULL_API_ACCESS

Un'istanza di Compute Engine è configurata per utilizzare il account di servizio predefinito con accesso completo a tutte le API Google Cloud .

Un'istanza configurata con l'account di servizio predefinito e l'ambito di accesso API impostato su Consenti l'accesso completo a tutte le API Cloud potrebbe consentire agli utenti di eseguire operazioni o chiamate API per le quali non dispongono di autorizzazioni IAM. Per saperne di più, consulta Account di servizio predefinito di Compute Engine.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Istanze VM nella console Google Cloud .

    Vai a Istanze VM

  2. Nell'elenco delle istanze, fai clic sul nome dell'istanza nel risultato.

  3. Se l'istanza è in esecuzione, fai clic su Arresta.

  4. Quando l'istanza è arrestata, fai clic su Modifica.

  5. Nella sezione Sicurezza e accesso, in Service account, seleziona Service account predefinito di Compute Engine.

  6. In Ambiti di accesso, seleziona Consenti l'accesso predefinito o Imposta l'accesso per ogni API. In questo modo vengono limitate le API a cui può accedere qualsiasi processo o carico di lavoro che utilizza il account di servizio VM predefinito.

  7. Se hai selezionato Imposta l'accesso per ogni API, procedi nel seguente modo:

    • Disabilita Cloud Platform impostandolo su Nessuno.
    • Attiva le API specifiche a cui deve accedere l'account di servizio VM predefinito.

  8. Fai clic su Salva.

  9. Fai clic su Avvia per avviare l'istanza.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

HTTP load balancer

Nome della categoria nell'API: HTTP_LOAD_BALANCER

Un'istanza Compute Engine utilizza un bilanciatore del carico configurato per utilizzare un proxy HTTP di destinazione anziché un proxy HTTPS di destinazione.

Per proteggere l'integrità dei tuoi dati e impedire a intrusi di manomettere le comunicazioni, configura i bilanciatori del carico HTTP(S) in modo da consentire solo il traffico HTTPS. Per saperne di più, consulta la panoramica del bilanciamento del carico HTTP(S) esterno.

Per le attivazioni a livello di progetto del livello Security Command Center Premium, questo risultato è disponibile solo se il livello Standard è abilitato nell'organizzazione principale.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Proxy di destinazione nella console Google Cloud .

    Vai a Proxy di destinazione

  2. Nell'elenco dei proxy di destinazione, fai clic sul nome del proxy di destinazione nel risultato.

  3. Fai clic sul link nella sezione Mappa URL.

  4. Fai clic su Modifica.

  5. Fai clic su Configurazione frontend.

  6. Elimina tutte le configurazioni di IP frontend e porta che consentono il traffico HTTP e crea nuove configurazioni che consentono il traffico HTTPS.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Instance OS login disabled

Nome della categoria nell'API: INSTANCE_OS_LOGIN_DISABLED

OS Login è disabilitato su questa istanza Compute Engine.

OS Login consente la gestione centralizzata delle chiavi SSH con IAM e disattiva la configurazione delle chiavi SSH basata su metadati in tutte le istanze di un progetto. Scopri come configurare l'accesso OS.

Per le attivazioni a livello di progetto del livello Security Command Center Premium, questo risultato è disponibile solo se il livello Standard è abilitato nell'organizzazione principale.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Istanze VM nella console Google Cloud .

    Vai a Istanze VM

  2. Nell'elenco delle istanze, fai clic sul nome dell'istanza nel risultato.

  3. Nella pagina Dettagli istanza che viene caricata, fai clic su Arresta.

  4. Dopo l'arresto dell'istanza, fai clic su Modifica.

  5. Nella sezione Metadati personalizzati, assicurati che l'elemento con la chiave enable-oslogin abbia il valore TRUE.

  6. Fai clic su Salva.

  7. Fai clic su Avvia per avviare l'istanza.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Integrity monitoring disabled

Nome della categoria nell'API: INTEGRITY_MONITORING_DISABLED

Il monitoraggio dell'integrità è disabilitato in un cluster GKE.

Il monitoraggio dell'integrità consente di controllare e verificare l'integrità in fase di avvio runtime dei nodi schermati mediante Monitoring. Questo consente di rispondere a errori di integrità e di impedire il deployment dei nodi compromessi nel cluster.

Per risolvere questo problema, completa i seguenti passaggi:

Una volta eseguito il provisioning di un nodo, non è possibile aggiornarlo per abilitare il monitoraggio dell'integrità. Devi creare un nuovo pool di nodi con il monitoraggio dell'integrità abilitato.

  1. Vai alla pagina Cluster Kubernetes nella console Google Cloud .

    Vai ai cluster Kubernetes

  2. Fai clic sul nome del cluster nel risultato.

  3. Fai clic su Aggiungi pool di nodi.

  4. Nella scheda Sicurezza, assicurati che l'opzione Abilita il monitoraggio dell'integrità sia attivata.

  5. Fai clic su Crea.

  6. Per eseguire la migrazione dei workload dai node pool non conformi esistenti ai nuovi node pool, consulta Migrazione dei workload in tipi di macchine diversi.

  7. Dopo aver spostato i workload, elimina il pool di nodi non conforme originale.

    1. Nella pagina Cluster Kubernetes, nel menu Node pool, fai clic sul nome del pool di nodi che vuoi eliminare.
    2. Fai clic su Rimuovi node pool.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Intranode visibility disabled

Nome della categoria nell'API: INTRANODE_VISIBILITY_DISABLED

La visibilità tra nodi è disabilitata per un cluster GKE.

Se abiliti la visibilità tra nodi, il traffico tra i pod dei vari nodi sarà visibile nell'infrastruttura di networking. Questa funzionalità consente di utilizzare il logging del flusso VPC o altre funzionalità VPC per monitorare o controllare il traffico tra nodi. Per ottenere i log, devi abilitare quelli del flusso VPC nella subnet selezionata. Per maggiori informazioni, consulta Utilizzo dei log di flusso VPC.

Per risolvere questo problema, completa i seguenti passaggi:

Una volta eseguito il provisioning di un nodo, non è possibile aggiornarlo per abilitare il monitoraggio dell'integrità. Devi creare un nuovo pool di nodi con il monitoraggio dell'integrità abilitato.

  1. Vai alla pagina Cluster Kubernetes nella console Google Cloud .

    Vai ai cluster Kubernetes

  2. Nella sezione Networking, fai clic su Modifica visibilità tra nodi nella riga Visibilità tra nodi.

    Se la configurazione del cluster è stata cambiata di recente, il pulsante di modifica potrebbe essere disabilitato. Se non riesci a modificare le impostazioni del cluster, attendi alcuni minuti e riprova.

  3. Nella finestra di dialogo, seleziona Abilita visibilità tra nodi.

  4. Fai clic su Salva modifiche.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

IP alias disabled

Nome della categoria nell'API: IP_ALIAS_DISABLED

È stato creato un cluster GKE con intervalli IP alias disabilitati.

Quando abiliti gli intervalli IP alias, i cluster GKE allocano indirizzi IP da un blocco CIDR noto, in modo che il cluster sia scalabile e interagisca meglio con prodotti ed entità Google Cloud . Per saperne di più, vedi Panoramica degli intervalli IP alias.

Per risolvere questo problema, completa i seguenti passaggi:

Non puoi eseguire la migrazione di un cluster esistente per utilizzare IP alias. Per creare un nuovo cluster con IP alias abilitati:

  1. Vai alla pagina Cluster Kubernetes nella console Google Cloud .

    Vai ai cluster Kubernetes

  2. Fai clic su Crea.

  3. Nel riquadro di navigazione, in Cluster, fai clic su Networking.

  4. In Opzioni di networking avanzate, seleziona Abilita routing del traffico VPC nativo (mediante IP alias).

  5. Fai clic su Crea.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

IP forwarding enabled

Nome della categoria nell'API: IP_FORWARDING_ENABLED

L'IP forwarding è abilitato sulle istanze Compute Engine.

Impedisci la perdita di dati e la divulgazione di informazioni disattivando l'IP forwarding dei pacchetti di dati per le tue VM.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Istanze VM nella console Google Cloud .

    Vai a Istanze VM

  2. Nell'elenco delle istanze, seleziona la casella accanto al nome dell'istanza nel risultato.

  3. Fai clic su Elimina.

  4. Seleziona Crea istanza per creare una nuova istanza che sostituisca quella che hai eliminato.

  5. Per assicurarti che l'inoltro IP sia disattivato, fai clic su Gestione, dischi, networking, chiavi SSH, quindi fai clic su Networking.

  6. In Interfacce di rete, fai clic su Modifica.

  7. Nella sezione Inoltro IP, assicurati che nel menu a discesa sia selezionata l'opzione Off.

  8. Specifica eventuali altri parametri dell'istanza, poi fai clic su Crea. Per ulteriori informazioni, consulta Creazione e avvio di un'istanza VM.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

KMS key not rotated

Nome della categoria nell'API: KMS_KEY_NOT_ROTATED

La rotazione non è configurata su una chiave di crittografia Cloud KMS.

La rotazione regolare delle chiavi di crittografia fornisce protezione in caso di compromissione di una chiave e limita il numero di messaggi criptati disponibili per la crittoanalisi per una versione specifica della chiave. Per ulteriori informazioni, vedi Rotazione delle chiavi.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Chiavi Cloud KMS nella console Google Cloud .

    Vai alle chiavi Cloud KMS

  2. Fai clic sul nome del keyring indicato nel risultato.

  3. Fai clic sul nome della chiave indicata nel risultato.

  4. Fai clic su Modifica periodo di rotazione.

  5. Imposta il periodo di rotazione su un massimo di 90 giorni.

  6. Fai clic su Salva.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

KMS project has owner

Nome della categoria nell'API: KMS_PROJECT_HAS_OWNER

Un utente dispone delle autorizzazioni roles/Owner per un progetto protetto da chiavi di crittografia. Per maggiori informazioni, vedi Autorizzazioni e ruoli.

Per le attivazioni a livello di progetto del livello Security Command Center Premium, questo risultato è disponibile solo se il livello Standard è abilitato nell'organizzazione principale.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina IAM nella console Google Cloud .

    Vai alla pagina IAM

  2. Se necessario, seleziona il progetto nel risultato.

  3. Per ogni entità a cui è stato assegnato il ruolo Proprietario:

    1. Fai clic su Modifica.
    2. Nel riquadro Modifica autorizzazioni, accanto al ruolo Proprietario, fai clic su Elimina.
    3. Fai clic su Salva.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

KMS public key

Nome della categoria nell'API: KMS_PUBLIC_KEY

Una chiave di crittografia Cloud KMS o un keyring Cloud KMS è pubblico e accessibile a chiunque su internet. Per ulteriori informazioni, consulta Utilizzo di IAM con Cloud KMS.

Per risolvere questo problema, se è correlato a una Cryptokey:

  1. Vai alla pagina Chiavi crittografiche nella console Google Cloud .

    Chiavi crittografiche

  2. In Nome, seleziona le chiavi automatizzate che contengono la chiave crittografica correlata al risultato di Security Health Analytics.

  3. Nella pagina Dettagli portachiavi che viene caricata, seleziona la casella di controllo accanto alla chiave crittografica.

  4. Se il RIQUADRO INFORMAZIONI non è visualizzato, fai clic sul pulsante MOSTRA RIQUADRO INFORMAZIONI.

  5. Utilizza la casella del filtro che precede Ruolo / Entità per cercare le entità allUsers e allAuthenticatedUsers e fai clic su Elimina per rimuovere l'accesso per queste entità.

Per risolvere questo problema, se è correlato a un keyring:

  1. Vai alla pagina Chiavi crittografiche nella console Google Cloud .

    Chiavi crittografiche

  2. Trova la riga con la chiave automatizzata nella ricerca e seleziona la casella di controllo.

  3. Se il RIQUADRO INFORMAZIONI non è visualizzato, fai clic sul pulsante MOSTRA RIQUADRO INFORMAZIONI.

  4. Utilizza la casella del filtro che precede Ruolo / Entità per cercare le entità allUsers e allAuthenticatedUsers e fai clic su Elimina per rimuovere l'accesso per queste entità.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

KMS role separation

Nome della categoria nell'API: KMS_ROLE_SEPARATION

Questo risultato non è disponibile per le attivazioni a livello di progetto.

A una o più entità sono assegnate più autorizzazioni Cloud KMS. Consigliamo di evitare di assegnare autorizzazioni di Amministratore Cloud KMS e altre autorizzazioni Cloud KMS allo stesso account. Per ulteriori informazioni, consulta Autorizzazioni e ruoli.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina IAM nella console Google Cloud .

    Vai a IAM

  2. Per ogni entità elencata nel risultato, procedi nel seguente modo:

    1. Per verificare se il ruolo è stato ereditato da una cartella o una risorsa dell'organizzazione, controlla la colonna Ereditarietà. Se la colonna contiene un link a una risorsa padre, fai clic sul link per accedere alla pagina IAM della risorsa padre.
    2. Fai clic su Modifica accanto a un'entità.
    3. Per rimuovere le autorizzazioni, fai clic su Elimina accanto ad Amministratore Cloud KMS. Se vuoi rimuovere tutte le autorizzazioni per l'entità, fai clic su Elimina accanto a tutte le altre autorizzazioni.

  3. Fai clic su Salva.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Legacy authorization enabled

Nome della categoria nell'API: LEGACY_AUTHORIZATION_ENABLED

L'autorizzazione precedente è abilitata sui cluster GKE.

In Kubernetes, controllo dell'accesso basato sui ruoli (RBAC) consente di definire i ruoli con regole che contengono un set di autorizzazioni, nonché di concedere le autorizzazioni a livello di cluster e spazio dei nomi. Questa funzionalità migliora la sicurezza in quanto gli utenti possono accedere solo a risorse specifiche. Valuta la possibilità di disattivare il controllo dell'controllo dell'accesso basato su attributi (ABAC) legacy.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Cluster Kubernetes nella console Google Cloud .

    Vai ai cluster Kubernetes

  2. Seleziona il cluster elencato nel risultato di Security Health Analytics.

  3. Fai clic su Modifica.

    Se la configurazione del cluster è stata cambiata di recente, il pulsante di modifica potrebbe essere disabilitato. Se non riesci a modificare le impostazioni del cluster, attendi alcuni minuti e poi riprova.

  4. Nell'elenco a discesa Autorizzazione precedente, seleziona Disabilitata.

  5. Fai clic su Salva.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Legacy metadata enabled

Nome della categoria nell'API: LEGACY_METADATA_ENABLED

I metadati legacy sono abilitati sui cluster GKE.

Il server di metadati di istanza di Compute Engine espone gli endpoint legacy /0.1/ e /v1beta1/, che non applicano intestazioni di query di metadati. Questa è una funzionalità delle API /v1/ che rende più difficile per un potenziale utente malintenzionato recuperare i metadati dell'istanza. Se non è obbligatorio, ti consigliamo di disattivare queste API legacy /0.1/ e /v1beta1/.

Per saperne di più, consulta Disattivazione e transizione dalle API di metadati legacy.

Per risolvere questo problema, completa i seguenti passaggi:

Puoi disabilitare le API di metadati legacy solo quando crei un nuovo cluster o quando aggiungi un nuovo pool di nodi a un cluster esistente. Per aggiornare un cluster esistente e disabilitare le API dei metadati legacy, consulta Migrazione dei carichi di lavoro su tipi di macchine diversi.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Legacy network

Nome della categoria nell'API: LEGACY_NETWORK

Esiste una rete legacy in un progetto.

Le reti legacy sono sconsigliate perché non supportano molte delle nuove funzionalità per la sicurezza. Google Cloud Utilizza invece le reti VPC. Per saperne di più, consulta la sezione Reti legacy.

Per le attivazioni a livello di progetto del livello Security Command Center Premium, questo risultato è disponibile solo se il livello Standard è abilitato nell'organizzazione principale.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Reti VPC nella consoleGoogle Cloud .

    Vai a Reti VPC

  2. Per creare una nuova rete non legacy, fai clic su Crea rete.

  3. Torna alla pagina Reti VPC.

  4. Nell'elenco delle reti, fai clic su legacy_network.

  5. Nella pagina Dettagli rete VPC, fai clic su Elimina rete VPC.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Load balancer logging disabled

Nome della categoria nell'API: LOAD_BALANCER_LOGGING_DISABLED

Il logging è disabilitato per il servizio di backend in un bilanciatore del carico.

L'abilitazione del logging per un bilanciatore del carico consente di visualizzare il traffico di rete HTTP(S) per le applicazioni web. Per saperne di più, vedi Bilanciatore del carico.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Cloud Load Balancing nella consoleGoogle Cloud .

    Vai a Cloud Load Balancing

  2. Fai clic sul nome del bilanciatore del carico.

  3. Fai clic su Modifica.

  4. Fai clic su Configurazione backend.

  5. Nella pagina Configurazione backend, fai clic su Modifica.

  6. Nella sezione Logging, seleziona Abilita il logging e scegli la frequenza di campionamento migliore per il progetto.

  7. Per completare la modifica del servizio di backend, fai clic su Aggiorna.

  8. Per completare la modifica del bilanciatore del carico, fai clic su Aggiorna.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Locked retention policy not set

Nome della categoria nell'API: LOCKED_RETENTION_POLICY_NOT_SET

Per i log non è impostata una policy di conservazione bloccata.

Un criterio di conservazione bloccato impedisce la sovrascrittura dei log e l'eliminazione del bucket di log. Per saperne di più, consulta Blocco bucket.

Per le attivazioni a livello di progetto del livello Security Command Center Premium, questo risultato è disponibile solo se il livello Standard è abilitato nell'organizzazione principale.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Browser di archiviazione nella Google Cloud console.

    Vai a Browser di archiviazione

  2. Seleziona il bucket elencato nel risultato di Security Health Analytics.

  3. Nella pagina Dettagli bucket, fai clic sulla scheda Conservazione.

  4. Se non è stata impostata una policy di conservazione, fai clic su Imposta criterio di conservazione.

  5. Inserisci un periodo di conservazione.

  6. Fai clic su Salva. Le norme di conservazione vengono visualizzate nella scheda Conservazione.

  7. Fai clic su Blocca per assicurarti che il periodo di conservazione non venga ridotto o rimosso.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Log not exported

Nome della categoria nell'API: LOG_NOT_EXPORTED

Una risorsa non ha un sink di log appropriato configurato.

Cloud Logging consente di trovare rapidamente la causa principale dei problemi del sistema e delle applicazioni. Tuttavia, per impostazione predefinita, la maggior parte dei log viene conservata solo per 30 giorni. Esporta copie di tutte le voci di log per estendere il periodo di archiviazione. Per ulteriori informazioni, vedi Panoramica delle esportazioni dei log.

Per le attivazioni a livello di progetto del livello Security Command Center Premium, questo risultato è disponibile solo se il livello Standard è abilitato nell'organizzazione principale.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Router dei log nella console Google Cloud .

    Vai al router dei log

  2. Fai clic su Crea sink.

  3. Per garantire che tutti i log vengano esportati, lascia vuoti i filtri di inclusione ed esclusione.

  4. Fai clic su Crea sink.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Master authorized networks disabled

Nome della categoria nell'API: MASTER_AUTHORIZED_NETWORKS_DISABLED

Le reti autorizzate del control plane non sono abilitate sui cluster GKE.

Le reti autorizzate del control plane migliorano la sicurezza del tuo cluster di container impedendo a specifici indirizzi IP di accedere al control plane del cluster. Per maggiori informazioni, consulta Aggiunta di reti autorizzate per l'accesso al control plane.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Cluster Kubernetes nella console Google Cloud .

    Vai ai cluster Kubernetes

  2. Seleziona il cluster elencato nel risultato di Security Health Analytics.

  3. Fai clic su Modifica.

    Se la configurazione del cluster è stata cambiata di recente, il pulsante di modifica potrebbe essere disabilitato. Se non riesci a modificare le impostazioni del cluster, attendi alcuni minuti e riprova.

  4. Nell'elenco a discesa Reti autorizzate del control plane, seleziona Abilitata.

  5. Fai clic su Aggiungi rete autorizzata.

  6. Specifica le reti autorizzate che vuoi utilizzare.

  7. Fai clic su Salva.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

MFA not enforced

Nome della categoria nell'API: MFA_NOT_ENFORCED

Questo risultato non è disponibile per le attivazioni a livello di progetto.

L'autenticazione a più fattori, nello specifico la verifica in due passaggi (V2P), è disabilitata per alcuni utenti nella tua organizzazione.

L'autenticazione a più fattori viene utilizzata per proteggere gli account da accessi non autorizzati ed è lo strumento più importante per proteggere la tua organizzazione contro la compromissione delle credenziali di accesso. Per saperne di più, vedi Proteggere la tua attività con la verifica in due passaggi.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina della Console di amministrazione nella console Google Cloud .

    Vai alla Console di amministrazione

  2. Applica la verifica in due passaggi a tutte le unità organizzative.

Ignora i risultati di questo tipo

Per eliminare i risultati di questo tipo, definisci una regola di disattivazione che disattivi automaticamente i risultati futuri di questo tipo. Per saperne di più, vedi Disattivazione dei risultati in Security Command Center.

Sebbene non sia un modo consigliato per eliminare i risultati, puoi anche aggiungere indicatori di sicurezza dedicati agli asset in modo che i rilevatori di Security Health Analytics non creino risultati di sicurezza per questi asset.

  • Per evitare che questo risultato venga attivato di nuovo, aggiungi il contrassegno di sicurezza allow_mfa_not_enforced con un valore di true all'asset.
  • Per ignorare le potenziali violazioni per unità organizzative specifiche, aggiungi il contrassegno di sicurezzaa excluded_orgunits all'asset con un elenco separato da virgole di percorsi delle unità organizzative nel campo valore. Ad esempio excluded_orgunits:/people/vendors/vendorA,/people/contractors/contractorA.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Network not monitored

Nome della categoria nell'API: NETWORK_NOT_MONITORED

Le metriche di log e gli avvisi non sono configurati per monitorare le modifiche alla rete VPC.

Per rilevare modifiche errate o non autorizzate alla tua configurazione di rete, monitora le modifiche alla rete VPC. Per saperne di più, consulta Panoramica delle metriche basate su log.

A seconda della quantità di informazioni, i costi di Cloud Monitoring possono essere significativi. Per comprendere l'utilizzo del servizio e i relativi costi, consulta Prezzi di Google Cloud Observability.

Per le attivazioni a livello di progetto del livello Security Command Center Premium, questo risultato è disponibile solo se il livello Standard è abilitato nell'organizzazione principale.

Per risolvere questo problema, completa i seguenti passaggi:

Crea metrica

  1. Vai alla pagina Metriche basate su log nella console Google Cloud .

    Vai a Metriche basate su log

  2. Fai clic su Crea metrica.

  3. In Tipo di metrica, seleziona Contatore.

  4. In Dettagli:

    1. Imposta un Nome metrica di log.
    2. Aggiungi una descrizione.
    3. Imposta Unità su 1.

  5. In Selezione dei filtri, copia e incolla il testo seguente nella casella Crea filtro, sostituendo il testo esistente, se necessario: 

      resource.type="gce_network"
  AND (protoPayload.methodName:"compute.networks.insert"
  OR protoPayload.methodName:"compute.networks.patch"
  OR protoPayload.methodName:"compute.networks.delete"
  OR protoPayload.methodName:"compute.networks.removePeering"
  OR protoPayload.methodName:"compute.networks.addPeering")

  6. Fai clic su Crea metrica. Viene visualizzata una conferma.

Crea policy di avviso

  1. Nella console Google Cloud , vai alla pagina Metriche basate su log:

    Vai a Metriche basate su log

    Se utilizzi la barra di ricerca per trovare questa pagina, seleziona il risultato con il sottotitolo Logging.

  2. Nella sezione Metriche definite dall'utente, seleziona la metrica che hai creato nella sezione precedente.

  3. Fai clic su Altro , quindi su Crea avviso da metrica.

    Si apre la finestra di dialogo Nuova condizione con le opzioni di metrica e trasformazione dei dati precompilate.

  4. Fai clic su Avanti.
    1. Rivedi le impostazioni precompilate. Potresti voler modificare il valore di soglia.
    2. Fai clic su Nome condizione e inserisci un nome per la condizione.
  5. Fai clic su Avanti.

  6. Per aggiungere notifiche al tuo criterio di avviso, fai clic su Canali di notifica. Nella finestra di dialogo, seleziona uno o più canali di notifica dal menu e fai clic su Ok.

    Per ricevere una notifica quando gli incidenti vengono aperti e chiusi, seleziona Notifica alla chiusura dell'incidente. Per impostazione predefinita, le notifiche vengono inviate solo quando vengono aperti incidenti.

  7. (Facoltativo) Aggiorna la Durata chiusura automatica incidenti. Questo campo determina quando Monitoring chiude gli incidenti in assenza di dati delle metriche.
  8. (Facoltativo) Fai clic su Documentazione e aggiungi tutte le informazioni che vuoi includere in un messaggio di notifica.
  9. Fai clic su Nome avviso e inserisci un nome per il criterio di avviso.
  10. Fai clic su Crea criterio.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Network policy disabled

Nome della categoria nell'API: NETWORK_POLICY_DISABLED

Il criterio di rete è disabilitato sui cluster GKE.

La comunicazione pod-to-pod è aperta per impostazione predefinita. La comunicazione aperta consente ai pod di connettersi direttamente attraverso i nodi, con o senza Network Address Translation. Una risorsa NetworkPolicy è come un firewall a livello di pod che limita le connessioni tra i pod, a meno che la risorsa NetworkPolicy non consenta esplicitamente la connessione. Scopri come definire un criterio di rete.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Cluster Kubernetes nella console Google Cloud .

    Vai ai cluster Kubernetes

  2. Fai clic sul nome del cluster elencato nel risultato di Security Health Analytics.

  3. In Networking, nella riga Policy di rete di Calico Kubernetes, fai clic su Modifica.

    Se la configurazione del cluster è stata cambiata di recente, il pulsante di modifica potrebbe essere disabilitato. Se non riesci a modificare le impostazioni del cluster, attendi alcuni minuti e riprova.

  4. Nella finestra di dialogo, seleziona Abilita policy di rete di Calico Kubernetes per il control plane e Abilita policy di rete di Calico Kubernetes per i nodi.

  5. Fai clic su Salva modifiche.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Nodepool boot CMEK disabled

Nome della categoria nell'API: NODEPOOL_BOOT_CMEK_DISABLED

I dischi di avvio in questo pool di nodi non sono criptati con chiavi di crittografia gestite dal cliente (CMEK). CMEK consente all'utente di configurare le chiavi di crittografia predefinite per i dischi di avvio in unpool di nodil.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Cluster Kubernetes nella console Google Cloud .

    Vai ai cluster Kubernetes

  2. Nell'elenco dei cluster, fai clic sul nome del cluster nel risultato.

  3. Fai clic sulla scheda Nodi.

  4. Per ogni pool di nodi default-pool, fai clic su Elimina.

  5. Quando ti viene richiesto di confermare, fai clic su Elimina.

  6. Per creare nuovi node pool utilizzando CMEK, consulta Utilizzo delle chiavi di crittografia gestite dal cliente (CMEK). Le chiavi CMEK comportano costi aggiuntivi correlati a Cloud KMS.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Nodepool secure boot disabled

Nome della categoria nell'API: NODEPOOL_SECURE_BOOT_DISABLED

L'avvio protetto è disattivato per un cluster GKE.

Abilita l'avvio protetto per Shielded GKE Nodes per verificare le firme digitali dei componenti di avvio del nodo. Per ulteriori informazioni, vedi Avvio protetto.

Per risolvere questo problema, completa i seguenti passaggi:

Una volta eseguito il provisioning di un node pool, non è possibile aggiornarlo per abilitare l'avvio protetto. Devi creare un nuovo node pool con l'avvio protetto abilitato.

  1. Vai alla pagina Cluster Kubernetes nella console Google Cloud .

    Vai ai cluster Kubernetes

  2. Fai clic sul nome del cluster nel risultato.

  3. Fai clic su Aggiungi pool di nodi.

  4. Nel menu Node pool, procedi nel seguente modo:

    1. Fai clic sul nome del nuovo node pool per espandere la scheda.
    2. Seleziona Sicurezza, quindi, in Opzioni per nodi schermati, seleziona Abilita l'avvio protetto.
    3. Fai clic su Crea.
    4. Per eseguire la migrazione dei workload dai node pool non conformi esistenti ai nuovi node pool, consulta Migrazione dei workload in tipi di macchine diversi.
    5. Dopo aver spostato i workload, elimina il pool di nodi non conforme originale.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Non org IAM member

Nome della categoria nell'API: NON_ORG_IAM_MEMBER

Un utente esterno all'organizzazione o al progetto dispone di autorizzazioni IAM su un progetto o un'organizzazione. Scopri di più sulle autorizzazioni IAM.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina IAM nella console Google Cloud .

    Vai a IAM

  2. Seleziona la casella di controllo accanto agli utenti esterni all'organizzazione o al progetto.

  3. Fai clic su Rimuovi.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Object versioning disabled

Nome della categoria nell'API: OBJECT_VERSIONING_DISABLED

Il controllo delle versioni degli oggetti non è abilitato in un bucket di archiviazione in cui sono configurati i sink.

Per supportare il recupero di oggetti eliminati o sovrascritti, Cloud Storage offre la funzionalità di controllo delle versioni degli oggetti. Abilita il controllo delle versioni degli oggetti per proteggere i dati di Cloud Storage dalla sovrascrittura o eliminazione accidentale. Scopri come attivare il controllo delle versioni degli oggetti.

Per le attivazioni a livello di progetto del livello Security Command Center Premium, questo risultato è disponibile solo se il livello Standard è abilitato nell'organizzazione principale.

Per risolvere questo problema, utilizza il flag --versioning in un comando gcloud storage buckets update con il valore appropriato:

    gcloud storage buckets update gs://finding.assetDisplayName --versioning

Sostituisci finding.assetDisplayName con il nome del bucket pertinente.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Open Cassandra port

Nome della categoria nell'API: OPEN_CASSANDRA_PORT

Le regole firewall che autorizzano qualsiasi indirizzo IP a connettersi alle porte Cassandra potrebbero esporre i tuoi servizi Cassandra a utenti malintenzionati. Per saperne di più, consulta la Panoramica delle regole firewall VPC.

Le porte del servizio Cassandra sono:

  • TCP - 7000, 7001, 7199, 8888, 9042, 9160, 61620, 61621

Questo risultato viene generato per le regole firewall vulnerabili, anche se le disattivi intenzionalmente. I risultati attivi per le regole firewall disattivate ti avvisano di configurazioni non sicure che consentiranno il traffico indesiderato se abilitate.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Firewall nella console Google Cloud .

    Vai a Firewall

  2. Nell'elenco delle regole firewall, fai clic sul nome della regola firewall nel risultato.

  3. Fai clic su Modifica.

  4. In Intervalli IP di origine, elimina 0.0.0.0/0.

  5. Aggiungi indirizzi IP o intervalli di indirizzi IP specifici che vuoi autorizzare a connettersi all'istanza.

  6. Aggiungi i protocolli specifici e le porte che vuoi aprire sull'istanza.

  7. Fai clic su Salva.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Open ciscosecure websm port

Nome della categoria nell'API: OPEN_CISCOSECURE_WEBSM_PORT

Le regole firewall che autorizzano qualsiasi indirizzo IP a connettersi alle porte CiscoSecure/WebSM potrebbero esporre i tuoi servizi CiscoSecure/WebSM a utenti malintenzionati. Per saperne di più, consulta la Panoramica delle regole firewall VPC.

Le porte del servizio CiscoSecure/WebSM sono:

  • TCP - 9090

Questo risultato viene generato per le regole firewall vulnerabili, anche se le disattivi intenzionalmente. I risultati attivi per le regole firewall disattivate ti avvisano di configurazioni non sicure che consentiranno il traffico indesiderato se abilitate.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Firewall nella console Google Cloud .

    Vai a Firewall

  2. Nell'elenco delle regole firewall, fai clic sul nome della regola firewall nel risultato.

  3. Fai clic su Modifica.

  4. In Intervalli IP di origine, elimina 0.0.0.0/0.

  5. Aggiungi indirizzi IP o intervalli di indirizzi IP specifici che vuoi autorizzare a connettersi all'istanza.

  6. Aggiungi i protocolli specifici e le porte che vuoi aprire sull'istanza.

  7. Fai clic su Salva.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Open directory services port

Nome della categoria nell'API: OPEN_DIRECTORY_SERVICES_PORT

Le regole firewall che autorizzano qualsiasi indirizzo IP a connettersi alle porte della directory potrebbero esporre i tuoi servizi di directory a utenti malintenzionati. Per saperne di più, consulta la Panoramica delle regole firewall VPC.

Le porte del servizio di directory sono:

  • TCP - 445
  • UDP - 445

Questo risultato viene generato per le regole firewall vulnerabili, anche se le disattivi intenzionalmente. I risultati attivi per le regole firewall disattivate ti avvisano di configurazioni non sicure che consentiranno il traffico indesiderato se abilitate.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Firewall nella console Google Cloud .

    Vai a Firewall

  2. Nell'elenco delle regole firewall, fai clic sul nome della regola firewall nel risultato.

  3. Fai clic su Modifica.

  4. In Intervalli IP di origine, elimina 0.0.0.0/0.

  5. Aggiungi indirizzi IP o intervalli di indirizzi IP specifici che vuoi autorizzare a connettersi all'istanza.

  6. Aggiungi i protocolli specifici e le porte che vuoi aprire sull'istanza.

  7. Fai clic su Salva.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Open DNS port

Nome della categoria nell'API: OPEN_DNS_PORT

Le regole firewall che autorizzano qualsiasi indirizzo IP a connettersi alle porte DNS potrebbero esporre i tuoi servizi DNS a utenti malintenzionati. Per saperne di più, consulta la Panoramica delle regole firewall VPC.

Le porte del servizio DNS sono:

  • TCP - 53
  • UDP - 53

Questo risultato viene generato per le regole firewall vulnerabili, anche se le disattivi intenzionalmente. I risultati attivi per le regole firewall disattivate ti avvisano di configurazioni non sicure che consentiranno il traffico indesiderato se abilitate.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Firewall nella console Google Cloud .

    Vai a Firewall

  2. Nell'elenco delle regole firewall, fai clic sul nome della regola firewall nel risultato.

  3. Fai clic su Modifica.

  4. In Intervalli IP di origine, elimina 0.0.0.0/0.

  5. Aggiungi indirizzi IP o intervalli di indirizzi IP specifici che vuoi autorizzare a connettersi all'istanza.

  6. Aggiungi i protocolli specifici e le porte che vuoi aprire sull'istanza.

  7. Fai clic su Salva.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Open Elasticsearch port

Nome della categoria nell'API: OPEN_ELASTICSEARCH_PORT

Le regole firewall che autorizzano qualsiasi indirizzo IP a connettersi alle porte Elasticsearch potrebbero esporre i tuoi servizi Elasticsearch a utenti malintenzionati. Per saperne di più, consulta la Panoramica delle regole firewall VPC.

Le porte del servizio Elasticsearch sono:

  • TCP - 9200, 9300

Questo risultato viene generato per le regole firewall vulnerabili, anche se le disattivi intenzionalmente. I risultati attivi per le regole firewall disattivate ti avvisano di configurazioni non sicure che consentiranno il traffico indesiderato se abilitate.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Firewall nella console Google Cloud .

    Vai a Firewall

  2. Nell'elenco delle regole firewall, fai clic sul nome della regola firewall nel risultato.

  3. Fai clic su Modifica.

  4. In Intervalli IP di origine, elimina 0.0.0.0/0.

  5. Aggiungi indirizzi IP o intervalli di indirizzi IP specifici che vuoi autorizzare a connettersi all'istanza.

  6. Aggiungi i protocolli specifici e le porte che vuoi aprire sull'istanza.

  7. Fai clic su Salva.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Open firewall

Nome della categoria nell'API: OPEN_FIREWALL

Le regole firewall che consentono le connessioni da tutti gli indirizzi IP, ad esempio 0.0.0.0/0, o da tutte le porte potrebbero esporre inutilmente le risorse ad attacchi provenienti da origini indesiderate. Queste regole dovrebbero essere rimosse o esplicitamente ristrette agli intervalli IP di origine o alle porte che ti interessano. Ad esempio, nelle applicazioni destinate a essere pubbliche, valuta la possibilità di limitare le porte consentite a quelle necessarie per l'applicazione, come 80 e 443. Se la tua applicazione deve consentire connessioni da tutti gli indirizzi IP o dalle porte, valuta la possibilità di aggiungere l'asset a una lista consentita. Scopri di più sull'aggiornamento delle regole firewall.

Questo risultato viene generato per le regole firewall vulnerabili, anche se le disattivi intenzionalmente. I risultati attivi per le regole firewall disattivate ti avvisano di configurazioni non sicure che consentiranno il traffico indesiderato se abilitate.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Regole firewall nella console Google Cloud .

    Vai a Regole firewall

  2. Fai clic sulla regola firewall elencata nel risultato di Security Health Analytics e poi fai clic su Modifica.

  3. In Intervalli IP di origine, modifica i valori IP per limitare l'intervallo degli IP consentiti.

  4. In Protocolli e porte, seleziona Protocolli e porte specificati, seleziona i protocolli consentiti e inserisci le porte consentite.

  5. Fai clic su Salva.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Open FTP port

Nome della categoria nell'API: OPEN_FTP_PORT

Le regole firewall che autorizzano qualsiasi indirizzo IP a connettersi alle porte FTP potrebbero esporre i tuoi servizi FTP a utenti malintenzionati. Per saperne di più, consulta la Panoramica delle regole firewall VPC.

Le porte del servizio FTP sono:

  • TCP - 21

Questo risultato viene generato per le regole firewall vulnerabili, anche se le disattivi intenzionalmente. I risultati attivi per le regole firewall disattivate ti avvisano di configurazioni non sicure che consentiranno il traffico indesiderato se abilitate.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Firewall nella console Google Cloud .

    Vai a Firewall

  2. Nell'elenco delle regole firewall, fai clic sul nome della regola firewall nel risultato.

  3. Fai clic su Modifica.

  4. In Intervalli IP di origine, elimina 0.0.0.0/0.

  5. Aggiungi indirizzi IP o intervalli di indirizzi IP specifici che vuoi autorizzare a connettersi all'istanza.

  6. Aggiungi i protocolli specifici e le porte che vuoi aprire sull'istanza.

  7. Fai clic su Salva.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Open group IAM member

Nome della categoria nell'API: OPEN_GROUP_IAM_MEMBER

Una o più entità che hanno accesso a un'organizzazione, un progetto o una cartella sono account Google Gruppi a cui è possibile partecipare senza approvazione.

I clienti diGoogle Cloud possono utilizzare Google Gruppi per gestire ruoli e autorizzazioni per i membri delle loro organizzazioni o applicare criteri di accesso a raccolte di utenti. Anziché concedere ruoli direttamente ai membri, gli amministratori possono concedere ruoli e autorizzazioni ai gruppi Google e poi aggiungere i membri a gruppi specifici. I membri del gruppo ereditano tutti i ruoli e le autorizzazioni di un gruppo, il che consente loro di accedere a servizi e risorse specifici.

Se un account Google Gruppi aperto viene utilizzato come entità in un'associazione IAM, chiunque può ereditare il ruolo associato semplicemente entrando a far parte del gruppo direttamente o indirettamente (tramite un sottogruppo). Ti consigliamo di revocare i ruoli dei gruppi aperti o di limitare l'accesso a questi gruppi.

Per risolvere questo problema, esegui una delle seguenti procedure.

Rimuovi il gruppo dalla policy IAM

  1. Vai alla pagina IAM nella console Google Cloud .

    Vai a IAM

  2. Se necessario, seleziona il progetto, la cartella o l'organizzazione nel risultato.

  3. Revoca il ruolo di ogni gruppo aperto identificato nel risultato.

Limitare l'accesso ai gruppi aperti

  1. Accedi a Google Gruppi.
  2. Aggiorna le impostazioni di ogni gruppo aperto e dei relativi sottogruppi per specificare chi può iscriversi al gruppo e chi deve approvarlo.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Open HTTP port

Nome della categoria nell'API: OPEN_HTTP_PORT

Le regole firewall che autorizzano qualsiasi indirizzo IP a connettersi alle porte HTTP potrebbero esporre i tuoi servizi HTTP a utenti malintenzionati. Per saperne di più, consulta la Panoramica delle regole firewall VPC.

Le porte del servizio HTTP sono:

  • TCP - 80

Questo risultato viene generato per le regole firewall vulnerabili, anche se le disattivi intenzionalmente. I risultati attivi per le regole firewall disattivate ti avvisano di configurazioni non sicure che consentiranno il traffico indesiderato se abilitate.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Firewall nella console Google Cloud .

    Vai a Firewall

  2. Nell'elenco delle regole firewall, fai clic sul nome della regola firewall nel risultato.

  3. Fai clic su Modifica.

  4. In Intervalli IP di origine, elimina 0.0.0.0/0.

  5. Aggiungi indirizzi IP o intervalli di indirizzi IP specifici che vuoi autorizzare a connettersi all'istanza.

  6. Aggiungi i protocolli specifici e le porte che vuoi aprire sull'istanza.

  7. Fai clic su Salva.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Open LDAP port

Nome della categoria nell'API: OPEN_LDAP_PORT

Le regole firewall che autorizzano qualsiasi indirizzo IP a connettersi alle porte LDAP potrebbero esporre i tuoi servizi LDAP a utenti malintenzionati. Per saperne di più, consulta la Panoramica delle regole firewall VPC.

Le porte del servizio LDAP sono:

  • TCP - 389, 636
  • UDP - 389

Questo risultato viene generato per le regole firewall vulnerabili, anche se le disattivi intenzionalmente. I risultati attivi per le regole firewall disattivate ti avvisano di configurazioni non sicure che consentiranno il traffico indesiderato se abilitate.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Firewall nella console Google Cloud .

    Vai a Firewall

  2. Nell'elenco delle regole firewall, fai clic sul nome della regola firewall nel risultato.

  3. Fai clic su Modifica.

  4. In Intervalli IP di origine, elimina 0.0.0.0/0.

  5. Aggiungi indirizzi IP o intervalli di indirizzi IP specifici che vuoi autorizzare a connettersi all'istanza.

  6. Aggiungi i protocolli specifici e le porte che vuoi aprire sull'istanza.

  7. Fai clic su Salva.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Open Memcached port

Nome della categoria nell'API: OPEN_MEMCACHED_PORT

Le regole firewall che autorizzano qualsiasi indirizzo IP a connettersi alle porte Memcached potrebbero esporre i tuoi servizi Memcached a utenti malintenzionati. Per saperne di più, consulta la Panoramica delle regole firewall VPC.

Le porte del servizio Memcached sono:

  • TCP - 11211, 11214, 11215
  • UDP - 11211, 11214, 11215

Questo risultato viene generato per le regole firewall vulnerabili, anche se le disattivi intenzionalmente. I risultati attivi per le regole firewall disattivate ti avvisano di configurazioni non sicure che consentiranno il traffico indesiderato se abilitate.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Firewall nella console Google Cloud .

    Vai a Firewall

  2. Nell'elenco delle regole firewall, fai clic sul nome della regola firewall nel risultato.

  3. Fai clic su Modifica.

  4. In Intervalli IP di origine, elimina 0.0.0.0/0.

  5. Aggiungi indirizzi IP o intervalli di indirizzi IP specifici che vuoi autorizzare a connettersi all'istanza.

  6. Aggiungi i protocolli specifici e le porte che vuoi aprire sull'istanza.

  7. Fai clic su Salva.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Open MongoDB port

Nome della categoria nell'API: OPEN_MONGODB_PORT

Le regole firewall che autorizzano qualsiasi indirizzo IP a connettersi alle porte MongoDB potrebbero esporre i tuoi servizi MongoDB a utenti malintenzionati. Per saperne di più, consulta la Panoramica delle regole firewall VPC.

Le porte del servizio MongoDB sono:

  • TCP - 27017, 27018, 27019

Questo risultato viene generato per le regole firewall vulnerabili, anche se le disattivi intenzionalmente. I risultati attivi per le regole firewall disattivate ti avvisano di configurazioni non sicure che consentiranno il traffico indesiderato se abilitate.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Firewall nella console Google Cloud .

    Vai a Firewall

  2. Nell'elenco delle regole firewall, fai clic sul nome della regola firewall nel risultato.

  3. Fai clic su Modifica.

  4. In Intervalli IP di origine, elimina 0.0.0.0/0.

  5. Aggiungi indirizzi IP o intervalli di indirizzi IP specifici che vuoi autorizzare a connettersi all'istanza.

  6. Aggiungi i protocolli specifici e le porte che vuoi aprire sull'istanza.

  7. Fai clic su Salva.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Open MySQL port

Nome della categoria nell'API: OPEN_MYSQL_PORT

Le regole firewall che autorizzano qualsiasi indirizzo IP a connettersi alle porte MySQL potrebbero esporre i tuoi servizi MySQL a utenti malintenzionati. Per saperne di più, consulta la Panoramica delle regole firewall VPC.

Le porte del servizio MySQL sono:

  • TCP - 3306

Questo risultato viene generato per le regole firewall vulnerabili, anche se le disattivi intenzionalmente. I risultati attivi per le regole firewall disattivate ti avvisano di configurazioni non sicure che consentiranno il traffico indesiderato se abilitate.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Firewall nella console Google Cloud .

    Vai a Firewall

  2. Nell'elenco delle regole firewall, fai clic sul nome della regola firewall nel risultato.

  3. Fai clic su Modifica.

  4. In Intervalli IP di origine, elimina 0.0.0.0/0.

  5. Aggiungi indirizzi IP o intervalli di indirizzi IP specifici che vuoi autorizzare a connettersi all'istanza.

  6. Aggiungi i protocolli specifici e le porte che vuoi aprire sull'istanza.

  7. Fai clic su Salva.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Open NetBIOS port

Nome della categoria nell'API: `OPEN_NETBIOS_PORT

Le regole firewall che autorizzano qualsiasi indirizzo IP a connettersi alle porte NetBIOS potrebbero esporre i tuoi servizi NetBIOS a utenti malintenzionati. Per saperne di più, consulta la Panoramica delle regole firewall VPC.

Le porte del servizio NetBIOS sono:

  • TCP - 137, 138, 139
  • UDP - 137, 138, 139

Questo risultato viene generato per le regole firewall vulnerabili, anche se le disattivi intenzionalmente. I risultati attivi per le regole firewall disattivate ti avvisano di configurazioni non sicure che consentiranno il traffico indesiderato se abilitate.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Firewall nella console Google Cloud .

    Vai a Firewall

  2. Nell'elenco delle regole firewall, fai clic sul nome della regola firewall nel risultato.

  3. Fai clic su Modifica.

  4. In Intervalli IP di origine, elimina 0.0.0.0/0.

  5. Aggiungi indirizzi IP o intervalli di indirizzi IP specifici che vuoi autorizzare a connettersi all'istanza.

  6. Aggiungi i protocolli specifici e le porte che vuoi aprire sull'istanza.

  7. Fai clic su Salva.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Open OracleDB port

Nome della categoria nell'API: OPEN_ORACLEDB_PORT

Le regole firewall che autorizzano qualsiasi indirizzo IP a connettersi alle porte OracleDB potrebbero esporre i tuoi servizi OracleDB a utenti malintenzionati. Per saperne di più, consulta la Panoramica delle regole firewall VPC.

Le porte del servizio OracleDB sono:

  • TCP - 1521, 2483, 2484
  • UDP - 2483, 2484

Questo risultato viene generato per le regole firewall vulnerabili, anche se le disattivi intenzionalmente. I risultati attivi per le regole firewall disattivate ti avvisano di configurazioni non sicure che consentiranno il traffico indesiderato se abilitate.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Firewall nella console Google Cloud .

    Vai a Firewall

  2. Nell'elenco delle regole firewall, fai clic sul nome della regola firewall nel risultato.

  3. Fai clic su Modifica.

  4. In Intervalli IP di origine, elimina 0.0.0.0/0.

  5. Aggiungi indirizzi IP o intervalli di indirizzi IP specifici che vuoi autorizzare a connettersi all'istanza.

  6. Aggiungi i protocolli specifici e le porte che vuoi aprire sull'istanza.

  7. Fai clic su Salva.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Open POP3 port

Nome della categoria nell'API: OPEN_POP3_PORT

Le regole firewall che autorizzano qualsiasi indirizzo IP a connettersi alle porte POP3 potrebbero esporre i tuoi servizi POP3 a utenti malintenzionati. Per saperne di più, consulta la Panoramica delle regole firewall VPC.

Le porte del servizio POP3 sono:

  • TCP - 110

Questo risultato viene generato per le regole firewall vulnerabili, anche se le disattivi intenzionalmente. I risultati attivi per le regole firewall disattivate ti avvisano di configurazioni non sicure che consentiranno il traffico indesiderato se abilitate.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Firewall nella console Google Cloud .

    Vai a Firewall

  2. Nell'elenco delle regole firewall, fai clic sul nome della regola firewall nel risultato.

  3. Fai clic su Modifica.

  4. In Intervalli IP di origine, elimina 0.0.0.0/0.

  5. Aggiungi indirizzi IP o intervalli di indirizzi IP specifici che vuoi autorizzare a connettersi all'istanza.

  6. Aggiungi i protocolli specifici e le porte che vuoi aprire sull'istanza.

  7. Fai clic su Salva.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Open PostgreSQL port

Nome della categoria nell'API: OPEN_POSTGRESQL_PORT

Le regole firewall che autorizzano qualsiasi indirizzo IP a connettersi alle porte PostgreSQL potrebbero esporre i tuoi servizi PostgreSQL a utenti malintenzionati. Per saperne di più, consulta la Panoramica delle regole firewall VPC.

Le porte del servizio PostgreSQL sono:

  • TCP - 5432
  • UDP - 5432

Questo risultato viene generato per le regole firewall vulnerabili, anche se le disattivi intenzionalmente. I risultati attivi per le regole firewall disattivate ti avvisano di configurazioni non sicure che consentiranno il traffico indesiderato se abilitate.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Firewall nella console Google Cloud .

    Vai a Firewall

  2. Nell'elenco delle regole firewall, fai clic sul nome della regola firewall nel risultato.

  3. Fai clic su Modifica.

  4. In Intervalli IP di origine, elimina 0.0.0.0/0.

  5. Aggiungi indirizzi IP o intervalli di indirizzi IP specifici che vuoi autorizzare a connettersi all'istanza.

  6. Aggiungi i protocolli specifici e le porte che vuoi aprire sull'istanza.

  7. Fai clic su Salva.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Open RDP port

Nome della categoria nell'API: OPEN_RDP_PORT

Le regole firewall che autorizzano qualsiasi indirizzo IP a connettersi alle porte RDP potrebbero esporre i tuoi servizi RDP a utenti malintenzionati. Per saperne di più, consulta la Panoramica delle regole firewall VPC.

Le porte del servizio RDP sono:

  • TCP - 3389
  • UDP - 3389

Questo risultato viene generato per le regole firewall vulnerabili, anche se le disattivi intenzionalmente. I risultati attivi per le regole firewall disattivate ti avvisano di configurazioni non sicure che consentiranno il traffico indesiderato se abilitate.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Firewall nella console Google Cloud .

    Vai a Firewall

  2. Nell'elenco delle regole firewall, fai clic sul nome della regola firewall nel risultato.

  3. Fai clic su Modifica.

  4. In Intervalli IP di origine, elimina 0.0.0.0/0.

  5. Aggiungi indirizzi IP o intervalli di indirizzi IP specifici che vuoi autorizzare a connettersi all'istanza.

  6. Aggiungi i protocolli specifici e le porte che vuoi aprire sull'istanza.

  7. Fai clic su Salva.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Open Redis port

Nome della categoria nell'API: OPEN_REDIS_PORT

Le regole firewall che autorizzano qualsiasi indirizzo IP a connettersi alle porte Redis potrebbero esporre i tuoi servizi Redis a utenti malintenzionati. Per saperne di più, consulta la Panoramica delle regole firewall VPC.

Le porte del servizio Redis sono:

  • TCP - 6379

Questo risultato viene generato per le regole firewall vulnerabili, anche se le disattivi intenzionalmente. I risultati attivi per le regole firewall disattivate ti avvisano di configurazioni non sicure che consentiranno il traffico indesiderato se abilitate.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Firewall nella console Google Cloud .

    Vai a Firewall

  2. Nell'elenco delle regole firewall, fai clic sul nome della regola firewall nel risultato.

  3. Fai clic su Modifica.

  4. In Intervalli IP di origine, elimina 0.0.0.0/0.

  5. Aggiungi indirizzi IP o intervalli di indirizzi IP specifici che vuoi autorizzare a connettersi all'istanza.

  6. Aggiungi i protocolli specifici e le porte che vuoi aprire sull'istanza.

  7. Fai clic su Salva.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Open SMTP port

Nome della categoria nell'API: OPEN_SMTP_PORT

Le regole firewall che autorizzano qualsiasi indirizzo IP a connettersi alle porte SMTP potrebbero esporre i tuoi servizi SMTP a utenti malintenzionati. Per saperne di più, consulta la Panoramica delle regole firewall VPC.

Le porte del servizio SMTP sono:

  • TCP - 25

Questo risultato viene generato per le regole firewall vulnerabili, anche se le disattivi intenzionalmente. I risultati attivi per le regole firewall disattivate ti avvisano di configurazioni non sicure che consentiranno il traffico indesiderato se abilitate.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Firewall nella console Google Cloud .

    Vai a Firewall

  2. Nell'elenco delle regole firewall, fai clic sul nome della regola firewall nel risultato.

  3. Fai clic su Modifica.

  4. In Intervalli IP di origine, elimina 0.0.0.0/0.

  5. Aggiungi indirizzi IP o intervalli di indirizzi IP specifici che vuoi autorizzare a connettersi all'istanza.

  6. Aggiungi i protocolli specifici e le porte che vuoi aprire sull'istanza.

  7. Fai clic su Salva.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Open SSH port

Nome della categoria nell'API: OPEN_SSH_PORT

Le regole firewall che autorizzano qualsiasi indirizzo IP a connettersi alle porte SSH potrebbero esporre i tuoi servizi SSH a utenti malintenzionati. Per saperne di più, consulta la Panoramica delle regole firewall VPC.

Le porte del servizio SSH sono:

  • SCTP - 22
  • TCP - 22

Questo risultato viene generato per le regole firewall vulnerabili, anche se le disattivi intenzionalmente. I risultati attivi per le regole firewall disattivate ti avvisano di configurazioni non sicure che consentiranno il traffico indesiderato se abilitate.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Firewall nella console Google Cloud .

    Vai a Firewall

  2. Nell'elenco delle regole firewall, fai clic sul nome della regola firewall nel risultato.

  3. Fai clic su Modifica.

  4. In Intervalli IP di origine, elimina 0.0.0.0/0.

  5. Aggiungi indirizzi IP o intervalli di indirizzi IP specifici che vuoi autorizzare a connettersi all'istanza.

  6. Aggiungi i protocolli specifici e le porte che vuoi aprire sull'istanza.

  7. Fai clic su Salva.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Open Telnet port

Nome della categoria nell'API: OPEN_TELNET_PORT

Le regole firewall che autorizzano qualsiasi indirizzo IP a connettersi alle porte Telnet potrebbero esporre i tuoi servizi Telnet a utenti malintenzionati. Per saperne di più, consulta la Panoramica delle regole firewall VPC.

Le porte del servizio Telnet sono:

  • TCP - 23

Questo risultato viene generato per le regole firewall vulnerabili, anche se le disattivi intenzionalmente. I risultati attivi per le regole firewall disattivate ti avvisano di configurazioni non sicure che consentiranno il traffico indesiderato se abilitate.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Firewall nella console Google Cloud .

    Vai a Firewall

  2. Nell'elenco delle regole firewall, fai clic sul nome della regola firewall nel risultato.

  3. Fai clic su Modifica.

  4. In Intervalli IP di origine, elimina 0.0.0.0/0.

  5. Aggiungi indirizzi IP o intervalli di indirizzi IP specifici che vuoi autorizzare a connettersi all'istanza.

  6. Aggiungi i protocolli specifici e le porte che vuoi aprire sull'istanza.

  7. Fai clic su Salva.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Org policy Confidential VM policy

Nome della categoria nell'API: ORG_POLICY_CONFIDENTIAL_VM_POLICY

Una risorsa Compute Engine non è conforme ai criteri dell'organizzazione constraints/compute.restrictNonConfidentialComputing. Per saperne di più su questo vincolo delle policy dell'organizzazione, consulta Applicazione dei vincoli delle policy dell'organizzazione.

La tua organizzazione richiede che questa VM abbia il servizio Confidential VM abilitato. Le VM per cui questo servizio non è abilitato non utilizzeranno la crittografia della memoria di runtime, saranno pertanto esposte ad attacchi alla memoria di runtime.

Per le attivazioni a livello di progetto del livello Security Command Center Premium, questo risultato è disponibile solo se il livello Standard è abilitato nell'organizzazione principale.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Istanze VM nella console Google Cloud .

    Vai a Istanze VM

  2. Nell'elenco delle istanze, fai clic sul nome dell'istanza nel risultato.

  3. Se la VM non richiede il servizio Confidential VM, spostala in una cartella o in un progetto nuovi.

  4. Se la VM richiede Confidential VM, fai clic su Elimina.

  5. Per creare una nuova istanza con Confidential VM abilitata, consulta la guida rapida: creazione di un'istanza Confidential VM.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Org policy location restriction

Nome della categoria nell'API: ORG_POLICY_LOCATION_RESTRICTION

Il vincolo gcp.resourceLocations dei criteri dell'organizzazione consente di limitare la creazione di nuove risorse alle regioni cloud selezionate. Per ulteriori informazioni, consulta Limitazione delle località delle risorse.

Per le attivazioni a livello di progetto del livello Security Command Center Premium, questo risultato è disponibile solo se il livello Standard è abilitato nell'organizzazione principale.

Per risolvere questo problema, completa i seguenti passaggi:

Il rilevatore ORG_POLICY_LOCATION_RESTRICTION copre molti tipi di risorse e le istruzioni di correzione sono diverse per ogni risorsa. L'approccio generale per correggere le violazioni della posizione include quanto segue:

  1. Copia, sposta o esegui il backup della risorsa fuori regione o dei relativi dati in una risorsa che si trova nella regione. Leggi la documentazione dei singoli servizi per ricevere istruzioni sullo spostamento delle risorse.
  2. Elimina la risorsa originale al di fuori della regione o i relativi dati.

Questo approccio non è possibile per tutti i tipi di risorse. Per indicazioni, consulta i consigli personalizzati forniti nel risultato.

Ulteriori considerazioni

Quando correggi questo problema, considera quanto segue.

Risorse gestite

I cicli di vita delle risorse a volte sono gestiti e controllati da altre risorse. Ad esempio, un gruppo di istanze gestite Compute Engine crea ed elimina istanze Compute Engine in base al criterio di scalabilità automatica del gruppo di istanze. Se le risorse gestite e di gestione rientrano nell'ambito dell'applicazione della località, entrambe potrebbero essere segnalate come violazione del criterio dell'organizzazione. La correzione dei risultati per le risorse gestite deve essere eseguita sulla risorsa di gestione per garantire la stabilità operativa.

Risorse in uso

Alcune risorse vengono utilizzate da altre risorse. Ad esempio, un disco Compute Engine collegato a un'istanza Compute Engine in esecuzione è considerato in uso dall'istanza. Se la risorsa in uso viola il criterio dell'organizzazione relativo alla località, devi assicurarti che la risorsa non sia in uso prima di risolvere la violazione della località.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

OS login disabled

Nome della categoria nell'API: OS_LOGIN_DISABLED

L'OS Login è disabilitato sulle istanze Compute Engine in questo progetto.

OS Login consente la gestione centralizzata delle chiavi SSH con IAM e disattiva la configurazione delle chiavi SSH basata su metadati in tutte le istanze di un progetto. Scopri come configurare l'accesso OS.

Per le attivazioni a livello di progetto del livello Security Command Center Premium, questo risultato è disponibile solo se il livello Standard è abilitato nell'organizzazione principale.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Metadati nella console Google Cloud .

    Vai a Metadati

  2. Fai clic prima su Modifica e poi su Aggiungi elemento.

  3. Aggiungi un elemento con chiave enable-oslogin e valore TRUE.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Over privileged account

Nome della categoria nell'API: OVER_PRIVILEGED_ACCOUNT

Un nodo GKE utilizza il nodo di servizio predefinito di Compute Engine, che dispone di un accesso esteso per impostazione predefinita e potrebbe disporre di privilegi in eccesso per l'esecuzione del tuo cluster GKE.

Per risolvere questo problema, completa i seguenti passaggi:

Segui le istruzioni per utilizzare i service account Google con privilegio minimo minimi.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Over privileged scopes

Nome della categoria nell'API: OVER_PRIVILEGED_SCOPES

Un account di servizio del nodo ha ambiti di accesso ampi.

Gli ambiti di accesso sono il metodo legacy per specificare le autorizzazioni per l'istanza. Per ridurre la possibilità di una escalation dei privilegi in un attacco, crea e utilizza un account di servizio con privilegi minimi per eseguire il cluster GKE.

Per risolvere questo problema, segui le istruzioni per utilizzare i service account Google con privilegio minimo minimi.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Over privileged service account user

Nome della categoria nell'API: OVER_PRIVILEGED_SERVICE_ACCOUNT_USER

Un utente dispone dei ruoli iam.serviceAccountUser o iam.serviceAccountTokenCreator a livello di progetto, cartella o organizzazione, anziché per un account di servizio specifico.

La concessione di questi ruoli a un utente per un progetto, una cartella o un'organizzazione consente all'utente di accedere a tutti i service account esistenti e futuri in questo ambito. Questa situazione può comportare un'escalation involontaria dei privilegi. Per ulteriori informazioni, consulta Autorizzazioni dei service account.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina IAM nella console Google Cloud .

    Vai alla pagina IAM

  2. Se necessario, seleziona il progetto, la cartella o l'organizzazione nel risultato.

  3. Per ogni entità a cui è assegnato roles/iam.serviceAccountUser o roles/iam.serviceAccountTokenCreator, procedi nel seguente modo:

    1. Fai clic su Modifica.
    2. Nel riquadro Modifica autorizzazioni, fai clic su Elimina accanto ai ruoli.
    3. Fai clic su Salva.

  4. Segui questa guida per concedere ai singoli utenti l'autorizzazione a impersonare un solo service account. Devi seguire la guida per ogni account di servizio per cui vuoi autorizzare la simulazione dell'identità da parte di utenti selezionati.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Owner not monitored

Nome della categoria nell'API: OWNER_NOT_MONITORED

Le metriche e gli avvisi di log non sono configurati per monitorare le assegnazioni o le modifiche alla proprietà del progetto.

Il ruolo IAM Proprietario ha il livello di privilegio più elevato per un progetto. Per proteggere le tue risorse, configura gli avvisi per ricevere notifiche quando vengono aggiunti o rimossi nuovi proprietari. Per ulteriori informazioni, consulta la panoramica delle metriche basate su log.

A seconda della quantità di informazioni, i costi di Cloud Monitoring possono essere significativi. Per comprendere l'utilizzo del servizio e i relativi costi, consulta Prezzi di Google Cloud Observability.

Per le attivazioni a livello di progetto del livello Security Command Center Premium, questo risultato è disponibile solo se il livello Standard è abilitato nell'organizzazione principale.

Per risolvere questo problema, completa i seguenti passaggi:

Crea metrica

  1. Vai alla pagina Metriche basate su log nella console Google Cloud .

    Vai a Metriche basate su log

  2. Fai clic su Crea metrica.

  3. In Tipo di metrica, seleziona Contatore.

  4. In Dettagli:

    1. Imposta un Nome metrica di log.
    2. Aggiungi una descrizione.
    3. Imposta Unità su 1.

  5. In Selezione dei filtri, copia e incolla il testo seguente nella casella Crea filtro, sostituendo il testo esistente, se necessario: 

      (protoPayload.serviceName="cloudresourcemanager.googleapis.com")
  AND (ProjectOwnership OR projectOwnerInvitee)
  OR (protoPayload.serviceData.policyDelta.bindingDeltas.action="REMOVE"
  AND protoPayload.serviceData.policyDelta.bindingDeltas.role="roles/owner")
  OR (protoPayload.serviceData.policyDelta.bindingDeltas.action="ADD"
  AND protoPayload.serviceData.policyDelta.bindingDeltas.role="roles/owner")

  6. Fai clic su Crea metrica. Viene visualizzata una conferma.

Crea policy di avviso

  1. Nella console Google Cloud , vai alla pagina Metriche basate su log:

    Vai a Metriche basate su log

    Se utilizzi la barra di ricerca per trovare questa pagina, seleziona il risultato con il sottotitolo Logging.

  2. Nella sezione Metriche definite dall'utente, seleziona la metrica che hai creato nella sezione precedente.

  3. Fai clic su Altro , quindi su Crea avviso da metrica.

    Si apre la finestra di dialogo Nuova condizione con le opzioni di metrica e trasformazione dei dati precompilate.

  4. Fai clic su Avanti.
    1. Rivedi le impostazioni precompilate. Potresti voler modificare il valore di soglia.
    2. Fai clic su Nome condizione e inserisci un nome per la condizione.
  5. Fai clic su Avanti.

  6. Per aggiungere notifiche al tuo criterio di avviso, fai clic su Canali di notifica. Nella finestra di dialogo, seleziona uno o più canali di notifica dal menu e fai clic su Ok.

    Per ricevere una notifica quando gli incidenti vengono aperti e chiusi, seleziona Notifica alla chiusura dell'incidente. Per impostazione predefinita, le notifiche vengono inviate solo quando vengono aperti incidenti.

  7. (Facoltativo) Aggiorna la Durata chiusura automatica incidenti. Questo campo determina quando Monitoring chiude gli incidenti in assenza di dati delle metriche.
  8. (Facoltativo) Fai clic su Documentazione e aggiungi tutte le informazioni che vuoi includere in un messaggio di notifica.
  9. Fai clic su Nome avviso e inserisci un nome per il criterio di avviso.
  10. Fai clic su Crea criterio.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Pod security policy disabled

Nome della categoria nell'API: POD_SECURITY_POLICY_DISABLED

PodSecurityPolicy è disattivato su un cluster GKE.

Un PodSecurityPolicy è una risorsa controller di ammissione che convalida le richieste di creazione e aggiornamento di pod in un cluster. I cluster non accettano i pod che non soddisfano le condizioni definite in PodSecurityPolicy.

Per le attivazioni a livello di progetto del livello Security Command Center Premium, questo risultato è disponibile solo se il livello Standard è abilitato nell'organizzazione principale.

Per risolvere questo problema, definisci e autorizza PodSecurityPolicies e attiva il controller PodSecurityPolicy. Per istruzioni, vedi Utilizzare PodSecurityPolicies.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Primitive roles used

Nome della categoria nell'API: PRIMITIVE_ROLES_USED

Un utente ha uno dei seguenti ruoli IAM di base: roles/owner, roles/editor o roles/viewer. Questi ruoli sono troppo permissivi e non devono essere utilizzati. Devono invece essere assegnati solo per progetto.

Per ulteriori informazioni, consulta la sezione Informazioni sui ruoli.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Policy IAM nella console Google Cloud .

    Vai alla policy IAM

  2. Per ogni utente a cui è stato assegnato un ruolo primitivo, valuta la possibilità di utilizzare ruoli più granulari.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Private cluster disabled

Nome della categoria nell'API: PRIVATE_CLUSTER_DISABLED

Un cluster GKE ha un cluster privato disabilitato.

I cluster privati consentono ai nodi di avere solo indirizzi IP privati. Questa funzionalità limita l'accesso a internet in uscita per i nodi. Se un nodo cluster non ha un indirizzo IP pubblico, non può essere trovato o esposto sulla rete internet pubblica. Puoi comunque instradare traffico a un nodo utilizzando un bilanciatore del carico interno. Per maggiori informazioni, consulta la sezione Cluster privati.

Non puoi rendere privato un cluster esistente. Per risolvere questo problema, crea un nuovo cluster privato:

  1. Vai alla pagina Cluster Kubernetes nella console Google Cloud .

    Vai ai cluster Kubernetes

  2. Fai clic su Crea cluster.

  3. Nel menu di navigazione, in Cluster, seleziona Networking.

  4. Seleziona il pulsante di opzione Cluster privato.

  5. In Opzioni di networking avanzate, seleziona la casella di controllo Abilita routing del traffico VPC nativo (mediante IP alias).

  6. Fai clic su Crea.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Private Google access disabled

Nome della categoria nell'API: PRIVATE_GOOGLE_ACCESS_DISABLED

Esistono subnet private senza accesso alle API pubbliche di Google.

L'accesso privato Google consente alle istanze VM con soli indirizzi IP interni (privati) di raggiungere gli indirizzi IP pubblici delle API e dei servizi Google.

Per ulteriori informazioni, consulta la pagina Configurazione dell'accesso privato Google.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Reti VPC nella consoleGoogle Cloud .

    Vai a Reti VPC

  2. Nell'elenco delle reti, fai clic sul nome della rete che preferisci.

  3. Nella pagina Dettagli rete VPC, fai clic sulla scheda Subnet.

  4. Nell'elenco delle subnet, fai clic sul nome della subnet associata al cluster Kubernetes nel risultato.

  5. Nella pagina Dettagli subnet, fai clic su Modifica.

  6. Nella sezione Accesso privato Google, seleziona On.

  7. Fai clic su Salva.

  8. Per rimuovere gli IP pubblici (esterni) dalle istanze VM il cui unico traffico esterno è verso le API di Google, consulta Annullamento dell'assegnazione di un indirizzo IP esterno statico.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Public bucket ACL

Nome della categoria nell'API: PUBLIC_BUCKET_ACL

Un bucket è pubblico e chiunque su internet può accedervi.

Per ulteriori informazioni, consulta la panoramica del controllo dell'accesso.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Browser di archiviazione nella Google Cloud console.

    Vai a Browser di archiviazione

  2. Seleziona il bucket elencato nel risultato di Security Health Analytics.

  3. Nella pagina Dettagli bucket, fai clic sulla scheda Autorizzazioni.

  4. Accanto a Visualizza per, fai clic su Ruoli.

  5. Nella casella Filtra, cerca allUsers e allAuthenticatedUsers.

  6. Fai clic su Elimina per rimuovere tutte le autorizzazioni IAM concesse a allUsers e allAuthenticatedUsers.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Public Compute image

Nome della categoria nell'API: PUBLIC_COMPUTE_IMAGE

Un'immagine Compute Engine è pubblica e chiunque su internet può accedervi. allUsers rappresenta tutti gli utenti su internet, mentre allAuthenticatedUsers rappresenta qualsiasi utente autenticato con un Account Google; nessuno dei due è limitato agli utenti all'interno della tua organizzazione.

Le immagini Compute Engine potrebbero contenere informazioni sensibili, ad esempio chiavi di crittografia o software concesso in licenza. che non devono essere accessibili al pubblico. Se hai intenzione di rendere pubblica questa immagine Compute Engine, assicurati che non contenga informazioni sensibili.

Per saperne di più, consulta la panoramica del controllo dell'accesso.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina delle immagini Compute Engine nella consoleGoogle Cloud .

    Vai alle immagini Compute Engine

  2. Seleziona la casella accanto all'immagine public-image, poi fai clic su Mostra riquadro informazioni.

  3. Nella casella Filtro, cerca le entità allUsers e allAuthenticatedUsers.

  4. Espandi il ruolo per cui vuoi rimuovere gli utenti.

  5. Fai clic su Elimina per rimuovere un utente da quel ruolo.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Public dataset

Nome della categoria nell'API: PUBLIC_DATASET

Un set di dati BigQuery è pubblico e accessibile a chiunque su internet. L'entità IAM allUsers rappresenta chiunque su internet e allAuthenticatedUsers rappresenta chiunque abbia eseguito l'accesso a un servizio Google; nessuno dei due è vincolato agli utenti nella tua organizzazione.

Per maggiori informazioni, vedi Controllare l'accesso ai set di dati.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Explorer di BigQuery nella console Google Cloud .

    Vai al set di dati BigQuery

  2. Nell'elenco dei set di dati, fai clic sul nome del set di dati identificato nel risultato. Si apre il riquadro Informazioni sul set di dati.

  3. Nella parte superiore del riquadro Informazioni sul set di dati, fai clic su CONDIVISIONE.

  4. Nel menu a discesa, fai clic su Autorizzazioni.

  5. Nel riquadro Autorizzazioni set di dati, inserisci allUsers e allAuthenticatedUsers e rimuovi l'accesso per queste entità.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Public IP address

Nome della categoria nell'API: PUBLIC_IP_ADDRESS

Un'istanza Compute Engine ha un indirizzo IP pubblico.

Per ridurre la superficie di attacco della tua organizzazione, evita di assegnare indirizzi IP pubblici alle tue VM. Le istanze arrestate potrebbero essere ancora segnalate con un IP pubblico, ad esempio se le interfacce di rete sono configurate per assegnare un IP pubblico temporaneo all'avvio. Assicurati che le configurazioni di rete delle istanze arrestate non includano l'accesso esterno.

Per maggiori informazioni, vedi Connessione sicura alle istanze VM.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Istanze VM nella console Google Cloud .

    Vai a Istanze VM

  2. Nell'elenco delle istanze, seleziona la casella accanto al nome dell'istanza nel risultato.

  3. Fai clic su Modifica.

  4. Per ogni interfaccia in Interfacce di rete, fai clic su Modifica e imposta IP esterno su Nessuno.

  5. Fai clic su Fine e poi su Salva.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Public log bucket

Nome della categoria nell'API: PUBLIC_LOG_BUCKET

Questo risultato non è disponibile per le attivazioni a livello di progetto.

Un bucket di archiviazione è pubblico e viene utilizzato come sink di log, il che significa che chiunque su internet può accedere ai log archiviati in questo bucket. allUsers rappresenta tutti gli utenti su internet, mentre allAuthenticatedUsers rappresenta qualsiasi utente che ha eseguito l'accesso a un servizio Google; nessuno dei due è limitato agli utenti all'interno della tua organizzazione.

Per ulteriori informazioni, consulta la panoramica del controllo dell'accesso.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Browser Cloud Storage nella consoleGoogle Cloud .

    Vai a Browser Cloud Storage

  2. Nell'elenco dei bucket, fai clic sul nome del bucket indicato nel risultato.

  3. Fai clic sulla scheda Autorizzazioni.

  4. Rimuovi allUsers e allAuthenticatedUsers dall'elenco delle entità.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Public SQL instance

Nome della categoria nell'API: PUBLIC_SQL_INSTANCE

La tua istanza SQL ha 0.0.0.0/0 come rete consentita. Ciò significa che qualsiasi client IPv4, compresi quelli che non intendevi autorizzare, può superare il firewall di rete ed eseguire tentativi di accesso all'istanza. I client devono comunque avere credenziali valide per accedere all'istanza.

Per maggiori informazioni, consulta Autorizzazione con reti autorizzate.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Istanze Cloud SQL nella console Google Cloud .

    Vai a Istanze Cloud SQL

  2. Seleziona l'istanza elencata nel risultato di Security Health Analytics.

  3. Fai clic su Modifica.

  4. Nel pannello di navigazione, fai clic su Connessioni.

  5. Nella sezione Reti autorizzate, elimina 0.0.0.0/0 e aggiungi indirizzi IP o intervalli di indirizzi IP specifici che vuoi autorizzare a connettersi all'istanza.

  6. Fai clic su Fine e poi su Salva.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Pubsub CMEK disabled

Nome della categoria nell'API: PUBSUB_CMEK_DISABLED

Un argomento Pub/Sub non è criptato con chiavi di crittografia gestite dal cliente (CMEK).

Con CMEK, le chiavi che crei e gestisci in Cloud KMS criptano le chiavi che Google utilizza per criptare i tuoi dati, offrendoti un maggiore controllo sull'accesso ai tuoi dati.

Per risolvere questo problema, elimina l'argomento esistente e creane uno nuovo:

  1. Vai alla pagina Argomenti di Pub/Sub nella console Google Cloud .

    Vai ad Argomenti

  2. Se necessario, seleziona il progetto contenente l'argomento Pub/Sub.

  3. Seleziona la casella di controllo accanto all'argomento elencato nel risultato, quindi fai clic su Elimina.

  4. Per creare un nuovo argomento Pub/Sub con CMEK abilitata, consulta la sezione Utilizzo delle chiavi di crittografia gestite dal cliente. Le chiavi CMEK comportano costi aggiuntivi correlati a Cloud KMS.

  5. Pubblica i risultati o altri dati nell'argomento Pub/Sub abilitato per CMEK.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Route not monitored

Nome della categoria nell'API: ROUTE_NOT_MONITORED

Le metriche di log e gli avvisi non sono configurati per monitorare le modifiche alle route di rete VPC.

Le routeGoogle Cloud sono destinazioni e hop che definiscono il percorso seguito dal traffico di rete da un'istanza VM a un IP di destinazione. Il monitoraggio delle modifiche alle tabelle delle route ti consente di contribuire a garantire che tutto il traffico VPC passi attraverso un percorso previsto.

Per ulteriori informazioni, consulta la panoramica delle metriche basate su log.

A seconda della quantità di informazioni, i costi di Cloud Monitoring possono essere significativi. Per comprendere l'utilizzo del servizio e i relativi costi, consulta Prezzi di Google Cloud Observability.

Per le attivazioni a livello di progetto del livello Security Command Center Premium, questo risultato è disponibile solo se il livello Standard è abilitato nell'organizzazione principale.

Per risolvere questo problema, completa i seguenti passaggi:

Crea metrica

  1. Vai alla pagina Metriche basate su log nella console Google Cloud .

    Vai a Metriche basate su log

  2. Fai clic su Crea metrica.

  3. In Tipo di metrica, seleziona Contatore.

  4. In Dettagli:

    1. Imposta un Nome metrica di log.
    2. Aggiungi una descrizione.
    3. Imposta Unità su 1.

  5. In Selezione dei filtri, copia e incolla il testo seguente nella casella Crea filtro, sostituendo il testo esistente, se necessario: 

      resource.type="gce_route"
  AND (protoPayload.methodName:"compute.routes.delete"
  OR protoPayload.methodName:"compute.routes.insert")

  6. Fai clic su Crea metrica. Viene visualizzata una conferma.

Crea policy di avviso

  1. Nella console Google Cloud , vai alla pagina Metriche basate su log:

    Vai a Metriche basate su log

    Se utilizzi la barra di ricerca per trovare questa pagina, seleziona il risultato con il sottotitolo Logging.

  2. Nella sezione Metriche definite dall'utente, seleziona la metrica che hai creato nella sezione precedente.

  3. Fai clic su Altro , quindi su Crea avviso da metrica.

    Si apre la finestra di dialogo Nuova condizione con le opzioni di metrica e trasformazione dei dati precompilate.

  4. Fai clic su Avanti.
    1. Rivedi le impostazioni precompilate. Potresti voler modificare il valore di soglia.
    2. Fai clic su Nome condizione e inserisci un nome per la condizione.
  5. Fai clic su Avanti.

  6. Per aggiungere notifiche al tuo criterio di avviso, fai clic su Canali di notifica. Nella finestra di dialogo, seleziona uno o più canali di notifica dal menu e fai clic su Ok.

    Per ricevere una notifica quando gli incidenti vengono aperti e chiusi, seleziona Notifica alla chiusura dell'incidente. Per impostazione predefinita, le notifiche vengono inviate solo quando vengono aperti incidenti.

  7. (Facoltativo) Aggiorna la Durata chiusura automatica incidenti. Questo campo determina quando Monitoring chiude gli incidenti in assenza di dati delle metriche.
  8. (Facoltativo) Fai clic su Documentazione e aggiungi tutte le informazioni che vuoi includere in un messaggio di notifica.
  9. Fai clic su Nome avviso e inserisci un nome per il criterio di avviso.
  10. Fai clic su Crea criterio.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Redis role used on org

Nome della categoria nell'API: REDIS_ROLE_USED_ON_ORG

Questo risultato non è disponibile per le attivazioni a livello di progetto.

Un ruolo IAM Redis viene assegnato a livello di organizzazione o cartella.

I seguenti ruoli IAM Redis devono essere assegnati solo per progetto, non a livello di organizzazione o cartella:

  • roles/redis.admin
  • roles/redis.viewer
  • roles/redis.editor

Per saperne di più, consulta Controllo dell'accesso e autorizzazioni.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Policy IAM nella console Google Cloud .

    Vai alla policy IAM

  2. Rimuovi i ruoli IAM Redis indicati nel risultato e aggiungili ai singoli progetti.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Release channel disabled

Nome della categoria nell'API: RELEASE_CHANNEL_DISABLED

Un cluster GKE non è iscritto a un canale di rilascio.

Iscriviti a un canale di rilascio per automatizzare gli upgrade delle versioni del cluster GKE. Inoltre, le funzionalità riducono la complessità della gestione delle versioni al numero di funzionalità e al livello di stabilità richiesti. Per maggiori informazioni, consulta la pagina Canali di rilascio.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Cluster Kubernetes nella console Google Cloud .

    Vai ai cluster Kubernetes

  2. Nella sezione Impostazioni di base del cluster, fai clic su Esegui l'upgrade della versione master del cluster nella riga Canale di rilascio.

    Se la configurazione del cluster è stata cambiata di recente, il pulsante di modifica potrebbe essere disabilitato. Se non riesci a modificare le impostazioni del cluster, attendi alcuni minuti e riprova.

  3. Nella finestra di dialogo, seleziona Canale di rilascio, quindi scegli il canale di rilascio a cui vuoi iscriverti.

    Se non è possibile eseguire l'upgrade della versione del control plane del tuo cluster a un canale di rilascio, questo canale potrebbe essere disattivato come opzione.

  4. Fai clic su Salva modifiche.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

RSASHA1 for signing

Nome della categoria nell'API: RSASHA1_FOR_SIGNING

RSASHA1 viene utilizzato per la firma della chiave nelle zone Cloud DNS. L'algoritmo utilizzato per la firma della chiave non deve essere debole.

Per risolvere questo problema, sostituisci l'algoritmo con uno consigliato seguendo la guida Utilizzare le opzioni di firma avanzate.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Service account key not rotated

Nome della categoria nell'API: SERVICE_ACCOUNT_KEY_NOT_ROTATED

Questo risultato non è disponibile per le attivazioni a livello di progetto.

Una chiave del account di servizio gestita dall'utente non è stata ruotata per più di 90 giorni.

In generale, le chiavi del account di servizio gestite dall'utente devono essere ruotate almeno ogni 90 giorni per garantire che i dati non siano accessibili con una vecchia chiave che potrebbe essere stata persa, compromessa o rubata. Per ulteriori informazioni, consulta Ruotare le chiavi account di servizio per ridurre il rischio per la sicurezza causato da chiavi compromesse.

Se hai generato tu stesso la coppia di chiave pubblica/privata, hai memorizzato la chiave privata in un modulo di sicurezza hardware (HSM) e hai caricato la chiave pubblica su Google, potresti non dover ruotare la chiave ogni 90 giorni. Puoi invece ruotare la chiave se ritieni che possa essere stata compromessa.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Service account nella console Google Cloud .

    Vai a Service account

  2. Se necessario, seleziona il progetto indicato nel risultato.

  3. Nell'elenco dei service account, trova quello elencato nel risultato.

  4. Fai clic sulla scheda Chiavi e poi identifica la chiave che vuoi disattivare.

  5. Per disattivare la chiave, segui le istruzioni riportate in Disattivare una account di servizio account.

  6. (Facoltativo) Dopo aver verificato che la chiave non è più in uso, elimina la chiave dell'account di servizio.

    Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Service account role separation

Nome della categoria nell'API: SERVICE_ACCOUNT_ROLE_SEPARATION

Questo risultato non è disponibile per le attivazioni a livello di progetto.

A una o più entità dell'organizzazione sono assegnate più autorizzazioni per il account di servizio. Nessun account deve disporre simultaneamente dell'autorizzazione Amministratore service account e di altre autorizzazioni account di servizio. Per scoprire di più sui service account e sui ruoli disponibili, consulta Service accounts.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina IAM nella console Google Cloud .

    Vai a IAM

  2. Per ogni entità elencata nel risultato, procedi nel seguente modo:

    1. Per verificare se il ruolo è stato ereditato da una cartella o una risorsa dell'organizzazione, controlla la colonna Ereditarietà. Se la colonna contiene un link a una risorsa padre, fai clic sul link per accedere alla pagina IAM della risorsa padre.
    2. Fai clic su Modifica accanto a un'entità.
    3. Per rimuovere le autorizzazioni, fai clic su Elimina accanto ad Amministratore service account. Per rimuovere tutte le autorizzazioni del account di servizio, fai clic su Elimina accanto a tutte le altre autorizzazioni.

  3. Fai clic su Salva.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Shielded VM disabled

Nome della categoria nell'API: SHIELDED_VM_DISABLED

Shielded VM è disabilitata su questa istanza Compute Engine.

Le Shielded VM sono macchine virtuali (VM) su Google Cloud protette da un set di controlli di sicurezza che contribuiscono alla difesa da rootkit e bootkit. Le Shielded VM aiutano a garantire che il bootloader e il firmware siano firmati e verificati. Scopri di più su Shielded VM.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Istanze VM nella console Google Cloud .

    Vai a Istanze VM

  2. Seleziona l'istanza correlata al risultato di Security Health Analytics.

  3. Nella pagina Dettagli istanza che viene caricata, fai clic su Arresta.

  4. Dopo l'arresto dell'istanza, fai clic su Modifica.

  5. Nella sezione Shielded VM, seleziona Attiva vTPM e Attiva il monitoraggio dell'integrità per abilitare Shielded VM.

  6. Facoltativamente, se non usi driver personalizzati o non firmati, abilita anche Avvio protetto.

  7. Fai clic su Salva. La nuova configurazione viene visualizzata nella pagina Dettagli istanza.

  8. Fai clic su Avvia per avviare l'istanza.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

SQL CMEK disabled

Nome della categoria nell'API: SQL_CMEK_DISABLED

Un'istanza di database SQL non utilizza le chiavi di crittografia gestite dal cliente (CMEK).

Con CMEK, le chiavi che crei e gestisci in Cloud KMS criptano le chiavi che Google utilizza per criptare i tuoi dati, offrendoti un maggiore controllo sull'accesso ai tuoi dati. Per saperne di più, consulta le panoramiche di CMEK per il tuo prodotto: Cloud SQL per MySQL, Cloud SQL per PostgreSQL o Cloud SQL per SQL Server. Le chiavi CMEK comportano costi aggiuntivi correlati a Cloud KMS.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Istanze Cloud SQL nella consoleGoogle Cloud .

    Vai a Istanze Cloud SQL

  2. Seleziona l'istanza elencata nel risultato di Security Health Analytics.

  3. Fai clic su Elimina.

  4. Per creare una nuova istanza con CMEK abilitato, segui le istruzioni per configurare CMEK per il tuo prodotto:

    1. Cloud SQL per MySQL
    2. Cloud SQL per PostgreSQL
    3. Cloud SQL per SQL Server

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

SQL contained database authentication

Nome della categoria nell'API: SQL_CONTAINED_DATABASE_AUTHENTICATION

Un'istanza di database Cloud SQL per SQL Server non ha il flag di database autenticazione di database indipendente impostato su Off.

Il flag autenticazione database indipendenti determina se puoi creare o collegare database indipendenti al motore del database. Un database indipendente include tutte le impostazioni e i metadati necessari per definire il database e non ha dipendenze di configurazione sull'istanza del motore del database in cui è installato.

L'attivazione di questo flag non è consigliata per i seguenti motivi:

  • Gli utenti possono connettersi al database senza autenticazione a livello del motore di database.
  • Isolare il database dal motore di database consente di spostarlo in un'altra istanza di SQL Server.

I database contenuti affrontano minacce uniche che devono essere comprese e ridotte dagli amministratori del motore di database SQL Server. La maggior parte delle minacce deriva dal processo di autenticazione UTENTE CON PASSWORD, che sposta il limite di autenticazione dal livello del motore di database a quello del database.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Istanze Cloud SQL nella consoleGoogle Cloud .

    Vai a Istanze Cloud SQL

  2. Seleziona l'istanza elencata nel risultato di Security Health Analytics.

  3. Fai clic su Modifica.

  4. Nella sezione Flag di database, imposta il flag di database autenticazione database indipendente su Off.

  5. Fai clic su Salva. La nuova configurazione viene visualizzata nella pagina Panoramica dell'istanza.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

SQL cross DB ownership chaining

Nome della categoria nell'API: SQL_CROSS_DB_OWNERSHIP_CHAINING

Un'istanza di database Cloud SQL per SQL Server non ha il flag di database cross db ownership chaining impostato su Off.

Il flag cross db ownership chaining consente di controllare il concatenamento della proprietà tra database a livello di database o di permettere il concatenamento della proprietà tra database per tutte le istruzioni di database.

L'abilitazione di questo flag non è consigliata a meno che tutti i database ospitati dall'istanza di SQL Server non partecipino al concatenamento della proprietà tra database e tenendo presenti le implicazioni per la sicurezza di questa impostazione.

Per saperne di più, consulta la sezione Configurazione dei flag di database.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Istanze Cloud SQL nella consoleGoogle Cloud .

    Vai a Istanze Cloud SQL

  2. Seleziona l'istanza elencata nel risultato di Security Health Analytics.

  3. Fai clic su Modifica.

  4. Nella sezione Flag di database, imposta il flag di database cross db ownership chaining con il valore Off.

  5. Fai clic su Salva. La nuova configurazione viene visualizzata nella pagina Panoramica dell'istanza.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

SQL external scripts enabled

Nome della categoria nell'API: SQL_EXTERNAL_SCRIPTS_ENABLED

Un'istanza di database Cloud SQL per SQL Server non ha il flag di database external scripts enabled impostato su Off.

Quando è attivata, questa impostazione consente l'esecuzione di script con determinate estensioni di linguaggio remote. Poiché questa funzionalità può influire negativamente sulla sicurezza del sistema, ti consigliamo di disattivarla.

Per maggiori informazioni, consulta la pagina Configurazione dei flag di database.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Istanze Cloud SQL nella consoleGoogle Cloud .

    Vai a Istanze Cloud SQL

  2. Seleziona l'istanza elencata nel risultato di Security Health Analytics.

  3. Fai clic su Modifica.

  4. Nella sezione Flag di database, imposta il flag di database external scripts enabled con il valore Off.

  5. Fai clic su Salva. La nuova configurazione viene visualizzata nella pagina Panoramica dell'istanza.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

SQL instance not monitored

Nome della categoria nell'API: SQL_INSTANCE_NOT_MONITORED

Questo risultato non è disponibile per le attivazioni a livello di progetto.

Le metriche di log e gli avvisi non sono configurati per monitorare le modifiche alla configurazione dell'istanza Cloud SQL.

La configurazione errata delle opzioni delle istanze SQL può causare rischi per la sicurezza. La disattivazione delle opzioni di backup automatico e alta disponibilità potrebbe influire sulla continuità aziendale e la mancata limitazione delle reti autorizzate potrebbe aumentare l'esposizione a reti non attendibili. Il monitoraggio delle modifiche alla configurazione delle istanze SQL ti aiuta a ridurre i tempi necessari per rilevare e correggere gli errori di configurazione.

Per saperne di più, consulta Panoramica delle metriche basate su log.

A seconda della quantità di informazioni, i costi di Cloud Monitoring possono essere significativi. Per comprendere l'utilizzo del servizio e i relativi costi, consulta Prezzi di Google Cloud Observability.

Per le attivazioni a livello di progetto del livello Security Command Center Premium, questo risultato è disponibile solo se il livello Standard è abilitato nell'organizzazione principale.

Per risolvere questo problema, completa i seguenti passaggi:

Crea metrica

  1. Vai alla pagina Metriche basate su log nella console Google Cloud .

    Vai a Metriche basate su log

  2. Fai clic su Crea metrica.

  3. In Tipo di metrica, seleziona Contatore.

  4. In Dettagli:

    1. Imposta un Nome metrica di log.
    2. Aggiungi una descrizione.
    3. Imposta Unità su 1.

  5. In Selezione dei filtri, copia e incolla il testo seguente nella casella Crea filtro, sostituendo il testo esistente, se necessario: 

      protoPayload.methodName="cloudsql.instances.update"
  OR protoPayload.methodName="cloudsql.instances.create"
  OR protoPayload.methodName="cloudsql.instances.delete"

  6. Fai clic su Crea metrica. Viene visualizzata una conferma.

Crea policy di avviso

  1. Nella console Google Cloud , vai alla pagina Metriche basate su log:

    Vai a Metriche basate su log

    Se utilizzi la barra di ricerca per trovare questa pagina, seleziona il risultato con il sottotitolo Logging.

  2. Nella sezione Metriche definite dall'utente, seleziona la metrica che hai creato nella sezione precedente.

  3. Fai clic su Altro , quindi su Crea avviso da metrica.

    Si apre la finestra di dialogo Nuova condizione con le opzioni di metrica e trasformazione dei dati precompilate.

  4. Fai clic su Avanti.
    1. Rivedi le impostazioni precompilate. Potresti voler modificare il valore di soglia.
    2. Fai clic su Nome condizione e inserisci un nome per la condizione.
  5. Fai clic su Avanti.

  6. Per aggiungere notifiche al tuo criterio di avviso, fai clic su Canali di notifica. Nella finestra di dialogo, seleziona uno o più canali di notifica dal menu e fai clic su Ok.

    Per ricevere una notifica quando gli incidenti vengono aperti e chiusi, seleziona Notifica alla chiusura dell'incidente. Per impostazione predefinita, le notifiche vengono inviate solo quando vengono aperti incidenti.

  7. (Facoltativo) Aggiorna la Durata chiusura automatica incidenti. Questo campo determina quando Monitoring chiude gli incidenti in assenza di dati delle metriche.
  8. (Facoltativo) Fai clic su Documentazione e aggiungi tutte le informazioni che vuoi includere in un messaggio di notifica.
  9. Fai clic su Nome avviso e inserisci un nome per il criterio di avviso.
  10. Fai clic su Crea criterio.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

SQL local infile

Nome della categoria nell'API: SQL_LOCAL_INFILE

Un'istanza di database Cloud SQL per MySQL non ha il flag di database local_infile impostato su Off. A causa di problemi di sicurezza associati al flag local_infile, questo deve essere disattivato. Per ulteriori informazioni, consulta la pagina Configurazione dei flag di database.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Istanze Cloud SQL nella consoleGoogle Cloud .

    Vai a Istanze Cloud SQL

  2. Seleziona l'istanza elencata nel risultato di Security Health Analytics.

  3. Fai clic su Modifica.

  4. Nella sezione Flag di database, imposta il flag del database local_infile su Off.

  5. Fai clic su Salva. La nuova configurazione viene visualizzata nella pagina Panoramica dell'istanza.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

SQL log checkpoints disabled

Nome della categoria nell'API: SQL_LOG_CHECKPOINTS_DISABLED

Un'istanza di database Cloud SQL per PostgreSQL non ha il flag di database log_checkpoints impostato su On.

L'abilitazione di log_checkpoints fa sì che i punti di controllo e i punti di riavvio vengano registrati nel log del server. Alcune statistiche sono incluse nei messaggi di log, tra cui il numero di buffer scritti e il tempo di scrittura.

Per saperne di più, consulta la sezione Configurazione dei flag di database.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Istanze Cloud SQL nella consoleGoogle Cloud .

    Vai a Istanze Cloud SQL

  2. Seleziona l'istanza elencata nel risultato di Security Health Analytics.

  3. Fai clic su Modifica.

  4. Nella sezione Flag di database, imposta il flag di database log_checkpoints su On.

  5. Fai clic su Salva. La nuova configurazione viene visualizzata nella pagina Panoramica dell'istanza.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

SQL log connections disabled

Nome della categoria nell'API: SQL_LOG_CONNECTIONS_DISABLED

Un'istanza di database Cloud SQL per PostgreSQL non ha il flag di database log_connections impostato su On.

L'abilitazione dell'impostazione log_connections comporta la registrazione dei tentativi di connessione al server e il corretto completamento dell'autenticazione client. I log possono essere utili per la risoluzione dei problemi e per verificare i tentativi di connessione insoliti al server.

Per saperne di più, consulta la sezione Configurazione dei flag di database.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Istanze Cloud SQL nella consoleGoogle Cloud .

    Vai a Istanze Cloud SQL

  2. Seleziona l'istanza elencata nel risultato di Security Health Analytics.

  3. Fai clic su Modifica.

  4. Nella sezione Flag di database, imposta il flag del database log_connections su On.

  5. Fai clic su Salva. La nuova configurazione viene visualizzata nella pagina Panoramica dell'istanza.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

SQL log disconnections disabled

Nome della categoria nell'API: SQL_LOG_DISCONNECTIONS_DISABLED

Un'istanza di database Cloud SQL per PostgreSQL non ha il flag di database log_disconnections impostato su On.

Se si abilita l'impostazione log_disconnections vengono create voci di log alla fine di ogni sessione. I log sono utili per la risoluzione dei problemi e per la conferma di attività insolite in un periodo di tempo. Per maggiori informazioni, consulta la pagina Configurazione dei flag di database.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Istanze Cloud SQL nella consoleGoogle Cloud .

    Vai a Istanze Cloud SQL

  2. Seleziona l'istanza elencata nel risultato di Security Health Analytics.

  3. Fai clic su Modifica.

  4. Nella sezione Flag di database, imposta il flag di database log_disconnections con il valore On.

  5. Fai clic su Salva. La nuova configurazione viene visualizzata nella pagina Panoramica dell'istanza.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

SQL log duration disabled

Nome della categoria nell'API: SQL_LOG_DURATION_DISABLED

Un'istanza di database Cloud SQL per PostgreSQL non ha il flag di database log_duration impostato su On.

Se log_duration è abilitato, questa impostazione fa sì che vengano registrati i tempi di esecuzione e la durata di ogni istruzione completata. Monitorare il tempo necessario per eseguire le query può essere fondamentale per identificare le query lente e risolvere i problemi relativi al database.

Per saperne di più, consulta la sezione Configurazione dei flag di database.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Istanze Cloud SQL nella consoleGoogle Cloud .

    Vai a Istanze Cloud SQL

  2. Seleziona l'istanza elencata nel risultato di Security Health Analytics.

  3. Fai clic su Modifica.

  4. Nella sezione Flag di database, imposta il flag di database log_duration su On.

  5. Fai clic su Salva. La nuova configurazione viene visualizzata nella pagina Panoramica dell'istanza.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

SQL log error verbosity

Nome della categoria nell'API: SQL_LOG_ERROR_VERBOSITY

Un'istanza di database Cloud SQL per PostgreSQL non ha il flag di database log_error_verbosity impostato su default o verbose.

Il flag log_error_verbosity controlla la quantità di dettagli nei messaggi registrati. Maggiore è il livello di dettaglio, maggiori saranno i dettagli registrati nei messaggi. Ti consigliamo di impostare questo flag su default o su verbose.

Per saperne di più, consulta la sezione Configurazione dei flag di database.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Istanze Cloud SQL nella consoleGoogle Cloud .

    Vai a Istanze Cloud SQL

  2. Seleziona l'istanza elencata nel risultato di Security Health Analytics.

  3. Fai clic su Modifica.

  4. Nella sezione Flag di database, imposta il flag di database log_error_verbosity su default o verbose.

  5. Fai clic su Salva. La nuova configurazione viene visualizzata nella pagina Panoramica dell'istanza.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

SQL log lock waits disabled

Nome della categoria nell'API: SQL_LOG_LOCK_WAITS_DISABLED

Un'istanza di database Cloud SQL per PostgreSQL non ha il flag di database log_lock_waits impostato su On.

Se si abilita l'impostazione log_lock_waits vengono create voci di log quando le attese della sessione durano di più rispetto al tempo di deadlock_timeout per acquisire un blocco. I log sono utili per determinare se i tempi di attesa del blocco compromettono le prestazioni.

Per saperne di più, consulta la sezione Configurazione dei flag di database.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Istanze Cloud SQL nella consoleGoogle Cloud .

    Vai a Istanze Cloud SQL

  2. Seleziona l'istanza elencata nel risultato di Security Health Analytics.

  3. Fai clic su Modifica.

  4. Nella sezione Flag di database, imposta il flag di database log_lock_waits su On.

  5. Fai clic su Salva. La nuova configurazione viene visualizzata nella pagina Panoramica dell'istanza.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

SQL log min duration statement enabled

Nome della categoria nell'API: SQL_LOG_MIN_DURATION_STATEMENT_ENABLED

Un'istanza di database Cloud SQL per PostgreSQL non ha il flag di database log_min_duration_statement impostato su -1.

Il flag log_min_duration_statement causa la registrazione delle istruzioni SQL eseguite per un periodo di tempo più lungo di quello specificato. Ti consigliamo di disattivare questa impostazione poiché le istruzioni SQL potrebbero contenere informazioni sensibili che non devono essere registrate. Per maggiori informazioni, vedi Configurazione dei flag di database.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Istanze Cloud SQL nella consoleGoogle Cloud .

    Vai a Istanze Cloud SQL

  2. Seleziona l'istanza elencata nel risultato di Security Health Analytics.

  3. Fai clic su Modifica.

  4. Nella sezione Flag di database, imposta il flag di database log_min_duration_statement su -1.

  5. Fai clic su Salva. La nuova configurazione viene visualizzata nella pagina Panoramica dell'istanza.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

SQL log min error statement

Nome della categoria nell'API: SQL_LOG_MIN_ERROR_STATEMENT

Un'istanza di database Cloud SQL per PostgreSQL non ha il flag di database log_min_error_statement impostato correttamente.

Il flag log_min_error_statement controlla se le istruzioni SQL che causano condizioni di errore vengono registrate nei log del server. Le istruzioni SQL con il livello di gravità specificato o superiore vengono registrate con messaggi per le istruzioni con errori. Maggiore è la gravità, minore è il numero di messaggi registrati.

Se il valore impostato per log_min_error_statement non è quello corretto, i messaggi potrebbero non essere classificati come messaggi di errore. Se la gravità impostata è troppo bassa, il numero di messaggi potrebbe aumentare e sarebbe difficile trovare gli errori veri e propri. Se la gravità impostata è troppo elevata, è possibile che i messaggi relativi agli errori effettivi non vengano registrati.

Per saperne di più, consulta la sezione Configurazione dei flag di database.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Istanze Cloud SQL nella consoleGoogle Cloud .

    Vai a Istanze Cloud SQL

  2. Seleziona l'istanza elencata nel risultato di Security Health Analytics.

  3. Fai clic su Modifica.

  4. Nella sezione Flag di database, imposta il flag di database log_min_error_statement su uno dei seguenti valori consigliati, in base al criterio di logging della tua organizzazione.

    • debug5
    • debug4
    • debug3
    • debug2
    • debug1
    • info
    • notice
    • warning
    • error

  5. Fai clic su Salva. La nuova configurazione viene visualizzata nella pagina Panoramica dell'istanza.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

SQL log min error statement severity

Nome della categoria nell'API: SQL_LOG_MIN_ERROR_STATEMENT_SEVERITY

Un'istanza di database Cloud SQL per PostgreSQL non ha il flag di database log_min_error_statement impostato correttamente.

Il flag log_min_error_statement controlla se le istruzioni SQL che causano condizioni di errore vengono registrate nei log del server. Le istruzioni SQL con il livello di gravità specificato o più restrittivo vengono registrate con messaggi per le istruzioni con errori. Più severa è la gravità, minore è il numero di messaggi registrati.

Se il valore impostato per log_min_error_statement non è quello corretto, i messaggi potrebbero non essere classificati come messaggi di errore. Se la gravità impostata è troppo bassa, il numero di messaggi potrebbe aumentare e sarebbe difficile trovare gli errori veri e propri. Un livello di gravità troppo elevato (troppo rigoroso) potrebbe impedire la registrazione dei messaggi di errore relativi agli errori effettivi.

Ti consigliamo di impostare questo flag su error o su un valore più restrittivo.

Per saperne di più, consulta la sezione Configurazione dei flag di database.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Istanze Cloud SQL nella consoleGoogle Cloud .

    Vai a Istanze Cloud SQL

  2. Seleziona l'istanza elencata nel risultato di Security Health Analytics.

  3. Fai clic su Modifica.

  4. Nella sezione Flag di database, imposta il flag di database log_min_error_statement su uno dei seguenti valori suggeriti, in base al criterio di logging della tua organizzazione.

    • error
    • log
    • fatal
    • panic

  5. Fai clic su Salva. La nuova configurazione viene visualizzata nella pagina Panoramica dell'istanza.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

SQL log min messages

Nome della categoria nell'API: SQL_LOG_MIN_MESSAGES

Un'istanza di database Cloud SQL per PostgreSQL non ha il flag di database log_min_messages impostato almeno su warning.

Il flag log_min_messages controlla quali livelli di messaggi vengono registrati nei log del server. Più elevata è la gravità, minore è il numero di messaggi registrati. L'impostazione di una soglia troppo bassa può comportare un aumento della dimensione e della durata dell'archiviazione dei log, il che complica l'individuazione di errori effettivi.

Per maggiori informazioni, consulta la pagina Configurazione dei flag di database.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Istanze Cloud SQL nella consoleGoogle Cloud .

    Vai a Istanze Cloud SQL

  2. Seleziona l'istanza elencata nel risultato di Security Health Analytics.

  3. Fai clic su Modifica.

  4. Nella sezione Flag di database, imposta il flag di database log_min_messages su uno dei seguenti valori suggeriti, in base al criterio di logging della tua organizzazione.

    • debug5
    • debug4
    • debug3
    • debug2
    • debug1
    • info
    • notice
    • warning

  5. Fai clic su Salva. La nuova configurazione viene visualizzata nella pagina Panoramica dell'istanza.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

SQL log executor stats enabled

Nome della categoria nell'API: SQL_LOG_EXECUTOR_STATS_ENABLED

Un'istanza di database Cloud SQL per PostgreSQL non ha il flag di database log_executor_stats impostato su Off.

Quando il flag log_executor_stats è attivato, le statistiche sulle prestazioni dell'esecutore vengono incluse nei log PostgreSQL per ogni query. Questa impostazione può essere utile per la risoluzione dei problemi, ma può aumentare notevolmente il numero di log e il sovraccarico delle prestazioni.

Per saperne di più, consulta la sezione Configurazione dei flag di database.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Istanze Cloud SQL nella console Google Cloud .

    Vai a Istanze Cloud SQL

  2. Seleziona l'istanza elencata nel risultato di Security Health Analytics.

  3. Fai clic su Modifica.

  4. Nella sezione Flag di database, imposta il flag di database log_executor_stats su Off.

  5. Fai clic su Salva. La nuova configurazione viene visualizzata nella pagina Panoramica dell'istanza.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

SQL log hostname enabled

Nome della categoria nell'API: `SQL_LOG_HOSTNAME_ENABLED

Un'istanza di database Cloud SQL per PostgreSQL non ha il flag di database log_hostname impostato su Off.

Quando il flag log_hostname è attivato, viene registrato il nome host dell'host che si connette. Per impostazione predefinita, i messaggi di log della connessione mostrano solo l'indirizzo IP. Questa impostazione può essere utile per la risoluzione dei problemi. Tuttavia, può verificarsi l'overhead delle prestazioni del server, poiché per ciascuna istruzione registrata, è necessaria una risoluzione DNS per convertire un indirizzo IP in un nome host.

Per saperne di più, consulta la sezione Configurazione dei flag di database.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Istanze Cloud SQL nella console Google Cloud .

    Vai a Istanze Cloud SQL

  2. Seleziona l'istanza elencata nel risultato di Security Health Analytics.

  3. Fai clic su Modifica.

  4. Nella sezione Flag di database, imposta il flag di database log_hostname su Off.

  5. Fai clic su Salva. La nuova configurazione viene visualizzata nella pagina Panoramica dell'istanza.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

SQL log parser stats enabled

Nome della categoria nell'API: SQL_LOG_PARSER_STATS_ENABLED

Un'istanza di database Cloud SQL per PostgreSQL non ha il flag di database log_parser_stats impostato su Off.

Quando il flag log_parser_stats è attivato, le statistiche sulle prestazioni del parser vengono incluse nei log PostgreSQL per ogni query. Questo può essere utile per la risoluzione dei problemi, ma può aumentare notevolmente il numero di log e il sovraccarico delle prestazioni.

Per saperne di più, consulta la sezione Configurazione dei flag di database.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Istanze Cloud SQL nella console Google Cloud .

    Vai a Istanze Cloud SQL

  2. Seleziona l'istanza elencata nel risultato di Security Health Analytics.

  3. Fai clic su Modifica.

  4. Nella sezione Flag di database, imposta il flag di database log_parser_stats su Off.

  5. Fai clic su Salva. La nuova configurazione viene visualizzata nella pagina Panoramica dell'istanza.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

SQL log planner stats enabled

Nome della categoria nell'API: SQL_LOG_PLANNER_STATS_ENABLED

Un'istanza di database Cloud SQL per PostgreSQL non ha il flag di database log_planner_stats impostato su Off.

Quando il flag log_planner_stats è attivato, viene utilizzato un metodo di profilazione non elaborato per il logging delle statistiche sulle prestazioni dello strumento di pianificazione PostgreSQL. Questo può essere utile per la risoluzione dei problemi, ma può aumentare notevolmente il numero di log e il sovraccarico delle prestazioni.

Per saperne di più, consulta la sezione Configurazione dei flag di database.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Istanze Cloud SQL nella console Google Cloud .

    Vai a Istanze Cloud SQL

  2. Seleziona l'istanza elencata nel risultato di Security Health Analytics.

  3. Fai clic su Modifica.

  4. Nella sezione Flag di database, imposta il flag di database log_planner_stats su Off.

  5. Fai clic su Salva. La nuova configurazione viene visualizzata nella pagina Panoramica dell'istanza.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

SQL log statement

Nome della categoria nell'API: SQL_LOG_STATEMENT

Un'istanza di database Cloud SQL per PostgreSQL non ha il flag di database log_statement impostato su ddl.

Il valore di questo flag controlla quali istruzioni SQL vengono registrate. Il logging aiuta a risolvere i problemi operativi e consente l'analisi forense. Se questo flag non è impostato sul valore corretto, le informazioni pertinenti potrebbero essere ignorate o nascoste in troppi messaggi. Si consiglia un valore ddl (tutte le istruzioni di definizione dei dati), se non diversamente indicato dal criterio di logging dell'organizzazione.

Per saperne di più, consulta la sezione Configurazione dei flag di database.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Istanze Cloud SQL nella console Google Cloud .

    Vai a Istanze Cloud SQL

  2. Seleziona l'istanza elencata nel risultato di Security Health Analytics.

  3. Fai clic su Modifica.

  4. Nella sezione Flag di database, imposta il flag di database log_statement su ddl.

  5. Fai clic su Salva. La nuova configurazione viene visualizzata nella pagina Panoramica dell'istanza.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

SQL log statement stats enabled

Nome della categoria nell'API: SQL_LOG_STATEMENT_STATS_ENABLED

Un'istanza di database Cloud SQL per PostgreSQL non ha il flag di database log_statement_stats impostato su Off.

Quando il flag log_statement_stats è attivato, le statistiche sulle prestazioni end-to-end vengono incluse nei log PostgreSQL per ogni query. Questa impostazione può essere utile per la risoluzione dei problemi, ma può aumentare notevolmente il numero di log e il sovraccarico delle prestazioni.

Per saperne di più, consulta la sezione Configurazione dei flag di database.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Istanze Cloud SQL nella console Google Cloud .

    Vai a Istanze Cloud SQL

  2. Seleziona l'istanza elencata nel risultato di Security Health Analytics.

  3. Fai clic su Modifica.

  4. Nella sezione Flag di database, imposta il flag di database log_statement_stats su Off.

  5. Fai clic su Salva. La nuova configurazione viene visualizzata nella pagina Panoramica dell'istanza.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

SQL log temp files

Nome della categoria nell'API: SQL_LOG_TEMP_FILES

Un'istanza di database Cloud SQL per PostgreSQL non ha il flag di database log_temp_files impostato su 0.

Potrebbero essere creati file temporanei per ordinamenti, hash e risultati temporanei delle query. Se imposti il flag log_temp_files su 0, vengono registrate tutte le informazioni relative ai file temporanei. La registrazione di tutti i file temporanei è utile per identificare eventuali problemi di prestazioni. Per saperne di più, consulta la sezione Configurazione dei flag di database.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Istanze Cloud SQL nella console Google Cloud .

    Vai a Istanze Cloud SQL

  2. Seleziona l'istanza elencata nel risultato di Security Health Analytics.

  3. Fai clic su Modifica.

  4. Nella sezione Flag di database, imposta il flag di database log_temp_files con il valore 0.

  5. Fai clic su Salva. La nuova configurazione viene visualizzata nella pagina Panoramica dell'istanza.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

SQL no root password

Nome della categoria nell'API: SQL_NO_ROOT_PASSWORD

Per l'istanza del database MySQL non è impostata una password per l'account root. Devi aggiungere una password all'istanza del database MySQL. Per ulteriori informazioni, vedi Utenti MySQL.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Istanze Cloud SQL nella consoleGoogle Cloud .

    Vai a Istanze Cloud SQL

  2. Seleziona l'istanza elencata nel risultato di Security Health Analytics.

  3. Nella pagina Dettagli istanza visualizzata, seleziona la scheda Utenti.

  4. Accanto all'utente root, fai clic su Altro e seleziona Cambia password.

  5. Inserisci una nuova password efficace e fai clic su Ok.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

SQL public IP

Nome della categoria nell'API: SQL_PUBLIC_IP

Un database Cloud SQL ha un indirizzo IP pubblico.

Per ridurre la superficie di attacco della tua organizzazione, i database Cloud SQL non devono avere indirizzi IP pubblici. Gli indirizzi IP privati offrono maggiore sicurezza di rete e minore latenza per l'applicazione.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Istanze Cloud SQL nella console Google Cloud .

    Vai a Istanze Cloud SQL

  2. Seleziona l'istanza elencata nel risultato di Security Health Analytics.

  3. Nel menu a sinistra, fai clic su Connessioni.

  4. Fai clic sulla scheda Networking e deseleziona la casella di controllo IP pubblico.

  5. Se l'istanza non è già configurata per l'utilizzo di un IP privato, consulta Configurazione dell'IP privato per un'istanza esistente.

  6. Fai clic su Salva.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

SQL remote access enabled

Nome della categoria nell'API: SQL_REMOTE_ACCESS_ENABLED

Un'istanza di database Cloud SQL per SQL Server non ha il flag di database remote access impostato su Off.

Quando è attiva, questa impostazione concede l'autorizzazione per eseguire stored procedure locali da server remoti o stored procedure remote dal server locale. Questa funzionalità può essere utilizzata in modo illecito per lanciare un attacco denial of service (DoS) su server remoti trasferendo l'elaborazione delle query a una destinazione. Per evitare abusi, ti consigliamo di disattivare questa impostazione.

Per maggiori informazioni, consulta la pagina Configurazione dei flag di database.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Istanze Cloud SQL nella consoleGoogle Cloud .

    Vai a Istanze Cloud SQL

  2. Seleziona l'istanza elencata nel risultato di Security Health Analytics.

  3. Fai clic su Modifica.

  4. Nella sezione Flag, imposta remote access su Off.

  5. Fai clic su Salva. La nuova configurazione viene visualizzata nella pagina Panoramica dell'istanza.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

SQL skip show database disabled

Nome della categoria nell'API: SQL_SKIP_SHOW_DATABASE_DISABLED

Un'istanza di database Cloud SQL per MySQL non ha il flag di database skip_show_database impostato su On.

Quando è attivato, questo flag impedisce agli utenti di utilizzare l'istruzione SHOW DATABASES se non hanno il privilegio SHOW DATABASES. Con questa impostazione, gli utenti senza autorizzazione esplicita non possono visualizzare i database che appartengono ad altri utenti. Ti consigliamo di attivare questo flag.

Per ulteriori informazioni, consulta la pagina Configurazione dei flag di database.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Istanze Cloud SQL nella consoleGoogle Cloud .

    Vai a Istanze Cloud SQL

  2. Seleziona l'istanza elencata nel risultato di Security Health Analytics.

  3. Fai clic su Modifica.

  4. Nella sezione Flag, imposta skip_show_database su On.

  5. Fai clic su Salva. La nuova configurazione viene visualizzata nella pagina Panoramica dell'istanza.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

SQL trace flag 3625

Nome della categoria nell'API: SQL_TRACE_FLAG_3625

Un'istanza di database Cloud SQL per SQL Server non ha il flag di database 3625 (flag di traccia) impostato su On.

Questo flag limita la quantità di informazioni restituite agli utenti che non sono membri del ruolo predefinito del server sysadmin, mascherando i parametri di alcuni messaggi di errore con asterischi (******). Per evitare la divulgazione di informazioni sensibili, ti consigliamo di attivare questo flag.

Per maggiori informazioni, consulta la pagina Configurazione dei flag di database.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Istanze Cloud SQL nella consoleGoogle Cloud .

    Vai a Istanze Cloud SQL

  2. Seleziona l'istanza elencata nel risultato di Security Health Analytics.

  3. Fai clic su Modifica.

  4. Nella sezione Flag di database, imposta 3625 su On.

  5. Fai clic su Salva. La nuova configurazione viene visualizzata nella pagina Panoramica dell'istanza.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

SQL user connections configured

Nome della categoria nell'API: SQL_USER_CONNECTIONS_CONFIGURED

Un'istanza di database Cloud SQL per SQL Server ha il flag di database user connections configurato.

L'opzione user connections specifica il numero massimo di connessioni utente simultanee consentite in un'istanza SQL Server. Poiché è un'opzione dinamica (con autoconfigurazione), SQL Server regola automaticamente il numero massimo di connessioni utente necessarie in base alle esigenze, fino al valore massimo consentito. Il valore predefinito è 0, il che significa che sono consentite fino a 32.767 connessioni utente. Per questo motivo, non è consigliabile configurare il flag di database user connections.

Per maggiori informazioni, consulta la pagina Configurazione dei flag di database.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Istanze Cloud SQL nella consoleGoogle Cloud .

    Vai a Istanze Cloud SQL

  2. Seleziona l'istanza elencata nel risultato di Security Health Analytics.

  3. Fai clic su Modifica.

  4. Nella sezione Flag di database, accanto a user connections, fai clic su Elimina.

  5. Fai clic su Salva. La nuova configurazione viene visualizzata nella pagina Panoramica dell'istanza.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

SQL user options configured

Nome della categoria nell'API: SQL_USER_OPTIONS_CONFIGURED

Un'istanza di database Cloud SQL per SQL Server ha il flag di database user options configurato.

Questa impostazione sostituisce i valori predefiniti globali delle opzioni SET per tutti gli utenti. Poiché gli utenti e le applicazioni potrebbero utilizzare le opzioni SET di database predefinite, l'impostazione delle opzioni utente potrebbe causare risultati imprevisti. Per questo motivo, non è consigliabile configurare il flag di database user options.

Per maggiori informazioni, consulta la pagina Configurazione dei flag di database.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Istanze Cloud SQL nella consoleGoogle Cloud .

    Vai a Istanze Cloud SQL

  2. Seleziona l'istanza elencata nel risultato di Security Health Analytics.

  3. Fai clic su Modifica.

  4. Nella sezione Flag di database, accanto a user options, fai clic su Elimina.

  5. Fai clic su Salva. La nuova configurazione viene visualizzata nella pagina Panoramica dell'istanza.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

SQL weak root password

Nome della categoria nell'API: SQL_WEAK_ROOT_PASSWORD

In un'istanza del database MySQL è impostata una password debole per l'account root. Devi impostare una password efficace per l'istanza. Per ulteriori informazioni, consulta Utenti MySQL.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Istanze Cloud SQL nella console Google Cloud .

    Vai a Istanze Cloud SQL

  2. Seleziona l'istanza elencata nel risultato di Security Health Analytics.

  3. Nella pagina Dettagli istanza visualizzata, seleziona la scheda Utenti.

  4. Accanto all'utente root, fai clic su Altro e seleziona Cambia password.

  5. Inserisci una nuova password efficace e fai clic su Ok.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

SSL not enforced

Nome della categoria nell'API: SSL_NOT_ENFORCED

Un'istanza del database Cloud SQL non richiede che tutte le connessioni in entrata utilizzino SSL.

Per evitare fughe di dati sensibili in transito tramite comunicazioni non criptate, tutte le connessioni in entrata nell'istanza di database SQL devono utilizzare SSL. Scopri di più sulla configurazione di SSL/TLS.

Per risolvere questo problema, consenti solo connessioni SSL per le tue istanze SQL:

  1. Vai alla pagina Istanze Cloud SQL nella console Google Cloud .

    Vai a Istanze Cloud SQL

  2. Seleziona l'istanza elencata nel risultato di Security Health Analytics.

  3. Nella scheda Connessioni, fai clic su Consenti solo connessioni SSL o Richiedi certificati client attendibili. Per maggiori informazioni, consulta Applicare la crittografia SSL/TLS.

  4. Se hai scelto Richiedi certificati client attendibili, crea un nuovo certificato client. Per saperne di più, vedi Creare un nuovo certificato client.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Too many KMS users

Nome della categoria nell'API: TOO_MANY_KMS_USERS

Limita a tre il numero di utenti principali che possono utilizzare le chiavi di crittografia. I seguenti ruoli predefiniti concedono le autorizzazioni per criptare, decriptare o firmare i dati utilizzando chiavi di crittografia:

  • roles/owner
  • roles/cloudkms.cryptoKeyEncrypterDecrypter
  • roles/cloudkms.cryptoKeyEncrypter
  • roles/cloudkms.cryptoKeyDecrypter
  • roles/cloudkms.signer
  • roles/cloudkms.signerVerifier

Per maggiori informazioni, vedi Autorizzazioni e ruoli.

Per le attivazioni a livello di progetto del livello Security Command Center Premium, questo risultato è disponibile solo se il livello Standard è abilitato nell'organizzazione principale.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Chiavi Cloud KMS nella console Google Cloud .

    Vai a Chiavi Cloud KMS

  2. Fai clic sul nome del keyring indicato nel risultato.

  3. Fai clic sul nome della chiave indicata nel risultato.

  4. Seleziona la casella accanto alla versione principale, quindi fai clic su Mostra riquadro informazioni.

  5. Riduci il numero di entità con autorizzazioni per criptare, decriptare o firmare i dati a un massimo di tre. Per revocare le autorizzazioni, fai clic su Elimina accanto a ogni entità.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Unconfirmed AppArmor profile

Nome della categoria nell'API: GKE_APP_ARMOR

Un container può essere configurato esplicitamente per non essere limitato da AppArmor. In questo modo si garantisce che al container non venga applicato alcun profilo AppArmor e che quindi non sia vincolato da un profilo. Se si disabilita il controllo di sicurezza preventivo aumenta il rischio di attacco container escape.

Per correggere questo problema, applica i seguenti passaggi ai tuoi workload interessati:

  1. Apri il manifest per ogni workload interessato.
  2. Imposta i seguenti campi con restrizioni su uno dei valori consentiti.

Campi con limitazioni

  • metadata.annotations["container.apparmor.security.beta.kubernetes.io/*"]

Valori consentiti

  • falso

User managed service account key

Nome della categoria nell'API: USER_MANAGED_SERVICE_ACCOUNT_KEY

Un utente gestisce una chiave del account di servizio. Le chiavi dei service account rappresentano un rischio per la sicurezza se non vengono gestite correttamente. Dovresti scegliere un'alternativa più sicura alle account di servizio account quando è possibile. Se devi eseguire l'autenticazione con una chiave dell'account di servizio, sei responsabile della sicurezza della chiave privata e di altre operazioni descritte in Best practice per la gestione delle chiavi degli account di servizio. Se non riesci a creare una chiave del account di servizio, la creazione di chiavi del account di servizio potrebbe essere disabilitata per la tua organizzazione. Per saperne di più, vedi Gestione delle risorse dell'organizzazione sicure per impostazione predefinita.

Se hai acquisito la chiave dell'account di servizio da una fonte esterna, devi convalidarla prima dell'uso. Per maggiori informazioni, consulta Requisiti di sicurezza per le credenziali di origine esterna.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Vai alla pagina Service account nella console Google Cloud .

    Vai a Service account

  2. Se necessario, seleziona il progetto indicato nel risultato.

  3. Elimina le chiavi dei account di servizio gestiti dall'utente indicate nel risultato, se non vengono utilizzate da alcuna applicazione.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Weak SSL policy

Nome della categoria nell'API: WEAK_SSL_POLICY

Un'istanza di Compute Engine ha un criterio SSL debole o utilizza il criterio SSL predefinito con una versione TLS inferiore a 1.2. Google Cloud

I bilanciatori del carico HTTPS e del proxy SSL utilizzano i criteri SSL per determinare il protocollo e i pacchetti di crittografia utilizzati nelle connessioni TLS stabilite tra gli utenti e internet. Queste connessioni criptano i dati sensibili per proteggerli da intercettazioni dannose. Un criterio SSL debole consente ai client che utilizzano versioni obsolete di TLS di connettersi a un protocollo o a un pacchetto di crittografia meno sicuri. Per un elenco di suite di crittografia consigliate e obsolete, visita la pagina relativa ai parametri TLS su iana.org.

Per le attivazioni a livello di progetto del livello Security Command Center Premium, questo risultato è disponibile solo se il livello Standard è abilitato nell'organizzazione principale.

I passaggi di correzione per questo risultato variano a seconda che sia stato attivato dall'utilizzo di un criterio SSL Google Cloud predefinito o di un criterio SSL che consente una suite di crittografia debole o una versione TLS minima inferiore a 1.2. Segui la procedura riportata di seguito corrispondente al trigger del risultato.

Correzione della policy SSL Google Cloud predefinita

  1. Vai alla pagina Proxy di destinazione nella console Google Cloud .

    Vai a Proxy di destinazione

  2. Trova il proxy di destinazione indicato nel risultato e prendi nota delle regole di forwarding nella colonna Utilizzato da.

  3. Per creare una nuova policy SSL, consulta Utilizzo dei criteri SSL. Il criterio deve avere una versione TLS minima di 1.2 e un profilo con restrizioni o moderno.

  4. Per utilizzare un profilo personalizzato , assicurati che le seguenti suite di crittografia siano disattivate:

    • TLS_RSA_WITH_AES_128_GCM_SHA256
    • TLS_RSA_WITH_AES_256_GCM_SHA384
    • TLS_RSA_WITH_AES_128_CBC_SHA
    • TLS_RSA_WITH_AES_256_CBC_SHA
    • TLS_RSA_WITH_3DES_EDE_CBC_SHA

  5. Applica la policy SSL a ogni regola di forwarding osservata in precedenza.

Correzione consentita per suite di crittografia debole o versione TLS di livello inferiore

  1. Nella console Google Cloud , vai alla pagina Policy SSL .

    Vai a Policy SSL

  2. Trova il bilanciatore del carico indicato nella colonna Utilizzato da.

  3. Fai clic sotto il nome della norma.

  4. Fai clic su Modifica.

  5. Modifica Versione TLS minima impostandola su TLS 1.2 e Profilo su Moderno o Con restrizioni.

  6. Per utilizzare un profilo personalizzato, assicurati che le seguenti suite di crittografia siano disattivate:

    • TLS_RSA_WITH_AES_128_GCM_SHA256
    • TLS_RSA_WITH_AES_256_GCM_SHA384
    • TLS_RSA_WITH_AES_128_CBC_SHA
    • TLS_RSA_WITH_AES_256_CBC_SHA
    • TLS_RSA_WITH_3DES_EDE_CBC_SHA

  7. Fai clic su Salva.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Web UI enabled

Nome della categoria nell'API: WEB_UI_ENABLED

L'interfaccia utente web (dashboard) di GKE è abilitata.

Un service account Kubernetes con privilegi elevati supporta l'interfaccia web di Kubernetes. Se compromesso, il account di servizio può essere utilizzato in modo illecito. Se stai già utilizzando la Google Cloud console, la UI web di Kubernetes aumenta inutilmente la superficie di attacco. Scopri di più sulla disattivazione dell'interfaccia web di Kubernetes.

Per risolvere questo problema, disattiva l'interfaccia web di Kubernetes:

  1. Vai alla pagina Cluster Kubernetes nella console Google Cloud .

    Vai ai cluster Kubernetes

  2. Fai clic sul nome del cluster elencato nel risultato di Security Health Analytics.

  3. Fai clic su Modifica.

    Se la configurazione del cluster è stata cambiata di recente, il pulsante di modifica potrebbe essere disabilitato. Se non riesci a modificare le impostazioni del cluster, attendi alcuni minuti e riprova.

  4. Fai clic su Componenti aggiuntivi. La sezione si espande per mostrare i componenti aggiuntivi disponibili.

  5. Nell'elenco a discesa Dashboard Kubernetes, seleziona Disabilitata.

  6. Fai clic su Salva.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Workload Identity disabled

Nome della categoria nell'API: WORKLOAD_IDENTITY_DISABLED

Workload Identity è disabilitato su un cluster GKE.

Workload Identity è il metodo consigliato per accedere ai servizi Google Cloud dall'interno di GKE, grazie al miglioramento delle sue proprietà di sicurezza e della sua gestibilità. Abilitando questo servizio puoi proteggere alcuni metadati di sistema potenzialmente sensibili dai carichi di lavoro degli utenti in esecuzione nel cluster. Scopri di più sull'occultamento dei metadati.

Per risolvere questo problema, segui la guida per abilitare Workload Identity in un cluster.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Correggere le configurazioni errate di AWS

AWS Cloud Shell Full Access Restricted

Nome della categoria nell'API: ACCESS_AWSCLOUDSHELLFULLACCESS_RESTRICTED

AWS CloudShell è un modo pratico per eseguire comandi CLI sui servizi AWS. Una policy IAM gestita ("AWSCloudShellFullAccess") fornisce l'accesso completo a CloudShell, che consente la funzionalità di caricamento e download di file tra il sistema locale di un utente e l'ambiente CloudShell. Nell'ambiente Cloud Shell, un utente dispone delle autorizzazioni sudo e può accedere a internet. Pertanto, è possibile installare un software di trasferimento di file (ad esempio) e spostare i dati da Cloud Shell a server internet esterni.

Consiglio: assicurati che l'accesso ad AWSCloudShellFullAccess sia limitato

Per risolvere questo problema, completa i seguenti passaggi:

Console AWS

  1. Apri la console IAM all'indirizzo https://console.aws.amazon.com/iam/
  2. Nel riquadro a sinistra, seleziona Norme.
  3. Cerca e seleziona AWSCloudShellFullAccess
  4. Nella scheda Entità allegate, seleziona la casella per ogni elemento e scegli Scollega.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Access Keys Rotated Every 90 Days or Less

Nome della categoria nell'API: ACCESS_KEYS_ROTATED_90_DAYS_LESS

Le chiavi di accesso sono costituite da un ID chiave di accesso e da una chiave di accesso segreta, che vengono utilizzati per firmare le richieste programmatiche che invii ad AWS. Gli utenti AWS hanno bisogno delle proprie chiavi di accesso per effettuare chiamate programmatiche ad AWS dall'interfaccia a riga di comando AWS (AWS CLI), dagli strumenti per Windows PowerShell, dagli SDK AWS o da chiamate HTTP dirette utilizzando le API per i singoli servizi AWS. Ti consigliamo di ruotare regolarmente tutte le chiavi di accesso.

Consiglio: assicurati che le chiavi di accesso vengano ruotate ogni 90 giorni o meno

Per risolvere questo problema, completa i seguenti passaggi:

Console AWS

  1. Vai alla console di gestione (https://console.aws.amazon.com/iam)
  2. Fai clic su Users.
  3. Fai clic su Security Credentials.
  4. Come amministratore
    - Fai clic su Make Inactive per le chiavi che non sono state ruotate in 90 giorni
  5. In qualità di utente IAM
    - Fai clic su Make Inactive o Delete per le chiavi che non sono state ruotate o utilizzate in 90 giorni
  6. Fai clic su Create Access Key.
  7. Aggiorna la chiamata programmatica con le nuove credenziali della chiave di accesso

Interfaccia a riga di comando AWS

  1. Mentre la prima chiave di accesso è ancora attiva, crea una seconda chiave di accesso, che è attiva per impostazione predefinita. Esegui questo comando:
aws iam create-access-key

A questo punto, l'utente ha due chiavi di accesso attive.

  1. Aggiorna tutte le applicazioni e gli strumenti per utilizzare la nuova chiave di accesso.
  2. Determina se la prima chiave di accesso è ancora in uso utilizzando questo comando:
aws iam get-access-key-last-used
  1. Un approccio consiste nell'attendere diversi giorni e poi controllare se la vecchia chiave di accesso è stata utilizzata prima di procedere.

Anche se il passaggio 3 indica che la vecchia chiave non viene utilizzata, ti consigliamo di non eliminare immediatamente la prima chiave di accesso. Modifica invece lo stato della prima chiave di accesso in Inattiva utilizzando questo comando:

aws iam update-access-key

  1. Utilizza solo la nuova chiave di accesso per verificare che le tue applicazioni funzionino. Le applicazioni e gli strumenti che utilizzano ancora la chiave di accesso originale smetteranno di funzionare a questo punto perché non hanno più accesso alle risorse AWS. Se trovi un'applicazione o uno strumento di questo tipo, puoi ripristinarne lo stato su Attivo per riattivare la prima chiave di accesso. Quindi torna al passaggio 2 e aggiorna questa applicazione per utilizzare la nuova chiave.

  2. Dopo aver atteso un po' di tempo per assicurarti che tutte le applicazioni e tutti gli strumenti siano stati aggiornati, puoi eliminare la prima chiave di accesso con questo comando:

aws iam delete-access-key

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

All Expired Ssl Tls Certificates Stored Aws Iam Removed

Nome della categoria nell'API: ALL_EXPIRED_SSL_TLS_CERTIFICATES_STORED_AWS_IAM_REMOVED

Per attivare le connessioni HTTPS al tuo sito web o alla tua applicazione in AWS, devi disporre di un certificato del server SSL/TLS. Puoi utilizzare ACM o IAM per archiviare ed eseguire il deployment dei certificati server.
Utilizza IAM come gestore dei certificati solo quando devi supportare le connessioni HTTPS in una regione non supportata da ACM. IAM cripta in modo sicuro le tue chiavi private e memorizza la versione criptata nell'archivio dei certificati SSL di IAM. IAM supporta il deployment dei certificati server in tutte le regioni, ma devi ottenere il certificato da un provider esterno per utilizzarlo con AWS. Non puoi caricare un certificato ACM in IAM. Inoltre, non puoi gestire i certificati dalla console IAM.

Consiglio: verifica che tutti i certificati SSL/TLS scaduti archiviati in AWS IAM vengano rimossi

Per risolvere questo problema, completa i seguenti passaggi:

Console AWS

La rimozione dei certificati scaduti tramite la console di gestione AWS non è attualmente supportata. Per eliminare i certificati SSL/TLS archiviati in IAM tramite l'API AWS, utilizza l'interfaccia a riga di comando (CLI).

Interfaccia a riga di comando AWS

Per eliminare il certificato scaduto, esegui il comando seguente sostituendo CERTIFICATE_NAME con il nome del certificato da eliminare:

aws iam delete-server-certificate --server-certificate-name <CERTIFICATE_NAME>

Quando il comando precedente ha esito positivo, non restituisce alcun output.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Autoscaling Group Elb Healthcheck Required

Nome della categoria nell'API: AUTOSCALING_GROUP_ELB_HEALTHCHECK_REQUIRED

Controlla se i gruppi di scalabilità automatica associati a un bilanciatore del carico utilizzano i controlli di integrità di Elastic Load Balancing.

In questo modo, il gruppo può determinare l'integrità di un'istanza in base a test aggiuntivi forniti dal bilanciatore del carico. L'utilizzo dei controlli di integrità di Elastic Load Balancing può contribuire a supportare la disponibilità delle applicazioni che utilizzano i gruppi di scalabilità automatica EC2.

Consiglio: controlla che tutti i gruppi di scalabilità automatica associati a un bilanciatore del carico utilizzino controlli di integrità

Per risolvere questo problema, completa i seguenti passaggi:

Console AWS

Per abilitare i controlli di integrità di Elastic Load Balancing

  1. Apri la console Amazon EC2 all'indirizzo https://console.aws.amazon.com/ec2/.
  2. Nel riquadro di navigazione, in Scalabilità automatica, scegli Gruppi di scalabilità automatica.
  3. Seleziona la casella di controllo relativa al gruppo.
  4. Scegli Modifica.
  5. In Controlli di integrità, per Tipo di controllo di integrità, scegli ELB.
  6. Per il periodo di tolleranza del controllo di integrità, inserisci 300.
  7. In fondo alla pagina, scegli Aggiorna.

Per ulteriori informazioni sull'utilizzo di un bilanciatore del carico con un gruppo di scalabilità automatica, consulta la guida per l'utente di AWS Auto Scaling.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Auto Minor Version Upgrade Feature Enabled Rds Instances

Nome della categoria nell'API: AUTO_MINOR_VERSION_UPGRADE_FEATURE_ENABLED_RDS_INSTANCES

Assicurati che le istanze del database RDS abbiano il flag di upgrade automatico della versione secondaria abilitato per ricevere automaticamente gli upgrade secondari del motore durante la periodo di manutenzione specificata. In questo modo, le istanze RDS possono ottenere le nuove funzionalità, le correzioni di bug e le patch di sicurezza per i motori di database.

Consiglio: assicurati che la funzionalità di upgrade automatico della versione secondaria sia abilitata per le istanze RDS

Per risolvere questo problema, completa i seguenti passaggi:

Console AWS

  1. Accedi alla Console di gestione AWS e vai al pannello di controllo RDS all'indirizzo https://console.aws.amazon.com/rds/.
  2. Nel pannello di navigazione a sinistra, fai clic su Databases.
  3. Seleziona l'istanza RDS da aggiornare.
  4. Fai clic sul pulsante Modify in alto a destra.
  5. Nella pagina Modify DB Instance: <instance identifier>, nella sezione Maintenance, seleziona Auto minor version upgrade e fai clic sul pulsante di opzione Yes.
  6. Nella parte inferiore della pagina, fai clic su Continue, seleziona Applica immediatamente per applicare subito le modifiche o seleziona Apply during the next scheduled maintenance window per evitare tempi di inattività.
  7. Esamina le modifiche e fai clic su Modify DB Instance. Lo stato dell'istanza dovrebbe passare da disponibile a in fase di modifica e tornare a disponibile. Una volta attivata la funzionalità, lo stato di Auto Minor Version Upgrade dovrebbe cambiare in Yes.

Interfaccia a riga di comando AWS

  1. Esegui il comando describe-db-instances per elencare tutti i nomi delle istanze di database RDS disponibili nella regione AWS selezionata:
aws rds describe-db-instances --region <regionName> --query 'DBInstances[*].DBInstanceIdentifier'
  1. L'output del comando deve restituire l'identificatore di ogni istanza di database.
  2. Esegui il comando modify-db-instance per modificare la configurazione dell'istanza RDS selezionata. Questo comando applicherà immediatamente le modifiche. Rimuovi --apply-immediately per applicare le modifiche durante il successivo periodo di manutenzione pianificato ed evitare tempi di inattività:
aws rds modify-db-instance --region <regionName> --db-instance-identifier <dbInstanceIdentifier> --auto-minor-version-upgrade --apply-immediately
  1. L'output del comando deve mostrare i nuovi metadati di configurazione per l'istanza RDS e controllare valore parametro AutoMinorVersionUpgrade.
  2. Esegui il comando describe-db-instances per verificare se la funzionalità di upgrade automatico della versione secondaria è stata abilitata correttamente:
aws rds describe-db-instances --region <regionName> --db-instance-identifier <dbInstanceIdentifier> --query 'DBInstances[*].AutoMinorVersionUpgrade'
  1. L'output del comando deve restituire lo stato attuale della funzionalità impostato su true, la funzionalità è enabled e gli upgrade del motore secondario verranno applicati all'istanza RDS selezionata.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Aws Config Enabled All Regions

Nome della categoria nell'API: AWS_CONFIG_ENABLED_ALL_REGIONS

AWS Config è un servizio web che esegue la gestione della configurazione delle risorse AWS supportate all'interno del tuo account e ti fornisce i file di log. Le informazioni registrate includono l'elemento di configurazione (risorsa AWS), le relazioni tra gli elementi di configurazione (risorse AWS) e le modifiche alla configurazione tra le risorse. Ti consigliamo di abilitare AWS Config in tutte le regioni.

Consiglio: assicurati che AWS Config sia abilitato in tutte le regioni

Per risolvere questo problema, completa i seguenti passaggi:

Console AWS

  1. Seleziona la regione su cui vuoi concentrarti in alto a destra nella console.
  2. Fai clic su Servizi.
  3. Fai clic su Configurazione.
  4. Se in questa regione è attivato un registratore di configurazione, devi andare alla pagina Impostazioni dal menu di navigazione a sinistra. Se un registratore di configurazione non è ancora abilitato in questa regione, seleziona "Inizia".
  5. Seleziona "Registra tutte le risorse supportate in questa regione".
  6. Scegli di includere le risorse globali (risorse IAM)
  7. Specifica un bucket S3 nello stesso account o in un altro account AWS gestito
  8. Crea un argomento SNS dallo stesso account AWS o da un altro account AWS gestito

Interfaccia a riga di comando AWS

  1. Assicurati che esista un bucket S3, un argomento SNS e un ruolo IAM appropriati in base ai prerequisiti del servizio AWS Config.
  2. Esegui questo comando per creare un nuovo registratore di configurazione:
aws configservice put-configuration-recorder --configuration-recorder name=default,roleARN=arn:aws:iam::012345678912:role/myConfigRole --recording-group allSupported=true,includeGlobalResourceTypes=true
  1. Crea localmente un file di configurazione del canale di distribuzione che specifichi gli attributi del canale, compilati in base ai prerequisiti configurati in precedenza:
{
 "name": "default",
 "s3BucketName": "my-config-bucket",
 "snsTopicARN": "arn:aws:sns:us-east-1:012345678912:my-config-notice",
 "configSnapshotDeliveryProperties": {
 "deliveryFrequency": "Twelve_Hours"
 }
}
  1. Esegui questo comando per creare un nuovo canale di distribuzione, facendo riferimento al file di configurazione JSON creato nel passaggio precedente:
aws configservice put-delivery-channel --delivery-channel file://deliveryChannel.json
  1. Avvia il registratore della configurazione eseguendo il seguente comando:
aws configservice start-configuration-recorder --configuration-recorder-name default

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Aws Security Hub Enabled

Nome della categoria nell'API: AWS_SECURITY_HUB_ENABLED

Security Hub raccoglie i dati di sicurezza da account, servizi e prodotti partner di terze parti supportati di AWS e ti aiuta ad analizzare le tendenze di sicurezza e a identificare i problemi di sicurezza con la priorità più alta. Quando abiliti Security Hub, inizia a utilizzare, aggregare, organizzare e dare la priorità ai risultati dei servizi AWS che hai abilitato, come Amazon GuardDuty, Amazon Inspector e Amazon Macie. Puoi anche attivare le integrazioni con i prodotti di sicurezza dei partner AWS.

Consiglio: assicurati che AWS Security Hub sia abilitato

Per risolvere questo problema, completa i seguenti passaggi:

Console AWS

  1. Utilizza le credenziali dell'identità IAM per accedere alla console Security Hub.
  2. Quando apri la console Security Hub per la prima volta, scegli Enable AWS Security Hub (Abilita AWS Security Hub).
  3. Nella pagina di benvenuto, l'elenco Standard di sicurezza elenca gli standard di sicurezza supportati da Security Hub.
  4. Scegli Abilita Security Hub.

Interfaccia a riga di comando AWS

  1. Esegui il comando enable-security-hub. Per attivare gli standard predefiniti, includi --enable-default-standards.
aws securityhub enable-security-hub --enable-default-standards
  1. Per attivare l'hub di sicurezza senza gli standard predefiniti, includi --no-enable-default-standards.
aws securityhub enable-security-hub --no-enable-default-standards

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Cloudtrail Logs Encrypted Rest Using Kms Cmks

Nome della categoria nell'API: CLOUDTRAIL_LOGS_ENCRYPTED_REST_USING_KMS_CMKS

AWS CloudTrail è un servizio web che registra le chiamate API AWS per un account e rende disponibili questi log a utenti e risorse in conformità con le policy IAM. AWS Key Management Service (KMS) è un servizio gestito che consente di creare e controllare le chiavi di crittografia utilizzate per criptare i dati dell'account e utilizza moduli di sicurezza hardware (HSM) per proteggere la sicurezza delle chiavi di crittografia. I log di CloudTrail possono essere configurati per sfruttare la crittografia lato server (SSE) e le chiavi master create dal cliente (CMK) di KMS per proteggere ulteriormente i log di CloudTrail. Ti consigliamo di configurare CloudTrail in modo che utilizzi SSE-KMS.

Consiglio: verifica che i log di CloudTrail siano crittografati at-rest mediante chiavi CMK di KMS

Per risolvere questo problema, completa i seguenti passaggi:

Console AWS

  1. Accedi alla console di gestione AWS e apri la console CloudTrail all'indirizzo https://console.aws.amazon.com/cloudtrail.
  2. Nel riquadro di navigazione a sinistra, scegli Trails .
  3. Fai clic su un sentiero.
  4. Nella sezione S3, fai clic sul pulsante di modifica (icona a forma di matita).
  5. Fai clic su Advanced.
  6. Seleziona una CMK esistente dal menu a discesa KMS key Id
    - Nota: assicurati che la CMK si trovi nella stessa regione del bucket S3
    - Nota: dovrai applicare una policy della chiave KMS alla CMK selezionata affinché CloudTrail come servizio possa criptare e decriptare i file di log utilizzando la CMK fornita. I passaggi per modificare la policy della chiave CMK selezionata sono disponibili qui.
  7. Fai clic su Save.
  8. Viene visualizzato un messaggio di notifica che indica che devi disporre delle autorizzazioni di decriptazione per la chiave KMS specificata per decriptare i file di log.
  9. Fai clic su Yes.

Interfaccia a riga di comando AWS

aws cloudtrail update-trail --name <trail_name> --kms-id <cloudtrail_kms_key>
aws kms put-key-policy --key-id <cloudtrail_kms_key> --policy <cloudtrail_kms_key_policy>

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Cloudtrail Log File Validation Enabled

Nome della categoria nell'API: CLOUDTRAIL_LOG_FILE_VALIDATION_ENABLED

La convalida del file di log di CloudTrail crea un file di riepilogo firmato digitalmente contenente un hash di ogni log che CloudTrail scrive in S3. Questi file di riepilogo possono essere utilizzati per determinare se un file di log è stato modificato, eliminato o lasciato invariato dopo la distribuzione del log da parte di CloudTrail. Ti consigliamo di abilitare la convalida dei file su tutti i CloudTrail.

Consiglio: assicurati che la convalida del file di log di CloudTrail sia abilitata

Per risolvere questo problema, completa i seguenti passaggi:

Console AWS

  1. Accedi alla console di gestione AWS e apri la console IAM all'indirizzo https://console.aws.amazon.com/cloudtrail.
  2. Fai clic su Trails nel riquadro di navigazione a sinistra.
  3. Fai clic sul percorso del target.
  4. Nella sezione General details, fai clic su edit.
  5. Nella sezione Advanced settings
  6. Seleziona la casella di attivazione nella sezione Log file validation.
  7. Fai clic su Save changes.

Interfaccia a riga di comando AWS

aws cloudtrail update-trail --name <trail_name> --enable-log-file-validation

Tieni presente che la convalida periodica dei log utilizzando questi digest può essere eseguita eseguendo il seguente comando:

aws cloudtrail validate-logs --trail-arn <trail_arn> --start-time <start_time> --end-time <end_time>

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Cloudtrail Trails Integrated Cloudwatch Logs

Nome della categoria nell'API: CLOUDTRAIL_TRAILS_INTEGRATED_CLOUDWATCH_LOGS

AWS CloudTrail è un servizio web che registra le chiamate API AWS effettuate in un determinato account AWS. Le informazioni registrate includono l'identità del chiamante API, l'ora della chiamata API, l'indirizzo IP di origine del chiamante API, i parametri della richiesta e gli elementi di risposta restituiti dal servizio AWS. CloudTrail utilizza Amazon S3 per l'archiviazione e la distribuzione dei file di log, pertanto i file di log vengono archiviati in modo duraturo. Oltre ad acquisire i log CloudTrail all'interno di un bucket S3 specificato per l'analisi a lungo termine, è possibile eseguire l'analisi in tempo reale configurando CloudTrail in modo che invii i log a CloudWatch Logs. Per un trail abilitato in tutte le regioni di un account, CloudTrail invia i file di log di tutte queste regioni a un gruppo di log CloudWatch Logs. Ti consigliamo di inviare i log di CloudTrail a CloudWatch Logs.

Nota: lo scopo di questo consiglio è garantire che l'attività dell'account AWS venga acquisita, monitorata e segnalata in modo appropriato. CloudWatch Logs è un modo nativo per farlo utilizzando i servizi AWS, ma non esclude l'utilizzo di una soluzione alternativa.

Consiglio: assicurati che i trail di CloudTrail siano integrati con i log di CloudWatch

Per risolvere questo problema, completa i seguenti passaggi:

Console AWS

  1. Accedi alla console CloudTrail all'indirizzo https://console.aws.amazon.com/cloudtrail/
  2. Seleziona l'Trail da aggiornare.
  3. Scorri verso il basso fino a CloudWatch Logs.
  4. Fai clic su Edit.
  5. In CloudWatch Logs, fai clic sulla casella Enabled.
  6. In Log Group scegli un gruppo di log nuovo o selezionane uno esistente.
  7. Modifica Log group name in modo che corrisponda a CloudTrail o scegli il gruppo CloudWatch esistente.
  8. In IAM Role, scegli una nuova opzione o selezionane una esistente.
  9. Modifica Role name in modo che corrisponda a CloudTrail o scegli il ruolo IAM esistente.
  10. Fai clic su "Salva modifiche".

Interfaccia a riga di comando AWS

aws cloudtrail update-trail --name <trail_name> --cloudwatch-logs-log-group-arn <cloudtrail_log_group_arn> --cloudwatch-logs-role-arn <cloudtrail_cloudwatchLogs_role_arn>

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Cloudwatch Alarm Action Check

Nome della categoria nell'API: CLOUDWATCH_ALARM_ACTION_CHECK

Controlla se Amazon CloudWatch ha azioni definite quando un allarme passa tra gli stati "OK", "ALARM" e "INSUFFICIENT_DATA".

La configurazione delle azioni per lo stato ALLARME negli allarmi Amazon CloudWatch è molto importante per attivare una risposta immediata quando le metriche monitorate superano le soglie.
Garantisce una rapida risoluzione dei problemi, riduce i tempi di inattività e consente la correzione automatizzata, mantenendo l'integrità del sistema e prevenendo interruzioni.

Gli allarmi hanno almeno un'azione.
Gli allarmi hanno almeno un'azione quando passano allo stato "INSUFFICIENT_DATA" da qualsiasi altro stato.
(Facoltativo) Gli allarmi hanno almeno un'azione quando l'allarme passa allo stato "OK" da qualsiasi altro stato.

Consiglio: controlla se per gli allarmi CloudWatch è abilitata almeno un'azione allarme, un'azione INSUFFICIENT_DATA o un'azione Ok.

Per risolvere questo problema, completa i seguenti passaggi:

Console AWS

Per configurare le azioni ALARM per gli allarmi Amazon CloudWatch:

  1. Apri la console Amazon CloudWatch all'indirizzo https://console.aws.amazon.com/cloudwatch/.
  2. Nel riquadro di navigazione, in "Allarmi", seleziona "Tutti gli allarmi".
  3. Scegli l'allarme Amazon CloudWatch che vuoi modificare, seleziona "Azioni" e poi "Modifica".
  4. A sinistra, scegli "Passaggio 2 - Configura azioni facoltative".
  5. Per "Attivatore stato allarme", seleziona l'opzione "In allarme" per configurare un'azione basata sull'ALLARME.
  6. Per inviare una notifica a un argomento SNS appena creato, seleziona "Crea nuovo argomento".
  7. Nella casella "Crea nuovo argomento…", specifica un nome univoco per l'argomento SNS.
  8. Nella casella "Endpoint email che riceveranno la notifica…", specifica uno o più indirizzi email.
  9. Quindi seleziona "Crea argomento" per creare l'argomento Amazon SNS richiesto.
  10. In basso a destra, seleziona "Avanti", "Avanti" e scegli "Aggiorna sveglia" per applicare le modifiche.
  11. Apri il client di posta e, nell'email di AWS Notifications, fai clic sul link per confermare l'iscrizione all'argomento SNS in questione.
  12. Ripeti i passaggi da 4 a 11 e, durante il passaggio 5, scegli "Ok" e "Dati insufficienti" per "Attivatore stato allarme" per configurare le azioni per questi due stati.
  13. Ripeti la procedura per tutti gli altri allarmi CloudWatch nella stessa regione AWS.
  14. Ripeti la procedura per tutti gli altri allarmi CloudWatch in tutte le altre regioni AWS.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Cloudwatch Log Group Encrypted

Nome della categoria nell'API: CLOUDWATCH_LOG_GROUP_ENCRYPTED

Questo controllo garantisce che i log di CloudWatch siano configurati con KMS.

I dati del gruppo di log sono sempre criptati in CloudWatch Logs. Per impostazione predefinita, CloudWatch Logs utilizza la crittografia lato server per i dati di log at-rest. In alternativa, puoi utilizzare AWS Key Management Service per questa crittografia. In questo caso, la crittografia viene eseguita utilizzando una chiave KMS di AWS. La crittografia tramite AWS KMS è abilitata a livello di gruppo di log associando una chiave KMS a un gruppo di log, al momento della creazione del gruppo di log o dopo la sua esistenza.

Consiglio: controlla che tutti i gruppi di log in Amazon CloudWatch Logs siano criptati con KMS

Per ulteriori informazioni, consulta la sezione Criptare i dati di log in CloudWatch Logs utilizzando AWS Key Management Service nella guida per l'utente di Amazon CloudWatch.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

CloudTrail CloudWatch Logs Enabled

Nome della categoria nell'API: CLOUD_TRAIL_CLOUD_WATCH_LOGS_ENABLED

Questo controllo verifica se i trail di CloudTrail sono configurati per inviare i log a CloudWatch Logs. Il controllo non va a buon fine se la proprietà CloudWatchLogsLogGroupArn della traccia è vuota.

CloudTrail registra le chiamate API AWS effettuate in un determinato account. Le informazioni registrate includono quanto segue:

  • L'identità del chiamante API
  • L'ora della chiamata API
  • L'indirizzo IP di origine del chiamante API
  • Parametri di richiesta
  • Gli elementi di risposta restituiti dal servizio AWS

CloudTrail utilizza Amazon S3 per l'archiviazione e la distribuzione dei file di log. Puoi acquisire i log di CloudTrail in un bucket S3 specificato per l'analisi a lungo termine. Per eseguire l'analisi in tempo reale, puoi configurare CloudTrail in modo che invii i log a CloudWatch Logs.

Per un trail abilitato in tutte le regioni di un account, CloudTrail invia i file di log di tutte queste regioni a un gruppo di log CloudWatch Logs.

Security Hub consiglia di inviare i log di CloudTrail a CloudWatch Logs. Tieni presente che questo consiglio ha lo scopo di garantire che l'attività dell'account venga acquisita, monitorata e segnalata in modo appropriato. Puoi utilizzare CloudWatch Logs per configurare questa impostazione con i tuoi servizi AWS. Questo consiglio non esclude l'utilizzo di una soluzione diversa.

L'invio dei log CloudTrail a CloudWatch Logs facilita la registrazione dell'attività in tempo reale e storica in base a utente, API, risorsa e indirizzo IP. Puoi utilizzare questo approccio per impostare sveglie e notifiche per attività anomale o sensibili dell'account.

Consiglio: controlla che tutti i trail di CloudTrail siano configurati in modo da inviare i log ad AWS CloudWatch

Per integrare CloudTrail con CloudWatch Logs, consulta la sezione Invio di eventi a CloudWatch Logs nella Guida per l'utente di AWS CloudTrail.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

No AWS Credentials in CodeBuild Project Environment Variables

Nome della categoria nell'API: CODEBUILD_PROJECT_ENVVAR_AWSCRED_CHECK

Controlla se il progetto contiene le variabili di ambiente AWS_ACCESS_KEY_ID e AWS_SECRET_ACCESS_KEY.

Le credenziali di autenticazione AWS_ACCESS_KEY_ID e AWS_SECRET_ACCESS_KEY non devono mai essere archiviate in testo non crittografato, in quanto ciò potrebbe comportare l'esposizione involontaria dei dati e l'accesso non autorizzato.

Consiglio: controlla che tutti i progetti contenenti le variabili env AWS_ACCESS_KEY_ID e AWS_SECRET_ACCESS_KEY non siano in testo non crittografato

Per rimuovere le variabili di ambiente da un progetto CodeBuild, consulta Modificare le impostazioni di un progetto di build in AWS CodeBuild nella Guida per l'utente di AWS CodeBuild. Assicurati che non sia selezionato nulla per le variabili di ambiente.

Puoi archiviare le variabili di ambiente con valori sensibili in AWS Systems Manager Parameter Store o AWS Secrets Manager e poi recuperarle dalla specifica di build. Per istruzioni, consulta la casella con l'etichetta Importante nella sezione Ambiente della Guida per l'utente di AWS CodeBuild.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Codebuild Project Source Repo Url Check

Nome della categoria nell'API: CODEBUILD_PROJECT_SOURCE_REPO_URL_CHECK

Controlla se l'URL del repository di origine Bitbucket di un progetto AWS CodeBuild contiene token di accesso personale o un nome utente e una password. Il controllo non va a buon fine se l'URL del repository di origine Bitbucket contiene token di accesso personale o un nome utente e una password.

Le credenziali di accesso non devono essere archiviate o trasmesse in testo non crittografato né visualizzate nell'URL del repository di origine. Anziché token di accesso personali o credenziali di accesso, devi accedere al provider di origine in CodeBuild e modificare l'URL del repository di origine in modo che contenga solo il percorso della posizione del repository Bitbucket. L'utilizzo di token di accesso personale o credenziali di accesso potrebbe comportare l'esposizione involontaria di dati o l'accesso non autorizzato.

Consiglio: controlla che tutti i progetti che usano github o bitbucket come origine utilizzino oauth

Puoi aggiornare il tuo progetto CodeBuild in modo che utilizzi OAuth.

Per rimuovere l'autenticazione di base/il token di accesso personale (GitHub) dall'origine del progetto CodeBuild

  1. Apri la console CodeBuild all'indirizzo https://console.aws.amazon.com/codebuild/.
  2. Scegli il progetto di build che contiene i token di accesso personale o un nome utente e una password.
  3. In Modifica, scegli Origine.
  4. Scegli Scollega da GitHub / Bitbucket.
  5. Scegli Connetti tramite OAuth, quindi Connetti a GitHub / Bitbucket.
  6. Quando richiesto, scegli l'autorizzazione appropriata.
  7. Riconfigura l'URL del repository e le impostazioni di configurazione aggiuntive, se necessario.
  8. Scegli Aggiorna origine.

Per ulteriori informazioni, consulta gli esempi basati su casi d'uso di CodeBuild nella Guida per l'utente di AWS CodeBuild.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Credentials Unused 45 Days Greater Disabled

Nome della categoria nell'API: CREDENTIALS_UNUSED_45_DAYS_GREATER_DISABLED

Gli utenti AWS IAM possono accedere alle risorse AWS utilizzando diversi tipi di credenziali, come password o chiavi di accesso. Ti consigliamo di disattivare o rimuovere tutte le credenziali inutilizzate da almeno 45 giorni.

Consiglio: verifica che le credenziali non utilizzate per almeno 45 giorni siano disattivate

Per risolvere questo problema, completa i seguenti passaggi:

Console AWS

Per gestire la password inutilizzata (accesso alla console utente IAM), procedi nel seguente modo.

  1. Accedi alla Console di gestione AWS:
  2. Fai clic su Services.
  3. Fai clic su IAM.
  4. Fai clic su Users.
  5. Fai clic su Security Credentials.
  6. Seleziona l'utente il cui Console last sign-in è maggiore di 45 giorni
  7. Fai clic su Security credentials.
  8. Nella sezione Sign-in credentials, Console password fai clic su Manage.
  9. Nella sezione Accesso alla console, seleziona Disable
    10. Fai clic su Apply.

Per disattivare le chiavi di accesso:

  1. Accedi alla Console di gestione AWS:
  2. Fai clic su Services.
  3. Fai clic su IAM.
  4. Fai clic su Users.
  5. Fai clic su Security Credentials.
  6. Seleziona le chiavi di accesso più vecchie di 45 giorni e che sono state utilizzate e
    - Fai clic su Make Inactive
  7. Seleziona le chiavi di accesso più vecchie di 45 giorni e che non sono state utilizzate e
    - Fai clic sulla X per Delete

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Default Security Group Vpc Restricts All Traffic

Nome della categoria nell'API: DEFAULT_SECURITY_GROUP_VPC_RESTRICTS_ALL_TRAFFIC

Un VPC è dotato di un gruppo di sicurezza predefinito le cui impostazioni iniziali negano tutto il traffico in entrata, consentono tutto il traffico in uscita e consentono tutto il traffico tra le istanze assegnate al gruppo di sicurezza. Se non specifichi un gruppo di sicurezza quando avvii un'istanza, questa viene assegnata automaticamente a questo gruppo di sicurezza predefinito. I gruppi di sicurezza forniscono un filtro stateful del traffico di rete in entrata/uscita verso le risorse AWS. Ti consigliamo di limitare tutto il traffico nel gruppo di sicurezza predefinito.

Il VPC predefinito in ogni regione deve avere il gruppo di sicurezza predefinito aggiornato per essere conforme. Tutti i VPC appena creati conterranno automaticamente un gruppo di sicurezza predefinito che dovrà essere corretto per rispettare questo consiglio.

NOTA:quando implementi questo consiglio, il logging dei flussi VPC è prezioso per determinare l'accesso alle porte con privilegio minimo richiesto dai sistemi per funzionare correttamente, perché può registrare tutte le accettazioni e i rifiuti di pacchetti che si verificano nei gruppi di sicurezza attuali. In questo modo si riduce notevolmente la barriera principale all'ingegneria del privilegio minimo: scoprire le porte minime richieste dai sistemi nell'ambiente. Anche se il consiglio relativo al logging del flusso VPC in questo benchmark non viene adottato come misura di sicurezza permanente, deve essere utilizzato durante qualsiasi periodo di rilevamento e progettazione per i gruppi di sicurezza con privilegi minimi.

Consiglio: assicurati che il gruppo di sicurezza predefinito di ogni VPC limiti tutto il traffico

Membri del gruppo di sicurezza

Per implementare lo stato prescritto, procedi nel seguente modo:

  1. Identifica le risorse AWS che esistono all'interno del gruppo di sicurezza predefinito
  2. Crea un insieme di gruppi di sicurezza con privilegio minimo per queste risorse
  3. Inserisci le risorse in questi gruppi di sicurezza
  4. Rimuovi le risorse indicate al punto 1 dal gruppo di sicurezza predefinito

Stato del gruppo di sicurezza

  1. Accedi alla console di gestione AWS all'indirizzo https://console.aws.amazon.com/vpc/home
  2. Ripeti i passaggi successivi per tutti i VPC, incluso il VPC predefinito in ogni regione AWS:
  3. Nel riquadro a sinistra, fai clic su Security Groups
  4. Per ogni gruppo di sicurezza predefinito, esegui le seguenti operazioni:
  5. Seleziona il gruppo di sicurezza default
  6. Fai clic sulla scheda Inbound Rules.
  7. Rimuovi tutte le regole in entrata
  8. Fai clic sulla scheda Outbound Rules.
  9. Rimuovi eventuali regole in uscita

Consigliato:

I gruppi IAM ti consentono di modificare il campo "nome". Dopo aver corretto le regole dei gruppi predefiniti per tutti i VPC in tutte le regioni, modifica questo campo per aggiungere un testo simile a "NON UTILIZZARE. NON AGGIUNGERE REGOLE"

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Dms Replication Not Public

Nome della categoria nell'API: DMS_REPLICATION_NOT_PUBLIC

Controlla se le istanze di replica di AWS DMS sono pubbliche. A questo scopo, esamina il valore del campo PubliclyAccessible.

Un'istanza di replica privata ha un indirizzo IP privato a cui non puoi accedere al di fuori della rete di replica. Un'istanza di replica deve avere un indirizzo IP privato quando i database di origine e di destinazione si trovano nella stessa rete. La rete deve anche essere connessa al VPC dell'istanza di replica utilizzando una VPN, AWS Direct Connect o il peering VPC. Per saperne di più sulle istanze di replica pubbliche e private, consulta la sezione Istanze di replica pubbliche e private nella Guida per l'utente di AWS Database Migration Service.

Devi anche assicurarti che l'accesso alla configurazione dell'istanza AWS DMS sia limitato solo agli utenti autorizzati. Per farlo, limita le autorizzazioni IAM degli utenti alla modifica delle impostazioni e delle risorse AWS DMS.

Consiglio: controlla se le istanze di replica di AWS Database Migration Service sono pubbliche

Non puoi modificare l'impostazione di accesso pubblico per un'istanza di replica DMS dopo averla creata. Per modificare l'impostazione di accesso pubblico, elimina l'istanza corrente e ricreala. Non selezionare l'opzione Accessibile pubblicamente.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Do Setup Access Keys During Initial User Setup All Iam Users Console

Nome della categoria nell'API: DO_SETUP_ACCESS_KEYS_DURING_INITIAL_USER_SETUP_ALL_IAM_USERS_CONSOLE

Per impostazione predefinita, nella console AWS non sono selezionate caselle di controllo quando viene creato un nuovo utente IAM. Quando crei le credenziali utente IAM, devi determinare il tipo di accesso richiesto.

Accesso programmatico: l'utente IAM potrebbe dover effettuare chiamate API, utilizzare l'interfaccia a riga di comando AWS o gli strumenti per Windows PowerShell. In questo caso, crea una chiave di accesso (ID chiave di accesso e una chiave di accesso segreta) per l'utente.

Accesso alla Console di gestione AWS: se l'utente deve accedere alla Console di gestione AWS, crea una password per l'utente.

Consiglio: non impostare le chiavi di accesso durante la configurazione utente iniziale per tutti gli utenti IAM che dispongono di una password della console

Per risolvere questo problema, completa i seguenti passaggi:

Console AWS

  1. Accedi alla Console di gestione AWS:
  2. Fai clic su Services.
  3. Fai clic su IAM.
  4. Fai clic su Users.
  5. Fai clic su Security Credentials.
  6. In qualità di amministratore
    - Fai clic sulla X (Delete) per le chiavi create contemporaneamente al profilo utente, ma non utilizzate.
  7. In qualità di utente IAM
    - Fai clic sulla X (Delete) per le chiavi create contemporaneamente al profilo utente, ma non utilizzate.

Interfaccia a riga di comando AWS

aws iam delete-access-key --access-key-id <access-key-id-listed> --user-name <users-name>

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Dynamodb Autoscaling Enabled

Nome della categoria nell'API: DYNAMODB_AUTOSCALING_ENABLED

Verifica se una tabella Amazon DynamoDB può scalare la propria capacità di lettura e scrittura in base alle necessità. Questo controllo viene superato se la tabella utilizza la modalità di capacità on demand o la modalità di provisioning con scalabilità automatica configurata. La scalabilità della capacità in base alla domanda evita eccezioni di limitazione, il che contribuisce a mantenere la disponibilità delle applicazioni.

Le tabelle DynamoDB in modalità di capacità on demand sono limitate solo dalle quote predefinite della tabella di throughput di DynamoDB. Per aumentare queste quote, puoi presentare un ticket di assistenza tramite AWS Support.

Le tabelle DynamoDB in modalità di provisioning con scalabilità automatica regolano dinamicamente la capacità di throughput di cui è stato eseguito il provisioning in risposta ai pattern di traffico. Per ulteriori informazioni sulla limitazione delle richieste DynamoDB, consulta Limitazione delle richieste e capacità burst nella Guida per gli sviluppatori di Amazon DynamoDB.

Consiglio: le tabelle DynamoDB devono scalare automaticamente la capacità in base alla domanda

Per istruzioni dettagliate su come attivare la scalabilità automatica di DynamoDB sulle tabelle esistenti in modalità capacità, consulta Attivazione della scalabilità automatica di DynamoDB sulle tabelle esistenti nella Guida per gli sviluppatori di Amazon DynamoDB.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Dynamodb In Backup Plan

Nome della categoria nell'API: DYNAMODB_IN_BACKUP_PLAN

Questo controllo valuta se una tabella DynamoDB è coperta da un piano di backup. Il controllo non viene superato se una tabella DynamoDB non è coperta da un piano di backup. Questo controllo valuta solo le tabelle DynamoDB con stato ACTIVE.

I backup ti aiutano a ripristinare più rapidamente un incidente di sicurezza. Inoltre, rafforzano la resilienza dei tuoi sistemi. L'inclusione delle tabelle DynamoDB in un piano di backup ti aiuta a proteggere i dati da perdite o eliminazioni involontarie.

Consiglio: le tabelle DynamoDB devono essere coperte da un piano di backup

Per aggiungere una tabella DynamoDB a un piano di backup AWS Backup, consulta Assegnazione di risorse a un piano di backup nella Guida per gli sviluppatori di AWS Backup.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Dynamodb Pitr Enabled

Nome della categoria nell'API: DYNAMODB_PITR_ENABLED

Il recupero point-in-time (PITR) è uno dei meccanismi disponibili per il backup delle tabelle DynamoDB.

Un backup point-in-time viene conservato per 35 giorni. Se hai bisogno di un periodo di conservazione più lungo, consulta Configurare i backup pianificati per Amazon DynamoDB utilizzando AWS Backup nella documentazione di AWS.

Consiglio: controlla che il recupero point-in-time (PITR) sia abilitato per tutte le tabelle AWS DynamoDB

Per risolvere questo problema, completa i seguenti passaggi:

Terraform

Per impostare PITR per le tabelle DynamoDB, imposta il blocco point_in_time_recovery:

resource "aws_dynamodb_table" "example" {
  # ... other configuration ...
  point_in_time_recovery {
    enabled = true
  }
}

Console AWS

Per abilitare il recupero point-in-time di DynamoDB per una tabella esistente

  1. Apri la console DynamoDB all'indirizzo https://console.aws.amazon.com/dynamodb/.
  2. Scegli la tabella con cui vuoi lavorare e poi scegli Backup.
  3. Nella sezione Recupero point-in-time, scegli Abilita in Stato.
  4. Scegli di nuovo Attiva per confermare la modifica.

Interfaccia a riga di comando AWS

aws dynamodb update-continuous-backups \
  --table-name "GameScoresOnDemand" \
  --point-in-time-recovery-specification "PointInTimeRecoveryEnabled=true"

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Dynamodb Table Encrypted Kms

Nome della categoria nell'API: DYNAMODB_TABLE_ENCRYPTED_KMS

Controlla se tutte le tabelle DynamoDB sono criptate con una chiave KMS gestita dal cliente (non predefinita).

Consiglio: controlla che tutte le tabelle DynamoDB siano criptate con AWS Key Management Service (KMS)

Per risolvere questo problema, completa i seguenti passaggi:

Terraform

Per correggere questo controllo, crea una chiave KMS di AWS e utilizzala per criptare la risorsa DynamoDB che viola la policy.

resource "aws_kms_key" "dynamodb_encryption" {
  description         = "Used for DynamoDB encryption configuration"
  enable_key_rotation = true
}

resource "aws_dynamodb_table" "example" {
  # ... other configuration ...
  server_side_encryption {
    enabled     = true
    kms_key_arn = aws_kms_key.dynamodb_encryption.arn
  }
}

Console AWS

Supponendo che esista una chiave AWS KMS disponibile per criptare DynamoDB.

Per modificare la crittografia di una tabella DynamoDB in una chiave KMS gestita e di proprietà del cliente.

  1. Apri la console DynamoDB all'indirizzo https://console.aws.amazon.com/dynamodb/.
  2. Scegli la tabella con cui vuoi lavorare, quindi scegli Impostazioni aggiuntive.
  3. Nella sezione Crittografia, scegli Gestisci crittografia.
  4. Per la crittografia dei dati inattivi, scegli Memorizzati nel tuo account, di tua proprietà e gestiti da te.
  5. Seleziona la chiave AWS da utilizzare. Salva le modifiche.

Interfaccia a riga di comando AWS

aws dynamodb update-table \
  --table-name <value> \
  --sse-specification "Enabled=true,SSEType=KMS,KMSMasterKeyId=<kms_key_arn>"

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Ebs Optimized Instance

Nome della categoria nell'API: EBS_OPTIMIZED_INSTANCE

Controlla se l'ottimizzazione EBS è abilitata per le istanze EC2 che possono essere ottimizzate per EBS

Consiglio: controlla che l'ottimizzazione EBS sia abilitata per tutte le istanze che la supportano

Per configurare le impostazioni delle istanze ottimizzate per EBS, consulta Istanze ottimizzate per Amazon EBS nella guida per l'utente di Amazon EC2.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Ebs Snapshot Public Restorable Check

Nome della categoria nell'API: EBS_SNAPSHOT_PUBLIC_RESTORABLE_CHECK

Controlla se gli snapshot Amazon Elastic Block Store non sono pubblici. Il controllo non riesce se gli snapshot Amazon EBS sono ripristinabili da chiunque.

Gli snapshot EBS vengono utilizzati per eseguire il backup dei dati sui volumi EBS in Amazon S3 in un momento specifico. Puoi utilizzare gli snapshot per ripristinare gli stati precedenti dei volumi EBS. Raramente è accettabile condividere uno snapshot con il pubblico. In genere, la decisione di condividere pubblicamente uno snapshot è stata presa per errore o senza una comprensione completa delle implicazioni. Questo controllo contribuisce a garantire che tutta la condivisione sia stata pianificata e intenzionale.

Consiglio: gli snapshot Amazon EBS non devono essere ripristinabili pubblicamente

Per risolvere questo problema, completa i seguenti passaggi:

Console AWS

Per risolvere il problema, aggiorna lo snapshot EBS in modo che sia privato anziché pubblico.

Per rendere privato uno snapshot EBS pubblico:

  1. Apri la console Amazon EC2 all'indirizzo https://console.aws.amazon.com/ec2/.
  2. Nel riquadro di navigazione, in Elastic Block Store, scegli il menu Snapshot e poi lo snapshot pubblico.
  3. In Azioni, scegli Modifica autorizzazioni.
  4. Scegli Privato.
  5. (Facoltativo) Aggiungi i numeri di account AWS degli account autorizzati con cui condividere lo snapshot e scegli Aggiungi autorizzazione.
  6. Scegli Salva.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Ebs Volume Encryption Enabled All Regions

Nome della categoria nell'API: EBS_VOLUME_ENCRYPTION_ENABLED_ALL_REGIONS

Elastic Compute Cloud (EC2) supporta crittografia at-rest quando utilizzi il servizio Elastic Block Store (EBS). Sebbene sia disabilitata per impostazione predefinita, è supportata l'applicazione forzata della crittografia durante la creazione del volume EBS.

Consiglio: assicurati che la crittografia del volume EBS sia abilitata in tutte le regioni

Per risolvere questo problema, completa i seguenti passaggi:

Console AWS

  1. Accedi alla Console di gestione AWS e apri la console Amazon EC2 utilizzando https://console.aws.amazon.com/ec2/
  2. In Account attributes, fai clic su EBS encryption.
  3. Fai clic su Manage.
  4. Fai clic sulla casella di controllo Enable.
  5. Fai clic su Update EBS encryption.
  6. Ripeti l'operazione per ogni regione che richiede la modifica.

Nota:la crittografia del volume EBS è configurata per regione.

Interfaccia a riga di comando AWS

  1. Esegui
aws --region <region> ec2 enable-ebs-encryption-by-default
  1. Verifica che venga visualizzato "EbsEncryptionByDefault": true.
  2. Ripeti l'operazione per ogni regione che richiede la modifica.

Nota:la crittografia del volume EBS è configurata per regione.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Ec2 Instances In Vpc

Nome della categoria nell'API: EC2_INSTANCES_IN_VPC

Amazon VPC offre più funzionalità di sicurezza rispetto a EC2 Classic. Ti consigliamo di fare in modo che tutti i nodi appartengano a un Amazon VPC.

Consiglio: verifica che tutte le istanze appartengano a un VPC

Per risolvere questo problema, completa i seguenti passaggi:

Terraform

Se hai istanze EC2 Classic definite in Terraform, puoi modificare le tue risorse in modo che facciano parte di un VPC. Questa migrazione dipenderà da un'architettura più adatta alle tue esigenze. Di seguito è riportato un semplice esempio di Terraform che illustra un EC2 esposto pubblicamente in un VPC.

  resource "aws_vpc" "example_vpc" {
    cidr_block = "10.0.0.0/16"
  }

  resource "aws_subnet" "example_public_subnet" {
    vpc_id            = aws_vpc.example_vpc.id
    cidr_block        = "10.0.1.0/24"
    availability_zone = "1a"
  }

  resource "aws_internet_gateway" "example_igw" {
    vpc_id = aws_vpc.example_vpc.id
  }

  resource "aws_key_pair" "example_key" {
    key_name   = "web-instance-key"
    public_key = "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQD3F6tyPEFEzV0LX3X8BsXdMsQz1x2cEikKDEY0aIj41qgxMCP/iteneqXSIFZBp5vizPvaoIR3Um9xK7PGoW8giupGn+EPuxIA4cDM4vzOqOkiMPhz5XK0whEjkVzTo4+S0puvDZuwIsdiW9mxhJc7tgBNL0cYlWSYVkz4G/fslNfRPW5mYAM49f4fhtxPb5ok4Q2Lg9dPKVHO/Bgeu5woMc7RY0p1ej6D4CKFE6lymSDJpW0YHX/wqE9+cfEauh7xZcG0q9t2ta6F6fmX0agvpFyZo8aFbXeUBr7osSCJNgvavWbM/06niWrOvYX2xwWdhXmXSrbX8ZbabVohBK41 email@example.com"
  }

  resource "aws_security_group" "web_sg" {
    name   = "http and ssh"
    vpc_id = aws_vpc.some_custom_vpc.id

    ingress {
      from_port   = 80
      to_port     = 80
      protocol    = "tcp"
      cidr_blocks = ["0.0.0.0/0"]
    }

    ingress {
      from_port   = 22
      to_port     = 22
      protocol    = "tcp"
      cidr_blocks = ["0.0.0.0/0"]
    }

    egress {
      from_port   = 0
      to_port     = 0
      protocol    = -1
      cidr_blocks = ["0.0.0.0/0"]
    }
  }

  resource "aws_instance" "web" {
    ami                    = <ami_id>
    instance_type          = <instance_flavor>
    key_name               = aws_key_pair.example_key.name
    monitoring             = true
    subnet_id              = aws_subnet.example_public_subnet.id
    vpc_security_group_ids = [aws_security_group.web_sg.id]
    metadata_options {
      http_tokens = "required"
    }
  }

Console AWS

Per eseguire la migrazione da EC2 Classic a VPC, consulta Eseguire la migrazione da EC2-Classic a un VPC

Interfaccia a riga di comando AWS

Questo esempio di AWS CLI illustra la stessa infrastruttura definita con Terraform. Si tratta di un semplice esempio di istanza EC2 esposta pubblicamente in un VPC

Crea VPC

  aws ec2 create-vpc \
  --cidr-block 10.0.0.0/16

Crea subnet pubblica

  aws ec2 create-subnet \
  --availability-zone 1a \
  --cidr-block 10.0.1.0/24 \
  --vpc-id <id_from_create-vpc_command>

Crea gateway internet

  aws ec2 create-internet-gateway

Collega il gateway internet al VPC

  aws ec2 attach-internet-gateway \
  --internet-gateway-id <id_from_create-internet-gateway_command> \
  --vpc-id <id_from_create-vpc_command>

Crea coppia di chiavi: la chiave privata verrà salvata in /.ssh/web-instance-key.pem

  aws ec2 create-key-pair \
  --key-name web-instance-key \
  --query "KeyMaterial" \
  --output text > ~/.ssh/web-instance-key.pem && \
  chmod 400 ~/.ssh/web-instance-key.pem

Crea gruppo di sicurezza

  aws ec2 create-security-group \
  --group-name "http and ssh" \
  --vpc-id <id_from_create-vpc_command>

Crea regole del gruppo di sicurezza: per un accesso più limitato, definisci un CIDR più limitato per SSH sulla porta 22

  aws ec2 authorize-security-group-ingress \
  --group-id <id_from_create-security-group_command>
  --protocol tcp \
  --port 80 \
  --cidr 0.0.0.0/0

  aws ec2 authorize-security-group-ingress \
  --group-id <id_from_create-security-group_command>
  --protocol tcp \
  --port 22 \
  --cidr 0.0.0.0/0

  aws ec2 authorize-security-group-egress \
  --group-id <id_from_create-security-group_command>
  --protocol -1 \
  --port 0 \
  --cidr 0.0.0.0/0

Crea istanza EC2

  aws ec2 run-instances \
  --image-id <ami_id> \
  --instance-type <instance_flavor> \
  --metadata-options "HttpEndpoint=enabled,HttpTokens=required" \
  --monitoring true \
  --key-name web-instance-key \
  --subnet-id <id_from_create-subnet_command> \
  --security-group-ids <id_from_create-security-group_command>

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Ec2 Instance No Public Ip

Nome della categoria nell'API: EC2_INSTANCE_NO_PUBLIC_IP

Le istanze EC2 con un indirizzo IP pubblico sono a maggior rischio di compromissione. È consigliabile che le istanze EC2 non siano configurate con un indirizzo IP pubblico.

Consiglio: verifica che nessuna istanza abbia un IP pubblico

Per risolvere questo problema, completa i seguenti passaggi:

Terraform

Utilizza l'argomento associate_public_ip_address = false con la risorsa aws_instance per assicurarti che le istanze EC2 vengano sottoposte a provisioning senza un indirizzo IP pubblico

resource "aws_instance" "no_public_ip" {
  ...
  associate_public_ip_address = false
}

Console AWS

Per impostazione predefinita, le subnet non predefinite hanno l'attributo di indirizzamento pubblico IPv4 impostato su false, mentre le subnet predefinite hanno questo attributo impostato su true. Un'eccezione è una subnet non predefinita creata dalla procedura guidata di avvio dell'istanza Amazon EC2, che imposta l'attributo su true. Puoi modificare questo attributo utilizzando la console Amazon VPC.

Per modificare il comportamento di indirizzamento IPv4 pubblico della subnet

  1. Apri la console Amazon VPC all'indirizzo https://console.aws.amazon.com/vpc/.
  2. Nel riquadro di navigazione, scegli Subnet.
  3. Seleziona la subnet e scegli Azioni, Modifica impostazioni subnet.
  4. Se selezionata, la casella di controllo Attiva l'assegnazione automatica dell'indirizzo IPv4 pubblico richiede un indirizzo IPv4 pubblico per tutte le istanze avviate nella subnet selezionata. Seleziona o deseleziona la casella di controllo in base alle tue esigenze, quindi scegli Salva.

Interfaccia a riga di comando AWS

Il seguente comando esegue un'istanza EC2 in una subnet predefinita senza associarvi un indirizzo IP pubblico.

aws ec2 run-instances \
--image-id <ami_id> \
--instance-type <instance_flavor> \
--no-associate-public-ip-address \
--key-name MyKeyPair

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Ec2 Managedinstance Association Compliance Status Check

Nome della categoria nell'API: EC2_MANAGEDINSTANCE_ASSOCIATION_COMPLIANCE_STATUS_CHECK

Un'associazione State Manager è una configurazione assegnata alle tue istanze gestite. La configurazione definisce lo stato che vuoi mantenere nelle istanze. Ad esempio, un'associazione può specificare che il software antivirus deve essere installato ed eseguito sulle tue istanze o che determinate porte devono essere chiuse. Le istanze EC2 associate ad AWS Systems Manager sono gestite da Systems Manager, il che semplifica l'applicazione di patch, la correzione di errori di configurazione e la risposta agli eventi di sicurezza.

Consiglio: Controlla lo stato di conformità dell'associazione dei gestori di sistema AWS

Per risolvere questo problema, completa i seguenti passaggi:

Terraform

L'esempio seguente mostra come creare una semplice istanza EC2, un documento AWS Systems Manager (SSM) e un'associazione tra SSM e l'istanza EC2. I documenti supportati sono di tipo Command e Policy.

resource "aws_instance" "web" {
  ami           = "<iam_id>"
  instance_type = "<instance_flavor>"
}

resource "aws_ssm_document" "check_ip" {
  name          = "check-ip-config"
  document_type = "Command"

  content = <<DOC
  {
    "schemaVersion": "1.2",
    "description": "Check ip configuration of a Linux instance.",
    "parameters": {

    },
    "runtimeConfig": {
      "aws:runShellScript": {
        "properties": [
          {
            "id": "0.aws:runShellScript",
            "runCommand": ["ifconfig"]
          }
        ]
      }
    }
  }
DOC
}

resource "aws_ssm_association" "check_ip_association" {
  name = aws_ssm_document.check_ip.name

  targets {
    key    = "InstanceIds"
    values = [aws_instance.web.id]
  }
}

Console AWS

Per informazioni sulla configurazione delle associazioni con AWS Systems Manager utilizzando la console, consulta Creazione di associazioni nella documentazione di AWS Systems Manager.

Interfaccia a riga di comando AWS

Crea un documento SSM

aws ssm create-document \
--name <document_name> \
--content  file://path/to-file/document.json \
--document-type "Command"

Creare un'associazione SSM

aws ssm create-association \
--name <association_name> \
--targets "Key=InstanceIds,Values=<instance-id-1>,<instance-id-2>"

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Ec2 Managedinstance Patch Compliance Status Check

Nome della categoria nell'API: EC2_MANAGEDINSTANCE_PATCH_COMPLIANCE_STATUS_CHECK

Questo controllo verifica se lo stato di conformità dell'associazione AWS Systems Manager è COMPLIANT o NON_COMPLIANT dopo l'esecuzione dell'associazione su un'istanza. Il controllo non riesce se lo stato di conformità dell'associazione è NON_COMPLIANT.

Un'associazione State Manager è una configurazione assegnata alle tue istanze gestite. La configurazione definisce lo stato che vuoi mantenere nelle istanze. Ad esempio, un'associazione può specificare che il software antivirus deve essere installato ed eseguito sulle tue istanze o che determinate porte devono essere chiuse.

Dopo aver creato una o più associazioni State Manager, le informazioni sullo stato di conformità sono immediatamente disponibili. Puoi visualizzare lo stato di conformità nella console o in risposta ai comandi AWS CLI o alle azioni API Systems Manager corrispondenti. Per le associazioni, Conformità della configurazione mostra lo stato di conformità (Conforme o Non conforme). Mostra anche il livello di gravità assegnato all'associazione, ad esempio Critica o Media.

Per saperne di più sulla conformità dell'associazione State Manager, consulta la sezione Informazioni sulla conformità dell'associazione State Manager nella Guida per l'utente di AWS Systems Manager.

Consiglio: controlla lo stato di conformità delle patch di AWS Systems Manager

Un'associazione non riuscita può essere correlata a diversi elementi, tra cui target e nomi dei documenti SSM. Per risolvere il problema, devi prima identificare e analizzare l'associazione visualizzando la cronologia delle associazioni. Per istruzioni sulla visualizzazione della cronologia delle associazioni, vedi Visualizzazione delle cronologie delle associazioni nella Guida per l'utente di AWS Systems Manager.

Dopo l'indagine, puoi modificare l'associazione per correggere il problema identificato. Puoi modificare un'associazione per specificare un nuovo nome, una nuova pianificazione, un nuovo livello di gravità o nuovi target. Dopo aver modificato un'associazione, AWS Systems Manager crea una nuova versione. Per istruzioni sulla modifica di un'associazione, vedi Modifica e creazione di una nuova versione di un'associazione nella Guida per l'utente di AWS Systems Manager.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Ec2 Metadata Service Allows Imdsv2

Nome della categoria nell'API: EC2_METADATA_SERVICE_ALLOWS_IMDSV2

Quando attivano il servizio di metadati sulle istanze AWS EC2, gli utenti hanno la possibilità di utilizzare la versione 1 del servizio di metadati dell'istanza (IMDSv1, un metodo di richiesta/risposta) o la versione 2 del servizio di metadati dell'istanza (IMDSv2, un metodo orientato alla sessione).

Consiglio: verifica che il servizio di metadati EC2 consenta solo IMDSv2

Dalla console:
1. Accedi alla Console di gestione AWS e apri la console Amazon EC2 utilizzando https://console.aws.amazon.com/ec2/
2. Nel menu Istanze, seleziona Istanze.
3. Per ogni istanza, selezionala, poi scegli Azioni > Modifica opzioni metadati istanza.
4. Se il servizio di metadati dell'istanza è attivato, imposta IMDSv2 su Required (Obbligatorio).

Dalla riga di comando:

aws ec2 modify-instance-metadata-options --instance-id <instance_id> --http-tokens required

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Ec2 Volume Inuse Check

Nome della categoria nell'API: EC2_VOLUME_INUSE_CHECK

Identificare e rimuovere i volumi Elastic Block Store (EBS) non collegati (inutilizzati) nel tuo account AWS per ridurre il costo della fattura AWS mensile. L'eliminazione dei volumi EBS inutilizzati riduce anche il rischio che i dati riservati/sensibili escano dalla tua sede. Inoltre, questo controllo verifica anche se le istanze EC2 archiviate sono configurate per eliminare i volumi al termine.

Per impostazione predefinita, le istanze EC2 sono configurate per eliminare i dati in tutti i volumi EBS associati all'istanza e per eliminare il volume EBS root dell'istanza. Tuttavia, tutti i volumi EBS non root collegati all'istanza, all'avvio o durante l'esecuzione, vengono mantenuti dopo la terminazione per impostazione predefinita.

Consiglio: controlla se i volumi EBS sono collegati alle istanze EC2 e configurati per l'eliminazione al termine dell'istanza

Per risolvere questo problema, completa i seguenti passaggi:

Terraform

Per evitare questo scenario utilizzando Terraform, crea istanze EC2 con blocchi EBS incorporati. In questo modo, tutti i blocchi EBS associati all'istanza (non solo la radice) verranno eliminati al termine dell'istanza impostando l'attributo ebs_block_device.delete_on_termination su true per impostazione predefinita.

resource "aws_instance" "web" {
    ami                    = <ami_id>
    instance_type          = <instance_flavor>
    ebs_block_device {
      delete_on_termination = true # Default
      device_name           = "/dev/sdh"
    }

Console AWS

Per eliminare un volume EBS utilizzando la console

  1. Apri la console Amazon EC2 all'indirizzo https://console.aws.amazon.com/ec2/.
  2. Nel riquadro di navigazione, scegli Volumi.
  3. Seleziona il volume da eliminare e scegli Azioni, Elimina volume.
  4. Nota: se Elimina volume è disattivato, il volume è collegato a un'istanza. Prima di poterlo eliminare, devi scollegare il volume dall'istanza.
  5. Nella finestra di dialogo di conferma, scegli Elimina.

Interfaccia a riga di comando AWS

Questo comando di esempio elimina un volume disponibile con l'ID volume vol-049df61146c4d7901. Se il comando ha esito positivo, non viene restituito alcun output.

aws ec2 delete-volume --volume-id vol-049df61146c4d7901

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Efs Encrypted Check

Nome della categoria nell'API: EFS_ENCRYPTED_CHECK

Amazon EFS supporta due forme di crittografia per i file system: la crittografia dei dati in transito e la crittografia at-rest. Questo controllo verifica che tutti i file system EFS siano configurati con la crittografia at-rest in tutte le regioni abilitate dell'account.

Consiglio: controlla se EFS è configurato per criptare i dati dei file utilizzando KMS

Per risolvere questo problema, completa i seguenti passaggi:

Terraform

Il seguente snippet di codice può essere utilizzato per creare un EFS criptato con KMS (nota: l'attributo kms_key_id è facoltativo e verrà creata una chiave se non viene passato alcun ID chiave KMS)

resource "aws_efs_file_system" "encrypted-efs" {
  creation_token = "my-kms-encrypted-efs"
  encrypted      = true
  kms_key_id     = "arn:aws:kms:us-west-2:12344375555:key/16393ebd-3348-483f-b162-99b6648azz23"

  tags = {
    Name = "MyProduct"
  }
}

Console AWS

Per configurare EFS con la crittografia utilizzando la console AWS, consulta Crittografia di un file system at-rest utilizzando la console.

Interfaccia a riga di comando AWS

È importante notare che, sebbene la creazione di EFS dalla console attivi la crittografia at-rest per impostazione predefinita, ciò non vale per EFS creato utilizzando la CLI, l'API o l'SDK. L'esempio seguente ti consente di creare un file system criptato nella tua infrastruttura.

aws efs create-file-system \
--backup \
--encrypted \
--region us-east-1 \

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Efs In Backup Plan

Nome della categoria nell'API: EFS_IN_BACKUP_PLAN

Le best practice di Amazon consigliano di configurare i backup per i tuoi Elastic File System (EFS). Vengono controllati tutti i file system EFS in ogni regione abilitata del tuo account AWS per verificare se i backup sono abilitati.

Consiglio: controlla se i file system EFS sono inclusi nei piani di backup AWS

Per risolvere questo problema, completa i seguenti passaggi:

Terraform

Utilizza la risorsa aws_efs_backup_policy per configurare un criterio di backup per i file system EFS.

resource "aws_efs_file_system" "encrypted-efs" {
  creation_token = "my-encrypted-efs"
  encrypted      = true

  tags = merge({
    Name = "${local.resource_prefix.value}-efs"
    }, {
    git_file             = "terraform/aws/efs.tf"
    git_org              = "your_git_org"
    git_repo             = "your_git_repo"
  })
}

resource "aws_efs_backup_policy" "policy" {
  file_system_id = aws_efs_file_system.encrypted-efs.id

  backup_policy {
    status = "ENABLED"
  }
}

Console AWS

Esistono due opzioni per il backup di EFS: il servizio AWS Backup e la soluzione di backup da EFS a EFS. Per correggere EFS di cui non è stato eseguito il backup utilizzando la console, consulta:

  1. Utilizzo di AWS Backup per eseguire il backup e il ripristino dei file system Amazon EFS
  2. Backup da EFS a EFS

Interfaccia a riga di comando AWS

Esistono alcune opzioni per creare file system EFS conformi utilizzando la CLI:

  1. Crea un EFS con il backup automatico abilitato (impostazione predefinita per l'archiviazione in una zona e condizionata alla disponibilità del backup nella regione AWS)
  2. Crea un EFS e inserisci una policy di backup

Tuttavia, supponendo che la correzione debba essere eseguita nel file system EFS esistente, l'opzione migliore è creare una norma di backup e associarla al file system EFS non conforme. Avrai bisogno di un comando per ogni EFS nella tua infrastruttura.

arr=( $(aws efs describe-file-systems | jq -r '.FileSystems[].FileSystemId') )
for efs in "${arr[@]}"
do
  aws efs put-backup-policy \
  --file-system-id "${efs}" \
  --backup-policy "Status=ENABLED"
done

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Elb Acm Certificate Required

Nome della categoria nell'API: ELB_ACM_CERTIFICATE_REQUIRED

Controlla se il bilanciatore del carico classico utilizza certificati HTTPS/SSL forniti da AWS Certificate Manager (ACM). Il controllo non riesce se il bilanciatore del carico classico configurato con il listener HTTPS/SSL non utilizza un certificato fornito da ACM.

Per creare un certificato, puoi utilizzare ACM o uno strumento che supporta i protocolli SSL e TLS, come OpenSSL. Security Hub consiglia di utilizzare ACM per creare o importare certificati per il bilanciatore del carico.

ACM si integra con i bilanciatori del carico classici per consentirti di eseguire il deployment del certificato sul bilanciatore del carico. Inoltre, devi rinnovare automaticamente questi certificati.

Consiglio: controlla che tutti i bilanciatori del carico classici utilizzino i certificati SSL forniti da AWS Certificate Manager

Per informazioni su come associare un certificato SSL/TLS ACM a un bilanciatore del carico classico, consulta l'articolo del Centro conoscenze AWS How can I associate an ACM SSL/TLS certificate with a Classic, Application, or Network Load Balancer?

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Elb Deletion Protection Enabled

Nome della categoria nell'API: ELB_DELETION_PROTECTION_ENABLED

Controlla se per un bilanciatore del carico delle applicazioni è abilitata la protezione dall'eliminazione. Il controllo non viene superato se la protezione da eliminazione non è configurata.

Abilita la protezione dall'eliminazione per proteggere il bilanciatore del carico delle applicazioni dall'eliminazione.

Consiglio: la protezione dall'eliminazione del bilanciatore del carico delle applicazioni deve essere abilitata

Per risolvere questo problema, completa i seguenti passaggi:

Console AWS

Per evitare che il bilanciatore del carico venga eliminato accidentalmente, puoi attivare la protezione dall'eliminazione. Per impostazione predefinita, la protezione dall'eliminazione è disabilitata per il bilanciatore del carico.

Se abiliti la protezione dall'eliminazione per il bilanciatore del carico, devi disabilitarla prima di poter eliminare il bilanciatore del carico.

Per abilitare la protezione da eliminazione dalla console.

  1. Apri la console Amazon EC2 all'indirizzo https://console.aws.amazon.com/ec2/.
  2. Nel riquadro di navigazione, in BILANCIAMENTO DEL CARICO, scegli Bilanciatori del carico.
  3. Scegli il bilanciatore del carico.
  4. Nella scheda Descrizione, scegli Modifica attributi.
  5. Nella pagina Modifica attributi bilanciatore del carico, seleziona Attiva per la protezione dall'eliminazione, quindi scegli Salva.
  6. Scegli Salva.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Elb Logging Enabled

Nome della categoria nell'API: ELB_LOGGING_ENABLED

Controlla se la registrazione è abilitata per il bilanciatore del carico delle applicazioni e il bilanciatore del carico classico. Il controllo non va a buon fine se access_logs.s3.enabled è false.

Elastic Load Balancing fornisce log di accesso che acquisiscono informazioni dettagliate sulle richieste inviate al bilanciatore del carico. Ogni log contiene informazioni come l'ora in cui è stata ricevuta la richiesta, l'indirizzo IP del client, le latenze, i percorsi delle richieste e le risposte del server. Puoi utilizzare questi log di accesso per analizzare i pattern di traffico e risolvere i problemi.

Per saperne di più, consulta Log di accesso per il bilanciatore del carico classico nella Guida per l'utente per i bilanciatori del carico classici.

Consiglio: controlla se i bilanciatori del carico classici e delle applicazioni hanno la registrazione abilitata

Per risolvere questo problema, completa i seguenti passaggi:

Console AWS

Per risolvere il problema, aggiorna i bilanciatori del carico per attivare la registrazione.

Per attivare i log degli accessi

  1. Apri la console Amazon EC2 all'indirizzo https://console.aws.amazon.com/ec2/.
  2. Nel riquadro di navigazione, scegli Bilanciatori del carico.
  3. Scegli un bilanciatore del carico delle applicazioni o un bilanciatore del carico classico.
  4. In Azioni, scegli Modifica attributi.
  5. Nella sezione Log di accesso, scegli Attiva.
  6. Inserisci la posizione S3. Questa posizione può esistere o essere creata per te. Se non specifichi un prefisso, i log di accesso vengono archiviati nella radice del bucket S3.
  7. Scegli Salva.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Elb Tls Https Listeners Only

Nome della categoria nell'API: ELB_TLS_HTTPS_LISTENERS_ONLY

Questo controllo garantisce che tutti i bilanciatori del carico classici siano configurati per utilizzare la comunicazione sicura.

Un listener è un processo che verifica la presenza di richieste di connessione. È configurato con un protocollo e una porta per le connessioni di frontend (client al bilanciatore del carico) e un protocollo e una porta per le connessioni di backend (bilanciatore del carico all'istanza). Per informazioni sulle porte, sui protocolli e sulle configurazioni dei listener supportati da Elastic Load Balancing, consulta Listener per il bilanciatore del carico classico.

Consiglio: controlla che tutti i bilanciatori del carico classici siano configurati con listener SSL o HTTPS

Per configurare SSL o TLS per i bilanciatori del carico classici, consulta Creare un bilanciatore del carico HTTPS/SSL utilizzando AWS Management Console.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Encrypted Volumes

Nome della categoria nell'API: ENCRYPTED_VOLUMES

Controlla se i volumi EBS in stato collegato sono criptati. Per superare questo controllo, i volumi EBS devono essere in uso e criptati. Se il volume EBS non è collegato, non è soggetto a questo controllo.

Per un ulteriore livello di sicurezza dei dati sensibili nei volumi EBS, devi abilitare la crittografia EBS at-rest. La crittografia Amazon EBS offre una soluzione di crittografia semplice per le tue risorse EBS che non richiede la creazione, la manutenzione e la protezione della tua infrastruttura di gestione delle chiavi. Utilizza le chiavi KMS durante la creazione di volumi e snapshot criptati.

Per saperne di più sulla crittografia Amazon EBS, consulta la sezione Crittografia Amazon EBS nella Guida per l'utente di Amazon EC2 per le istanze Linux.

Consiglio: i volumi Amazon EBS collegati devono essere criptati at-rest

Per risolvere questo problema, completa i seguenti passaggi:

Console AWS

Non esiste un modo diretto per criptare un volume o uno snapshot esistente non criptato. Puoi criptare un nuovo volume o snapshot solo al momento della creazione.

Se hai abilitato la crittografia per impostazione predefinita, Amazon EBS cripta il nuovo volume o snapshot risultante utilizzando la chiave predefinita per la crittografia Amazon EBS. Anche se non hai abilitato la crittografia per impostazione predefinita, puoi abilitarla quando crei un singolo volume o snapshot. In entrambi i casi, puoi eseguire l'override della chiave predefinita per la crittografia Amazon EBS e scegliere una chiave simmetrica gestita dal cliente.

Per ulteriori informazioni, consulta Creazione di un volume Amazon EBS e Copia di uno snapshot Amazon EBS nella Guida per l'utente di Amazon EC2 per le istanze Linux.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Encryption At Rest Enabled Rds Instances

Nome della categoria nell'API: ENCRYPTION_AT_REST_ENABLED_RDS_INSTANCES

Le istanze di database Amazon RDS criptate utilizzano l'algoritmo di crittografia AES-256 standard di settore per criptare i dati sul server che ospita le istanze di database Amazon RDS. Una volta criptati i dati, Amazon RDS gestisce l'autenticazione dell'accesso e la decriptazione dei dati in modo trasparente con un impatto minimo sulle prestazioni.

Consiglio: assicurati che la crittografia at-rest sia abilitata per le istanze RDS

Per risolvere questo problema, completa i seguenti passaggi:

Console AWS

  1. Accedi alla Console di gestione AWS e apri la dashboard RDS all'indirizzo https://console.aws.amazon.com/rds/.
  2. Nel pannello di navigazione a sinistra, fai clic su Databases.
  3. Seleziona l'istanza di database da criptare.
  4. Fai clic sul pulsante Actions in alto a destra e seleziona Take Snapshot.
  5. Nella pagina Scatta snapshot, inserisci un nome del database di cui vuoi scattare uno snapshot nel campo Snapshot Name e fai clic su Take Snapshot.
  6. Seleziona lo snapshot appena creato e fai clic sul pulsante Action in alto a destra, quindi seleziona Copy snapshot dal menu Azioni.
  7. Nella pagina Crea copia dello snapshot del database, esegui le seguenti operazioni:
  • Nel campo Nuovo identificatore snapshot DB, inserisci un nome per new snapshot.
  • Controlla Copy Tags, Il nuovo snapshot deve avere gli stessi tag dello snapshot di origine.
  • Seleziona Yes dall'elenco a discesa Enable Encryption per abilitare la crittografia. Puoi scegliere di utilizzare la chiave di crittografia predefinita di AWS o la chiave personalizzata dall'elenco a discesa Chiave master.
  1. Fai clic su Copy Snapshot per creare una copia criptata dello snapshot dell'istanza selezionato.
  2. Seleziona la nuova copia criptata dello snapshot e fai clic sul pulsante Action in alto a destra e seleziona il pulsante Restore Snapshot dal menu Azioni. In questo modo, lo snapshot criptato verrà ripristinato in una nuova istanza del database.
  3. Nella pagina Restore DB Instance (Ripristina istanza DB), inserisci un nome univoco per la nuova istanza del database nel campo DB Instance Identifier (Identificatore istanza DB).
  4. Esamina i dettagli di configurazione dell'istanza e fai clic su Restore DB Instance.
  5. Una volta completato il processo di provisioning della nuova istanza, puoi aggiornare la configurazione dell'applicazione in modo che faccia riferimento all'endpoint della nuova istanza del database criptato. Una volta modificato l'endpoint del database a livello di applicazione, puoi rimuovere l'istanza non criptata.

Interfaccia a riga di comando AWS

  1. Esegui il comando describe-db-instances per elencare tutti i nomi dei database RDS disponibili nella regione AWS selezionata. L'output comando deve restituire l'identificatore dell'istanza del database.
aws rds describe-db-instances --region <region-name> --query 'DBInstances[*].DBInstanceIdentifier'
  1. Esegui il comando create-db-snapshot per creare uno snapshot per l'istanza del database selezionata. L'output comando restituirà new snapshot con il nome DB Snapshot Name.
aws rds create-db-snapshot --region <region-name> --db-snapshot-identifier <DB-Snapshot-Name> --db-instance-identifier <DB-Name>
  1. Ora esegui il comando list-aliases per elencare gli alias delle chiavi KMS disponibili in una regione specificata. L'output del comando deve restituire ogni key alias currently available. Per la nostra procedura di attivazione della crittografia RDS, individua l'ID della chiave KMS predefinita di AWS.
aws kms list-aliases --region <region-name>
  1. Esegui il comando copy-db-snapshot utilizzando l'ID chiave KMS predefinito per le istanze RDS restituite in precedenza per creare una copia criptata dello snapshot dell'istanza del database. L'output comando restituirà encrypted instance snapshot configuration.
aws rds copy-db-snapshot --region <region-name> --source-db-snapshot-identifier <DB-Snapshot-Name> --target-db-snapshot-identifier <DB-Snapshot-Name-Encrypted> --copy-tags --kms-key-id <KMS-ID-For-RDS>
  1. Esegui il comando restore-db-instance-from-db-snapshot per ripristinare lo snapshot criptato creato nel passaggio precedente in una nuova istanza di database. Se l'operazione va a buon fine, l'output comando deve restituire la nuova configurazione dell'istanza di database criptata.
aws rds restore-db-instance-from-db-snapshot --region <region-name> --db-instance-identifier <DB-Name-Encrypted> --db-snapshot-identifier <DB-Snapshot-Name-Encrypted>
  1. Esegui il comando describe-db-instances per elencare tutti i nomi dei database RDS disponibili nella regione AWS selezionata. L'output restituirà il nome dell'identificatore dell'istanza del database. Seleziona il nome del database criptato che abbiamo appena creato, DB-Name-Encrypted.
aws rds describe-db-instances --region <region-name> --query 'DBInstances[*].DBInstanceIdentifier'
  1. Esegui di nuovo il comando describe-db-instances utilizzando l'identificatore dell'istanza RDS restituito in precedenza per determinare se l'istanza del database selezionata è criptata. L'output comando deve restituire lo stato di criptaggio True.
aws rds describe-db-instances --region <region-name> --db-instance-identifier <DB-Name-Encrypted> --query 'DBInstances[*].StorageEncrypted'

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Encryption Enabled Efs File Systems

Nome della categoria nell'API: ENCRYPTION_ENABLED_EFS_FILE_SYSTEMS

I dati EFS devono essere criptati at-rest utilizzando AWS KMS (Key Management Service).

Consiglio: assicurati che la crittografia sia abilitata per i file system EFS

Per risolvere questo problema, completa i seguenti passaggi:

Console AWS

  1. Accedi alla console di gestione AWS e vai al pannello di controllo Elastic File System (EFS).
  2. Seleziona File Systems dal pannello di navigazione a sinistra.
  3. Fai clic sul pulsante Create File System nel menu in alto della dashboard per avviare la procedura di configurazione del file system.

  4. Nella pagina di configurazione di Configure file system access, esegui le seguenti azioni.
    - Scegli la VPC corretta dall'elenco a discesa VPC.
    - Nella sezione Crea target di montaggio, seleziona le caselle di controllo per tutte le zone di disponibilità (AZ) all'interno del VPC selezionato. Questi saranno i tuoi target di montaggio.
    - Fai clic su Next step per continuare.

  5. Esegui le seguenti operazioni nella pagina Configure optional settings.
    - Crea tags per descrivere il nuovo file system.
    - Scegli performance mode in base ai tuoi requisiti.
    - Seleziona la casella di controllo Enable encryption e scegli aws/elasticfilesystem dal menu a discesa Seleziona chiave master KMS per attivare la crittografia per il nuovo file system utilizzando la chiave master predefinita fornita e gestita da AWS KMS.
    - Fai clic su Next step per continuare.

  6. Esamina i dettagli di configurazione del file system nella pagina review and create e poi fai clic su Create File System per creare il nuovo file system AWS EFS.

  7. Copia i dati dal vecchio file system EFS non criptato nel nuovo file system criptato creato.
  8. Rimuovi il file system non criptato non appena la migrazione dei dati al file system criptato appena creato è completata.
  9. Modifica la regione AWS dalla barra di navigazione e ripeti l'intera procedura per le altre regioni AWS.

Dall'interfaccia a riga di comando:
1. Esegui il comando describe-file-systems per descrivere le informazioni di configurazione disponibili per il file system selezionato (non criptato) (consulta la sezione Audit per identificare la risorsa corretta):

aws efs describe-file-systems --region <region> --file-system-id <file-system-id from audit section step 2 output>
  1. L'output del comando deve restituire le informazioni di configurazione richieste.
  2. Per eseguire il provisioning di un nuovo file system AWS EFS, devi generare un identificatore univoco universale (UUID) per creare il token richiesto dal comando create-file-system. Per creare il token richiesto, puoi utilizzare un UUID generato casualmente da "https://www.uuidgenerator.net".
  3. Esegui il comando create-file-system utilizzando il token univoco creato nel passaggio precedente.
aws efs create-file-system --region <region> --creation-token <Token (randomly generated UUID from step 3)> --performance-mode generalPurpose --encrypted
  1. L'output del comando deve restituire i nuovi metadati di configurazione del file system.
  2. Esegui il comando create-mount-target utilizzando l'ID del file system EFS appena creato restituito nel passaggio precedente come identificatore e l'ID della zona di disponibilità che rappresenterà il target di montaggio:
aws efs create-mount-target --region <region> --file-system-id <file-system-id> --subnet-id <subnet-id>
  1. L'output del comando deve restituire i nuovi metadati della destinazione di montaggio.
  2. Ora puoi montare il file system da un'istanza EC2.
  3. Copia i dati dal vecchio file system EFS non criptato nel nuovo file system criptato creato.
  4. Rimuovi il file system non criptato non appena la migrazione dei dati al file system criptato appena creato è completata.
aws efs delete-file-system --region <region> --file-system-id <unencrypted-file-system-id>
  1. Modifica la regione AWS aggiornando --region e ripeti l'intera procedura per le altre regioni AWS.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Iam Password Policy

Nome della categoria nell'API: IAM_PASSWORD_POLICY

AWS consente criteri per le password personalizzati sul tuo account AWS per specificare i requisiti di complessità e i periodi di rotazione obbligatori per le password degli utenti IAM. Se non imposti un criterio della password personalizzato, le password degli utenti IAM devono soddisfare il criterio della password AWS predefinito. Le best practice per la sicurezza di AWS consigliano i seguenti requisiti di complessità della password:

  • Richiedi almeno un carattere maiuscolo nella password.
  • Richiedi almeno un carattere minuscolo nelle password.
  • Richiedi almeno un simbolo nelle password.
  • Richiedi almeno un numero nelle password.
  • Richiedi una lunghezza minima della password di almeno 14 caratteri.
  • Richiedi almeno 24 password prima di consentire il riutilizzo.
  • Richiedi almeno 90 giorni prima della scadenza della password

Questo controllo verifica tutti i requisiti specificati delle norme relative alle password.

Consiglio: controlla se il criterio della password dell'account per gli utenti IAM soddisfa i requisiti specificati

Per risolvere questo problema, completa i seguenti passaggi:

Terraform

resource "aws_iam_account_password_policy" "strict" {
  allow_users_to_change_password = true
  require_uppercase_characters   = true
  require_lowercase_characters   = true
  require_symbols                = true
  require_numbers                = true
  minimum_password_length        = 14
  password_reuse_prevention      = 24
  max_password_age               = 90
}

Console AWS

Per creare una norma per le password personalizzata

  1. Accedi alla console di gestione AWS e apri la console IAM all'indirizzo https://console.aws.amazon.com/iam/.
  2. Nel riquadro di navigazione, scegli Impostazioni account.
  3. Nella sezione Norme relative alle password, scegli Modifica norme relative alle password.
  4. Seleziona le opzioni che vuoi applicare al criterio per le password e scegli Salva modifiche.

Per modificare una policy password personalizzata

  1. Accedi alla Console di gestione AWS e apri la console IAM all'indirizzo https://console.aws.amazon.com/iam/.
  2. Nel riquadro di navigazione, scegli Impostazioni account.
  3. Nella sezione Criteri per le password, scegli Modifica.
  4. Seleziona le opzioni che vuoi applicare al criterio per le password e scegli Salva modifiche.

Interfaccia a riga di comando AWS

aws iam update-account-password-policy \
--allow-users-to-change-password \
--require-uppercase-characters \
--require-lowercase-characters \
--require-symbols \
--require-numbers \
--minimum-password-length 14 \
--password-reuse-prevention 24 \
--max-password-age 90

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Iam Password Policy Prevents Password Reuse

Nome della categoria nell'API: IAM_PASSWORD_POLICY_PREVENTS_PASSWORD_REUSE

I criteri della password IAM possono impedire il riutilizzo di una determinata password da parte dello stesso utente. Ti consigliamo di impostare il criterio della password in modo che impedisca il riutilizzo delle password.

Consiglio: assicurati che il criterio della password IAM impedisca il riutilizzo della password

Per risolvere questo problema, completa i seguenti passaggi:

Console AWS

  1. Accedi alla console AWS (con le autorizzazioni appropriate per visualizzare le impostazioni dell'account Identity Access Management)
  2. Vai al servizio IAM nella console AWS
  3. Fai clic su Impostazioni account nel riquadro a sinistra.
  4. Seleziona "Impedisci il riutilizzo della password".
  5. Imposta "Numero di password da ricordare" su 24

Interfaccia a riga di comando AWS

 aws iam update-account-password-policy --password-reuse-prevention 24

Nota: tutti i comandi che iniziano con "aws iam update-account-password-policy" possono essere combinati in un unico comando.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Iam Password Policy Requires Minimum Length 14 Greater

Nome della categoria nell'API: IAM_PASSWORD_POLICY_REQUIRES_MINIMUM_LENGTH_14_GREATER

I criteri relativi alle password vengono utilizzati, in parte, per applicare i requisiti di complessità delle password. I criteri della password IAM possono essere utilizzati per garantire che le password abbiano almeno una determinata lunghezza. È consigliabile che il criterio della password richieda una lunghezza minima di 14 caratteri.

Suggerimento: assicurati che la policy della password IAM richieda una lunghezza minima di 14 caratteri

Per risolvere questo problema, completa i seguenti passaggi:

Console AWS

  1. Accedi alla console AWS (con le autorizzazioni appropriate per visualizzare le impostazioni dell'account Identity Access Management)
  2. Vai al servizio IAM nella console AWS
  3. Fai clic su Impostazioni account nel riquadro a sinistra.
  4. Imposta "Lunghezza minima della password" su 14 o un valore superiore.
  5. Fai clic su "Applica criterio per le password".

Interfaccia a riga di comando AWS

 aws iam update-account-password-policy --minimum-password-length 14

Nota: tutti i comandi che iniziano con "aws iam update-account-password-policy" possono essere combinati in un unico comando.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Iam Policies Allow Full Administrative Privileges Attached

Nome della categoria nell'API: IAM_POLICIES_ALLOW_FULL_ADMINISTRATIVE_PRIVILEGES_ATTACHED

I criteri IAM sono il mezzo con cui vengono concessi privilegi a utenti, gruppi o ruoli. È consigliabile e considerato un consiglio di sicurezza standard concedere il privilegio minimo, ovvero concedere solo le autorizzazioni necessarie per eseguire un'attività. Determina le attività che gli utenti devono svolgere e poi crea policy che consentano loro di eseguire solo queste attività, anziché concedere privilegi amministrativi completi.

Consiglio: assicurati che non siano collegate policy IAM che consentono privilegi amministrativi completi "*:*"

Per risolvere questo problema, completa i seguenti passaggi:

Console AWS

Per scollegare la policy con privilegi amministrativi completi:

  1. Accedi alla Console di gestione AWS e apri la console IAM all'indirizzo https://console.aws.amazon.com/iam/.
  2. Nel riquadro di navigazione, fai clic su Norme e poi cerca il nome della norma trovato nel passaggio di controllo.
  3. Seleziona le norme da eliminare.
  4. Nel menu delle azioni delle norme, seleziona prima Detach.
  5. Seleziona tutti gli utenti, i gruppi e i ruoli a cui è associata questa norma.
  6. Fai clic su Detach Policy.
  7. Nel menu delle azioni delle norme, seleziona Detach.

Interfaccia a riga di comando AWS

Per scollegare la policy con privilegi amministrativi completi trovata nel passaggio di controllo:

  1. Elenca tutti gli utenti, i gruppi e i ruoli IAM a cui è collegata la policy gestita specificata.
 aws iam list-entities-for-policy --policy-arn <policy_arn>
  1. Scollega la policy da tutti gli utenti IAM:
 aws iam detach-user-policy --user-name <iam_user> --policy-arn <policy_arn>
  1. Scollega la policy da tutti i gruppi IAM:
 aws iam detach-group-policy --group-name <iam_group> --policy-arn <policy_arn>
  1. Scollega la policy da tutti i ruoli IAM:
 aws iam detach-role-policy --role-name <iam_role> --policy-arn <policy_arn>

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Iam Users Receive Permissions Groups

Nome della categoria nell'API: IAM_USERS_RECEIVE_PERMISSIONS_GROUPS

Gli utenti IAM ottengono l'accesso a servizi, funzioni e dati tramite i criteri IAM. Esistono quattro modi per definire le policy per un utente: 1) modificare direttamente la policy utente, ovvero una policy inline o utente; 2) collegare una policy direttamente a un utente; 3) aggiungere l'utente a un gruppo IAM a cui è collegata una policy; 4) aggiungere l'utente a un gruppo IAM con una policy inline.

È consigliata solo la terza implementazione.

Consiglio: assicurati che gli utenti IAM ricevano le autorizzazioni solo tramite i gruppi

Per creare un gruppo IAM e assegnargli un criterio:

  1. Accedi alla Console di gestione AWS e apri la console IAM all'indirizzo https://console.aws.amazon.com/iam/.
  2. Nel riquadro di navigazione, fai clic su Groups e poi su Create New Group .
  3. Nella casella Group Name, digita il nome del gruppo e poi fai clic su Next Step .
  4. Nell'elenco delle policy, seleziona la casella di controllo per ogni policy che vuoi applicare a tutti i membri del gruppo. Poi, fai clic su Next Step .
  5. Fai clic su Create Group.

Per aggiungere un utente a un determinato gruppo:

  1. Accedi alla Console di gestione AWS e apri la console IAM all'indirizzo https://console.aws.amazon.com/iam/.
  2. Nel riquadro di navigazione, fai clic su Groups.
  3. Seleziona il gruppo a cui aggiungere un utente
  4. Fai clic su Add Users To Group.
  5. Seleziona gli utenti da aggiungere al gruppo
  6. Fai clic su Add Users.

Per rimuovere un'associazione diretta tra un utente e una policy:

  1. Accedi alla Console di gestione AWS e apri la console IAM all'indirizzo https://console.aws.amazon.com/iam/.
  2. Nel riquadro di navigazione a sinistra, fai clic su Utenti.
  3. Per ogni utente:
    - Seleziona l'utente
    - Fai clic sulla scheda Permissions
    - Espandi Permissions policies
    - Fai clic su X per ogni criterio, poi fai clic su Scollega o Rimuovi (a seconda del tipo di criterio)

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Iam User Group Membership Check

Nome della categoria nell'API: IAM_USER_GROUP_MEMBERSHIP_CHECK

Per rispettare le best practice di sicurezza IAM, gli utenti IAM devono sempre far parte di un gruppo IAM.

Aggiungendo utenti a un gruppo, è possibile condividere i criteri tra i tipi di utenti.

Consiglio: controlla se gli utenti IAM sono membri di almeno un gruppo IAM

Per risolvere questo problema, completa i seguenti passaggi:

Terraform

resource "aws_iam_user" "example" {
  name = "test-iam-user"
  path = "/users/dev/"
}

resource "aws_iam_group" "example" {
  name = "Developers"
  path = "/users/dev/"
}

resource "aws_iam_user_group_membership" "example" {
  user   = aws_iam_user.example.name
  groups = [aws_iam_group.example.name]
}

Console AWS

Quando utilizzi la Console di gestione AWS per eliminare un utente IAM, IAM elimina automaticamente le seguenti informazioni:

  1. L'utente
  2. Tutte le appartenenze a gruppi di utenti, ovvero l'utente viene rimosso da tutti i gruppi di utenti IAM di cui faceva parte
  3. Qualsiasi password associata all'utente
  4. Qualsiasi chiave di accesso appartenente all'utente
  5. Tutte le policy inline incorporate nell'utente (le policy applicate a un utente tramite le autorizzazioni del gruppo di utenti non sono interessate)

Per eliminare un utente IAM:

  1. Accedi alla console di gestione AWS e apri la console IAM all'indirizzo https://console.aws.amazon.com/iam/.
  2. Nel riquadro di navigazione, scegli Utenti, quindi seleziona la casella di controllo accanto al nome utente che vuoi eliminare.
  3. Nella parte superiore della pagina, scegli Elimina.
  4. Nella finestra di dialogo di conferma, inserisci il nome utente nel campo di input di testo per confermare l'eliminazione dell'utente.
  5. Scegli Elimina.

Per aggiungere un utente a un gruppo di utenti IAM:

  1. Accedi alla console di gestione AWS e apri la console IAM all'indirizzo https://console.aws.amazon.com/iam/.
  2. Nel riquadro di navigazione, scegli Gruppi di utenti e poi il nome del gruppo.
  3. Scegli la scheda Utenti, quindi scegli Aggiungi utenti. Seleziona la casella di controllo accanto agli utenti che vuoi aggiungere.
  4. Scegli Aggiungi utenti.

Interfaccia a riga di comando AWS

A differenza della Console di gestione Amazon Web Services, quando elimini un utente a livello di programmazione, devi eliminare manualmente gli elementi collegati all'utente, altrimenti l'eliminazione non va a buon fine.

Prima di tentare di eliminare un utente, rimuovi i seguenti elementi:

  1. Password ( DeleteLoginProfile )
  2. Chiavi di accesso ( DeleteAccessKey )
  3. Certificato di firma ( DeleteSigningCertificate )
  4. Chiave pubblica SSH ( DeleteSSHPublicKey )
  5. Credenziali Git ( DeleteServiceSpecificCredential )
  6. Dispositivo di autenticazione a più fattori (MFA) ( DeactivateMFADevice , DeleteVirtualMFADevice )
  7. Policy inline ( DeleteUserPolicy )
  8. Policy gestite collegate ( DetachUserPolicy )
  9. Appartenenze a gruppi ( RemoveUserFromGroup )

Per eliminare un utente, dopo aver eliminato tutti gli elementi allegati:

aws iam delete-user \
  --user-name "test-user"

Per aggiungere un utente IAM a un gruppo IAM:

aws iam add-user-to-group \
  --group-name "test-group"
  --user-name "test-user"

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Iam User Mfa Enabled

Nome della categoria nell'API: IAM_USER_MFA_ENABLED

L'autenticazione a più fattori (MFA) è una best practice che aggiunge un ulteriore livello di protezione oltre a nomi utente e password. Con l'autenticazione MFA, quando un utente accede alla Console di gestione AWS, deve fornire un codice di autenticazione sensibile al tempo, fornito da un dispositivo virtuale o fisico registrato.

Consiglio: controlla se per gli utenti IAM AWS è abilitata l'autenticazione a più fattori (MFA)

Per risolvere questo problema, completa i seguenti passaggi:

Terraform

Per quanto riguarda Terraform, esistono alcune opzioni per risolvere l'assenza di dispositivi MFA. Probabilmente hai già una struttura ragionevole per organizzare gli utenti in gruppi e criteri restrittivi.

Il seguente esempio mostra come:

  1. Crea utenti.
  2. Crea profili di accesso degli utenti con una chiave pubblica PGP.
  3. Crea un gruppo e un criterio di gruppo che consenta l'autogestione del profilo IAM.
  4. Collega gli utenti al gruppo.
  5. Crea dispositivi MFA virtuali per gli utenti.
  6. Fornisci a ogni utente il codice QR e la password di output.
variable "users" {
  type = set(string)
  default = [
    "test@example.com",
    "test2@example.com"
  ]
}

resource "aws_iam_user" "test_users" {
  for_each = toset(var.users)
  name     = each.key
}

resource "aws_iam_user_login_profile" "test_users_profile" {
  for_each                = var.users
  user                    = each.key
  # Key pair created using GnuPG, this is the public key
  pgp_key = file("path/to/gpg_pub_key_base64.pem")
  password_reset_required = true
  lifecycle {
    ignore_changes = [
      password_length,
      password_reset_required,
      pgp_key,
    ]
  }
}

resource "aws_iam_virtual_mfa_device" "test_mfa" {
  for_each                = toset(var.users)
  virtual_mfa_device_name = each.key
}

resource "aws_iam_group" "enforce_mfa_group" {
  name = "EnforceMFAGroup"
}

resource "aws_iam_group_membership" "enforce_mfa_group_membership" {
  name  = "EnforceMFAGroupMembership"
  group = aws_iam_group.enforce_mfa_group.name
  users = [for k in aws_iam_user.test_users : k.name]
}

resource "aws_iam_group_policy" "enforce_mfa_policy" {
  name   = "EnforceMFAGroupPolicy"
  group  = aws_iam_group.enforce_mfa_group.id
  policy = <<POLICY
{
  "Version": "2012-10-17",
  "Statement": [
    {
        "Sid": "AllowViewAccountInfo",
        "Effect": "Allow",
        "Action": [
            "iam:GetAccountPasswordPolicy",
            "iam:ListVirtualMFADevices"
        ],
        "Resource": "*"
    },
    {
        "Sid": "AllowManageOwnPasswords",
        "Effect": "Allow",
        "Action": [
            "iam:ChangePassword",
            "iam:GetUser"
        ],
        "Resource": "arn:aws:iam::*:user/$${aws:username}"
    },
    {
        "Sid": "AllowManageOwnAccessKeys",
        "Effect": "Allow",
        "Action": [
            "iam:CreateAccessKey",
            "iam:DeleteAccessKey",
            "iam:ListAccessKeys",
            "iam:UpdateAccessKey"
        ],
        "Resource": "arn:aws:iam::*:user/$${aws:username}"
    },
    {
        "Sid": "AllowManageOwnSigningCertificates",
        "Effect": "Allow",
        "Action": [
            "iam:DeleteSigningCertificate",
            "iam:ListSigningCertificates",
            "iam:UpdateSigningCertificate",
            "iam:UploadSigningCertificate"
        ],
        "Resource": "arn:aws:iam::*:user/$${aws:username}"
    },
    {
        "Sid": "AllowManageOwnSSHPublicKeys",
        "Effect": "Allow",
        "Action": [
            "iam:DeleteSSHPublicKey",
            "iam:GetSSHPublicKey",
            "iam:ListSSHPublicKeys",
            "iam:UpdateSSHPublicKey",
            "iam:UploadSSHPublicKey"
        ],
        "Resource": "arn:aws:iam::*:user/$${aws:username}"
    },
    {
        "Sid": "AllowManageOwnGitCredentials",
        "Effect": "Allow",
        "Action": [
            "iam:CreateServiceSpecificCredential",
            "iam:DeleteServiceSpecificCredential",
            "iam:ListServiceSpecificCredentials",
            "iam:ResetServiceSpecificCredential",
            "iam:UpdateServiceSpecificCredential"
        ],
        "Resource": "arn:aws:iam::*:user/$${aws:username}"
    },
    {
        "Sid": "AllowManageOwnVirtualMFADevice",
        "Effect": "Allow",
        "Action": [
            "iam:CreateVirtualMFADevice",
            "iam:DeleteVirtualMFADevice"
        ],
        "Resource": "arn:aws:iam::*:mfa/$${aws:username}"
    },
    {
        "Sid": "AllowManageOwnUserMFA",
        "Effect": "Allow",
        "Action": [
            "iam:DeactivateMFADevice",
            "iam:EnableMFADevice",
            "iam:ListMFADevices",
            "iam:ResyncMFADevice"
        ],
        "Resource": "arn:aws:iam::*:user/$${aws:username}"
    },
    {
        "Sid": "DenyAllExceptListedIfNoMFA",
        "Effect": "Deny",
        "NotAction": [
            "iam:CreateVirtualMFADevice",
            "iam:EnableMFADevice",
            "iam:GetUser",
            "iam:ListMFADevices",
            "iam:ListVirtualMFADevices",
            "iam:ResyncMFADevice",
            "sts:GetSessionToken"
        ],
        "Resource": "*",
        "Condition": {
            "BoolIfExists": {
                "aws:MultiFactorAuthPresent": "false"
            }
        }
    }
  ]
}
POLICY
}

output "user_password_map" {
  # Outputs a map in the format {"test@example.com": <PGPEncryptedPassword>, "test2@example.com": <PGPEncryptedPassword>}
  value = { for k, v in aws_iam_user_login_profile.test_users_profile : k => v.password }
}

output "user_qr_map" {
  # Outputs a map in the format {"test@example.com": <QRCode>, "test2@example.com": <QRCode>}
  value = { for k, v in aws_iam_virtual_mfa_device.test_mfa : k => v.qr_code_png }
}

Console AWS

Per abilitare l'MFA per tutti gli account utente con accesso alla console AWS, consulta Abilitazione di un dispositivo di autenticazione a più fattori (MFA) virtuale (console) nella documentazione AWS.

Interfaccia a riga di comando AWS

Crea un dispositivo MFA

aws iam create-virtual-mfa-device \
  --virtual-mfa-device-name "test@example.com" \
  --outfile ./QRCode.png \
  --bootstrap-method QRCodePNG

Abilitare il dispositivo MFA per un utente esistente

aws iam enable-mfa-device \
  --user-name "test@example.com" \
  --serial-number "arn:aws:iam::123456976749:mfa/test@example.com" \
  --authentication-code1 123456 \
  --authentication-code2 654321

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Iam User Unused Credentials Check

Nome della categoria nell'API: IAM_USER_UNUSED_CREDENTIALS_CHECK

Controlla eventuali password IAM o chiavi di accesso attive che non sono state utilizzate negli ultimi 90 giorni.

Le best practice consigliano di rimuovere, disattivare o ruotare tutte le credenziali non utilizzate per 90 giorni o più. In questo modo si riduce la finestra di opportunità per l'utilizzo delle credenziali associate a un account compromesso o abbandonato.

Consiglio: controlla che tutti gli utenti IAM AWS dispongano di password o chiavi di accesso attive che non sono state utilizzate in maxCredentialUsageAge giorni (il valore predefinito è 90)

Per risolvere questo problema, completa i seguenti passaggi:

Terraform

Per rimuovere le chiavi di accesso scadute create tramite Terraform, rimuovi la risorsa aws_iam_access_key dal modulo e applica la modifica.

Per reimpostare la password di accesso di un utente IAM, utilizza -replace quando esegui terraform apply.

Supponendo il seguente profilo di accesso utente

resource "aws_iam_user" "example" {
  name          = "test@example.com"
  path          = "/users/"
  force_destroy = true
}

resource "aws_iam_user_login_profile" "example" {
  user    = aws_iam_user.example.name
  pgp_key = "keybase:some_person_that_exists"
}

Esegui il seguente comando per reimpostare la password del profilo di accesso dell'utente

terraform apply -replace="aws_iam_user_login_profile.example"

Console AWS

Per disattivare le credenziali per gli account inattivi:

  1. Apri la console IAM all'indirizzo https://console.aws.amazon.com/iam/.
  2. Scegli Utenti.
  3. Scegli il nome dell'utente le cui credenziali hanno più di 90 giorni o sono state utilizzate l'ultima volta.
  4. Scegli le credenziali di sicurezza.
  5. Per ogni credenziale di accesso e chiave di accesso che non è stata utilizzata per almeno 90 giorni, scegli Rendi inattiva.

Per richiedere una nuova password agli utenti della console al successivo accesso:

  1. Apri la console IAM all'indirizzo https://console.aws.amazon.com/iam/.
  2. Scegli Utenti.
  3. Scegli il nome dell'utente le cui credenziali hanno più di 90 giorni o sono state utilizzate l'ultima volta.
  4. Scegli le credenziali di sicurezza.
  5. Nella sezione Credenziali di accesso e password della console, scegli Gestisci.
  6. Imposta una nuova password (generata automaticamente o personalizzata).
  7. Seleziona la casella per richiedere la reimpostazione della password.
  8. Scegli Applica.

Interfaccia a riga di comando AWS

Per rendere inattive le chiavi di accesso

aws iam update-access-key \
  --access-key-id <value> \
  --status "Inactive"

Per eliminare le chiavi di accesso

aws iam delete-access-key \
  --access-key-id <value>

Per reimpostare la password di un profilo di accesso utente

aws iam update-login-profile \
  --user-name "test@example.com" \
  --password <temporary_password> \
  --password-reset-required

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Kms Cmk Not Scheduled For Deletion

Nome della categoria nell'API: KMS_CMK_NOT_SCHEDULED_FOR_DELETION

Questo controllo verifica se è pianificata l'eliminazione delle chiavi KMS. Il controllo non va a buon fine se è pianificata l'eliminazione di una chiave KMS.

Le chiavi KMS non possono essere recuperate una volta eliminate. Anche i dati criptati con una chiave KMS non sono più recuperabili in modo permanente se la chiave KMS viene eliminata. Se sono stati criptati dati significativi con una chiave KMS la cui eliminazione è pianificata, valuta la possibilità di decriptare i dati o di criptarli nuovamente con una nuova chiave KMS, a meno che tu non stia eseguendo intenzionalmente una cancellazione crittografica.

Quando una chiave KMS viene pianificata per l'eliminazione, viene applicato un periodo di attesa obbligatorio per consentire l'annullamento dell'eliminazione, se è stata pianificata per errore. Il periodo di attesa predefinito è di 30 giorni, ma può essere ridotto fino a 7 giorni quando l'eliminazione della chiave KMS è pianificata. Durante il periodo di attesa, l'eliminazione pianificata può essere annullata e la chiave KMS non verrà eliminata.

Per ulteriori informazioni sull'eliminazione delle chiavi KMS, consulta la sezione Eliminazione delle chiavi KMS nella Guida per gli sviluppatori di AWS Key Management Service.

Consiglio: controlla che non sia pianificata l'eliminazione di tutte le CMK

Per annullare l'eliminazione pianificata di una chiave KMS, vedi Per annullare l'eliminazione della chiave in Pianificazione e annullamento dell'eliminazione della chiave (console) nella Guida per gli sviluppatori di AWS Key Management Service.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Lambda Concurrency Check

Nome della categoria nell'API: LAMBDA_CONCURRENCY_CHECK

Controlla se la funzione Lambda è configurata con un limite di esecuzione simultanea a livello di funzione. La regola è NON_COMPLIANT se la funzione Lambda non è configurata con un limite di esecuzione simultanea a livello di funzione.

Consiglio: controlla se le funzioni Lambda sono configurate con un limite di esecuzione simultanea a livello di funzione

Per configurare un limite di esecuzione simultanea a livello di funzione, consulta la sezione Configurazione della concorrenza riservata nella documentazione di AWS Lambda.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Lambda Dlq Check

Nome della categoria nell'API: LAMBDA_DLQ_CHECK

Controlla se una funzione Lambda è configurata con una coda di messaggi non recapitabili. La regola è NON_COMPLIANT se la funzione Lambda non è configurata con una coda di messaggi non recapitabili.

Consiglio: controlla se le funzioni Lambda sono configurate con una coda di messaggi non recapitabili

Per aggiornare le funzioni Lambda in modo che utilizzino le code di messaggi non recapitabili, consulta Code di messaggi non recapitabili nella documentazione di AWS.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Lambda Function Public Access Prohibited

Nome della categoria nell'API: LAMBDA_FUNCTION_PUBLIC_ACCESS_PROHIBITED

Le best practice di AWS consigliano di non esporre pubblicamente la funzione Lambda. Questo criterio controlla tutte le funzioni Lambda implementate in tutte le regioni abilitate all'interno del tuo account e non verrà soddisfatto se sono configurate per consentire l'accesso pubblico.

Consiglio: controlla se la policy collegata alla funzione Lambda vieta l'accesso pubblico

Per risolvere questo problema, completa i seguenti passaggi:

Terraform

L'esempio seguente mostra come utilizzare Terraform per eseguire il provisioning di un ruolo IAM che limita l'accesso a una funzione Lambda e collegare questo ruolo alla funzione Lambda

resource "aws_iam_role" "iam_for_lambda" {
  name = "iam_for_lambda"

  assume_role_policy = <<EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": "sts:AssumeRole",
      "Principal": {
        "Service": "lambda.amazonaws.com"
      },
      "Effect": "Allow",
      "Sid": ""
    }
  ]
}
EOF
}

resource "aws_lambda_function" "test_lambda" {
  filename      = "lambda_function_payload.zip"
  function_name = "lambda_function_name"
  role          = aws_iam_role.iam_for_lambda.arn
  handler       = "index.test"

  source_code_hash = filebase64sha256("lambda_function_payload.zip")

  runtime = "nodejs12.x"

}

Console AWS

Se una funzione Lambda non supera questo controllo, significa che l'istruzione della policy basata sulle risorse per la funzione Lambda consente l'accesso pubblico.

Per risolvere il problema, devi aggiornare le norme per rimuovere le autorizzazioni o aggiungere la condizione AWS:SourceAccount. Puoi aggiornare i criteri basati sulle risorse solo dall'API Lambda.

Le seguenti istruzioni utilizzano la console per esaminare la policy e l'interfaccia a riga di comando AWS per rimuovere le autorizzazioni.

Per visualizzare la policy basata sulle risorse per una funzione Lambda

  1. Apri la console AWS Lambda all'indirizzo https://console.aws.amazon.com/lambda/.
  2. Nel riquadro di navigazione, scegli Funzioni.
  3. Scegli la funzione.
  4. Scegli Autorizzazioni. La policy basata sulle risorse mostra le autorizzazioni applicate quando un altro account o servizio AWS tenta di accedere alla funzione.
  5. Esamina la policy basata sulle risorse.
  6. Identifica l'istruzione dei criteri che ha valori del campo Entità che rendono pubblici i criteri. Ad esempio, consentendo "*" o { "AWS": "*" }.

Non puoi modificare la policy dalla console. Per rimuovere le autorizzazioni dalla funzione, utilizza il comando remove-permission di AWS CLI.

Prendi nota del valore dell'ID istruzione (Sid) per l'istruzione che vuoi rimuovere.

Interfaccia a riga di comando AWS

Per utilizzare la CLI per rimuovere le autorizzazioni da una funzione Lambda, esegui il comando remove-permission come segue.

aws lambda remove-permission \
--function-name <value> \
--statement-id <value>

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Lambda Inside Vpc

Nome della categoria nell'API: LAMBDA_INSIDE_VPC

Controlla se una funzione Lambda si trova in un VPC. Potresti visualizzare risultati non riusciti per le risorse Lambda@Edge.

Non valuta la configurazione di routing della subnet VPC per determinare la raggiungibilità pubblica.

Consiglio: controlla se esistono funzioni Lambda all'interno di un VPC

Per risolvere questo problema, completa i seguenti passaggi:

Console AWS

Per configurare una funzione in modo che si connetta a subnet private in un virtual private cloud (VPC) nel tuo account:

  1. Apri la console AWS Lambda all'indirizzo https://console.aws.amazon.com/lambda/.
  2. Vai a Funzioni e seleziona la funzione Lambda.
  3. Scorri fino a Rete e seleziona un VPC con i requisiti di connettività della funzione.
  4. Per eseguire le funzioni in modalità ad alta disponibilità, Security Hub consiglia di scegliere almeno due subnet.
  5. Scegli almeno un gruppo di sicurezza che soddisfi i requisiti di connettività della funzione.
  6. Scegli Salva.

Per ulteriori informazioni, consulta la sezione relativa alla configurazione di una funzione Lambda per accedere alle risorse in un VPC nella guida per gli sviluppatori di AWS Lambda.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Mfa Delete Enabled S3 Buckets

Nome della categoria nell'API: MFA_DELETE_ENABLED_S3_BUCKETS

Una volta abilitata l'eliminazione con autenticazione MFA sul bucket S3 sensibile e classificato, l'utente deve disporre di due forme di autenticazione.

Consiglio: assicurati che l'eliminazione con autenticazione MFA sia abilitata sui bucket S3

Per attivare l'eliminazione con autenticazione MFA su un bucket S3, segui i passaggi riportati di seguito.

Nota:
- Non puoi attivare l'eliminazione MFA utilizzando la Console di gestione AWS. Devi utilizzare l'interfaccia a riga di comando AWS o l'API.
- Devi utilizzare l'account "root" per abilitare l'eliminazione con autenticazione MFA sui bucket S3.

Dalla riga di comando:

  1. Esegui il comando s3api put-bucket-versioning
aws s3api put-bucket-versioning --profile my-root-profile --bucket Bucket_Name --versioning-configuration Status=Enabled,MFADelete=Enabled --mfa “arn:aws:iam::aws_account_id:mfa/root-account-mfa-device passcode”

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Mfa Enabled Root User Account

Nome della categoria nell'API: MFA_ENABLED_ROOT_USER_ACCOUNT

L'account utente "root" è l'utente con i privilegi più elevati in un account AWS. L'autenticazione a più fattori (MFA) aggiunge un ulteriore livello di protezione oltre al nome utente e alla password. Con l'MFA abilitata, quando un utente accede a un sito web AWS, gli verrà chiesto il nome utente e la password, nonché un codice di autenticazione dal suo dispositivo AWS MFA.

Nota:quando l'autenticazione MFA virtuale viene utilizzata per gli account "root", è consigliabile che il dispositivo utilizzato NON sia un dispositivo personale, ma un dispositivo mobile dedicato (tablet o smartphone) gestito in modo da essere mantenuto carico e protetto indipendentemente da qualsiasi dispositivo personale individuale. ("MFA virtuale non personale") In questo modo si riducono i rischi di perdere l'accesso all'MFA a causa della perdita del dispositivo, della permuta del dispositivo o se la persona proprietaria del dispositivo non lavora più presso l'azienda.

Consiglio: assicurati che l'autenticazione MFA sia abilitata per l'account utente "root"

Per configurare l'autenticazione MFA per l'account utente "root":

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

Nota: per gestire i dispositivi MFA per l'account AWS "root", devi utilizzare le credenziali dell'account "root" per accedere ad AWS. Non puoi gestire i dispositivi MFA per l'account "root" utilizzando altre credenziali.

  1. Scegli Dashboard e , in Security Status , espandi Activate MFA nel tuo account principale.
  2. Scegli Activate MFA
  3. Nella procedura guidata, scegli il dispositivo A virtual MFA e poi Next Step .
  4. IAM genera e visualizza le informazioni di configurazione per il dispositivo MFA virtuale, inclusa una grafica del codice QR. L'immagine è una rappresentazione della "chiave di configurazione segreta" disponibile per l'inserimento manuale sui dispositivi che non supportano i codici QR.
  5. Apri l'applicazione MFA virtuale. Per un elenco delle app che puoi utilizzare per ospitare dispositivi MFA virtuali, vedi Applicazioni MFA virtuali. Se l'applicazione MFA virtuale supporta più account (più dispositivi MFA virtuali), scegli l'opzione per creare un nuovo account (un nuovo dispositivo MFA virtuale).
  6. Determina se l'app MFA supporta i codici QR, quindi procedi in uno dei seguenti modi:
  • Utilizza l'app per scansionare il codice QR. Ad esempio, puoi scegliere l'icona della fotocamera o un'opzione simile a Scansiona codice, quindi utilizzare la fotocamera del dispositivo per scansionare il codice.
  • Nella procedura guidata Gestisci dispositivo MFA, scegli Mostra chiave segreta per la configurazione manuale, quindi digita la chiave di configurazione segreta nell'applicazione MFA.

Al termine, il dispositivo MFA virtuale inizia a generare password monouso.

Nella procedura guidata Gestisci dispositivo MFA, nella casella Codice di autenticazione 1, digita la password monouso attualmente visualizzata nel dispositivo MFA virtuale. Attendi fino a 30 secondi per la generazione di una nuova password monouso. Poi digita la seconda password monouso nella casella Codice di autenticazione 2. Scegli Assegna MFA virtuale.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Multi Factor Authentication Mfa Enabled All Iam Users Console

Nome della categoria nell'API: MULTI_FACTOR_AUTHENTICATION_MFA_ENABLED_ALL_IAM_USERS_CONSOLE

L'autenticazione a più fattori (MFA) aggiunge un ulteriore livello di garanzia di autenticazione oltre alle credenziali tradizionali. Con la MFA abilitata, quando un utente accede alla console AWS, gli verrà chiesto il nome utente e la password, nonché un codice di autenticazione dal token MFA fisico o virtuale. Ti consigliamo di abilitare l'MFA per tutti gli account con una password per la console.

Consiglio: verifica che l'autenticazione a più fattori (MFA) sia abilitata per tutti gli utenti IAM con una password per la console

Per risolvere questo problema, completa i seguenti passaggi:

Console AWS

  1. Accedi alla Console di gestione AWS e apri la console IAM all'indirizzo https://console.aws.amazon.com/iam/.
  2. Nel riquadro a sinistra, seleziona Users.
  3. Nell'elenco User Name, scegli il nome dell'utente per cui vuoi attivare l'MFA.
  4. Scegli la scheda Security Credentials, quindi scegli Manage MFA Device.
  5. In Manage MFA Device wizard, scegli il dispositivo Virtual MFA, quindi scegli Continue.

IAM genera e visualizza le informazioni di configurazione per il dispositivo MFA virtuale, inclusa una grafica del codice QR. L'immagine è una rappresentazione della "chiave di configurazione segreta" disponibile per l'inserimento manuale sui dispositivi che non supportano i codici QR.

  1. Apri l'applicazione MFA virtuale. Per un elenco delle app che puoi utilizzare per ospitare dispositivi MFA virtuali, consulta Applicazioni MFA virtuali all'indirizzo https://aws.amazon.com/iam/details/mfa/#Virtual_MFA_Applications. Se l'applicazione MFA virtuale supporta più account (più dispositivi MFA virtuali), scegli l'opzione per creare un nuovo account (un nuovo dispositivo MFA virtuale).
  2. Determina se l'app MFA supporta i codici QR, quindi procedi in uno dei seguenti modi:
  • Utilizza l'app per scansionare il codice QR. Ad esempio, puoi scegliere l'icona della fotocamera o un'opzione simile a Scansiona codice, quindi utilizzare la fotocamera del dispositivo per scansionare il codice.
  • Nella procedura guidata Gestisci dispositivo MFA, scegli Mostra chiave segreta per la configurazione manuale, quindi digita la chiave di configurazione segreta nell'applicazione MFA.

Al termine, il dispositivo MFA virtuale inizia a generare password monouso.

  1. In Manage MFA Device wizard, in MFA Code 1 box, digita il one-time password visualizzato attualmente nel dispositivo MFA virtuale. Attendi fino a 30 secondi per la generazione di una nuova password monouso. Quindi, digita il secondo one-time password in MFA Code 2 box.

  2. Fai clic su Assign MFA.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

No Network Acls Allow Ingress 0 0 0 0 Remote Server Administration

Nome della categoria nell'API: NO_NETWORK_ACLS_ALLOW_INGRESS_0_0_0_0_REMOTE_SERVER_ADMINISTRATION

La funzione Elenco di controllo dell'accesso alla rete (NACL) fornisce il filtro stateless del traffico di rete in entrata e in uscita verso le risorse AWS. È consigliabile che nessun ACL di rete consenta l'accesso in entrata senza restrizioni alle porte di amministrazione del server remoto, ad esempio SSH alla porta 22 e RDP alla porta 3389, utilizzando i protocolli TDP (6), UDP (17) o ALL (-1).

Consiglio: assicurati che nessun ACL di rete consenta il traffico in entrata da 0.0.0.0/0 alle porte di amministrazione del server remoto

Per risolvere questo problema, completa i seguenti passaggi:

Console AWS

Esegui le seguenti operazioni:
1. Accedi alla Console di gestione AWS all'indirizzo https://console.aws.amazon.com/vpc/home
2. Nel riquadro a sinistra, fai clic su Network ACLs
3. Per ogni ACL di rete da correggere, esegui le seguenti operazioni:
- Seleziona l'ACL di rete
- Fai clic sulla scheda Inbound Rules
- Fai clic su Edit inbound rules
- A) Aggiorna il campo Origine a un intervallo diverso da 0.0.0.0/0 oppure B) fai clic su Delete per rimuovere la regola in entrata incriminata
- Fai clic su Save

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

No Root User Account Access Key Exists

Nome della categoria nell'API: NO_ROOT_USER_ACCOUNT_ACCESS_KEY_EXISTS

L'account utente "root" è l'utente con i privilegi più elevati in un account AWS. Le chiavi di accesso AWS forniscono l'accesso programmatico a un determinato account AWS. Ti consigliamo di eliminare tutte le chiavi di accesso associate all'account utente "root".

Consiglio: assicurati che non esistano chiavi di accesso all'account utente "root"

Per risolvere questo problema, completa i seguenti passaggi:

Console AWS

  1. Accedi alla Console di gestione AWS come "root" e apri la console IAM all'indirizzo https://console.aws.amazon.com/iam/.
  2. Fai clic su <root_account> in alto a destra e seleziona My Security Credentials dall'elenco a discesa.
  3. Nella schermata popup, fai clic su Continue to Security Credentials.
  4. Fai clic su Access Keys (ID chiave di accesso e chiave di accesso segreta).
  5. Nella colonna Status (se sono presenti chiavi attive).
  6. Fai clic su Delete (nota: le chiavi eliminate non possono essere recuperate).

Nota: anche se una chiave può essere resa inattiva, questa chiave inattiva verrà comunque visualizzata nel comando CLI della procedura di controllo e potrebbe comportare la segnalazione errata di una chiave come non conforme.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

No Security Groups Allow Ingress 0 0 0 0 Remote Server Administration

Nome della categoria nell'API: NO_SECURITY_GROUPS_ALLOW_INGRESS_0_0_0_0_REMOTE_SERVER_ADMINISTRATION

I gruppi di sicurezza forniscono un filtro stateful del traffico di rete in entrata e in uscita verso le risorse AWS. È consigliabile che nessun gruppo di sicurezza consenta l'accesso in entrata senza restrizioni alle porte di amministrazione del server remoto, ad esempio SSH alla porta 22 e RDP alla porta 3389, utilizzando i protocolli TDP (6), UDP (17) o ALL (-1).

Consiglio: assicurati che nessun gruppo di sicurezza consenta il traffico in entrata da 0.0.0.0/0 alle porte di amministrazione del server remoto

Per implementare lo stato prescritto, procedi nel seguente modo:

  1. Accedi alla console di gestione AWS all'indirizzo https://console.aws.amazon.com/vpc/home
  2. Nel riquadro a sinistra, fai clic su Security Groups
  3. Per ogni gruppo di sicurezza, esegui le seguenti operazioni:
  4. Seleziona il gruppo di sicurezza
  5. Fai clic sulla scheda Inbound Rules.
  6. Fai clic sul pulsante Edit inbound rules.
  7. Identificare le regole da modificare o rimuovere
  8. A) Aggiorna il campo Origine a un intervallo diverso da 0.0.0.0/0 oppure B) fai clic su Delete per rimuovere la regola in entrata incriminata.
  9. Fai clic su Save rules.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

No Security Groups Allow Ingress 0 Remote Server Administration

Nome della categoria nell'API: NO_SECURITY_GROUPS_ALLOW_INGRESS_0_REMOTE_SERVER_ADMINISTRATION

I gruppi di sicurezza forniscono un filtro stateful del traffico di rete in entrata e in uscita verso le risorse AWS. Ti consigliamo di non consentire a nessun gruppo di sicurezza l'accesso in entrata senza restrizioni alle porte di amministrazione del server remoto, ad esempio SSH alla porta 22 e RDP alla porta 3389.

Consiglio: assicurati che nessun gruppo di sicurezza consenta il traffico in entrata da ::/0 alle porte di amministrazione del server remoto

Per implementare lo stato prescritto, procedi nel seguente modo:

  1. Accedi alla console di gestione AWS all'indirizzo https://console.aws.amazon.com/vpc/home
  2. Nel riquadro a sinistra, fai clic su Security Groups
  3. Per ogni gruppo di sicurezza, esegui le seguenti operazioni:
  4. Seleziona il gruppo di sicurezza
  5. Fai clic sulla scheda Inbound Rules.
  6. Fai clic sul pulsante Edit inbound rules.
  7. Identificare le regole da modificare o rimuovere
  8. A) Aggiorna il campo Origine a un intervallo diverso da ::/0 oppure B) Fai clic su Delete per rimuovere la regola in entrata incriminata
  9. Fai clic su Save rules.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

One Active Access Key Available Any Single Iam User

Nome della categoria nell'API: ONE_ACTIVE_ACCESS_KEY_AVAILABLE_ANY_SINGLE_IAM_USER

Le chiavi di accesso sono credenziali a lungo termine per un utente IAM o per l'utente "root" dell'account AWS. Puoi utilizzare le chiavi di accesso per firmare richieste programmatiche all'interfaccia a riga di comando AWS o all'API AWS (direttamente o utilizzando l'SDK AWS)

Consiglio: assicurati che sia disponibile una sola chiave di accesso attiva per ogni singolo utente IAM

Per risolvere questo problema, completa i seguenti passaggi:

Console AWS

  1. Accedi alla Console di gestione AWS e vai al pannello di controllo IAM all'indirizzo https://console.aws.amazon.com/iam/.
  2. Nel pannello di navigazione a sinistra, seleziona Users.
  3. Fai clic sul nome utente IAM che vuoi esaminare.
  4. Nella pagina di configurazione dell'utente IAM, seleziona la scheda Security Credentials.
  5. Nella sezione Access Keys, scegli una chiave di accesso risalente a meno di 90 giorni fa. Questa deve essere l'unica chiave attiva utilizzata da questo utente IAM per accedere alle risorse AWS a livello di programmazione. Testa le tue applicazioni per assicurarti che la chiave di accesso scelta funzioni.
  6. Nella stessa sezione Access Keys, identifica le chiavi di accesso non operative (diverse da quella scelta) e disattivala facendo clic sul link Make Inactive.
  7. Se visualizzi la casella di conferma Change Key Status, fai clic su Deactivate per disattivare la chiave selezionata.
  8. Ripeti i passaggi 3-7 per ogni utente IAM nel tuo account AWS.

Interfaccia a riga di comando AWS

  1. Utilizzando le informazioni sull'utente IAM e sulla chiave di accesso fornite in Audit CLI, scegli una chiave di accesso risalente a meno di 90 giorni. Questa deve essere l'unica chiave attiva utilizzata da questo utente IAM per accedere alle risorse AWS a livello di programmazione. Testa le tue applicazioni per assicurarti che la chiave di accesso scelta funzioni.

  2. Esegui il comando update-access-key riportato di seguito utilizzando il nome utente IAM e gli ID chiave di accesso non operativa per disattivare le chiavi non necessarie. Consulta la sezione Audit per identificare l'ID chiave di accesso non necessario per l'utente IAM selezionato

Nota: il comando non restituisce alcun output:

aws iam update-access-key --access-key-id <access-key-id> --status Inactive --user-name <user-name>
  1. Per verificare che la coppia di chiavi di accesso selezionata sia stata deactivated eseguita correttamente, esegui di nuovo il comando di controllo list-access-keys per l'utente IAM:
aws iam list-access-keys --user-name <user-name>
  • L'output del comando deve mostrare i metadati per ogni chiave di accesso associata all'utente IAM. Se la coppia o le coppie di chiavi non operative Status sono impostate su Inactive, la chiave è stata disattivata correttamente e la configurazione dell'accesso utente IAM ora rispetta questo consiglio.
  1. Ripeti i passaggi 1-3 per ogni utente IAM nel tuo account AWS.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Public Access Given Rds Instance

Nome della categoria nell'API: PUBLIC_ACCESS_GIVEN_RDS_INSTANCE

Assicurati e verifica che le istanze di database RDS di cui è stato eseguito il provisioning nel tuo account AWS limitino l'accesso non autorizzato per ridurre al minimo i rischi per la sicurezza. Per limitare l'accesso a qualsiasi istanza di database RDS accessibile pubblicamente, devi disabilitare il flag Accessibile pubblicamente del database e aggiornare il gruppo di sicurezza VPC associato all'istanza.

Consiglio: assicurati che l'accesso pubblico non sia concesso all'istanza RDS

Per risolvere questo problema, completa i seguenti passaggi:

Console AWS

  1. Accedi alla Console di gestione AWS e vai al pannello di controllo RDS all'indirizzo https://console.aws.amazon.com/rds/.
  2. Nel pannello di navigazione, nella dashboard RDS, fai clic su Databases.
  3. Seleziona l'istanza RDS che vuoi aggiornare.
  4. Fai clic su Modify dal menu in alto della dashboard.
  5. Nel riquadro Modifica istanza DB, nella sezione Connectivity, fai clic su Additional connectivity configuration e aggiorna il valore di Publicly Accessible su Non accessibile pubblicamente per limitare l'accesso pubblico. Segui i passaggi riportati di seguito per aggiornare le configurazioni delle subnet:
    - Seleziona la scheda Connectivity and security e fai clic sul valore dell'attributo VPC all'interno della sezione Networking.
    - Seleziona la scheda Details dal riquadro inferiore della dashboard VPC e fai clic sul valore dell'attributo di configurazione della tabella di routing.
    - Nella pagina dei dettagli della tabella di routing, seleziona la scheda Itinerari dal riquadro inferiore della dashboard e fai clic su Edit routes.
    - Nella pagina Modifica itinerari, aggiorna la Destinazione del target impostata su igw-xxxxx e fai clic su Save itinerari.
  6. Nel pannello Modifica istanza DB, fai clic su Continue e, nella sezione Pianificazione delle modifiche, esegui una delle seguenti azioni in base ai tuoi requisiti:
    - Seleziona Applica durante la prossima periodo di manutenzione pianificata per applicare automaticamente le modifiche durante la prossima periodo di manutenzione pianificata.
    - Seleziona Applica immediatamente per applicare subito le modifiche. Con questa opzione, tutte le modifiche in attesa verranno applicate in modo asincrono il prima possibile, indipendentemente dall'impostazione del periodo di manutenzione per questa istanza di database RDS. Tieni presente che vengono applicate anche le modifiche disponibili nella coda delle modifiche in attesa. Se una delle modifiche in attesa richiede tempi di inattività, la scelta di questa opzione può causare tempi di inattività imprevisti per l'applicazione.
  7. Ripeti i passaggi da 3 a 6 per ogni istanza RDS disponibile nella regione corrente.
  8. Modifica la regione AWS dalla barra di navigazione per ripetere la procedura per altre regioni.

Interfaccia a riga di comando AWS

  1. Esegui il comando describe-db-instances per elencare tutti gli identificatori dei nomi dei database RDS disponibili nella regione AWS selezionata:
aws rds describe-db-instances --region <region-name> --query 'DBInstances[*].DBInstanceIdentifier'
  1. L'output del comando deve restituire l'identificatore di ogni istanza di database.
  2. Esegui il comando modify-db-instance per modificare la configurazione dell'istanza RDS selezionata. Quindi, utilizza il comando seguente per disattivare il flag Publicly Accessible per le istanze RDS selezionate. Questo comando utilizza il flag apply-immediately. Se vuoi to avoid any downtime --no-apply-immediately flag can be used:
aws rds modify-db-instance --region <region-name> --db-instance-identifier <db-name> --no-publicly-accessible --apply-immediately
  1. L'output del comando dovrebbe mostrare la configurazione PubliclyAccessible nei valori in attesa e dovrebbe essere applicata all'ora specificata.
  2. L'aggiornamento della destinazione del gateway internet tramite AWS CLI non è attualmente supportato. Per aggiornare le informazioni sul gateway internet, utilizza la procedura della console AWS.
  3. Ripeti i passaggi da 1 a 5 per ogni istanza RDS di cui è stato eseguito il provisioning nella regione corrente.
  4. Modifica la regione AWS utilizzando il filtro --region per ripetere la procedura per altre regioni.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Rds Enhanced Monitoring Enabled

Nome della categoria nell'API: RDS_ENHANCED_MONITORING_ENABLED

Il monitoraggio avanzato fornisce metriche in tempo reale sul sistema operativo su cui viene eseguita l'istanza RDS tramite un agente installato nell'istanza.

Per maggiori dettagli, vedi Monitoraggio delle metriche del sistema operativo con il monitoraggio avanzato.

Consiglio: controlla se il monitoraggio avanzato è abilitato per tutte le istanze DB RDS

Per risolvere questo problema, completa i seguenti passaggi:

Terraform

Per correggere questo controllo, attiva il monitoraggio avanzato sulle tue istanze RDS nel seguente modo:

Crea un ruolo IAM per RDS:

resource "aws_iam_role" "rds_logging" {
  name = "CustomRoleForRDSMonitoring"
  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Action = "sts:AssumeRole"
        Effect = "Allow"
        Sid    = "CustomRoleForRDSLogging"
        Principal = {
          Service = "monitoring.rds.amazonaws.com"
        }
      },
    ]
  })
}

Recupera la policy gestita da AWS per il monitoraggio avanzato di RDS:

data "aws_iam_policy" "rds_logging" {
  name = "AmazonRDSEnhancedMonitoringRole"
}

Allega la policy al ruolo:

resource "aws_iam_policy_attachment" "rds_logging" {
  name       = "AttachRdsLogging"
  roles      = [aws_iam_role.rds_logging.name]
  policy_arn = data.aws_iam_policy.rds_logging.arn
}

Definisci un intervallo di monitoraggio e un ARN del ruolo di monitoraggio per l'istanza RDS che viola la norma per abilitare il monitoraggio avanzato:

resource "aws_db_instance" "default" {
  identifier           = "test-rds"
  allocated_storage    = 10
  engine               = "mysql"
  engine_version       = "5.7"
  instance_class       = "db.t3.micro"
  db_name              = "mydb"
  username             = "foo"
  password             = "foobarbaz"
  parameter_group_name = "default.mysql5.7"
  skip_final_snapshot  = true
  monitoring_interval  = 60
  monitoring_role_arn  = aws_iam_role.rds_logging.arn
}

Console AWS

Puoi attivare il monitoraggio avanzato quando crei un'istanza DB, un cluster DB Multi-AZ o una replica di lettura oppure quando modifichi un'istanza DB o un cluster DB Multi-AZ. Se modifichi un'istanza del database per attivare il monitoraggio avanzato, non è necessario riavviarla per applicare la modifica.

Puoi attivare il monitoraggio avanzato nella console RDS quando esegui una delle seguenti azioni nella pagina Database:

  • Crea un'istanza del database o un cluster di database Multi-AZ: scegli Crea database.
  • Crea una replica di lettura: scegli Azioni, poi Crea replica di lettura.
  • Modifica un'istanza DB o un cluster DB Multi-AZ: scegli Modifica.

Per attivare o disattivare il monitoraggio avanzato nella console RDS

  1. Scorri fino a Configurazione aggiuntiva.
  2. In Monitoraggio, scegli Abilita monitoraggio avanzato per l'istanza DB o la replica di lettura. Per disattivare il monitoraggio avanzato, scegli Disattiva monitoraggio avanzato.
  3. Imposta la proprietà Ruolo di monitoraggio sul ruolo IAM che hai creato per consentire ad Amazon RDS di comunicare con Amazon CloudWatch Logs per tuo conto oppure scegli Predefinito per consentire a RDS di creare un ruolo denominato rds-monitoring-role.
  4. Imposta la proprietà Granularità sull'intervallo, in secondi, tra i punti in cui vengono raccolte le metriche per l'istanza del database o la replica di lettura. La proprietà Granularità può essere impostata su uno dei seguenti valori: 1, 5, 10, 15, 30 o 60. L'aggiornamento più rapido della console RDS avviene ogni 5 secondi. Se imposti la granularità su 1 secondo nella console RDS, vedrai comunque le metriche aggiornate solo ogni 5 secondi. Puoi recuperare gli aggiornamenti delle metriche di 1 secondo utilizzando CloudWatch Logs.

Interfaccia a riga di comando AWS

Crea il ruolo IAM RDS:

aws iam create-role \
  --role-name "CustomRoleForRDSMonitoring" \
  --assume-role-policy-document file://rds-assume-role.json

Collega la policy AmazonRDSEnhancedMonitoringRole al ruolo:

aws iam attach-role-policy \
  --role-name "CustomRoleForRDSMonitoring"\
  --policy-arn "arn:aws:iam::aws:policy/service-role/AmazonRDSEnhancedMonitoringRole"

Modifica l'istanza RDS per abilitare il monitoraggio avanzato impostando --monitoring-interval e --monitoring-role-arn:

aws rds modify-db-instance \
  --db-instance-identifier "test-rds" \
  --monitoring-interval 30 \
  --monitoring-role-arn "arn:aws:iam::<account_id>:role/CustomRoleForRDSMonitoring"

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Rds Instance Deletion Protection Enabled

Nome della categoria nell'API: RDS_INSTANCE_DELETION_PROTECTION_ENABLED

L'attivazione della protezione da eliminazione dell'istanza è un ulteriore livello di protezione contro l'eliminazione accidentale del database o l'eliminazione da parte di un'entità non autorizzata.

Se la protezione da eliminazione è abilitata, un'istanza del database RDS non può essere eliminata. Prima che una richiesta di eliminazione possa essere completata, la protezione da eliminazione deve essere disattivata.

Consiglio: controlla se per tutte le istanze RDS è abilitata la protezione da eliminazione

Per risolvere questo problema, completa i seguenti passaggi:

Terraform

Per correggere questo controllo, imposta deletion_protection su true nella risorsa aws_db_instance.

resource "aws_db_instance" "example" {
  # ... other configuration ...
  deletion_protection = true
}

Console AWS

Per abilitare la protezione da eliminazione per un'istanza DB RDS

  1. Apri la console Amazon RDS all'indirizzo https://console.aws.amazon.com/rds/.
  2. Nel riquadro di navigazione, scegli Database, quindi scegli l'istanza DB da modificare.
  3. Scegli Modifica.
  4. Nella sezione Protezione da eliminazione, scegli Abilita la protezione da eliminazione.
  5. Scegli Continua.
  6. In Pianificazione delle modifiche, scegli quando applicare le modifiche. Le opzioni sono Applica durante il successivo periodo di manutenzione pianificato o Applica immediatamente.
  7. Scegli Modifica istanza DB.

Interfaccia a riga di comando AWS

Lo stesso vale per l'interfaccia a riga di comando AWS. Imposta --deletion-protection come indicato di seguito.

aws rds modify-db-instance \
  --db-instance-identifier = "test-rds" \
  --deletion-protection

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Rds In Backup Plan

Nome della categoria nell'API: RDS_IN_BACKUP_PLAN

Questo controllo valuta se le istanze DB Amazon RDS sono coperte da un piano di backup. Questo controllo non viene superato se un'istanza DB di RDS non è coperta da un piano di backup.

AWS Backup è un servizio di backup completamente gestito che centralizza e automatizza il backup dei dati nei servizi AWS. Con AWS Backup, puoi creare policy di backup chiamate piani di backup. Puoi utilizzare questi piani per definire i requisiti di backup, ad esempio la frequenza con cui eseguire il backup dei dati e per quanto tempo conservare i backup. L'inclusione delle istanze DB di RDS in un piano di backup ti aiuta a proteggere i tuoi dati da perdite o eliminazioni involontarie.

Suggerimento: le istanze DB di RDS devono essere coperte da un piano di backup

Per risolvere questo problema, completa i seguenti passaggi:

Terraform

Per correggere questo controllo, imposta backup_retention_period su un valore maggiore di 7 nella risorsa aws_db_instance.

resource "aws_db_instance" "example" {
  # ... other Configuration ...
  backup_retention_period = 7
}

Console AWS

Per abilitare immediatamente i backup automatici

  1. Apri la console Amazon RDS all'indirizzo https://console.aws.amazon.com/rds/.
  2. Nel riquadro di navigazione, scegli Database e poi l'istanza DB da modificare.
  3. Scegli Modifica per aprire la pagina Modifica istanza DB.
  4. In Periodo di conservazione del backup, scegli un valore positivo diverso da zero, ad esempio 30 giorni, poi scegli Continua.
  5. Seleziona la sezione Pianificazione delle modifiche e scegli quando applicare le modifiche: puoi scegliere Applica durante il prossimo periodo di manutenzione pianificato o Applica immediatamente.
  6. Poi, nella pagina di conferma, scegli Modifica istanza database per salvare le modifiche e attivare i backup automatici.

Interfaccia a riga di comando AWS

Lo stesso vale per l'interfaccia a riga di comando AWS. Per attivare i backup automatici, modifica backup-retention-period impostando un valore maggiore di 0 (valore predefinito).

aws rds modify-db-instance --db-instance-identifier "test-rds" --backup-retention-period 7

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Rds Logging Enabled

Nome della categoria nell'API: RDS_LOGGING_ENABLED

Controlla se i seguenti log di Amazon RDS sono abilitati e inviati a CloudWatch.

I database RDS devono avere i log pertinenti abilitati. Il logging del database fornisce registri dettagliati delle richieste effettuate a RDS. I log del database possono essere utili per i controlli di sicurezza e di accesso e possono aiutare a diagnosticare i problemi di disponibilità.

Consiglio: controlla se i log esportati sono abilitati per tutte le istanze DB RDS

Per risolvere questo problema, completa i seguenti passaggi:

Terraform

resource "aws_db_instance" "example" {
  # ... other configuration for MySQL ...
  enabled_cloudwatch_logs_exports = ["audit", "error", "general", "slowquery"]
  parameter_group_name            = aws_db_parameter_group.example.name
}

resource "aws_db_parameter_group" "example" {
  name   = "${aws_db_instance.example.dbInstanceIdentifier}-parameter-group"
  family = "mysql5.7"

  parameter {
    name  = "general_log"
    value = 1
  }

  parameter {
    name  = "slow_query_log"
    value = 1
  }

  parameter {
    name  = "log_output"
    value = "FILE"
  }
}

Per MariaDB, crea anche un gruppo di opzioni personalizzato e imposta option_group_name nella risorsa aws_db_instance.

resource "aws_db_instance" "example" {
  # ... other configuration for MariaDB ...
  enabled_cloudwatch_logs_exports = ["audit", "error", "general", "slowquery"]
  parameter_group_name            = aws_db_parameter_group.example.name
  option_group_name               = aws_db_option_group.example.name
}

resource "aws_db_option_group" "example" {
  name                     = "mariadb-option-group-for-logs"
  option_group_description = "MariaDB Option Group for Logs"
  engine_name              = "mariadb"
  option {
    option_name = "MARIADB_AUDIT_PLUGIN"
    option_settings {
      name  = "SERVER_AUDIT_EVENTS"
      value = "CONNECT,QUERY,TABLE,QUERY_DDL,QUERY_DML,QUERY_DCL"
    }
  }
}

Console AWS

Per creare un gruppo di parametri DB personalizzato

  1. Apri la console Amazon RDS all'indirizzo https://console.aws.amazon.com/rds/.
  2. Nel riquadro di navigazione, scegli Gruppi di parametri.
  3. Scegli Crea gruppo di parametri.
  4. Nell'elenco Famiglia di gruppi di parametri, scegli una famiglia di gruppi di parametri del database.
  5. Nell'elenco Tipo, scegli Gruppo di parametri del database.
  6. In Nome gruppo, inserisci il nome del nuovo gruppo di parametri del database.
  7. In Descrizione, inserisci una descrizione per il nuovo gruppo di parametri del database.
  8. Scegli Crea.

Per creare un nuovo gruppo di opzioni per la registrazione di MariaDB utilizzando la console

  1. Apri la console Amazon RDS all'indirizzo https://console.aws.amazon.com/rds/.
  2. Nel riquadro di navigazione, scegli Gruppi di opzioni.
  3. Scegli Crea gruppo.
  4. Nella finestra del gruppo di opzioni Crea, fornisci quanto segue:
    * Nome: deve essere univoco all'interno del tuo account AWS. Solo lettere, cifre e trattini.
    * Descrizione: utilizzata solo a scopo di visualizzazione.
    * Motore: seleziona il motore DB.
    * Versione principale del motore: seleziona la versione principale del motore DB.
  5. Scegli Crea.
  6. Scegli il nome del gruppo di opzioni appena creato.
  7. Scegli l'opzione Aggiungi.
  8. Scegli MARIADB_AUDIT_PLUGIN dall'elenco Nome opzione.
  9. Imposta SERVER_AUDIT_EVENTS su CONNECT, QUERY, TABLE, QUERY_DDL, QUERY_DML, QUERY_DCL.
  10. Scegli l'opzione Aggiungi.

Per pubblicare i log di SQL Server DB, Oracle DB o PostgreSQL su CloudWatch Logs dalla Console di gestione AWS

  1. Apri la console Amazon RDS all'indirizzo https://console.aws.amazon.com/rds/.
  2. Nel riquadro di navigazione, scegli Database.
  3. Scegli l'istanza del database che vuoi modificare.
  4. Scegli Modifica.
  5. In Esportazioni log, scegli tutti i file di log per iniziare la pubblicazione in CloudWatch Logs.
  6. L'esportazione dei log è disponibile solo per le versioni motore del database che supportano la pubblicazione in CloudWatch Logs.
  7. Scegli Continua. Poi, nella pagina di riepilogo, scegli Modifica istanza database.

Per applicare un nuovo gruppo di parametri DB o un nuovo gruppo di opzioni DB a un'istanza DB RDS

  1. Apri la console Amazon RDS all'indirizzo https://console.aws.amazon.com/rds/.
  2. Nel riquadro di navigazione, scegli Database.
  3. Scegli l'istanza del database che vuoi modificare.
  4. Scegli Modifica.
  5. Nella sezione Opzioni database, modifica il gruppo di parametri DB e il gruppo di opzioni DB in base alle esigenze.
  6. Al termine delle modifiche, scegli Continua. Controlla il riepilogo delle modifiche.
  7. Scegli Modifica istanza DB per salvare le modifiche.

Interfaccia a riga di comando AWS

Recupera le famiglie di motori e scegli quella che corrisponde al motore e alla versione dell'istanza del database.

aws rds describe-db-engine-versions \
  --query "DBEngineVersions[].DBParameterGroupFamily" \
  --engine "mysql"

Crea un gruppo di parametri in base al motore e alla versione.

aws rds create-db-parameter-group \
  --db-parameter-group-name "rds-mysql-parameter-group" \
  --db-parameter-group-family "mysql5.7" \
  --description "Example parameter group for logs"

Crea un file rds-parameters.json contenente i parametri necessari in base al motore DB. Questo esempio utilizza MySQL5.7.

[
  {
    "ParameterName": "general_log",
    "ParameterValue": "1",
    "ApplyMethod": "immediate"
  },
  {
    "ParameterName": "slow_query_log",
    "ParameterValue": "1",
    "ApplyMethod": "immediate"
  },
  {
    "ParameterName": "log_output",
    "ParameterValue": "FILE",
    "ApplyMethod": "immediate"
  }
]

Modifica il gruppo di parametri per aggiungere i parametri in base al motore del database. Questo esempio utilizza MySQL5.7

aws rds modify-db-parameter-group \
  --db-parameter-group-name "rds-mysql-parameter-group" \
  --parameters file://rds-parameters.json

Modifica l'istanza DB per associare il gruppo di parametri.

aws rds modify-db-instance \
  --db-instance-identifier "test-rds" \
  --db-parameter-group-name "rds-mysql-parameter-group"

Inoltre, per MariaDB, crea un gruppo di opzioni nel seguente modo.

aws rds create-option-group \
  --option-group-name "rds-mariadb-option-group" \
  --engine-name "mariadb" \
  --major-engine-version "10.6" \
  --option-group-description "Option group for MariaDB logs"

Crea un file rds-mariadb-options.json nel seguente modo.

{
  "OptionName": "MARIADB_AUDIT_PLUGIN",
  "OptionSettings": [
    {
      "Name": "SERVER_AUDIT_EVENTS",
      "Value": "CONNECT,QUERY,TABLE,QUERY_DDL,QUERY_DML,QUERY_DCL"
    }
  ]
}

Aggiungi l'opzione al gruppo di opzioni.

aws rds add-option-to-option-group \
  --option-group-name "rds-mariadb-option-group" \
  --options file://rds-mariadb-options.json

Associa il gruppo di opzioni all'istanza di database modificando l'istanza MariaDB.

aws rds modify-db-instance \
  --db-instance-identifier "rds-test-mariadb" \
  --option-group-name "rds-mariadb-option-group"

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Rds Multi Az Support

Nome della categoria nell'API: RDS_MULTI_AZ_SUPPORT

Le istanze DB di RDS devono essere configurate per più zone di disponibilità (AZ). Ciò garantisce la disponibilità dei dati memorizzati. I deployment multizona consentono il failover automatico in caso di problemi con la disponibilità della zona di disponibilità e durante la manutenzione regolare di RDS.

Consiglio: controlla se l'alta disponibilità è abilitata per tutte le istanze DB RDS

Per risolvere questo problema, completa i seguenti passaggi:

Terraform

Per correggere questo controllo, imposta multi_az su true nella risorsa aws_db_instance.

resource "aws_db_instance" "example" {
  # ... other configuration ...
  multi_az                = true
}

Console AWS

Per abilitare più zone di disponibilità per un'istanza di database

  1. Apri la console Amazon RDS all'indirizzo https://console.aws.amazon.com/rds/.
  2. Nel riquadro di navigazione, scegli Database e poi l'istanza DB da modificare.
  3. Scegli Modifica. Viene visualizzata la pagina Modifica istanza DB.
  4. In Specifiche istanza, imposta il deployment multi-AZ su Sì.
  5. Scegli Continua e controlla il riepilogo delle modifiche.
  6. (Facoltativo) Scegli Applica immediatamente per applicare subito le modifiche. La scelta di questa opzione può causare un'interruzione in alcuni casi. Per ulteriori informazioni, consulta la sezione Utilizzo dell'impostazione Applica immediatamente nella Guida per l'utente di Amazon RDS.
  7. Nella pagina di conferma, rivedi le modifiche. Se sono corretti, scegli Modifica istanza database per salvare le modifiche.

Interfaccia a riga di comando AWS

Lo stesso vale per l'interfaccia a riga di comando AWS. Attiva il supporto multi-AZ fornendo l'opzione --multi-az.

modify-db-instance
  --db-instance-identifier "test-rds" \
  --multi-az

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Redshift Cluster Configuration Check

Nome della categoria nell'API: REDSHIFT_CLUSTER_CONFIGURATION_CHECK

Controlla gli elementi essenziali di un cluster Redshift: crittografia at-rest, logging e tipo di nodo.

Questi elementi di configurazione sono importanti per la manutenzione di un cluster Redshift sicuro e osservabile.

Consiglio: controlla che tutti i cluster Redshift dispongano di crittografia at-rest, logging e tipo di nodo.

Per risolvere questo problema, completa i seguenti passaggi:

Terraform

resource "aws_kms_key" "redshift_encryption" {
  description         = "Used for Redshift encryption configuration"
  enable_key_rotation = true
}

resource "aws_redshift_cluster" "example" {
  # ... other configuration ...
  encrypted                           = true
  kms_key_id                          = aws_kms_key.redshift_encryption.id
  logging {
    enable               = true
    log_destination_type = "cloudwatch"
    log_exports          = ["connectionlog", "userlog", "useractivitylog"]
  }
}

Console AWS

Per abilitare il log di controllo del cluster

  1. Apri la console Amazon Redshift all'indirizzo https://console.aws.amazon.com/redshift/.
  2. Nel menu di navigazione, scegli Cluster, poi scegli il nome del cluster da modificare.
  3. Scegli Proprietà.
  4. Scegli Modifica e Modifica audit log.
  5. Imposta Configura audit logging su Attiva, imposta Tipo di esportazione log su CloudWatch (opzione consigliata) e scegli i log da esportare.

Per utilizzare AWS S3 per gestire i log di controllo di Redshift, consulta Redshift - Database audit logging nella documentazione di AWS.

  1. Scegli Salva modifiche.

Per modificare la crittografia del database su un cluster

  1. Accedi alla Console di gestione AWS e apri la console Amazon Redshift all'indirizzo https://console.aws.amazon.com/redshift/.
  2. Nel menu di navigazione, scegli Cluster, quindi scegli il cluster per cui vuoi modificare la crittografia.
  3. Scegli Proprietà.
  4. Scegli Modifica e Modifica crittografia.
  5. Scegli la crittografia da utilizzare (KMS o HSM) e fornisci:
  • Per KMS: chiave da utilizzare
  • Per HSM: connessione e certificato client

Interfaccia a riga di comando AWS

  1. Crea una chiave KMS e recupera l'ID chiave
aws kms create-key \
  --description "Key to encrypt Redshift Clusters"
  1. Modificare il cluster
aws redshift modify-cluster \
  --cluster-identifiers "test-redshift-cluster" \
  --encrypted \
  --kms-key-id <value>

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Redshift Cluster Maintenancesettings Check

Nome della categoria nell'API: REDSHIFT_CLUSTER_MAINTENANCESETTINGS_CHECK

Gli upgrade automatici delle versioni principali vengono eseguiti in base al periodo di manutenzione

Consiglio: controlla che tutti i cluster Redshift abbiano allowVersionUpgrade abilitato e preferredMaintenanceWindow e automatedSnapshotRetentionPeriod impostati

Per risolvere questo problema, completa i seguenti passaggi:

Terraform

Questo controllo è conforme a tutti i valori predefiniti forniti da Terraform. In caso di cluster Redshift non riuscito, esamina i requisiti e rimuovi gli override predefiniti per i seguenti attributi della risorsa aws_redshift_cluster.

resource "aws_redshift_cluster" "example" {

  # ...other configuration ...

  # The following values are compliant and set by default if omitted.
  allow_version_upgrade               = true
  preferred_maintenance_window        = "sat:10:00-sat:10:30"
  automated_snapshot_retention_period = 1
}

Console AWS

Quando crei un cluster Redshift tramite la console AWS, i valori predefiniti sono già conformi a questo controllo.

Per saperne di più, consulta Gestione dei cluster utilizzando la console.

Interfaccia a riga di comando AWS

Per correggere questo controllo utilizzando l'interfaccia a riga di comando AWS, procedi nel seguente modo:

aws redshift modify-cluster \
  --cluster-identifier "test-redshift-cluster" \
  --allow-version-upgrade

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Redshift Cluster Public Access Check

Nome della categoria nell'API: REDSHIFT_CLUSTER_PUBLIC_ACCESS_CHECK

L'attributo PubliclyAccessible della configurazione del cluster Amazon Redshift indica se il cluster è accessibile pubblicamente. Quando il cluster è configurato con PubliclyAccessible impostato su true, si tratta di un'istanza esposta a internet con un nome DNS risolvibile pubblicamente, che viene risolto in un indirizzo IP pubblico.

Quando il cluster non è accessibile pubblicamente, si tratta di un'istanza interna con un nome DNS che viene risolto in un indirizzo IP privato. A meno che tu non voglia che il cluster sia accessibile pubblicamente, non devi configurarlo con PubliclyAccessible impostato su true.

Consiglio: controlla se i cluster Redshift sono accessibili pubblicamente

Per risolvere questo problema, completa i seguenti passaggi:

Terraform

Per correggere questo controllo, è necessario modificare la risorsa cluster Redshift e impostare publicly_accessible su false. Il valore predefinito è true.

resource "aws_redshift_cluster" "example" {
  # ... other configuration ...
  publicly_accessible = false
}

Console AWS

Per disabilitare l'accesso pubblico a un cluster Amazon Redshift

  1. Apri la console Amazon Redshift all'indirizzo https://console.aws.amazon.com/redshift/.
  2. Nel menu di navigazione, scegli Cluster, quindi scegli il nome del cluster con il gruppo di sicurezza da modificare.
  3. Scegli Azioni, quindi Modifica impostazione accessibile pubblicamente.
  4. Nella sezione Consenti a istanze e dispositivi esterni al VPC di connettersi al database tramite l'endpoint del cluster, scegli No.
  5. Scegli Conferma.

Interfaccia a riga di comando AWS

Utilizza il comando modify-cluster per impostare --no-publicly-accessible.

aws redshift modify-cluster \
  --cluster-identifier "test-redshift-cluster" \
  --no-publicly-accessible

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Restricted Common Ports

Nome della categoria nell'API: RESTRICTED_COMMON_PORTS

Controlla se il traffico in entrata senza restrizioni per i gruppi di sicurezza è accessibile alle porte specificate che presentano il rischio più elevato. Questo controllo non viene superato se una delle regole di un gruppo di sicurezza consente il traffico in entrata da "0.0.0.0/0" o "::/0" per queste porte.

L'accesso illimitato (0.0.0.0/0) aumenta le opportunità di attività dannose, come hacking, attacchi denial of service e perdita di dati.

I gruppi di sicurezza forniscono un filtro stateful del traffico di rete in entrata e in uscita verso le risorse AWS. Nessun gruppo di sicurezza deve consentire l'accesso in entrata illimitato alle seguenti porte:

  • 20, 21 (FTP)
  • 22 (SSH)
  • 23 (Telnet)
  • 25 (SMTP)
  • 110 (POP3)
  • 135 (RPC)
  • 143 (IMAP)
  • 445 (CIFS)
  • 1433, 1434 (MSSQL)
  • 3000 (framework di sviluppo web Go, Node.js e Ruby)
  • 3306 (MySQL)
  • 3389 (RDP)
  • 4333 (ahsp)
  • 5000 (framework di sviluppo web Python)
  • 5432 (postgresql)
  • 5500 (fcp-addr-srvr1)
  • 5601 (OpenSearch Dashboards)
  • 8080 (proxy)
  • 8088 (porta HTTP legacy)
  • 8888 (porta HTTP alternativa)
  • 9200 o 9300 (OpenSearch)
Consiglio: i gruppi di sicurezza non devono consentire l'accesso illimitato alle porte ad alto rischio

Per risolvere questo problema, completa i seguenti passaggi:

Console AWS

Per eliminare una regola del gruppo di sicurezza:

  1. Apri la console Amazon EC2 all'indirizzo https://console.aws.amazon.com/ec2/.
  2. Nel riquadro di navigazione, scegli Gruppi di sicurezza.
  3. Seleziona il gruppo di sicurezza da aggiornare, scegli Azioni e poi Modifica regole in entrata per rimuovere una regola in entrata o Modifica regole in uscita per rimuovere una regola in uscita.
  4. Scegli il pulsante Elimina a destra della regola da eliminare.
  5. Scegli Anteprima modifiche, Conferma.

Per informazioni su come eliminare le regole da un gruppo di sicurezza, consulta Configurare le regole del gruppo di sicurezza nella Guida per l'utente di Amazon EC2.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Restricted Ssh

Nome della categoria nell'API: RESTRICTED_SSH

I gruppi di sicurezza forniscono un filtro stateful del traffico di rete in entrata e in uscita verso le risorse AWS.

Il CIS consiglia di non consentire a nessun gruppo di sicurezza l'accesso in entrata illimitato alla porta 22. La rimozione della connettività illimitata ai servizi di console remota, come SSH, riduce l'esposizione al rischio di un server.

Consiglio: i gruppi di sicurezza non devono consentire l'ingresso da 0.0.0.0/0 alla porta 22

Per risolvere questo problema, completa i seguenti passaggi:

Console AWS

Esegui i seguenti passaggi per ogni gruppo di sicurezza associato a un VPC.

Apri la console Amazon VPC all'indirizzo https://console.aws.amazon.com/vpc/.

  1. Nel riquadro a sinistra, scegli Gruppi di sicurezza.
  2. Seleziona un gruppo di sicurezza.
  3. Nella sezione inferiore della pagina, scegli la scheda Regole in entrata.
  4. Scegli Modifica regole.
  5. Identifica la regola che consente l'accesso tramite la porta 22 e scegli la X per rimuoverla.
  6. Scegli Salva regole.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Rotation Customer Created Cmks Enabled

Nome della categoria nell'API: ROTATION_CUSTOMER_CREATED_CMKS_ENABLED

Controlla se la rotazione automatica delle chiavi è abilitata per ogni chiave e corrisponde all'ID chiave della chiave KMS AWS creata dal cliente. La regola è NON_COMPLIANT se il ruolo di registrazione AWS Config per una risorsa non dispone dell'autorizzazione kms:DescribeKey.

Consiglio: assicurati che sia abilitata la rotazione per le chiavi CMK create dal cliente

Per abilitare la rotazione automatica delle chiavi per AWS KMS, consulta la sezione Rotazione delle chiavi AWS KMS nella documentazione di AWS.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Rotation Customer Created Symmetric Cmks Enabled

Nome della categoria nell'API: ROTATION_CUSTOMER_CREATED_SYMMETRIC_CMKS_ENABLED

AWS Key Management Service (KMS) consente ai clienti di ruotare la chiave di backup, ovvero il materiale della chiave archiviato in KMS e associato all'ID chiave della chiave master del cliente (CMK) creata dal cliente. È la chiave di supporto utilizzata per eseguire operazioni crittografiche come la crittografia e la decriptazione. La rotazione automatica delle chiavi attualmente conserva tutte le chiavi di backup precedenti in modo che la decrittografia dei dati criptati possa avvenire in modo trasparente. Ti consigliamo di abilitare rotazione della chiave CMK per le chiavi simmetriche. La rotazione delle chiavi non può essere abilitata per nessuna chiave CMK asimmetrica.

Consiglio: assicurati che sia abilitata la rotazione per le chiavi CMK simmetriche create dal cliente

Per risolvere questo problema, completa i seguenti passaggi:

Console AWS

  1. Accedi alla Console di gestione AWS e apri la console IAM all'indirizzo https://console.aws.amazon.com/iam.
  2. Nel riquadro di navigazione a sinistra, scegli Customer managed keys .
  3. Seleziona una CMK gestita dal cliente in cui Key spec = SYMMETRIC_DEFAULT
  4. Sotto il riquadro "Configurazione generale", apri la scheda "Rotazione delle chiavi".
  5. Seleziona la casella di controllo "Ruota automaticamente questa chiave KMS ogni anno".

Interfaccia a riga di comando AWS

  1. Esegui questo comando per abilitare rotazione della chiave:
 aws kms enable-key-rotation --key-id <kms_key_id>

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Routing Tables Vpc Peering Are Least Access

Nome della categoria nell'API: ROUTING_TABLES_VPC_PEERING_ARE_LEAST_ACCESS

Verifica se le tabelle di routing per il peering VPC sono configurate con il principio del privilegio minimo.

Consiglio: assicurati che le tabelle di routing per il peering VPC siano ad "accesso minimo"

Per aggiornare le tabelle di routing per il peering VPC, consulta Aggiornare le tabelle di routing per una connessione di peering VPC nella guida per l'utente di AWS VPC.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

S3 Account Level Public Access Blocks

Nome della categoria nell'API: S3_ACCOUNT_LEVEL_PUBLIC_ACCESS_BLOCKS

Il blocco dell'accesso pubblico di Amazon S3 fornisce impostazioni per punti di accesso, bucket e account per aiutarti a gestire l'accesso pubblico alle risorse Amazon S3. Per impostazione predefinita, i nuovi bucket, punti di accesso e oggetti non consentono l'accesso pubblico.

Consiglio: controlla se le impostazioni richieste di blocco dell'accesso pubblico S3 sono configurate a livello di account

Per risolvere questo problema, completa i seguenti passaggi:

Terraform

La seguente risorsa Terraform configura l'accesso a livello di account a S3.

resource "aws_s3_account_public_access_block" "s3_control" {
  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

Console AWS

Per modificare le impostazioni di blocco dell'accesso pubblico per tutti i bucket S3 in un account AWS.

  1. Accedi alla Console di gestione AWS e apri la console Amazon S3 all'indirizzo https://console.aws.amazon.com/s3/.
  2. Scegli le impostazioni di accesso pubblico con blocco per questo account.
  3. Scegli Modifica per modificare le impostazioni di accesso pubblico con blocco per tutti i bucket nel tuo account AWS.
  4. Scegli le impostazioni che vuoi modificare e poi seleziona Salva modifiche.
  5. Quando ti viene chiesta la conferma, inserisci confirm. Poi scegli Conferma per salvare le modifiche.

Interfaccia a riga di comando AWS

aws s3control put-public-access-block \
--account-id <value> \
--public-access-block-configuration '{"BlockPublicAcls": true, "BlockPublicPolicy": true, "IgnorePublicAcls": true, "RestrictPublicBuckets": true}'

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

S3 Buckets Configured Block Public Access Bucket And Account Settings

Nome della categoria nell'API: S3_BUCKETS_CONFIGURED_BLOCK_PUBLIC_ACCESS_BUCKET_AND_ACCOUNT_SETTINGS

Amazon S3 fornisce Block public access (bucket settings) e Block public access (account settings) per aiutarti a gestire l'accesso pubblico alle risorse Amazon S3. Per impostazione predefinita, i bucket e gli oggetti S3 vengono creati con l'accesso pubblico disattivato. Tuttavia, un'entità AWS IAM con autorizzazioni S3 sufficienti può attivare l'accesso pubblico a livello di bucket o di oggetto. Se abilitata, Block public access (bucket settings) impedisce che un singolo bucket e i relativi oggetti contenuti diventino accessibili pubblicamente. Analogamente, Block public access (account settings) impedisce che tutti i bucket e gli oggetti contenuti diventino accessibili pubblicamente in tutto l'account.

Suggerimento:

Assicurati che i bucket S3 siano configurati con Block public access (bucket settings).

Per risolvere questo problema, completa i seguenti passaggi:

Console AWS

Se l'output indica true per le impostazioni di configurazione separate, significa che sono impostate nell'account.

  1. Accedi alla Console di gestione AWS e apri la console Amazon S3 utilizzando https://console.aws.amazon.com/s3/
  2. Scegli Blocca l'accesso pubblico (impostazioni account).
  3. Scegli Modifica per modificare le impostazioni di accesso pubblico con blocco per tutti i bucket nel tuo account AWS.
  4. Scegli le impostazioni che vuoi modificare e poi seleziona Salva. Per informazioni dettagliate su ciascuna impostazione, passa il mouse sopra le icone i.
  5. Quando ti viene chiesta la conferma, inserisci confirm. Poi fai clic su Conferma per salvare le modifiche.

Interfaccia a riga di comando AWS

Per impostare le impostazioni di Blocco dell'accesso pubblico per questo account, esegui questo comando:

aws s3control put-public-access-block
--public-access-block-configuration BlockPublicAcls=true, IgnorePublicAcls=true, BlockPublicPolicy=true, RestrictPublicBuckets=true
--account-id <value>

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

S3 Bucket Access Logging Enabled Cloudtrail S3 Bucket

Nome della categoria nell'API: S3_BUCKET_ACCESS_LOGGING_ENABLED_CLOUDTRAIL_S3_BUCKET

Il logging dell'accesso al bucket S3 genera un log che contiene i record di accesso per ogni richiesta effettuata al bucket S3. Un record del log degli accessi contiene dettagli sulla richiesta, come il tipo di richiesta, le risorse specificate nella richiesta, l'ora e la data di elaborazione della richiesta. Ti consigliamo di abilitare il logging degli accessi al bucket S3 CloudTrail.

Suggerimento:

Assicurati che il logging degli accessi ai bucket S3 sia abilitato sul bucket S3 CloudTrail

Per risolvere questo problema, completa i seguenti passaggi:

Console AWS

  1. Accedi alla Console di gestione AWS e apri la console S3 all'indirizzo https://console.aws.amazon.com/s3.
  2. In Tutti i bucket, fai clic sul bucket S3 di destinazione.
  3. Fai clic su Proprietà in alto a destra nella console.
  4. Nella sezione Bucket: <s3\_bucket\_for\_cloudtrail>, fai clic su Logging</b></s3\_bucket\_for\_cloudtrail>.
  5. Configura la registrazione dei bucket
    - Fai clic sulla casella di controllo Abilitata
    - Seleziona il bucket di destinazione dall'elenco
    - Inserisci un prefisso di destinazione
  6. Fai clic su Salva.

Interfaccia a riga di comando AWS

  1. Recupera il nome del bucket S3 in cui CloudTrail registra i log:
aws cloudtrail describe-trails --region <region-name> --query trailList[*].S3BucketName
  1. Copia e aggiungi il nome del bucket di destinazione in , il prefisso per il file di log in e, facoltativamente, aggiungi un indirizzo email nel seguente modello e salvalo come :
{
 "LoggingEnabled": {
 "TargetBucket": "<Logging_BucketName>",
 "TargetPrefix": "<LogFilePrefix>",
 "TargetGrants": [
 {
 "Grantee": {
 "Type": "AmazonCustomerByEmail",
 "EmailAddress": "<EmailID>"
 },
 "Permission": "FULL_CONTROL"
 }
 ]
 }
}
  1. Esegui il comando put-bucket-logging con il nome del bucket e come input. Per ulteriori informazioni, consulta put-bucket-logging:
aws s3api put-bucket-logging --bucket <BucketName> --bucket-logging-status file://<FileName.Json>

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

S3 Bucket Logging Enabled

Nome della categoria nell'API: S3_BUCKET_LOGGING_ENABLED

La funzionalità di logging degli accessi di AWS S3 Server registra le richieste di accesso ai bucket di archiviazione, il che è utile per gli audit di sicurezza. Per impostazione predefinita, il logging degli accessi al server non è abilitato per i bucket S3.

Consiglio: controlla se il logging è abilitato su tutti i bucket S3

Per risolvere questo problema, completa i seguenti passaggi:

Terraform

Il seguente esempio mostra come creare due bucket:

  1. Un bucket di logging
  2. Un bucket conforme
variable "bucket_acl_map" {
  type = map(any)
  default = {
    "logging-bucket"   = "log-delivery-write"
    "compliant-bucket" = "private"
  }
}

resource "aws_s3_bucket" "all" {
  for_each            = var.bucket_acl_map
  bucket              = each.key
  object_lock_enabled = true
  tags = {
    "Pwd"    = "s3"
  }
}

resource "aws_s3_bucket_acl" "private" {
  for_each = var.bucket_acl_map
  bucket   = each.key
  acl      = each.value
}

resource "aws_s3_bucket_versioning" "enabled" {
  for_each = var.bucket_acl_map
  bucket   = each.key
  versioning_configuration {
    status = "Enabled"
  }
}

resource "aws_s3_bucket_logging" "enabled" {
  for_each      = var.bucket_acl_map
  bucket        = each.key
  target_bucket = aws_s3_bucket.all["logging-bucket"].id
  target_prefix = "log/"
}

resource "aws_s3_bucket_server_side_encryption_configuration" "example" {
  for_each = var.bucket_acl_map
  bucket   = each.key

  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm     = "aws:kms"
    }
  }
}

Console AWS

Per informazioni su come attivare il logging degli accessi a S3 tramite la console AWS, consulta Abilitazione del logging degli accessi al server Amazon S3 nella documentazione di AWS.

Interfaccia a riga di comando AWS

Il seguente esempio mostra come:

  1. Crea una policy del bucket per concedere all'entità di servizio di logging l'autorizzazione a PutObject nel bucket Logging.

policy.json

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "S3ServerAccessLogsPolicy",
            "Effect": "Allow",
            "Principal": {"Service": "logging.s3.amazonaws.com"},
            "Action": "s3:PutObject",
            "Resource": "arn:aws:s3:::MyBucket/Logs/*",
            "Condition": {
                "ArnLike": {"aws:SourceARN": "arn:aws:s3:::SOURCE-BUCKET-NAME"},
                "StringEquals": {"aws:SourceAccount": "SOURCE-AWS-ACCOUNT-ID"}
            }
        }
    ]
}

aws s3api put-bucket-policy \
  --bucket my-bucket
  --policy file://policy.json
  1. Applica il criterio al bucket di logging

logging.json

{
    "LoggingEnabled": {
        "TargetBucket": "MyBucket",
        "TargetPrefix": "Logs/"
    }
}

aws s3api put-bucket-logging \
  --bucket MyBucket \
  --bucket-logging-status file://logging.json

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

S3 Bucket Policy Set Deny Http Requests

Nome della categoria nell'API: S3_BUCKET_POLICY_SET_DENY_HTTP_REQUESTS

A livello di bucket Amazon S3, puoi configurare le autorizzazioni tramite un criterio bucket, rendendo gli oggetti accessibili solo tramite HTTPS.

Consiglio: assicurati che la policy bucket S3 sia impostata in modo da rifiutare le richieste HTTP

Per risolvere questo problema, completa i seguenti passaggi:

Console AWS

utilizzando AWS Policy Generator:

  1. Ripeti i passaggi 1-4 descritti in precedenza.
  2. Fai clic su Policy Generator nella parte inferiore dell'editor delle norme del bucket.
  3. Seleziona il tipo di policy
    S3 Bucket Policy
  4. Aggiungi istruzioni
    - Effect = Nega
    - Principal = *
    - AWS Service = Amazon S3
    - Actions = *
    - Amazon Resource Name =
  5. Genera criterio
  6. Copia il testo e aggiungilo alla policy del bucket.

Interfaccia a riga di comando AWS

  1. Esporta la policy del bucket in un file JSON.
aws s3api get-bucket-policy --bucket <bucket_name> --query Policy --output text > policy.json
  1. Modifica il file policy.json aggiungendo questa istruzione:
{
 "Sid": <optional>",
 "Effect": "Deny",
 "Principal": "*",
 "Action": "s3:*",
 "Resource": "arn:aws:s3:::<bucket_name>/*",
 "Condition": {
 "Bool": {
 "aws:SecureTransport": "false"
 }
 }
 }
  1. Applica di nuovo questa policy modificata al bucket S3:
aws s3api put-bucket-policy --bucket <bucket_name> --policy file://policy.json

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

S3 Bucket Replication Enabled

Nome della categoria nell'API: S3_BUCKET_REPLICATION_ENABLED

Questo controllo verifica se la replica tra regioni è abilitata per un bucket Amazon S3. Il controllo non riesce se la replica tra regioni non è abilitata per il bucket o se è abilitata anche la replica nella stessa regione.

La replica è la copia automatica e asincrona degli oggetti tra bucket nella stessa regione AWS o in regioni AWS diverse. La replica copia gli oggetti appena creati e gli aggiornamenti degli oggetti da un bucket di origine a uno o più bucket di destinazione. Le best practice di AWS consigliano la replica per i bucket di origine e di destinazione di proprietà dello stesso account AWS. Oltre alla disponibilità, devi prendere in considerazione altre impostazioni di protezione del sistema.

Consiglio: controlla se la replica tra regioni di bucket S3 è abilitata

Per abilitare la replica tra regioni in un bucket S3, consulta Configurazione della replica per i bucket di origine e di destinazione di proprietà dello stesso account nella Guida per l'utente di Amazon Simple Storage Service. Per Bucket di origine, scegli Applica a tutti gli oggetti nel bucket.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

S3 Bucket Server Side Encryption Enabled

Nome della categoria nell'API: S3_BUCKET_SERVER_SIDE_ENCRYPTION_ENABLED

Controlla che il bucket S3 abbia la crittografia predefinita di Amazon S3 abilitata o che la policy del bucket S3 neghi esplicitamente le richieste put-object senza crittografia lato server.

Consiglio: assicurati che tutti i bucket S3 utilizzino la crittografia at-rest

Per risolvere questo problema, completa i seguenti passaggi:

Terraform

resource "aws_s3_bucket_server_side_encryption_configuration" "enable" {
  bucket = "my-bucket"

  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm = "AES256"
    }
  }
}

Console AWS

Per abilitare la crittografia predefinita su un bucket S3

  1. Apri la console Amazon S3 all'indirizzo https://console.aws.amazon.com/s3/.
  2. Nel riquadro di navigazione a sinistra, scegli Bucket.
  3. Scegli il bucket S3 dall'elenco.
  4. Scegli Proprietà.
  5. Scegli Crittografia predefinita.
  6. Per la crittografia, scegli AES-256 o AWS-KMS.
  7. Scegli AES-256 per utilizzare le chiavi gestite da Amazon S3 per la crittografia predefinita. Per saperne di più sull'utilizzo della crittografia lato server di Amazon S3 per criptare i dati, consulta la Guida per l'utente di Amazon Simple Storage Service.
  8. Scegli AWS-KMS per utilizzare le chiavi gestite da AWS KMS per la crittografia predefinita. Quindi, scegli una chiave master dall'elenco delle chiavi master AWS KMS che hai creato.
  9. Digita l'Amazon Resource Name (ARN) della chiave AWS KMS da utilizzare. Puoi trovare l'ARN della tua chiave AWS KMS nella console IAM, alla voce Chiavi di crittografia. In alternativa, puoi scegliere un nome della chiave dall'elenco a discesa.
  10. Importante: se utilizzi l'opzione AWS KMS per la configurazione di crittografia predefinita, sei soggetto alle quote RPS (richieste al secondo) di AWS KMS. Per ulteriori informazioni sulle quote di AWS KMS e su come richiedere un aumento della quota, consulta la Guida per gli sviluppatori di AWS Key Management Service.
  11. Scegli Salva.

Per ulteriori informazioni sulla creazione di una chiave AWS KMS, consulta la Guida per gli sviluppatori di AWS Key Management Service.

Per ulteriori informazioni sull'utilizzo di AWS KMS con Amazon S3, consulta la Guida per l'utente di Amazon Simple Storage Service.

Quando attivi la crittografia predefinita, potresti dover aggiornare la policy del bucket. Per ulteriori informazioni sul passaggio dalle norme dei bucket alla crittografia predefinita, consulta la Guida per l'utente di Amazon Simple Storage Service.

Interfaccia a riga di comando AWS

aws s3api put-bucket-encryption \
  --bucket my-bucket \
  --server-side-encryption-configuration '{"Rules": [{"ApplyServerSideEncryptionByDefault": {"SSEAlgorithm": "AES256"}}]}'

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

S3 Bucket Versioning Enabled

Nome della categoria nell'API: S3_BUCKET_VERSIONING_ENABLED

Amazon S3 è un modo per conservare più varianti di un oggetto nello stesso bucket e può aiutarti a eseguire il ripristino più facilmente sia da azioni utente non intenzionali sia da errori dell'applicazione.

Consiglio: controlla che il controllo delle versioni sia abilitato per tutti i bucket S3

Per risolvere questo problema, completa i seguenti passaggi:

Terraform

resource "aws_s3_bucket" "my_bucket" {
  bucket = "my-bucket"

  versioning {
    enabled = true
  }
}

Console AWS

Per attivare o disattivare il controllo delle versioni su un bucket S3

  1. Accedi alla Console di gestione AWS e apri la console Amazon S3 all'indirizzo https://console.aws.amazon.com/s3/.
  2. Nell'elenco dei bucket, scegli il nome del bucket per cui vuoi attivare il controllo delle versioni.
  3. Scegli Proprietà.
  4. In Controllo delle versioni del bucket, scegli Modifica.
  5. Scegli Sospendi o Attiva, quindi scegli Salva modifiche.

Interfaccia a riga di comando AWS

aws s3control put-bucket-versioning \
--bucket <bucket_name> \
--versioning-configuration Status=Enabled

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

S3 Default Encryption Kms

Nome della categoria nell'API: S3_DEFAULT_ENCRYPTION_KMS

Controlla se i bucket Amazon S3 sono criptati con AWS Key Management Service (AWS KMS)

Consiglio: controlla che tutti i bucket siano criptati con KMS

Per risolvere questo problema, completa i seguenti passaggi:

Terraform

resource "aws_kms_key" "s3_encryption" {
  description         = "Used for S3 Bucket encryption configuration"
  enable_key_rotation = true
}

resource "aws_s3_bucket_server_side_encryption_configuration" "enable" {
  bucket   = "my-bucket"

  rule {
    apply_server_side_encryption_by_default {
      kms_master_key_id = aws_kms_key.s3_encryption.arn
      sse_algorithm     = "aws:kms"
    }
  }
}

Console AWS

Per abilitare la crittografia predefinita su un bucket S3

  1. Apri la console Amazon S3 all'indirizzo https://console.aws.amazon.com/s3/.
  2. Nel riquadro di navigazione a sinistra, scegli Bucket.
  3. Scegli il bucket S3 dall'elenco.
  4. Scegli Proprietà.
  5. Scegli Crittografia predefinita.
  6. Per la crittografia, scegli AWS-KMS.
  7. Scegli AWS-KMS per utilizzare le chiavi gestite da AWS KMS per la crittografia predefinita. Quindi, scegli una chiave master dall'elenco delle chiavi master AWS KMS che hai creato. Per ulteriori informazioni su come creare chiavi KMS, consulta la documentazione AWS - Creating Keys.
  8. Digita l'Amazon Resource Name (ARN) della chiave AWS KMS da utilizzare. Puoi trovare l'ARN della tua chiave AWS KMS nella console IAM, alla voce Chiavi di crittografia. In alternativa, puoi scegliere un nome della chiave dall'elenco a discesa.
  9. Importante: questa soluzione è soggetta alle quote RPS (richieste al secondo) di AWS KMS. Per ulteriori informazioni sulle quote di AWS KMS e su come richiedere un aumento della quota, consulta la Guida per gli sviluppatori di AWS Key Management Service.
  10. Scegli Salva.

Per ulteriori informazioni sull'utilizzo di AWS KMS con Amazon S3, consulta la Guida per l'utente di Amazon Simple Storage Service.

Quando attivi la crittografia predefinita, potresti dover aggiornare la policy del bucket. Per ulteriori informazioni sul passaggio dalle norme dei bucket alla crittografia predefinita, consulta la Guida per l'utente di Amazon Simple Storage Service.

Interfaccia a riga di comando AWS

Crea una chiave KMS

aws kms create-key \
  --description "Key to encrypt S3 buckets"

Attivare rotazione della chiave

aws kms enable-key-rotation \
  --key-id <key_id_from_previous_command>

Aggiorna bucket

aws s3api put-bucket-encryption \
  --bucket my-bucket \
  --server-side-encryption-configuration '{"Rules": [{"ApplyServerSideEncryptionByDefault": {"KMSMasterKeyID": "<id_from_key>", "SSEAlgorithm": "AES256"}}]}'

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Sagemaker Notebook Instance Kms Key Configured

Nome della categoria nell'API: SAGEMAKER_NOTEBOOK_INSTANCE_KMS_KEY_CONFIGURED

Controlla se è configurata una chiave AWS Key Management Service (AWS KMS) per un'istanza di notebook Amazon SageMaker. La regola è NON_COMPLIANT se "KmsKeyId" non è specificato per l'istanza del notebook SageMaker.

Consiglio: controlla che tutte le istanze di notebook SageMaker siano configurate per utilizzare KMS

Per configurare KMS per SageMaker, consulta la sezione Key Management nella documentazione di Amazon SageMaker.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Sagemaker Notebook No Direct Internet Access

Nome della categoria nell'API: SAGEMAKER_NOTEBOOK_NO_DIRECT_INTERNET_ACCESS

Controlla se l'accesso diretto a internet è disabilitato per un'istanza di notebook SageMaker. A questo scopo, controlla se il campo DirectInternetAccess è disabilitato per l'istanza del notebook.

Se configuri l'istanza SageMaker senza un VPC, per impostazione predefinita l'accesso diretto a internet è abilitato sull'istanza. Devi configurare l'istanza con un VPC e modificare l'impostazione predefinita su Disattiva: accedi a internet tramite un VPC.

Per addestrare o ospitare modelli da un blocco note, è necessario l'accesso a internet. Per abilitare l'accesso a internet, assicurati che il VPC abbia un gateway NAT e che il gruppo di sicurezza consenta le connessioni in uscita. Per scoprire di più su come connettere un'istanza notebook alle risorse in un VPC, consulta Connettere un'istanza notebook alle risorse in un VPC nella Guida per gli sviluppatori di Amazon SageMaker.

Devi anche assicurarti che l'accesso alla configurazione di SageMaker sia limitato solo agli utenti autorizzati. Limita le autorizzazioni IAM degli utenti per modificare le impostazioni e le risorse di SageMaker.

Consiglio: controlla se l'accesso diretto a internet è disabilitato per tutte le istanze di notebook Amazon SageMaker

Per risolvere questo problema, completa i seguenti passaggi:

Console AWS

Tieni presente che non puoi modificare l'impostazione di accesso a internet dopo la creazione di un'istanza notebook. Deve essere interrotto, eliminato e ricreato.

Per configurare un'istanza di notebook SageMaker in modo da negare l'accesso diretto a internet:

  1. Apri la console SageMaker all'indirizzo https://console.aws.amazon.com/sagemaker/
  2. Vai a Istanze notebook.
  3. Elimina l'istanza con l'accesso diretto a internet attivato. Scegli l'istanza, seleziona Azioni, quindi Arresta.
  4. Dopo l'arresto dell'istanza, scegli Azioni, poi Elimina.
  5. Scegli Crea istanza di notebook. Fornisci i dettagli di configurazione.
  6. Espandi la sezione di rete, quindi scegli un VPC, una subnet e un gruppo di sicurezza. In Accesso diretto a internet, scegli Disabilita: accedi a internet tramite un VPC.
  7. Scegli Crea istanza di notebook.

Per ulteriori informazioni, consulta Connettere un'istanza notebook alle risorse in un VPC nella Guida per gli sviluppatori di Amazon SageMaker.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Secretsmanager Rotation Enabled Check

Nome della categoria nell'API: SECRETSMANAGER_ROTATION_ENABLED_CHECK

Controlla se un secret archiviato in AWS Secrets Manager è configurato con la rotazione automatica. Il controllo non riesce se il secret non è configurato con la rotazione automatica. Se fornisci un valore personalizzato per il parametro maximumAllowedRotationFrequency, il controllo viene superato solo se il secret viene ruotato automaticamente entro il periodo di tempo specificato.

Secrets Manager ti aiuta a migliorare la security posture della tua organizzazione. I secret includono credenziali del database, password e chiavi API di terze parti. Puoi utilizzare Secrets Manager per archiviare i secret in modo centralizzato, criptarli automaticamente, controllare l'accesso e ruotarli in modo sicuro e automatico.

Secrets Manager può ruotare i secret. Puoi utilizzare la rotazione per sostituire i segreti a lungo termine con quelli a breve termine. La rotazione dei segreti limita il periodo di tempo in cui un utente non autorizzato può utilizzare un segreto compromesso. Per questo motivo, devi ruotare spesso i secret. Per scoprire di più sulla rotazione, consulta la sezione Rotazione dei secret di AWS Secrets Manager nella Guida per l'utente di AWS Secrets Manager.

Consiglio: controlla che la rotazione sia abilitata per tutti i secret di AWS Secrets Manager

Per attivare la rotazione automatica per i secret di Secrets Manager, consulta Configurare la rotazione automatica per i secret di AWS Secrets Manager utilizzando la console nella Guida per l'utente di AWS Secrets Manager. Devi scegliere e configurare una funzione AWS Lambda per la rotazione.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Sns Encrypted Kms

Nome della categoria nell'API: SNS_ENCRYPTED_KMS

Controlla se un argomento SNS è criptato at-rest utilizzando AWS KMS. I controlli non vengono superati se un argomento SNS non utilizza una chiave KMS per la crittografia lato server (SSE).

La crittografia dei dati at-rest riduce il rischio che i dati archiviati su disco vengano accessibili a un utente non autenticato su AWS. Inoltre, aggiunge un altro insieme di controlli di accesso per limitare la capacità degli utenti non autorizzati di accedere ai dati. Ad esempio, sono necessarie autorizzazioni API per decriptare i dati prima che possano essere letti. Gli argomenti SNS devono essere criptati at-rest per un livello di sicurezza aggiuntivo.

Consiglio: controlla che tutti gli argomenti SNS siano criptati con KMS

Per attivare SSE per un argomento SNS, consulta Attivazione della crittografia lato server (SSE) per un argomento Amazon SNS nella Guida per gli sviluppatori di Amazon Simple Notification Service. Prima di poter utilizzare SSE, devi anche configurare le policy delle chiavi AWS KMS per consentire la crittografia degli argomenti e la crittografia e la decrittografia dei messaggi. Per ulteriori informazioni, consulta Configurazione delle autorizzazioni AWS KMS nella Guida per gli sviluppatori di Amazon Simple Notification Service.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Vpc Default Security Group Closed

Nome della categoria nell'API: VPC_DEFAULT_SECURITY_GROUP_CLOSED

Questo controllo verifica se il gruppo di sicurezza predefinito di un VPC consente il traffico in entrata o in uscita. Il controllo non riesce se il gruppo di sicurezza consente il traffico in entrata o in uscita.

Le regole per il gruppo di sicurezza predefinito consentono tutto il traffico in uscita e in entrata dalle interfacce di rete (e dalle relative istanze) assegnate allo stesso gruppo di sicurezza. Ti consigliamo di non utilizzare il gruppo di sicurezza predefinito. Poiché il gruppo di sicurezza predefinito non può essere eliminato, devi modificare l'impostazione delle regole del gruppo di sicurezza predefinito per limitare il traffico in entrata e in uscita. In questo modo si impedisce il traffico non intenzionale se il gruppo di sicurezza predefinito viene configurato accidentalmente per risorse come le istanze EC2.

Consiglio: assicurati che il gruppo di sicurezza predefinito di ogni VPC limiti tutto il traffico

Per risolvere il problema, inizia creando nuovi gruppi di sicurezza con privilegi minimi. Per istruzioni, consulta la sezione Creare un gruppo di sicurezza nella Guida per l'utente di Amazon VPC. Poi, assegna i nuovi gruppi di sicurezza alle tue istanze EC2. Per istruzioni, consulta Modificare il gruppo di sicurezza di un'istanza nella Guida per l'utente di Amazon EC2 per le istanze Linux.

Dopo aver assegnato i nuovi gruppi di sicurezza alle risorse, rimuovi tutte le regole in entrata e in uscita dai gruppi di sicurezza predefiniti. Per istruzioni, consulta Eliminare le regole del gruppo di sicurezza nella Guida per l'utente di Amazon VPC.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Vpc Flow Logging Enabled All Vpcs

Nome della categoria nell'API: VPC_FLOW_LOGGING_ENABLED_ALL_VPCS

I log di flusso VPC sono una funzionalità che consente di acquisire informazioni sul traffico IP da e verso le interfacce di rete nel VPC. Dopo aver creato un log di flusso, puoi visualizzarne e recuperarne i dati in Amazon CloudWatch Logs. È consigliabile abilitare i log di flusso VPC per i pacchetti "Rifiuti" per i VPC.

Consiglio: assicurati che il logging dei flussi VPC sia abilitato in tutti i VPC

Per risolvere questo problema, completa i seguenti passaggi:

Console AWS

  1. Accedi alla console di gestione
  2. Seleziona Services e poi VPC
  3. Nel riquadro di navigazione a sinistra, seleziona Your VPCs
  4. Seleziona un VPC
  5. Nel riquadro a destra, seleziona la scheda Flow Logs.
  6. Se non esiste alcun log di flusso, fai clic su Create Flow Log.
  7. In Filtro, seleziona Reject.
  8. Inserisci un Role e un Destination Log Group
  9. Fai clic su Create Log Flow.
  10. Fai clic su CloudWatch Logs Group.

Nota:se imposti il filtro su "Rifiuta", l'accumulo di dati di logging per questo consiglio verrà ridotto drasticamente e verranno fornite informazioni sufficienti ai fini del rilevamento, della ricerca e della correzione delle violazioni. Tuttavia, durante i periodi di progettazione del gruppo di sicurezza con privilegio minimo, l'impostazione di questo filtro su "Tutti" può essere molto utile per scoprire i flussi di traffico esistenti necessari per il corretto funzionamento di un ambiente già in esecuzione.

Interfaccia a riga di comando AWS

  1. Crea un documento di policy, chiamalo role_policy_document.json e incolla i seguenti contenuti:
{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Sid": "test",
 "Effect": "Allow",
 "Principal": {
 "Service": "ec2.amazonaws.com"
 },
 "Action": "sts:AssumeRole"
 }
 ]
}
  1. Crea un altro documento delle norme, chiamalo iam_policy.json e incolla i seguenti contenuti:
{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Effect": "Allow",
 "Action":[
 "logs:CreateLogGroup",
 "logs:CreateLogStream",
 "logs:DescribeLogGroups",
 "logs:DescribeLogStreams",
 "logs:PutLogEvents",
 "logs:GetLogEvents",
 "logs:FilterLogEvents"
 ],
 "Resource": "*"
 }
 ]
}
  1. Esegui il comando seguente per creare un ruolo IAM:
aws iam create-role --role-name <aws_support_iam_role> --assume-role-policy-document file://<file-path>role_policy_document.json
  1. Esegui il comando seguente per creare una policy IAM:
aws iam create-policy --policy-name <ami-policy-name> --policy-document file://<file-path>iam-policy.json
  1. Esegui il comando attach-group-policy utilizzando l'ARN della policy IAM restituita nel passaggio precedente per collegare la policy al ruolo IAM (se il comando ha esito positivo, non viene restituito alcun output):
aws iam attach-group-policy --policy-arn arn:aws:iam::<aws-account-id>:policy/<iam-policy-name> --group-name <group-name>
  1. Esegui describe-vpcs per ottenere l'ID VPC disponibile nella regione selezionata:
aws ec2 describe-vpcs --region <region>
  1. L'output del comando deve restituire l'ID VPC disponibile nella regione selezionata.
  2. Esegui create-flow-logs per creare un log di flusso per il VPC:
aws ec2 create-flow-logs --resource-type VPC --resource-ids <vpc-id> --traffic-type REJECT --log-group-name <log-group-name> --deliver-logs-permission-arn <iam-role-arn>
  1. Ripeti il passaggio 8 per gli altri VPC disponibili nella regione selezionata.
  2. Modifica la regione aggiornando --region e ripeti la procedura di correzione per gli altri VPC.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Vpc Sg Open Only To Authorized Ports

Nome della categoria nell'API: VPC_SG_OPEN_ONLY_TO_AUTHORIZED_PORTS

Questo controllo verifica se un gruppo di sicurezza Amazon EC2 consente il traffico in entrata senza restrizioni da porte non autorizzate. Lo stato del controllo viene determinato come segue:

Se utilizzi il valore predefinito per authorizedTcpPorts, il controllo non riesce se il gruppo di sicurezza consente il traffico in entrata senza restrizioni da qualsiasi porta diversa dalle porte 80 e 443.

Se fornisci valori personalizzati per authorizedTcpPorts o authorizedUdpPorts, il controllo non riesce se il gruppo di sicurezza consente il traffico in entrata senza restrizioni da qualsiasi porta non elencata.

Se non viene utilizzato alcun parametro, il controllo non riesce per qualsiasi gruppo di sicurezza che abbia una regola di traffico in entrata senza restrizioni.

I gruppi di sicurezza forniscono un filtro stateful del traffico di rete in entrata e in uscita verso AWS. Le regole del gruppo di sicurezza devono seguire il principio dell'accesso con privilegi minimi. L'accesso senza restrizioni (indirizzo IP con suffisso /0) aumenta le opportunità di attività dannose come hacking, attacchi denial of service e perdita di dati. A meno che una porta non sia specificamente consentita, l'accesso illimitato deve essere negato.

Consiglio: controlla che tutti i gruppi di sicurezza con 0.0.0.0/0 di qualsiasi VPC consentano solo traffico TCP/UDP in entrata specifico

Per modificare un gruppo di sicurezza, consulta Utilizzare i gruppi di sicurezza nella Guida per l'utente di Amazon VPC.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.

Both VPC VPN Tunnels Up

Nome della categoria nell'API: VPC_VPN_2_TUNNELS_UP

Un tunnel VPN è un collegamento criptato in cui i dati possono passare dalla rete del cliente ad AWS o da AWS nell'ambito di una connessione VPN AWS Site-to-Site. Ogni connessione VPN include due tunnel VPN che puoi utilizzare contemporaneamente per l'alta disponibilità. Assicurarsi che entrambi i tunnel VPN siano attivi per una connessione VPN è importante per confermare una connessione sicura e ad alta disponibilità tra un VPC AWS e la tua rete remota.

Questo controllo verifica che entrambi i tunnel VPN forniti da AWS Site-to-Site VPN siano in stato attivo. Il controllo non viene superato se uno o entrambi i tunnel sono nello stato DOWN.

Consiglio: controlla che entrambi i tunnel VPN forniti da AWS tra siti siano in stato attivo

Per modificare le opzioni del tunnel VPN, consulta Modifica delle opzioni del tunnel VPN Site-to-Site nella Guida per l'utente di AWS Site-to-Site VPN.

Scopri di più su questo tipo di risultato, sulle risorse supportate e sulle impostazioni di scansione.