Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Le credenziali esposte nei sistemi di progettazione offrono opportunità facilmente sfruttabili per gli utenti malintenzionati. Per difendersi da questa minaccia, GitHub Advanced Security for Azure DevOps analizza le credenziali e altri contenuti sensibili nel codice sorgente. La protezione push impedisce anche la perdita di credenziali fin dall'inizio. È necessario gitHub Advanced Security per Azure DevOps o, se si usa l'esperienza autonoma, GitHub Secret Protection per Azure DevOps abilitato.
L'analisi dei segreti nel repository cerca eventuali segreti già esistenti nel codice sorgente storico e la protezione al push impedisce che nuovi segreti vengano esposti 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.
Prerequisiti
Per altre informazioni sulle autorizzazioni di sicurezza avanzata, vedere Gestire le autorizzazioni di sicurezza avanzata.
Informazioni sugli avvisi di scansione dei segreti
Quando si abilita la protezione avanzata o la protezione dei segreti in particolare, analizza i repository per i segreti emessi da vari provider di servizi e genera avvisi di analisi dei segreti.
Se l'accesso a una risorsa richiede credenziali abbinate, l'analisi dei segreti crea un avviso solo quando vengono rilevate entrambe le parti della coppia nello stesso file. L'accoppiamento garantisce che le perdite più critiche non siano nascoste dietro le informazioni relative alle perdite parziali. L'abbinamento di coppie aiuta anche a ridurre i falsi positivi, poiché 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 le allerte di scansione dei segreti. È possibile filtrare in base allo stato e al tipo di segreto. Vai a un avviso per ulteriori dettagli, incluse le linee guida per la risoluzione. Dopo aver abilitato Sicurezza avanzata, viene avviata un'analisi per il repository selezionato, inclusi tutti i commit cronologici. Nel corso del tempo, gli avvisi vengono visualizzati man mano che l'analisi avanza.
La ridenominazione dei rami non influisce sui risultati. Tuttavia, la visualizzazione del nuovo nome potrebbe richiedere fino a 24 ore.
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 doverlo inserire direttamente 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 una credenziale primaria rispetto a una credenziale secondaria è identico, salvo indicazioni contrarie.
Gestire gli avvisi di scansione dei segreti
Visualizzazione degli avvisi per un repository
Seleziona la scheda Segreti per visualizzare tutti gli avvisi di scansione 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 forniti sono visualizzabili selezionando "Altro" dall'elenco a discesa attendibilità nella scheda analisi dei segreti.
Dettagli dell'avviso
Quando si passa a un avviso, appare una vista dettagliata dell'avviso che rivela ulteriori dettagli sul rilevamento e fornisce indicazioni specifiche per la risoluzione dell'avviso.
Annotazioni
L'immagine contiene un valore formattato per assomigliare a un token di accesso personale ( PAT). Questo valore non è un pat valido e viene usato solo a scopo illustrativo. GitHub Advanced Security per Azure DevOps esegue controlli di validità sui segreti rilevati. Sebbene lo strumento possa inizialmente rilevare valori che corrispondono al formato previsto di un pat, esegue una convalida aggiuntiva per verificare l'autenticità. Se un token ha esito negativo, ovvero non è un pat valido effettivo, l'analisi dei segreti lo riconosce come non valido e non attiva un avviso di rilevamento. Ciò consente di ridurre i falsi positivi e garantisce che solo i segreti effettivi e validi generino avvisi.
| Sezione | Spiegazione |
|---|---|
| Posizione | La sezione Locations descrive in dettaglio i percorsi in cui la scansione dei segreti ha individuato le credenziali trapelate. Potrebbero essere presenti più posizioni o più commit nella cronologia che contengono la credenziale trapelata. Tutti questi posizioni e commit vengono visualizzati sotto Posizioni con un collegamento diretto al frammento di codice e al commit in cui è stato identificato. |
| Raccomandazione | La sezione delle raccomandazioni contiene linee guida per la correzione o un collegamento a indicazioni sulla correzione della documentazione non Microsoft per le credenziali identificate. |
| Chiudi avviso | Non esiste alcuna funzionalità di correzione automatica per gli avvisi di scansione dei segreti. Tutti gli avvisi di scansione dei segreti devono essere attestati manualmente come rettificati 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 fornitori, il tag Confidence: other appare anche accanto al badge di gravità nella vista dettagli degli avvisi.
Correzione degli avvisi di scansione dei segreti
Ogni segreto ha passaggi di correzione univoci per guidare l'utente attraverso come revocare e rigenerare un nuovo segreto al suo posto. Il dettaglio dell'avviso condivide passaggi specifici o documentazione per ogni avviso.
Un avviso di scansione segreti rimane aperto finché non è chiuso. Per attestare che l'allerta di analisi dei segreti è stata risolta:
- Vai all'avviso che desideri chiudere e selezionalo.
- Selezionare il menu a discesa Chiudi avviso.
- Se non è già selezionata, selezionare Fisso.
- Selezionare Chiudi per inviare e chiudere l'avviso.
Ignorare gli avvisi di analisi dei segreti
Per ignorare un avviso, seguire questa procedura:
- Vai all'avviso che desideri chiudere e fare clic su di esso.
- Selezionare il menu a discesa Chiudi avviso.
- Se non è già selezionata, selezionare Rischio accettato o Falso positivo come motivo di chiusura.
- Aggiungere un commento facoltativo nella casella di testo Commento .
- Selezionare Chiudi per inviare e chiudere l'avviso.
- Lo stato dell'avviso passa da Aperto a Chiuso e visualizza il tuo motivo della rimozione.
È possibile aprire manualmente qualsiasi avviso ignorato in precedenza.
Mettere al sicuro i segreti compromessi
Una volta effettuato il commit di un segreto in un repository, il segreto viene compromesso. Microsoft consiglia le azioni seguenti per i segreti compromessi:
Importante
Prendere in considerazione l'uso dei token microsoft Entra più sicuri rispetto ai token di accesso personali a rischio più elevato. Per altre informazioni, vedere Ridurre l'utilizzo di PAT. Esaminare le indicazioni per l'autenticazione per scegliere il meccanismo di autenticazione appropriato per le proprie esigenze.
- 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, archiviare il nuovo segreto in modo sicuro e assicurarsi che non venga mai archiviato come testo non crittografato. Un'opzione consiste nell'usare Azure Key Vault o altre soluzioni di gestione dei segreti.
Protezione dei segreti tramite push
La protezione push verifica eventuali push in arrivo per individuare segreti ad alta attendibilità e ne impedisce l'avanzamento. Un messaggio di errore visualizza tutti i segreti identificati, consentendoti di rimuoverli o di continuare con l'invio 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 attualmente esegue la scansione dei repository per i segreti forniti da alcuni provider di servizi.
Se l'accesso a una risorsa richiede credenziali abbinate, l'analisi dei segreti potrebbe creare un avviso solo quando entrambe le parti della coppia vengono rilevate nello stesso file. L'accoppiamento garantisce che le perdite più critiche non coprano informazioni sulle perdite parziali. L'abbinamento di coppie aiuta anche a ridurre i falsi positivi, poiché 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 potrebbero generare un numero più elevato 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.
Attivare la protezione push dalla riga di comando
La protezione push è incorporata in modo nativo in Azure DevOps Git. Se i commit contengono un segreto identificato, l'errore seguente 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 di eseguire 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.
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, 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:
- Rimuovere il segreto dal codice.
- Eseguire il commit delle modifiche usando
git commit --amend - Eseguire di nuovo il push delle modifiche.
Se il segreto è stato aggiunto indietro nella cronologia, modifica i commit usando un rebase interattivo:
- Usare
git logper determinare in quale commit hai inserito per la prima volta il segreto. - Eseguire una rebase interattiva:
git rebase -i [commit ID before credential introduction]~1 - Identificare il commit da modificare modificando
pickeditnella prima riga del testo visualizzato nell'editor. - Rimuovere il segreto dal codice.
- Confermare il cambiamento con
git commit --amend. - Completa il rebase eseguendo
git rebase --continue.
Eseguire il push di un segreto bloccato
Non ignorare i segreti contrassegnati perché ciò può mettere a rischio la sicurezza dell'azienda. Se confermi che un segreto identificato non è un falso positivo, rimuovi il segreto dall'intera cronologia del branch prima di spingere di nuovo le modifiche.
Se si ritiene che un segreto bloccato sia un falso positivo o sicuro da inviare, è possibile ignorare la protezione del push.
Includere la stringa skip-secret-scanning:true nel messaggio di commit.
Anche se si ignora la protezione contro il push, viene generato un avviso di scansione dei segreti nell'interfaccia di avviso una volta che il segreto viene inviato.
Informazioni sui controlli di validità
I controlli di validità dei segreti consentono di classificare in ordine di priorità gli avvisi indicando se un segreto rilevato è ancora utilizzabile. Per i tipi di segreti supportati, GitHub Advanced Security per Azure DevOps chiede automaticamente al provider emittente se la credenziale è attiva, dopo l'abilitazione dell'analisi dei segreti non è necessaria alcuna funzionalità separata.
Se il bundle GitHub Advanced Security per Azure DevOps o la protezione dei segreti è attivata, i controlli di validità vengono abilitati automaticamente.
Cosa si ottiene
- Verifica automatica per i tipi di segreti partner supportati (nessuna configurazione aggiuntiva).
- Stato visualizzato nell'elenco degli avvisi di scansione dei segreti e nel pannello dei dettagli.
- Applicazione di filtri in base allo stato di convalida in modo da potersi concentrare sui segreti attivi.
- Facoltativamente, è possibile eseguire un controllo di validità "su richiesta" per il segreto nella schermata di avviso.
Significati dello stato
| stato | Meaning | Action |
|---|---|---|
Active |
Il provider ha confermato che il segreto è ancora utilizzabile. | Aprire l'avviso e seguire la procedura raccomandazioni e correzione. |
| Sconosciuto | Nessun segnale definitivo di attività; potrebbe essere inattivo o la verifica non è riuscita a causa di un servizio, di rete o di altri errori imprevisti. | Trattare come potenzialmente attivo; ripetere la verifica o effettuare una rotazione se sensibile. |
Flusso di lavoro tipico
- Filtrare lo stato di convalida =
Activeper visualizzare avvisi con rischio più elevato. - Per ogni segreto attivo, aprire l'avviso e seguire i passaggi di raccomandazione e correzione forniti nella visualizzazione degli avvisi.
- Usare la verifica su richiesta dopo la correzione per confermare le modifiche dello stato.
- Gestire i segreti sconosciuti successivamente: ripetere la verifica su richiesta quando necessario o trattarli come attivi se i dati sono sensibili.
- Chiudere gli avvisi secondo la tua politica dopo aver completato i passaggi di rimedio nell'avviso.
Verifica su richiesta
Usare "verify secret" (nel dettaglio dell'avviso) dopo aver seguito le raccomandazioni e la correzione o quando un tentativo precedente ha restituito Sconosciuto. Il timestamp viene aggiornato al completamento.