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.
Questa guida illustra i passaggi di configurazione e altre azioni che consentono di integrare GitHub Advanced Security (GHAS) e portale di Microsoft Azure con un caso d'uso che consente di convalidare l'integrazione end-to-end. Questa integrazione consente di ottimizzare la sicurezza delle applicazioni native del cloud di Microsoft correlando i rischi di runtime e il contesto con il codice originato per una correzione più rapida basata sull'intelligenza artificiale.
Seguendo questa guida, è possibile:
- Configurare il repository GitHub per la copertura di Defender for Cloud.
- Creare un fattore di rischio di esecuzione.
- Testare casi d'uso reali in Defender for Cloud.
- Collegare il codice alle risorse di runtime.
- Avviare una campagna di sicurezza in GitHub. Questa campagna usa il contesto di runtime per classificare in ordine di priorità gli avvisi di sicurezza GHAS.
- Creare issue GitHub in Defender for Cloud per iniziare la risoluzione.
- Colmare il divario tra i team di ingegneria e sicurezza.
Prerequisiti
| Aspetto | Dettagli |
|---|---|
| Requisiti ambientali | - GitHub account con un connettore creato in Defender for Cloud - Licenza GHAS - Defender Cloud Security Posture Management (DCSPM) abilitato nella sottoscrizione - Microsoft Security Copilot (facoltativo per la correzione automatica) |
| Ruoli e autorizzazioni | - Autorizzazioni di amministratore della sicurezza - Amministratore della sicurezza nella sottoscrizione Azure (per visualizzare i risultati in Defender for Cloud) - Proprietario dell'organizzazione GitHub |
| Ambienti Cloud | - Disponibile solo nei cloud commerciali (non in Azure per enti pubblici, Azure gestito da 21Vianet o da altri cloud sovrani) |
Prepara il tuo ambiente
Passaggio 1: Configurare il repository GitHub ed eseguire il flusso di lavoro
Per testare l'integrazione, usare repository personalizzati o un esempio GitHub repository che include già tutto il contenuto per creare un'immagine del contenitore vulnerabile. Prima di configurare un repository, assicurarsi che:
Si definisce un connettore per l'organizzazione GitHub che si prevede di usare nel portale di Defender for Cloud. Seguire i passaggi descritti in Connettere l'ambiente GitHub a portale di Microsoft Azure.
Configurare l'analisi del codice senza agente per il connettore GitHub. Seguire la procedura descritta in Configurare l'analisi del codice senza agente (anteprima).
Il repository usato per l'integrazione è privato.
Se si vuole usare un repository di esempio, clonare il repository seguente nell'organizzazione GitHub: build25-woodgrove/mdc-customer-playbook. Questo repository consente ai clienti di testare l'integrazione di Defender for Cloud e GHAS. Ha GHAS abilitato ed è inserito in un tenant di Azure con CSPM di defender abilitato.
Nel repository seguire questa procedura:
Andare a Impostazioni.
Nel riquadro sinistro selezionare Segreti e variabiliAzioni. Selezionare quindi Nuovo segreto del repository.
Aggiungere i segreti seguenti a livello di repository o organizzazione:
Variable Description ACR_ENDPOINTServer di login del registro dei container ACR_USERNAMENome utente per il registro contenitori ACR_PASSWORDPassword per il registro contenitori Annotazioni
I nomi possono essere scelti liberamente e non devono seguire un modello specifico.
È possibile trovare queste informazioni nel portale di Azure seguendo questa procedura:
Nel repository selezionare Azioni.
Selezionare il flusso di lavoro Compila e invia all'ACR e quindi selezionare Esegui flusso di lavoro.
Verificare che l'immagine sia stata distribuita al registro dei contenitori.
Per il repository di esempio, l'immagine deve trovarsi in un registro denominato mdc-mock-0001 con il tag mdc-ghas-integration.
Distribuire la stessa immagine come contenitore in esecuzione nel cluster. Un modo per completare questo passaggio consiste nel connettersi al cluster e usare il comando . Ecco un esempio per il servizio Azure Kubernetes:
Impostare la sottoscrizione del cluster:
az account set --subscription $subscriptionIDImpostare le credenziali per il cluster:
az aks get-credentials --resource-group $resourceGroupName --name $kubernetesClusterName --overwrite-existingDistribuire l'immagine:
kubectl run $containerName --image=$registryName.azurecr.io/mdc-mock-0001:mdc-ghas-integration
Passaggio 2: Creare il fattore di rischio di esempio (regola business critical)
Uno dei fattori di rischio rilevati da Defender for Cloud per questa integrazione è la criticità aziendale. Le organizzazioni possono creare regole per etichettare le risorse come business critical.
Nel portale di Defender for Cloud passare a Impostazioni ambienteCriticità risorse.
Nel riquadro destro selezionare il collegamento per aprire Microsoft Defender.
Selezionare Crea una nuova classificazione.
Screenshot del pulsante per la creazione di una nuova classificazione.
Immetti un nome e una descrizione.
Nel generatore di query selezionare Risorsa cloud.
Scrivere una query per impostare Nome risorsa uguale al nome del contenitore distribuito nel cluster per la convalida. Quindi seleziona Avanti.
Nella pagina Preview Assets, se Microsoft Defender ha già rilevato la tua risorsa, il nome del contenitore appare con un tipo di asset K8s-container o K8s-pod.
Anche se il nome non è ancora visibile, continuare con il passaggio successivo. Microsoft Defender applica l'etichetta di criticità al contenitore dopo aver rilevato il contenitore. Questo processo può richiedere fino a 24 ore.
Scegliere un livello di criticità e quindi esaminare e inviare la regola di classificazione.
Passaggio 3: Verificare che l'ambiente sia pronto
La convalida conferma che l'ambiente è configurato correttamente per visualizzare il codice in base alle raccomandazioni di runtime e generare risultati interattivi.
Durante questo passaggio, Defender verifica che:
- Visibilità completa del codice durante il runtime
- I repository di codice sorgente vengono monitorati continuamente da portale di Microsoft Azure per individuare le vulnerabilità di sicurezza.
- Gli artefatti di compilazione (ad esempio le immagini dei contenitori) vengono analizzati nei registri contenitori prima della distribuzione.
- I carichi di lavoro di runtime distribuiti nei cluster Kubernetes vengono monitorati per individuare i rischi per la sicurezza.
- Defender for Cloud correla e traccia ogni artefatto dal codice, tramite compilazione e distribuzione, al runtime e ritorno.
Annotazioni
Possono essere necessarie fino a 24 ore dopo l'applicazione dei passaggi precedenti per visualizzare i risultati seguenti.
Verificare che GitHub analisi senza agente preleva il repository.
Passare a Cloud Security Explorer ed eseguire la query. Le query di convalida testano se Defender può identificare gli artefatti prodotti dalle pipeline e dai carichi di lavoro. Se le query restituiscono risultati, indica che l'analisi e la correlazione funzionano come previsto.
Annotazioni
Se non vengono restituiti risultati, potrebbe indicare che gli artefatti non sono ancora generati, l'analisi non è configurata o le autorizzazioni non sono presenti. Per altre informazioni, vedere Ruoli utente e autorizzazioni .
Verificare che Defender for Cloud (in Registro Azure Container) ha analizzato l'immagine del contenitore e usata per creare un contenitore. Nella query aggiungere le condizioni per la distribuzione specifica.
Verificare che il contenitore sia in esecuzione e che Defender for Cloud abbia analizzato il cluster AKS.
Verificare che i fattori di rischio siano configurati correttamente sul lato Defender for Cloud. Cerca il tuo nome del contenitore nella pagina di inventario di Defender for Cloud, e dovrebbe essere contrassegnato come critico.
Annotazioni
Questo passaggio è necessario solo se i fattori di rischio non sono già configurati nell'ambiente.
Se si usano già fattori di rischio, è possibile verificare la configurazione in ImpostazioniCriticità risorsa.
La convalida corretta garantisce che i passaggi successivi, ad esempio raccomandazioni, campagne e GitHub generazione di problemi producano risultati significativi.
Passaggio 4: Creare una campagna GitHub
Poiché il flusso di lavoro distribuisce un'immagine che crea un contenitore in esecuzione con uno dei fattori di rischio (business critical), gli sviluppatori possono visualizzare i fattori di rischio in GitHub.
Annotazioni
Dopo aver classificato la risorsa come critica, possono essere necessarie fino a 12 ore prima che Defender for Cloud invii i dati a GitHub. Ulteriori informazioni.
Per creare una campagna di analisi, è necessario lavorare a livello di organizzazione GitHub. Questa esperienza non è disponibile a livello di singolo repository.
In GitHub passare all'organizzazione GitHub usata per il test di configurazione.
SelezionareSicurezzaCampagneCrea campagnaDai filtri di scansione del codice. Questa campagna definisce quali elementi individuati dal cloud (ad esempio immagini di contenitori o carichi di lavoro) vengono valutati e monitorati nell'ambiente.
Creare la campagna seguente. Questa campagna mostra gli avvisi aperti con gravità media in cui l'immagine distribuita dal repository è associata a una risorsa critica. Il repository di test dovrebbe essere rilevato con questa campagna.
Selezionare SalvaPubblica come campagna.
Immettere le informazioni necessarie e quindi pubblicare la campagna.
Passaggio 5: Valutare le raccomandazioni
Usare le raccomandazioni dal codice al runtime e gli avvisi di sicurezza per valutare lo stato dei problemi di sicurezza. È quindi possibile assegnare la raccomandazione per la risoluzione al team di ingegneria pertinente grazie alla connessione tra gli avvisi di sicurezza di Dependabot e la corrispondenza degli ID comunemente noti delle vulnerabilità ed esposizioni (CVE) in Defender per il Cloud.
Raccomandazioni sul runtime del codice
Per visualizzare i suggerimenti di ottimizzazione tra codice e runtime:
Nel portale di Defender for Cloud passare alla scheda Raccomandazioni .
Cercare il nome del contenitore creato. Aprire quindi una delle raccomandazioni per aggiornare il software , il nome della raccomandazione inizia con Aggiorna.
Se è stato usato il repository di esempio, cercare Aggiornare la raccomandazione brace-expansion.
Passare alla scheda Informazioni dettagliate correzione e visualizzare il codice per il diagramma di runtime. Il diagramma mappa il contenitore in esecuzione, all'immagine del contenitore nel repository del codice e al repository del codice di origine in GitHub.
Quando viene eseguita la campagna, Defender visualizza il codice per le raccomandazioni di runtime che mettono in correlazione i risultati del cloud con il codice e gli artefatti di compilazione.
La visualizzazione seguente fornisce il contesto degli asset interessati e dei segnali di rischio. Questa visualizzazione consente di comprendere il motivo per cui è stata generata una raccomandazione prima di intervenire.
Screenshot della scheda Informazioni dettagliate sulla correzione che mostra un diagramma delle fasi di sviluppo collegate.
Avvisi di sicurezza
Gli avvisi di sicurezza vengono visualizzati come parte del flusso di valutazione delle raccomandazioni. Questi avvisi forniscono un contesto aggiuntivo sui rischi attivi e consentono di classificare in ordine di priorità la correzione, ma non creano automaticamente GitHub problemi.
Selezionare la scheda Associated CVEs. Si noti che alcuni ID CVE hanno un collegamento View in GitHub nella colonna Related GitHub Alerts.
Selezionare il collegamento per aprire l'avviso di sicurezza GHAS pertinente. Per visualizzare il contenuto degli avvisi GHAS in GitHub è necessario disporre delle autorizzazioni di accesso per il repository di GitHub pertinente. Contattare l'amministratore GitHub in caso contrario.
Creare un problema di GitHub
Per chiudere il ciclo tra i team di progettazione e sicurezza, è possibile creare un problema GitHub che assegna priorità ai problemi di sicurezza su cui deve concentrarsi il team di progettazione. Questa prioritizzazione può includere il trasferimento dei risultati che GHAS non ha rilevato ma che Defender per il Cloud ha individuato per gli ID CVE che non fanno parte delle dipendenze dirette. Questi risultati possono includere vulnerabilità nell'immagine di base, nel sistema operativo o nel software come NGINX.
Il problema GitHub viene generato automaticamente con tutti gli ID CVE presenti nell'ambito della raccomandazione. La raccomandazione è con e senza corrispondenze di avvisi Dependabot, inclusi altri contesti di runtime sul repository di origine.
Dalla visualizzazione delle raccomandazioni è possibile generare in modo esplicito un problema di GitHub per tenere traccia del lavoro di correzione.
Aprire la raccomandazione relativa all'aggiornamento software .
Selezionare la scheda Informazioni dettagliate correzione.
Esaminare la casella Runtime interessata.
Validate se esiste già un problema di GitHub: se esiste già un problema di GitHub, viene visualizzata un'icona GitHub nella casella. Passare il puntatore del mouse sull'icona per visualizzare i dettagli del problema.
Se non esiste alcun problema e si dispone delle autorizzazioni necessarie, è possibile generare un nuovo problema di GitHub.Selezionare Intervenire.
Selezionare l'opzione Genera segnalazione su GitHub dal popup.
Se il problema è stato creato correttamente, verrà visualizzata una notifica popup con un collegamento al problema.
Il problema viene creato nel repository di codice di origine.
Annotazioni
Se l'opzione Genera problema GitHub non è disponibile, i permessi necessari per GitHub o il repository potrebbero mancare.
Contattare il GitHub o l'amministratore del repository per richiedere l'accesso.Quando il problema viene assegnato a un utente GitHub o se lo stato viene modificato, l'aggiornamento si riflette nel portale di Defender for Cloud.
Monitorare gli aggiornamenti di proprietà e stato - Le modifiche apportate allo stato dei problemi o all'assegnazione in GitHub vengono riflesse in Microsoft Defender per il cloud, consentendo di tenere traccia della proprietà e dell'avanzamento della risoluzione.
Apportare correzioni proattive
Sul lato GitHub, se si dispone di una licenza GitHub Copilot, è possibile risolvere il problema con l'aiuto dell'agente di codifica GitHub:
- Assegnare un agente di codifica GitHub al problema.
- Esaminare la correzione generata.
- Se la correzione sembra ragionevole, applicarla.
- Osservare come Defender for Cloud aggiorna lo stato del problema a Chiuso.
Contenuti correlati
- Che cos'è GitHub'integrazione della sicurezza avanzata con portale di Microsoft Azure (anteprima)?
- Panoramica della sicurezza portale di Microsoft Azure DevOps
- Quickstart: Connettere l'ambiente GitHub a portale di Microsoft Azure
- Configurare l'analisi del codice senza agente (anteprima)