Raccomandazioni sulla sicurezza per le risorse DevOps
Questo articolo elenca i suggerimenti visualizzati in Microsoft Defender per il cloud se si connette un ambiente Azure DevOps, GitHub o GitLab usando la pagina Impostazioni ambiente. Le raccomandazioni visualizzate nell'ambiente sono basate sulle risorse protette e sulla configurazione personalizzata.
Per informazioni sulle azioni che è possibile eseguire in risposta a queste raccomandazioni, vedere Correggere le raccomandazioni in Defender per il cloud.
Altre informazioni sui vantaggi e sulle funzionalità di sicurezza di DevOps.
Le raccomandazioni di DevOps non influiscono sul punteggio di sicurezza. Per decidere quali raccomandazioni risolvere prima, esaminare la gravità di ogni raccomandazione e il potenziale impatto sul punteggio di sicurezza.
Raccomandazioni di Azure DevOps
Per i repository Di Azure DevOps deve essere abilitata la sicurezza avanzata di GitHub per Azure DevOps (GHAzDO)
Descrizione: La sicurezza devOps in Defender per il cloud usa una console centrale per consentire ai team di sicurezza di proteggere le applicazioni e le risorse dal codice al cloud in Azure DevOps. Con l'abilitazione di repository GitHub Advanced Security for Azure DevOps (GHAzDO), tra cui GitHub Advanced Security per Azure DevOps, si ottengono risultati relativi a segreti, dipendenze e vulnerabilità del codice nei repository di Azure DevOps visualizzati in Microsoft Defender per il cloud.
Gravità: alta
I repository Di Azure DevOps devono avere i risultati dell'analisi dei segreti risolti
Descrizione: i segreti sono stati trovati nei repository di codice. Correggere immediatamente per evitare una violazione della sicurezza. I segreti trovati nei repository possono trapelare o essere individuati da avversari, causando la compromissione di un'applicazione o di un servizio. Lo strumento di analisi delle credenziali di Microsoft Security DevOps analizza solo le build su cui è configurato per l'esecuzione. Pertanto, i risultati potrebbero non riflettere lo stato completo dei segreti nei repository.
Gravità: alta
I repository DevOps di Azure devono avere i risultati di analisi del codice risolti
Descrizione: le vulnerabilità sono state trovate nei repository di codice. Per migliorare il comportamento di sicurezza dei repository, è consigliabile correggere queste vulnerabilità.
Gravità: medio
I repository Di Azure DevOps devono avere i risultati dell'analisi delle vulnerabilità delle dipendenze risolti
Descrizione: vulnerabilità delle dipendenze rilevate nei repository di codice. Per migliorare il comportamento di sicurezza dei repository, è consigliabile correggere queste vulnerabilità.
Gravità: medio
I repository DevOps di Azure devono avere un'infrastruttura perché i risultati dell'analisi del codice risolti
Descrizione: problemi di configurazione della sicurezza dell'infrastruttura come codice rilevati nei repository. I problemi sono stati rilevati nei file modello. Per migliorare il comportamento di sicurezza delle risorse cloud correlate, è consigliabile risolvere questi problemi.
Gravità: medio
Le pipeline di Azure DevOps non devono avere segreti disponibili per le compilazioni di fork
Descrizione: nei repository pubblici è possibile che gli utenti esterni all'organizzazione creino fork ed eseguano compilazioni nel repository con fork. In questo caso, se questa impostazione è abilitata, gli esterni possono accedere ai segreti della pipeline di compilazione che devono essere interni.
Gravità: alta
Le connessioni al servizio Azure DevOps non devono concedere l'accesso a tutte le pipeline
Descrizione: le connessioni al servizio vengono usate per creare connessioni da Azure Pipelines a servizi esterni e remoti per l'esecuzione di attività in un processo. Le autorizzazioni della pipeline controllano quali pipeline sono autorizzate a usare la connessione al servizio. Per supportare la sicurezza delle operazioni della pipeline, alle connessioni del servizio non deve essere concesso l'accesso a tutte le pipeline YAML. Ciò consente di mantenere il principio dei privilegi minimi perché una vulnerabilità nei componenti usati da una pipeline può essere usata da un utente malintenzionato per attaccare altre pipeline con accesso alle risorse critiche.
Gravità: alta
I file protetti di Azure DevOps non devono concedere l'accesso a tutte le pipeline
Descrizione: i file protetti offrono agli sviluppatori un modo per archiviare i file che possono essere condivisi tra le pipeline. Questi file vengono in genere usati per archiviare segreti, ad esempio certificati di firma e chiavi SSH. Se a un file sicuro viene concesso l'accesso a tutte le pipeline YAML, un utente non autorizzato può rubare informazioni dai file protetti creando una pipeline YAML e accedendo al file sicuro.
Gravità: alta
I gruppi di variabili di Azure DevOps con variabili segrete non devono concedere l'accesso a tutte le pipeline
Descrizione: i gruppi di variabili archiviano i valori e i segreti che è possibile passare a una pipeline YAML o rendere disponibili in più pipeline. È possibile condividere e usare gruppi di variabili in più pipeline nello stesso progetto. Se un gruppo di variabili contenente segreti è contrassegnato come accessibile a tutte le pipeline YAML, un utente malintenzionato può sfruttare gli asset che coinvolgono le variabili segrete creando una nuova pipeline.
Gravità: alta
Le connessioni al servizio di Azure classico di Azure DevOps non devono essere usate per accedere a una sottoscrizione
Descrizione: usare il tipo di connessioni al servizio di Azure Resource Manager (ARM) anziché le connessioni al servizio classico di Azure per connettersi alle sottoscrizioni di Azure. Il modello arm offre più miglioramenti alla sicurezza, tra cui un controllo di accesso più forte, un controllo migliorato, una distribuzione/governance basata su ARM, l'accesso alle identità gestite e all'insieme di credenziali delle chiavi per i segreti, l'autenticazione basata su Entra Permissions e il supporto per tag e gruppi di risorse per una gestione semplificata.
Gravità: medio
(Anteprima) I repository Di Azure DevOps devono avere i risultati dei test di sicurezza dell'API risolti
Descrizione: vulnerabilità di sicurezza api rilevate nei repository di codice. Per migliorare il comportamento di sicurezza dei repository, è consigliabile correggere queste vulnerabilità.
Gravità: medio
(Anteprima) I repository DevOps di Azure devono richiedere l'approvazione minima di due revisori per i push di codice
Descrizione: per impedire il commit diretto di modifiche indesiderate o dannose, è importante implementare i criteri di protezione per il ramo predefinito nei repository Di Azure DevOps. È consigliabile richiedere almeno due revisori del codice per approvare le richieste pull prima che il codice venga unito al ramo predefinito. Richiedendo l'approvazione da un numero minimo di due revisori, è possibile ridurre il rischio di modifiche non autorizzate, che potrebbero causare instabilità del sistema o vulnerabilità di sicurezza.
Questa raccomandazione viene fornita in Defender per il cloud comportamento di sicurezza di base, se Azure DevOps è stato connesso a Defender per il cloud.
Gravità: alta
(Anteprima) I repository Di Azure DevOps non devono consentire ai richiedenti di approvare le proprie richieste pull
Descrizione: per impedire il commit diretto di modifiche indesiderate o dannose, è importante implementare i criteri di protezione per il ramo predefinito nei repository Di Azure DevOps. È consigliabile impedire agli autori di richieste pull di approvare i propri invii per garantire che ogni modifica subisca una revisione obiettivo da parte di un utente diverso dall'autore. In questo modo, è possibile ridurre il rischio di modifiche non autorizzate, che potrebbero causare instabilità del sistema o vulnerabilità di sicurezza.
Questa raccomandazione viene fornita in Defender per il cloud comportamento di sicurezza di base, se Azure DevOps è stato connesso a Defender per il cloud.
Gravità: alta
(Anteprima) I progetti Azure DevOps devono avere disabilitato la creazione di pipeline classiche
Descrizione: la disabilitazione della creazione di pipeline di compilazione e versione classica impedisce un problema di sicurezza che deriva da YAML e pipeline classiche che condividono le stesse risorse, ad esempio le stesse connessioni al servizio. I potenziali utenti malintenzionati possono sfruttare le pipeline classiche per creare processi che evase i meccanismi di difesa tipici configurati per le pipeline YAML moderne.
Gravità: alta
Raccomandazioni su GitHub
Le organizzazioni GitHub non devono rendere accessibili i segreti delle azioni a tutti i repository
Descrizione: per i segreti usati nei flussi di lavoro di GitHub Action archiviati a livello di organizzazione di GitHub, è possibile usare i criteri di accesso per controllare quali repository possono usare i segreti dell'organizzazione. I segreti a livello di organizzazione consentono di condividere segreti tra più repository. In questo modo si riduce la necessità di creare segreti duplicati. Tuttavia, una volta reso accessibile un segreto a un repository, chiunque abbia accesso in scrittura nel repository può accedere al segreto da qualsiasi ramo in un flusso di lavoro. Per ridurre la superficie di attacco, assicurarsi che il segreto sia accessibile solo dai repository selezionati.
Questa raccomandazione viene fornita in Defender per il cloud comportamento di sicurezza di base, se Azure DevOps è stato connesso a Defender per il cloud.
Gravità: alta
Nei repository GitHub deve essere abilitata l'analisi dei segreti
Descrizione: GitHub analizza i repository per i tipi noti di segreti, per evitare l'uso fraudolento dei segreti di cui è stato accidentalmente eseguito il commit nei repository. L'analisi dei segreti analizzerà l'intera cronologia Git in tutti i rami presenti nel repository GitHub per individuare eventuali segreti. Esempi di segreti sono token e chiavi private che un provider di servizi può emettere per l'autenticazione. Se un segreto viene archiviato in un repository, chiunque abbia accesso in lettura al repository può usare il segreto per accedere al servizio esterno con tali privilegi. I segreti devono essere archiviati in una posizione sicura dedicata all'esterno del repository per il progetto.
Gravità: alta
Nei repository GitHub deve essere abilitata l'analisi del codice
Descrizione: GitHub usa l'analisi del codice per analizzare il codice per trovare vulnerabilità ed errori di sicurezza nel codice. L'analisi del codice può essere usata per trovare, valutare e classificare in ordine di priorità le correzioni per i problemi esistenti nel codice. L'analisi del codice può anche impedire agli sviluppatori di introdurre nuovi problemi. Le analisi possono essere pianificate per giorni e ore specifiche oppure le analisi possono essere attivate quando si verifica un evento specifico nel repository, ad esempio un push. Se l'analisi del codice rileva una potenziale vulnerabilità o un errore nel codice, GitHub visualizza un avviso nel repository. Una vulnerabilità è un problema nel codice di un progetto che potrebbe essere sfruttato per danneggiare la riservatezza, l'integrità o la disponibilità del progetto.
Gravità: medio
Per i repository GitHub deve essere abilitata l'analisi Dependabot
Descrizione: GitHub invia avvisi Dependabot quando rileva le vulnerabilità nelle dipendenze del codice che interessano i repository. Una vulnerabilità è un problema nel codice di un progetto che potrebbe essere sfruttato per danneggiare la riservatezza, l'integrità o la disponibilità del progetto o di altri progetti che usano il codice. Le vulnerabilità variano in base al tipo, alla gravità e al metodo di attacco. Quando il codice dipende da un pacchetto che presenta una vulnerabilità di sicurezza, questa dipendenza vulnerabile può causare una serie di problemi.
Gravità: medio
I repository GitHub devono avere i risultati dell'analisi dei segreti risolti
Descrizione: segreti trovati nei repository di codice. Questa operazione deve essere risolta immediatamente per evitare una violazione della sicurezza. I segreti trovati nei repository possono essere persi o individuati da avversari, causando la compromissione di un'applicazione o di un servizio.
Gravità: alta
I repository GitHub devono avere i risultati di analisi del codice risolti
Descrizione: vulnerabilità trovate nei repository di codice. Per migliorare il comportamento di sicurezza dei repository, è consigliabile correggere queste vulnerabilità.
Gravità: medio
I repository GitHub devono avere i risultati dell'analisi delle vulnerabilità delle dipendenze risolti
Descrizione: i repository GitHub devono avere i risultati dell'analisi delle vulnerabilità delle dipendenze risolti.
Gravità: medio
I repository GitHub devono avere un'infrastruttura perché i risultati dell'analisi del codice risolti
Descrizione: sono stati rilevati problemi di configurazione dell'infrastruttura come codice nei repository. I problemi sono stati rilevati nei file modello. Per migliorare il comportamento di sicurezza delle risorse cloud correlate, è consigliabile risolvere questi problemi.
Gravità: medio
I repository GitHub devono avere criteri di protezione per il ramo predefinito abilitato
Descrizione: il ramo predefinito del repository deve essere protetto tramite i criteri di protezione dei rami per impedire il commit diretto di modifiche indesiderate/dannose nel repository.
Gravità: alta
I repository GitHub devono avere forzare i push nel ramo predefinito disabilitato
Descrizione: poiché il ramo predefinito viene in genere usato per la distribuzione e altre attività con privilegi, le modifiche apportate devono essere affrontate con cautela. L'abilitazione delle operazioni di forza push può introdurre modifiche indesiderate o dannose al ramo predefinito.
Gravità: medio
Le organizzazioni GitHub devono avere la protezione push di analisi dei segreti abilitata
Descrizione: Protezione push blocca i commit che contengono segreti impedendo così l'esposizione accidentale dei segreti. Per evitare il rischio di esposizione delle credenziali, protezione push deve essere abilitata automaticamente per ogni repository abilitato per l'analisi dei segreti.
Gravità: alta
I repository GitHub non devono usare strumenti di esecuzione self-hosted
Descrizione: gli strumenti di esecuzione self-hosted in GitHub non dispongono di garanzie di funzionamento nelle macchine virtuali temporanee e possono essere compromessi in modo permanente da codice non attendibile in un flusso di lavoro. Di conseguenza, gli strumenti di esecuzione self-hosted non devono essere usati per i flussi di lavoro delle azioni.
Gravità: alta
Le organizzazioni GitHub devono disporre delle autorizzazioni del flusso di lavoro azioni impostate su sola lettura
Descrizione: per impostazione predefinita, ai flussi di lavoro di azione devono essere concesse autorizzazioni di sola lettura per impedire agli utenti malintenzionati di sfruttare flussi di lavoro con autorizzazioni eccessiva per accedere e manomettere le risorse.
Gravità: alta
Le organizzazioni GitHub devono avere più di una persona con autorizzazioni di amministratore
Descrizione: avere almeno due amministratori riduce il rischio di perdere l'accesso amministratore. Ciò è utile in caso di scenari di account break-glass.
Gravità: alta
Le organizzazioni GitHub devono avere autorizzazioni di base impostate su nessuna autorizzazione o lettura
Descrizione: le autorizzazioni di base devono essere impostate su nessuna o leggono affinché un'organizzazione segua il principio dei privilegi minimi e impedisca l'accesso non necessario.
Gravità: alta
(Anteprima) I repository GitHub devono avere i risultati dei test di sicurezza delle API risolti
Descrizione: le vulnerabilità di sicurezza delle API sono state trovate nei repository di codice. Per migliorare il comportamento di sicurezza dei repository, è consigliabile correggere queste vulnerabilità.
Gravità: medio
(Anteprima) Le organizzazioni GitHub non devono rendere accessibili i segreti delle azioni a tutti i repository
Descrizione: per i segreti usati nei flussi di lavoro di GitHub Action archiviati a livello di organizzazione GitHub, è possibile usare i criteri di accesso per controllare quali repository possono usare i segreti dell'organizzazione. I segreti a livello di organizzazione consentono di condividere segreti tra più repository, riducendo la necessità di creare segreti duplicati. Tuttavia, quando un segreto viene reso accessibile a un repository, chiunque abbia accesso in scrittura nel repository può accedere al segreto da qualsiasi ramo in un flusso di lavoro. Per ridurre la superficie di attacco, assicurarsi che il segreto sia accessibile solo dai repository selezionati.
Gravità: alta
(Anteprima) Le organizzazioni di GitHub devono bloccare i suggerimenti copilot che corrispondono al codice pubblico
Descrizione: l'abilitazione del filtro di GitHub Copilot per bloccare i suggerimenti di codice corrispondenti al codice pubblico in GitHub migliora la sicurezza e la conformità legale. Impedisce l'incorporazione involontaria di codice pubblico o open source, riducendo il rischio di problemi legali e garantendo la conformità alle condizioni di licenza. Inoltre, consente di evitare di introdurre potenziali vulnerabilità dal codice pubblico nei progetti dell'organizzazione, mantenendo così una maggiore qualità e sicurezza del codice. Quando il filtro è abilitato, GitHub Copilot controlla i suggerimenti di codice con il codice circostante di circa 150 caratteri rispetto al codice pubblico in GitHub. Se è presente una corrispondenza o una corrispondenza vicina, il suggerimento non verrà visualizzato.
Gravità: alta
(Anteprima) Le organizzazioni GitHub devono applicare l'autenticazione a più fattori per i collaboratori esterni
Descrizione: l'applicazione dell'autenticazione a più fattori per i collaboratori esterni in un'organizzazione GitHub è una misura di sicurezza che richiede ai collaboratori di usare una forma aggiuntiva di identificazione oltre alla password per accedere ai repository e alle risorse dell'organizzazione. Ciò migliora la sicurezza proteggendo dall'accesso non autorizzato, anche se una password viene compromessa e contribuisce a garantire la conformità agli standard del settore. Implica l'informazione dei collaboratori sul requisito e il supporto per la transizione, riducendo infine il rischio di violazioni dei dati.
Gravità: alta
(Anteprima) I repository GitHub devono richiedere l'approvazione minima di due revisori per i push di codice
Descrizione: per impedire il commit diretto di modifiche indesiderate o dannose, è importante implementare i criteri di protezione per il ramo predefinito nei repository GitHub. È consigliabile richiedere almeno due revisori del codice per approvare le richieste pull prima che il codice venga unito al ramo predefinito. Richiedendo l'approvazione da un numero minimo di due revisori, è possibile ridurre il rischio di modifiche non autorizzate, che potrebbero causare instabilità del sistema o vulnerabilità di sicurezza.
Gravità: alta
Raccomandazioni su GitLab
I progetti GitLab devono avere i risultati dell'analisi dei segreti risolti
Descrizione: i segreti sono stati trovati nei repository di codice. Questa operazione deve essere risolta immediatamente per evitare una violazione della sicurezza. I segreti trovati nei repository possono essere persi o individuati da avversari, causando la compromissione di un'applicazione o di un servizio.
Gravità: alta
I progetti GitLab devono avere i risultati di analisi del codice risolti
Descrizione: le vulnerabilità sono state trovate nei repository di codice. Per migliorare il comportamento di sicurezza dei repository, è consigliabile correggere queste vulnerabilità.
Gravità: medio
I progetti GitLab devono avere i risultati dell'analisi delle vulnerabilità delle dipendenze risolti
Descrizione: i repository GitHub devono avere i risultati dell'analisi delle vulnerabilità delle dipendenze risolti.
Gravità: medio
I progetti GitLab devono avere un'infrastruttura perché i risultati dell'analisi del codice risolti
Descrizione: sono stati rilevati problemi di configurazione dell'infrastruttura come codice nei repository. I problemi mostrati sono stati rilevati nei file modello. Per migliorare il comportamento di sicurezza delle risorse cloud correlate, è consigliabile risolvere questi problemi.
Gravità: medio
Raccomandazioni sulla sicurezza di DevOps deprecate
I repository di codice devono avere i risultati di analisi del codice risolti
Descrizione: la sicurezza devOps in Defender per il cloud ha rilevato vulnerabilità nei repository di codice. Per migliorare il comportamento di sicurezza dei repository, è consigliabile correggere queste vulnerabilità. (Nessun criterio correlato)
Gravità: medio
I repository di codice devono avere i risultati dell'analisi dei segreti risolti
Descrizione: la sicurezza devOps in Defender per il cloud ha trovato un segreto nei repository di codice. Questa operazione deve essere risolta immediatamente per evitare una violazione della sicurezza. I segreti trovati nei repository possono essere persi o individuati da avversari, causando la compromissione di un'applicazione o di un servizio. Per Azure DevOps, lo strumento Microsoft Security DevOps CredScan analizza solo le build su cui è stato configurato per l'esecuzione. Pertanto, i risultati potrebbero non riflettere lo stato completo dei segreti nei repository. (Nessun criterio correlato)
Gravità: alta
I repository di codice devono avere i risultati di analisi Dependabot risolti
Descrizione: la sicurezza devOps in Defender per il cloud ha rilevato vulnerabilità nei repository di codice. Per migliorare il comportamento di sicurezza dei repository, è consigliabile correggere queste vulnerabilità. (Nessun criterio correlato)
Gravità: medio
I repository di codice devono avere un'infrastruttura perché i risultati dell'analisi del codice sono stati risolti
Descrizione: la sicurezza devOps in Defender per il cloud ha rilevato un'infrastruttura come problemi di configurazione della sicurezza del codice nei repository. I problemi mostrati sono stati rilevati nei file modello. Per migliorare il comportamento di sicurezza delle risorse cloud correlate, è consigliabile risolvere questi problemi. (Nessun criterio correlato)
Gravità: medio
Nei repository GitHub deve essere abilitata l'analisi del codice
Descrizione: GitHub usa l'analisi del codice per analizzare il codice per trovare vulnerabilità ed errori di sicurezza nel codice. L'analisi del codice può essere usata per trovare, valutare e classificare in ordine di priorità le correzioni per i problemi esistenti nel codice. L'analisi del codice può anche impedire agli sviluppatori di introdurre nuovi problemi. Le analisi possono essere pianificate per giorni e ore specifiche oppure le analisi possono essere attivate quando si verifica un evento specifico nel repository, ad esempio un push. Se l'analisi del codice rileva una potenziale vulnerabilità o un errore nel codice, GitHub visualizza un avviso nel repository. Una vulnerabilità è un problema nel codice di un progetto che potrebbe essere sfruttato per danneggiare la riservatezza, l'integrità o la disponibilità del progetto. (Nessun criterio correlato)
Gravità: medio
Nei repository GitHub deve essere abilitata l'analisi dei segreti
Descrizione: GitHub analizza i repository per i tipi noti di segreti, per evitare l'uso fraudolento dei segreti di cui è stato accidentalmente eseguito il commit nei repository. L'analisi dei segreti analizzerà l'intera cronologia Git in tutti i rami presenti nel repository GitHub per individuare eventuali segreti. Esempi di segreti sono token e chiavi private che un provider di servizi può emettere per l'autenticazione. Se un segreto viene archiviato in un repository, chiunque abbia accesso in lettura al repository può usare il segreto per accedere al servizio esterno con tali privilegi. I segreti devono essere archiviati in una posizione sicura dedicata all'esterno del repository per il progetto. (Nessun criterio correlato)
Gravità: alta
Per i repository GitHub deve essere abilitata l'analisi Dependabot
Descrizione: GitHub invia avvisi Dependabot quando rileva le vulnerabilità nelle dipendenze del codice che interessano i repository. Una vulnerabilità è un problema nel codice di un progetto che potrebbe essere sfruttato per danneggiare la riservatezza, l'integrità o la disponibilità del progetto o di altri progetti che usano il codice. Le vulnerabilità variano in base al tipo, alla gravità e al metodo di attacco. Quando il codice dipende da un pacchetto che presenta una vulnerabilità di sicurezza, questa dipendenza vulnerabile può causare una serie di problemi. (Nessun criterio correlato)
Gravità: medio