Analisi dei segreti

Le credenziali esposte nei sistemi di progettazione offrono opportunità facilmente sfruttabili per gli utenti malintenzionati. Per difendersi da questa minaccia, GitHub Advanced Security per Azure DevOps analizza le credenziali e altri contenuti sensibili nel codice sorgente. La protezione push impedisce anche la perdita di credenziali al primo posto.

L'analisi dei segreti per il repository esegue l'analisi di eventuali segreti già esistenti nel codice sorgente nella cronologia e la protezione push impedisce l'esposizione di nuovi segreti nel codice sorgente.

GitHub Advanced Security per Azure DevOps funziona con Azure Repos. Per usare GitHub Advanced Security con i repository GitHub, vedere GitHub Advanced Security.

Informazioni sugli avvisi di analisi dei segreti

Quando la sicurezza avanzata è abilitata, analizza i repository per individuare i segreti emessi da un'ampia gamma di provider di servizi e genera avvisi di analisi dei segreti.

Se l'accesso a una risorsa richiede credenziali abbinate, l'analisi dei segreti può creare un avviso solo quando entrambe le parti della coppia vengono rilevate nello stesso file. L'associazione garantisce che le perdite più critiche non siano nascoste dietro informazioni sulle perdite parziali. La corrispondenza delle coppie consente anche di ridurre i falsi positivi perché entrambi gli elementi di una coppia devono essere usati insieme per accedere alla risorsa del provider.

La scheda Sicurezza avanzata in Repos>Advanced Security in Azure DevOps è l'hub per visualizzare gli avvisi di sicurezza. Selezionare la scheda Segreti per visualizzare gli avvisi di analisi dei segreti. È possibile filtrare in base allo stato e al tipo di segreto. È possibile passare a un avviso per altri dettagli, incluse le indicazioni sulla correzione. Dopo l'abilitazione della sicurezza avanzata, viene avviata un'analisi per il repository selezionato, inclusi tutti i commit cronologici. Nel corso del tempo, gli avvisi inizieranno a essere visualizzati man mano che l'analisi avanza.

Non c'è alcun impatto sui risultati se i rami vengono rinominati. Potrebbero essere necessarie fino a 24 ore prima che venga visualizzato il nuovo nome.

Per correggere i segreti esposti, invalidare le credenziali esposte e crearne una nuova. Il segreto appena creato deve quindi essere archiviato in modo sicuro in modo da non eseguirne direttamente il push nel codice. Ad esempio, il segreto può essere archiviato in Azure Key Vault. La maggior parte delle risorse dispone di credenziali primarie e secondarie. Il metodo per eseguire il rollover di credenziali primarie rispetto a una credenziale secondaria è identico, a meno che non diversamente specificato.

Gestire gli avvisi di analisi dei segreti

Visualizzazione degli avvisi per un repository

Chiunque disponga delle autorizzazioni di collaboratore per un repository può visualizzare un riepilogo di tutti gli avvisi per un repository nella scheda Sicurezza avanzata in Repository. Selezionare la scheda Segreti per visualizzare tutti gli avvisi di analisi dei segreti.

Se La sicurezza avanzata è stata abilitata di recente per il repository, è possibile che venga visualizzata una scheda che indica che la sicurezza avanzata sta ancora analizzando il repository.

Una volta completata l'analisi, vengono visualizzati tutti i risultati. Viene generato un singolo avviso per ogni credenziale univoca rilevata, in tutti i rami e la cronologia del repository. Non sono presenti filtri di ramo perché vengono distribuiti in un unico avviso.

I segreti non provider sono visualizzabili selezionando "Altro" nell'elenco a discesa attendibilità nella scheda analisi dei segreti.

Dettagli dell'avviso

Quando si passa a un avviso, viene visualizzata una visualizzazione di avviso dettagliata e vengono visualizzati altri dettagli sulla ricerca e vengono fornite indicazioni specifiche per la correzione per risolvere l'avviso.

Sezione	Spiegazione
Ufficio	La sezione Percorsi descrive in dettaglio i percorsi in cui l'analisi dei segreti ha individuato le credenziali perse. Potrebbero essere presenti più posizioni o più commit nella cronologia che contengono le credenziali perse. Tutti questi percorsi e commit vengono visualizzati in Percorsi con un collegamento diretto al frammento di codice e ne è stato identificato il commit.
Elemento consigliato	La sezione delle raccomandazioni contiene linee guida per la correzione o collegamento a linee guida per la correzione della documentazione di terze parti per le credenziali identificate.
Chiudi notifica di avviso	Non esiste alcun comportamento di correzione automatica per gli avvisi di analisi dei segreti. Tutti gli avvisi di analisi dei segreti devono essere attestati manualmente come corretti tramite la pagina dei dettagli dell'avviso. Selezionare il pulsante Chiudi per verificare che il segreto sia revocato.
Gravità	Tutti gli avvisi di analisi dei segreti vengono impostati come critici. Qualsiasi credenziale esposta è potenzialmente un'opportunità per un attore malintenzionato.
Ricerca dei dettagli	Il tipo di credenziale e la regola usati per trovare le credenziali sono elencati nella barra laterale della pagina dei dettagli dell'avviso.

Con i segreti non provider, il tag Confidenza: l'altro tag viene visualizzato anche dalla notifica di gravità nella visualizzazione dei dettagli dell'avviso.

Correzione degli avvisi di analisi dei segreti

Ogni segreto ha passaggi di correzione univoci per guidare l'utente attraverso come revocare e rigenerare un nuovo segreto al suo posto. I dettagli dell'avviso condividono passaggi o documentazione specifici per ogni avviso.

Un avviso di analisi dei segreti rimane aperto fino a quando non viene chiuso. Per attestare che è stato risolto un avviso di analisi dei segreti:

1. Passare all'avviso che si vuole chiudere e selezionare l'avviso.
2. Selezionare l'elenco a discesa Chiudi avviso .
3. Se non è già selezionata, selezionare Correzione.
4. Selezionare Chiudi per inviare e chiudere l'avviso.

Ignorare gli avvisi di analisi dei segreti

Per ignorare gli avvisi in Sicurezza avanzata, sono necessarie le autorizzazioni appropriate. Per impostazione predefinita, solo gli amministratori del progetto possono ignorare gli avvisi di sicurezza avanzata. Per altre informazioni sulle autorizzazioni di sicurezza avanzata, vedere Gestire le autorizzazioni di sicurezza avanzata.

Per ignorare un avviso:

1. Passare all'avviso da chiudere e selezionare l'avviso.
2. Selezionare l'elenco a discesa Chiudi avviso .
3. Se non è già selezionata, selezionare Rischio accettato o Falso positivo come motivo di chiusura.
4. Aggiungere un commento facoltativo nella casella di testo Commento .
5. Selezionare Chiudi per inviare e chiudere l'avviso.
6. Lo stato dell'avviso passa da Apri a Chiuso e visualizza il motivo di chiusura.

Qualsiasi avviso ignorato in precedenza può essere riaperto manualmente.

Protezione dei segreti compromessi

Una volta eseguito il commit di un segreto in un repository, il segreto viene compromesso. Microsoft consiglia le azioni seguenti per i segreti compromessi:

• Per un token di accesso personale di Azure DevOps compromesso, eliminare il token compromesso, creare un nuovo token e aggiornare tutti i servizi che usano il token precedente.
• Per tutti gli altri segreti, verificare innanzitutto che il segreto di cui è stato eseguito il commit in Azure Repos sia valido. In tal caso, creare un nuovo segreto, aggiornare eventuali servizi che usano il segreto precedente e quindi eliminare il segreto precedente.
• identificare le azioni eseguite dal token compromesso sulle risorse dell'organizzazione.

Quando si aggiorna un segreto, assicurarsi di archiviare il nuovo segreto in modo sicuro e assicurarsi che sia sempre accessibile e mai archiviato come testo non crittografato. Una possibilità può essere tramite l'insieme di credenziali delle chiavi di Azure o altre soluzioni di gestione dei segreti.

Protezione push dei segreti

La protezione push controlla eventuali push in ingresso per i segreti con attendibilità elevata e impedisce il passaggio del push. Un messaggio di errore visualizza tutti i segreti identificati per rimuoverli o continuare a eseguire il push dei segreti, se necessario.

Informazioni sugli avvisi di protezione push

Gli avvisi di protezione push sono avvisi utente segnalati dalla protezione push. L'analisi dei segreti come protezione push esegue attualmente l'analisi dei repository per i segreti rilasciati da alcuni provider di servizi.

Se l'accesso a una risorsa richiede credenziali abbinate, l'analisi dei segreti può creare un avviso solo quando entrambe le parti della coppia vengono rilevate nello stesso file. L'associazione garantisce che le perdite più critiche non siano nascoste dietro informazioni sulle perdite parziali. La corrispondenza delle coppie consente anche di ridurre i falsi positivi perché entrambi gli elementi di una coppia devono essere usati insieme per accedere alla risorsa del provider.

La protezione push potrebbe non bloccare le versioni precedenti di determinati token perché questi token possono generare un numero maggiore di falsi positivi rispetto alla versione più recente. La protezione push potrebbe anche non bloccare i token legacy. Per i token, ad esempio le chiavi di Archiviazione di Azure, La sicurezza avanzata supporta solo i token creati di recente, non i token che corrispondono ai modelli legacy.

Eseguire il push della protezione dalla riga di comando

La protezione push è incorporata in modo nativo in Azure DevOps Git. Se i commit contengono un segreto identificato, viene visualizzato un errore che indica che il push è stato rifiutato.

Protezione push dall'interfaccia Web

La protezione push funziona anche dall'interfaccia Web. Se un segreto viene identificato in un commit, viene visualizzato il blocco di errore seguente che impedisce il push delle modifiche:

Cosa fare se il push è stato bloccato

La protezione push blocca i segreti trovati in file di testo normale che sono in genere (ma non limitati a) file di testo, ad esempio il codice sorgente o i file di configurazione JSON. Questi segreti vengono archiviati in testo non crittografato. Se un attore malintenzionato ottiene l'accesso ai file e viene pubblicato in un repository pubblico, i segreti sono utilizzabili da chiunque.

È consigliabile rimuovere il segreto dal file contrassegnato e quindi rimuovere il segreto dalla cronologia dei commit. Se il segreto contrassegnato è un segnaposto o un segreto di esempio, è consigliabile aggiornare il segreto falso per anteporre la stringa Placeholder davanti al segreto falso.

Se il segreto è stato aggiunto nel commit precedente immediato, modificare il commit e creare un nuovo commit:

1. Rimuovere il segreto dal codice.
2. Eseguire il commit delle modifiche usando git commit --amend
3. Eseguire di nuovo il push delle modifiche.

Se il segreto è stato aggiunto di nuovo nella cronologia, modificare i commit usando una riassegnazione interattiva:

1. Usare git log per determinare quale commit è stato eseguito per primo.
2. Eseguire una rebase interattiva: git rebase -i [commit ID before credential introduction]~1
3. Identificare il commit da modificare modificando pick edit nella prima riga del testo visualizzato nell'editor.
4. Rimuovere il segreto dal codice.
5. Eseguire il commit della modifica con git commit --amend.
6. Completare la ribase eseguendo git rebase --continue.

Eseguire il push di un segreto bloccato

Non è consigliabile ignorare i segreti contrassegnati perché il bypass può mettere a rischio la sicurezza dell'azienda. Se si conferma che un segreto identificato non è un falso positivo, è necessario rimuovere il segreto dall'intera cronologia dei rami prima di tentare di eseguire nuovamente il push delle modifiche.

Se si ritiene che un segreto bloccato sia un falso positivo o sicuro da eseguire, è possibile ignorare la protezione push. Includere la stringa skip-secret-scanning:true nel messaggio di commit. Anche se si ignora la protezione push, viene generato un avviso di analisi dei segreti nell'esperienza utente dell'avviso dopo il push del segreto.